Synchronous messaging for mobile station

Abstract

In some embodiments, base station/mobile station state entry schemes may use synchronous messaging for mobile stations to enter into a state in synchronization with an associated base station, e.g., they both know the frame or relative frame in which the state is to be entered, whether or not it actually is entered in that frame.

Description

TECHNICAL FIELD

The present invention relates generally to wireless devices and in particular, to messaging between base stations and mobile stations.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements.

FIG. 1 is a diagram of a network system including a heterogeneous wireless access network in accordance with some embodiments.

FIG. 2 is a flow diagram of a method for synchronous event messaging in accordance with some embodiments.

FIG. 3 is a diagram illustrating base station initiated synchronous event messaging in accordance with some embodiments.

FIG. 4 is a diagram illustrating base station initiated synchronous event messaging with retries in accordance with some embodiments.

FIG. 5 is a diagram illustrating mobile station initiated synchronous event messaging in accordance with some embodiments.

FIG. 6 is a diagram illustrating mobile station initiated quick synchronous event messaging in accordance with some embodiments.

FIG. 7 is a diagram illustrating mobile station initiated quick synchronous event messaging with retries in accordance with some embodiments.

DETAILED DESCRIPTION

Embodiments of the present invention may help facilitate improved performance for high throughput wireless networks, e.g., IEEE 802.16, 3GPP Long Term Evolution LTE, LTE advanced mobile phone networks and other types of high bandwidth networks. In some embodiments, base station/mobile station state entry schemes use synchronous messaging, e.g., in the MAC (media access control) layer management messages for mobile stations to enter into a state in synchronization with an associated base station. That is, they both know the frame or relative frame in which the state is to be entered, whether or not it actually is entered in that frame.

FIG. 1 shows a simplified exemplary network with wireless access through a radio access network (RAN) 101. The RAN may be implemented as a homogeneous network, using a single wireless technology, or as a heterogeneous network, using a combination of different wireless technologies. The RAN allows mobile stations (MS) (also referred to as subscriber stations or mobile terminals) to access multiple different networks (NTWK) 108 via network switches 106. The networks 108 may comprise any networks including but not limited to voice and/or data networks such as the Internet (TCP/IP), the public switch telephone network (PSTN), other subscriber based voice/data networks, and others.

The switches 106 generally refer to the different switches (e.g., circuit and/or soft switches) used to find and/or connect a client to a desired target within the networks 108 and/or RAN 101. They may also comprise gateway interfaces and any other server apparatuses for performing desired connectivity.

The RAN 101 includes base stations (BS) 102. They are coupled to radio network controllers 104 for controlling client access through the RAN, and ultimately, to one or more of the networks 108 or to another wireless client in the RAN. In a general sense, the base stations may comprise RNC functionality, depending on particular architectures.

The base stations provide an air interface for transmitting and receiving signals with mobile stations. The base stations may also be coupled between each other, e.g., wirelessly or through cable connections. In many embodiments, they facilitate functions such as modulation/demodulation and depending on the utilized wireless communications scheme, physical channel coding, micro diversity, error handling, and/or closed loop power control. The controllers 104 may function to control radio resources and admission, allocate channels, control power settings, control handover, and/or control macro diversity, ciphering, segmentation/reassembly, broadcast signaling, and open loop power control. Again, they may or may not be part of a base station, e.g., there may be a controller serving more than one base station or each station may comprise its own controller.

The RAN 101 corresponds generally to a cellular RAN for a given wireless operator (e.g., Verizon™, AT&T™, and Sprint™), but as used herein, it may also encompass other types of access networks, depending, among other things, on characteristics of the wireless operator and wireless client such as how the network is configured, the type of wireless client, where it is, and the like. For example, it may encompass local area networks such as WiFi networks and the like that may be accessible to a wireless client. It may also comprise other or at least portions of other operator access networks such as when roaming is available.

Transmission of data from within the RAN 101 to a mobile station (MS) may proceed in the following manner. Data such as voice data, IP packets or Ethernet frames may be encapsulated in an appropriate format (e.g., WiMax or LTE data frame format) and forwarded from a network 108 to an appropriate base station, e.g., the “serving” base station, within a given cell. The serving base station then transmits the data to the MS using a unidirectional wireless link, which may be referred to as a “downlink” (or forward link). Transmission of data from the MS to a network destination proceeds in the reverse direction. In this case, the encapsulated data is transmitted from the mobile station to its serving base station, typically using a unidirectional wireless link referred to as an “uplink” (or forward link). After passing through the network controller, the data packets are forwarded through an appropriate switch, converted to an appropriate format, e.g., IP Packets or Ethernet frames, and transmitted henceforth to the desired destination. Data (e.g., data bursts) may be transmitted using a Time-Division-Duplexing (TDD) scheme. In the TDD scheme, both the uplink and downlink typically share the same RF channel, but do not transmit simultaneously.

A BS may activate or authorize an MS to enter into a state to participate in an event such as a handover or scan operation, or to be in a desired mode such as a sleep mode. For the state to be entered, it is typically desired for the BS and MS to be in synchronization with one another as to the start frame for state entry. The BS and MS message each other to agree on the state to start in a known future frame. Traditionally, asynchronous messaging has been used, but it can be wasteful in that excessive frames may be allotted for retransmission. Accordingly, in accordance with some embodiments, synchronous messaging schemes are presented herein.

FIG. 2 shows a routine 201 for a mobile station (MS) to enter into a state by way of synchronous messaging between itself and an associated BS. FIGS. 3 through 5, discussed below, depict different ways in which this may occur. At 202, the MS receives a state entry communication from the BS. it may have been initiated by the BS, or alternatively, it may be in response to an initial message from the MS to the BS. The communication may be any type of suitable communication from a BS. For example, it could be a command sent specifically to the MS, or alternatively, it could be part of a multi-cast transmission such as with a traffic indication message (e.g., a MOB_TRF-IND communication used with WiMax systems). The communication will typically include a particular state (e.g., sleep mode) that the MS is to enter or a confirmation that a requested state may be entered.

At 204, the MS transmits a response back to the BS. This may be a conventional response used to acknowledge receipt of the received communication. This response, in some embodiments, serves as a synchronization reference for the MS and BS. At 206, the MS waits to determine if an additional communication (e.g., retry message) from the BS is received within a hold-off interval. If for some reason, the BS didn't receive the response from the MS, e.g., within a specified number (one or more) of frames from when it sent the communication, it will typically send the message again. The hold-off time should be sufficient to allow the MS to receive such a retry message if it is sent by the BS.

If the hold-off time elapses without the MS receiving another communication from the BS, then at 208, the MS enters the designated state in a frame (i.e., a “start” frame) that is a pre-designated number (zero, one, or some other number) of frames from the end of the hold-off time. On the other hand, if another message from the BS is received within the hold-off time, then the routine goes back, to 204 and treats that additional (e.g., retry) communication as if it were a communication received at 202 (e.g., an initial communication). The BS and MS will be state synchronized (the BS knows the frame when the state is entered) because when it receives the response communication from the MS, it knows that the MS will enter the sate in the pre-designated number of frames from the end of the hold-off time. In some embodiments, with a sufficiently wide frame interval (e.g., close to 5 mSec.), the BS may assume that it receives the response communication in the frame that is just before the MS's hold-off interval. Thus, the MS and BS both know when (what frame) the state is to be entered without the need for selection and transmission of start frame information.

FIG. 3 shows an example of a BS initiated synchronous messaging scheme. As indicated in the figure, there is a fixed relationship between CMD (command communication) from the BS and RSP, the response from the MS back to the BS. In the depicted embodiment, the relationship is that the frames are adjacent with one another.

The BS sends the CMD communication to the MS. For example, it may be a command for the MS to enter into a sleep mode. If the MS doesn't receive another CMD communication from the BS within the hold-off time, then it enters the commanded state in the frame just after the hold-off time (which is a single frame in this case) expires. The BS and MS are said to be synchronized when the state is entered. This is indicated by the frame(s) (F6 here) that are hatched.

The hold-off time is an interval (in this example, shown as one frame) that provides the BS with a means to re-send the CMD communication before the MS enters the commanded state to start the synchronized action. Depending on particular design concerns, the hold-off time may be one or more frames. In some embodiments, depending on how the frames are defined, it could also be a frame fraction or combinations thereof.

FIG. 4 shows the example of FIG. 3 but with errors and retries. The “X'd” out arrows indicate transmission(s) not received by the entity that is to receive the transmission. As shown, when the BS does not receive the RSP communication from the MS, the CMD communication is sent again by the BS. If the RSP is not received by the BS within its acceptable frame range (the next frame IN THIS EXAMPLE), then the BS sends the CMD again. Note that the hold-off interval should be chosen to be sufficiently long to give the BS enough time to re-send the CMD and be received by the MS before it assumes it can enter the commanded state. The BS repeats this until it receives an acceptable response (RSP) within the appropriate frame range (for this example, the next frame after CMD was sent).

FIG. 5 shows an example of an MS initiated synchronous messaging scenario. The MS makes the request and then the BS actions follow those for the BS-initiated cases. Since in many schemes, the BS may change the MS request (the BS usually has permission to alter the MS requests), this can be readily done. The MS retries if it does not receive the BS CMD communication within the specified interval (e.g., not more than a few frames). One variant is to place the MS request into a bandwidth request (e.g., CDMA BW request) header, which removes the need for the MS REQ communication.

FIG. 6 shows another embodiment for an MS-initiated case. In this case, the synchronization is referenced from the MS request, as with the previous embodiments, and then it enters the state on the frame that occurs after it receives a confirmation from the BS. The MS requests an action (e.g., sleep mode, range request, etc.) that the BS does not alter. The BS then confirms that it received the request (and implicitly authorizes it) through a confirmation communication (labeled as CNFN). The confirmation can come in any suitable type of communication, however, in some embodiments, it may be sent using a multi-cast communication from the BS (e.g., a traffic indication message such as MOB_TRF-IND message in a WiMax system). It may be repeated on purpose to give extra chances for the MS to receive it. Note that the synchronization reference still comes from the MS communication, i.e., the REQ communication in this example. The MS may not enter the state until it receives confirmation from the BS (e.g., from the second, third or later CNFN message), but it and the BS still reference synchronization from the MS REQ frame.

With this method, if MS does not receive response (CNFN) from BS, MS has another chance to receive it without needing to perform a CDMA bandwidth request and then send another state entry request. FIG. 7 shows the example of FIG. 6 but with transmission errors included.

The invention is not limited to the embodiments described, but can be practiced with modification and alteration within the spirit and scope of the appended claims. For example, it should be appreciated that the present invention is applicable for use with all types of mobile devices. Examples include but are not limited to personal computers, cellular phones, so-called smart phones, and the like. Further, arrangements may be shown in block diagram form in order to avoid obscuring the invention, and also in view of the fact that specifics with respect to implementation of such block diagram arrangements are highly dependent upon the platform within which the present invention is to be implemented, i.e., such specifics should be well within purview of one skilled in the art. Where specific details are set forth in order to describe example embodiments of the invention, it should be apparent to one skilled in the art that the invention can be practiced without, or with variation of, these specific details. The description is thus to be regarded as illustrative instead of limiting.

Claims

1. A method, comprising: in a mobile station, receiving a state entry communication from a base station;transmitting a response to the base station; andentering the state if another state entry communication is not received from the base station within a hold-off interval.

2. The method of claim 1, in which the state entry communication is a command for the mobile station to enter into the state.

3. The method of claim 2, in which the state is a state for the mobile station to enter into a sleep mode.

4. The method of claim 1, in which the base and mobile stations communicate in accordance with a WiMax protocol.

5. The method of claim 1, in which the state is entered by the mobile station in a frame that comes directly after the hold-off interval ends.

6. The method of claim 1, in which the mobile and base stations are synchronized, as to the mobile station state, referenced from a frame corresponding to the transmitted response.

7. A mobile station to perform the method of claim 1.

8. The method of claim 1, in which the state entry communication is initiated by the mobile station via a state request communication from the mobile station to the base station.

9. A method, comprising: in a mobile station, transmitting to a base station a state entry request;receiving a confirmation communication from the base station; andentering the requested state, in response to the confirmation, wherein the base station and mobile station assume state entry referenced from a pre-designated frame interval after the state entry request.

10. The method of claim 9, in which the base station sends multiple confirmation communications to the mobile station.

11. The method of claim 9, in which the confirmation communication is through a multi-cast communication from the base station.

12. The method of claim 11, in which the pre-designated frame interval is 1 frame, wherein the state entry is assumed to be in the second frame after the state entry request.

13. A mobile station to perform the method of claim 9.

14. A radio access network, comprising: a base station to send a state entry communication to a mobile station, and receive a response from the mobile station, the mobile station to enter the state if another state entry communication is not received from the base station within a hold-off duration.

15. The network of claim 14, in which the state entry communication is a command for the mobile station to enter into the state.

16. The network of claim 15, in which the state is a state for the mobile station to enter into a sleep mode.

17. The network of claim 14, in which the base and mobile stations communicate in accordance with a WiMax protocol.