Analysis of the packet dropping constituency in Proxy-based mobile IPv6 over WLANs

Abstract

WiFi networks carrying IPv6 traffic with Proxy-based mobility support are to considered here. The performance of the handover function is first tested through the analysis of the effects of the packet size and inter-arrival times. Then, the sequence of events occurring during the handover period are scrutinized to observe the drawbacks that led to the obtained results. Finally, some suggestions are given to decrease the number of dropped packets, and thus improving the performance of the system.

Full text

Analysis of the Packet Dropping Constituency in
Proxy-based Mobile IPv6 over WLANs
W. Alayed
Department of Computer Engineering
King Saud University
Riyadh, Saudi Arabia
N.E. Rikli
Department of Computer Engineering
King Saud University
Riyadh, Saudi Arabia
Email: rikli@ksu.edu.sa
Abstract— WiFi networks carrying IPv6 traffic with Proxy-
based mobility support are to considered here. The performance
of the handover function is first tested through the analysis of the
effects of the packet size and inter-arrival times. Then, the
sequence of events occurring during the handover period are
scrutinized to observe the drawbacks that led to the obtained
results. Finally, some suggestions are given to decrease the
number of dropped packets, and thus improving the
performance of the system.
Keywords—PMIPv6; handover; wlan; packet drop; delay.
I. INTRODUCTION
Mobile networking technology are geared toward
supporting the requirements of the current and future smart and
sophisticated mobile devices, such as cellular phones, personal
digital assistants (PDAs), and laptop computers. The shifting to
an all IP-based network that additionally should integrate all
wireless technologies in the 4G wireless network era including
all cellular networks, WiFi, WiMAX, ad hoc networks, have
led to the new developments in mobility functions of the IP
stack. Proxy Mobile IPv6 (PMIPv6) has been suggested as a
promising mobility management scheme due to its scalable
features in mobility support for IPv6 nodes in a network by
network-based management, which does not require the nodes
to be directly involved into the IP mobility management
functions.
Proxy Mobile IPv6 is the mobility protocol proposed by the
Network based Localized Mobility Management (NetLMM)
group of the IETF to be handled entirely without the mobile
node (MN) involvement [1]. This protocol is based on Mobile
IPv6 (MIPv6), extending the MIPv6 signaling messages and
reusing the Home Agent (HA) concept. The main difference
between PMIPv6 and MIPv6 is that the MIPv6 is Host-Based
while PMIPv6 is Network-Based Localized Mobility
Management which provides mobility support to MN without
their involvement. This is achieved by relocating relevant
functionality for mobility management from the MN to the
network [2] which gives the service provider the opportunity to
control the network in terms of traffic and QoS.
Other advantages of PMIPv6 include freeing up of the MN
from doing any mobility related activities and thereby saving
its resources for other purposes. Also, the signaling traffic
volume will be reduced and there will not be any tunneled
packets in the access network. These aspects become very
important since the access networks in mobile networks usually
are air interfaces. Further, PMIPv6 is also becoming a very
attractive mobility management protocol for mobile network
operators as seen by its inclusion in current 3rd Generation
Partnership Project (3GPP) standardization as a possible
alternative mobility management protocol for the Long Term
Evolution (LTE) technologies.
The performances have been evaluated using metrics such
as handover latency, service disruption time, and binding
update cost, and under various network environments and
technologies. Based on the obtained results, some
improvements have been suggested by researchers. In [3], a
Handover Coordinator for PMIPv6 is proposed to serve the
mobile node while it is in the overlap region of the current and
next coverage area. Simulation results show an improvement in
both delay and packet loss during handover. The cost may be
high due to need to place this handover coordinator entity in all
overlap regions.
In [4], a bi-casting based PMIPv6 scheme that duplicates
packets to the current and candidate points of attachment was
proposed. As in the previous case, this scheme minimizes
handover delay and packet loss. Its drawback is the inefficient
utilization of network resources such as backhaul bandwidth
and buffer space.
In [5], a fast-multicast handover procedure for PMIPv6,
where mobile nodes are unaware of mobility, was introduced.
The handover procedure optimizes multicast group
management by utilizing the context of mobile nodes.
Consequently, the service interruption time was minimized,
and the buffering functionality prevents the multicast packet
loss.
In [6], a Packet Lossless PMIPv6 with authentication has
been proposed to reduce packet losses. This was achieved by
allowing the previous mobile access gateway to register to a
Local Mobility Anchor on behalf of a new MAG during layer 2
handoff. Then, the new MAG buffers packets during handover
after registration and thus reduces packet loss. Additionally, an
Authorization and Accounting function was suggested to
authenticate the MN and to receive MNs probes securely.
In this paper, we will concentrate on a WiFi environment
where we will study the performance of the existing techniques
and suggest and analyze improvements. The rest of the paper is
organized as follows. In the next section we will present the
PMIPv6 architecture and operation, followed by the simulation
model, then the results will be presented, and finally we will
conclude with the main results and future work.

II. PROXY MOBILE IPV6
A. Architecture
The core functional entities in the PMIPv6 infrastructure
are as shown in Figure 1:
Figure 1: PMIPv6 domain basic configuration.
Mobile' Access' Gateway' (MAG):!"#$%! &'($()!
*&+,-+.%!(#&!.-/$0$()!+&01(&2!%$3'10$'3! -'! /&#10,!-,! 1! 45!
(#1(!$%! 1((16#&2! (-! $(%! 166&%%! 0$'78! "# &! 49:! $%! ;%;100)! (#&!
166&%%! +-;(&+!,-+! (#&! 45<! $8&8!(#&! ,$+%(! #-*! +-;(&+! $'! (#&!
=-610$>&2! 4-/$0$()! 41'13&.&'(! $',+1%(+;6(;+&8! ?(! $%!
+&%*-'%$/0&! ,-+! 2&(&6($'3! (#&! .-@&.&'(%! -,! 1'! 45! 1'2!
*&+,-+.%! .-/$0$()A+&01(&2! %$3'10$'3! B$(#! (#&! =49! B#$0&!
+&3$%(&+$'3!(#&!45!(-!=498! "#&+&! 1+&! .;0($*0&! 49:%! $'!1!
C4?C@D!2-.1$'!EFG8!
Local' Mobility' Anchor' (LMA):!"#$%! $%! 1'! &'($()!
B$(#$'!(#&!/167/-'&!'&(B-+7!(#1(!.1$'(1$'%!1!6-00&6($-'!-,!
+-;(&%! ,-+! $'2$@$2;10! 45%! B$(#$'! (#&! C4?C@D! 2-.1$'8! ?(!
16(%!$'!1!%$.$01+!B1)!(-!(#&!#-.&!13&'(!HI9J!$'!4?C@D!1'2!
$(!$%!+&%*-'%$/0&!,-+!.1$'(1$'$'3!(#&!%(1(&!-,!(#&!45%!;%$'3!
(#&!/$'2$'3!616#&!&'(+$&%!EFG8!!
B. Operation
When a MN enters the PMIPv6 domain, it has the option to
send a Router Solicitation message. The MAG detects the
attachment and contacts the LMA by sending a Proxy Binding
Update message (PBU). The LMA processes the PBU message
and assigns the MN with Home Network Prefixes. It also sets
up a Binding Cache Entry (BCE) in an internal cache table.
The BCE main fields are the Mobile Node Identifier (MN-ID),
the prefix assigned and the MAG’s IP address visible from the
LMA (the Proxy Care-of Address (P-CoA)). Then, it sends a
Proxy Binding Acknowledgement (PBA) to the MAG which
includes the assigned home prefix(es). The LMA also sets up a
bidirectional tunnel with the MAG that can be used for
forwarding traffic.
As soon as the MAG receives the PBA, it sends a Router
Advertisement message (RA) to the MN with the available
prefixes for which the MN uses to configure its IP address. The
MN can use either the state-full or state-less modes for IP
configuration, based on the modes that are permitted on the
link as indicated by the (RA) message. Once the address is
configured on the MN, it becomes ready to send and receive
packets. This procedure is shown in Figure 2.
Figure 2: PMIPv6 message signaling [7].
Any packets directed to the MN are first received by the
LMA. The LMA checks the packets destination address,
compares it with the internal cache, and forwards them using
the bidirectional tunnel to the MAG that the MN is connected
to. The MAG receives the packets, removes the outer header,
and forwards the packet to the MN. The MN can send packets
to the pertinent MAG, which then forwards them to the LMA
using the tunnel. The LMA removes the outer header and
routes them to the CN.
When the MN leaves the network for a handover, the
MAG will detect its disconnection and send a signal to the
LMA about this disconnection. This is signal is a
deregistration message. The LMA starts a timer for the entry
corresponding to that MN in the binding cache table. If a PBU
message for that MN is received before the timer times out, a
result of a new attachment during a handover, then the LMA
updates the Binding Cache Entry for that MN and the timer is
cancelled. If the timeout happens, then the LMA removes the
Binding Cache Entry corresponding to that MN from the
internal table. This procedure is shown in Figure 3.
Figure 3: Mobile Node Handover -Signaling call flow [7].

III. SIMULATION MODEL
The network topology of the test network is as shown in
Figure 4. It consists of two WiFi subnets, serviced by MAG1
and MAG2. Each network is operating at 11Mbps data rate
and with a coverage area of 20 m2. The mobile node (MN) is
assumed moving in a straight line from MAG1 (p-MAG)
towards MAG2 (n-MAG) with a constant speed of 50m/s. The
source of the data stream is the Correspondent Node (CN),
which generates a CBR traffic consisting of fixed sized UDP
packets at fixed intervals.
We have chosen a simple network and simple mobility
model to get a tractable simulation model. This will allow us
to concentrate on monitoring the operation of PMIPv6 without
including the other factors such as congestion, random
movement … etc.
The wired links are duplex links that operate at 100 Mbps
with default delay of 1 ms except for the (CN-LMA) link
which has a default delay of 10 ms. The queuing is a drop tail
queue with a maximum length of 30 packets.
Figure 4: PMIPv6 network setup.
IV. RESULTS AND DISCUSSIONS
The simulation of the network in Figure 4 has been
implemented using ns-2.29-nist. The obtained results are to be
discussed into two parts. First, we present the performance
results obtained at various links in the network. Then, in the
second part we correlate these results to the actual operation of
the protocol.
A. Link-based performance
1) CN-MN
Different simulation scenario results are shown in Figure 5
and Figure 6. In Figure 5 is shown the packet drop rate as a
function of the inter-arrival time and with packet size as a
parameter. We notice that the packet drops increase as the
traffic intensity increases (inter-arrival time decreases), and
that the two parametric curves are almost identical.
Figure 5: Interval and packet size impact on (end-to-end)
drops.
In Figure 6 is shown the end-to-end delay as a function of
the inter-arrival time with the packet size as a parameter. At
heavy traffic, the queuing delay increases the end-to-end delay,
while at lower traffic intensities the total delay is almost
constant, and consists merely of the propagation and
transmission delays.
Figure 6: Interval and packet size impact on (end-to-end)
average delay.
We may notice that the average end-to-end delay (CN-MN)
and the end-to-end total packet drops differ for each case only
due to the change in traffic intensity, and do not have anything
to do with PMIPv6.
2) MAG-MN
However, the PMIPv6 impact is significant on the MAG-
MN link as shown in Figure 7 and Figure 8. The variation in
dropped packets is noticeable for both the changes in packet
size and inter-arrival times. In all cases however, there is a
steady decrease in the dropping rate as the inter-arrival times
are increased. At high traffic intensity, it is more for smaller
packet size, and then it switches after 0.02 sec inter-arrival
time, where it becomes higher for the larger packet size.

Figure 7: Interval and packet size impact on (MAG-to-
MN) drops.
The variation in the delay due to the increase in traffic
intensity is small, while that due to the packet size is
noticeable. In fact, there is a constant gap between the
performances with different packet sizes, and practically
constant performance with a fixed packet length, as shown in
Figure 8.
Figure 8: Interval and packet size impact on (MAG-to-
MN) average delay.
After running many simulation experiments, it became
clear that packet sizes and inter-arrivals do not have that much
impact on the overall simulation results. Knowing that the
LMA is always sending packets to the MAGs at constant rate
explains why the average delay (MAG->MN) for a specific
packet size is the same.
B. Tracing the dropped packets
Figure 9 shows the times when the successfully received
packets were sent. In the first part, the packets were sent
through the current MAG (p-MAG), while in the second they
were sent through the new MAG (n-MAG). There is a clear
gap between the two segments, which corresponds to the
dropped packets. This interval includes the handover period.
Our goal in this section is to shade some light on how the
packets are dropped and why. We hope by doing so, to
improve the performance of this handover technique.
1) Sending Times
From Figure 10, it is clear that while the mobile node is
moving and the signal strength gets below the minimum
threshold at p-MAG, the LMA still continues to send packets
to p-MAG. It stops only when the LMA receives a PBU from
n-MAG, at the new connection point.
Figure 9: Sending time for successful packets.
The second portion shows that all the packets that arrived at
p-MAG were sent unsuccessfully, since the connection with
the MN was lost.
Figure 10: Sending time for dropped packets.
Tracing PMIPv6 performance applied on WiFi network
shows that all packets have been sent from the LMA during the
period (time from p-MAG loosing the signal until the LMA
receives a PBU from n-MAG) are dropped as it is shown in
Figures 9 and Figure 10. It is clear that all dropped packets are
sent from the LMA to p-MAG before the LMA receives a PBU
from n-MAG. But the p-MAG still carries on trying to send
them to the MN that is no longer connected to it.
2) Packet Exchange
During the handover period a sequence of events has been
recorded in a typical handover scenario. The first part, as
shown in Figure 11, corresponds to the loss of connectivity
between the MN and the p-MAG without any action being
taken. It starts when the first packet is retransmitted (although
other reasons may be the cause).
We notice that after a packet is sent and an ACK is not
received, it will be resent up to seven times. After the seventh
trial the packet is dropped. This explains why the packet drops
still occur even after the PMIPv6 handover is completed.

Figure 11: Handover period in details - part 1.
The second part, as shown in Figure 12, starts when the
MN realizes that it is disconnected from the p-MAG, and starts
scanning for a new network. The scanning operation may be
repeated over various channels, and stops when it chooses the
channel over which the available access point is operating.
Then, the MN sends a Probe request to the n-MAG. We notice
that packets are still sent from the LMA to p-MAG where they
are all dropped.
The third and last part starts when the n-MAG accepts the
connection and sends an Association response to MN and a
PBU to LMA, and the handover is complete. The packet drop
ends after the Association Response between the n-MAG and
MN has been confirmed.
Table 1 shows a detailed summary for the dropped packets.
Knowing that for a total of 29 packets that are dropped only 7
are dropped before the MN has established a connection to n-
MAG, which means that there are 22 packets, i.e. most of the
packets, can be saved.
So, our suggestions are based on this remark, which tries to
avoid such loss to improve the performance of the system.
Thus we suggest the following:
 Whenever the n-MAG sends a probe response to
the MN it also sends a (Stop sending) signal to the
LMA. Consequently, the LMA will stop
forwarding packets to the p-MAG and holds them
in its queue. As soon as the MN is successfully
connected to n-MAG, it restarts forwarding those
packets again to n-MAG.
 When the BCE is updated at the LMA, the LMA
should send a message to p-MAG requesting all
the queued packets targeted to the MN to be sent
back. Then the LMA will forward those packets to
the n-MAG.
 The LMA stops sending packets to the p-MAG
after a number of drops. After several packet
drops, the LMA should notice that the MN has lost
connection to its p-MAG. Therefore, the LMA
should stop sending packets to p-MAG and waits
until the MN gets connected to n-MAG.
Afterwards, the LMA forwards its queued packets
to the n-MAG.
We believe that these suggestions when implemented will
both decrease the total packets loss and increase the capacity
efficiency of the system. The only hurdle that may hinder such
achievement is the programing efficiency of the protocol that
will allow this in real time.
Figure 12: Handover period in details - part 2.

Figure 13: Hanover period in details - part 3.
Table 1: Drops count in details.
Total packet drop
29
Dropped packets id
1034-1063
Number of packet drops before the connection
to MAG2 has been established
7
Dropped packet (s) id before the connection to
MAG2 has been established
1034-1040
Number of packet drops after the connection
to MAG2 has been established
22
Dropped packet (s) id after the connection to
MAG2 has been established
1041-1063
V. CONCLUSION
In this paper, we have considered a WiFi network
consisting of two overlapping networks and a MN moving in a
straight line between them. PMIPv6 was considered as the
means of handover at layer three. The purpose of this setup
was to study the detailed operation of the standard and discover
any possible inefficiencies.
The performance of the network was tested for the delay
and packet drop. Then, the sequence of events happening
during the handover period has been observed. Based on our
observations, some suggestions have been proposed to decrease
the number of dropped packets and improve the performance
of the system.
In our future work, these suggestions will be implemented
and tested through simulation. Their effects on other
performance criteria will be also analyzed.
REFERENCES
EKG ?L"M<! N5&(B-+7A/1%&2! =-610$>&2! 4-/$0$()! 41'13&.&'(<N! $'!
O#1+(&+A$&(,A'&(0..APQ<!FPKP8!!
EFG "8! 4&0$1<! O8! R8! S&+'1+2-%<! 28! 08! T8! 9'(-'$-! <! M8! :$;%(! 1'2! 48!
O102&+-'<! N?C! M0-B! 4-/$0$()! $'! C4?C@D! S1%&2! 5&(B-+7%U!
V-0;($-'! W&%$3'! 1'2! LX*&+$.&'(10! L@10;1($-'<N! Y$+&0&%%!
C&+%-'10! O-..;'$61($-'%<! @-08! Q<! '-8! DK<! *8! DPZ[DF\<! ]!
5-@&./&+!FPKK8!!
EZG =8! 41313;01<! I8! O#1'! 1'2! T8! M10-B-<! N96#$&@$'3! V&1.0&%%!
4-/$0$()! (#+-;3#!I1'2-@&+! O--+2$'1($-'! $'! 1! 5&(B-+7A/1%&2!
=-610$>&2! 4-/$0$()! 41'13&2! I&(&+-3&'&-;%! L'@$+-'.&'(<N! $'!
C&+%-'10! ?'2--+! 1'2! 4-/$0&! ^12$-! O-..;'$61($-'%! HC?4^OJ<!
FPKP!?LLL!FK%(!?'(&+'1($-'10!V).*-%$;.!-'<!FPKP8!!
EQG R8A?8! _$.<! V8AR8! _-#! 1'2! 58AV8!_-<! NSAC4?C@DU! C4?C@D! B$(#!
S$61%($'3!,-+!V-,(!I1'2-@&+<N!$'! KK(#!?'(&+'1($-'10!O-',&+&'6&!
-'!92@1'6&2!O-..;'$61($-'!"&6#'-0-3)<!FPP`8!!
E]G R8AI8! =&&! 1'2! "8! L+'%(<! NM1%(! C4?C@D! 4;0($61%(! I1'2-@&+!
C+-6&2;+&! ,-+! 4-/$0$()Aa'1B1+&!4-/$0&! 5-2&%<N! $'! ?LLL! \Z+2!
b&#$6;01+!"&6#'-0-3)!O-',&+&'6&!Hb"O!V*+$'3J<!FPKK8!!
EDG V8! ^);<! :8Ac8! _$.<! S8! _$.! 1'2! c8! 4;'<! N9! V6#&.&! (-! ^&2;6&!
C167&(! =-%%! 2;+$'3! C4?C@D! I1'2-@&+! 6-'%$2&+$'3!
9;(#&'($61($-'<N!$'!?'(&+'1($-'10!O-',&+&'6&!-'! O-.*;(1($-'10!
V6$&'6&%!1'2!?(%!9**0$61($-'%!?OOV9<!FPPd8!!
E\G L8!V8! :;'21@&00$<!_8!=&;'3<! b8!W&@1+1*100$<!_8! O#-B2#;+)!1'2!S8!
C1($<! NC+-X)! 4-/$0&! ?C@D! E^MO]FKZG<N! ?'(&+'&(! L'3$'&&+$'3!
"1%7!M-+6&!H?L"MJ<!FPPd8!
EdG 48!=$&/%6#<! L28<!98! 4;#1''1!1'2!T8!S0;.&<!N"+1'%$&'(! S$'2$'3!
,-+! C+-X)! 4-/$0&! ?C@D! E^MODP]dG<N! ?'(&+'&(! L'3$'&&+$'3! "1%7!
M-+6&!H?L"MJ<!FPKK8!
E`G OR8!S&+'1+2-%<! 98!2&! 01!T0$@1<! M8!:$;%(<!"8!4&0$1!1'2!^8!O-%(1<!N9!
C4?C@DA/1%&2! %-0;($-'! ,-+! W$%(+$/;(&2! 4-/$0$()! 41'13&.&'(!
2+1,(A/&+'1+2-%A2..A*.$*APK<N!W44!Y-+7$'3!:+-;*<!FPKF8!