Fast handover solution for network-based distributed mobility management in intelligent transportation systems

(1)

Fast handover solution for network-based distributed mobility management in intelligent transportation systems

Authors Balfaqih, Mohammed; mahamod, ismail; Rosdiadee, Nordin; Abd Alrazak, Rahem; balfagih, zain

Publisher Springer US

Download date 21/06/2023 04:13:14

Link to Item http://hdl.handle.net/20.500.14131/732

(2)

Some of the authors of this publication are also working on these related projects:

Master dissertationView project

Heterogeneous Coexistence in TV White Space (TVWS) Using Time Series Financial Predictive Model for Rural Broadband Wireless NetworkView project Universiti Kebangsaan Malaysia

34PUBLICATIONS 392CITATIONS SEE PROFILE

Universiti Kebangsaan Malaysia 694PUBLICATIONS 7,072CITATIONS

SEE PROFILE

Rosdiadee Nordin

Universiti Kebangsaan Malaysia 273PUBLICATIONS 4,356CITATIONS

SEE PROFILE

Abd Alrazak Tareq Rahem Universiti Kebangsaan Malaysia 28PUBLICATIONS 149CITATIONS

SEE PROFILE

(3)

DOI 10.1007/s11235-016-0178-y

Fast handover solution for network-based distributed mobility management in intelligent transportation systems

Mohammed Balfaqih¹ · Mahamod Ismail¹ · Rosdiadee Nordin¹ · Abd Alrazak Rahem¹ · Zain Balfaqih²

Abstract The current IP mobility protocols are called centralized mobility management (CMM) solutions, in which all data traffic and management signaling messages must be forwarded to an anchor entity. In some vehicle scenarios, vehicles may move as a group from one roadside unit to another (i.e., after traffic lights or traffic jams). This causes data traffic and exchanged mobility messages to peak at the anchor entity and, consequently, affects the network performance. A new design paradigm aimed at addressing the anchor entity issue is called distributed mobility management (DMM); it is an IETF proposal that is still being actively discussed by the IETF DMM working group. Nev- ertheless, network-based DMM is designed based on the well-known network-based CMM protocol Proxy Mobile IPv6 (PMIPv6). There is no significant difference between network-based DMM and PMIPv6 in terms of handover latency and packet loss. Because vehicles change their roadside unit frequently in this context, the IP addresses of mobile users (MUs) require fast IP handover management to configure a new IP address without disrupting ongoing

B

Mohammed Balfaqih [email protected] Mahamod Ismail [email protected] Rosdiadee Nordin [email protected] Abd Alrazak Rahem [email protected] Zain Balfaqih

[email protected]

1 Department of Electrical, Electronic and System Engineering, Faculty of Engineering, UKM, Bangi, Malaysia

2 Department of Information System, Faculty of Engineering, Effat University, Jeddah, Saudi Arabia

sessions. Thus, this paper proposes the Fast handover for network-based DMM (FDMM) based on the Fast Handover for PMIPv6 (PFMIPv6). Several modifications to PFMIPv6 are required to adapt this protocol to DMM. This paper specifies the necessary extensions to support the scenario in which an MU has old IP flows and hence has multiple anchor entities. In addition, the analytic expressions required to evaluate and compare the handover performance of the proposed FDMM and the IETF network-based DMM have been derived. The numerical results show that FDMM outperforms the IETF network-based DMM in terms of handover latency, session recovery and packet loss at the cost of some extra signaling.

Keywords DMM·PMIPv6·Fast handover·Performance analysis·IP Mobility in VANET·V2I

1 Introduction

The rapid growth in modern mobile user devices has led to aggressive use of network resources and has dramatically increased network traffic loads. In parallel, wireless/mobile technologies for next generation networks will be unified networks based on IP technology. The Cisco VNI report [1]

stated that IP traffic represented 41 % of wireless device traffic in 2012 and estimates that figure will rise to 55 % by 2017. Thus, IP mobility management protocols play a critical role in providing the unified and ubiquitous services envisaged by future wireless networks—including vehicular networks.

In a vehicle environment, multiple factors such as build- ings, trees, multiple intersections and traffic road situations can affect network performance. The high-speeds and large numbers of mobile users (MUs) on the road (i.e., one vehicle

(4)

and reuse the IETF standard protocols because reuse is both more efficient and less error-prone [4]. Thus, most of the DMM solutions are designed based on existing IETF CMM protocols. Similar to CMM solutions, DMM solutions are categorized based on whether the MUs are involved in an IP mobility process or not into host-based and network-based, respectively. Previous works have extended the MIPv6 protocol as host-based DMM solutions [5] and extended the PMIPv6 protocol as network-based solutions [6,7]. However, network-based DMM solutions have superior performance compared to host-based DMM solutions [8].

Adapting network-based DMM in the context of Intelli- gent Transportation Systems (ITSs) faces several problems.

One is that during vehicle roaming, a network-based DMM has high handover latency and long session recovery time, which cause high levels of packet loss. This is because a network-based DMM initiates the handover process reac- tively when an MU attaches to a new Mobile Anchor and Access Router (nMAAR).

This article proposes a network-based DMM approach that is an extension of the Fast Handover for Proxy Mobile IPv6 (PFMIPv6) protocol called Fast handover for DMM (FDMM). The PFMIPv6 protocol was standardized in [9] to reduce handover latency, improve session recovery time, and avoid the packet loss of PMIPv6. FDMM employs both new and revised functions as well as messages from its normative PFMIPv6 protocol. FDMM specifies a bidirectional tunnel between the Serving MAAR (S-MAAR) and the nMAAR to tunnel an MU’s packets. This allows the MU to send packets as soon as it attaches to an nMAAR and receives a packet meant for it. Two operation modes have been introduced: predictive (pre-FDMM) mode and reactive (re-FDMM) mode.

The handover performance of FDMM is analytically eval- uated by studying the handover latency, session recovery, packet loss and signaling cost compared to the IETF network- based DMM.

The main contributions of our work are as follows:

• Reducing handover latency and session recovery time by proposing the HO-Initiate process between MAARs.

• Reducing packet loss by introducing buffering at the nMAAR when a handover occurs.

work. Note that throughout the paper, the terms MU and vehicle are used interchangeably because a vehicle may carry multiple MUs.

2 Related work

Extending and adapting the existing CMM mobility protocols to support DMM eases backward compatibility and facilitates network architecture migration. Comparative analysis studies [10–13] have shown that network-based CMM protocols outperform host-based CMM protocols. Thus, extending network-based protocols to support DMM is better than extending host-based protocols [8]. The network-based solutions considered from the previous studies were found by searching for the keywords (‘Distributed mobility management’ and ‘PMIPv6’) in specific databases, such as IETF, ISI Web of Science and Scopus. Searching these keywords resulted in 7 documents in IETF, 29 articles in the ISI Web of Science and 93 articles in Scopus. The duplicated articles in these two databases were eliminated, resulted in 97 final articles. Figure1shows the employed review methodology to identify the considered related works. Applying the review methodology has helped in extracting the most relevant 10 articles for the scope and objectives of this paper.

The 97 articles were further scrutinized based on problem scope, solution approach and evaluation method. The scope of theses articles address different problems including mobility management, flow management, route optimiza- tion, security and comparative analysis study. The considered related works, in this paper, fall within the solutions addressing the mobility management problem. These considered articles were classified based on the distributions of the control and data planes into two categories: partially distributed solutions and fully distributed solutions.

2.1 Partially distributed solutions

The main concept of the partially distributed solutions is to keep the control plane centralized and distribute the data plane among several anchors. In [14], the authors introduced an early partially distributed proposal for network-based

(5)

Fig. 1 Related work selection methodology

DMM called Dynamic Mobility Anchoring (DMA). In this scheme, the mobility management functionalities are shifted to a new entity called Mobility-capable Access Router (MAR), which has Mobile Access Gateway (MAG) functionalities as well. The proposed approach relies on a database (DB) to store current mobility sessions and allocate network prefixes to MUs and their respective MARs. Upon handover, the new MAR retrieves the IP address information of the anchoring MARs from the DB. Then, the new MAR proceeds with the binding update process. However, the signaling cost and handover latency of this scheme are high compared with methods in which the central entity works as a proxy to process the binding update process, as was proposed in [15].

Another partially distributed approach based on PMIPv6 was introduced in [16], named D-PMIPv6. Using this approach, the functions of the Local Mobility Anchor (LMA) are separated into two entities: (i) Control plane LMA (CLMA) and (ii) Data plane LMA (DLMA). The former manages binding registration and selects a DLMA for each MU, while the latter forwards data traffic. The MAG still manages the mobility related signaling messages on behalf of the MU and tracks movement just as in PMIPv6. Although the proposed approach may relieve the burden on the LMA, it maintains the tunnel and hierarchy architecture between the DLMA and the MAG during a whole data session. Thus, it is not a good fit with the flat architectures required.

Hybrid centralized-distributed DMM (H-DMM) architecture was introduced as another partially distributed approach in [17]. The proposed approach capitalizes on existing CMM and DMM solutions by intelligently combining the IETF network-based DMM [15] and PMIPv6 protocols to employ the appropriate protocol based on flow characteristics and the number of active prefixes. The MU obtains two different prefixes: one from the S-MAAR and another from the LMA;

the former prefix is changed with every handover, while the latter remains the same. However, the authors did not identify how to determine or select the most applicable protocol.

Another hybrid centralized-distributed DMM scheme, known as the dynamic tunneling scheme, was proposed in [18]. The proposed scheme introduced two mobility anchors:

(i) Access Mobility Anchor (AMA), which has the functionality of MAG and was extended to allocate a prefix to the MU, and (ii) LMA, which has the functionality of PMIPv6’s LMA and is responsible for establishing tunnels with AMAs on request. The session-to-mobility ratio is utilized at AMAs to determine how to establish tunnels for an MU. Tunnel establishment remains between AMAs as long as the session- to-mobility ratio is lower or equal to a certain threshold;

otherwise, the MU’s AMA establishes a tunnel for the MU using the LMA. However, this scheme suffers from the draw- backs of roaming between LMAs during a mobility session, which is not recommended by the IETF [19,20]. In addition, this scheme may cause a significant service disruption because of the need to update the new anchor location of the prefix used by the current flows.

2.2 Fully distributed solutions

The main concept of the fully distributed solutions is to distribute both the control and data planes. In [6], the Fully DMM (F-DMM) method was proposed, which allocates a unified network prefix to the PMIPv6 domain with different sub-network prefixes for different MAGs. The functionality of an LMA is distributed among all MAGs that advertise the same network prefix, and each MU determines its address using a stateful address configuration. However, the proposed approach requires solid control of IP addressing.

Another fully distributed approach based on PMIPv6 and IEEE 802.21 Media Independent Handover (MIH) protocols, named F-DMM, was proposed in [21]. The authors suggested employing MIH Functions (MIHF) to update the nMAAR with the S-MAAR and AnchorMAAR (AMAARs) upon a handover. The performance analysis results show that the F- DMM reduces handover latency and packet loss compared

(6)

Fig. 2 IETF network-based DMM initial registration operation [15]

to partially distributed DMM and CMM. Nevertheless, the proposed method lacks details of how the Media Indepen- dent Information Server (MIIS) obtains information about neighboring networks. In addition, F-DMM initiates the pre- handover process only after the link condition is degraded, when it is likely that the MU will not be connected to the S-MAAR long enough to send and receive BU messages.

Among these solutions, the authors in [22] introduced one of the most promising proposals for the IETF network-based DMM, which they published later in [15]. The proposed solution facilitates the partially distributed approach and has been extended to facilitate the fully distributed approach as well.

The next section explores the IETF network-based DMM operations on which our proposed solution FDMM relies.

3 IETF network-based DMM

The IETF network-based DMM distributes the LMA’s functions between all access routers, i.e., the MAARs. DMM employs the concept of a “flatter” system where the anchor entity is placed dynamically closer to the MU. Two main approaches have been identified to design the IETF network- based DMM: (i) the partially distributed approach and (ii) the fully distributed approach.

In the partially distributed approach, the LMA’s data plane is distributed only among MAARs, while the control plane is kept centralized in a Centralized Mobility Database (CMD). The CMD handles mobility session management by exchanging Proxy Binding Update (PBU) and Proxy Binding Acknowledgment (PBA) messages with MAARs. A MAAR maintains a local Binding Cache Entry (BCE) of the MUs attached to it. Each MAAR has a unique set of global IPv6 prefixes called a Local Network Prefix (LNP), which it allocates to MUs upon attachment.

On the other hand, the fully distributed approach distributes both the control and data planes among MAARs.

However, there is no much difference between DMM and

PMIPv6 protcols in terms of handover latency and packet loss [23]. The following sub-sections provide more detailed information about network-based DMM operations by describing the initial registration and the handover process.

3.1 Initial registration

When an MU joins a subnet, it sends a Router Solicitation (RS) message to the responsible MAAR (MAAR1 in Fig.2).

The MAAR assigns an exclusive LNP (pref1::MU1/64) to the MU and creates a local BCE for that MU containing the MU-ID, the LNP and other useful parameters. Then, it sends a PBU to the CMD to initiate a new mobility session and create its BCE. After the CMD replies with a PBA, the MAAR sends a Router Advertisement (RA) message to the MU containing the assigned LNP so it can configure an IPv6 address. Subsequently, that MAAR (MAAR1 in Fig.2) is the S-MAAR as long as the MU is attached.

3.2 Handover management

The handover procedure starts when the MU moves to a different MAAR (MAAR2 in Fig. 3). The MU, as shown in Fig. 4, will send a router solicitation message to the nMAAR, which reserves another an LNP for the MU from its unique set of prefixes and stores a temporary BCE.

Then, the nMAAR requests the CMD via a PBU message to register the MU. Upon PBU reception, the CMD will update its BCE, replacing the S-MAAR’s address field with MAAR2’s address and adding MAAR1’s address into the Anchor MAAR (AMAAR) list field. The CMD replies to the nMAAR with an extended PBA containing the AMAAR’s address and the corresponding previous LNP (pLNP). After the nMAAR receives this PBA, it sends an RA message advertising the new LNP (nLNP) allocated to the MU.

The MU will configure a new IP address (Pref2::MU1/64).

The nMAAR establishes a tunnel towards all AMAARs to

(7)

Fig. 3 First roaming scenario in the IETF network-based DMM [15]

Fig. 4 Signaling flow of the IETF network-based DMM handover management operation in first roaming [15]

handle the traffic of previous LNPs (pLNPs, Pref1::/64 in our example). In parallel with the previous procedure, the CMD exchanges PBU and PBA messages with active AMAARs (MAAR1 only in our example) to notify them of the new MU location. In turn, they will update their local BCE and modify the tunnel towards the nMAAR. Thereafter, the active IP flows using pLNP will be anchored at MAAR1 while new flows using nLNP will be routed by the nMAAR to the MU without any special packet handling.

DMM is dynamic mobility; thus, this handover procedure takes place only if the old IP flows require session continuity (e.g., an application with a long life that cannot survive an IP address change). When the MU moves again, to MAAR3 as shown in Fig.5, the handover procedure is repeated. In such a scenario, the MU will have several simul- taneous IP flows anchored at different MAARs. The siganllig flow of handover operation in second roaming is shown in Fig.6.

4 The fast handover for IETF network-based DMM (FDMM) solution

In the IETF network-based DMM, the MAAR is responsible for initiating the MU’s binding registration with the CMD.

Thus, it is possible to improve the handover procedure if the MAARs are informed of the pending attachment of an MU in a timely manner. We propose a solution to shorten the handover latency by performing movement detection and the binding registration process in advance. In addition, we propose a buffering mechanism to reduce packet loss by buffering any packets intended for the MU at the nMAAR.

Our proposed FDMM solution is derived from the existing architecture of PFMIPv6, with some modifications in the key terms, message formats, and functionalities. FDMM consid- ers the protocol operation and does not consider issues such as radio access network discovery and candidate MAAR discovery (i.e., how the MAAR could map the LNPs with the correspondingL2 identifier).

We introduce two operation modes as defined in PFMIPv6:

reactive-FDMM (re-FDMM) mode and predictive-FDMM (pre-FDMM) mode. FDMM supports both the fully and partially distributed IETF network-based DMM architectures proposed in [15] because the CMD is not involved in the handover management operation. The following sub-sections define the FDMM messages and mobility options and provide more detail concerning the handover management operation.

4.1 FDMM messages

To enable the nMAAR to register the MU and recover the old sessions, the Handover Initiate (HI) and Handover Acknowledge (HAck) messages in [9] are extended for context transfer, in which parameters such as MU-ID, MU’s LNPS, S-MAAR address, CMD and the routing state table

(8)

Fig. 5 Second roaming scenario in the IETF Network-based DMM [15]

Fig. 6 Signaling flow of the IETF Network-based DMM handover management operation at second roaming [15]

are transferred from the S-MAAR. In addition, we defined different mobility options such that one or more mobility options can be included in the HI and HAck messages.

A. Handover initiate message (HI)In pre-FDMM mode, this message is delivered to the nMAAR and AMAARs (if any), whereas in re-FDMM mode, it is delivered to the S-MAAR and AMAARs (if any). Distributed (D) and Target type (T) flags are added to the message format defined in PFMIPv6. The D flag is used to distinguish the messages from those defined in [9] and must be set to one in all new messages using the proposed extension.

The T flag is used to distinguish whether the destination is the nMAAR (value of 0), AMAAR (1) or S-MAAR (2).

B. Handover acknowledge message (HAck)This message is sent by the nMAAR or the AMAARs to acknowledge receipt of the HI message. Just as defined in the HI message, the D and T flags are also present in the HAck message.

The included mobility options in HI and HAck differ depending on the required information. The defined mobility options are as follows:

(i.) Context request option This option is sent in the HI message to request context information from the MU and is most useful for retrieving additional or dynamically selected context information. The Context Request option is typically used for re-FDMM mode (nMAAR-initiated) to retrieve the context information from the S-MAAR. When this option is included in the HI message, all the requested context information should be included in the Hack message in the corresponding mobility option(s) (e.g., pLNP(s), AMAAR(s), CMD, or MU LL-ID mobility options).

(ii.) Central mobility database (CMD) optionThis option is used to transfer the CMD Address (CMDA) with which the MU is currently registered.

(iii.) Mobile user link-local address interface identifier (MU LLA-IID) optionThis option is used to transfer the interface identifier of the MU’s IPv6 Link-local Address

(9)

used in the pAN. In deployments where the interface identifier is assigned by the network or is known to the network, this option is used to transfer this identifier from the S-MAAR to the nMAAR.

(iv.) Local network prefix optionThis option is used to transfer the Local Network Prefix (LNP) that is assigned to the MU in the S-MAAR and AMAAR(s).

(v.) Link-local address option This option, as defined in [24], is used to transfer the link local address of the S-MAAR.

(vi.) Anchor MAAR option This new option is defined for use with the HI, HAck, PBU and PBA messages. This option is used to notify the nMAAR or CMD about the AMAAR’s global address and the pLNP anchored to it. There can be multiple AMAAR options present in the message.

(vii.) New MAAR optionThis new option is defined for use with the HI, HAck, PBU and PBA messages. It is used to notify the AMAAR, S-MAAR or CMD about the nMAAR’s global address to update the BCE and routing state.

4.2 Handover management operation 4.2.1 Predictive mode

The handover operation in pre-FDMM mode starts when the Received Signal Strength (RSS) of the MU with the serving Access Network (sAN) decreases to less than the predefined threshold Sth. The MU then discovers a new AN (nAN) (e.g., by scanning neighboring ANs. The nAN will be the one from which the MU receives the strongest signal). The MU, as shown in Fig.7, sends an L2 report message containing its ID and the nAN’s ID to its S-MAAR (MAAR1 in the example shown in Fig.3). Upon receiving the report message, the S- MAAR derives the nMAAR from the (AN ID, MAAR info) tuple in the report message, similar to that described in [25].

A Layer 2 handover will be executed if the MU is moving within the same MAAR; otherwise, if the MU is moving towards another MAAR, the S-MAAR sends a HI message with a zero value for the ‘T’ flag and a value of 1 for the ‘D’

flag to the nMAAR containing the MU-ID and the MU’s LNP (i.e., Pref1::/64). The ‘D’ flag indicates that it is a distributed extension, while the ‘T’ flag indicates that the HI message is for the nMAAR. The CMD and MU LLA-IID options are included in the HI message.

Upon receiving the HI message, the nMAAR assigns the MU’s nLNP (Pref2::/64) and stores it in a temporary BCE allocated locally. The nMAAR also updates the routing state.

The previously assigned LNP is now referred to as the MU’s pLNP, and the corresponding MAAR (MAAR1) acts as the AMAAR for that LNP. Then, the nMAAR replies with the HAck message and piggybacks the allocated LNP to the

Fig. 7 Signaling flow of pre-FDMM handover management operation at first roaming

S-MAAR to ensure that the new location has successfully changed and that the routing state has been updated.

A bidirectional tunnel is established between the S- MAAR and the nMAAR; packets destined for the MU are forwarded from the S-MAAR to the nMAAR over this tunnel. Note that traffic destined for any of the MU’s prefixes (i.e., from more than one handover) will be forwarded to the nMAAR. The nMAAR starts buffering when it receives data traffic.

When the handover is ready on the network side, the MU is triggered to perform the handover to the nAN. The S-MAAR advertises the allocated LNP to the MU in the handover command message, which then configures a new IP address (Pref2::/64). Additionally, Pref1::/64 is deprecated by advertising it with a 0 second preferred lifetime. The MU establishes a physical-layer connection with the nAN (e.g., radio channel assignment), which in turn triggers the establishment of a link-layer connection between the nAN and the nMAAR, if that has not yet been established. In this way, old IP flows using Pref1::/64 are still active and anchored at MAAR1, but new flows use Pref2::/64, which is the LNP routed by MAAR2 without any special packet handling required for either uplink or downlink (see Fig.7).

The nMAAR then sends the PBU to the CMD with the New MAAR and Anchor MAAR options. Upon PBU reception and BC lookup, the CMD retrieves any already existing entry for the MU and updates the MU’s binding cache entry,

(10)

Fig. 8 Signaling flow of pre-FDMM handover management operation at second roaming

replacing the S-MAAR’s address with MAAR2’s, and adds the previous location (MAAR1’s address) into the AMAAR’s list field along with the pLNP assigned by MAAR1. The CMD sends back the PBA to the nMAAR. From this point forward, packets to/from the MU go through MAAR2 instead of MAAR1, and MAAR2 becomes the new S-MAAR.

The next time the MU moves, the process is repeated, except that the number of AMAARs involved rises according to the number of pLNPs that the MU wishes to maintain.

Indeed, the Anchor MAAR option is added in the HI message to notify the nMAAR about the AMAAR’s global address and their corresponding pLNPs (see Fig.8). In addition, the nMAAR sends a HI message with a ‘T’ flag value of 1 to the AMAAR(s) that contains the MU-ID and nMAAR address.

The New MAAR option is included in the HI message to notify the AMAARs about the nMAAR’s global address. The AMAARs update their routing states by setting the nMAAR as the next hop. Inactive AMAARs will be de-registered during the exchange of binding messages with the CMD.

4.2.2 Reactive mode

The MU undergoes a handover from the sAN to the nAN.

The MU establishes a connection (e.g., radio channel) with the nAN, which triggers the establishment of a connection between the nAN and the nMAAR. At this step, the MU ID is transferred to the nMAAR for the subsequent proce- dures. The AN-ID on the old link (Old AN ID), which will

Fig. 9 Signaling flow of re-FDMM handover management operation at first roaming

be provided by either the MU or the nAN, is also transferred to the nMAAR to help identify the S-MAAR on the new link.

The signaling flow of the handover procedure at first roaming is shown in Fig.9. The nMAAR sends the HI message to the S-MAAR. The HI message has the ’D’ and ‘T’ flags set and includes the MU ID. The value of the ‘T’ flag is set to 2, indicating that the destination was the S-MAAR. The Context Request option is included to request the context information of the MU from the S-MAAR. The S-MAAR sends the HAck message back to the nMAAR with the ’D’

and ‘T’ flags set and includes the MU-ID, the MU’s LNP (i.e., Pref1::/64), the MU LL-ID, (only when it is valid—i.e., non-zero), and the CMD address currently serving the MU.

The context information requested by the nMAAR must be included. A bidirectional tunnel is established between the S-MAAR and the nMAAR, and packets destined for the MU are forwarded from the S-MAAR to the nMAAR over this tunnel. The rest of the process and the data traffic flows will be handled in the same way as was defined in the discussion of predictive mode.

For future MU movements, the process is repeated, except for the AMAARs involved. After the S-MAAR sends the HAck message to the nMAAR, it will add the AMAAR mobility option containing the AMAAR’s address and the corresponding pLNP (See Fig. 10). Then, the nMAAR sends the HI message with the ‘T’ flag set to 1 to the AMAAR(s) containing the MU-ID and the New MAAR option. The AMAARs update their routing state by setting the nMAAR as the next hop and reply with the HAck message.

(11)

Fig. 10 Signaling flow of re-FDMM handover management operation at second roaming

5 Performance analysis

We developed analytical models to study the handover performance of FDMM compared to the IETF network-based DMM. In the following analysis, we considered various aspects including handover latency, session recovery, packet loss, handover failure probability and signaling cost. Analy- sis of these metrics is useful for assessing the handover performance of our proposed solution by considering different system parameters. In the past, this type of analysis has received much attention, starting during the develop- ment of cellular networks [26–29] and then being applied to handover and mobility management in IP-based networks [30,31]. Notations used in the analysis are listed in Table1.

The related assumptions of our analytical models are as follows (see Fig.11):

(i.) We assume that the wireless network is composed of statistically identical cells. Each cell is hexagonal and has the radiusrof its circumscribed circle. We consider the worst case, in which each cell is a different IP-subnet (SN).

(ii.) BeyondDdistance from the boundary of the S-MAAR, the RSS from the S-MAAR drops below St h. Based on the corresponding value of St h, the value of D is obtained using the path loss model, calculated as

Pr(D) = Pr(D0)

D0

D

e

[32,33], where Pr(D0) is the received power at a known reference distance D0

andeis the path loss exponent. The typical value ofe varies between 2 and 5 based on environmental condi- tions [33].

(iii.) The MU is able to receive theRSSfrom the nMAAR at distance D(i.e., the MU moves out of the area ofH^‘) while it can still receive the RSSfrom the S-MAAR.

The MU can receive the signal from the S-MAAR if the R S S>Smi n.

(iv.) The MU decides to perform the HO-Initiate process to roam to the nMAAR when theRSSfrom the S-MAAR drops belowSt h.

(v.) Buffering occurs at the nMAAR after receiving the data traffic from the S-MAAR. Additionally, for the sake of simplicity, we consider the session in the downstream direction.

(vi.) The vehicle moves away from the home MAAR (i.e., first MAAR it is attached to). This increases the MAAR- MAAR hop number (i.e., hMAAR−MAAR)between the S-MAAR and nMAAR every time a handover occurs.

Additionally, we consider that hCMD−MAARis the same for all MAARs because the differences are negligi- ble. This assumption is the worst-case scenario for our proposed solution because the signaling cost increases exponentially, as shown later.

5.1 Analytical models

We consider an environment consisting of a rectangular area with dimensionsX*Y, as shown in Fig.11. TheSNcoverage in this area equals n*m. The radio coverage area of each cell is hexagonal, andr is the radius of its circumscribed circle. Therefore, any two successive cells overlap at lengths of lx andly along their horizontal and vertical diameters, respectively. Then,

(12)

ξ Network scale U_max Maximum pause time

¯

ν Average speed of the MU μS N Subnet (i.e., cell) average crossing rate

T_{S N} MU’s average residence time in a cell T_{P R} Active prefix lifetime

¯

T_{P R} Mean value ofT_{P R} T_{P R}^H Active prefix lifetime while the MU is attached to

the prefix home network (prefix used as LNP) T_{P R}^F Active prefix lifetime while the MU is visiting a

foreign network (the prefix is used as pLNP)

1/λ^FP R Mean value ofT_{P R}^F

¯

N_{P R} Average number of used active prefixes N¯_{pL N P} Average number of active anchored prefixes.

α (H) Probability that H handovers occur during the intervalT_{P R}^F

E(L) Expected epoch length

E(T) Expected epoch time E(P) Expected pause time

L₂ Layer2 handoff latency L_{Aut h} Authentication latency

L_c Average control packet size L_d Average data packet size

BW_w Bandwidth of the wireless link BW Bandwidth of the wired link

l_w Wireless propagation latency l Wire propagation latency

p_f Probability that the wireless link fails PC_x Processing time by node x

C_x_,_y Symmetric cost to transfer a packet between network nodesxandy

d_x_,_y(p) Symmetric delay of a packet of sizepsent fromxtoy

λ Sessions arrival mean rate to an MU

Fig. 11 System model for handover analysis

(13)

X =(2r∗m)−((m−1)∗lx) (1) Y =(2r∗n)−

(n−1)∗ly

(2)

where

lx =2(r−a)=2

r−

r

√3 2

=r

2−√ 3

and

ly =

r²−a²= r²

1−3 4

=r 2 Therefore,SNis obtained by

S N =m∗n=

X−2r−r√ 3 r√

3

∗

2Y−r 3r

(3) We consider the scenario where the MU and the CNs are in the same domain. The CNs are non-mobile for simplicity. Figure11shows the system model of our analysis. The network scaleξis defined here as the ratio between the number of hops between two MAARs and the number of hops between an MAAR and the CMD:

ξ =hM A A R,M A A R/hM A A R,C M D (4) wherehM A A R,M A A R=√

S N.

The average number of hops between two neighboring MAARs is less than that between a MAAR and the CMD.

This means that the network scale isξ ≤1. In the literature, the default value of this ratio is considered to lie between 0.2 and 0.5 [34–36]. In our case, the default value of the network scale isξ = 0.5. However, we investigate the impact of this parameter on different costs later.

For mobility modeling, we use the City Section Mobility (CSM) model introduced in [37,38]. The CSM model represents a pattern of movement influenced by the constraints of the environment. In real-life scenarios, vehicles do not have the ability to travel freely because they have to follow traffic regulations. The CSM model represents a realistic movement pattern for vehicles in a city [39], and its stochastic properties have been analyzed in [40]. Thus, we adopt those properties for our mobility model. The area used in the CSM model for analysis is represented by a grid of streets forming a particu- lar section of a city. An MU starts at a predefined intersection of two streets, and then it randomly chooses a destination.

When the MU reaches the destination, it pauses for a random amount of time and then randomly chooses another destination. This cycle is repeated, and each cycle in which the MU moves from a source to a destination is termed an epoch [40].

In the environment shown in Fig.11, the roads are parallel to the axes.NxandNyare the numbers of horizontal and vertical roads, respectively. Horizontal roads areSxdistance apart, and vertical roads are Sy distance apart. Therefore,

Nx = _S^X_x +1 andNy = _S^Y_y +1. The expected epoch length is obtained as follows [40]:

E(L)= X(Nx+1) 3Nx +Y

Ny+1 3Ny

(5) Letv¯be the average velocity of a vehicle. Then, the expected epoch time is calculated as follows:

E(T)= E(L)

¯

v (6)

For safety, at each road intersection, there is a random pause delay of between 0 andUmaxto avoid collisions. Hence, the expected pause time can be represented by

E(P)= Umax

2 (7)

By assuming that 2r = K1∗Sx = K2∗Sy andlx = ly = Sx/2 = Sy/2, the expected number ofSNcrossings can be obtained as in [39,40] as follows:

E(C)= m K1(m+1)

6N_x² (6Nx−4m K1+K1+3) +n K2(n+1)

6N²_y

6Ny−4n K2+K2+3

(8) Finally, using (6), (7), and (8), the average elapsed time within anSNis estimated as in [36], as shown below:

TS N =

E(T)+2E(P) E(C)

(9) Then, we can obtain the crossing rateμS N by using (9), as follows:

μSN = 1 TSN

(10) The vehicle in DMM and FDMM configures a new address at each visitedSN, and the vehicle might simultaneously use more than one IP address. The prefix is considered “active”

when at least one IP flow uses the address derived from it.

In the following, we use the DMM traffic model introduced in [23]. The average number of active prefixes at a handover event includes the one that is configured from the LNP by the S-MAAR as well as any others from the pLNPs by the AMAARs. According to DMM [15], a prefix is always main- tained for at least the first handover, after which it may be allowed to expire based on user activity. Hence, the active prefix lifetime is obtained by

TPR=T^H +T^F (11)

(14)

where T_PR^H = TSN, and T_PR^F is a random decay interval because the MU leaves the “home” MAAR until the prefix expires. By denoting 1/λ_PR^F = E

T_PR^F

, we can write T¯PR=E

T_PR^F

= 1 μSN + 1

λ_PR^F (12)

At a handover event, the average number of active prefixes, N¯PR, is one (the LNP) plus the average number of active pLNPs,N¯pL N P, as shown below:

N¯P R=1+ ¯NpL N P (13)

whereN¯pL N P is the product of the average number of handovers that occur during the foreign prefix lifetime multiplied by the prefix generation rateg, which in our case is simply g= 1 prefix per handover. We refer to the probability thatH handovers occur during the intervalT_PR^F as∝(H). Therefore, a pLNP remains active on average forE[∝(H)] subnet residence intervals. From the above considerations, we obtain

N¯pL N P =g E[∝(H)]=E[∝(H)] (14)

Finally, from the probability∝ (H)and its expected value, this yields

∝(H)=P_PR^H −P_PR^K⁺¹=P_PR^H (1−PPR) (15) E[∝(H)]= PP R

1−PP R =μSN

λ_PR^F (16)

By merging (13), (14) and (16), we finally obtain N¯PR=1+μSN

λPR^F

(17) 5.2 Analysis of the handover latency

Here, we define the Handover Latency (HL) as the time between the last moment the MU can receive and send packets through the S-MAAR and the first moment it can receive and send packets through the nMAAR [23,41]. According to

the DMM protocol [15], the handover procedure is composed of three phases as follows (see Fig.12):

T_HL^DMM=TL2+TAuth+T_Binding^DMM (18) As an MU moves from a point of attachment belonging to one MAAR to one belonging to another MAAR, it triggers the handover process by initiating the Layer 2 and authentication processes. These phases are related to the wireless technology and authentication mechanism being used. Thus, TL2, which is the elapsed time to establish the new Layer 2 link, and TAuth, which is the elapsed time to authorize an MU, are considered constant in the IETF network-based DMM and FDMM.

The symbolT_Binding^DMM denotes the elapsed time of the mobility binding phase. The binding phase is required to update the MU location and recover the ongoing IP flows. The calculation ofT_Binding^DMM is as follows:

T_Binding^DMM =T_MD^DMM+T_LU^DMM (19)

where T_MD^DMM represents the movement detection latency, which is the total time spent exchanging router solicitation and router advertisement messages, and is expressed as follows:

T_MD^DMM=2dMU−M A A R(c) (20)

wheredM N−M A A R(c)is

dMU−M A A R(c)= Lc

BW_w +l_w 1 1−Pf

hMU−M A A R

(21) The time that T_LU^{D M M}represents includes both the time required to exchange PBU/PBA messages and the processing time needed to update the MU’s location and establish the tunnel.

T^DMM=2dC M D−M A A R(c)+T^CMD+2T^MAAR (22)

(15)

Fig. 13 Pre-FDMM handover operation timeline

wheredC M D−M A A R(c)is dC M D−M A A R(c)=

Lc

BW +l

hC M D−M A A R (23) On the other hand, FDMM operates as either pre-FDMM or re-FDMM, depending on the circumstances. Compared to the IETF network-based DMM, the two FDMM modes involve extra signaling costs due to the required handover preparation for the MU. As shown in Fig.13, whent≤x, the handover will be performed in the reactive mode; otherwise, it will be executed in the predictive mode. The following parameters are used for FDMM performance analysis:

xTime duration from when the RSS reaches the threshold until the MU scans its neighboring Access Networks (ANs) T Time duration from when an L2 report is sent to the S-MAAR to when the MU receives a handover command from the S-MAAR

tTime duration starting when the RSS reaches the threshold and ending when theL2 link down event completes

∅Time duration starting when anL2 report is sent to the S-MAAR and ending when theL2 link goes down, where x <∅ ≤x+T

TH I Time duration required by the handover initiation process, including theHIand HAck message exchanges

The pre-FDMM occurs once when t > x. The handover latency of pre-FDMM may differ by the time point at which theL2 link goes down. Thus, two possible cases may occur: If∅ = x+T, the MU’s L2 link with the S- MAAR goes down after receiving the handover command.

In such a case, the nMAAR has already completed the pre-handover process and established a tunnel with the S- MAAR. In contrast, if x < ∅ < x +T, the MU’s L2 link with the S-MAAR goes down before receiving the handover command. Thus, the pre-handover process and the time to establish a tunnel between the nMAAR and the S- MAAR must be included in the handover latency calculation.

BecauseT =2dMU−M A A R(c)+TH I, we can express the pre-FDMM handover latency as follows:

T_{H L}^{pr e}⁻^{F D M M} =(((2dMU−M A A R(c)+TH I)− ∅)+((TL2

+TAut h)−x)) (24)

Becausexis executed during the pre-handover process, we did not include it during the L2 link establishment and authentication phases. TheTH I is expressed as follows:

TH I =2dM A A R−M A A R(c)+T_PC^{M A A R} (25) wheredM A A R−M A A R(c)is

dM A A R−M A A R(c)= Lc

BW +l

hM A A R−M A A R (26) We can express the latency for re-FDMM handover as shown in Fig.14, whereT_{H L}^{r e}⁻^{F D M M}is

T_{H L}^{r e}⁻^{F D M M} =TL2+TAut h+TH I (27) 5.3 Analysis of the handover failure probability

We define the Handover Failure Probability (PF) as the probability that the sub-network/cell residence time is less than the handover latency [11]. The general expression for PF is as follows [41]:

P F(.)=Pr ob{TS N <H L(.)} = _{H L}_(.)

0

μS Ne^−μ^{S N}^x

d x=1−e^−μ^{S N}^{H L}^(.) (28) In Eq. (8),TS Nis defined as the mean subnet residence time, which is the inverse ratio of the subnet average crossing rate.

The expression is applied to the IETF network-based DMM and FDMM.

(16)

Fig. 14 The re-FDMM handover operation timeline

5.4 Analysis of the session recovery time

The session recovery time (SR) represents the interval that starts when the last data packet of a given session is received by the terminal before the handover and ends when the first packet is received after the handover [23]. In the IETF network-based DMM, the session recovery time (as shown in Fig.12) equals the handover latency plus the time taken for the MU to receive the first data packet:

T_{S R}^{D M M} =

T_{H L}^{D M M}−dMU−M A A R(c)

+dM A A R−M A A R(d)+dMU−M A A R(d) (29) wheredM A A R−M A A R(d)is

dM A A R−M A A R(d)= Ld

BW +l

hM A A R−M A A R

Similar to the IETF network-based DMM, the session recovery time in FDMM equals the handover latency plus the interval for the first data packet to travel from the S-MAAR to the nMAAR and from the nMAAR to the MU. The session recovery time in re-FDMM is expressed as follows:

T_{S R}^{r e}⁻^{F D M M} =TL2+TAut h+TH I+dM A A R−M A A R(d)

+dMU−M A A R(d) (30)

On the other hand, the session recovery time in pre-FDMM is

T_{S R}^{pr e}⁻^{F D M M} =(max{(2dMU−M A A R(c)+TH I)− ∅,0}

+((TL2+TAut h)−x)+dMU−M A A R(d)) (31) As shown in Fig.13,(dMU−MAAR(c)+((TL2+TAuth)−x)) >

dMAAR−MAAR(d); thus, we include the time for theL2 link to switch between ANs in the session recovery time. In addition, the S-MAAR starts forwarding data traffic to the nMAAR

after it receives the HAck message but before sending the handover command. At that time, the MU still can receive and send data through the S-MAAR until it receive the handover command. Thus, the interval to send the handover command is not included in the session recovery time.

5.5 Analysis of packet loss

We define Packet Loss (PL) as the total number of data traffic messages lost or dropped during the MU handover. In the IETF network-based DMM, no buffering mechanism is used during the handover; therefore, the packet loss will be proportional to the length of the session recovery interval and to the compound packet arrival rate,λ[23]. We consider that packets are transferred to and from the MU at a rate of λ=λpN¯P Rpackets/second, whereλpis the packet rate per active prefix. The packet loss will be expressed as follows:

P LD M M =λLdT_{S R}^{D M M} (32)

Similarly, the packet loss in re-FDMM is represented as follows:

P Lr e−F D M M =λT_{S R}^{r e}⁻^{F D M M} (33) On the other hand, a buffering mechanism is employed in pre-FDMM; thus, the number of packets lost is proportional to the interval required to establish a tunnel when the MU is detached from the S-MAAR as well as to the buffer overflow at the nMAAR (see Fig.13) [42,43]. Thus, the packet loss will be the total of the packets transferred before initiating the buffering plus the packets that overflow the buffer after buffering begins, as follows:

TBu f f er i ng^{F D M M} =(dMU−M A A R(c)+((TL2+TAut h)−x))

−(dM A A R−M A A R(d)) (34)

(17)

P Lpr e−F D M M =λLd

max{(dMU−M A A R(c)+TH I)

−∅,0} +max

T_Buffering^FDMM −B,0

(35) whereBis the buffer size.

5.6 Analysis of the signaling cost

The Signaling Cost (C) is accumulative of the handover- related signaling messages for an MU and can be calculated as the product of the size of mobility signaling message and the hop distance [44–46]. In the IETF network-based DMM, the signaling cost consists of RS/RA messages between the MU and the MAAR, PBU/PBA registration handshakes between the nMAAR and the CMD to register nLNP, and PBU/PBA messages exchanged between each AMAAR and the CMD. Thus, the signaling cost of the IETF network-based DMM is defined as

C_sig^{D M M} =2μsnLc(hMU−M A A R

+hC M D−M A A R(N¯P R+1)) (36) As stated in the assumptions, we assume that the vehicle is moving away from the home MAAR. Consequently, the number of hops between the nMAAR and the AMAAR increases each time a handover occurs. Increasing the number of hops increases the signaling cost of FDMM in an exponential way. This is considered the worst-case scenario for FDMM but has no impact on the signaling cost of the IETF network-based DMM. In addition to the IETF network-based DMM signaling cost, the signaling cost of FDMM predictive mode includes the extra signaling messages exchanged between MAARs. The pre-FDMM signaling cost is expressed as follows:

C_sig^{pr e}⁻^{F D M M} =2μsnLc

⎛

⎝hC M D−M A A R+hMU−M A A R

+

¯ N_{P R}

n=1

nhM A A R−M A A R

⎞

⎠ (37)

In reactive mode, there are no RS and RA messages exchanged between the MU and the nMAAR because the handover operation starts after attachment to the nMAAR.

The signaling cost of re-FDMM is

C^{r e}_sig⁻^{F D M M} =2μsnLc

⎛

⎝hC M D−M A A R

+

¯ N_{P R}

n=1

nhM A A R−M A A R

⎞

⎠ (38)

Table 2 Default parameter values [23,39–41,47]

Parameter Value

X,Y 36 & 24 km

S_x =S_y 200 m

K₁=K₂ 5

U_max 4 Sec

1/λ^FP R 240 Sec

L_c,L_d 80 & 400 bytes

BW,BW_w 100 & 10 Mbps

l,l_w 0.5 & 2 ms

T_PC^{C M D},T_PC^{M A A R} 20, 10 ms

∅ 35 ms

B 500 KB

λ 50 packets/s

ξ 0.5

p_f 0.5

¯

v 25 m/s

r 1000 m

6 Numerical results and discussion

In this section, we present and discuss the numerical results based on the analysis provided in the previous section. The default parameter values are summarized in Table 2, as obtained from Hossain et al. [39,40], Seonggeun, R. et al.

[47], Ali-Ahmad et al. [41], and Giust et al. [23]. The assigned value of the total Layer 2 latencyL2, including the scanning phase, is 330 ms, where the scanning phase x is 300 ms.

On the other hand, the authentication latency LAut h is 100 ms. We study the impact of several parameters on handover performance by varying their values.

First, we investigate the effect of the cell’s radiusr. We use default values, except that we vary the cell’s radius value from 1000 to 6000 m to take different transmission technology ranges (e.g., 802.11p, WiMax, LTE) into account. Altering the range causes the number of cellsNSto vary from 285 to 4.

As a result of increasing the cell’s radius, the average number of hops between network entities decreases, which affects the handover latency. As shown in Fig. 15a, the handover latencies of the IETF network-based DMM and re-FDMM are slightly reduced by increasing the cell’s radius because the number of hops between the MAAR and the CMD and between MAARs decreases. In pre-FDMM, no signaling is exchanged between network entities after the L2 link has gone down by receiving the handover command. This is because the binding registration process occurs in advance—

before the link goes down. Thus, varying the valuer has no effect on the pre-FDMM handover latency. The session recovery time, as shown in Fig.15b, has the same trend as

(18)

Fig. 15 The impact ofr(radius of cells) on handover latency and session recovery

Fig. 16 The impact of varyingr(the radius of cells) on packet loss

the handover latency, with a slight delay increment due to the delay in forwarding the data traffic to the vehicle.

Figure16shows the impact of varying the radius of the cells on packet loss. Packet loss in the IETF network-based DMM and re-FDMM is proportional to the session recovery time because no buffering mechanism is used. Packet loss for DMM and re-FDMM decreases as the session recovery time is reduced. On the other hand, the pre-FDMM buffers the ongoing data traffic at the nMAAR, and hence, packet loss will be eliminated as long as the data traffic does not exceed the buffer size.

As shown in Fig.17, increasing the radius of the cells when vehicle speed is considered constant reduces the subnet crossing rateμS N. As a consequence, the handover failure probability decreases because it has a direct proportion to the subnet crossing rate. In addition, the low crossing rate

decreases the number of handover events; thus, the signaling cost decreases dramatically in both the IETF network-based DMM and FDMM.

The handover performance could be affected by signaling over either wired or wireless links. Here, we investigate the effect of wired links by studying the network scale impacts.

We vary the network scaleξfrom 0.1 to 1, which means varying the ratio of the distance between MAARs to the distance between the MAAR and the CMD.

Figure 18a shows the impact of network scale on handover latency and packet loss. Altering the network scale has no effect on the handover latency of the IETF network- based DMM and pre-FDMM. This is because the handover management messages in DMM are exchanged between the MAARs and the CMD, where the hop number is constant during the change of the network scale. In addition, pre-FDMM exchanges the handover management messages proactively before theL2 link goes down. On the other hand, re-FDMM handover latency increases linearly due to the increment of the number of hops between MAARs during the exchange of HO-Initiate process messages. The network scale has the same impact on handover failure probability as on handover latency due to the direct proportion between handover latency and handover failure probability.

In Fig.18b, the IETF network-based DMM and re-FDMM experience steady increases in packet loss as the network scale increases. In contrast, buffering eliminates the packet loss in pre-FDMM. The IETF network-based DMM has the highest packet loss due to its high handover latency and the data transmission delays from the S-MAAR to the nMAAR and from the nMAAR to the vehicle. Increasing the network scale increases the number of hops between the S-MAAR and the nMAAR. The data transmission delay between MAARs has a significant effect on re-FDMM because more messages must pass through the hops between MAARs to recover

(19)

Fig. 17 The impact of varyingr(the radius of cells) on handover failure probability and signaling cost

Fig. 18 The impact ofξ(network scale) on handover latency and packet loss active sessions. Therefore, increasing the network scale will increase packet loss significantly in re-FDMM.

The signaling cost, as shown in Fig.19, of our proposed solution increases steadily as the network scale increases.

This is because the MAARs exchange signaling during the handover in our proposed solution, in contrast with the IETF network-based DMM. Therefore, the deployment of our proposed solution is more suitable for large operator networks where the distance between MAARs and the CMD might be substantial compared to the distances between MAARs, where the signaling cost effects on network performance are not that significant.

Just as we studied the effect of signaling over wired links on handover performance, we also studied the effect of signaling over wireless links. Thus, we investigate the impact of the probability of wireless link failure probability,pf, on

handover performance. The pf value is varied from 0.1 to 0.8.

In FDMM, the handover procedure starts either after vehicle detachment in re-FDMM or after receiving a handover command from the nMAAR in pre-FDMM. Therefore, no messages are exchanged over a wireless link between the vehicle and the MAAR during the handover; hence, the handover latency is constant, as shown in Fig.20a. In contrast, the IETF network-based DMM handover latency decreases slightly due to the HS and HA messages exchanged between the MAAR and the MU.

As mentioned before, packet loss depends on the session recovery time when a buffer mechanism is not deployed. The session recovery time of the IETF network-based DMM and FDMM increases slightly when the probability of wireless link failure increases because of the effect of the wireless