State model for a wireless device

Details State model for a wireless device State model for a wireless device

2002-01-03

2003-08-12

Trost, William (Department: 2683)

Telecommunications

Radiotelephone system

Zoned or cellular telephone system

C455S509000

Reexamination Certificate

active

06606498

ABSTRACT:

BACKGROUND OF INVENTION
1. Field of the Invention
The present invention relates to a state machine. More specifically, the present invention discloses a state machine with a unique slot seizing state that is compatible with Personal Access Communications System (PACS) protocol enabled devices.
2. Description of the Prior Art
Please refer to FIG.
1
.
FIG. 1
is a partial functional diagram of Personal Access Communications System (PACS) architecture and signaling layers, which is fully described in the PACS Air Interface Rev. A manual, and which is incorporated herein by reference. A typical PACS wireless environment
10
includes one or more subscriber units (SUs)
12
in wireless communications with one or more radio ports (RPs)
14
. The RPs
14
, in turn, are in communications with a radio port controller unit (RPCU)
16
, which controls the RPs
14
, receiving signals from, and sending signals to, the RPs
14
. The RPCU
16
is used to connect to a broader access network (not shown) such as a telephone network or the like. Interface A is an air interface, which is bridged by wireless signals between the SU
12
and the RP
14
. Most modern communications protocols are arranged as a three-tiered structure, with the lowest layer, layer
1
, being the physical layer that connects two devices. The layer
1
interface thus bridges interface A, extending only so far as the RP
14
. Interface P provides connectivity between the RPCU
16
and the RPs
14
, the exact nature of which may vary from implementation to implementation. There is a corresponding state machine on both the SU
14
and RPCU
16
sides for layer
2
communications, and the situation is similar for layer
3
. Instead of layers
2
and
3
, RP
14
plays the layer
1
role of bridging interfaces A and P.
Please refer to FIG.
2
.
FIG. 2
is a simplified block diagram of a PACS SU
20
. The SU
20
includes a processor
22
that executes SU software modules
24
. The software modules
24
include kernel code
26
that is implementation-specific, depending upon the hardware used within the SU
20
; drivers
30
for providing a general interface with the kernel
26
; a layer
1
interface
31
; a layer
2
interface
32
; a layer
3
interface
33
; a man machine interface (MMI)
34
and utilities
35
. The utilities
35
provide such functionality as timers and timer management, memory management, and the like. The MMI
34
is in charge of controlling an LCD
28
, and handling input signals from a keypad
27
, to provide a user interface for the SU
20
. The PACS layer
3
interface
33
supports the MMI
34
, and provides authentication, privacy (encryption/decryption), emergency calls and supplemental services. The PACS layer
2
interface
32
supports the layer
3
interface
33
, and provides for alerting services, channel access, synchronization, multiplexing/demultiplexing, segmentation and assembly and the like. The PACS layer
1
interface
31
supports the layer
2
interface
32
and provides the physical link required to communicate with an RP
14
, and hence the RPCU
16
.
Please refer to FIG.
3
.
FIG. 3
is a block diagram for communications in a PACS system from a SU layer
3
perspective. Within a SU
40
, a PACS layer
3
interface
43
is in communications with an MMI
44
for the SU
40
, a PACS layer
2
interface
42
, timers
41
, and a PACS RPCU layer
3
interface
43
x
. Communications with the RPCU layer
3
interface
43
x
is wireless in nature, through the layer
2
interface
42
, and a supporting layer
1
interface (not shown). However, from the standpoint of the SU layer
3
interface
43
, such complications are not apparent, and the SU layer
3
interface
43
appears to communicate directly with the RPCU layer
3
interface
43
x
, both passing messages to, and receiving messages from, the RPCU layer
3
interface
43
x
. Similarly, the SU layer
3
interface
43
exchanges messages with the MMI
44
and the lower layer
2
interface
42
. The layer
3
interface
43
is able to set a plurality of timers
41
, and receive notification when any of the timers
41
expires.
Please refer to FIG.
4
.
FIG. 4
is a finite state model for a PACS layer
3
interface. For stable and predictable operations, a PACS layer
3
interface runs as a finite state machine
50
S, transitioning from one state to another on an event, and performing some action just prior to the state transition. A key state is a null state
50
in which the layer
3
state machine
50
S has no traffic channel established with an RPCU
16
and is awaiting anything “interesting” to happen. Any “interesting” event will cause the state machine
50
S to transition out of the null state
50
and into another state designed to handle that particular “interesting” event. For example, one such event is a layer
2
42
notification that the SU
40
must register with the RPCU
16
. On such an event, the state machine
50
S transitions to a terminal registration pending state
56
to await confirmation of registration with the RPCU
16
. Two other types of events are incoming call detection and non-emergency call origination events. In the first, another user is attempting to call the SU
40
. In the later, the MMI
44
indicates that the user is attempting to make a call. In either event, the state machine
50
S first transitions to a radio call identifier pending state
51
to await reception from the RPCU layer
3
interface
43
x
of an identifier for the particular call. After receiving the radio call identifier from the RPCU layer
3
interface
43
x
, the state machine
50
S transitions to either an incoming call present state
52
, or a call initiated state
53
depending on whether or not the SU
40
is the originator of the call. In the incoming call present state
52
, the state machine
50
S waits for the user to answer the call, and alerts the user of an incoming call (i.e., by ringing the telephone). When the user answers the phone, the state machine
50
S transitions into a call received state
57
. In the call received state
57
, the SU
40
informs the RPCU layer
3
interface
43
x
that the user has answered the phone, and awaits acknowledgement from the RPCU layer
3
interface
43
x
. Once the RPCU layer
3
interface
43
x
acknowledges the SU
40
, the state machine
50
S transitions into a stable state
59
. Similarly, in the call initiated state
53
, the state machine
50
S awaits for connection confirmation from the RPCU layer
3
interface
43
x
that the call has been placed. Once such confirmation is received, the state machine
50
S transitions into the stable state
59
. It is in the stable state
59
that the exchange of user information (voice or data) occurs. Hanging up the phone, as indicated from the MMI
44
, causes the state machine
50
S to transition into a disconnect request state
54
in which the SU
40
inform the RPCU layer
3
interface
43
x
that the call is terminated and awaits acknowledgment of such from the RPCU layer
3
interface
43
x
. On such acknowledgment, the state machine
50
S transitions back into the null state
50
. Due to their nature, emergency calls are handled separately from normal, non-emergency calls. On detection of origination of an emergency call, the state machine
50
S transitions from the null state
50
into an emergency call request state
58
. While in the emergency call request state
58
, the SU
40
awaits registration of the call with the RPCU layer
3
interface
43
x
, confirmation of which causes the state machine
50
S to then transition into the call initiated state
53
.
Every transition from the null state
50
requires that the SU
40
establish a traffic channel with the RPCU layer
3
interface
43
x
. This is termed slot seizing, and is required for any type of originating call, incoming calls, and terminal registration of the SU
40
. However, the prior art does not distinctly provide for slot seizing. Slot seizing should not properly be performed in the null state
50
as the null state is specifically a state in which no

Affiliated with

Also associated with

Rating

State model for a wireless device does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with State model for a wireless device, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and State model for a wireless device will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3081528