Mobility Management in IEEE 802.16-2009

Figure 7.1 shows the procedures involved in initiating and carrying out a handover. The standard does not specify how the handover decision should be made, nor does it mandate whether the decision should be made by the network or the MS. The standard, however, provides means for information acquisition by both the BS and the MS to make efficient decisions. The information acquired generally specifies the quality of the signal received by the MS from the various BS, but also information on the readiness of these BSs to support the MS's requirements.

image

Figure 7.1 Flow chart for handover process. Reproduced by permission of © 2009 IEEE.

The procedures in the figure are almost identical to those of network entry and initialization, which were described previously in Chapter 5. To enhance service delivery for an already active call, the standard defined certain optimizations so as to accelerate the handover process. These optimizations are described on the next page. In addition, certain enhancements in the standard, such as seamless handover and macro-diversity handovers, will be outlined.

Acquiring Network Topology

A network topology means different things for the BS and the MS. A BS requires an understanding of the capabilities of its neighboring BS, and requires active communication links to these BS for various mobility management objectives, including handover and resource allocations. Meanwhile, an MS must have a way of measuring the signal strengths and understanding the capabilities of the BSs it recognizes as traverses the network.

A BS understands the status of its neighboring BSs through the network's backbone. For an MS, information on network topology can be acquired in two manners: either through topology advertisement from the serving BS, or through the MS scanning for neighbor BSs. The topology advertisement, sent through the neighbor advertisement message (MOB_NBR-ADV), voids the need for the MS to scan the DCD/UCD of neighboring BSs. Each MS maintains what is called an association table that maintains a record of the BSs to which the MS has been or may be associated. The table is limited by a parameter specifying the maximum number of neighbors, NMS_max_neighbors. A BS may send information for more than NMS_max_neighbors neighboring BSs. However, an MS is only required to support at NMS_max_neighbors in its association table.

To perform scanning of neighboring BSs, an MS needs to be allocated time intervals from its serving BS. An MS therefore needs to send a scanning interval allocation request (MOB_SCN-REQ), through which an MS may specify desired scanning intervals with interleaving intervals of operation. The final decision for selecting scanning intervals and their durations, however, is completely left to the BS. A BS receiving a MOB_SCN-REQ responds with MOB_SCN-RSP either granting scanning intervals and durations, or denying the sensing request. In a MOB_SCN-RSP, a BS may also recommend certain neighboring BSs for association. A BS may also send an unsolicited MOB_SCN-RSP whereby the MS would respond with a report of its measurements for the indicated neighboring BSs, if applicable. It is possible that an MS receives several responses, called scanning interval allocation response or MOB_SCN-RSP, to its scanning request, which could happen if multiple BSs respond to the MS's request, or if the MS's serving BS has a short timeout clock. In such cases, the MS should only consider to the most recent it receives. Whether or not a BS recommends neighboring BSs for association, an MS can perform any scanning or association activities in the scanning intervals it is allocated.

Association Procedures

The standard defines association as “an optional initial ranging procedure occurring during scanning interval with respect to one of the neighbor BS.” Its role is to enhance the handover process through gathering information that is useful for selecting the target BS and that accelerates the MS's ranging process during handover. As aforementioned, an MS maintains an association table for the various BSs that it is informed about or becomes aware of as it traverses the network. To maintain a fresh list, each BSID entry in the association table expires after a set amount of time. This expiry can be either indicated by the BS, or set by the network. If indicated in initial ranging, a serving BS can be included in the table.

For an MS, association can be directed by a BS recommending neighboring BSs through MOB_SCN-RSP. If the MS supports directed association, it shall scan the recommended BSs. Such support is indicated during network entry when negotiation basic capabilities.

There are three levels of association.

  • Association Level 0: Scan/Association without coordination;
  • Association Level 1: Association with coordination; and
  • Association Level 2: Network assisted association reporting.

If Level 0 is chosen by the network, only the scanning intervals are coordinated between the serving BS and the MS. A target BS would not be aware of an MS possible handover to its coverage. The MS would contend as if performing initial ranging.

If the MS requests (through MOB_SCN-REQ) or the BS arranges for a Level 1 association, the BS would provide scanning intervals to the MS and coordinate handover with neighboring BSs. Through an unsolicited MOB_SCN-RSP, the serving BS may indicate possible alternatives to the MS. A neighboring BS would provide a rendezvous time, a unique code number and a transmission opportunity. A rendezvous time is the identification of the frame with the transmission opportunity in which the MS would send the unique code number. Assigning a unique code and transmission opportunity is called dedicated ranging. A form of coordination may be exercised between BSs such that no or minimum collision can result from codes utilized in handover procedures. An MS is expected to synchronize immediately at the first frame following the rendezvous time, and be able to extract information from the UL-MAP to distinguish the transmission opportunity. If synchronization fails, the MS aborts the Level 1 association. If the MS is still interested in establishing the connection, the MS may perform a Level 0 association afterwards.

In the network assisted association, Level 2, an MS is only required to send the CDMA ranging to the neighboring BS at the appropriate time. The serving BS would relay ranging and other information from the neighboring BS through a single association report message (MOB_ASC_REPORT). The target BS would expect the MS's CDMA code during the ranging period indicated, whether or not it is a dedicated ranging period.

The Handover Process

Procedures for cell reselection and handover decision and initiation need not to be associated to each other. An MS may consider reselection proactively to achieve certain operational objectives, for example, an MS may persistently seek the BS with a relatively much higher signal strength or with better indications of QoS support. Handover decisions may originate at either an MS or the serving BS. If an MS decides to handover, it sends an MS handover request (MOB_MSHO-REQ), while if a BS is requesting an MS to handover; it sends a BS handover request (MOB_BSHO-REQ). For any ongoing handover process, both the MS and BS will ignore any handover initiation requests unless the ongoing handover has been acknowledged to be either successfully terminated or cancelled.

An MS needs to synchronize and range with the target BS prior to resuming regular operations. Depending on how association is made, synchronization and ranging can be optimized to accelerate the handover process. In particular, procedures for negotiating basic capabilities, authentication, registration and adjustments can all be skipped during handover procedure. As such information would have been relayed in initial ranging, it is possible to establish a level of collaboration between the BS in IEEE 802.16 such that these information can be relayed from the serving BS to the target BS.

If an MS acquires a pre-allocated Basic CID prior to a seamless handover, it will be able to derive the primary management and transport CID autonomously from the pre-allocated basic CID. This usually takes place if a seamless handover can be supported at the serving BS, the target BS and the MS. If a dedicated allocation is made for the MS to send in a RNG-REQ directly, the CDMA ranging can be bypassed. Such a dedicated allocation would be part of what is called fast ranging—an expedited ranging procedure that is viable through the serving BS negotiating entry parameters with the target BS. The target BS would indicate further information using a Fast_Ranging_IE information element.

Options within the MOB_BSHO-REQ and MOB_MSHO-REQ offer great flexibility in terms of how a handover can proceed. A BS, for example, can specify the target BS to which the MS should attempt to handover. As an alternative, the BS may select a group of neighboring BS, of which the MS can attempt handover to one or more. In such a case, the MS does not need to notify the serving BS about the chosen BS. It is also possible that an MS would ignore BS's recommended set of neighboring BSs. An MS can also explicitly reject a handover recommendation if it is unable to successfully perform the process. In such a case, a BS may reconsider its recommendation. In some instance, a BS can force the MS to perform handover regardless of the MS's considerations of choice. Note that a serving BS may coordinate with neighboring BSs, informing more than one BS of the MS's intent to handover. Information, as will be described below, can also be relayed to expedite the handover procedure.

An MS committed to a handover will terminate with the serving BS through indicating the handover type in a handover indicator message (MOB_HO-IND). In such instances, a BS may retain certain information about the MS that would expedite the MS handover to the target BS and would indicate this to the MS in the MOB_BSHO-RSP message. A MS can cancel an ongoing handover procedure through the serving BS by either resuming regular operation, for example, sending a bandwidth request, or by explicitly cancelling the handover in a MOB_HO-IND message.

A handover drop occurs when an MS loses communication with the serving BS prior to completing the handover procedure, including termination with the serving BS. Both an MS and a BS can detect a drop, for example, if the number of RNG-REQ retries limit has been exceeded. An MS detecting a drop can attempt a handover entry to either a target BS or the serving BS. If the serving BS has already discarded the MS's context, a full network reentry with possible handover optimization needs to be performed.

If both the serving and the target BSs support continuity of downlink transmissions, for example, maintainable state for ARQ connections through the handover, it is possible that the “in flight” information can be transferred from the serving BS to the target BS to maintain continuous delivery at the MS.

The standard describes a range of possible optimizations whereby an MS's context can be shared between the serving BS and the target BS. An MS's static context refers to parameters acquired and configured in network entry and initialization, and that may have been adjusted later on during an MS's connection lifetime, in addition to all service flow encodings. An MS's dynamic context, however, refers to the state of counters, timers, state machine status, and data buffer contents.

There are several levels of handover optimization that can be exercised in the network. At one end, no optimizations can be exercised, and in such a setting an MS always has to perform a full network entry with or without a traffic IP address refresh. At the other end, there is the fully optimized handover whereby both static and dynamic contexts are handed from the MS's serving BS to the target BS during handover. In between the two ends, there are further two options whereby full optimization can be done with, for example, Traffic Encryption Key (TEK) updates, and a partially optimized handover whereby only static context is moved.

Optional Handover Modes

The standard defines two optional handover modes, both of which are based on diversity communications. The two modes, called Macro-Diversity Handover (MDHO) and Fast BS Switching (FBSS), essentially rely on maintaining diversity set detailing the set of BSs with which an MS can establish connections. The difference between the two handover types is that in MDHO the MS communicates with all BSs in the diversity set, while in FBSS the MS only communicates with an anchor BS. A critical advantage of FBSS is that an MS does not perform a full handover process; rather, it merely indicates a change of anchor in its diversity set. In other words, an MS “serving” entity becomes the diversity set, and not just one serving base station. As long the MS remains within the same diversity set, it is not required to perform a full handover procedure. Both MDHO and FBSS can be viewed as soft handovers, compared to the mandatory hard handover described above.

BSs involved in MDHO or FBSS, in addition to the MS, must support the type of handover mode utilized. For both BSs and MSs, the support of either mode is optional. An MS is to follow the type of handover dictated by the BS either in its response to a MOB_MSHO-REQ, that is, a MOB_BSHO-RSP, or in its handover initiation, that is, a MOB_BSHO-REQ. As in a regular handover, both the BS and the MS would ignore any handover initiation requests if there is a currently active one.

The MS selects and updates BSs for its diversity set through scanning, and shall report this diversity set to the serving or anchor BS, depending on the handover mode employed. An MS is also required to continuously monitor the signal strength of the BSs included in this set, and select one BS as its anchor. Meanwhile, an MS may consider the anchor's MOB_NBR-ADV, previously performed signal strength measurement, propagation delay measurement, scanning, ranging and association activity. The selection should be reported through either the CQICH or the MOB_MSHO-REQ. A regular handover can be considered a special case of either MDHO or FBSS whereby the diversity set includes a single BS that is also the anchor BS.

BSs supporting either diversity handovers would include the H_Add and H_Delete thresholds in their DCD messages. These thresholds can be used by an MDHO or FBSS capable MS in determining whether a BS should be included or deleted from the diversity set maintained by the MS. If the mean CINR of an active BS in the current diversity set is less than the H_Delete threshold, the MS may request that this BS be dropped from this diversity set. Similarly, if the mean CINR is greater than the H_Add threshold, the MS may request that the respective BS be added. The MS update of its diversity set is recommended but not mandated. In fact, an MS's diversity set is only required to be a subset of those listed in a BS's MOB_BSHO-RSP or MOB_BSHO-REQ. An MS may reject a recommended diversity set any recommend a preferred one to be included.

There are two ways in which an MS can gather control information under MDHO. In the first one, the MS observes control information from all BSs in the diversity set while in the second one, the MS only observes control information from the anchor BS. In the latter case, the anchor BS may include burst allocation information for the non-anchor BS. Under FBSS, an MS only observes the anchor BS for control information.

An MDHO begins with a decision for an MS, made by either the MS or the BS, to begin a simultaneous exchange of messages and traffic with multiple BSs. For the downlink, two or more BSs would provide synchronized transmission to the MS; while for the uplink, transmission from the MS would be received by multiple BSs. For FBSS, a handover comprises an update of the anchor BS.

The following conditions are shared by both handover types:

  • The involved BSs are synchronized based on a common time source.
  • The frame sent by the involved BSs at a given frame time arrive at the MS within the same prefix interval.
  • The involved BSs have a synchronized frame structure.
  • The involved BSs have the same frequency assignment.
  • The involved BSs required to share or transfer the MS's MAC context.

Similarly, the following conditions pertain only to MDHO handovers:

  • The involved BSs would use the same set of CIDs for the connections that are established with the MS.
  • The same MAC/PHY PDUs shall be sent to the MS by all the involved BSs.

There are two manners in which the anchor BS can be updated in MDHO employing anchors or FBSS. The first relies on the use of HO messages, whereby handover is achieved after deciding on a preferred anchor and a switching by either the MS (through a MOB_MSHO-REQ and MOB_BSHO-RSP exchange) or the BS (through a MOB_BSHO-REQ). The second manner utilizes the fast-feedback whereby the MS transmits fast anchor BS selection information to the current BS selection. The standard describes the required signaling between the MS and both the old and the new anchors in order to achieve a stable transfer. In both update methods, network entry procedures are not required if the new anchor BS is within the MS's diversity set. The standard also describes procedures for MS-assisted coordination of downlink transmission when an MS performs an anchor BS update, but only under FBSS.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset