Since the era of All-IP is drawing near and the prevalent use of mobile devices, which demands for anywhere, anytime and any way high speed internet access, is being accelerated more and more, the importance of IP Mobility has been increased as the time passes. Mobile IPv6, the most representative efforts in the way toward All-IP mobile networks, however, has some weaknesses such as latency, packet loss, and signaling overhead. Also, it has been slowly deployed in real world over past years due to the different interests from the researchers and market.
So, I decided to post an article based on the paper entitled as 'MOBILITY MANAGEMENT FOR ALL-IP MOBILE NETWORKS: MOBILE IPV6 VS. PROXY MOBILE IPV6' published in 2008, because, from the emergence of Proxy Mobile IPv6 upward, there was little change on the field of ‘mobility management’ and, few days ago, on last Tuesday exactly, the second big telco in korea, KT, announced the ‘All-IP’ future plan to provide a user with a seamless wireless experience regardless of the type of devices like smartphone, laptop, or even the mobile router.
First. We need to know what the mobility management is. Mobility management enables the serving networks to locate a mobile subscriber’s point of attachment for delivering data packets (i.e., location management) and to maintain a mobile subscriber’s connection as it continues to change its point of attachment (i.e., handover management). Actually, the term ‘Mobility Management’ is jargon from 3gpp, but since it bears the aspects of both location and handover, I borrowed it.
The IP Mobility describes the network structure for the communication between CN, Correspondent Node and MN, Mobile Node. When MN moves to another domain or location, in the current IP-based network structure, we should set new IP address to be connected to internet. And while re-configuring, the connection between MN and CN becomes down since the communication is based on Internet Protocol, which uses IP pair per each session.
The core idea of IP Mobility is that we designate one fixed node, we call it as HA, Home Agent, as a serving node which will send/receive the packets instead of MN. In this figure, there are FA connected to Router but you may ignore that since it was the agent from Mobile IPv4 and it was obsoleted as Mobile IPv6 emerged. CN sends the packets to HA and, HA hands the packets over to MN so that wherever the MN locates, it can be communicable via HA and vise versa.
The typical variations of Mobile IPv6 are Hierarchical MIPv6 and Fast MIPv6. As I mentioned earlier, in Mobile IPv6, HA acts as an proxy of MN so that it can receive or send any packets regardless of the current location of MN through the bi-directional tunnel between HA and MN. But there’s drawback of packet delay and also the packet loss during the handover procedure, result from the distance between the MN and HA that it must get through for every movement of MN.
So to alleviate these weaknesses, Hierarchical MIPv6 and Fast MIPv6 were appeared on the scene.
Fast MIPv6 is based on the assumption that the next location of MN can be predicted with the information from Layer 2.
It predicts what the new Access Router will be and then makes a tunnel toward it, in order to send the portion of upcoming data, before the MN moves and then detaches from current AR. New AR stores the packets coming through the tunnel and, after the MN attaches to it, it flushes the buffer to MN so that the user doesn’t need to re-initiate the whole data flow again.
Hierarchical MIPv6 is to optimize the binding procedure in hierarchical network structure with a special entity named MAP(Mobile Anchor Point) that works as local HA.When MN relocates within the same MAP domain, it is only required to send binding message to MAP instead of HA, resulting the overall handover time to be shorten.
So far, we have discussed three types of Mobile IPv6 variations. Each of them has a unique characteristic, but the common drawback of these is that, MN is the primary entity which signals the binding message to HA directly. This causes the congestion on the wireless environment and wastes the electric power of MN which is critical issue on the ubiquitous computing.Also, there should be a modification on the kernel to enable MN to send the mobility-related message in accordance with the situation MN perceives.This is why NETLMM WG come up with the way of Network-based Mobility Management so called ‘Proxy MIPv6’ which doesn't require MN to signal HA for the mobility messages,
With PMIPv6, MN itself doesn’t need to be involved in the mobility procedure and can be connected to the network with the same method it used to do with existing fixed network. Instead, AR signals the mobility messages to HA on behalf of MN thus resolve the issues I stated earlier.
To support the network-based mobility management, MAG and LMA is introduced in PMIPv6. LMA acts as a local HA so, all the packet flows must pass through this entity, then the bi-directional tunnel to be specific. MAG is an entity attached to AP or AP itself, with the functionalities for the mobility support, with the establishment of bi-directional tunnel reaching out to LMA. When MN attaches to the LMA domain, LMA assigns ‘MN-HoA’ to MN which is made of the domain prefix and the MN-Identifier like a MAC address. MAG also has its own IP address named ‘Proxy-CoA’ which is a point of contact of MN on a specific location. You can find some similarity to HMIPv6 in regard to the fact that there’s local anchor point for each network domain represented as MAP or LMA.
Even though PMIPv6 has many advantage over other protocols, it bears a critical defect on not supporting macro handover which means it covers only its own domain. The way to make up for its weak point is to merge this protocol with others so that the MN can be covered by PMIPv6 within its domain, and other protocols intervene in other coverage. This is why we need to know the characteristics of PMIPv6 and subsidiaries, in order to choose what protocol we need to deploy, on appropriate circumstance.
Basically, MIPv6 and their enhancement protocols except FMIPv6 support location and handover management functionalities to some extent. Successful deployment of MIPv6 and their enhancement protocols requires the addition or modification of some functionality in both the network and MN. In contrast, PMIPv6 requires no modification of the MN’s protocol stack. HMIPv6, and PMIPv6 have been proposed to reduce handover and registration latencies in a localized domain. HMIPv6, although it is an efficient localized mobility management protocol that can reduce handover latency significantly compared to MIPv6, it still requires movement detection and DAD because the MN’s on-link CoA (LCoA) should be newly assigned whenever the MN moves to another subnet within a domain. the performance of handover latency in PMIPv6 appears to be better than that of HMIPv6 because the MN within a PMIPv6 domain always uses the same home address, and hence does not perform movement detection and DAD
MIPv6 is most affected by the change in wireless link delay because it requires the largest number of messages
(e.g., the message exchanges for the BU or binding acknowledgment (BA) to/from the HA, the return routability procedure, and the BU for the CN) to be exchanged over the wireless link. In contrast, PMIPv6 is least affected because the MN is not involved in mobility-related signaling. In particular, it must be noted that the handover latencies of MIPv6 and HMIPv6 are significantly larger than that of PMIPv6.
Since we evaluate handover latency only for intradomain movement, HMIPv6 and PMIPv6 do not require registration to the CN because the MN’s movement within a domain is transparent outside the domain. That is, the delay between the MN and CN does not affect the handover latency of each protocol within a domain. However, for MIPv6, the handover latency increases with the delay between the MN and CN. This is because MIPv6 requires registration to both the HA and CN whenever the MN moves across subnets; thus, the increase in the delay between the MN and CN affects the increase in handover latency in MIPv6.
in PMIPv6, movement detection does not occur except when the MN moves across a PMIPv6 domain. This is due to the fact that since PMIPv6 only supports the per-MN-prefix model, a unique home network prefix is assigned to each MN, In other words, the MN is not related to movement detection delay in intra-domain movement. On the contrary, the graphs for MIPv6 and HMIPv6 increase with the same slope as the movement detection delay does. In MIPv6 and HMIPv6, whenever the MN moves across subnets, it configures the different CoAs via stateless (or stateful) address autoconfiguration. Therefore, in MIPv6 and HMIPv6, movement detection should be performed as quickly as possible in order to minimize handover latency and packet loss. Increased movement detection delay results in increased handover latency, and this could cause significant degradation to be experienced by the MNs.
댓글