Design and evaluation of network-based distributed mobility management solution based on PFMIPv6
Authors Balfaqih, Mohammed; Ismail, M; Nordin, R; balfagih, zain;
Yuwono, Tito
Publisher IEEE
Download date 21/06/2023 04:27:52
Link to Item http://hdl.handle.net/20.500.14131/733
See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/314668216
Design and evaluation of network-based distributed mobility management solution based on PFMIPv6
Conference Paper · August 2016
DOI: 10.1109/ICWT.2016.7870867
CITATIONS
2
READS
82 5 authors, including:
Some of the authors of this publication are also working on these related projects:
Spectrum sensing and energy detection in cognitive networksView project
Minimizing Feedback Overhead in the Uplink of Fifth Generation (5G) Cellular Networks for Practical Implementation of Massive-MIMO SystemView project Mohammed Balfaqih
Universiti Kebangsaan Malaysia 34PUBLICATIONS 392CITATIONS
SEE PROFILE
Mahamod Ismail
Universiti Kebangsaan Malaysia 694PUBLICATIONS 7,072CITATIONS
SEE PROFILE
Rosdiadee Nordin
Universiti Kebangsaan Malaysia 273PUBLICATIONS 4,356CITATIONS
SEE PROFILE
Design and Evaluation of Network-Based Distributed Mobility Management Solution Based on PFMIPv6
Mohammed Balfaqih1, M. Ismail1, R. Nordin1
1Dept. of Electrical, Electronic and System Engineering Faculty of Engineering and Built Environment
43600 UKM Bangi, Selangor, MALAYSIA Email: [email protected]
Zain Balfaqih2, Tito Yuwono3
2Dept. of Information System, Fac. of Engineering Effat University, Jeddah, SAUDI ARABIA
3Dept. of Electrical Engineering Universitas Islam Indonesia
Jalan Kaliurang KM 14 Yogyakarta, INDONESIA Abstract— Proxy Mobile IPv6 (PMIPv6) protocol provides IP
mobility support to a Mobile User (MU) once it performs a handover from an access router to another. Furthermore, Fast Handover for PMIPv6 (PFMIPv6) protocol has been standardized to improve the handover performance of PMIPv6 in terms of handover latency and packet loss. The limitation of these Centralized Mobility Management (CMM) protocols (e.g., non optimal routes, single point of failure and scalability) has led to the development of Distributed Mobility Management (DMM) paradigm. DMM aims to flat the network architecture by placing the anchor entity dynamically closer to the MU. The DMM solutions can be classified into: host-based DMM, in which MU participates in IP mobility process, and network-based DMM, where IP mobility process is done in the network side without MU involvement. However, existing network-based DMM proposals rely on PMIPv6 protocol which experience high handover latency and packet loss. Thus, we present the design and operation of a proposed network-based DMM solution based on PFMIPv6. We have developed an analytical model to evaluate and compare the handover latency and the packet loss of the proposed network-based DMM solution and IETF network- based DMM proposal.
Keywords— Disributed Mobility Management, PFMIPv6, Performance analysis, IP Mobility Management.
I. INTRODUCTION
The number of mobile users and their data traffic usage have been increasing dramatically during the last few years and are expected to grow even more in future years [1]. This is mainly due to the deployment of various and new wireless technologies and the rapid growth of number of applications and services that have aggressive Internet connectivity demand. As wireless/mobile technologies move to be full IP based architectures to support next generation wireless networks (NGWN), IP mobility management ensures communication session(s) continuity for mobile users while moving and changing their wireless networks.
The existing IP mobility protocols employ a centralized mobility anchor to be in charge of mobility management.
Consequently, both control and data signaling messages must be forwarded to this mobility anchor. Such centralized functions reduce system scalability and overall performance and reliability of the network. This has pushed industry and academic communities to look for solutions to reduce the load
in the anchor entity. There is an effort by Internet Engineering Task Force (IETF) to address these issues where a new design paradigm named Distributed Mobility Management (DMM) [2] is being actively discussed and proposed.
IETF DMM working group is currently redesigning and extending existing Centralized Mobility Management (CMM) protocols since it is more effective and compatible [3]. The proposed DMM solutions, so far, can be categorized based on mobile user participating in IP mobility procedures or not; into host-based solutions [4], and network-based solutions [5-6].
Reference [7] has shown that network-based DMM outperforms host-based DMM in handover latency and packet loss. However, all the proposed solutions are adapted protocols with reactive handover process where the Mobile User (MU) initiated the handover process upon the attachment with the new Access Router (AR). This increases the handover latency and the session recovery time and consequently increases the packets loss [8].
In this article, which is an extension of [9, 10], we review existing DMM solutions and propose a network-based DMM solution derived from Fast Handover for Proxy Mobile IPv6 (PFMIPv6) protocol [11]. To overcome the drawbacks of existing DMM solutions, the proposed solution specifies a bidirectional tunnel between MAARs to allow a MU to transmit/receive its packets immediately after the attachment with a new AR. The proposed solution is based on PFMIPv6 architecture with revised functions and messages. To make PFMIPv6 working in distributed manner, control plane of Local Mobility Anchor (LMA) is kept centralized in a central entity called Central Mobility Database (CMD), while its data plane is moved to Mobile Access Gateway (MAG) which is then referred as Mobile Anchor Access Router (MAAR). In addition to MAG functionalities, MAAR is responsible of Proxy Binding Update (PBU) process and Handover Initiate (HO-initiate) process.
The rest of this paper is organized as follows: Section II provides a brief background and related work description. In Section III, the proposed network-based DMM solution is detailed. In Section IV, we evaluate the proposed solution by analyzing the handover latency and packet loss. The numerical results and discussion is given in Section V. Finally, conclusion is provided in Section VI.
- 132 - 978-1-5090-2649-4/16/$31.00 ©2016 IEEE
II. BACKGROUND AND RELATED WORK
The purpose of DMM is to provide an alternative paradigm of CMM using a flatter system idea by placing the anchor entity adjacent to the MU dynamically. Currently, there is no DMM standard in place and few DMM proposals have been developed. These proposals can be classified into two categories: partially distributed approach, in which data plane is distributed and managed by the MAARs while control plane is managed by the CMD, and fully distributed approach, in which control and data planes are distributed. Since our proposed solution is partially distributed, in the following, we will explore selected partially distributed proposals.
In [12], the authors introduced partially distributed scheme called Dynamic Mobility Anchoring (DMA). Comprehensive analysis of DMA scheme was presented in [13]. DMA combines the functionalities of the LMA and the MAG into a new entity called Mobility-capable Access Router (MAR). In addition, a database is proposed to store MU’s information including: ongoing mobility sessions, allocated network prefixes and corresponding MARs. Once the MU roams to a new MAR, the new MAR restores ongoing sessions from the database and performs binding update process with each anchoring MAR. However, in this proposal, the database works as a rely which results high signalling cost and high handover latency in contrast with proposals that employ the database as a proxy to perform binding registration, as proposed in [14].
In [15], partially distributed solution was proposed based on PMIPv6. The solution splits LMA’s functions between Location Management (LM) server and MAG. The LM server manages and tracks the location of a MU while the MAG is responsible for intercepting and forwarding the packets from/to a MU based on the location information from the LM.
However, the signalling cost of this solution is high due to the high number of messages exchanged between LMs and MAGs. In addition, the handover latency is high since the MU initiated the handover process reactively upon the attachment with the new AR.
L. Yi et al proposed in [16] splitting functions of LMA into two distinct entities: a control plane LMA (CLMA) and a data plane LMA (DLMA). The former maintains MUs’
mobility sessions and selects the most suitable DLMA to the
MUs, while the second is the anchor to manage MUs’ traffic.
On other hand, The MAG entity remains same as in PMIPv6 maintaining mobility signaling messages and tracking MU movement. Although this proposal relieves the burden from the LMA, it preserves DLMA/MAG hierarchy along with the tunnels during the whole duration of a data session. Therefore, the solution does not for flat architectures.
One of the promising network-based DMM proposals is presented in [14] by IETF, whereas its performance is then analyzed in [8]. The proposed solution is similar to [13] with the different that the database, which is renamed as CMD, maintains the control plane of LMA. The MAG, on other hand, is enriched with the data plane of the LMA and named as MAAR. Each MAAR has a unique set of prefixes to where it assigns one of the prefixes to the MUs upon the attachment.
The next Section details the procedure of the proposed network-based DMM solution.
III. NETWORK-BASED DISTRIBUTED MOBILITY MANAGEMENT SOLUTION
The proposed network-based DMM solution employs the architecture proposed in [14] as shown in Fig. 1. Our solution takes advantage of aspects presented by PFMIPv6 and employs some of its terminology with the following essential differences:
The LMA, which is renamed CMD as in [14], maintains the control functions only and is supplied with a binding cache entry (BCE) to store mobility sessions registry.
The MAG is enhanced with data forwarding functions of the LMA and it is renamed as MAAR similar to [14] with the same address configuration method. It includes Local Binding Cache Entry (LBCE) to store attached MUs’
information.
MAAR maintains HO-initiate process to transfer network- resident context and forward MUs’ data traffic prior to handover execution. In addition, MAAR buffers data packets meant to the MU during the handover process.
The signalling of PFMIPv6 is extended to include some additional mobility options.
Fig. 1. Network-based DMM Architecture: Initial Registration [14].
A. Initial Registeration:
The initial registration process occurs similar to [14]. Upon the MU attachment to an access network, it sends a Router Solicitation (RS) message asking for a prefix to be assigned.
The responsible MAAR, for example MAAR1, will assign for the MU a unique Local Network Prefix (LNP) from its prefixes pool. It then sends PBU carrying the MU-ID and the assigned prefix to the CMD, and creates LBCE for the MU.
The CMD as a response will update its BCE with the new mobility session and sends PBA to the MAAR. After that, the MAAR informs the MU the assigned prefix to configure IPv6 address through Router Advertisement (RA) message. Fig. 2 shows signaling flow of the initial registration process. After MU attachment, the current MAAR (i.e. named Serving MAAR, S-MAAR) does not perform any special handling or encapsulation to forward packets carrying LNP to the MU.
Fig. 2. Initial Registeration Signalling Flow [14].
B. Handover Management:
This Section details the handover operation of the proposed network-based DMM solution. Fig. 3 shows the first roaming scenario in network-based DMM architecture. When the MU during its movement detects that the handover is imminent, it scans the neighboring Access Networks (ANs) to find a new AN (nAN) who has the highest Received Signal Strength (RSS). As shown in Fig. 4, the MU then reports its ID and the nAN’s ID, to the S-MAAR. Once the S-MAAR receives the report message, it will obtain the new MAAR from (AN ID, MAAR info) tuple which is a similar process to
that in [17]. The S-MAAR after that starts to set up a bidirectional tunnel with the nMAAR by sending Hanover Initiate (HI) message. The HI message in [11] is extended to include two new flags: Distributed (D) flag with the value (1), in which it specifies that HI message is distributed extension, and Target Type (T) flag. Here, the T flag value is set to (0), whereas it indicates that the destination is the nMAAR. The HI message contains also the MU-ID and MU’s LNP (i.e.
Pref1::/64).
Fig. 4. Handover Management Signaling Flow of the Proposed Solution at First Roaming Scenario.
The nMAAR then will execute the following procedures:
assigning a new LNP (Pref2::/64) to the MU, creating temporary LBCE for the MU, updating the routing state of the MU. The nMAAR then will execute the following procedures:
assigning a new LNP (Pref2::/64) to the MU, creating temporary LBCE for the MU, updating the routing state of the MU. Now, the prefix that was allocated by MAAR1 is referred
Fig. 3. Network-based DMM Architecture: First Roaming Scenario [14].
- 134 -
as previous LNP (pLNP), and the MAAR1 becomes the Anchor-MAAR (A-MAAR) for that prefix. The nMAAR sends Handover Acknowledgement (HAck) message back to the S-MAAR to confirm that it updates the routing state successfully with the new MU location. S-MAAR and the nMAAR establish a bidirectional tunnel between them to forward the packets intended to any of the MU’s prefixes. The nMAAR buffers the received packets.
The nMAAR triggers the MU to perform the handover through handover command message, which contains the assigned nLNP. The MN thereafter establishes a physical- layer connection with the nAN and initiates a link-layer connection establishment. In this way, packets destined to Pref1::/64 are anchored at MAAR1 and forwarded through the tunnel to the MAAR2 which finally transmits them to the final destination. In uplink, when packets are transmitted by the MN using Pref1::/64, the packets are first sent to MAAR2 which is tunneled them to MAAR2 to forward them towards the next hop to destination. On other hand, MAAR2 routes packets carrying Pref2::/64 without the need for specific packet processing both for uplink and downlink (see Fig. 3).
Thereafter, the nMAAR transmits the PBU message containing nMAAR address and A-MAAR list addresses to the CMD. The CMD, upon the PBU receipt, will retrieve MU’s entry in the BCE and perform the following procedures:
displacing the current the S-MAAR’s address with MAAR2’s address, inserting MAAR1’s address and pLNP assigned by MAAR1 into an additional BCE’s field called “A-MAARs list”. The CMD then replies with the PBA message.
Fig. 5. Handover Management Signaling Flow of the Proposed Solution at Second Roaming Scenario
Once the MU changes its S-MAAR again, it will repeat the handover process with considering that the number of A- MAARs involved increases depending on how many pLNP the MU has to preserve. In addition, the S-MAAR includes
“Anchor MAAR option” in HI message informing the nMAAR regarding the A-MAARs’ addresses and their correspondent pLNPs (see Fig. 5). The nMAAR upon receiving the HI message will send HI message with value ‘1’
in T flag, and “New MAAR option”. The value ‘1’ in T flag specifies that the receiver is A-MAAR, while “New MAAR option” contains nMAAR’s address. As a response, the A- MAARs will set the nMAAR as their next hop.
IV. PERFORMANCE ANALYSIS
To evaluate the handover performance of the proposed network-based DMM solution and compare it with IETF proposal presented in [14], we analyze the handover performance in terms of handover latency and packet loss.
Table I summarizes the notations used throughout in this paper.
TABLEI:NOTATION
Symbol Definition Symbol Definition
SN Number of cells (i.e.,
subnet). r Radius of a cell.
TL2 layer2 handoff latency. TAuth authentication latency.
Lc average size of control
packets. Lp average size of data packets.
BWW Wireless link bandwidth. BW Wired link bandwidth.
lw wireless propagation
latency. l wire propagation
latency.
pf probability that the
wireless link fails. TPCx processing time by node x.
dx,y(p) symmetric delay of a packet of size p sent from x to y.
(.)
TSR Session recovery time.
A. Handover Latency:
The Handover Latency (HL) is defined as the time interval from the last moment that the MU can receive/transmit packets through S-MAAR, to the first moment the MU can receive/transmit packets through nMAAR [6, 7]. The handover procedure of IETF proposal [14] includes three phases as follows (see Fig. 6).
2
IETF IETF
HL L Auth Binding
T =T +T +T (1)
TL2 represents the link layer establishment latency, while TAuth represents the MU authentication latency. TBindingIETF is the binding registration phase, and is calculated as:
2 ( ) 2 ( ) 2
IETF CMD MAAR
Binding MU MAAR CMD MAAR PC PC
T = d − c + d − c +T + T (2)
CMD
T
PC andT
PCMAARare the processing time at the CMD and the MAAR, respectively. dMU MAAR− ( )c refers to the delay of control packets transmission through wireless link between the MU and the MAAR, and is expressed as:( ) ( 1 )( 1 )
1
p
MU MAAR W MU MAAR
W f
d c L h
BW P
− = + −
− (3)
MAAR CMD( )
d − c refers to the delay of control packets transmission through wire link between the MAAR and the CMD, and is expressed as:
, ( ) ( p 1) ,
CMD M A A R CMD M A A R
d c L h
= BW + (4)
On other hand, the proposed network-based DMM solution operates proactively with an extra signaling (see Fig. 6). The additional parameters that have been used to analyze the handover latency of the proposed solution are: x: Time interval between reaching the MU’s RSS the threshold value, and scanning its neighboring ANs, T: Time interval between when the MU sends the report message and receives the handover command to and from the S-MAAR, : Represents the interval between sending the report message to the S-MAAR, and dropping the L2 link connection, where x < x + T , t:
Time from reaching the MU’s RSS the threshold value until dropping the L2 link connection t = +x T , and THI: HO- initiate process latency.
Because T = 2dMU-MAAR(C) + THI, the handover latency of the proposed solution can be calculated as follows:
(((2 ( ) ) (( 2 ) ))
propsed
HL MU MAAR HI L Auth
T = d − c +T − +φ T +T −x (5) The time interval x occurs before executing the handover, thus, the latency of L2 link setting and authentication phases is excluded from the handover latency calculation. The THI is
calculated as follows:
2 ( ) MAAR
HI MAAR MAAR PC
T = d − c +T (6)
B. Packet Loss:
The Packet Loss (PL) is defined as the overall packets loss or dropped during the handover process. There is no buffering mechanism is used in the IETF proposal during the handover process. Thus, the PL is proportional to the length of session recovery interval and to the compound packet transmission rate Ȝ [7]. The session recovery interval
T
SR(.) is defined as the interval from the last data packet of a given session received before the handover to the first packet received after the handover [7].The packet loss of IETF proposal and the proposed solution are expressed as follows:
(.)
(.) d SR
PL =
λ
L T (7) The session recovery time interval to recover old IP flows’sessions can be calculated as follows:
( ( )) ( ) ( )
IETF IETF
SR HL MU MAAR MAAR MAAR MU MAAR
T =T −d − c +d − d +d − d (8)
The proposed network-based DMM solution, on other hand, employs buffering mechanism at the nMAAR. Thus, the packet loss is proportional to tunnel establishment interval and buffer excess at the nMAAR (see Fig. 7) [18, 19]. Hence, the packet loss is expressed as the sum of the transmitted packets before the buffering start, and the packets that exceed the buffering size:
( ( ) (( 2 ) ) ( ( ))
Buffering MU MAAR L Auth MAAR MAAR
T = d − c + T +T − −x d − d (9)
{ } { }
(max ( ) ) , 0 max , 0 )
proposed d MU MA A R HI Buffering
PL =λL d − c +T −φ + T −B (10)
where B represents the buffer size.
Fig. 7. Handover Operation Timeline of the Network-based DMM Proposed Solution.
Fig. 6. Handover Operation Timeline of the IETF Proposal.
- 136 -
V. NUMERICAL RESULTS AND DISCUSSION
This section presents and discusses the numerical results of the performance analysis introduced in the former section. It studies several parameters impact on the handover performance. The default parameter values are obtained from Hossain, M. S. et al. [20, 21], Rayu S. et al. [22], Ali-Ahmad et al. [7], and Giust, F. et al. [8]. The default parameter values are as follows: TL2= 330ms, TAuth= 100ms, Lc= 80bytes, Lp= 400bytes, BW= 100 Mbps, BWw= 10 Mbps, l= 0.5ms, lw= 2ms,
CMD
TPC = 20ms, TPCMA A R= 10ms, Pf= 0.5, r= 1000m, ൌ35ms, B=500 KB.
A. Handover Latency:
To study the handover latency, we vary separately the values of r, , and Pf. The handover latency of the proposed network-based DMM solution, as shown in the results, is reduced considerably comparing to IETF proposal.
Fig. 8. The Impact of r (radius of cells) on the Handover Late.
Fig. 8 illustrates the effect of different transmission technology ranges (e.g., 802.11p, WiMax, LTE) by varing the value of cell’s radius r 1000 to 6000 m. varying the transmission range varies the number of cells NS from 285 to 4. The average number of hops between routers, as a result, will increase and accordingly the handover latency will be affected. Thus, stretch the cell’s radius reduces the handover latency of IETF proposal slightly by due to the reduction of the average number of hops, while it has no impact on the handover latency of the propoed network-based DMM because there is no signaling exchanged between the routers during the handover. Howevre, the effect of number of hops will be more considerable on IETF proposal in the scenario when the MU roams more than once to different MAARs with active flows.
There is a probability during the handover procedure of the proposed solution that the MU’s Link with S-the MAAR drops before the MU receives the handover command. The S- MAAR, at that point, already knows the nMAAR and it is carrying out the HO-Initiate procedure. The proposed solution takes around 0.035 second to perform HO-Initiate process (i.e., from receiving L2 report until sending the handover command to the MU). To inspect the efficiency of the
proposed solution, we investigated this probability by varying the value of between 0.005 and 0.035 second.
Fig. 9. The Impact of (time between receiving L2 report till link goes down) on the Handover Latency.
In Fig. 9, the handover latency of the proposed solution rises slightly once the L2 link drops before the MU receives the handover command (i.e., reducing the value of ). On other hand, varying the value of does not impact on IETF proposal because the handover procedure starts after L2 link goes down.
Fig. 10. The Impact of Pf (probability of wireless link fail), on the Handover Latency.
The wireless link failure probability Pf, as shown in Fig.
10, is varied from 0 to 0.8. The Pf has no effect on the proposed solution while the handover latency of IETF proposal raises a little because the messages exchanged between MAAR and MU (i.e. RS and RA messages).
B. Packet Loss:
The same parameters are varied to examine their impact on the packet loss. Fig. 11 shows the impact of the cells’ radius on the packet loss. The figure shows that increasing cells’
radius decreases the packet loss of IETF proposal, while it has no effect on the proposed solution. This is because that the average number of hops decreases by increasing cells’ radius
Fig. 8. The Impact of r (radius of cells) on the Handover Latency.
Fig. 9. The Impact of (time between receiving L2 report till link goes down) on the Handover Latency
Fig. 10. The Impact of Pf (probability of wireless link fail), on the Handover Latency
and as a consequence the session recovery time decreases. The IETF proposal does buffer the packets destined to the MU, thus, the packet loss is proportional to the session recovery time only. On the contrary, the proposed solution buffers the packets destined to the MU and hence there is no packet loss if the data traffic does not surpass the buffering size.
Fig. 11. The Impact of r (radius of cells) on the Packet Loss.
Fig. 12 shows that there is packet loss in the proposed solution when the L2 link drops before completing the HI process. This is because the buffering at nMAAR has not been initiated yet.
Fig. 12. The Impact of (time between receiving L2 report till link goes down) on the Packet Loss.
The packet loss as mentioned before proportions with the session recovery time when there is no buffering mechanism is employed. Once the wireless link failure probability increases, the session recovery time of the IETF proposal increases slightly due to the possible transmission failure while forwarding data traffic to the MU through wireless link.
Therefore, as shown in Fig. 13, the packet loss of IETF proposal increases.
Fig. 13. The Impact of Pf (probability of wireless link fail), on the Packet Loss.
VI. CONCLUSION
This article presents a network-based DMM solution based on PFMIPv6. The proposed solution distributes the functionalities of PFMIPv6 protocol with some modification in the key terms, message formats, and functionalities. The S- MAAR starts the handover procedure proactively by initiating HO-initiate process. In order to further improve the performance during the handover, we specify a buffer technique at the nMAAR to buffer packets meant for the MU.
We developed an analytical model to evaluate the proposed solution comparing to DMM. We can conclude from the analysis that the proposed solution reduces the handover latency and the packet loss significantly comparing to IETF proposal. Increasing the time between receiving report message and when the MU’s link goes down increases the handover latency of the proposed solution.
REFERENCES
[1] Cisco White Paper. (2014). Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2013–2018.
[2] IETF DMM WG. http://datatracker.ietf.org/wg/dmm/charter/.
[3] P. Seite, D. Liu, H. Yokota, J. Korhonen, and H. A. Chan,
“Requirements for distributed mobility management,” IETF RFC 7333, 2014.
[4] C. Bernardos, A. Oliva, and F. Giust, “An IPv6 Distributed Client Mobility Management approach using existing mechanisms,” draft- bernardos-dmm-cmip-03 (work in progress), March 2015.
[5] J. Lee, “PMIPv6-based distributed mobility management,” Draft- jaehwoon-dmm-pmipv6-04 (work in progress), June 2015.
[6] F. Giust, and M. Liebsch, “Deployment of Control-/Data-Plane separation in DMM,” draft-giust-dmm-cpdp-deployment-00. (work in progress), July 2015.
[7] H. Ali-Ahmad, M. Ouzzif, P. Bertin, and X. Lagrange, “Distributed mobility management: Approaches and analysis,” 2013 IEEE international conference on Communications workshops (ICC), pp.
1297–1302, 2013.
[8] F. Giust, C. J. Bernardos, and A. Oliva, “Analytic evaluation and experimental validation of a network-based IPv6 distributed mobility management solution,” IEEE Transactions on Mobile Computing, vol.
13, pp. 2484–2497, 2014.
[9] M. Balfaqih, M. Ismail, R. Nordin, and Z. Balfaqih, “Proxy mobile IPv6 Handover management in vehicular networks: State of the art, taxonomy Fig. 11. The Impact of r (radius of cells) on the Packet Loss.
Fig. 12. The Impact of (time between receiving L2 report till link goes down) on the Packet Loss.
Fig. 13. The Impact of Pf (probability of wireless link fail), on the Packet Loss.
- 138 -
and directions for future research,” Wireless Personal Communications, vol. 84, pp. 1509–1534, 2015.
[10] M. Balfaqih, M. Ismail, R. Nordin, A. Rahem and Z. Balfaqih, “Fast handover solution for network-based distributed mobility management in intelligent transportation systems,” Telecommunication Systems, pp.
1-22, 2016.
[11] H. Yokota, K. Chowdhury, R. Koodly, B. Patil, and F. Xia, “Fast handovers for proxy mobile IPv6,” RFC 5949, 2010.
[12] P. Seite, P. Bertin, J. H. Lee, “Distributed mobility anchoring,” IETF draft-seite-dmm-dma-07 (work in progress), February 2014.
[13] H. Ali-Ahmad, K. Munir, P. Bertin, K. Guillouard, M. Ouzzif, and X.
Lagrange, “Processing loads analysis of distributed mobility management and SIP-based reachability,” Telecommunication Systems, pp. 1-16, March 2016.
[14] Bernardos C., Oliva A. de la, and Giust F. “A PMIPv6-Based Solution for Distributed Mobility Management,” Internet-Draft (Work in Progress), draft-bernardos-dmm-pmip-04, March 2015.
[15] P. P. Ernest, O. E. Falowo, and H. A. Chan, “Network-based distributed mobility management: Design and analysis,” IEEE 9th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob), 2013.
[16] L. Yi, H. Zhou, D. Huang, and H. Zhang,, “D-PMIPv6: A distributed mobility management scheme supported by data and control plane separation,” Mathematical and Computer Modelling, vol. 58, pp. 1415- 1426, 2013.
[17] R. Koodli, “Mobile IPv6 Fast Handovers,” IETF RFC 5568, July, 2009.
[18] K. Mun-Suk, L. SuKyoung, D. Cypher and N. Golmie, “Fast Handover Latency Analysis in Proxy Mobile IPv6,” IEEE Global Telecommunications Conference (GLOBECOM 2010), 2010.
[19] K. Mun-Suk, L. SuKyoung, C. David and G. Nada, “Performance analysis of fast handover for proxy Mobile IPv6,” Information Sciences, vol. 219, no. 0, pp. 208-224, 2013.
[20] M. S. Hossain, and M. Atiquzzaman, “Cost analysis of mobility protocols,” Telecommunication Systems, vol. 52, pp. 2271-2285, 2013.
[21] M. S. Hossain, and M. Atiquzzaman, “Stochastic Properties and Application of City Section Mobility Model,” IEEE Global Telecommunications Conference (GLOBECOM 2009), 2009.
[22] S. Rayu, K. J. Park, and J. W. Choi, “Enhanced Fast Handover for Network Mobility in Intelligent Transportation Systems,” IEEE Transactions on Vehicular Technology, vol. 63, pp. 357-371, 2014.
