CSN-anchored Mobility

The CSN-anchored mobility refers to mobility across different ASNs alternatively to mobility across different IP subnets, and thereby requires network layer mobility management. The mobile IP protocols are used to manage mobility across IP subnets, and to enable CSN-anchored mobility. This section describes mobile IP based macro-mobility between the ASN and CSN across R3 reference point. In the case of IPv4, this implies re-anchoring of the current FA to a new FA, and the consequent binding updates (or MIP re-registration) to update the upstream and downstream data forwarding paths. In CSN-anchored mobility, the anchor mobile IP FA of the MS is changed. The new FA and CSN exchange messages to establish a data forwarding path. The CSN-anchored mobility management is established between ASN and CSN that are in the same or different administrative domains. The mobility management may further extend to handovers across ASNs in the same administrative domain. The procedures for CSN-anchored mobility management and the change of MS point of attachment to the ASN may not be synchronized. In this case, the procedures may be delayed relative to the completion of link layer handover by the MS. 

In an intra-NAP R3 mobility scenario, an MS is moving between FAs within a single NAP domain. The R3 mobility event results in a handover between two FAs, thereby relocating the ASN R3 reference anchor point in the NAP. Note that R3 mobility does not automatically terminate or otherwise interfere with idle/sleep operation of the MS. The CSN-anchored mobility accommodates the scenario in which the MS remains in idle state or sleep mode until it is ready to transmit uplink traffic or is notified of downlink traffic by the serving BS. In all non-roaming scenarios, the HA is located in the CSN of H-NSP. For roaming scenarios, the HA is located in the CSN of either the H-NSP or V-NSP, depending on roaming agreement between H-NSP and V-NSP, user subscription profile and policy in H-NSP. The CSN-anchored mobility within a single NAP administrative domain does not introduce significant latency and packet loss. A make-before-break handover operation (i.e., when a data path is established between the MS and target BS before the data path with the serving BS is broken) is feasible within the same NAP administrative domain. To accomplish this procedure, the previous anchor FA maintains data flow continuity while signaling to establish the data path to a new anchor FA. The PMIP procedures do not require additional signaling over-the-air or additional data headers to perform CSN-anchored mobility. The CSN-anchored mobility activities are transparent to the MS. The MS uses Dynamic Host Configuration Protocol (DHCP) for IP address assignment and host configuration. DHCP is a network application protocol used by devices to obtain configuration information for operation in an IP network. This protocol reduces system administration workload, allowing devices to be added to the network with minimal user intervention 

WIMAX Mobility Management

The WiMAX network architecture supports two types of mobility: ASN-anchored mobility (intra-ASN) and CSN-anchored mobility. ASN-anchored mobility refers to a scenario where a mobile terminal moves between two base stations belonging to the same ASN while maintaining the same foreign agent at the ASN. The handover in this case utilizes R6 and R8 reference points. The CSN-anchored mobility refers to an inter-ASN mobility scenario where the mobile station moves to a new anchor foreign agent and the new FA and CSN exchange signaling messages to establish data forwarding paths. The handover in this case is performed via R3 reference point with tunneling over R4 to transfer undelivered packets. 

Figure below illustrates three different mobility scenarios supported in WiMAX networks. When the mobile station moves from positions 1 to 2, or 1 to 3, an ASN-anchored mobility through R8 or R6 reference points, respectively, is implied, whereas moving from position 1 to 4 involves a CSN-anchored mobility scheme though R3 reference point.

WIMAX Radio Resource Management (RRM)

Efficient utilization of radio resources within an access network is performed by the radio resource management entity. The mobile WiMAX RRM is based on a generic architecture. The RRM defines mechanisms and procedures to share radio resource related information between BS and ASN-GW. The RRM procedures allow different BSs to communicate with each other or with a centralized RRM entity residing in the same or a different ASN to exchange information related to measurement and management of radio resources. Each BS performs radio resource measurement locally based on a distributed RRM mechanism. It is also possible to deploy RRM in an ASN using base stations with RRM function, as well as a centralized RRM entity that does not reside in the BS and collects and updates radio resource indicators such as choice of target BS, admission or rejection of service flows, etc., from several BSs. The RRM procedures facilitate the following WiMAX network functions: 

• MS admission control and connection admission control, i.e., whether the required radio resources are available at a candidate target BS prior to handover; 

• Service flow admission control, i.e., creation or modification of existing/additional service flows for an existing MS in the network, selection of values for admitted and active QoS parameter sets for service flows; 

• Load balancing by managing and monitoring system load and use of counter-measures to enable the system back to normal loading condition; 

• Handover preparation and control for improvement/maintenance of overall performance indicators (for example, the RRM may assist in system load balancing by facilitating selection of the most suitable BS during a handover).  

The RRM is composed of two functional entities, i.e., radio resource agent (RRA) and radio resource control (RRC). The radio resource agent is a functional entity that resides in the BS. Each BS includes a radio resource agent. It maintains a database of collected radio resource indicators. An RRA entity is responsible for assisting local radio resource management, as well as communicating to the RRC to collect and measure radio resource indicators from the BS and from a plurality of mobile terminals served by the BS using MAC management procedures as specified by the IEEE 802.16 specifications. It also communicates RRM control information over the air interface to the MS, as defined by the IEEE 802.16 specifications. An example of such RRM control information is a list of neighbor BSs and their parameters. It further performs signaling with RRC for radio resource management functions, as well as controlling the radio resources of the serving BS, based on the local measurements and reports received by the BS and information received from the RRC functional entity. 

The local resource control includes power control, monitoring the MAC and PHY functions, modifying the contents of the neighbor advertisement message, assisting the local service flow management function and policy management for service flow admission control, making determinations and conducting actions based on radio resource policy, assisting the local handover functions. 

The radio resource control functional entity may reside in BS, in ASN-GW, or as a standalone server in an ASN, and is responsible for collection of radio resource indicators from associated RRAs. The RRC can be collocated with RRA in the BS. The RRC functional entity may communicate with other RRCs in neighboring BSs which may be in the same or different ASN. The RRC may also reside in the ASN-GW and communicate to other RRAs across R6 reference point. When the RRC is located in the ASN, each RRA is associated with exactly one RRC. The RRC relay functional entity may reside in ASN-GW for the purpose of relaying RRM messages. The RRC relay cannot terminate RRM messages, but only relays them to the final destination RRC. Standard RRM procedures are required between RRA and RRC, and between RRCs across network interfaces to ensure interoperability. These procedures are classified into two types: information reporting procedures for delivery of BS radio resource indicators from RRA to RRC; and between RRCs and decision support procedures from RRC to RRA for communicating recommendations on aggregated RRM status (e.g., in neighboring BSs) for various purposes. 

The RRM primitives can be used either to report radio resource indicators (i.e., from RRA to RRC or between RRCs) or to communicate decisions from RRC to RRA. The former type of primitive is called information reporting primitive and the latter is called decision support primitive. The available radio resource information provided by the RRAs to RRC is used by RRC for load balancing. The RRC may interact with the handover controller to ensure load balance.