IEEE C802.16m-
Project
IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16>
Title
Proposal for IEEE 802.16m Synchronous Messaging for Mobility
Management and Power Saving
Date
Submitted
June 30, 2008
Source(s)
Susan Hartman Susan.Hartman@intel.com Intel Corporation
Call for Contributions on Project 802.16m System Description Document (SDD)
Re:
IEEE 802.16m Mobility Management and Power Saving
Abstract
Proposal for IEEE 802.16m Synchronous Messaging for Mobility Management and Power
Saving
Purpose
Discussion and Approval
Notice
Release
Patent
Policy
This document does not represent the agreed views of the IEEE 802.16 Working Group or any
of its subgroups. It represents only the views of the participants listed in the “Source(s)” field
above. It is offered as a basis for discussion. It is not binding on the contributor(s), who
reserve(s) the right to add, amend or withdraw material contained herein.
The contributor grants a free, irrevocable license to the IEEE to incorporate material contained
in this contribution, and any modifications thereof, in the creation of an IEEE Standards
publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may
include portions of this contribution; and at the IEEE’s sole discretion to permit others to
reproduce in whole or in part the resulting IEEE Standards publication. The contributor also
acknowledges and accepts that this contribution may be made public by IEEE 802.16.
The contributor is familiar with the IEEE-SA Patent Policy and Procedures:
<http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and
<http://standards.ieee.org/guides/opman/sect6.html#6.3>.
Further information is located at <http://standards.ieee.org/board/pat/pat-material.html> and
<http://standards.ieee.org/board/pat>.
1
Proposal for IEEE 802.16m Synchronous Messaging for Mobility
Management and Power Saving
Susan Hartman
1. Introduction and Motivation
Handover, Scanning, and Sleep Mode require synchronization between the MS and BS
as to the Start Frame for the action. Current management command exchanges can be
improved to enable the Start Frame to be synchronized more efficiently.
2. Example: Issues with 802.16e Power Saving Class Activation
MS may request Power Saving Class (PSC) activation by sending the MOB_SLP-REQ
message to the BS. The MS can suggest a Start Frame, but it is better if the BS
specifies the Start Frame so there is less uncertainty in guessing a good value for the
Start Frame.
MS has a timer (T43) to retry the MOB_SLP-REQ message however BS does not have
a timer for MOB_SLP-RSP retries for BS-initiated PSC activation. It seems that BS
does not retry the MOB_SLP-RSP if the MS does not receive it. (Please refer to figures
B8, B9, and B10 in [3]).
MS/BS synchronization is aided with the use of the MOB_TRF-IND message (TRFIND_Required = 1). MOB_TRF-IND has three uses:
 Notify MS of traffic so MS deactivates PSC
 Update SLPID
 Help verify synchronization between MS and BS
MOB_TRF-IND message for synchronization contributes to overhead and it is a weak
synchronization mechanism since there may be many MSs in Sleep Mode, so the
MOB_TRF-IND message received by an MS in its Listening Window may not be meant
to indicate synchronization for that MS.
For effective power saving, PSC activation and switching must be very quick. The MS
can lose significant power saving during messaging delays.
Suppose BS anticipates that MS will send MOB_SLP-REQ message. BS may provide
bandwidth for this message with or without HARQ. MS is responsible for retries if it
does not receive MOB_SLP-RSP. On the other hand, when bandwidth with HARQ is
used for either the MOB_SLP-REQ or MOB_SLP-RSP, there is uncertainty about when
the retries will be completed (if any). Since with HARQ the message cannot be
changed after it is sent, the Start Frame has to take into account the frames required for
HARQ retries. During the gap between MS receiving MOB_SLP-RSP and the Start
Frame, MS is not in a power save mode.
2
3. Synchronous Messaging for MS/BS Synchronization
This contribution proposes use of a synchronous method of messaging for PSC
activations. With this synchronous method, synchronization is assured so that TRFIND_Required is not needed for this purpose and the latency of activation is very small.
The same synchronous messaging can be used for negotiating scanning, handover,
and other 802.16m messaging. Figure 1 shows an example of synchronous messaging.
As seen in Figure 1, there is a fixed relationship between CMD and RSP (it is shown as
FN+1 in this example, but it could be FN (same frame) or other). The Hold-Off Time is
an interval (in this example shown as one frame) that provides the BS with a means to
re-send CMD before MS starts the synchronized action. Hold-Off Time can be one or
more frames.
CMD
BS
RSP
MS
BW
Hold-Off
Time
Not synchronized
Synchronized
Synchronized Signaling
Figure 1 Synchronous Messaging
shows an example with errors and retries. As seen, when BS does not receive
RSP from MS, the CMD is sent again. If the RSP is not received by the BS, the BS
cannot distinguish from the MS missing the CMD or the BS missing the MS.
Figure 2
BS
CMD
CMD
CMD
RSP
MS
BW
BW
RSP
BW
Hold-Off
Time
Not synchronized
Synchronized
Synchronized Signaling
Figure 2 Synchronous Messaging with Retries
3
4. MS-Initiated Synchronous Messaging
Figure 3 shows MS-initiated synchronous messaging. The MS makes the request and
then the BS actions are the same as for the BS-initiated case since the BS may change
the MS request (the BS usually has permission to alter the MS requests). The MS must
retry if it does not receive the BS CMD within the specified interval (likely no more than
a few frames).
CMD
CDMA
BW
REQ
RSP
Hold-Off
Time
BW
Not synchronized
Synchronized
Synchronized Signaling
Figure 3 MS-Initiated Synchronous Messaging
shows a variant of MS-initiated quick synchronous messaging. In this scenario,
the MS is requesting an action that the BS does not alter. The Sync messages are
multicast and repeated on purpose to give extra chances for the MS to receive the
Sync. With this method, if MS does not receive response (Sync) from BS, MS has
another chance to receive it without needing to perform a CDMA bandwidth request and
then send another action request.
Figure 4
Sync
CDMA
BW
REQ
Sync
Sync
Not synchronized
Synchronized
Synchronization reference frame
Synchronized Signaling
Figure 4 MS-Initiated Quick Synchronous Messaging
4
Figure 5
shows an example of MS-initiated quick synchronous messaging with errors and
retries.
Sync
CDMA
BW
Sync
REQ
Sync
Sync
CDMA
BW
REQ
Sync
Sync
Not synchronized
Synchronized
Synchronization reference frame
Synchronized Signaling
Figure 5 MS-Initiated Quick Synchronous Messaging with Retries
5. Conclusions and Recommendations
We would like to recommend that 802.16m incorporate the above described
synchronous messaging into the 802.16m specification.
6.
Proposed Text for SDD
Insert the following text into Medium Access Control sub-layer sub-clause (i.e.
Chapter 10 in [3]):
------------------------------- Text Start ---------------------------------------------------
10 Medium Access Control Sub-Layer
10.x Synchronized Messaging
IEEE 802.16m supports synchronous messaging for selected message exchanges to
provide efficient synchronization between MS and BS.
------------------------------- Text End ---------------------------------------------------
7.
References
[1] IEEE Std. 802.16e-2005, IEEE Standard for Local and metropolitan area networks,
Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems,
Amendment 2: Physical and Medium Access Control Layers for Combined Fixed and
Mobile Operation in Licensed Bands, and P802.16Rev2/D3 (February 2008).
[2] WiMAX Forum™ Mobile System Profile, Release 1.0 Approved Specification
(Revision 1.4.0: 2007-05-02), http://www.wimaxforum.org/technology/documents.
[3] IEEE 802.16m-08/003r1, “The Draft IEEE 802.16m System Description Document”
5