See

discussions, stats, and author profiles for this publication at: http://www.researchgate.net/publication/224208659

Implementation and Evaluation of Proxy Mobile

IPv6 in NS-3 Network Simulator
CONFERENCE PAPER JANUARY 2011
DOI: 10.1109/ICUT.2010.5677817 Source: IEEE Xplore

CITATIONS

5 AUTHORS, INCLUDING:
Hyon-Young Choi

Youn-Hee Han

Korea University

Korea University of Technology and Education

16 PUBLICATIONS 40 CITATIONS

97 PUBLICATIONS 597 CITATIONS

SEE PROFILE

SEE PROFILE

Jungsoo Park
Electronics and Telecommunications Resear
18 PUBLICATIONS 118 CITATIONS
SEE PROFILE

Available from: Youn-Hee Han

Retrieved on: 23 August 2015

Implementation and Evaluation of Proxy Mobile

IPv6 in NS-3 Network Simulator
Hyon-Young Choi , Sung-Gi Min , Youn-Hee Han , Jungsoo Park and Hyoungjun Kim

Department

of Computer and Radio Communication Engineering, Korea University, Seoul, South Korea
Email: {neongas, sgmin}@korea.ac.kr
School of Computer Science and Engineering, Korea University of Technology and Education, CheonAn, South Korea
Email: yhhan@kut.ac.kr
Standard Research Center, Electronics and Telecommunications Research Institute (ETRI), Daejeon, South Korea
Email: {pjs, khj}@etri.re.kr
AbstractWith the rapid growth in the number of mobile
subscribers and mobile devices, the demand high-speed Internet
access is becoming a primary concern in our lives. Not long ago,
the most stable and well known solution of IP-based mobility
management is Mobile IPv6 (MIPv6). Even if MIPv6 is a wellknown mature standard for IPv6 mobility management support,
however, it has revealed some problems such as handover latency,
packet loss, and signaling overhead. Thus, a new IPv6 mobility
management protocol called Proxy Mobile IPv6 (PMIPv6) is
being actively standardized by the IETF NETLMM Working
Group. Unlike the various host-based protocols such as MIPv6, a
network-based approach such as PMIPv6 has salient features and
is expected to expedite the real deployment of IP-based mobility
management. In this paper, we present an implementation of
PMIPv6 in NS-3 network simulator and the evaluation of the
simulation for validating.

I. I NTRODUCTION
The wireless network is increasing quickly with full growth
of wired network in communication market of recent times.
Equally, with the rapid growth in the number of mobile
subscribers and mobile nodes (MNs) such as cellular phone,
PDA (Personal Digital Assistant), and laptop computer, the
demand for the seamless mobility services such as VoIP (Voice
over IP), media streaming, is becoming one of the most
important issue in the mobility management.
Mobility management enables the serving networks to locate an MNs point-of-attachment for delivering data packets (i.e., location management), and to maintain an MNs
connection as it continues to change its point-of-attachment
(i.e., handover management). Nowadays the most stable and
well known solution for host-based mobility management is
Mobile IPv6 (MIPv6) that has been standardized by Internet
Engineering Task Force (IETF) [1].
However, even if MIPv6 is a well-known mature standard
for IPv6 mobility support, it has nevertheless revealed some
problems in terms of the various actuality aspects during the
past years. These are followed as below:
1) The MIPv6 specification is too complex to implement it
in MNs with limited resources;
2) A lot of signaling of MIPv6 adds overhead to wireless
access links;

3) Signaling overhead of MIPv6 causes MNs to consume

their battery power;
4) MIPv6s handover latency is very long;
5) The modification to an MNs IP stack is necessary,
since MIPv6 is a host-based mobility protocol.
IETF MIPSHOP Working Group published two mobility
supports protocols, Hierarchical Mobile IPv6 (HMIPv6) [2],
[3] and Fast Handovers for Mobile IPv6 (FMIPv6) [4], [5],
addressing the optimization of the handover procedure related
to MIPv6 mechanisms. But, such protocols also require the
modification to an MNs IP stack and do not reduce the waste
of the wireless link resources. No requirement for modification
of MNs is expected to accelerate the practical deployment of
IP-based mobility management protocols. Such an expectation
can be easily demonstrated by the fact that in the WLAN
switching market, no modification of the software on MNs
has been required to support IP mobility, so these unmodified
MNs have enabled network service providers to offer services
to as many customers as possible [6].
The network-based mobility management protocol called
Proxy Mobile IPv6 (PMIPv6) [7] is being actively standardized by the IETF NETLMM Working Group, and is starting
to attract much attention among the telecommunication community and internet community. Unlike the various existing
protocols for IP mobility management such as MIPv6, which
are host-based approaches, a network-based approach such as
PMIPv6 has salient features and is expected to expedite the
real deployment of IP mobility management.
The fundamental foundation of PMIPv6 is based on MIPv6
in the sense that it extends MIPv6 signaling and reuses many
concepts such as the home agent (HA) functionality. However, PMIPv6 is designed to provide network-based mobility
management support to an MN in a topologically localized
domain. Therefore, an MN is exempted from participation in
any mobility-related signaling, and the proxy mobility agent
in the serving network performs mobility-related signaling on
behalf of the MN. Once an MN enters its PMIPv6 domain and
performs access authentication, the serving network ensures
that the MN is always on its home network and can obtain its
home address (HoA) on any access network.

978-1-4244-8811-7/10/$26.00 2010 IEEE

MN

MAG
MN Attachment

AAA Server

LMA

CN

AAA Query with MN-ID

AAA Reply with Profile
PBU with MN-ID
PBA with MN-ID, Home Network Prefix option

RA**

Tunnel Setup
[Proxy-CoA:LMAA][MN-HoA:CN](data)

[MN-HoA:CN](data)

[MN-HoA:CN](data)

Fig. 2.

Fig. 1.

Message flow in PMIPv6

Overview of PMIPv6

In this paper, we present an implementation of PMIPv6

in NS-3 network simulator (NS-3) [8] and the evaluation of
the simulation for validating. NS-3 is a new simulator that is
intended to eventually replace the aging NS-2. Even though
NS-2 still has a greater number of models included in the
distribution, NS-3 has a good development momentum and
is believed to have a better core architecture, better suited to
receive community contributions. In addition, it is reportedly
[9] one of the better performing simulation tools available
today.
The rest of this paper is organized as follows. In Section 2
and Section 3, we provide the overview of the representative
network-based approach (i.e., PMIPv6) for IP mobility support
and the overview of the NS-3 network simulator, respectively.
In Section 4, we explain the implementation of PMIPv6 in
NS-3 in detail, and the description of the simulation and the
results is presented in Section 5. Finally we conclude the paper
with a summary of results in Section 6.
II. PMIP V 6 OVERVIEW
In PMIPv6, the serving network controls mobility management on behalf of the MN; thus, the MN is not required
to participate in any mobility-related signaling. The primary
features of PMIPv6s goals are as follows:
1) Support for unmodified MNs: Unlike MIPv6, a networkbased approach should not require any software update
for IP mobility support on MNs.
2) Support for IPv4 and IPv6: Although the initial design
of a network-based approach uses an IPv6 host, it is
intended to work with IPv4 or dual-stack hosts as well.
3) Efficient use of wireless resources: A network-based approach should avoid tunneling overhead over a wireless
link; hence, it should minimize overhead within the radio
access network.
4) Handover performance improvement: A network-based
approach should minimize the time required for
handover.
Fig. 1 illustrates an overview of how PMIPv6 works within
a localized domain. The brief descriptions of the basic terminology are also shown in the figure.
The new principal functional entities of PMIPv6 are the
mobile access gateway (MAG) and local mobility anchor

(LMA). The MAG typically runs on an access router (AR).

The main role of the MAG is detecting the MNs movements
and initiating mobility-related signaling with the MNs LMA
on behalf of the MN. In addition, the MAG establishes a
tunnel with the LMA for enabling the MN to use an address
from its home network prefix and emulates the MNs home
network on the access network for each MN. On the other
hand, the LMA is similar to the HA in MIPv6. However, it
has additional capabilities required to support PMIPv6. The
main role of the LMA is to maintain reachability to the MNs
address while it moves around within a PMIPv6 domain, and
the LMA includes a binding cache entry for each currently
registered MN. The binding cache entry maintained at the
LMA is more extended than that of the HA in MIPv6 with
some additional fields such as the MN-Identifier, the MNs
home network prefix, a flag indicating a proxy registration,
and the interface identifier of the bidirectional tunnel between
the LMA and MAG. Such information associates an MN with
its serving MAG, and enables the relationship between the
MAG and LMA to be maintained.
Fig. 2 shows the message flow of the overall operations in
PMIPv6. Each step shown in Fig. 2 is described as follows:
1) Step 1: An MN first attaches to an access network
connected to the MAG.
2) Step 2: The access authentication procedure is performed using an MNs identity (i.e., MN-Identifier) via
the deployed access security protocols on the access
network.
3) Step 3: After successful access authentication, the MAG
obtains the MNs profile, which contains MN-Identifier,
LMA address, supported address configuration mode,
and so on from the policy store.
4) Step 4: The MAG sends a proxy binding update (PBU)
message including the MN-Identifier to the MNs LMA
on behalf of the MN.
5) Step 5: Once the LMA receives the PBU message, it
allocates an appropriate home network prefix for the
MN.
6) Step 6: The LMA sends a proxy binding
acknowledgment (PBA) message including the MNs
home network prefix option, and sets up a route for
the MNs home network prefix over the tunnel to the
MAG.

h
pT
u

uT

w]tV
w]s

t
j

|y

pT

ccee

i|sV
ij

ccee

p]tk

Fig. 3.

o
ccee

p]tih

The main NS-3 modules

p]ti|
p]ts[w

Unlike MIPv6, a tunnel in PMIPv6 is established between

the LMA and the MAG, and not an MN. This could be desirable because the tunneling increases the bandwidth constraints
on the wireless link and the processing burden on the MN.
Once the MAG receives the PBA message from the LMA,
it has obtained all the required information to emulate the
MNs home network on the access network, and it then starts
to send a router advertisement (RA) message to the MN.
After receiving the RA message, the MN configures its home
address by combining the home network prefix included in
the RA message and its interface identifier, which is based
on the supported address configuration mode (e.g., stateless
or stateful address configuration mode) from the policy store.
It must be noted that since PMIPv6 only supports the perMN prefix model and not the shared-prefix model, a unique
home network prefix is assigned to each MN. Therefore, the
MN always obtains its unique home address while it moves
within a PMIPv6 domain. After the bidirectional tunnel is
successfully set up, all traffic sent from the MN gets routed
to its LMA through the tunnel. The LMA receives any data
packets sent by the correspondent node (CN) to the MN. The
LMA forwards the received packet to the MAG through the
tunnel. After receiving the packets, the MAG on the other
end of the tunnel removes the outer header and forwards the
packets to the MN.
III. NS-3 N ETWORK S IMULATOR OVERVIEW
NS-3 is organized with a set of modules, as shown in Fig.
3. The core module provides additional C++ syntactic sugar
to make programming easier, such as smart pointers [10], rich
dynamic type system, COM-like [11] interface query system,
callback objects, and runtime described object attributes.
Other modules in NS-3 include common, containing data
types related to the manipulation of packets and headers, and
the simulator module, containing time manipulation primitives
and the event scheduler. The node module sits conceptually
above the previous modules and provides many fundamental
features in a network simulator, such as a Node class, an
abstract base class for a link-layer interface (NetDevice),
and several address types. The mobility module contains an
abstract base class for mobility models. A MobilityModel
object may be aggregated with a Node object to provide the
node with the ability to know its own position.
NS-3 also contains a module internet-stack implementing
a UDP/TCP/IPv4/IPv6 stack, and few NetDevice implementations including WiFi, CSMA, and PointToPoint. Although
there is no concrete concept of operating system or system call,

ccee

p]{s[w

toV
so

ccee

p]sZw
p]sy
p]zy
p]zzy

{uk
~uk

ccee

uT
~t

juk
o

p]to

p]ti|o
p]tiho
p]tvo

Fig. 4.

Major PMIPv6 classes in NS-3

application module provides a form of user-level application

using Linux-like socket interface. Finally, a helper module is
on the side of other modules. This module provides a set of
very simple C++ classes that do not use pointers and wrap the
existing lower level classes with a more programmer-friendly
interface.
IV. I MPLEMENTATION OF PMIP V 6 IN NS-3 N ETWORK
S IMULATOR
In implementing PMIPv6 in NS-3, we focused on the integration with newer version of NS-3 because NS-3 is at an early
stage and the cycle of releasing new stable version is fast. To
minimize the module dependency with the existing modules,
we added new code as possible, even if the existing code is
reusable. In addition, we defined the minimal part of MIPv6
such as mobility headers and these handler classes because
current NS-3 release does not have MIPv6 implementation
yet.
We depicted the major PMIPv6 classes with the match
of the module classification in NS-3 in Fig. 4. White boxes
mean classes which are already providing in NS-3 and gray
boxes are newly defined classes for PMIPv6 implementation.
Rounded box refers the part of NS-3 modules.
There are three boxes which have two class names together.
These mean that upon the role of the model such as the MAG
or the LMA, either of two class names has relations with
other classes. For example, in case of the MAG, Pmipv6Mag,
BindingUpdateList, and MagHelper have relations with others.
PBU, PBA and many option headers inherited from Header
class are defined in common module. Node class in node

w]t

OX`PGowihOP

RwOP
RnzzOP
RzOP
RkOP

p]tih
p]tk
OX^P

p]to
Tw
Ts
T{
T
T

tvm
Tk
Tv
RzOP
RkOP
RhvOP
TjwOP

XGGGGQ

p]tvo
T
T
RnhOP

OX]PGnt OP

uk
~GGG
Gthn

p]ts[w

OXXPGzOP

w]s

OX\PGyOP

p]sZw

OXWPGowi|OP

p]ti|

OX[PGyOP

p]tvt
Tupo

O`PGwOP

uaawo

p]tk
O_P

OXZPGj

p]tiT
|o
T
Th
To
Ts
Tw
T

p]tiT
ho

T
Tw
T
T

O]PGyOP

uk

p]sZw

OZPGzOP

p]tvT
opo

p]tvh
T{{o

O\PGyOP

p]sZw
OYPGzOP

w]t

uaawo
~GGG
Gsth

O[PGj

uk

OXPGuj

~t

Fig. 6.
Fig. 5.

p]ts[w O^PGntOP

uk
p]tvoT
uwo

OXYPGzOP

p]sZw

OX_PGwOP

Process of binding update

Class diagram of packet headers

module manages all applications and net-devices as lists.

Various types of net-devices in net-device module can exist in
a node. TunnelNetDevice is a virtual net-device for tunneling
data packets between the LMA and the MAG. UnicastRadvd in
application module is a variance of Radvd application, which
sends RA message to the specific MN only.
Classes in the internet-stack module such as
Ipv6L3Protocol, Ipv6MobilityDemux, Pmipv6Mag, and
Pmipv6Lma are aggregated to the Node class. Ipv6L3Protocol
is the main network layer control class. It manages upper layer
protocols and passes the packet to the right transport layer
protocol matched with the next-header field in IPv6 header.
Two transport layer protocols are defined in the figure, which
are Ipv6MobilityL4Protocol and Ipv6TunnelL4Protocol.
Ipv6MobilityL4Protocol handles mobility packets such as
PBU and PBA packet, and Ipv6TunnelL4Protocol handles
IPv6-in-IPv6 tunneling packets. Ipv6L3Protocol also contains
routing manipulate classes. In NS-3, default routing protocol
is Ipv6ListRouting, which can manage many routing protocols
with priority basis. Ipv6StaticRouting class is used for basic
routing query and Ipv6StaticSourceRouting is used for source
address based routing query.
Ipv6MobilityDemux
class
de-multiplexes
mobility
packets to the matched handler class such as
Ipv6MobilityBindingUpdate and Ipv6MobilityBindingAck.
Pmipv6Mag or Pmipv6Lma class is PMIPv6 agent installed
in the MAG or the LMA, respectively. It handles binding
process related messages.
To provide simple and easy way of initializing and setting
up the classes to users, we defined two helper classes in helper
module which are MagHelper and LmaHelper. Using these
classes, user can setup all objects within only one or two
function calls.
A. Packet Headers
PMIPv6 utilizes mobility header of MIPv6 with additional
P flag in header field and many newly defined options such
as Home Network Prefix option, Handoff Indicator option,

Access Technology Type option, and so on. Class diagram

of packet headers is shown in Fig. 5.
All headers including option headers are derived from
Header class. The most important methods of Header class
is Serialize() and Deserialize(). Serialize() method makes
realistic packet format from stored values in the class variables
and Deserialize() method, in reverse, fills the variables in the
class from the packetized data. Print() method is used for
displaying the header information in text format for trace and
GetSerializedSize() method should return the number of bytes
of the header data in forms of realistic packet format.
Ipv6MobilityHeader
class
is
base
class
for
Ipv6MobilityBindingUpdateHeader
and
Ipv6MobilityBindingAckHeader. As the same as mobility
header definition, Mobility options also have the common
base class of Ipv6MobilityOptionHeader and are derived from
it.
Mobility Headers inherit MobilityOptionField class as well.
This class has a role of managing all options included in
the mobility header and calculating the padding to make
sure that the whole mobility header packet size is multiple of 8-octets. CalculatePad() method is used for padding
mechanism with the help of GetAlignment() method in
Ipv6MobilityOptionHeader whenever new option is added
by AddOption() method. GetAlignment() function returns the
information of padding rule [1].
B. Binding Update Processing
Binding update process begins with the attachment event of
an MN from link-layer and ends with the completing the local
configuration such as tunneling and routing after receiving
PBA message from the LMA as a response of PBU message.
Fig. 6 shows the process of binding update.
As Wifi module is used for wireless environment, WifiMac
can notice the attachment of a MN and it notifies to the
Pmipv6Mag. Pmivp6Mag initializes binding update list and
sends PBU packet to the LMA.
Sent IPv6 packets from upper protocols are handled by
IPv6L3protocol. It passes the packet to the proper net-device

kGGGGGGOjuGGtuP

uk
O^PGzOP

p]sZw

oGuGwGy
ZaXa[aXaaV][GG
ZaXa[aaaV][

OX[PGzOP

ZaYaaYV][
_WaaYWWaaWWaY

ZaXaaXV][
_WaaYWWaaWWaZ

OXZPGzOP

p]{s[w
thnX

p]zzy

thnY
ZaXaaYV][
_WaaYWWaaWWa[

OZP ypOP
O[P pmOP

~GGG
GukG
GGG
GsthGGthn

p]zy
OZP ypOP
O[P pmOP

p]zy
p]sy

O\PGzOP

p]sZw
OZPGypOP

OXYPGyOP

OXXPGskOP

p]sZw

O`PGyOP

uaawo

uaawo

uk

ZaXaaZV][
_WaaYWWaaWWa\
o|i

ZaXaYaaXV][
_WaaYWWaaa

hwX

hwY

OXWPGypOP

OYPGyOP

OXPGj

ZaXaXaaXV][
_WaaYWWaaa

OXWP ypOP
OXXP skOP

p]sy
O[PGpmOP

ZaYaaXV][
_WaaYWWaaWWaX

p]sZw

O]PGzOP

{uk

ju

sth

uk

O_PGj

uk

tGOYWVP

tu

ZaXa[aXaYWWaaWWaV][
_WaaYWWaaWWa

kGGGGGOjuGGtuP

Fig. 8.
Fig. 7.

Simulation topology

Process of data packet between the LMA and the MAG

for the destination after routing query. Once an IPv6 packet

is arrived the net-device of the other node, it is delivered to
the Ipv6L3Protocol through ProtocolHandler in Node class.
Then, Ipv6L3Protocol checks the IPv6 next-header field in
the packet, and passes to the right transport handler. As
a result, PBU packet arrived at the LMA is handled by
Ipv6MobilityL4Protocol.
Ipv6MobilityL4Protocol de-multiplexes the packet to
the Ipv6MobiltiyBindingUpdate based on mobility header
type in PBU packet. Because PBU packet is P flag
on, Ipv6MobilityBindingUpdate passes the packet to the
Pmipv6Lma. Pmipv6Lma handles PBU packet with creating/updating binding cache and setting up tunneling and routing. After processing PBU packet successfully, PBA packet
is delivered to the Pmipv6Mag as the similar process as PBU
packet delivery. Pmipv6Mag completes binding update list and
finishing the setting of tunneling and routing.
C. Data Processing
After binding update process completed, bidirectional tunnel
between the LMA and the MAG is established and proper
routing entries are inserted both the LMA and the MAG. From
this moment, the MN can exchange data with a CN. Fig.
7 shows how data packets are processed through the tunnel
between the LMA and the MAG.
When a data packet is arrived at the LMA or the MAG, it
is passed to Ipv6L3Protocol. Ipv6L3Protocol performs routing
query for incoming packet by calling RouteInput() method of
Ipv6ListRouting. Ipv6ListRouting performs subsequent routing query to Ipv6StaticRouting. Ipv6StaticSourceRouting can
be used for routing query if it exists.
Because the packet is towards the CN or the MN, the result
of routing query is forwarding the packet to the tunnel, that
is, out-going net-device is TunnelNetDevice. In TunnelNetDevice, the packet is encapsulated with another IPv6 header
towards the opposite node between LMA and MAG, and is
sent.
On the opposite node, tunneled data packet is arrived at
the Ipv6TunnelL4Protocol as a result of LocalDeliver() in

routing query. Ipv6TunnelL4Protocol decapsulates the packet

and passes it to Ipv6L3Protocol. Then the packet is finally
delivered to the CN or the MN.
V. S IMULATION AND R ESULTS
We have performed the simple simulation for validating the
basic operation of PMIPv6 implementation. NS-3 3.8 is used
for the simulation with IEEE 802.11 network environment.
The network topology for the simulation is shown in Fig. 8.
The CN is directly attached to the LMA, and the LMA
manages two MAGs. Wired link speed is 50 Mbps, and the
link delay, except for the link between the CN and the LMA,
is 2ms. The link delay between the CN and the LMA is
10ms. MNs address is assigned automatically with stateless
auto-configuration based on RA message from the MAG. In
order not to change MNs default gateway after receiving RA
message, all MAGs MAC addresses on the edge network
are unified to 00:00:AA:BB:CC:DD. Therefore, the same
link-local address is assigned as shown in Fig. 8. The MN is
moving from the MAG1 to the MAG2 with the speed, 20m/s,
while communicating with the CN. CBR over UDP with 10ms
inter-packet delay and 1 kbyte packet size is used for data
traffic.
Fig. 9 and Fig. 10 are parts of PCAP trace file PCAP is a
binary format for storing (usually live captured) packets, used
by programs such as wireshark and tcpdump. To check that
the handover procedure in PMIPv6 is performed correctly, we
focused on the moment of handover.
Fig. 9 shows the packet trace of handover in the MN. The
MN tries to find APs by sending Probe Request at 5.393847s
because it is disconnected from MAG1s AP. Then, it performs
association process with the first responder of Probe Request
which is MAG2s AP. The second responder, which is MAG1s
AP, is ignored.
We can notice that handover procedure in the MAG2 is
started after receiving Association Request from the MN. After
exchanging PBU and PBA message between the MAG2 and
the LMA, the MAG2 starts to send RA message to the MN if
binding update is succeeded. At 5.410915s, there is first RA
message.

390

380

Sequence

5.3849s

Fig. 9.

PCAP trace of handover in the MN

370

360

350
5.2

Fig. 11.

Fig. 10.

PCAP Trace of binding update process in the LMA

For the data traffic, the last data packet before handover
occurred is at 5.384772s, which is the second line in the figure.
During handover, there are two more data packets from the
previous AP but they are ignored. And the first data packet
from MAG2s AP is at 5.423765s.
Fig. 10 shows the packet trace of binding update process in
the LMA. It might show MIPv6 message but we can check the
P flag is on. From the figure, binding update is successfully
processed between the MAG2 and the LMA.
To figure out the handover latency and packet drops, we
put additional sequence number in UDP data. Fig. 11 shows
the received sequence number of packets in MN. The received
time in the figure is at UDP application, not link-layer.
We define handover latency as the time difference between
the last packet in previous MAG and the first packet in new
MAG. In Fig. 11, the last packet is at 5.3849s and the first
packet is at 5.42389s. Therefore handover latency in this case
is 38.99ms. And the lost packets are three in total.
It should be noted that IEEE 802.11 MAC implementation
in NS-3 3.8 cannot scan APs over other channel. As channel
for AP1 and AP2 is the same, the handover latency is not
included channel scanning time.
VI. C ONCLUSION
PMIPv6 could be considered as the next-generation standard
protocol from the perspective of the practical deployment. Currently, 3GPP and WiMAX consider PMIPv6 as a promising
alternative of MIPv6.

5.42389s

5.25

5.3

5.35

5.4
Time(s)

5.45

5.5

5.55

5.6

Packet sequence diagram during handover in the MN

In this paper, we have implemented PMIPv6 in NS-3

network simulator. NS-3 is a new simulator that is intended
to eventually replace the aging NS-2 simulator. NS-3 has
good development momentum and better features comparing
to other simulations including NS-2. Especially PCAP trace
file based on realistic packets is remarkable. We performed
simulation in IEEE 802.11 wireless network environment
for testing the PMIPv6 operation and its performance. The
simulation result showed this implementation works well and
the handover latency is very short.
ACKNOWLEDGEMENTS
This research was supported by the ICT Standardization program of MKE(The Ministry of Knowledge Economy) (2010-P1-09, Development of Multi-Network Technology Standards using IPv6-based Multihoming)
R EFERENCES
[1] D. B. Johnson and C. E. Perkins and J. Arkko, Mobility Support in IPv6,
IETF RFC 3775, June 2004.
[2] C. Castelluccia, HMIPv6: A Hierarchical Mobile IPv6 Proposal, ACM
Mobile Computing and Communications Review, Vol. 4, No. 1, pp. 4859, January 2000.
[3] H. Soliman and C. Castelluccia and K.-E. Malki and L. Bellier, Hierarchical Mobile IPv6 Mobility Management (HMIPv6), IETF RFC 4140,
August 2005.
[4] L. Dimopoulou and G. Leoleis and I.O. Venieris, Fast Handover Support
in a WLAN Environment: Challenges and Perspectives, IEEE Network,
Vol. 19, No. 3, pp. 14-20, May-June 2005.
[5] Rajeev Koodli, ed., Fast Handovers for Mobile IPv6, IETF RFC 4068,
July 2005.
[6] J. Kempf, and ed., Goals for Network-Based Localized Mobility Management (NETLMM), IETF RFC 4831, April 2007.
[7] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. Patil,
Proxy Mobile IPv6, IETF RFC 5213, August 2008.
[8] NS-3 network simulator hompage, http://www.nsnam.org.
[9] E. Weingartner, H. vom Lehn, and K. Wehrle. A Performance Comparison
of Recent Network Simulators, In Proceedings of the IEEE International
Conference on Communications 2009 (ICC 2009), June 2009.
[10] D. Edelson, Smart Pointers: Theyre smart, but theyre not pointers,
University of California, Santa Cruz, Computer Research Laboratory,
1992.
[11] D. Box, Essential COM, Addison-Wesley, 1998.