Use of Existing Message to Request and ACK Handoff

As mentioned earlier, the HO-REQ and HO-ACK messages have not been defined in the 802.16-2004 standard and defining the new messages in the standard is not our goal either. To avoid a change to the standard, we observe that it is possible to reuse an existing message, namely the Deregistration Command (DREG-CMD) with action code of 03, to serve the place of the HO-REQ and HO-ACK messages. That is, when the SS initiates the handoff, it sends a DREG-CMD (code = 03) message to its BS. If the BS agrees to the handoff, it returns another DREG-CMD (code = 03) to the SS. When the latter is received by the SS, it signifies that the handoff process is started.

We now explain why the DREG-CMD (code = 03) message can be applied as such. The standard specifies [5] that "the DREG-CMD message shall be transmitted by the BS on an SS's basic CID to force the SS to change its access state. Upon receiving a DREG-CMD, the SS shall take the action indicated by the action code." If the action code is 03, the "SS shall return to normal operation and may transmit on any of its active connections." First of all, BS does not expect to receive the DREG-CMD (code = 03) message from its SSs. If it is indeed received, how the BS would interpret the message has not been specified in the standard. Thus, it is acceptable if the BS chooses to interpret the message as a request for handoff (HOREQ). After the SS sends the first DREG-CMD (code = 03) message, the SS intends to begin a handoff, thus has a context to interpret the returned DREG-CMD from the BS as an ACK (HO-ACK).

The choice of the DREG-CMD (code = 03) message has an additional advantage. Namely, the message simply asks the SS to resume normal operations, thus it does not cause any adverse effects to the SS if it does not interpret the message in such a special way for supporting handoff. Furthermore, the message also enables correct operations for mixed SSs and BSs with or without the new handoff capability. For example, suppose that the SS has the handoff capability, but its BS does not. In this case, after receiving the first DREG-CMD (code = 03) from the SS, the BS will not send the second DREG-CMD (code = 03) to acknowledge (or approve) the handoff. Without the returned DREG-CMD, the SS simply continues its operations as defined in the original standard. In short, by initiating the handoff process from the SS, and by reusing the DREG-CMD (code = 03) message, we ensure that there are no problems arising from the misinterpretation of a message that arrives at an unexpected time due to a failure of synchronization, for example.

To prevent "ping-ponging" of an SS between an old and new BS, we propose the usual solution of a hysteresis threshold, such that a handoff will only be requested by the SS if the received signal strength from the new BS exceeds that from the old BS by at least this threshold. However, as the handoff scheme uses a "short" version of the initialization process, and in particular omits the authentication and key exchanges and request/grant of connection IDs (which are retained by the old BS and transmitted over the backhaul to the new BS), it is possible for the SS to abort the handoff at any stage before the MAC and PHY are reset at the old BS with BN-MSG4 in, simply by sending another DREG-CMD (code = 03) to the old BS.

With the protocol designed for supporting terminal mobility in the 802.16-2004 networks, mobile terminals now can no longer enjoy the "unlimited" supply of power as in the fixed wireless networks. In the following, we propose and study a mechanism to conserve battery energy for terminals in the 802.16-2004 networks.

Handoff Protocol and Message Exchanges

Figure 1 shows the sequence of message exchanges for connection handoff. We note that as a SS can stay silent (with no transmission) at times, its BS may not recognize the need of handoff when the SS moves away for the BS. So SS initiated handoff is more appropriate than that initiated by BS. When a SS realizes a need for handoff (e.g., by checking error rate for the MAPs periodically broadcast from BS on the DL or by measuring the received signal strength), it sends a handoff request (HO-REQ) to its current BS (denoted as the old BS). In turn, the BS returns with a handoff acknowledgment (HO-ACK) message to signify that the SS can start the handoff process. It is important to note that both HO-REQ and HO-ACK messages are not defined in the 802.16-2004 standard. We include them here mainly to illustrate the handoff protocol and discuss later how one can replace these messages by an existing one defined in the standard.

Figure 1: Handoff protocol. 

Soon after the old BS responds to the SS's request for handoff, the old BS sends the Backhaul Network message 1 (BN-MSG1) to inform the PFA, which is the "anchor" point for the SS, of the MAC address, CIDs, encryption keys, and other service parameters associated with the SS. Upon receiving the MSG1, the PFA forwards BN-MSG2 messages, which contain information about the SS's MAC address, connections, and operational parameters, via the backhaul network to alert all BS's surrounding the old BS, to look out for the possible handoff of the SS. This list of neighboring BSs, which are the likely candidates for handoff, is maintained at the PFA, and is analogous to the neighbor list in code division multiple access (CDMA) systems.

Following the reception of the HO-ACK message, the SS proceeds to execute the functionalities in Figure 1. That is, it scans and synchronizes with a new channel of a neighboring BS (denoted as the new BS in the diagram). Then, it obtains the UL transmission parameters, completes the ranging and adjustment procedure, registers and sets up provisional connections with the new BS. Once the "short initialization process" is completed, the new BS sends the BN-MSG3 to inform the PFA of the completion of the handoff. In turn, the PFA sends the BN-MSG4 to reset PHY and MAC associated with the SS on the old BS. As the new connections are established between the SS and the new BS, the PFA starts to tunnel data to the new BS for forwarding to the SS.

Before continuing, we note that there is a key delay requirement for the handoff protocol to work properly. That is, the BN-MSG2 sent from the PFA must be received and processed by all BSs surrounding the old BS before the first ranging (RNG-REQ) message from the SS arrives. This is so because without receiving the BN-MSG2 message, the neighboring BSs will not be aware of the handoff, and thus follow the rest of the steps for the normal initialization process, instead of those of the "short" process for handoff. (On the other hand, the SS knows that it has to follow the short process because it has been told to do so by receiving the HO-ACK message from the old BS.) As the scanning and synchronization with a new channel may take at least tens of milliseconds to complete, the delay requirement does not appear to be a stringent one. Rather, with a typical high-speed IP backhaul network, it is expected that the BN-MSG2 message can reach and be processed by the neighboring BSs within a couple of tens of milliseconds, which should be short in comparison with the delay incurred in channel scanning and synchronization.

Initialization Process | Protocols for Connection Handoff

As our objective is to support mobility without standard change, we have to use the features and protocols defined in the existing 802.16-2004 standard. We observe that in the most basic sense, handoff is to tear down the existing connection with the current BS and to set up a new connection with a neighboring BS with better link quality. Let us ignore the delay in setting up the new connection for a moment. The key functionalities for handoff are quite similar to the initialization process of a SS when registering with a BS upon power up. This is the starting point of our approach. Namely, we attempt to reuse some of the functionalities of the initialization process defined in the 802.16-2004 standard to assist connection handoff. Toward this goal, it is instructional to first review the initialization process. Then, we identify a set of required functionalities for connection handoff.

A schematic diagram of steps in the initialization process is given in Figure 1. In the first step of the process, an SS begins scanning its frequency list to identify an operating channel (or it may be programmed to log on with a specified BS). After deciding on the channel to attempt communication, the SS tries to synchronize to the downlink (DL) transmission by detecting the periodic frame preambles. Once the PHY layer is synchronized, the SS in step 2 looks for the periodically broadcast downlink channel descriptor (DCD) and uplink channel descriptor (UCD) messages, from which the SS learns the modulation and forward-error-control information for the chosen channel.

Figure 1: Initialization steps for 802.16-2004. (From K. K. Leung, S. Mukherjee, and G. E. Rittenhouse. Proc. 2005 IEEE Wireless Communications and Networking Conference, WCNC 2005. With permission.)

With the channel parameters known, the SS identifies a transmission opportunity from the uplink (UL) medium access protocol (MAP) to send ranging message(s) to the target BS. Based on the range-response message from the BS, the SS can adjust its transmission power and timing. Furthermore, the message also provides the SS with the basic and primary management connection identifiers (CIDs). After the ranging process is completed, the SS and BS exchange two messages to inform each other of their capabilities.

The next step is for the SS to go through the authentication procedure and exchange of encryption keys with the BS. The step involves several messages exchanged between the SS and BS. It starts with the SS sending its X.502 digital certificate (MAC address and SS public key), cryptographic algorithm, and basic CID to the BS. At the end of the step, both the SS and BS agree upon the authorization and traffic-encryption keys and their associated lifetimes.

In the registration step, the SS sends the BS a request message to register with the network. The BS returns a response message to indicate success or failure of the registration and, if successful, a secondary management CID. Then, the SS acquires an IP address and related parameters via dynamic host communication protocol (DHCP). In the next step, the SS sends a request for time and receives a response from a timeserver. The DHCP server also provides the address of the Trivial File Transfer Protocol (TFTP) server from which the SS can obtain a configuration file containing operational parameters. As a final step, connections are set up for service flows between the SS and BS. There are alternative ways to set up the connections. One way is for the BS to send a dynamic service addition (DSA) message to the SS. The request message contains service flow IDs, possibly CIDs and their QoS parameters. The connection setup is completed after the SS returns a DSA response to the BS and the BS sends an acknowledgment.

Handoff Objective and Mobility Management | Protocols for Connection Handoff

As the quality of an established radio link between a Subscriber Station (SS) (or terminal) and its BS deteriorates due to mobility, the objective of handing off the connection to a neighboring BS is to maintain the Internet Protocol (IP) connectivity between the SS and the corresponding host. A major goal is to minimize packet loss and delay induced by the handoff process. As the 802.16-2004 standard defines only the PHY and MAC layers, without loss of generality, suppose that the network under study employs the Hierarchical Mobile IP (HMIP) algorithm for micromobility management. Using the common terminology for mobile networks, Figure 1 shows the architecture of the HMIP for the 802.16 network under consideration. Specifically, one router is designated the Primary Foreign Agent (PFA) and serves as the "anchor point" for each SS (or connection). That is, data from and to a given SS always goes through the corresponding PFA. In addition, the PFA also keeps track of the operational parameters for the 802.16-2004 connections associated with the SS. As shown in the figure, the communication path consists of multiple IP tunnels and packets are forwarded by tunneling.

Figure 1: Hierarchical mobile Internet Protocol for 802.16-2004 network.