HANDOFF WITH UMTS AND WIFI

Mobile WiMAX intends to combine the advantages of both WiFi networks and third generation networks such as UMTS while intercommunicating with both.

1 Handoff with UMTS

If we carefully examine the reference models of both WiMAX and UMTS networks, we will notice that they share many similarities. For instance, the WiMAX ASN may be directly mapped to the UMTS terrestrial radio access network (UTRAN) while the CSN may be mapped to the UMTS core network as their functionalities are distributed in the same fashion. 

Moreover, the QoS classes of service provided by both technologies enable a direct transfer of traffic flows from one network to another. In fact, the UMTS conversational class may be mapped to the UGSs class, the UMTS streaming class to the nrtPS, the UMTS interactive service class to the (extended) rtPS, and the UMTS background class to the BE class. Regarding security, both UMTS and WiMAX networks support mutual authentication and provide integrity, replay protection, confidentiality, and nonrepudiation guarantees. Nevertheless, moving from WiMAX to UMTS will induce degradation in the provided data rates. Network planning authorities may choose between deploying loose or tight coupling between WiMAX and UMTS networks depending on the degree of integration of both networks. 

When loose coupling is implemented, access to the 3G AAA services is guaranteed by the packet data gateway (PDG) edge routers connected to the WiMAX network or routed through the Internet. PDG routers provide a tunnel termination gateway (TTG) between the WiMAX network and the mobile core network while providing charging gateway interfaces, IP address allocation, authentication in external networks, and single access to mobile core network packet data domain services. 

Meanwhile, WiMAX and UMTS traffics are separated so that WiMAX providers can implement their own mobility, authentication, and billing mechanisms while signing roaming agreements with 3G providers. 3G providers will benefit from extending the coverage of their networks while reducing the deployment costs and serving rural or inaccessible areas. However, loose coupling requires the implementation of higher level mobility management protocols that need to be media independent; thus adding complexity and latency when roaming between different access networks. To address this issue, each network should share its admission control and resource management information with the neighboring networks.

When tight coupling is implemented, WiMAX and UMTS networks will use the same core network components including gateways, AAA entities, and infrastructure. More specifically, the WiMAX network will be connected to the UMTS gateway GPRS support node (GGSN) and the packet-switching domain of the UMTS core network. The UMTS considers the WiMAX network as a radio network controller (RNC); therefore, mobile terminals need to implement the UMTS protocol stacks. Compared to loose coupling, tight coupling facilitates the management procedures as the same billing and authentication, and mobility protocols can be used for both networks. Besides, vertical handoff may be easily initialized and optimized as the core network possesses a clear view of resource status in both networks. However, introducing WiMAX traffic into the UMTS network should be preceded by adapting some core network entities to handle new types of load and traffic patterns to avoid capacity conflicts. Last but not least, the tight-coupling approach is less flexible in coverage extensions than loose coupling; consequently, it is generally practical to adopt it when WiAMX and UMTS networks are owned by the same operator and the integration is implemented by means of adding patches to the existing components.

2 Handoff with WiFi

IEEE 802.11e standard aims at providing QoS guarantees at the LAN scale by specifying differentiations mechanisms at the WiFi MAC layer. However, WiFi networks-limited coverage prevents them from providing continuous Internet-related services and real-time applications support anywhere and at any time. On the other hand, IEEE 802.16e, from which inherits mobile WiMAX, faces some problems related with energy saving and quality providing in some indoor areas. Consequently, integrating WiMAX and WiFi is a hot topic that is currently attracting an increasing number of researchers. A multilayer network protocol architecture that aims at addressing QoS and mobility issues for integrating WiFi and WiMAX. In fact, they designed a two-tier network that considers a 802.16e cell as overlay cell that overlays a few WiFi cells and 802.11e cells as underlay cell cluster. When the MS stills under the coverage of WiFi cells, handoff will be performed horizontally as WiFi can provide high bandwidth and good performance. The AP, which offers the highest bandwidth value and reduces the unnecessary handover probability due to signal strength dropping down, will be selected as target AP. Analyze multiple parameters in a cross-layer fashion to optimize the handoff decision. Examples of such parameters, which are adopted during the simulation, include residential time, WiMAX-cell capacity, and blocking and dropping probability.

The proposed network stack supports three IEEE 802.11 physical layers which are 802.11b, 802.11g, and 802.11n, providing data rates of 11, 54, and 250 Mbps. The network stack also includes IEEE 802.16 and IEEE 802.16e physical and MAC layers. A handover layer based on the IEEE 802.21 standard lies between the lower layers and the network layer implementing the Fast Mobile IPv6 protocol. Management entities are present at each layer and implement all the required provisioning, maintenance, operation, and administration functions. They are also in charge of communicating with servers processing the QoS policies, the mobility decisions, and the profiles storage. To define unified layer 2 abstractions in the IEEE 802.21 to support layer 3 fast handoff. Moreover, WiFi/WiMAX and Fast Mobile IP interaction is achieved by the IEEE 802.21 primitives. They also base the handoff decision on the analysis of different link parameters such as signal strength, velocity of MNs, delay, service level prediction, etc. For instance, the target cell selection is speed sensitive, which means that the MNs are directed to the appropriate cell layer according to their velocity to decrease the blocking and dropping probabilities. A handoff protection mechanism consisting in reserving two free guard channels for handoff usage in advance to minimize the dropping of handoff calls. The proposed mobility management scheme depends on three types of arrival hosts in the WiFi cell.

 If a filtered MN arrives in the WiFi cell from neighboring WiMAX cells and overlaid WiMAX cell, the scheme does not change its state. However, if a nonfiltered MN arrives in the WiFi cell from overlaid WiMAX cell and initial session itself, and if the residential time is longer than the residential time threshold and the WiMAX cell has enough capacity, then it will be overflowed to the WiMAX cell to reduce the handoff probability. Otherwise, it will be assigned to the WiFi cell. Overflow thresholds to reduce the dropping of a handoff call and the blocking of a new call. When a nonfiltered MN arrives in the WiFi cell and the blocking and dropping probabilities of the WiMAX cell are less than the overflow threshold, it will be overflowed into the WiMAX cell. Otherwise, it will be assigned to the WiFi cell.

MEASUREMENTS FOR HANDOFF OPTIMIZATION

Handoff optimization is a key challenge for the network management as it results in the enhancement of the network performances by optimizing throughput, routing, delay profiles, delivered QoS, and communication costs. Therefore, mobile WiMAX should take into consideration numerous parameters that implement a particular handoff policy to optimize the handoff performance, especially in case of interaction with heterogeneous networking technologies. It is valuable to note that IEEE 802.16e specifications consider the handover decision algorithms beyond the scope of the standard.

1 Monitoring Parameters

Radio resource management (RRM) specifications should guarantee efficient resource utilization in WiMAX networks by assisting functions such as QoS provision, service flow admission control, and mobility management. RRM mechanisms shall be implemented in ASNs either with BSs that directly communicate between them or with BSs having no direct communication between them or at a centralized RRM entity that does not reside in a BS but that collects and monitors radio resource indicators from several BSs. Each BS should collect data about the neighboring BSs either through static configuration data or through a different RRM entity aware of the dynamic load of neighboring BSs. RRM mechanisms should support network functions in taking the required decisions. For instance, RRM may assist handoff preparation and control to improve the overall performances. 

For example, RRM mechanisms may optimize the system load control by selecting the most suitable target BS during handoff or updating the list of recommended BSs to handoff. The radio resources available at a BS where a BS-ID defines a sector with a single frequency assignment may be a good hint for BS selection during network entry or handoff. More specifically, the available radio resource indicator, which gives the percentage of reported average available subchannels and symbols resources perframe, may be used to select recommended target BSs that achieve approximately equal load. Averaging is calculated over a configurable time interval with a default value of 200 frames [8]. Choosing the more suitable BS as a target BS is done through scanning and association activities. The criteria that enlighten the choice may include the link quality in the UL direction. Such handoff monitoring parameters are measured by the MSs and then sent in a form of report to the managed BS, which may deliver them to the radio resource controller (RRC). The RRC, which is generally implemented at the ASN GW or at a BS, controls multiple radio resource agents (RRAs) located at the BS level. RRAs maintain a database of collected radio resource indicators received by the managed MSs or by the respective BSs. In fact, IEEE 802.16d amendments define the receive signal strength indicator (RSSI) and the CINR as two main signal quality indicators that help in assigning BSs and selecting adaptive burst profiles. The specifications also define the mean and the standard deviation because the channel behavior varies in time. These indicators enable the channel quality monitoring and may be augmented to include measurements related to QoS parameters such as the burst error rate. 

It is valuable to note that the RSSI measurements do not require receiver demodulation lock; therefore, they provide reliable channel-strength estimation even at low signal levels. Each BS has to collect the RSSI measurements while each MS shall obtain an RSSI measurement in an implementation-specific fashion. After performing successive RSSI measurements, the MS should derive and update estimates of the mean and the standard deviation of the RSSI and then report them in units of dBm via a REP-RSP message. To obtain such a report, statistics are quantized in 1 dB increments ranging from−40 to −123 dBm while the values outside that range are assigned the closest extreme value within the scale. IEEE 802.16d specifications do not impose how to estimate the RSSI of a single message, but they claim the relative accuracy of a single-signal-strength measurement taken from a single message to be 2 dB with an absolute accuracy of 4 dB. 

Each BS has to collect the CINR measurements while each MS shall obtain a CINR measurement in an implementation-specific fashion. After performing successive CINR measurements, the MS should derive and update estimates of the mean and the standard deviation of the CINR and then report them in units of dB REP-RSP messages. IEEE 802.16d specifications do not impose how to estimate the CINR of a single message, but they claim the relative accuracy of a single signal strength measurement taken from a single message to be 1 dB with an absolute accuracy of 2 dB.

2 Optimization Functions

The handoff process should not decrease the overall performance; therefore, it should implement mechanisms that optimize the delay to support real-time applications such as VoIP and video streaming. Connection dropping should also be reduced. IEEE 802.16e and mobile WiMAX specifications define prescan mechanism to measure the radio connection and select the target BS before handoff execution. Nevertheless, the handoff procedure should include not only layer 2 handoff but also the IP layer handoff for IP-based services. 

Figure 1 below shows that layer 3 handoff, which includes movement detection, IP configuration, and location registration subphases, highly affects the overall handoff delay and requires much more time to be executed than layer 2 handoff. Optimizing such delay is a hot research issue. For instance, the fast handoff procedure proposed proposes to process the configuration of CoA, duplicated address detection (DAD), etc. in advance to reduce the handoff latancy. However, the mobile IP procedure always begins after ending layer two handoff so that the handoff delay is the summation of the layer 2 handoff delay and layer 3 handoff delay. Consequently, it is imperative to consider the correlation between layer 2 and layer 3 within a cross-layer scheme. Analyzed the signaling message flow sequence and the format of both IEEE 802.16e and fast MIPv6 to correlate both handoff procedures and minimize the required signaling overhead. For instance, propose to integrate some layer 3 handoff information with the MOB_HO_IND message and the RNG_REQ as they share semantic characteristics while performing the handoff.

 

Figure 1: The handoff process for IP based services.

Regarding QoS, mobile WiMAX specifications define different classes of services having different requirements in the quality of the traffic delivered to MSs. This quality is generally measured in terms of data integrity, latency, and jitter. The handoff process should be optimized to not highly affect these parameters. For instance, maintaining data integrity during handoff means that the packet loss, duplication, or reordering rates will not be considerably increased while the impact on the DP setup latency/jitter should be minimized. From the QoS point of view, there are controlled handoffs and uncontrolled handoffs. A controlled handoff should respect the following conditions:

• If the handoff is initiated by the MS, the latter should send to its serving BS a list of potential targets.
• Network should base its target selection on the list of potential targets provided by the MS.
• Network should inform the MS with the list of available targets for handoff. If that list is empty, the network will refuse to accept MS handoff. The available targets list should be a subset of the one requested by the MS or reported by it.
• MS should process handoff by moving to one of the provided targets or it should cancel the handoff. The decision is sent via the MOB_HO-IND message.

When any of these conditions is not respected, the handoff is considered uncontrolled and does not provide any QoS guarantees. In the worst case, the MS can connect to the target BS without any indications given to that target BS inducing an unpredictive handoff. To provide data integrity and optimize the handoff process, several mechanisms are provided and classified into two main groups: DP setup mechanisms and DP synchronization mechanisms. DP setup mechanisms refer mainly to buffering and bi-multicasting. Buffering consists in saving the traffic of the services for which data integrity is required at the DP originator or the DP terminator level. 

Nevertheless, the buffering point may change during handoff based on the data integrity mechanism selection. Moreover, buffering may be done only during handoff or for simplicity within the lifetime of a session. On the other hand, multicasting refers to multicasting downstream traffic at the originator endpoint of the DP while bicasting consists in bicasting traffic to the serving element and to only one target. It is worth noticing that bicasting achieves better performances when it is combined with buffering. DP synchronization mechanisms aim at guaranteeing data delivery in different data functions, which buffered the different DPs (serving and target) used to deliver the data during handoff. It is achieved by using either sequence numbers, data retrieving, or Ack window with sequence number disablement. 

A sequence number is attached to each SDU in the ASN DP and then incremented by one every time it is forwarded in the DP. Data retrieving does not require the definition of sequence numbers; the anchor DP function buffers or copies the data during handoff preparation, and when a final target BS is identified, the serving BS will push back all the nonsent packets to anchor/target DF. When Ack window with sequence number disablement is implemented, data storage buffers in anchor DP are released by full or partial ACKs from the serving BS without requiring sequence numbers. Vertical handoff between mobile WiMAX and other wireless networks represents a hot research topic as it requires the implementation of optimization algorithms that are able to decide when to initiate handoff and which access network to choose while minimizing the handoff latency and preserving the security context and the required QoS. 

CELL SELECTION

Cell selection/resection enables a correct network topology acquisition and guides the handover process in selecting the best target BS.

1:  Neighbor Advertisement from Serving Base Station

Each BS in the network should broadcast information describing the network topology via MOB_NBR-ADV messages. As stated earlier, these messages carry channel information for neighboring BSs normally provided by each BS’s own DCD/UCD messages. The serving BS may obtain such neighbors-related information over the backbone before broadcasting it to the managed MSs. Thanks to MOB_NBR-ADV messages, MSs are able to synchronize with the neighboring BSs without being obliged to monitor transmission for individual DCD/UCD broadcasts. The standard specifications fix the maximum period of sending the MOB_NBR-ADV message to 1 s so that an MS moving at high speed through the coverage area of each BS may get the message and perform handoff. It is valuable to note that the period of sending the MOB_NBR-ADV message determines the maximum speed, with which an MS is allowed to move through the network; therefore, it must be carefully chosen. Optimizing the handoff process requires a selection of the most suitable target BS that fits mobility path and application needs. To achieve that goal, MSs have to scan multiple channels to discover neighboring BSs and then select the best target. That selection may be based on different parameters such as the measured signal strength, the packet delay, the error ratio, the throughput, and the security level . Cell reselection is achieved when the MS scans and/or associates with more than one BS to evaluate their suitability as handover target. The MS may integrate information obtained from a MOB_NBR_ADV message to give insight into available neighboring BSs for cell reselection. Note that the serving BS may allocate scanning intervals or sleep intervals for the cell reselection activity. However, such activity does not require terminating the ongoing connection with the serving BS.

2:  Periodic Intervals for Scanning Neighbor

Usually, the serving BS allocates time intervals known as scanning intervals to the MSs. Unfortunately, channel scanning can be a relatively time-consuming activity; therefore, MSs should process it and obtain the neighboring BSs list before performing handoff. The duration and frequency of scanning should be carefully determined to interleave scanning period and normal operations without affecting the network performances and the provided QoS. It is clear that a long scanning period increases the packets jitter and the end-to-end delay while imposing large buffer sizes. 

Contrarily, a short scanning period requires multiple iterations and increases the overall scanning duration. The scanning procedure depicted in Figure 1 begins when an MS sends a MOB-SCN_REQ message to its serving BS to request the allocation of a group of scanning intervals while indicating the estimated duration of time required for the scan. The serving BS replies by a MOB-SCN_RSP message denying the request or stating the scanning interval duration that should be at least as long as requested by the MS. If no MOB-SCN_RSP message is received within a timer, the MS may retransmit the MOB-SCN_REQ message. The serving BS may also send an unsolicited MOB-SCN_RSP message with a value of zero associated with the scan duration to trigger the MS to report scanning result. 

Upon the receipt of a positive MOB-SCN_RSP message, the MS may begin scanning for one or more BSs during the time interval stated in that message. The MS may attempt to synchronize with the DL transmission of the scanned BS and estimate the quality of the PHY channel. IEEE 802.16e specifies a default scanning strategy requiring that each MS keeps a nonvolatile storage where it saves the last set of operational parameters. When the MS intends to acquire a DL channel, it should use its stored information. 

However, if that MS fails to obtain the DL channel, it will continuously scan the possible channels of the DL frequencies until it finds a DL signal. IEEE 802.16e specifications support temporarily suspending the communication between the BS and the MS during the scanning period. The exchange of MOB-SCN_REQ and MOB-SCN_RSP messages enables each entity to buffer packets while the normal communication is temporarily suspended. An MS may end scanning and return to the normal operation mode anytime during any scanning interval; this is achieved by sending a MAC PDU message such as a bandwidth request to the target BS. At the end of scanning, the MS should report the scan status to its serving BS via a MOB-SCN_REP message.

Figure 1: IEEE 802.16e scanning operation.

Network-Initiated Handoff | WiMAX HANDOFF CONTROL

The network can initiate handover depending on its current status. Such a decision can be made after the evaluation of the payload of different BSs or the data throughput at the reference points. In profile A, ASN GWs may initiate handover of MSs under their control. The network-initiated handoff procedure depicted by Figure 1 begins by a prehandover operation, during which the serving ASN GW collects status information from the BSs and the MSs to decide whether a network-initiated handover is required. If it is the case, the ASN GW sends a HO_Directive message to the serving BS to order it to handoff some MSs to other BSs while providing it with a list of recommended BSs and starting a timer. 

The ASN GW may also specify how many payload should be migrated to other BSs to achieve load balancing as it may indicate the list of the recommended MSs that need to be handed over. The serving BS should respond by a HO_Directive_Rsp message to make the ASN GW stop the timer. The serving BS selects some candidate MSs based on the information maintained by it and the list given by the HO_Directive message and then it may order some candidates to achieve scanning to get their neighbors’ information. The serving BS will then select some suitable MSs for handover and send separately a HO_Req message relative to each MS to the serving ASN-GW. The following procedure is the same as the process of MS-initiated handoff described earlier. When the process of handover preparation is finalized by the network, the serving BS will send a MOB-BSHO_REQ message to each MS to order it to hand over to the target BS.

Figure 1: The preparation phase of a network-initiated handoff.

Base Station Initiated Handoff | WiMAX HANDOFF CONTROL

The serving BS may decide to no longer manage an MS and initiate handoff for it. This occurs generally when the serving BS can no longer provide the required QoS or when it detects that the MS is moving out of its coverage area. Although the causes of a BS-initiated handoff are similar to the causes of an MS-initiated handoff, it is useful to let the BS decide to centralize the handoff procedure. In fact, the MSs are generally tiny equipments with limited power and computing resources; therefore, it is important to implement the handoff process at the BS level. 

The serving BS continues broadcasting the MOB_NBR-ADV message for the served MSs, but it orders the MS that needs to perform handoff via a MOB_BSHO-REQ message to start scanning the neighboring BSs. The MOB_BSHO-REQ message transmitted on the basic connection defines a list of recommended target BSs along with service level predictions and channel details. Upon receiving that message, the BS starts the scanning procedure and sends back a MOB_BSHO-RSP message to the serving BS indicating a list of recommended BSs. 

The rest of the handoff process is similar to the MS-initiated handoff case. In fact, the MS waits for the list of the target BSs and then sends a HO-IND message to its serving BS. Upon receiving the fast ranging IE, the MS sends the RNG-REQ ranging request message to the target BS to register with it. The BS-initiated handoff process, described earlier, is depicted by the flow chart in Figure 1.

Figure 1: The BS initiated handoff at the MS level.

Mobile-Initiated Handoff | WiMAX HANDOFF CONTROL

An MS may decide to change its serving BS after losing signal quality or after detecting that a higher QoS can be disserved by another BS. In such situations, the MS will initiate the handoff. Nevertheless, IEEE 802.16e specifications did not specify the methodology of deciding whether or not to perform the handoff; they only focused on the mechanisms that should be implemented to collect information about the neighboring BSs for taking the handoff decision. In fact, each BS should transmit on the broadcast connection a mobile neighbor advertisement message MOB_NBR-ADV informing the listening MSs of the characteristics of any neighboring BS. Such a message includes the identifier of each neighboring BS, its frequency, the supported services, and its available radio resources such as its available channels. Upon getting such information, each MS should be able to take the handoff decision in the light of scanning of possible target BSs. The scanning procedure begins when the MS sends its serving BS a MOB_SCN-REQ message to inform the serving BS that it wishes to scan the neighboring BSs. The message indicates a length of time in frames for this interval and the type of association that will be used for scanning. The aim of association is to enable the MS acquiring and recording ranging parameters and service availability information to select the proper BS target. 

The specifications define three levels of possible associations, which are the association without coordination, the association with coordination, and the network-assisted association reporting. With the association without coordination, the target BS has no knowledge of the MS. Association with coordination means that the serving BS will coordinate association with the requested target BS and then respond to the requesting MS. With the network-assisted association reporting, the serving BS coordinates association with the requested target BS, a RNG-RSP message is sent back over the backbone to the serving BS. The latter collects all received RNG-RSP messages from all scanned BSs and then sends them to the MS in the form of a MOB_ASC_REPORT message. 

Next, the serving BS responds with a MOB_SCN-RSP message specifying the length of the approved scan and the association type that will be used. Upon receiving that message, the MS may scan its neighbors by synchronizing with a given BSs DL transmissions and estimating the quality of the physical channel. After performing scanning, the MS sends a MOB_MSHO-REQ message to its serving BS on the basic connection. That message includes a list of BSs recommended by the MS as targets. Upon receiving such message, the serving BS sends HO-prenotification messages to all BSs specified in the MOB_MSHO-REQ message and waits for the corresponding HO-prenotification-response messages to analyze them. Next, the serving BS generates the MOB_BSHO-RSP message indicating a list of target stations and sends it back to the MS on the basic connection. The MS may now perform or cancel the handoff; it informs its serving BS via a MOB_HO-IND message sent on the basic connection. If it performs handoff, the MS will inform its serving BS that it is leaving it while providing the parameters of the target BS and then it registers with the target BS. The target BS may, upon receiving the HO-prenotification message, include a fast ranging information element (IE) that provides the MS with a noncontention-based initial ranging opportunity to minimize the handoff process latency.

WiMAX HANDOFF

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.

1: SUPPORTED ARCHITECTURE

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.

2: FUNCTIONAL DECOMPOSITION

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.

Figure 1: Handoff function network transaction.

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.

HANDOFF VERSUS ROAMING

1. Handoff: Overview

The recent years have been marked by a growing need for advanced applications and Internet-related services at high throughput and low costs while guaranteeing continuous and open access to such services. Besides, mobile access to Internet services requires access to packet-switched wireless networks, which are generally divided into an access part and a core part. The access part contains the link-layer devices while the core part contains network-layer devices mainly acting at the network layer. A mobile node (MN) wishing to access Internet services needs to attach to the first link-layer device in the access network, also called, link-layer point of attachment (PoA). Nevertheless, the communicating MN may change the link-layer PoA during an active session due to particular reasons. This process is called handover or handoff. Handoff may be mobility driven when link conditions change due to mobility. In such case, the handoff occurs when the MN leaves the radio coverage of the actual PoA and becomes threatened by losing the network connectivity. On the other hand, handoff may be policy driven when the change in the PoA is argued by higher data rates, better services, lower costs, etc. After selecting the new PoA, a particular mobility mechanism implementing the handover process is executed. Such a mobility mechanism updates the mobile device and the network states to reflect the new PoA and redirects the ongoing data packets that were addressed to the old PoA during the handoff. If the MN has switched to a new link-layer PoA belonging to the same access network, a link-layer mobility mechanism will be executed. However, if the mobile device changes between link-layer PoAs belonging to different access networks, a network-layer mobility mechanism will be executed. When both PoAs (the old and the new) implement the same physical layer technology, the handoff is referred to as intratechnology handoff or horizontal handoff. Besides, when the new PoA implements a different physical layer technology compared to the old PoA, an intertechnology handoff, vertical handoff, or roaming takes place. In the latter case, the MN should be equipped with more than one network interface card (NIC). On the other hand, the handoff, which involves connecting to a new link and disconnecting from an old one, may be hard, soft, smooth, or seamless depending on the implemented mobility solution. Hard handoff takes place when the MN receives data packets from only one PoA during the handoff as the current link is disconnected first and then the connection to a new link is established. Controversially, soft handoff enables the MN to receive data packets by more than a PoA simultaneously as first a connection is established to a new link and then the old link is disconnected. Finally, a smooth handoff is a handoff where packet loss is minimized while a seamless handoff is a handoff transparent to the application. Handoff is always triggered by the occurrence of a certain event at the mobile device or in the network. If the handoff trigger occurs in the mobile device, the handoff is mobile initiated; otherwise, it is network initiated. As there is more than one candidate PoA to switch to, the decision to select the new PoA may be taken by the MN or the network; thus the handoff may be mobile controlled or network controlled, respectively. The handoff is mobile controlled and network assisted when the handoff decision is taken by the mobile based on information received from the network. Controversially, if the handoff decision is taken by the network upon the reception of information from the mobile such as the signal quality of neighboring PoAs, the handoff is network controlled and mobile assisted.

2. Roaming: Overview

Roaming appeared with the Global System for Mobile (GSM) technology. It may be defined as the set of mechanisms that allows extending the connectivity service to a location that is not covered by the home network (HN) where the service is registered but is covered by a visited network (VN). The VN always asks the HN for the authentication and authorization data associated with the visiting MN to allow or deny service access. Roaming also refers to changing the access network while on move. For instance, an MN which is GSM enabled and equipped with a wireless local area network (WLAN) NIC may roam between the two networks depending on its location without interrupting an active session. Roaming support is provided through the implementation of mobility management, authentication, authorization, and billing procedures. Different service providers managing different networks need to negotiate a roaming agreement to define the legal aspects related to service availability and billing. Often, the roaming process consists of three steps. First, the HN detects the MN as an unknown device which is not registered; therefore, the VN tries to identify the MN’s HN. If there is no roaming agreement between the HN and the VN, the MN will be not able to access VN services. However, if a roaming agreement exists, the VN requests MN’s service information to deduce whether the MN is allowed to roam. If it is the case, the VN maintains a subscriber record for the device while the HN updates the MN-related information so that any information destined to the MN will be correctly routed. The subscribers activity is registered in a file maintained by the VN. This file includes the details of the initiated calls, the subscribers visited locations, the calling parties, the volume of the exchanged data in case of data calls, the time of the calls and their duration, etc. Based on such information, the HN will be able to perform billing. Interstandards roaming allows MNs to seamlessly move between mobile networks with different access technologies. Nevertheless, this roaming type is particularly challenging as communication technologies have evolved independently across continents and were implemented by different industry bodies.