Sunday, August 1, 2010

Energy Conservation via Sleep Mode

Need for "Sleep" and "Wakeup" Modes
The simplest way to save energy and thus prolong the battery life of a SS is to put the SS to "sleep" (i.e., kill all processes running on the SS except for the minimum required to sustain the connection) when it is not involved in any communications. During the sleep period, the SS will not transmit, but "listen" to the channel occasionally to maintain connectivity. This feature is not specified in the 802.16-2004 standard, as that standard was proposed for stationary SSs and it was assumed that power supply for the SSs would not be a critical problem.

Clearly, an SS in the sleep mode requires a complementary mechanism for "waking up" so that it can resume transmitting or receiving. The signaling message that accomplishes this is usually called the "paging" signal. Again, the 802.16-2004 standard does not include a paging signal either.

Message Exchanges to Enter Sleep Mode
We propose the following sequence of steps before an SS enters the sleep mode.

Based on a lack of traffic on the DL and UL, the SS decides that it should enter the sleep mode. Thus, the decision to enter the sleep mode is SS-initiated. The algorithm that the SS applies to arrive at this decision is arbitrary, and can be specific to that SS alone while being unknown to the BS.

The SS uses a CID belonging to one of its current sessions to send a bandwidth request (BR) message to the BS. This is the mechanism for requesting additional bandwidth specified in the current 802.16-2004 standard. As it is very unlikely for a SS to specify 0 bytes in the BR message (i.e., requesting zero additional bandwidth), we propose for the BS to interpret such a message from the SS as a request for permission to enter the sleep mode. A key advantage of such use of BR message with 0-byte request is that if the BS is not enabled to support this sleep/wakeup function, then a request for an additional bandwidth of zero bytes will simply be ignored or discarded, thereby causing no changes to the current session.

If the BS is capable of supporting sleep/wakeup in the SS, then it includes a pre-specified Uplink Interval Usage Code (UIUC) that serves as an acknowledgment to the SS that it is allowed to enter into the sleep mode. The specific UIUC is known and hard-wired in the BS and SS.

On receipt of this acknowledgment message from the BS, the SS enters the sleep mode after a fixed time interval (measured in the number of frames), which is set by the network operator and assumed known to both the BS and the SS. This obviates the need to transmit this interval defining the sleep start time from BS to SS or vice versa, thereby eliminating the need to change the standard to accommodate a message that does so.

During the sleep mode, the SS maintains frame synchronization (this is one of the few processes that are maintained during the sleep mode). Further, the SS decodes DL information periodically to check whether the SS is being "paged" by the BS (see the description of the "wakeup" subsequently). The period (e.g., once every five frames) is predefined by the network operator and hard-wired in the SS. Battery energy is conserved as the SS decodes data occasionally.

Note that from the perspective of the BS, the SS is treated just the same as if it were not in the sleep mode, with the exception that the BS does not transmit data to a sleeping SS without first ensuring that the SS has been waken up. The session parameters associated with a sleeping SS are retained.

The sleep period is not indefinite, but continues only for a finite number of frames, after which the SS wakes up by default if it has not already been waken up by a paging message sent from the BS, or by the arrival of data at the SS intended for transmission on the UL. This maximum sleep duration is also predetermined, fixed, and set by the network operator and assumed to be known to both BS and SS.

Message Exchanges to Wakeup a Sleeping SS
1. SS Wakes Up on Its Own
If the SS has any data to send on the UL to the BS, it simply wakes up by reviving all processes that were running before it entered the sleep mode, and then transmitting the data just as it would have if it had never entered the sleep mode. As the BS retained all session parameters when the SS first entered the sleep mode, the BS is ready to receive the data and does so. The arrival of this data from the SS alerts the BS to the fact that the "sleeping" SS has now woken up by its UL transmission. The BS then treats the SS as if it is no more in sleep mode.

2. BS Wakes Up the SS via a Paging Message
The BS wakes up a sleeping SS by transmitting a "paging" message during one of the periodic frames that is received and decoded by the SS. A specific "paging" message is not supported by the current 802.16-2004 standard. However, the standard permits network operators to use several UIUCs to define modulation and coding rates (burst profiles) for both the orthogonal frequency division multiplexing (OFDM) and OFDMA modes of operation. The network operator may therefore reserve one of these UIUCs for "paging." The steps involved in waking up a sleeping SS to receive DL data is given next.

In the UL-MAPs transmitted by the BS over a number of consecutive frames, the BS specifies the CID of the SS scheduled for wakeup, employing the UIUC designated for "paging" purposes with the most robust modulation and coding scheme available. The reason for this is that the SS is only receiving and decoding periodic frames during sleep mode. Further, as the sleeping SS does not transmit anything on the UL, the BS has no information about DL channel quality, and cannot tailor its coding scheme accordingly. Thus, if the DL channel suffers degradation, the SS may not receive the BS transmission, so robust modulation/coding with repetition maximizes the chance of the SS receiving the paging "message."

Upon receiving the UIUC information in the UL-MAP, the SS exits the sleep mode. To confirm with the BS that the SS has indeed exited the sleep mode, the SS transmits another bandwidth request message with 0 bytes in the BR field. The receipt of this message by the BS is interpreted by the BS as an acknowledgment by the SS that it has now "woken up" and resumed normal operation.
Related Posts with Thumbnails