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.)
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.
