This paper was presented as part of the Mobility Management in the Networks of the Future World (MobiWorld) Workshop at

A Design of Network-based Flow Mobility based on

Proxy Mobile IPv6
Tran Minh Trung (1), Youn-Hee Han (2), Hyon-Young Choi (3), Hong Yong Geun (1)
(1) Electronics and Telecommunications Research Institute Standards Research Center (email: [email protected])
(2) Korea University of Technology and Education (email: [email protected])
(3) Korea University (email: [email protected])

Abstract—Supporting flow mobility is an emerging challenge in this solution by providing flow mobility capability [10]. The
today mobile networks. This paper introduces a network-based IETF Mobile Extension (MEXT) working group is now also
solution to support flow mobility. It requires minimum finalizing a flow binding protocol for MIPv6 [8].
modification at the mobile node. All signaling processes are
performed by the network. The mobile node can seamlessly All of the above solutions are host-based protocol. They
switch flow over multiple access technologies while maintaining require the mobile node to be modified to involve in mobility
ongoing connections. management process. A massive amount of software logic and
PMIPv6, network-based flow mobility, logical interface system resources are required on the mobile node which has a
limitation energy and resource. To avoid this limitation, the
I. INTRODUCTION network-based mobility management, Proxy Mobile IPv6
The number of mobile subscribers today is increasing (PMIPv6) [1] is a better choice since it has many advantages
rapidly. The traffic demand of mobile subscribers now is not as analyzed in [11].
only for voice and SMS service but also for the high-speed In this paper we focus on network-based flow mobility
internet access services such as Video streaming, IPTV, and solutions. First we analyze the technical challenges to support
Game … To adapt with this exponential growth of traffic flow mobility and show the limitations of existing solutions.
demand, operators are looking for a solution to extend the Then we introduce our novel solution with performance
network capacity. Since the WiFi hotspots, a cheap access evaluation results.
technology, is available everywhere and co-existing with other
expensive access networks such as 3GPP, LTE and WiMax, II. PROBLEM STATEMENTS
the cheapest way is to comprise WiFi with various
heterogeneous access networks to realize global accessibility A. Network-based flow mobility
and converge diverse networking resources together to satisfy Flow mobility is an extension of IP mobility, a well known
the mobile subscribers’ traffic demands. IETF standard communication protocol [7]. It allows moving
Most of the mobile nodes today are equipped with multiple selected flows from one network to another in mid-session
interfaces using different access technologies such as WiFi, without any interruptions while keeping the other flows on the
WiMax, and LTE … To best utilize this capacity the network current network. Figure 1 shows an example in which the
should be extended to support simultaneous connections from mobile node equipped with two interfaces, WIFI and 3GPP.
multiple interfaces of the mobile node. It also has to be able to At first time the mobile user transfer both voice and video
optimize the data distribution over multiple interfaces. For flow via 3GPP interfaces. When the mobile user moves from
example, mobile node equipped with two interfaces using two 3GPP service area to the overlapping area of 3GPP and WIFI
different access technology, 3GPP and WiFi. At the beginning network, the video flow can be moved to WIFI interface in
it is walking in the 3GPP zone and using voice and video order to get higher bandwidth while the voice flow is still
streaming services [fig.1.a]. Then it moves to an overlapping transferred via 3GPP interface. The key advantage of network-
zone of the 3GPP and WiFi networks [fig1.b]. Since the WiFi based mobility management is that it does not require any
can support higher bandwidth, the operator decides to modification of the MN. The network will perform mobility
seamlessly move the video streaming from 3GPP to WiFi management on behalf of the mobile node. The client just
network to provide better connection for video traffic and also involves in minimal proportions. This design results in a
to reduce the traffic load on 3GPP network. simple mobile device with minimal software requirements. It
was standardized by IETF in PMIPv6 [1], and also adopted in
Several solutions are proposed to gain this goal. The 3GPP
3GPP and WiMAX architecture. There was many extensions
released 8 introduces a client-server based protocol to enable
of the network-based mobility management are being planned.
seamless handover between 3G and WiFi. It was developed
One of them is the network-based flow mobility management
basing on Dual Stack Mobile IP, which is a mobility protocol
stated in the re-charter of the NETEXT working group
specified in the IETF RFC5454. The QUALCOMM enhances

This research was supported by the ICT Standardization program of

MKE(The Ministry of Knowledge Economy), and also supported by the IT
R&D program of MKE/KEIT [10035245: Study on Architecture of Future
Internet to Support Mobile Environments and Network Diversity].

978-1-4244-9920-5/11/$26.00 ©2011 IEEE 373

 (a) (b)
Figure 1: IP flow mobility

description of the logical interface. It will be used by the

B. Technical challenges mobile node to support network-based flow mobility.
The PMIPv6 [1] allows mobile nodes to connect to the
network through multiple interfaces for simultaneous access. The important work left is how to extend the PMIPv6 to
support shared-prefix model and flow-based routing capability.
The Mobile Node (MN) can send and receive simultaneously
Some solutions [3-6] were proposed for these technical
packets to the PMIPv6 domain over multiple interfaces.
requirements. The internet draft [4], a combined version of [5]
However it cannot performs flow mobility due to some and [6], specified a protocol between the Local Mobility
limitations: Anchor (LMA) and Mobile Access Gateways (MAGs) for
• The PMIPv6 can only support IP mobility: In PMIPv6, distributing specific traffic flows on different interfaces. The
when the mobile node performs handover from a network authors considered two possible scenarios. Based on that, they
to another, all of the IP flows are moved to the new specified the signaling messages for each scenario to support
network. However, the flow mobility requires to support flow mobility. In this document the author did not specify the
moving just some of the selected flows to the new procedure for the LMA to support shared-prefix model. In
network, while the other flows are kept transmitting on addition, they requested the LMA to send the flow policy to
the old one. the MAG. It was considered as a redundant action since the
• The PMIPv6 can only support unique prefix(es) per MAG is only hosting the prefixes that the LMA intends to
interface model: Basically, a home network prefix (HNP) assign to the MN. It has no control on the MN. All of the
can only be assigned to a single interface at one time. flows forwarding decisions are decided by the LMA.
However in a real system, multiple flows can be
associated with a HNP. When the flow mobility occurs, III. PROPOSED SOLUTION
some of these flows are moved to a new interface, while In this paper we solve the limitations of the existing
the other flows are kept transmitting via the old interface.
solutions by providing solutions for supporting shared-prefix
To keep the sessions continuing the HNP should be
model and flow-based routing at the network side. The
preserved during the movement of the flows. It means
that the HNP should be able to be assigned proposed solutions did not require the LMA to send any flow
simultaneously to multiple interfaces. policies to the MAG. The proposed scheme also adopted the
flow binding results in MEXT WG [8] to enable the LMA to
• The PMIPv6 does not support flow-based routing: support flow-based routing without any complicated
Normally, the network can only route a packet at IP-based requirement at both MN and network side.
level. However to route packet at flow-based level it
should be able to classify the packets at flow level and A. Shared-prefix model support
then apply the same policy to the packets that has the In shared-prefix model, a HNP can be assigned
same flow information simultaneously to multiple interfaces. To do that the PMIPv6
can be extended in two ways, proactive and reactive signaling
C. Related works approaches.
To support flow mobility in PMIPv6, the re-charter of the 1) Pro-active signaling
IETF NETEXT working group allows the mobile node to use
logical interface to hide the actual usage of physical interface To support flow mobility, HNP is shared across
from the IP layer. An informational document [2] was attachments immediately when it is assigned to the MN. When
approved as working group document to provide a detailed the LMA assigns a new HNP to the MN, it will immediately
signal this HNP to the entire MAGs to which the MN attaches.

374
 Figure 2: Call flow of pro-active signaling Figure 3: Call flow of re-active signaling
By doing this, the HNPs assigned to the MN are always shared With this approach, the implementations need two
across its attachments in advance. Therefore the LMA can extensions:
move flows from an attachment to another in a free manner
without any extra signaling messages. • Extend the PBA message to include both the new HNP
assigned to new attachment and the old HNP that are
Figure 2 shows signaling call flow of the proactive signaling already assigned to the current MN's attachments.
approach.
• Extend the MAG and LMA to enable them to
• Step 1: The MN attaches to the MAG1 using the physical exchange HUR and HUA.
interface IF1. The network assigns HNP1 to the IF1.
2) Re-active signaling
• Step 2: The MN performs new attachment via the
physical interface IF2. With the re-active signaling approach, an HNP is shared
with another attachment only when a flow is moved to an
• Step 3: The MAG sends a Proxy Binding Update (PBU) attachment which the HNP associated to that flow is not valid.
message with the handoff indicator (HI) value of 1 to When the LMA decides to move a flow and realizes that the
inform the LMA. If the LMA recognizes that the MN can HNP used by that flow is not valid on the destination MAG, it
support flow mobility, it will assign both the new HNP2 will signal the HNP to that MAG. By doing this, an HNP will
and the old HNP1 to the new attachment. Upon accepting be shared on the destination MAG only when the flow
this PBU message, the LMA sends a Proxy Binding associating with it is moved to a destination MAG that it is not
Acknowledgement (PBA) message including both of the valid. Figure 3 shows the signaling call flow of re-active
HNP1 and HNP2 to the MAG2. signaling approach.
• Step 4: The LMA signals MAG1 to update with the new • Step 1: The MN attaches to the network using 2 interfaces,
HNP2 by sending a Home Network Prefix Update IF1 and IF2. The network assigns HNP1 to the IF1 and
Request (HUR) to the MAG1. When receiving the HUR HNP2 to the HNP2. The flow 1 is forwarded by the
message, the MAG1 setups a tunnel and a routing path for MAG1 and uses HNP1.
the HNP2 and sends back a Home Network Prefix Update
Acknowledgement Message (HUA) to inform the LMA • Step 2: The LMA decides to move flow 1 to the MAG2,
that it is ready to forward the packets of the HNP2. and signals MAG2 to update with the HNP1 by sending a
HUR message to the MAG2. On receiving the HUR
After the above steps, both MAG1 and MAG2 can forward message, the MAG2 setups a routing path for the HNP1
any packets of flows associated with the HNP1 as well as and sends back a HUA message to inform the LMA that it
HNP2. Therefore the LMA can move flows between two is ready for forwarding the packets of HNP1.
attachments freely without any extra signaling messages. For
example the LMA can move the flow 1, which uses HNP1, • Step 3: After receiving HUA from the MAG2, the LMA
from MAG1 to MAG2 immediately because the MAG2 is updates the flow binding table to move the flow 1 from
already enabled to forward the packets of the HNP1. MAG1 to MAG2.

375
 BID MN-ID ATT HNP Proxy-CoA FID TS BID Action Mode
1 MN1 3GPP HNP1 IP1 (MAG1) 1 TCP (Flow1) 1 Forward Active
2 MN1 WiFi HNP2 IP2 (MAG2) 2 UDP 2 Forward Inactive
(a) The MN attaches with MAG using two interfaces (a) Before the flow mobility occurs
BID MN-ID ATT HNP Proxy-CoA FID TS BID Action Mode
1 MN1 3GPP HNP1 IP1(MAG1) 1 TCP (Flow1) 2 Forward Active
2 MN1 WiFi HNP1,2 IP2(MAG2) 2 UDP 2 Forward Inactive
(b) After the LMA receiving HUA (b) After the LMA decides to move TCP flow 1 to the MAG2

Figure 5: Binding Cache Entry Figure 4: Flow binding table

The key difference between proactive and reactive approach is C. Protocol operations
that in the case of the re-active approach, the HNPs assigned 1) Local Mobility Anchor Operation (LMA)
to the MN is not shared across attachments in advance. Each
attachment will be assigned with a unique HNP as described The LMA operation is extended for exchanging the HUR/and
in the PMIPv6 standard [1]. The HNP1 is shared on the HUA messages with the MAG. The LMA will send HUR
MAG2 only when the flow1, which is associated with the message to the MAG whenever it discovers out that the MAG
HNP1, is moved to the MAG2. need to be updated with new HNPs. The following sub-
With the re-active approach, the implementations need only section discusses more detail about the extended operations at
to extend the MAG and LMA to enable them to exchange HUR the LMA.
and HUA when the flow mobility occurs.
• Sending HUR: When a HNP is needed to be shared on a
MAG, the LMA will send an HUR message including the
B. Flow-based routing HNP to that MAG to request it to setup a tunnel and
update the routing path for the HNP. Depending on the
To support flow-based routing the LMA should be able to
way of implementation, proactive or reactive signaling
bind a particular flow to a Proxy-CoA without affecting other
approach, the trigger for sending an HUR message is
flows associating with the same HNP. To do that, we need to different. With proactive signaling approach, the HUR
perform the extensions as follows: will be initiated whenever a new HNP is assigned to the
1) Multiple Care-of Address registration: MN. In contrast, with the reactive signaling approach, the
HUR will be initiated only when the LMA decides to
The LMA is extended to allow a mobile node to register move a flow and the HNP used by that flow is not valid
multiple proxy care of address (Proxy-CoA), which is the same on the destination MAG.
situation as described in the RFC 5648. The LMA maintains
multiple binding cache entries for a MN. The number of • Receiving HUA: After sending HUR, the LMA waits for
binding cache entries of a MN is equal to the number of the the HUA from MAG. On receiving the HUA, the LMA
MN’s interfaces attaching to the MAG. Figure 4.a shows two updates binding cache to bind the HNP to an extra Proxy-
binding cache entries of the MN1. Each entry is representing CoA. Figure 4 shows the Binding Cache Entries of the
for a MN’s interface and associates with a Proxy-CoA. MN1 before and after the LMA receiving HUA message
from the MAG2. In the figure 4.a the HNP1 is bounded
2) Shared-prefix model support: only to the IP1 of MAG1. After the LMA sends HUR to
With the extensions described in the previous section, the LMA request the MAG2 to update with the HNP1, the HNP1 is
can bind a HNP to multiple Proxy-CoAs (MAGs). Figure 4.b now bounded to the IP2 of the MAG2 as showed in the
shows that, on receiving HUA from MAG2, the LMA updates figure 4.b.
the corresponding entry record to bind the HNP1 to the Proxy- • Moving a flow: When the LMA decides to move a flow, it
CoA IP2 of the MAG2. The HNP1 is now shared between first checks whether the HNP used by that flow is valid on
MAG1 and MAG2. the destination MAG or not by checking the existing
3) Flow binding support: binding cache entries of the MN. If it is valid, the LMA
just updates the flow binding cache entry list with new
Each LMA maintains a flow binding table [fig.5]. Similar to BID. If it is not valid the LMA sends HUR message to
flow binding described in [8], each flow binding entry points to request the destination MAG to update with the HNP
a specific binding cache entry identifier (BID). When the LMA used by the flow. After that, if the MAG sends an HUA
decides to move a flow, it simply updates the pointer of the message to the LMA, the LMA will update the binding
flow binding entry with the BID of the interface to which the cache entry to bind the HNP to new Proxy-CoA [Figure
flow will be moved. The traffic selector (TS) in flow binding 4.b] and then update the flow binding entry list with the
table is defined as in [8]. TS is used to classify the packets of destination BID. Figure 5 shows the flow binding list
flows basing on specific parameters such as service type, entry before and after it is updated. In the figure 5.a, the
source and destination address … The packets matching with flow 1 is associated with the binding cache entry 1. It
the same TS will be applied with the same forwarding policy. means that the flow 1 is forwarded via the Proxy-CoA of
As shown in the figure 5, all TCP packets are moved from the MAG1. After that the LMA updates the flow binding
MAG1 to MAG2. list entry with the new binding cache entry 2. The flow 1

376
 is now associated with the Proxy-CoA 2 of the MAG2 as The same as HUR, we can utilize the existing PBU message
shown in the figure 5.b. Thus the flow 1 is successfully for using as a HUA with the following extension fields:
moved from MAG1 to MAG2
• Message type (T): The T bit is set by MAG to indicate
2) Mobile Access Getway Operation that it is a HUA.
The MAG operation is extended for exchanging the HUR/and • The mobility options: The mobility option field is a
HUA messages with the LMA. Two operations are added as variable length field. It contains the HNP that is needed to
follows: be shared.
• Receiving HUR: On receiving the HUR message, the 3) PBU
MAG sets up its endpoint of the bi-directional tunnel to A new flag (F) is included in the Binding Update Massage
the LMA with the HNP which is piggybacked in the to indicate to the LMA that the MN can support flow mobility.
HUR; and also sets up the routing path for the traffic This field is necessary only when the LMA cannot acquire
using HNP included in the HUR. information about flow mobility capacity of the MN from the
• Sending HUA: After successfully setting up the tunnel MN's policy profile. In this case, the MN will signal the MAG
and routing path for new HNP, the MAG sends HUA about its flow mobility capacity by using layer 2.5 signaling
including the HNP to inform the LMA that the flows message. The MAG then set the value of F flag to inform the
using HNP can be forwarded via the MAG. LMA about the flow mobility capacity of the MN. The F flag
MUST be set to 1 if the MN can support flow mobility and
3) Mobile Node Operation MUST be set to 0 if the MN cannot support flow mobility.
For simplicity, we assume that the MN uses a single logical
IV. PERFORMANCE EVALUATION
interface to hide all of its available physical interfaces. The
followings are necessary requirements of the logical interface We have performed simple NS-3 simulation for validating the
to support flow mobility. basic operation of PMIPv6 flow handover procedure with pro-
active signaling procedure. NS-3 network simulator version
• The logical interface can simultaneously attach to 3.9 is used with IEEE 802.11 (WLAN) and IEEE 802.16
multiple MAGs by using multiple interfaces.
(WiMax) network environment. For the details of basic
• The logical interface can accept all the packets receiving PMIPv6 design and implementation in NS-3, refer to our
from any physical interfaces that are abstracted by the previous work [12]. In order to support the proposed PMIPv6
logical interface, if the packets have a valid HNP. flow mobility, the virtual interface and the flow binding
manager in the MN and the paired control interface in the
• The logical interface must transmit uplink packets on the
LMA are additionally implemented to our basic PMIPv6
same physical interface on which the downlink packet
was received for the particular prefix/flow. implementation in NS-3. The control interface in the LMA
includes the module of flow handover decision and the handler
• The forth requirement is important for supporting flow of HUR/HUA messages. We also update MAG so that it
mobility since it can guarantee that packets belonging to includes the handler of HUR/HUA messages.
the same session are routed along the same path. In other
words a flow mobility decision made at the LMA will be The network topology is shown in Figure 6. There are
understood at the MN as an implicit decision when the three CBR over UDP traffics with 3.2 Mbps from the CN to
packets belonging to the same flow will arrive at a new the MN. WLAN has higher priority by default policy, and
interface. The detailed discussion about logical interface WiMax does for the UDP2 traffic. Figure 7 shows the
is provided in [2]. throughput for the UDP traffics. After WLAN is activated at
the beginning of the simulation, UDP1 and UDP2 start to send
D. Messages Format via WLAN at 1.5 seconds. When WiMax is activated at 5.0
1) HUR seconds, UDP2 performs flow handover from the WLAN to
the WiMax because WiMax has higher priority for the UDP2.
The HUR can be a new message. However we can utilize the The reason of increased throughput more than the serving rate
current PBA message for using it as a HUR with the following just after flow handover is that queued packets in the WLAN
extension fields: interface queue due to congestion are delivered while ordinary
packets are serving through WiMax. After flow handover of
• Acknowledge (A): The A bit is set by the LMA to request
an HNP update acknowledgement to be returned upon UDP2, it serves with its full rate. At 11.0 seconds, the LMA
receipt of the HUR. decides to move UDP1 to the WiMax due to decrease of
throughput after UDP3 is started to send at 10.0 seconds. After
• Message type (T): The T bit is set by LMA to indicate rapid increasing of throughput due to receiving both interfaces
that it is a HUR message. at the same time, UDP1 serves with its full rate as well.
• The mobility options: The mobility option field is a It should be noted that there are unfair throughput period
variable-length field. It contains all new HNPs that are before 5.0 seconds. Two over-rated traffics with the same
assigned to the new attachment of the MN. interface cause full of interface queue and packet drop. When
2) HUA the interface queue is not full yet, the fair distribution between
UDP1 and UDP2 packets is satisfied. However, when the

377
 5.5
UDP1
UDP2
5
PBU/PBA for WLAN (HNP1)
4.5
UDP1, UDP2 start
4

3.5

Throughput(Mbps)
3

2.5

1.5
PBU/PBA for WiMax (HNP1, 2)
Flow Handover (New interface activated)
1
UDP3 starts
0.5
Flow Handover
(LMA decision)
0
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Time(s)

Figure 7: Throughput of UDP1 and UDP2 traffics in the MN

5500
1650
UDP1 through MAG1
5000 1600 UDP1 through MAG2
UDP2 through MAG1
1550
UDP2 through MAG2
4500
Figure 6: Simulation topology 1500
1450
4000
interface queue is full, due to the characteristic of the drop-tail 1400
3500 1350
queue, a series of queuing operation, which are one packet is 1300

Sequence
3000
sending, an arrived packet is queued, and another arrived 5.49 5.51 5.53 5.55 5.57 5.59

3850
packet is dropped, is performed. Since the serving rates of 2500

UDP1 and UDP2 are the same, their order is alternative. As a 2000
3800

result, UDP2 is dropped more than UDP1 if the interface 1500

3750
queue of WLAN is full. Figure 8 depicts the received packet 1000
sequence for UDP1 and UDP2 in the MN. For each UDP 500 3700

traffic different symbol is assigned based on the transit MAG 10.99 11.01 11.03 11.05 11.07 11.09
0
for the received packets. Since there are two flow handovers, 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

which are at 5.0 seconds and at 11.0 seconds approximately, Time(s)

two breaking points of graph are shown in the figure. Figure 8: Packet sequence for UDP1 and UDP2 in the MN
Top-left subfigure shows the packet sequence in case of
flow handover of UDP2. Since 5.55 seconds, UDP2 packets REFERENCES
through MAG2 are arrived at the MN. However, there are [1] S.Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, B. Patil, “Proxy
arriving packets through MAG1 as well. Hence, it can be Mobile IPv6,” IETF RFC5213, August 2008.
explained the rapid increasing of throughput after flow [2] T. Melia, S.Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, B.
handover. With the same manner, the packets for the UDP1in Patil, “Logical Interface Support for multi-mode IP Hosts,” IETF
NETEXT WG , August 2010.
the bottom-right subfigure are arrived at the MN from both
[3] T.M.Trung, Y.Hong, Y.Han, “Flow mobility support in PMIPv6”, IETF
interfaces. It is noticed that the group of packets which are NETEXT WG, September 2010.
through MAG2 using WiMax interface has the same arrival [4] Bernardos, CJ., Jeyatharan, M., R. Koodli, R., Melia, T., and F. Xia,
time because the transmitting unit of WiMax is Burst, which "Proxy Mobile IPv6 Extensions to Support Flow Mobility ", IETF
can contain several packets together. NETEXT WG, July 2010.
[5] Koodli, Rajeev. and Kuntal. Chowdhury , "Flow Handover for Proxy
Mobile IPv6", IETF NETEXT WG, October 2009.
V. CONCLUSIONS [6] Xia, F., "Flow Binding in Proxy Mobile IPv6", IETF NETEXT WG,
June 2010.
[7] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC
The network-based flow mobility is a promising technology 3775, June 2004.
that can help the operators to comprise various heterogeneous [8] Tsirtsis, G., Soliman , H., Montavont , N., Giaretta , G., and K.
access networks to extend their network capacity at low cost. Kuladinithi , "Flow Bindings in Mobile IPv6 and NEMO Basic Support",
The IETF NETEXT working group introduced several IETF MEXT WG, August 2010.
solutions to get this goal. This paper provides a promising [9] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami,
"Multiple Care-of Addresses Registration", RFC 5648,
solution to support the network based flow mobility in
[10] Qualcomm, “3G/WiFi Seamless Offload”, Technical report, March
PMIPv6 basing on a comprehensive overview on the literature 2010
of the IETF NETEXT working group. Our next plan is to [11] K.-S. Kong, Y.-H. Han, M.-K. Shin, H.-R. You, and W. Lee, "Mobility
implement and evaluate the performance of the re-active Management for All-lP Mobile Networks: Mobile IPv6 vs. Proxy
signaling procedure. We will compare the performance of two Mobile IPv6," IEEE Wireless Communication, Vol. 15, No. 2, pp. 36-45,
signaling approaches and perform more detail analysis of the April 2008
advantages and disadvantages of each procedure. [12] H.-Y. Choi, S.-G. Min, Y.-H. Han, J. Park, and H. Kim,
“Implementation and Evaluation of Proxy Mobile IPv6 in NS-3 Network
Simulator,” In Proceeding of Ubiquitous Information Technologies and
Applications (CUTE), December 2010.

378