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. 

PKM Version 2: Multicast and Broadcast

1 Multicast and Broadcast Services Support

PKMv2 supports strong protection from theft of multicast and broadcast service by encrypting MBS defined in the IEEE 802.16e amendment.

MBS requires a MBS GSA. It is the set of security information that multiple BS and one or more of its client SSs share but not bound to any MS authorization state to support secure and access-controlled MBS content reception across the IEEE 802.16 network. Each MBS capable of MS may establish a MBS SA during the MS initialization process. MBS GSAs shall be provisioned within the BS. A MBS GSA's shared information includes the cryptographic suite employed within the GSA and key material information such as MAKs and MGTEKs. The exact content of the Marin General Services Authority (MGSA) is dependent on the MGSA's cryptographic suite. As like any other unicast SAs, MBS GSA is also identified using 16-bit SAIDs. Each MS shall establish one or more MBS GSA with its serving BS. Using the PKMv2 protocol, an MS receives or establishes an MBS GSA's keying material. The BS and MBS content server must ensure that each client MS only has access to the MGSAs it is authorized to access. An SA's keying material (e.g., MAK and MGTEK) has a limited lifetime. When the MBS content server or BS delivers MBS SA keying material to an MS, it also provides the MS with that material's remaining lifetime. It is the responsibility of the MS to request new keying material from the MBS server or BS before the set of keying material that the MS currently holds expires at the MBS server or BS.

2 Optional Multicast Broadcast Rekeying Algorithm

When the Multicast Broadcast Rekeying Algorithm (MBRA) is supported, the MBRA is used to refresh traffic keying material efficiently not for the unicast service, but for the multicast or the broadcast service.

Note that an SS may get the traffic keying material before an SS is served with the specific multicast service or the broadcast service. The initial GTEK request exchange procedure is executed by using the key request and key reply messages that are carried on the primary management connection. The GTEK is the TEK for multicast or broadcast service. Once an SS shares the traffic keying material with a BS, the SS does not need to request new traffic keying material. A BS updates and distributes the traffic keying material periodically by sending two key update command messages.

A BS manages the M&B (Multicast & Broadcast) TEK grace time for the respective GSA-ID in itself. The GSA-ID is the SA-ID for multicast or broadcast service. This M&B TEK grace time is defined only for the multicast service or the broadcast service. This parameter means time interval (in seconds), before the estimated expiration of an old distributed GTEK. In addition, the M&B TEK grace time is longer than the TEK grace time managed in an SS.

A BS distributes updated traffic keying material by sending two key update command messages before old distributed GTEK is expired. The usage type of these messages is distinguished according to the key push modes included in the key update command message. The purpose of the key update command message for the GKEK update mode is to distribute the GKEK. The key update command message for the GKEK update mode is carried on the primary management connection. A BS intermittently transmits the key update command message for the GKEK update mode to each SS to reduce the BS's load in refreshing traffic key material. The GKEK is needed to encrypt the new GTEK. The GKEK may be randomly generated in a BS or an ASA server.

A BS transmits the PKMv2 group key update command message for the GTEK update mode carried on the broadcast connection after the M&B TEK grace time starts. The aim of the key update command message for the GTEK update mode is to distribute new GTEK and the other traffic keying material to all SSs served with the specific multicast service or the broadcast service. This GTEK is encrypted with already transmitted GKEK.

An SS shall be capable of maintaining two successive sets of traffic keying material per authorized GSA-ID. Through operation of its GTEK state machines, an SS shall check whether it receives new traffic keying material or not. If an SS gets new traffic keying material, then its TEK grace time is not operated. However, if it does not have that, then an SS shall request a new set of traffic keying material a configurable amount of time, the TEK grace time, before the SS's latest GTEK is scheduled to expire.

If an SS receives two valid key update command messages and shares new valid GKEK and GTEK with a BS, then that SS does not need to request a new set of traffic keying material.

If an SS does not receive at least one of the two key update command messages, then that SS sends the key request message to get a new traffic keying material. A BS responds to the key request message with the key reply message. In other words, if an SS does not get valid new GKEK or GTEK, then the GTEK request exchange procedure initiated by an SS is executed.

An SS tries to get the GTEK before an SS is served with the specific service. The initial GTEK request exchange procedure is executed by using the key request and key reply messages that are carried on the primary management connection.

A BS must be capable of maintaining two successive sets of traffic keying material per authorized GSA-ID. That is, when GKEK has been changed a BS manages the M&B TEK grace time for the respective GSA-ID in itself. Through operation of its M&B TEK grace time, a BS shall push a new set of traffic keying material. This M&B TEK grace time is defined only for the multicast service or the broadcast service in a BS. This parameter means time interval (in seconds) before the estimated expiration of an old distributed GTEK. That is, the M&B TEK grace time is longer than the TEK grace time managed in an SS.

A BS distributes updated GTEK by using two key update command messages when the GKEK has been changed, or by using one (the second) key update command message otherwise, around the M&B TEK grace time, before the already distributed GTEK expires. Those messages are distinguished according to a parameter included in that message, "key push modes." A BS transmits the first key update command message to each SS served with the specific service before the M&B TEK grace time. The first key update command message is carried on the primary management connection. A BS intermittently transmits the first key update command message to each SS to reduce the BS's load for key refreshment. The purpose of the first key update command message is to distribute the GKEK. This GKEK is needed to encrypt the updated GTEK. The GKEK is also encrypted with the SS's KEK. The GKEK may be randomly generated in a BS or an ASA server.

A BS transmits the PKMv2 group key update command message carried on the broadcast connection after the M&B TEK grace time. The aim of the second key update command message is to distribute the GTEK to the specific service group. This GTEK is encrypted with transmitted GKEK before the M&B TEK grace time.

An SS must also be capable of maintaining two successive sets of traffic keying material per authorized GSA-ID. Through operation of its GTEK state machines, an SS checks whether it receives new traffic keying material or not. If an SS gets new traffic keying material, then its TEK grace time is not operated. However, if it does not have that, then the SS requests a new set of traffic keying material for the TEK grace time before the SS's latest GTEK is scheduled to expire.