IEEE Globecom 2010 Workshop on Seamless Wireless Mobility
Proxy Mobile IP with Distributed Mobility Anchors
H Anthony Chan
Department of Electrical Engineering, University of Cape Town, Rondebosch, South Africa
h.a.chan@ieee.org
Abstract Existing wireless networks typically support mobility
by routing via a mobility anchor in a home network, but such via
routing can result in non-optimized routes. This paper proposes a
method to distribute the functions of the mobility anchor to
different networks to avoid such non-optimized routes. It
proposes a distributed mobility anchors architecture consisting of
home mobility anchors (H-MA) at the home networks and visited
mobility anchors (V-MA) at the visited networks. It splits the
functions of a mobility anchor into the logical functions of: (1)
home network prefixes allocation, (2) location management (LM),
and (3) mobility routing (MR). The V-MA performs MR function
to avoid triangle routing problem in Proxy mobile IP, whereas
the H-MA also performs the LM function. The needed location
information of a mobile node (MN) is acquired by a V-MA from
the H-MA only when a packet is first sent to the MN via the V-
MA and are then cached at the V-MA to enable optimized MR
for packets subsequently sent to the MN.
Keywords-handoff; mobile IP; mobility anchor; mobility
management; proxy mobile IP
I. INTRODUCTION
Using the same IP address for session identity and for
routing address in the current IP network has the well-known
problem of breaking the session upon changes of routing
address so that the mobility will not be seamless. Mobile IP
(MIP) including its numerous variants are based on separating
the session identiy from the routing address.
As a mobile node moves to a different network, its routing
address will change. MIP enables a mobile node to keep its
session identifier by routing via a mobility anchor at its home
network so that ongoing sessions may survive the routing
address changes. Yet routing via the same mobility anchor
back in the home network regardless of which network the MN
has moved to may result in longer routes. Distributing the
mobility anchor functions throughout different networks will
avoid such unneccessarily long routes.
This paper looks at MIP in terms of architecture and
protocol layers, the triangle routing problem, and migrating
home agents (Section II). It explains a distributed mobility
anchors design (Section III) and the packet flow (Section IV) as
improvements to proxy MIP, but the design should work
equally well for MIP. It then discusses the performance
(Sections V) based on existing results in the literature and
compares with other related design (Section VI).
II. MOBILE IP AND MIGRATING HOME AGENTS
A. Mobile IP protocols
Mobile IP (MIP) [1, 2] as well as its many variants
decouples the session identity in a home address (HoA) and
978-1-4244-8865-0/10/$26.00 2010 IEEE
routing address in a care-of-address (CoA). A mobile node
(MN) acquires a HoA from its home network and a CoA when
it is attached to a visiting network.
Figure 1a shows the protocol stack as a packet traverses
from a correspondent node (CN) to a MN. The network layer in
the figure shows the destination IP address of the packet. The
packet from the CN is destined to the HoA and is intercepted
by a home agent (HA). The HA encapsulates the packet using
the CoA as the destination address and tunnels it to the MN.
The MN will receive this IP-in-IP tunneled packet and de-
capsulates the packet to retrieve the original packet.
a. MIP
Application Application
Transport Transport
HoA HoA HoA HoA
CoA CoA
CN HA MN
b. PMIP
Application Application
Transport Transport
HoA HoA HoA HoA HoA HoA
CoA CoA
CN MA MAG MN
Figure 1. Architectural view and protocol stacks of (a) MIP and (b) PMIP.
The above basic Mobile IP is host-based, requiring the
nodes to possess the capability to support this protocol.
B. Proxy Mobile IP protocol
Network-based mobility management protocol, such as
Proxy Mobile IPv6 (PMIPv6) [3], employs network elements
to perform the mobility management functions on behalf of the
MN and therefore removes the need to add the MIP function to
every MN. In PMIP (Fig. 1b) a CN and an MN communicates
with each other using the MNs HoA with todays unmodified
IP protocol stack. The MIP function that was needed in MN for
the host-based MIP is moved to the network element called
Mobile Access Gateway (MAG). The MN connects to a visited
network through the MAG, which provides a proxy CoA, so
that it can continue to use its own HoA to attach to the new
network and communicate with the CN. CN only knows the
MNs HoA, and its packets destined to MN are first intercepted
by the HA function residing in a Mobility Anchor (MA). (MA
is originally called local mobility anchor in PMIPv6. The word
local is dropped in this paper.) MAG and MA manage the
binding between the HoA and the CoA, perform encapsulation
and decapsulation, and are the tunneling endpoints for the
traffic between the MN and the CN. Between the MA and the
MAG, the packet is tunneled with the proxy CoA as the
destination IP address in the outter header of the IP tunnel. The
16
inner header uses HoA as the destination IP address which is
shaded in the figure and is not visible while the packet is being
tunneled.
C. Splitting the logical functions of a mobility anchor
This paper splits the logical functions of a mobility anchor
into the following: (1) allocation of home network prefix or
HoA to a MN that registers with the network; (2) internetwork
location management (LM) function: managing and keeping
track of the internetwork location of a MN, which include a
mapping of the HoA to the mobility anchoring point that the
MN is anchored to; and (3) mobility routing (MR) function:
intercepting packets to/from a MNs HoA and forwarding the
packets, based on the internetwork location information, either
to the destination or to some other network element that knows
how to forward to the destination.
PMIP bundles these logical functions into one single entity
known as the mobility anchor MA, resulting in triangle routing
problem as shown in Figure 2.
Home network Visited network
with MA with MAG
MN
Figure 2. Triangle trouting problem with a MN and a CN in networks which
may be close to each other but are far from the MA.
D. Migrating home agents
Migrating home agents [4] duplicate many home agents in
different geographic locations (Figure 3). These home agents
announce the same IP prefixes using anycast, and each can
provide the same full functions of a MNs HA.
MA MA MA MA
MN
Figure 3. Replicating MAs in multiple networks.
The MN attaches to the nearest HA. Traffic originating
from the MN uses the HA nearest to where the traffic
originates, regardless of whether the MN is in the home
network or in a visited network. Packets from the CN destined
to MNs HoA are intercepted by the nearest HA owing to the
use of anycast, so that they again uses the HA nearest to where
the traffic originates.
The authors of migrating home agents have shown with
experimental data that, by strategically locating the home
agents, the round trip time for packets between the MN and a
CN using migrating home agents can approach that of IP
routing without mobile IP.
Although migrating home agents solve triangle routing
problem in mobile IP, the need to synchronize all these HAs is
a challenge [5]. The amount of signaling to push the
information changes from each HA to all the other HAs need
to scale with possibly a large number of MNs and HAs.
III. DISTRIBUTED MOBILITY ANCHORS DESIGN
Having splitted the logical functions of the MA, one may
examine which logical functions needs to be present in many
geographic locations and which logical functions should not.
Placing the MR function in multiple geographic locations
(Figure 4) will solve the triangle routing problem. Yet pushing
the LM information to different networks may be an overkill,
especially because the MN seldom actually communicates with
the CNs in all the other networks.
LM
MR MR MR
MR MR
(V-MA) (V-MA)
(H-MA)
MN CN
Figure 4. Mobility routing (MR) function is available in many networks,
whereas the management (LM) function resides in MNs home network only.
Placing the LM function at the MNs home network will
eliminate the need to synchronize the LM information in
different networks in a timely and scalable manner. The
CN different LM function in different MNs home networks form a
distributed database for the LM information of all the MNs.
The MA to which an MN is anchored to is the destination
MA (D-MA). It will deliver incoming packets to the MN.
When a CN sends a packet to MN, the MA closest to that
CN needs to intercept the packet to avoid triangle routing. This
MA is the originating MA (O-MA) that will perform the MR
function to route this packet to the D-MA.
A. Home mobility anchor versus visited mobility anchor
MA
The home mobility anchor (H-MA) of a MN consists of the
logical functions of home prefix allocation, LM, and MR. It
resides in the MNs home network, i.e., the network to which
the MN is registered. The visited mobility anchor (V-MA)
CN resides in a visited network performing MR function only for
the MN.
Note that the logical functions of the H-MA do not need to
be in one single physical entity or even co-locate. It is possible
to have one or multiple instances of the LM function and one or
multiple instances of the MR function, and they do not need to
be in one-to-one relationship.
Each H-MA in each network uses its own block of IP
prefixes to allocate the home IP prefixes to the MNs belonging
to that home network. The IP prefixes of all the H-MAs form a
superset of IP prefixes. All the H-MAs and V-MAs advertise
this same superset of IP prefixes using anycast. Then, no matter
where a MN is located, the anycast and the routing algorithm
will enable the nearest MA to serve the MN.
To perform internetwork LM function when the MN is in a
visited network, H-MA needs to know which V-MA the MN is
17
anhored to. The H-MAs in different networks provide a
distributed database of such records for all the MNs anchored
to these networks.
The MA to which the MN is anchored delivers incoming
packets to the MN; it is the D-MA for incoming packets. When
the MN is in its home network, it is anchored to its H-MA.
When the MN is in a visited network, it is anchored to the
nearest V-MA in that network, and MAG performs the MIP
signaling on behalf of the MN.
Any packet sent from a CN in any network to the HoA is
intercepted by the O-MA which is the MA nearest to the CN.
The O-MA will need to obtain the location information of the
MN from the H-MA in order to route the packets to the D-MA.
Because the MNs HoA belongs to the IP prefix of its home
network, the mapping of the HoA to the H-MA does not
change often and can therefore be known to all the V-MAs.
The MR function in the V-MA before route optimization is
simply to forward a packet from the CN to the H-MA of the
MN, and the H-MA has the dynamic location information
about the MN to complete the MR. After route optimization the
packets will need to be forwarded directly from the O-MA to
the D-MA.
B. Registration to home network
An MN will register with a H-MA in its home network. The
H-MA can download the profile of the MN from the home
AAA server. It allocates to the MN a HoA belonging to a block
of prefixes managed by the H-MA. It performs MR for the MN
within this home network and also performs LM for the MN. If
the MN has moved to another network and is anchored to a V-
MA of a visited network, the V-MA needs to update the H-MN
of the new location of the MN, i.e., the new V-MA the MN is
anchored to.
C. Anchoring to a visited network
An MN that has registered with the H-MA in its home
network may leave the home network. As it enters a visited
network, it still receives the prefix advertisement of its HoA
from the MA that uses anycast to advertise the superset of the
HoA prefixes.
When a change of MAG is involved, the new MAG sends
binding update to the MA on behalf of the MN using MNs
HoA and its proxy CoA. The MA may look up and therefore
knows which H-MA the MN has registered to, based on the
prefix of the MNs HoA.
The visited MA (V-MA) in the visited network becomes
the new mobility anchoring point of the MN. It performs MR
function for the MN. It also informs the H-MA that it is the
current mobility anchoring point for the MN.
After the MN has anchored to a V-MA (V-MA-1) in a
visited network, it may move to another visited network and
anchor to another V-MA (V-MA-2). The H-MA must again be
informed of this new anchoring point. In addition, the V-MA-1
is also informed that the MN has anchored to V-MA-2 so that,
for a limited time, if V-MA-1 receives packets destined to MN,
the V-MA-1 may forward these packets to the V-MA-2.
18
D. Intercepting packet using anycast
Each MA in its network owns a unique set of IP prefixes to
allocate home network prefixes or HoAs to the MNs registered
to that network. The HoA prefixes of all the MAs form a
superset of HoA prefixes. Some prefixes in this superset may
be aggregatable, but some may not. Each MA advertises the
superset of these HoA prefixes using anycast so that an IP
packet sent to any HoA will be intercepted by the MA nearest
to the sender. An example is shown in Figure 5.
MA of Network 1 MA of Network 2 MA of Network 2
allocates HoA with allocates HoA with allocates HoA with
prefixes P1A, P1B prefixes P2A, P2B prefixes P3A, P3C
PA,PB,P3C PA,PB,P3C PA,PB,P3C
Figure 5. Example of Anycast of HoA Prefixes. The MA in each network
broadcasts the superset of prefixes PA, PB, P3C, where PA is the aggregate of
P1A, P2A and P3A, and PB is the aggregate of P1B and P2B.
E. Mobility routing
When an O-MA has intercepted a packet with a destination
address of an MNs HoA, it checks whether it has location
information for this HoA in its cache. If the cache memory
indicates that the MN is anchored to a MA, it tunnels the
packet to that MA (D-MA).
If the location information is not in the cache memory, the
O-MA tunnels the packet to the H-MA based on the HoA
prefix. When the H-MA receives this packet, it checks its
location information about this HoA. If the location
information indicates that the MN is currently anchored to a V-
MA, the V-MA is the D-MA serving the MN. The H-MA
tunnels the packet to the D-MA and also sends this location
information to the O-MA to enable O-MA to tunnel future
packets directly to the D-MA. When the O-MA receives this
new location information from the H-MA, it caches this
information, which will time out if the O-MA has no activities
related to this HoA.
If an MN has recently moved from one D-MA (previous D-
MA) to another D-MA (new D-MA), The new D-MA will send
the new location information of the HoA to both the H-MA and
the previous D-MA. The previous D-MA caches this location
information, which will time out when its timer expires.
When the previous D-MA receives packets for the HoA
from an O-MA, it checks its cache memory about the new
location information of the MN. If the cache memory has not
timed out, it tunnels the packets to the new D-MA. Meanwhile,
it sends this location information update to the O-MA.
IV. PACKET FLOW
There are 3 cases of packet flow to be considered here: (1)
sending packet to a MN from a non-mobile CN; (2) sending
packet from a MN to a non-mobile CN; (3) sending packet
from a MN to a mobile CN.
A. Sending packets to a mobile node
When a CN first attempts to communicate with a MN using LM
the MNs HoA, the packet is intercepted by the MA (O-MA) MR MR MR MR MR
(H-LMA) (V-LMA) (V-LMA)
nearest to that CN because all MAs are advertising the same
superset of IP prefixes using anycast. This O-MA uses the HoA MAG
to look up the H-MA of the MN and then tunnels the packet to
the H-MA. The H-MA receives the packet and de-capsulates it MN CN
to read the HoA of the MN. Appl Appl
If the MN is in a visited network, the H-LMN tunnels the Transport Transport
packets to the V-MA to which the MN is currently anchored. HoA HoA HoA HoA HoA HoA
This V-MA is the D-MA that will de-capsulate the packet and CoA OMA VMA
use the proxy care-of address (proxy CoA) to tunnel the packet MN MAG O-MA CN
to the MAG to deliver to the MN. Figure 6 shows the
destination address at the network layer of the protocol stack of Figure 8. Sending packet from a mobile node.
a first packet sent from the CN to the MN.
C. Sending packets from a MN to another MN
We now consider the case of sending packets from a MN
First Packet
(MN1) to another MN (MN2). Packet sent from MN1 will first
Appl Appl be tunneled from MAG to O-MA as in Figure 8. The route
Transport Transport from O-MA to MN2 will be the same as that in Figure 6 and
HoA HoA HoA HoA HoA HoA HoA HoA HoA HoA Figure 7 for respectively the first packets and subsequent
HMA HMA VMA VMA CoA CoA packets.
CN OMA HMA VMA MAG MN
For the subsequent packets, the traversed route will be:
Figure 6. The first packet sent from a CN to a MN in a visited network MN1-MAG1-OMA-DMA-MAG2-MN2. It is possible to
showing the destination IP address of the packet.
bypass the O-MA and/or the D-MA.
Only the first packets from the CN may encounter triangle
routing. When the H-MA has received this first packet from the V. PERFORMANCE
O-MA and as it forwards this packet to the V-MA (D-MA), it
also informs the O-MA that the HoA is currently anchored to This section addresses the performance issues based on
the D-MA. The O-MA keeps this location management existing results already reported in the migrating home agent
information in a cache memory so that it may forward future design. The difference in design of distributed mobility anchor
packets directly to the D-MA. The D-MA uses the proxy care- from migrating home agent is that the O-MA may lack location
of address (proxy CoA) to tunnel the packets to the MAG to information. For the first packets sent to the HoA of MN, the
deliver to the MN. In the absence of traffic from the O-MA to ingress router lacks the location information about HoA and is
the HoA, the cache memory in the O-MA times out after a simply using PMIP. After the first packets, the HMA will push
predefined period. the location information to the O-MA. Having cached this
location information at the O-MA, the O-MA for this particular
The D-MA may also inform O-MA the proxy-CoA. The O- HoA has no difference from a full HA in the migrating home
MA will keep this information in its cache memory so that it agent design. So the routing for the subsequent packets will be
may tunnel future packets directly to the MAG (Figure 7). following the migrating home agent. The authors of migrating
home design have already reported their performance in their
paper.
Route Optimization
Appl Appl A. Round trip time
Transport Transport In distributed MA, the O-MA is no different from a full
HoA HoA HoA HoA HoA HoA functioned MA for the MN once it has acquired and cached the
CoA CoA location management information to optimize routing. The
CN OMA MAG MN routing design from the CN to the MN for later packets is
Figure 7. Subsequent packets sent from the CN and tunneled to the MAG following the same design in migrating home agents. Therefore
showing the destination IP address as the packet. we may borrow the experimental results with migrating home
agents, for which the authors had already reported round trip
times approaching that as if the packets were sent directly
B. Sending packets from a mobile node (direct route) from CN to the CoA of MN.
The packets from a MN addressed to a CN may go through
the MA to preserve location privacy. Figure 8 shows the source B. Simultaneous move problem
IP address of such a packet, which is tunneled to the O-MA.
Because both the source and the destination nodes may be
This MA is the closest MA to which the MN is anchored to and
mobile, they may be changing their MA's at the same time. In
will then send the packet to the CN.
this case, the mobile node has moved from a previous MA to a

19
new MA while the correspondent node has also changed its O-
MA. The O-MA of the correspondent node may be using
outdated cache information to route packets to the previous D-
MA. The new D-MA needs to inform the previous D-MA to
forward these packets to the new D-MA. Meanwhile, the
previous D-MA may inform the O-MA to route any future
packets directly to the new D-MA.
VI. COMPARISON WITH OTHER DESIGNS
It is interesting to compare the distributed mobility anchor
with the mobility solution in cellular phone system. In GSM,
the home location register (HLR) keeps the full data of all the
subscribers to the home network. When a mobile phone is
visiting a different GSM network, it obtains service from a
visitor location register (VLR). VLRs are present in all other
GSM networks away from the home GSM network and are
usually co-located with the mobile switching center (MSC).
Within a network, there may be as many VLRs as MSCs.
Yet, HLRs may be physically separate and may be fewer in
number compared with the VLRs.
VLR does not copy all the information from HLR. It only
obtains the data from HLR on demand. The functions of HLR
and VLR in the GSM network are analogous to those of H-MA
and V-MA in mobile IP.
Session mobility is well supported in the cellular phone
system, which has a long history of performance and
scalability. It is capable of supporting session mobility not only
for using a phone number and other identifiers for a voice
session. Mobile IP is already using this same principle in the IP
network. Cellular phone system also needs a good design of
HLR and VLR to support handoff. The design of the
distributed mobility anchors is analogous to reproducing this
handoff design from the GSM in the IP network.
A. Other distributed mobility management designs
A distributed mobility management scheme had been
proposed [6] for future flat IP architecture consisting of access
nodes and without the mobility management hierarchy defined
in PMIPv6. The benefits of this design over centralized
mobility mangement have also been verified through
simulation [7].
The focus of distributed MA in this paper is on existing
PMIPv6 network. PMIPv6 has already been adopted in
WiMAX Forum and in 3GPP standards so that deployment is
expected in future. This paper retains the existing hierarchy of
PMIPv6 with MA and MAG with modifications requiring only
software upgrade.
Distributing the function of HA using a distributed hash
table structure had been proposed [8]. A lookup query will find
out where the location information is stored.
This paper distributes the location management function to
each H-MA in its home network only. Because each H-MA is
in charge of different IP prefix ranges, each V-MA can tell
from the MNs HoA which H-MA the HoA belongs to.
A similar design had been submitted to the IETF netext
working group. However the authors are not continuing the
20
proposal to netext so that the submitted draft [9] will expire and
will become unavaible. Instead, a related draft [10] has been
submitted to IETF to initiate discussions on distributed
mobility management (DMN), and an email discussion group
on DMN has also been set up in IETF.
VII. CONCLUSIONS
This paper proposes an architecture to distribute the
mobility anchors over different networks. The different
mobility anchors functions are defined by splitting and
modifying the full functions of the mobility anchors in
PMIPv6. The MR functions are available in multiple networks
whereas the location management information in different
networks form a distributed database system. Then one way to
achieve DMN is to modify the existing PMIPv6 in IETF. While
the distributed mobility anchors is applied to PMIP using MA,
the design should work equally well to MIP using HA.
Distributed mobility anchor is then not just for future network
but also becomes practical with existing network using PMIP
or MIP.
VIII. ACKNOWLEDGMENT
The author would like to thank F. Xia, J. Xiang, and H.
Ahmed for valuable discussions in this work.
REFERENCES
[1] C. Perkins, editor, IP Mobility Support for IPv4, IETF RFC 3344,
August 2002.
[2] D. Johnson, C. Perkins, and J. Arkko, Mobility Support for IPv6, IETF
RFC 3775, June 2004.
[3] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. Patil,
Proxy Mobile IPv6, IETF RFC 5213, August 2008.
[4] R. Wakikawa, G. Valadon, and J. Murai, Migrating Home Agents
Towards Internet-scale Mobility Deployments, Proceedings of the
ACM 2nd CoNEXT Conference on Future Networking Technologies,
Lisboa, Portugal. 4-7 December 2006.
[5] L. Zhang, R. Wakikawa, and Z. Zhu, Support Mobility in the Global
Internet, Proceedings of ACM Workshop on MICNET, MobiCom
2009, Beijing, China, 21 September 2009.
[6] P. Bertin, S. Bonjour, and J-M Bonnin, A Distributed Dynamic
Mobility Management Scheme Designed for Flat IP Architectures,
Proceedings of 3rd International Conference on New Technologies,
Mobility and Security, (NTMS 2008).
[7] P. Bertin, S. Bonjour, and J-M Bonnin, Distributed or Centralized
Mobility? Proceedings of Global Communications Conference
(GlobeCom 2009).
[8] M. Fisher, F.U. Anderson, A. Kopsel, G. Schafer, and M. Schlager, A
Distributed IP Mobility Approach for 3G SAE, 19th International
Symposium on Personal, Indoor and Mobile Radio Communications,
(PIMRC 2008).
[9] H. Chan, F. Xia, J. Xiang, and H. Ahmed, Distributed local mobility
anchors, IETF draft-chan-netext-distributed-lma-03, March 2010.
[10] D. Liu, Z. Cao, P. Seite, and H. Chan, Distributed mobility
management, IETF draft-liu-distributed-mobility-02, July 2010.