IEEE 802.16e standard defined the required procedures and functions that should be implemented at the physical and MAC layers to perform handoff. The mobile WiMAX version inherits from the IEEE 802.16e standard, but it also defines the protocols that should be implemented at the higher layers to support intra-/inter-ASN handoff, roaming, seamless handoff, and micro-/macro-mobility.
As described earlier, an ASN includes at least one ASN GW responsible for communicating with the CSN and a BS managing the connections to the MSs in its coverage. An ASN GW may be associated with one or more BSs while a BS can be managed by one or more ASN GWs so that multiple vendors can simultaneously interoperate within the same ASN. The BS may be a serving BS or a target BS depending on its task during the handoff process. In fact, the serving BS is the BS related to the MS before handoff while the target BS is the BS associated with the MS after handoff. On the other hand, we distinguish the serving ASN GW, the target ASN GW, and the anchor ASN GW. The serving ASN GW is the ASN GW corresponding to the serving BS; the target ASN GW is the ASN GW connected to the target BS while the anchor ASN GW is the ASN GW receiving the CSN data addressed to the MS and relaying them to the serving ASN GW. Thanks to the anchoring ASN GW, the MSs mobility is transparent to the CSN that does not need to know which ASN GW is managing the BS that is serving the MS. Therefore, the anchoring function prevents the CSN from frequently changing IP addresses. If the serving ASN GW is directly receiving data from the CSN, it is also considered as the anchor ASN GW. Nevertheless, the anchor ASN GW does not need to be a serving ASN GW or a target ASN GW. The intra-ASN handoff is processed between BSs within the same ASN; it does not induce important delay and minimizes data loss. Besides, intra-ASN handoff does not result in a change of the MSs IP address because the mobility is transparent to the outside of the ASN. Contrarily, an inter-ASN handoff is processed between BSs belonging to different ASNs and involves ASN GWs associated with separate ASNs. These ASN GWs need to coordinate their actions by adopting either anchoring or reanchoring to make the handoff smooth to the MS.
The ASN-anchored mobility management is defined as mobility of an MS not involving a change in the CoA; it applies to mobility in networks not based on MIP. The specifications identify three functions responsible for the handoff, the MS context, and the data delivery control. More specifically, the Handoff function, which is implemented on the serving, the relaying, and the target peers, manages the signaling messages exchange and takes decisions associated with the handover. Figure 1 illustrates a possible handoff scenario. First, the serving-handoff function sends a handoff request (HO_Req) and waits for the corresponding reply. That HO_Req should include at least the MS_ID identifying the MS that requests the handoff, the list of the candidate target BS identifiers (IDs), possibly the MS/Session information content, and the first requested bicast SDU sequence number. The relaying handoff function relays the HO_Req to multiple target handoff functions, which are in charge of analyzing the request, formulating, and sending the correspondent handoff responses (HO_Rsp). The HO_Rsp primitive includes at least the MS_ID and the list of the recommended target BS IDs; it may also carry other optional information. The received responses are forwarded by the handoff-relaying function to the serving-handoff function. The latter should send back a handoff confirmation (HO_Cnf) to the chosen target stating the final handoff action that may either be an initiation, a cancellation, or a handoff rejection. The HO_Cnf should at least indicate the MS_ID, the DL ARQ synchronization information per service flow describing the context necessary to restore communication from the point it has been interrupted and the UL ARQ synchronization information per service flow describing the context necessary to restore communication from the point it has been interrupted.
On the other hand, the context function manages the MS context and related information while handling their exchange in the backbone to set up any state or retrieve any state in network elements. For instance, the MSs context in the context function associated with the serving/anchor handoff function needs to be updated. More specifically, the MSs context in the context function associated with the serving handoff-function will be transferred to the context function associated with the target handoff function. Context information transfer may be triggered to populate a new MSs security context at a target BS, inform the network of an MSs initial network entry, or inform the network of the MSs idle mode behavior. The specifications identify relaying context functions, context functions acting as context servers, and context functions acting as context clients. The relaying context function mediates information delivery between context-client and context-server functions. The context-server function stores the most updated session context information for the MS while the context-client function, which is associated with the functional entity having the 802.16 physical link, retrieves session context information stored at the context-server level during handoff processes.
Finally, the data path (DP) function, also referred to as the bearer function, establishes the routes and manages the current data packets transmission between two functional entities. More specifically, the DP function controls the setup of the bearer plane between two BSs, two gateways, or a gateway and a BS; it may implement the setup of tunnels and support multicast and broadcast. The specifications distinguish four DP functions with respect to their roles in the handoff process. First, the anchor DP function anchors the data path associated with the MS across handoffs by forwarding the received data packets toward the serving DP function; it may buffer some of the packets and maintain some state information regarding bearer for the MS during handoffs. Second, the serving DP function is implemented at the end of the DP and associated with the serving PHY(physical)/MAC function (e.g., the serving BS) to handle the transmission of all data packets destined to the MS. Third, the target DP function is associated with a target BS that has been selected as the target of the handoff; it communicates with the anchor DP function to establish the DP that will replace the current path after the termination of the handoff. If the handoff succeeds, the target DP function becomes the serving DP function. Fourth, the relaying DP function mediates message exchange between serving, target, and anchor DP functions.
No comments:
Post a Comment