Livinus Tuyisenge
email: livinus.tuyisenge@univ-reims.fr

Marwane Ayaida
email: marwane.ayaida@univ-reims.fr

Samir Tohme

Lissan-Eddine Afilal

A Mobile Internal Vertical Handover Mechanism for Distributed Mobility Management in VANETs

Keywords: Vertical handover, Logical interface, PMIPv6, VANETs, HVNs

With the rapid development of internet, new technologies and new domains of activities are increasingly created with an exponential pace. Therefore, network operators and service providers experience an astonishing demand in terms of network services' performance. Vehicular Ad hoc Networks (VANETs), which have evolved to Internet of Vehicles (IoV), are one of these new technologies with high demand in connectivity. This is due to their two critical characteristics (their high mobility and their frequent dynamic topology changes), since they generate scattered networks. Therefore, a high network's performance has become a critical issue for connected and autonomous vehicles deployment. This is due to the fact that VANETs need a high coverage density in order to work efficiently. In order to address this issue, the Heterogeneous Vehicular Networks (HVN) paradigm has appeared. It consists in a hybridation of the vehicular network (IEEE 802.11p) and the cellular networks (3G/LTE/4G). This makes the vertical handover to be one of the key technologies for the IoV deployment. In this paper, we propose a vertical handover mechanism, denoted Proxy MIPv6-based Mobile Internal Vertical Handover (PMIP-MIVH), which uses a logical interface and a Distributed PMIPv6 scheme in order to improve the handover performance and consequently the overall network's performance. Numerical model analysis show that our proposed solution (PMIP-MIVH) performs well in terms of handover connection durations, handover latency and session continuity. Finally, we have evaluated our solution using the well known network simulator NS3. We conducted performance comparison with existing PMIP-based solutions in terms of Packet Delivery Ratio (PDR), End-toend delay, jitter and throughput metrics. Simulation results also show that our solution outperforms the considered existing solutions and therefore validate the analytical results.

Introduction

Vehicular networks are emerging ones that connect vehicles with each others and with the road infrastructure. However, their high level of mobility and dynamic change in the topology make very difficult to predict how long the vehicle will stay connected to a network, since this prediction might be based on a lot of parameters. Among those parameters, we can cite velocity, direction, traffic flow, network signal, distance between the vehicles and the RSUs (Road Side Units), signal interference, obstacle's interferences, multipath fading, transmission range, transmission power, transmission power gain, sensibility to the Service Level of Agreement (SLA), user preferences, QoS, etc. In [START_REF] Zeadally | Data analytics for cooperative intelligent transport systems[END_REF], authors highlight the large amount of data that might be exchanged between VANETs entities (vehicles, RSUs, Traffic Control centers) in order to support applications in VANETs also known as Cooperative Intelligent Transport System (C-ITS) applications. They also emphasize the challenging issue for generating, aggregating [START_REF] Cherkaoui | Optimal selection of aggregation locations for participatory sensing by mobile cyber-physical systems[END_REF], transmitting and interpreting these data in order to have accurate and optimized C-ITS applications' operations.

Albeit this prediction difficulty, most of existing solutions are still relying only on the Received Signal strength Indicator (RSSI) measurement, before deciding to trigger a handover. This always conducts to a critical disconnection time, often referred as handover latency. This has a negative impact on the application's performance such as the loss of packets. The latter might be harmful for some types of applications such as safety and realtime applications. First, we have considered this difficulty to have a good and accurate method to predict how long the vehicle will stay connected to a network. Then, we analyzed the consequences of the disconnection time during a vertical handover in critical applications such as autonomous driving. That is why, in this paper, we focused our attention on how we can reduce this disconnection time and its negative impacts. As a result on this issue, we propose a method that allows the mobile to directly and simultaneously connect to any available new type of network, while it stills connected to the current network. Therefore, our method results in an anticipation of the next potential mobile handover. That said, it is based on a soft and efficient use of a logical interface. As a result, our method allows to reduce the handover latency and reduce/avoid as much as possible the packet loss, which also increases the overall system's throughput. Our proposed method also allows the vehicle to maintain the session continuity. Moreover, our approach can be extended in order to well perform the traffic load-balancing by routing different flows through different networks. This might increase the quality of service (QoS) and user experience (UX) improvement of our method by taking into account the network user preferences and bandwidth when filtering the traffic flow if possible. Otherwise, the best effort could be applied by default.

The remainder of this paper is organized as follows. In section 2, we present an overview of some existing handover solutions. We give a background of PMIPv6 on which we based our solution in section 3. Then in section 4, we describe our proposed approach and algorithm. In section 5, we present the analytical model and numerical results for our solution. We have conducted simulations in a highway's mobility scenario to validate our solution in section 6.3. We discuss these simulation results in comparison with the already existing handover solution (PMIPv6-HD) in section 6.3.2.

Then, we extended our approach by conducting near-realistic simulations in urban mobility scenario using the SUMO software in section 6.4. We also discuss about the finding results. Finally, we conclude and present our perspectives in section 7.

Seamless mobility related works

The large and fast development of telecommunication systems and the deployment of IoT (Internet of Things) allowed the development and standardization of many new communication processes and protocols.

The VANET's field [START_REF] Wahid | State of the art routing protocols in VANETs: A review[END_REF] has followed this development's pace. It has then evolved into the IoV [START_REF] Yang | An overview of Internet of Vehicles[END_REF]. Then, the heterogeneous vehicles networks'(HVNs) paradigm came in with its related protocols, in order to strengthen the communications capabilities of vehicles. Therefore, many IoV architectures have also been proposed in the literature as it can be read in our previous published work [START_REF] Tuyisenge | Handover Mechanisms in Internet of Vehicles (IoV): Survey, Trends, Challenges, and Issues[END_REF].

Readers can also found all the most important details about the state of the art on vehicular communications, standardization efforts and emerging technologies in a recent and comprehensive survey in [START_REF] Singh | A tutorial survey on vehicular communication state of the art, and future research directions[END_REF]. Authors of [START_REF] Singh | A tutorial survey on vehicular communication state of the art, and future research directions[END_REF] also highlight the remaining openness of the seamless connectivity challenge in HVNs. Although this remains open to the research community, many handover's solutions have already been proposed to deal with this connectivity and mobility issues. We have summarized them in the table 1, we describe them and we highlight their shortcomings in sub-section 2.1, before proposing our solution in section 4.

Handover classification overview

Many handover mechanisms, also known as mobility management, were proposed in the literature. We can mainly classify them (i.e mobility handovers) into two classes:

• Global mobility management: in which the main mobility manager, known as Home Agent (HA), is located in the core network and the mobility is managed in a centralized manner. We can cite as examples: Mobile IPv4 (MIPv4) [START_REF] Perkins | IP Mobility Support for IPv4, Revised[END_REF][START_REF] Perkins | IP Mobility Support for IPv4[END_REF][START_REF] Perkins | IP Mobility Support for IPv4[END_REF][START_REF] Perkins | IP Mobility Support[END_REF], Mobile IPv6 (MIPv6) [START_REF] Johnson | Mobility Support in IPv6, RFC 6275[END_REF], Network Mobility (NEMO) [START_REF] Thubert | Network Mobility (NEMO) Basic Support Protocol[END_REF], etc.

• Local mobility management: in which the mobility is managed locally in a small region, named mobility domain and is assumed to be managed in a distributed way. We can cite as examples: Proxy MIPv6 (PMIPv6) [START_REF] Gundavelli | Proxy mobile IPv6, RFC 5213[END_REF], Distributed Mobility Management (DMM) [START_REF] Chan | Requirements for Distributed Mobility Management[END_REF], Fully DMM (FDMM) [START_REF] Murtadha | Fully distributed mobility management scheme for future heterogeneous wireless networks[END_REF].

We propose a classification of the main existing handovers mechanisms in the table 1, followed by their details.

Definitions and description of existing handover types

After a deep analysis of the existing handover types in the literature, we have identified many different existing approaches. This could be explained by the fact that the handover involves many steps (Initiation, Decision and Execution). Thus, there are some standards that cover the execution step, while the other steps, especially the decision step, are not really standardized. This is why we found many different approaches

Level

Mono layer

Internet layer or Transport layer MIPv4, MIPv6, NEMO [START_REF] Thubert | Network Mobility (NEMO) Basic Support Protocol[END_REF], mSCTP [START_REF] Thaalbi | Improving vertical handover over heterogeneous technologies using a cross layer framework[END_REF], SIGMA [START_REF] Shohrab | Cost analysis of mobility protocols[END_REF] Cross layer Access-Internet, Access-Application layer FDMM [START_REF] Murtadha | Fully distributed mobility management scheme for future heterogeneous wireless networks[END_REF] Architecture Centralized Control plan and data plan NEMO [START_REF] Thubert | Network Mobility (NEMO) Basic Support Protocol[END_REF], MIPv4 [START_REF] Perkins | IP Mobility Support for IPv4, Revised[END_REF][START_REF] Perkins | IP Mobility Support for IPv4[END_REF][START_REF] Perkins | IP Mobility Support for IPv4[END_REF][START_REF] Perkins | IP Mobility Support[END_REF], MIPv6 [START_REF] Johnson | Mobility Support in IPv6, RFC 6275[END_REF] Distributed Data plan or both plans FDMM [START_REF] Murtadha | Fully distributed mobility management scheme for future heterogeneous wireless networks[END_REF] in the literature. Therefore, we propose that the handover mechanisms could be classified according to the following criteria: technologies that are used, execution way, the decision actor, the number of layers involved in the handover process and the type of the possible deployment architecture. Therefore, these existing handover mechanisms that we summarized in the table 1 can be described as follows:

• Horizontal handover means that the handover is taking place between different cells within the same network technology type (intra-system). While vertical handover represents a handover that occurs between two differents network technologies (inter-system).

• Hard handover means that the mobile must be disconnected from the current network before it can reconnect to another cell or network. Whereas soft handover means that the mobile can be connected to more than one network during the handover process. In order to perform this soft handover, the Multiple Care-of-Address (MCoA) method is often used.

• Mobile Node (MN)-based handover means that it is the mobile that triggers the handover process. Whereas the Network-based handover refers to a process in which the core network decides to make the handover on behalf of a mobile. The mobile is then no longer involved in the handover process [START_REF] Taha | Securing IP Mobility Management for Vehicular Ad Hoc Networks[END_REF]. In addition, Hybrid handover approach refers to a combination of both MN-based and Network-based handover.

• Mono layer and crosslayer based handovers are used to reflect the number of OSI model (Open Systems Interconnection model) layers that are involved in order to fulfill the handover process. Hence, one layer refers to handover that involves only one layer, mostly the network layer (L3 for IP addresses), whereas crosslayer handover involves interactions between different layers such as the link layer (L2), the network layer (L3) and the transport layer (L4).

• In terms of architectural type, we have centralized solutions in which both control plan and data plan are centralized. It means that all packets are routed through one entity, mostly the HA. In contrast, there are Fully Distributed Mobility Management (FDMM) solutions where both of these plans (control and data) are distributed. There are also Partial Distributed Mobility Management (PDMM) solutions which can be seen as a hybrid version in which control plan is centralized while data plan is distributed. This is the case in Software Defined Network (SDN) [START_REF] Todorova | DDoS Attack Detection in SDN-based VANET Architectures[END_REF][START_REF] Taha | Securing IP Mobility Management for Vehicular Ad Hoc Networks[END_REF] as recently proposed in [START_REF] Singh | Multipath TCP for V2I communication in SDN controlled small cell deployment of smart city[END_REF]. Recently, Cloud computing based solutions have also been proposed [START_REF] Skondras | Mobility management on 5G vehicular cloud computing systems[END_REF].

To avoid redundancy, we here also refer readers to our previous published work [START_REF] Tuyisenge | Handover Mechanisms in Internet of Vehicles (IoV): Survey, Trends, Challenges, and Issues[END_REF],

for more details on these handover's methods.

After our deep review of these existing handover solutions, we have concluded that the Proxy MIPv6 (PMIPv6) is one of the most promising protocol solutions in this field. Therefore, we have dedicated the following section to give a background describing the PMIPv6 protocol, its advantages and disadvantages. Then, we provide a review of the extensions that have been already proposed in order to improve its handover performance. we highlight some remaining shortcomings of this protocol that motivate us to propose our solution..

3.

Background: PMIPv6 description, extensions and shortcomings

Description of PMIPv6

PMIPv6 is the only network-based standardized protocol for mobility management. It is specified in RFC 5213 [START_REF] Gundavelli | Proxy mobile IPv6, RFC 5213[END_REF]. PMIPv6 provides network-based mobility management to the hosts that are connecting to a localized network domain referred to as PMIPv6 domain. In PMIPv6, the network makes handover decisions and handles the mobility management on behalf of the mobile. This allows to make the handover transparent to the mobile. This also assumes a good stability of the mobile network. In such way, the network can assign a Home Network Prefix (HNP) to a mobile router which serves all mobiles within the mobile network in motion. To function, PMIPv6 introduces two new functional entities which are the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG), as topologically illustrated by the figure 1.

The MAG is the entity which is responsible of detecting the Mobile Node's (MN's) attachment and therefore providing IP connectivity to the MN. On the other side, the

• MN detachment

In order to perform its topological anchor' functionalities, the LMA must maintain a database called Binding Cache (BC) in which it stores an entry for each MN located in the PMIPv6 domain. Thus, each entry represents a mapping between the MN and its MAG, with also a list of the assigned HNPs to this MN. As normal database, the LMA must perform the basic functions of persistent storage, known as CRUD (Create, Read, Update, Delete) operations, each time that a change is necessary in the BC. To perform these CRUD functions, PMIPv6 entities exchange messages as illustrated in figure 1

Advantages and disadvantages of PMIPv6

The main advantages of PMIPv6 are:

• Standard and maturity: PMIPv6 has been standardized in 2008 in RFC 5213 [START_REF] Gundavelli | Proxy mobile IPv6, RFC 5213[END_REF]. Since then, it has been widely applied/deployed by many internet services' providers such as telecommunications operators.

• Support for unmodified MNs: unlike MIPv6, a network-based approach such as PMIPv6 should not require any software update for IP mobility support on MNs [START_REF] Choi | Implementation and Evaluation of Proxy Mobile IPv6 in NS-3 Network Simulator[END_REF].

• Support for IPv4 and IPv6: although the initial design of a network-based approach uses an IPv6 host, PMIPv6 is intended to work also with IPv4 or dualstack hosts as well [START_REF] Choi | Implementation and Evaluation of Proxy Mobile IPv6 in NS-3 Network Simulator[END_REF].

• Transparent handover: thanks to each network-based handover approach, PMIPv6 allows to make transparent handover to the mobiles under its domain, by handling the mobility management on behalf of them.

However, there are some primary features and goals of network-based handover approaches (as specified in [START_REF] Choi | Implementation and Evaluation of Proxy Mobile IPv6 in NS-3 Network Simulator[END_REF]) that PMIPv6 does not fulfill well and which constitute its drawbacks. We can cite:

• Inefficient use of wireless resources: network-based approach should avoid tunneling overhead over a wireless link. Hence, it should minimize the overhead within the radio access network. However, to perform its CRUD functions, we have seen that a lot of messages may be used, each time that a change occurs in the PMIPv6 domain. In fact, the CRUD process always starts by performing a lookup in the BC to verify whether a MN's entry is already available in the BC or not. Due to the high velocity of vehicles and the frequent topology changes in VANETs, which consequently trigger frequent exchanges of PBUs and PBAs in the PMIPv6 domain (figure 1), PMIPv6 presents a large overhead on the wireless resources within the radio access network.

Furthermore, depending on the number of entries in the BC which is proportional to the number of MNs in the PMIPv6 domain, the lookup process may take a long time and then causes the handover latency to increase. This results in performance degradation. Thus, a good conception of the storage structure to be used in BC is of great importance. We will see how it can be achieved in sub-section 3.2.1.

• Performance degradation: a network-based approach should minimize the required time for handover, also known as the handover latency. However, depending on the number of available MAGs and resources in the domain, the location of LMA may be far from the MAGs. Thus, the handover latency may greatly be impacted by the distance between LMA and MAG and therefore degrading the handover performance.

• Nevertheless, the LMA represents a single point of failure in PMIPv6, due to its centralized architecture.

Therefore, some PMIPv6 extensions have been proposed. We describe them in section 3.2.1 and we give their shortcomings in sub-section 3.2.2 to demonstrate the motivations of our proposal in this paper.

PMIPv6 extensions

In order to enhance the PMIPv6 functionalities, the multihoming support [START_REF] Melia | Logical-Interface Support for IP Hosts with Multi-Access Support[END_REF] and the flow mobility [START_REF] Bernardos | Proxy Mobile IPv6 Extensions to Support Flow Mobility[END_REF] extensions have been proposed. However, when dealing with multihoming (whether local multihoming or remote multihoming, as described in [section 3.2.4] of [START_REF] Braden | Requirements for Internet Hosts -Communication Layers[END_REF]), two multihoming requirement issues can be distinguished:

• A host may silently discard an incoming datagram whose destination address does not correspond to the physical interface through which it is received.

• A host may restrict itself to send (non-source-routed) IP datagrams only through the physical interface that corresponds to the IP source address of the datagrams.

Thus, this has introduced the terms of strong End System (ES) model and weak ES model. For the strong ES model, a host must silently discard an incoming datagram whose destination address does not correspond to the physical interface through which it is received. Furthermore, a host must restrict itself to send IP datagrams only through the physical interface mapped to the datagrams IP source address. On other hand, the weak ES allows the host to act as gateway for some packet/datagrams. For that, a weak ES must not silently discard an incoming datagram that the destination address does not correspond to the physical interface through which it is received. More, a weak ES must not restrict itself to send (non-source-routed) IP datagrams only through the physical interface that corresponds to the IP source address of the datagrams.

However, the weak ES problem still be that it may cause the ICMP [START_REF]IETF, Internet Control Message Protocol[END_REF] Redirect (i.e: message type=5) mechanism to fail. This means that, if a datagram is sent out to a physical interface that does not correspond to the destination address, the first-hop gateway will not realize when it needs to send a Redirect message.

Meanwhile, some researches [START_REF] Trung | A design of network-based flow mobility based on Proxy mobile IPv6[END_REF][START_REF] Xie | Design and Implementation of Flow Mobility Based on D-PMIPv6[END_REF][START_REF] Hong | Analysis of the usage of a logical interface in PMIPv6[END_REF] have been made on the use of logical interfaces in PMIPv6 in order to enable the flow mobility. In [START_REF] Yang | A multi-link mechanism for heterogeneous radio networks[END_REF], Yang et Al. have proposed a similar approach to the logical interface approach. They introduced the use of multi-link connection by adding two additional components: Multi-Link Adaptor (MLA) and Multi-Connection Manager (MCM) in the mobile node and core network respectively. However, their solution is similar to the PMIPv6 and these both solutions suffer from the robustness principle that states to: "Be liberal in what you accept, and conservative in what you send". This means that in such centralized solutions, one misbehaving host can deny internet service to many other hosts [START_REF] Braden | Requirements for Internet Hosts -Communication Layers[END_REF]. Their solution is still based on global and centralized architecture which can stay facing the disadvantages of centralized system such as overhead, bottleneck, single point of failure and no scalability. It might present a high handover latency due to exchanged control messages between the MLA and MCM (same case of MIPv4) depending on the distance between the mobile (UE) and the core network (MME: Mobility Management Entity or HA). In the way of addressing this robusteness issues, others extensions [START_REF] Yokota | Fast Handovers for Proxy Mobile IPv6[END_REF][START_REF] Melia | Logical-Interface Support for IP Hosts with Multi-Access Support[END_REF][START_REF] Bernardos | Proxy Mobile IPv6 Extensions to Support Flow Mobility[END_REF][START_REF] Trung | A design of network-based flow mobility based on Proxy mobile IPv6[END_REF][START_REF] Xie | Design and Implementation of Flow Mobility Based on D-PMIPv6[END_REF][START_REF] Hong | Analysis of the usage of a logical interface in PMIPv6[END_REF][START_REF] Yang | A multi-link mechanism for heterogeneous radio networks[END_REF][START_REF] Jain | Implementation and validation of BLUE and PI queue disciplines in NS-3[END_REF] have been proposed in the literature. They propose to extend and/or modify the manner that these signaling and updating control messages are exchanged. Some of them propose to extend the content of the exchanged messages. This is the case in [START_REF] Jung | Distributed mobility control in Proxy Mobile IPv6 networks[END_REF], where authors introduce the Proxy Binding Query (PBQ) and Proxy Query Acknowledgement (PQA) messages as illustrated in figure 3 [START_REF] Jung | Distributed mobility control in Proxy Mobile IPv6 networks[END_REF].

However, these extensions are still be based on the centralized architecture of PMIPv6, facing again the problem of centralized LMA, which becomes a bottleneck and single point of failure. Therefore, IETF (Internet Engineering Task Force) have discussed and recently proposed PMIP-based Distributed Mobility Management (DMM) [START_REF] Chan | Requirements for Distributed Mobility Management[END_REF], as mentionned in section 2.1 in the architecture part of table 1. These distributed approaches can be divided into two categories [START_REF] Murtadha | Fully distributed mobility management scheme for future heterogeneous wireless networks[END_REF]:

• Partially DMM: in which the control plane (signaling messages) is still centralized while the data plane is distributed among MAGs. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 • Fully DMM : in which both, the control plane and data plane, are completely distributed into the MAGs.

Sequence # A H L K M R P Q Reserved Lifetime Mobility options 0 1 2 3
In [START_REF] Jung | Distributed mobility control in Proxy Mobile IPv6 networks[END_REF], authors have proposed many DMM candidates schemes such as Signaldriven PMIP (S-PMIP), Data-Driven Distributed PMIP (DD-PMIP) and Signal-Driven Distributed PMIP (SD-PMIP). However, these schemes are not efficient for real-time and critical applications, especially for self-driving cars in VANETs. Furthermore, the consequent overhead created by the exchanges of updating messages in these architectures can be very disastrous for critical applications such as autonomous vehicles self-driving. Thus, authors of [START_REF] Kim | Distributed mobility management in proxy mobile IPv6 using hash function[END_REF] have proposed an improvement in handover performance by adding/using a hash function in the BC representation in order to reduce the lookup time overhead. They proposed a Distributed PMIPv6 solution based on a hash function 1 and they call it PMIP-HD for Hash-based Distributed PMIPv6. The hash function is distributed within the MAGs. This hash function allows a rapid lookup of MNs at the MAGs during the binding update and binding query of the signaling control. Performance analysis and mathematical analysis model are also detailed in [START_REF] Mohammed | Fast handover solution for network-based distributed mobility management in intelligent transportation systems[END_REF].

Shortcomings of existing solutions and motivation of our paper

After this extensions'overview, we concluded that inspite of having advantages and different manner of handling the handover's steps, the paramount and common problem is still being to find the most suitable time to trigger the handover in a such way to minimize the handover latency and the handover impact, especially the packet loss and the ping-pong effect. This is due to the disconnection time which always occurs before being connected to the next network. This time is mainly composed of a disconnection detection time, a new address configuration time and exchanging time of handover processing messages (Binding update, Binding Acknowledgment, PBU and PBA, etc). Many researches have relied on the RSSI measurement, but we are convinced that this is still not enough to fix this trigger time and avoid the ping-pong effect, because it stills a disconnection time to be minimized. This is why we propose our vertical handover mechanism called: PMIP-MIVH in order to overcome these stated issues, when considering critical applications in VANETs such as the remote monitoring of self-driving cars. For that, inspired by the amandements that have been done for the OCB mode2 of IEEE 802.11p in order to lessen the connection time, we have firstly proposed the "Anticipation of the Next Potential Handover Mode (ANPHM)" in order to answer to the problem of the suitable time to trigger the handover and also to reduce the impact of the signaling overhead when a handover is unavoidable. Then, we have also concluded that the use of a logical interface might be beneficial in handling multihoming, when connected to two or more different networks. In fact, it is specified in [section 3.2.4] of [START_REF] Braden | Requirements for Internet Hosts -Communication Layers[END_REF], that the most important advantage of a logical interface is that it may be bound to multiple physical interfaces, in order to increase the reliability or throughput between directly connected machines by providing alternative physical paths between them. They suggest that this might be achieved by performing a so called "link-layer multiplexing" which makes the protocols above the link layer unaware that multiple physical interfaces are present. However, it is specified that the link-layer device driver must be responsible for multiplexing and routing packets across the physical interfaces, without specifying how it is achieved. Furthermore, we did not found a proposal that have tested the use of logical interface for mobility management in the VANETs field. This is why, secondly, we have proposed the MIVH (Mobile Internal Vertical Handover) by describing and conceiving the use of logical interface as an extension of the weak ES model in handling multihoming for handover in VANETs. For that, we considered the logical interface to be an extension of the weak ES with an embedded gateway functionality. Thus, the logical interface acts as a gateway/proxy of the physical interfaces. Therefore, it allows the vehicle to externally show only one IP address in a specific PMIPv6 domain.

In addition, since the PMIPv6-HD solution above-mentionned improves the handover by reducing the lookup time thanks to the use of hash function, we wanted to extend its architecture by combining this solution with the use of logical interface in order to reduce the overhead of configuring new addresses and multihoming handling overhead in VANETs.

Therefore, we proposed a hybrid version of mobility handover management by combining:

• An extension of the soft handover: we consider that a mobile (vehicle) is equipped with multiple interfaces and can be connected simultaneously to multiple networks. Then, we introduced the ANPHM, that will be explained later in section 4.

• the network-based handover: we extended the PMIPv6-HD approach for radio access connectivity and signaling which will now be performed only by the MAGs (without LMA), and a long time ahead of the handover. Since using a distributed architecture, we considered a connected topology of MAGs in which MAGs can communicate with each others, whether in one hop or multiple hops.

• the MN-based: for session continuity purpose, the use of logical interface allows the vehicle to externally show only one IP address and to mask the presence of multiple interfaces.

In few words, we propose in this paper, an extended soft vertical handover approach called distributed PMIP-based Mobile Internal Vertical Handover (PMIP-MIVH) based on PMIP6-HD and the use of a logical interface, which reduces considerably the packet loss, the disconnection time and hence increases the packet delivery ratio (PDR) and the throughput. It also promotes the deployment of the emerging and critical VANETs applications, by ensuring the session continuity.

Thus, inspired by the network-based goals and features and given the PMIPv6 drawbacks mentionned in section 3.2, the contributions of our paper are twofold:

• In order to minimize the required time for handover, we made our first contribution by introducing the ANPHM to anticipate the next handover process. To ensure this, the vehicle directly connects to each new available network without triggering the handover, while it stills well connected to the current network. Thus, at least, the vehicle becomes connected simultaneously to two networks. We are aware that this strategy could suffer from the waste of resources as a drawback. However, we assumed and suggested that it can be improved by using these resources for flow mobility when the dual (or multiple) connections are available for long time. The important thing that we wanted to stress here is that, in case of handover, we have anticipated the handover process and packets can be directly received instead of lately trigger the handover at this time due, in general, to the lack of efficiency of prediction algorithms.

• We made our second contribution by proposing to reduce the handover radio signaling overhead to a minimun number of exchanged messages, by principally executing the handover internally in the mobile node using the logical interface as a gateway/proxy for the physical interfaces, when necessary. For that, thanks to our anticipation and by using the logical interface, we only have to create a tunnel between the logical interface and a physical up interface in order to redirect our packets. Therefore, we reduce the amount of signaling exchanged messages on the wireless link during the handover process. It is to be recalled that these signaling messages might have been (or have to be) sent while configuring a new IP address when a handover from one RAT (radio access technology) to another has occurred, especially in multihoming domains.

Our proposed approach: the PMIP-MIVH

In our approach we considered the following assumptions:

• As illustrated by the figure 4, we considered the context of heterogeneous vehicular network which means that we often have more than one network. Otherwise, no need for handover because whether we directly connect to the only available network or we are completely disconnected.

• Possibility of soft handovers: as illustrated by figure 5, our target is to be always connected to, at least, 2 overlapping networks when available as usually used in datacenters (redundant networks). That is where the role of logical interface is used.

• The MN does not wait to be disconnected before it reconnects to another network (use of multiple network devices on every vehicle or mobile),

• In order to make redundancy, we want to use the diversity by duplicating the flow on the different available physical interfaces by mimicking the flow mobility extensions

• Finally, we take advantage of distributed PMIPv6 for architectural purposes.

Here also we assumed a connected topology of MAGs in which MAGs can communicate with each others.

In such scenario, every vehicle must always be connected at least to one network. Thanks to soft handover, a vehicle can also be simultaneously connected to multiple networks by using multiple RAT devices installed on every vehicle. Following the PMIPv6 flow mobility extensions specifications and by using logical interface, we can reduce the handover latency and the packet loss. Hence, we can ensure QoS and increase the throughput and the load balancing by making just a mobile internal handover (RAT switching) which lasts few time. This is because it has to take place within the mobile. Thus, there is no long delay and we gain time by anticipating all new address configurations while MN is still connected to at least one network. Those are the most aspects that we considered to propose within our PMIP-MIVH approach.

Practically, we want the logical interface to play the role of data transmission and data reception, while the multiple physical interfaces play the role of signaling, radio access and control plane. This is the signaling part (Initiation) of the handover process that we wanted to anticipate. This step is done using the distributed PMIPv6 approach. We will use the term of "Immediate Connection using PMIPv6" to refer to this step, later in the flowchart. Therefore, the MAG is responsible of handling the L2 handover steps at this stage within our PMIP-MIVH method. Thereafter, when the mobile needs to receive data, it will firstly check the availability of the connectivity by calling the interface::IsUp method (which implements the selection and decision phase of the handover) of the logical interface. This method consequently triggers the method IsUp() on each of the installed physical interfaces. The method IsUp() on physical interfaces is inspired from the ones proposed by the Media Independent Event Service (MIES) [START_REF]IEEE Std[END_REF][START_REF] Gupta | [END_REF][START_REF] Jose | PMIPV6-HC-MIH: An approach for improving handover performance in NGWN[END_REF]. Using the OR conjuction, it checks whether at least one interface is up (which means that its RSSI is enough to receive packets) at this mobile. Later, we will use the term of "Find remained Up interface" to refer to this selection and decision phases in the flowchart of our approach. Thus, the pseudo-code in algorithm 1 illustrates this process.

If at least one interface is connected, therefore the mobile can receive data without wondering whether the corresponding physical interface is down or not. This is possible thanks to the possibility of establishing a reception tunnel between the logical interface and each up interface. In other general situation, it might firstly trigger the handover process at this time in order to handle the data reception. This is where we gain and improve the handover latency and the throughput, compared to other Algorithm 1 Find Up Interface Require: N ≥ 2;

N=number of devices interf ace = 0

U P = [] for (i = 0; i < N ; i ← i + 1) do if (IsU p(i)) then U P ← U P ∪ i end if
end for interf ace = choose candidate interface in UP vector Create Tunnel with interf ace to Receive packet available solutions. Therefore, the communication with the remote correspondent can continue even if there might have been occured changes in the physical interface states. When receiving data, the logical interface can lookup to the up interfaces on which it can route the received data. By this method, we have assured that the session continuity is guaranteed thanks to the logical interface functionalities.

This needs that we design a virtual tunnel or bridge to route packets within the mobile itself. We have opted for the use of Generic Routing Encapsulation (GRE) tunnels as described in RFC 2784 and updated by RFC 2890. In other words, we want to make mapping from the transport layer port to the link layer (L4-to-L2 mapping) which will allow to route the upper layer packet to a corresponding RAT network type and also will allow us to perform the vertical handover just by switching the RAT technology only inside the mobile, exactly at layer 2.5. We have illustrated this approach with figure 6 and we denote this approach Mobile Internal Vertical Handover (MIVH). Apart from being viewed as a simple network interface by the host IP layer and upper layers (such as the application layer), the logical interface has specific properties that are essential in vertical handovers (handover between multiple access networks) which are:

• possibility to have a relation to a set of physical interfaces on the host that it is abstracting or hidding their existence

• Possibility to be attached to multiple access technologies

• Dynamicity of connection and attachment with the physical interfaces, which consequently become sub-interfaces when attached to logical interfaces (heritage)

• a dynamic mapping between transmission/reception functions of logical interface with the transmit/receive functions of physical interfaces.

• Maintenance of a IP flow information for each of its attached pysical interfaces.

All those properties help the logical interface to hide the presence of multiple physical interfaces on the mobile (vehicles), hidding consequently any changes (that are monitored by using the MIES feature of MIH) taking places at lower layers among the physical interfaces. This is essential for a transparent and seamless vertical handover. Note that, similarly to the IEEE 802.21 MIH standard on which we based our approach, 3GPP group has standardized a mechanism called Access Network Discovery and Selection Function (ANDSF) [START_REF] Etsi | Universal Mobile Telecommunications System (UMTS); LTE; Access Network Discovery and Selection Function (ANDSF) Management Object (MO)[END_REF][START_REF] Taaghol | Seamless integration of mobile WiMAX in 3GPP networks[END_REF][START_REF] Song | Improvements to seamless vertical handover between mobile WiMAX and 3GPP UTRAN through the evolved packet core[END_REF], in order to facilitate the seamless inter-RAT handover between 3GPP networks and non-3GPP networks. The main ANDSF feature is to assist the UE to discover the non-3GPP access networks. A comparison between these techniques can be found in [START_REF] Khattab | A Survey on MIH vs. ANDSF: Who Will Lead the Seamless Vertical Handover through Heterogeneous Networks?[END_REF][START_REF] Tuysuz | Energy-efficient vertical handover parameters, classification and solutions over wireless heterogeneous networks: A comprehensive survey[END_REF]. From this comparison, it results that MIH is very appropriate in many kinds of scenarios while presenting a low implementation complexity than ANDSF. Furthermore, it is concluded that ANDSF needs additional entities such as the FAF (Forward Authentication Function) proposed in [START_REF] Taaghol | Seamless integration of mobile WiMAX in 3GPP networks[END_REF] and the DFF (Data Forwarding Function) as proposed in [START_REF] Song | Improvements to seamless vertical handover between mobile WiMAX and 3GPP UTRAN through the evolved packet core[END_REF], in order to have good performance. In our work, we have been inspired by these MIH features and we used them in a combination with the PMIPv6 ones, especially for the signaling and the disconnection detection tasks that are handled by the MAG in the PMIPv6 domain.

Therefore, we have proposed the algorithm illustrated by the flowchart presented in the figure 7.

In this figure 7, we show how our approach works. It is launched when the mobile starts and is not connected to any network interface. Then, when it arrives in the coverage of the first available network, it simply connects to it in the usual way. At this time, it becomes connected to one network and apply the Best Effort principle. Then, the mobile has to monitor for other potential networks to which it can connect using the MIH standard principle [START_REF]IEEE Std[END_REF][START_REF] Jose | PMIPV6-HC-MIH: An approach for improving handover performance in NGWN[END_REF]. If available (which means that the Received Signal strength Indicator (RSSI) is higher enough to be connected to this network), it has to anticipate the potential next handover process, but it remains connected to the current network. Reason why, the mobile directly connects to it and becomes connected to, at least, two networks.

The fact of being connected to two networks or more can be exploited in order to maximize the probability of receiving packets, when one interface goes down. This can be achieved by asking the logical interface to ensure the redundancy of received packets after a detection of a disconnection of one of the physical interfaces by duplicating the received messages on the available physical interfaces. When implemented, this feature might help in increasing the packet delivery ratio and also the throughput. This is also possible because in our use-case (VANETs), we assume that the battery or energy are less restrictive than for other networks such as mobile phones or sensors in WSN. This is why we consider that, being simultaneously connected to multiple network will have no more impact on the battery life and therefore on the connection duration.

Since the mobile just connects to the new network, but it does not directly trigger a handover, we also avoid the ping pong aspect. This is because, even when the mobile did not last in the new network or if the anticipation fails (anticipation error), it remains connected to, at least, one other network, so that no more handover process is needed. It has just to well route the affected flow, which was attached to the RAT which becomes disconnected (for example LTE device at step 2 in this figure 6), to the remaining connected RAT (ITS G5 or WLAN, at step 4 in the same figure 6). For that, it firstly creates a tunnel (GRE tunnel) done in step 3 in this figure. The selection of the best candidate network could be done using a suitable Multiple Attribute Decision-Making (MADM) method such as fuzzy logic or Analytical Hierarchy Process (AHP) in order to verify their respective QoS capability and respect the user QoE and Service Level Agreement (SLA). Thanks to our logical interface, which always presents one HNP to the host IP layer and serves as a gateway to external network outside the vehicle, all this process takes place only inside the mobile node (vehicle) in layer 2, without loss of IP session conectivity. This proves that the mobile communication and session will be kept and guaranted to other correspondents. We have, then, reduced all the handover latency, the packet loss and the message overhead that were produced when exchanging messages between LMA and MAGs. All packets from external networks (WiFi, LTE, ITS G5) will be delivered whether their respective link type is up or down.

Pratical and application use-case: remote monitoring of self-driving cars

In order to test our proposed approach, we considered the use-case of remotely monitoring and collecting information for autonomous self-driving car, as illustrated by figure 8. For that, we have a data center which collects real time information about a selfdriving car. When data are received within this remote server located in the traffic center office, a traffic operator can analyze them and alert the passenger in the driving car in case of self-driving car deficiency (data alerting from sensors, possible loss of connection, weather problem, GPS inaccurracy, battery discharges, path prediction error, etc).

In order to test the applicability, we have performed simulation using NS3 and results show that packets destined to LTE device are well delivered and received through the ITS-G5 device when the LTE device becomes down and vice-versa. It is to be mentioned that due to this considered application, our main objective were the reduction of lost packets number and latency. It is to be noticed also that concerning the technologies and for the sake of tested deployment, we choose the two widely available technologies at the moment, which are the WIFI and Cellular (LTE) networks in addition to the ITS-G5 (IEEE 802.11p) which is specific to VANETs. Concerning the 5G, our approach could be easily extended to consider it as an additional available technology, after finalizing its deployment.

For the rest of the paper, the analytical results are detailed in section 5 while simulation results are discussed in section 6.3.2.

Analytical model and numerical results discussion

We used the model described in [START_REF] Jung | Distributed mobility control in Proxy Mobile IPv6 networks[END_REF], where performance in terms of costs of some DMM scheme were analyzed, to perform our approach measures. The extended model is illustrated by figure 9, where the correspondent Node (CN) represents a static remote server and the Mobile Node (MN) is the mobile vehicle which will need to perform a handover. This cost is related to the total cost required for binding update with LMA and for data packet delivery from CN to MN. In [START_REF] Jung | Distributed mobility control in Proxy Mobile IPv6 networks[END_REF], authors have compared two existing schemes (PMIP and PMIP-LR) and their three proposed schemes i.e. Signal-Driven PMIP (S-PMIP), Data Driven Distributed-PMIP (DD-PMIP), and Signal-Driven Distributed PMIP (SD-PMIP). Authors of [START_REF] Kim | Distributed mobility management in proxy mobile IPv6 using hash function[END_REF] have also proposed the Hash-based Distributed PMIPv6 (PMIP-HD) solution that we have already described in section 3.2.1. We compared our approach to their solutions. The parameters used in this cost analysis are described in the table 2, whereas their 535 respective values used in the analytical comparison are given in the table 3.

Cost analysis

The cost analysis for the classical PMIPv6 is detailed in [START_REF] Kim | Distributed mobility management in proxy mobile IPv6 using hash function[END_REF] and is given as follows: The Binding Update Cost (BUC) is equal to:

BU C P M IP =T setup + S control × 2T M AG-LM A + P LM A =T setup + S control × 2τ H M AG-LM A + αlog(N M AG × N Host ) (1)
and the Packet Delivery Cost (PDC) is expressed as:

P DC P M IP =S data (T CN -M AG + 2T M AG-LM A + T M AG-M N ) + P LM A =S data (κH CN -M AG + 2τ H M AG-LM A + κH M AG-M N ) + βlog(N M AG × N Host/M AG ) (2) 20
Then, we get the Total Cost (TC) by summing the BUC and the PDC as follows:

T C P M IP =BU C P M IP + P DC P M IP (3)
Following the same philosophy, the binding update (step 2) which takes place between the new MAG and the intermediate MAG (respectively MAG2 and MAG3 in figure 8) takes at least two control messages (PBU/PBA). Therefore, the BU C 1 of PMIP-HD is expressed as:

BU C 1 =S Control × 2T M AG-M AG + P hash + P M AG , (4)
where:

T M AG-M AG = τ H M AG-M AG , P hash is the processing cost of Hash function using MN-Home Address (MN-HoA) 540 at MN-MAG and P M AG is the processing cost for binding update to the designated MAG. Therefore: P hash = δlog(N Host/M AG ) and

P M AG = αlog(N Host/M AG )
The signaling operation for binding query (step 4) which takes place between the CN-MAG and the intermediate MAG (MAG3 in figure 8) when CN have a data to sent to MN, also takes 2 control messages (PBQ/PQA) [START_REF] Jung | Distributed mobility control in Proxy Mobile IPv6 networks[END_REF]:

BU C 2 =S Control × 2T M AG-M AG + P hash (at CN-MAG) + P M AG (5)
Therefore, we obtain that the total Signaling Control Cost (SCC) of PMIP-HD is equal to:

SCC P M IP -HD =BU C 1 + BU C 2 (6)
which gives us:

SCC P M IP -HD =T setup + 2 × (S control × 2T M AG-M AG ) + 2 × (P hash + P M AG ) =T setup + S control × 4τ H M AG-M AG + 2δlog(N Host/M AG ) + (α + β)log(N Host ) (7)
and the packet Data Delivery Cost (DDC) of PMIP-HD is given as:

DDC P M IP -HD =S data (T CN -M AG + T M AG-M AG + T M AG-M N ) + P M AG =S data (κH CN -M AG + τ H M AG-M AG + κH M AG-M N ) + βlog(N Host ) (8)
Thus, the total cost of PMIP-HD becomes:

T C P M IP -HD =SCC P M IP -HD + DDC P M IP -HD (9)
In our approach (PMIP-MIVH), we reduced this cost by anticipating the connection setup time T setup , and by eliminating the new address configuration time µ in the handover process by using the proposed logical interface. Therefore, our P M AG (for binding update to the designated MAG) becomes

P M AG =(α -µ)log(N Host/M AG ) (10)
That gives the handover Signaling Control Cost of our approach as:

SCC P M IP -M IV H =S control × 2T M AG-M AG + P hash + P M AG + S control × 2T M AG-M AG + P hash + P M AG =S control × 4τ H M AG-M AG + 2δlog(N Host ) + (α -µ + β)log(N Host ) (11)
and the packet Data Delivery Cost is the sameas that of PMIP-HD:

DDC P M IP -M IV H =DDC P M IP -HD (12)
Then, we get the Total Cost of our approach, denoted T C P M IP -M IV H , equals to:

T C P M IP -M IV H =SCC P M IP -M IV H + DDC P M IP -M IV H (13)

Numerical analysis

In order to validate our approach, we have compared our proposed solution PMIP-MIVH to the classical PMIPv6 and the PMIP-HD solutions. For simplicity, we only considered the PMIP-HD in the category of distributed mobility management (DMM) candidates because it has been already compared to the other DMM schemes in [START_REF] Kim | Distributed mobility management in proxy mobile IPv6 using hash function[END_REF],

where it shows that it outperforms them. We have chosen to measure the performance in terms of: the setup time impact on the total cost, the impact of the number of hosts per MAG and the impact of binding update cost in order to test how much our solution is scalable, and finally the impact of the distance represented as the hop count between the PMIP entities (LMA and MAGs). The parameters values are reported in the table 3.

All results are expressed in Unit Cost.

Figure 10 shows the impact of the setup time on the total costs. It can be clearly noticed that the classical PMIP has the highest total cost (figure 10a). Thus, its total cost is up to 51666.4 against 14828.1 for PMIP-HD and 14323.5 for PMIP-MIVH when the setup time T setup is 500 ms. We added the figure 10b in order to higlight the improvement of our approach compared to PMIP-HD. Thanks to our anticipation of this setup time, our approach has the lowest total cost and the handover is not anymore impacted by this time as done in other schemes. Through this figure 10b, we notice that when the time T setup increases, the total cost remains constant in our proposed approach while the total cost of PMIP-HD increases proportionally to the T setup . This proves that by anticipating this setup time, we can improve the handover performance. Therefore, our approach represents a 3.40% of improvement compared to the PMIP-HD and up to 72.27% compared to PMIP, for T setup equals to 500 ms.

Figure 11 shows the impact of the number of host per MAG N Host/M AG , which therefore increases the BUC in log scale. It shows that our approach is well adapted to high number of hosts and presents a 3.41% of improvement compared to the PMIP-HD and 72.2% compared to the classical PMIP. Here also, we used figure 11b in order to higlight the performance of our approach compared to PMIP-HD. This results highly depend on the Binding Cache design which influences the lookup time. The increasing of the curves is not linear and is not proportional to the increase of N Host/M AG , thanks to our consideration of using an optimal BC design like a hash table or a Balanced Binary Search Tree (BBST) using a hash function 3 . That is why we use the log scale of N Host/M AG in the total cost analysis equations in section 5.1. Other optimal BC designs might be achieved by using other optimal search designs (such as the optimal binary search tree 4 ) in which the search operation time is in a log scale of the number of stored hosts on the MAG. Therefore, the difference is not noticeable until when N Host/M AG represents a high exponential value with base 10.

Figure 12 shows the impact of the Binding Update Cost. It shows that our approach benefits from the usage of the logical interface and the presentation of only one HNP to IP layer in order to reduce, in average, about 3.39% and 72% to the binding impact compared to PMIP-HD and PMIP respectively.

Figure 13 shows that the increasing of hop count between MAGs has a high impact on the total cost in PMIP-HD and in our approach while it has a constant im- pact in PMIP. However, our approach performs better than PMIP-HD with an average difference of 504 (unit cost). Therefore, PMIP has the highest total cost even though it remains constant. This shows the advantage of Distributed Mobility Manage-595 ment (DMM) approaches compared to centralized mobility management approaches. Furthermore, we can notice that when H M AG-M AG equals to 10, the total cost of the PMIP-HD solution and our approach starts to double the respective total cost at H M AG-M AG =1. In the figure 14, we show that the hop count between LMA and MAG drastically impacts the total cost in PMIP due to the centralized traffic through 600 the LMA, which also impacts the scalability of the whole network. However, it shows Figure 12: Alpha value impact on the total costs Figure 13: Hop count between MAGs impact on the total costs that our approach has similar performance as PMIP-HD, because they both benefit from the distributed architecture, and therefore, there is no traffic which passes through the LMA.

Figure 14: Hop count between LMA and MAG impact on the total costs 6. Simulation setup and results

Implementation details and validation

To test and validate our proposed method of vertical handover, named Proxy MIPv6based Mobile Internal Vertical Handover (PMIP-MIVH), we have performed simulation using 3 interfaces per vehicle: one for ITS G5 (also known as WAVE), one for LTE and another one for WIFI. We followed the PMIPv6 implementation as described in [START_REF] Choi | Implementation and evaluation of proxy mobile IPv6 in NS-3 network simulator[END_REF]. Then, we modified and extended some components from this specification, especially the Ipv6L3Protocol. Concerning the LTE implementation, we have followed the specification of supporting PMIPv6 standard in LTE [START_REF] Etsi | Universal Mobile Telecommunications System (UMTS);LTE; Architecture enhancements for non-3GPP accesses (3[END_REF][START_REF] Etsi | Universal Mobile Telecommunications System (UMTS);LTE;Proxy Mobile IPv6 (PMIPv6) based Mobility and Tunnelling protocols[END_REF]. Therefore, as we are in the context of vertical handover, the S1 interface (between the eNB and SGW) and S5/S8 interface (between SGW and PGW) were used. Note also that the X2 interface (between eNBs) is available, but it is often used for horizontal handover (intra-LTE and inter-LTE Handovers). More details about these interfaces can be found in our previous published work [START_REF] Tuyisenge | Handover Mechanisms in Internet of Vehicles (IoV): Survey, Trends, Challenges, and Issues[END_REF]. Thereafter, we implemented the logical interface feature which is described by the algorithm 1. We use one logical interface (as VirtualNetDevice instance) per vehicle, which will be the only interface visible outside of a vehicle, to serve as a gateway for other available interfaces (physical network devices). From the point of view of upper layers and CNs, these latter interfaces are therefore seen as virtual devices installed inside the vehicle, while the logical interface becomes shown as the physical device of the mobile. However, this logical interface has an exception: it could not be turned down (Radio Agnostic as proned by PMIPv6) to the CNs and upper layer's point of view. Thus, it allows the transparent handover execution and the session continuity maintenance.

We designed and implemented the scenario illustrated by the figure 8 in NS3. Using the wireshark software and our PCAP logs, we have therefore measured and checked if all the PMIPv6 major functions and requirements presented in section 3.1 are present and are well functioning. In fact, we firstly validated the the MN attachment detection. Then, the binding and registration function has been checked through PBU and PBA messages analysis. We analyzed also the establishment of the tunnel between the PMIP entities (MAGs and LMA). After that, we have also validated the implementation of the logical interface and MIVH by plotting the receiving interface per packet with MIVH and without it (figure 15a), as well as the throughput (figure 15b). Through figure 15a, it can be seen that the vertical handover takes place between the 15 th second and 20 th second in the simulation. It can be seen that our approach (PMIP-MIVH) receives more packets (every point represents a received packet), compared to the PMIP-HD during this interval (15-20 sec). This is also confirmed by the figure 15b which demonstrates a great improvement (throughput difference) on our proposed approach PMIP-MIVH compared to the PMIP-HD approach in this period between the 15 th second and the 20 th second. After this implementation validation, we followed by measuring general metrics performance.

Performance metrics definitions

For handover performance measurement, we consider 2 unicast real-time applications using UDP between the UE and the CN (application of remote monitoring and trajectory correction of a self-driving car). In the first application, CN is the sender and UE is the receiver (remote driving command informations), whereas the UE is the sender and CN is the receiver in the second application (collection of vehicles data from vehicle's sensors). This allows us to test the real-time application metrics. The definition and description of the measured performance metrics are given below:

• End-to-End delay: It represents the time that a packet takes to travel from the sender node to the receiver node. It is calculated as the difference between the reception timestamp at the receiver and the transmission timestamp at the sender.

Delay = Reception time -Transmission time (14)

• Jitter: It represents the variation between the packets' delay. It is the time difference in the packet inter-arrival time. In other words, the jitter is a delay that causes some packets to arrive later than the expected arrival time at the destination. It is calculated by monitoring the variation of the difference time between the reception time for the current packet and the reception time of the previous packet at the receiver node side.

• Packet Delivery Ratio (PDR): it represents the reception ratio. It is calculated as the ratio between the total received unicast packets divided by the total sent unicast packets.

PDR = total received packets total sent packets (15)

• Packet Error Rate (PER): it reperesents the packet loss ratio. It gives an idea on the total number of lost packets compared to the total number of sent packets.

• Throughput: It represents the datarate at which packets were sent on the available bandwidth of the channel. It is calculated by measuring the number (multiplied by the size) of received packet per unit of time (second).

Throughput = Total received packets × Packet size Duration [START_REF] Thaalbi | Improving vertical handover over heterogeneous technologies using a cross layer framework[END_REF] where duration represents the time during which the considered total received packets number were sent from the transmitter and received at the receiver. We have then varied the number of host per MAG in order to evaluate the impact of the binding and lookup time at the PMIPv6 entity (MAGs and LMA), then we varied the hop count between MAGs. Finally, we varied the packet size in order to consider applications which might use high data volume in communications such as VoIP and real-time applications, as it might happen in self-driving cars. Simulation results are given and discussed in the next section 6.3.2.

Comparison and discussion of the simulation results

In the following simulation results and discussion, we will consider the DMM solutions by comparing our proposed PMIP-MIVH solution with PMIP-HD for the reasons already explained in the section 5.2. Through figure 17, we aim to verify the impact of lookup time by increasing the 690 number of UEs that are present in the simulation, and consequently, which might increase the BC table size. For both solutions (PMIP-HD and our solution PMIP-MIVH), when measuring the PDR (figure 17a) and consequently the PER (17b), we notice that the PDR decreases as the number of UEs increases. Consequently, the PER increases as the UEs number increases. This variation is also remarked for the throughput (fig- 695 ure 17d) which decreases as the UEs number increases. The jitter, illustrated by figure 17c, increases according to the increasing of the number of UEs. This proves that the lookup has an important impact on the vertical handover process. However, in all of these measured performance metrics, our approach shows an improvement. Indeed, until the average number of UEs (4 UEs at these figures), our PMIP-MIVH presents higher PDR and higher throughput compared to the PMIP-HD. PMIP-MIVH has also lower PER and jitter. Even though, these values degrade very rapidly when the number of UEs increases. These results highly depend on the number of resources that are available at the MAGs and consequently, how these resources are managed. Notice that the resource management [START_REF] Adouane | Dynamic management of spectral resources in LTE networks[END_REF][START_REF] Masiuk | Resource management method in LTE heterogeneous networks[END_REF] is very complex and very different on Wifi technology from LTE one. Few thorough reviews on resource management are available in [START_REF] Ku | Resource allocation and link adaptation in LTE and LTE Advanced: A tutorial[END_REF][START_REF] Adouane | Dynamic management of spectral resources in LTE networks[END_REF]. It is noticed here that the resource management is outside of this paper scope.

Impact of distance between MAGs

In order to see the impact of the number of MAGs in the PMIP domain, which may influence the distance between two MAGs (distance between the MN's MAG and the CN's MAG), we used the hop count between the MAGs and measure the PDR, PER, jitter, delay and throughput.

In figure 18a, illustrating the PDR, our PMIP-MIVH shows a difference of about (0.488166-0.360947= 0.127219) compared to PMIP-HD when the hop count is 40. This represents around 26% of improvement. This result is also remarkable for the PER in figure 18b. These results show that our approach highly benefits from the use of logical interface in order to increase the packets reception. In fact, by rerouting the received packets to the remained connected physical devices, the logical interface reduces the number of packets that might be lost in PMIP-HD by triggering the handover when an interface failed to correctly receive the packets due to a weak network coverage.

Concerning the jitter, figure 18c shows that our approach is still well performing, because it has for example (121.436-116.921= 4.515) ms less than PMIP-HD when the hop count between MAGs (hMAGMAG) is equal to 60. This represents around 3.71% of improvement in jitter in average. This also depends on the number of packets that are not correctly received or completely lost, which increases the jitter. An increase in the number of lost packets implies higher jitter.

The throughput improvement is illustrated by figure 18e. It can be seen that our method also improves the throughput of around (0.0624176-0.0467316 = 0.015686) MBits/sec in average. This represents on average, 25.13% of improvement. This is also due to the reduction of the number of lost packets thanks to the use of the logical interface in our approach.

The average delay measured ( 18d) does not show any great difference between the two approaches. However, this proves that our approach can improve the PDR and the throughput without degrading the delay performances, which is also very important, especially for non fault-tolerant applications.

Impact of packet size

In order to see what happens if we have a high volume data, we varied the packet size and measured the behavior of the two solutions. The results are illustrated by figure 19. On the figure 19a and19b, illustrating respectively the PDR and the PER, we see that until a certain packet size (1024 in our simulations), the PDR and respectively the PER do not change greatly. This means that both of the two solutions can support Meanwhile, our approach results are always lower than those of PMIP-HD and presents an improvement of over 1.16% when using packets of 1024 bytes.

Concerning the throughput, figure 19d shows that the throughput increases proportionally to the packet size. Which is an obvious and expected result, since it is calculated considering the packet size of the received packet during a sample interval period. Furthermore, we can notice that our approach have higher throughput values than the PMIP-HD solution. This is also due to the increase in the number of received packets in our approach than in the PMIP-HD. Which is also proved by the PDR. The obtained network topology was, then, loaded into the mobility simulator tool SUMO6 [START_REF] Lopez | Microscopic traffic simulation using SUMO[END_REF], which gives the network topology illustrated by the figure 21. From this exported network topology, we have generated the road traffic using the "ran-domTrips.py" script provided by SUMO. The simulation duration was set to 300 seconds. Then, we have exported the generated traffic flow into an XML trace file using the SUMO application and the "fcd-output" switch flag. Regarding the mobility model, we have used the IDM (Intelligent Driver Model7 ) car-following model [START_REF] Chen | Calibration of MITSIM and IDM car-following model based on NGSIM trajectory datasets[END_REF] in order to generate random trips. We used the Dijkstra algorithm as path finding algorithm. The arrival rate 1/p was calculated by using the period (p) which is given by the formula: p = duration/n where n represents the maximum number of vehicles, that are integrated during the duration time. The following step was to export these traces to the NS2 mobility format using the "traceExporter.py" script. Finally, we applied these traces to the mobility of our vehicles in the network simulator NS3. The other infrastructure components such as the RSUs, the MAGs, the correspondent server node (CN), the SGW and PGW nodes still static during all the simulations by assigning them the constant mobility model. As a result, we have the following topology illustrated by the figure 22, that has been plotted using NetAnim. Results of the simulation are discussed in the following sub-section.

Comparison and discussion of the simulation results

Number of UEs impact

To verify the impact of the number of vehicles in the urban mobility scenario, we have launched simulations by varying the number of vehicles from 20 to 200 vehicles. To be able to reach this number of vehicles, we have increased the bandwidth (in terms of resource blocks) available on the LTE eNBs. Therefore, we have obtained the following results as illustrated by the figure 23. In the figure 23a, the PDR is plotted. We see that the PDR decreases as the number of vehicles increases. Consequently, we see that the PER, plotted in the figure 23b increases when the number of vehicles increases. This means that the density in urban mobility can have an impact on the reception of packets, depending on the number of packets that have been sent. Therefore, a tradeoff between the packet frequency and the density must be chosen in order to maintain a good PDR. However, the important thing to be noticed is that our approach presents better results compared to the PMIPv6-HD. Indeed , our approach still present around 6.41% of improvement over the PMIPv6-HD solution, especially in high density (above 120 vehicles). In order to validate our assumption about the density impact in the PDR, we have calculated the average delay. Thus, we illustrated it in the figure 23d, in which we see that the density of 120 vehicles was a good tradeoff in our simulation scenario. Hence, we can see that the delay increases proportionally to the increase of the vehicles number, until it reaches 1 second when the number of vehicles equals to 120 vehicles. After that, the delay starts to decrease, which means that the vehicles are now smoothly distributed in the simulation area. This means that each vehicle has at least one vehicle in its vicinity. Here also, we can see that our approach still do better compared to the PMIP-HD. Indeed, it stills present 5.8% lower delay values than PMIPv6-HD for 120 vehicles. The jitter illustrated by the figure 23c shows also that the jitter stops to linearly decrease when the density is sufficient. It tends to stabilize itself after a density of 120 vehicles. The figure also validates that our approach has improved the jitter.

Finally, we have calculated the goodput, in order to see why the PDR decreases despite the density stabilization and the connectivity establishment. It is to be noticed that the goodput, which is the ratio between the delivered amount of information and the total delivery time, is different from the throughput. This goodput is illustrated by figure 23e. Despite the PDR decrease, we can see that the goodput (which also reflects the number of received packets) increases as the number of vehicles increases. However, due to the number of vehicles and the frequency of sending packets, the number of sent packets becomes very large in high density and causes more collisions. This causes that a great number of packets are not correctly delivered and become lost. Nevertheless, we see that our approach outperforms the PMIPv6-HD solution. This validates the improvement and contribution of our approach compared to existing solutions in the urban scenario as it was demonstrated previously in the highway scenario.

Conclusion and perspectives

Vertical handover is one of the key technologies that will enable the connected and autonomous vehicles deployment. In this paper, we have proposed a vertical handover management approach, which reduces the Binding Update time by eliminating the setup time. Our proposed approach improves the handover performances thanks to the anticipation of the next handover by connecting simultaneously to different available networks using the PMIP-HD architecture. Our approach also takes benefit from a proposed logical interface in order to maintain the connectivity session. We have proposed and described the implementation of the proposed PMIP-MIVH vertical handover management in VANETs context. Numerical analysis shows that our proposed approach outperforms the existing mobility management schemes. We also highly focus our attention on the implementation and simulation of the proposed solution using the well-known and most used Network Simulator version 3 (NS3). We have described and conducted thoroughly the performance metrics in terms of packet delivery ratio (PDR), packet error rate (PER), delay, jitter and throughput. We have varied the number of UEs in order to test the scalability of our approach in a highway scenario. The simulation results confirmed the analytical ones. They show that our proposed PMIP-MIVH outperforms the existing solutions. Furthermore, we extended our simulations by considering an urban mobility scenario using the SUMO traffic modeling tool. We exported the mobility of the Reims city in France from OpenStreetMap in order to deepen the performance test of our proposed model. The results of the urban mobility consolidate the results of the highway mobility simulations. Moreover, both of these simulations results validate the analytical results. They all show that our approach outperforms the existing solutions in terms of handover management in VANETs field. As perspectives, our future works will focus on designing a testbed in order to evaluate this solution in more realistic scenario and consider more real-time parameters and requirements. We also intend to design a more efficient handover decision algorithm to enhance the performances of this logical interface-based approach. Furthermore, we will design and implement the flow mobility mechanism in order to efficiently use the resources when the dual (or multiple) connections are available for long time. Due to the number of collisions that occur in dense simulations, we will also direct our future works to look for an inclusion of a collision avoidance algorithm in order to increase the reception ratio in high density environment.

Figure 1 :

 1 Figure 1: PMIPv6 architecture [22]

ProxyFigure 3 :

 3 Figure 3: PBU and PBA extended format to give respectively PBQ and PQA by adding the Q flags for P-DMM schemes [22].

Figure 4 :

 4 Figure 4: Context of the proposed approach

Figure 5 :

 5 Figure 5: Proposed Mobile Internal Vertical Handover architecture and location of the proposed logical interface in the TCP/IP model.

Figure 6 :

 6 Figure 6: Implementation architecture of the PMIP-MIVH inside the vehicle.

Figure 7 :

 7 Figure 7: Flowchart of the Algorithm of the proposed PMIP-MIVH approach

Figure 8 :

 8 Figure 8: Application use-case architecture

Figure 9 :

 9 Figure9: Network model for numerical analysis[START_REF] Jung | Distributed mobility control in Proxy Mobile IPv6 networks[END_REF]

Figure 10 :

 10 Figure 10: (a) Setup time impact on the total cost. (b) Zoom of the Setup time impact between PMIP-HD and PMIP-MIVH.

Figure 11 :

 11 Figure 11: (a) Impact of the number of hosts per MAG on the total costs. (b) Zoom of impact of the number of hosts per MAG between PMIP-HD and PMIP-MIVH.

Figure 15 :

 15 Figure 15: (a) Comparison of the receiving interface per packet. (b) Real-time throughput with samples interval of 0.5 seconds

6. 3 .

 3 Highway mobility scenario 6.3.1. Scenario settingsFor the mobility topology in this first scenario, we considered a two-lane highway as illustrated by the figure16, vehicles are moving in the same direction, with 20m as inter-vehicle distance. The used mobility model is "Constant Velocity Mobility Model". Regarding the wifi channel, we maintained the default model, which means that we create a channel model with a propagation delay equal to a constant the speed of light, and a propagation loss based on a log distance model with a reference loss of 46.6777 dB at reference distance of 1m. Figure16represents a NetAnim 5 screenshot, illustrating the simulation scenario, and default parameters that we used in the simulation are given in the table 4.

Figure 16 :

 16 Figure 16: Example of simulation scenario

Figure 17 :

 17 Figure 17: Number of UEs impact: (a) PDR (b) PER (c) Jitter (d) Throughput

Figure 18 :Figure 19 :

 1819 Figure 18: Impact of distance between MAGs: (a) PDR (b) PER (c) Jitter (d) Delay (e) Throughput

6. 4 .

 4 Urban mobility simulation using SUMO 6.4.1. Scenario settings In this second scenario, we have imported a real map of the Reims City in France from OpenStreetMap, as illustrated by figure 20.

Figure 20 :

 20 Figure 20: Imported urban mobility scenario of Reims city from OpenStreetMap

Figure 21 :

 21 Figure 21: Reims urban network loaded into the mobility simulator tool SUMO

Figure 22 :

 22 Figure 22: Urban network mobility in the NetAnim visualization tool

Figure 23 :

 23 Figure 23: Number of UEs impact: (a) PDR (b) PER (c) Jitter (d) Delay (e) Goodput

Table 1 :

 1 Main handover categories

	Criteria	Categories Description	Examples
	Technologies Horizontal Intra-system	Wifi
		Vertical	Inter-systems	Wifi to 3G
	Execution	Hard	Break before Make	MIPv4 [7, 8, 9, 10],
				MIPv6 [11]
		Soft	Make before Break	PMIPv6 [13]
	Decision ac-	MN-based Mobile	MIPv4 [7, 8, 9, 10],
	tor			MIPv6 [11]
		Network-	Network	NEMO [12] , PMIPv6
		based		[13]
		Hybrid	Mobile assisted by Net-	Variables: DMM [14]
			work

L2 dettachment L2 attachment Lookup MNID &Profile (AAA) Router Advertisement Address configuration PBA(MNID,HNPs, Status) Lookup MNID Create/Update BCE, HNPs Allocation Create/Update Tunneling Router solicitation Binding/ Update BCE, Setup /Update Tunnel and routing PBU(MNID,Profile) PBU(MNID,HNPs) MinDelayBefore BCE entry delete timer PBA(MNID,HNPs, Status) <Tunnel> <Tunnel>

  and figure 2. As shown in both these two figures, the two main messages are denoted PBU (Proxy Binding Update) and PBA (Proxy Binding Acknowledgement).

	MN	Old MAG	LMA	New MAG
			(a)
	Figure 2: Sequence diagram of PMIPv6 main functions for the control plane

Table 2 :

 2 Description of Parameters used for cost analysis

	Parameters Description
	T a-b	Transmission cost of a packet between
		nodes a and b
	Pc	Processing cost of node c for binding
		update or lookup
	Tsetup	Setup time of PMIP connection be-
		tween MN and MAG
	N Host/M AG Number of active hosts per MAGs
	NMAG	Number of MAGs in the PMIP domain
	H a-b	Hop count between nodes a and b in the
		network
	S control	Size of control packet (in bytes)
	SData	Size of control packet (in bytes)
	α	Unit cost of binding update with LMA
	β	Unit cost of lookup for MN at LMA or
		MAG
	τ	Unit Transmission cost of a packet per
		a wired link (hop)
	κ	Unit Transmission cost of a packet per
		a wireless link (hop)
	δ	Unit cost of hash operation at MAG
	µ	Unit cost of new MN address or HNP
		configuration

Table 3 :

 3 Parameters values used for cost analysis

					Constants	Default
					HMN-MAG	1
	Variables	Default Min	Max	HCN-MAG
	T setup(ms)	200	100	500	S control (bytes) 50
	N Host/M AG	200	100	1000	SData(bytes)	1024
	HMAG-LMA	20	10	100	β	1
	HMAG-MAG	5	1	10	τ	1
	α	3	1	10	κ	4
					δ	1
					µ	2

Table 4 :

 4 Default parameters values used in the simulation

	Variables		Default Min	Max
	N Host/M AG	4	1
	HMAG-MAG	20	10
	Packet	size	1024	256
	(bytes)
	Speed (m/s)	20	10
	Constants		Default
	HMN-MAG		1
	HCN-MAG
	α			3
	β			1
	τ			1
	κ			4
	first MAG position	(250,80,0)
	first AP position	(250,60,0)
	second MAG position	(620,80,0)
	second AP position	(620,60,0)
	PGW (LMA) position	(270,120,0)
	SGW position		(400,60,0)
	CN position		(275,300,0)
	first RSU position	(200,90,0)
	UE start position	(0,0,0)
	eNB DL EARFCN	100 MHz
	eNB UL EARFCN	18100 MHz
	eNB DL bandwidth	25 RBs
	eNB UL bandwidth	25 RBs
	eNB TxPower		46 dBm
	Mobility Model		ConstantVelocity,
				ManhattanGrid, Ran-
				domWaypoint
	inter-Vehicle distance	20 m
	number of road line	2
	Wifi PHY model	YansWifiPhy
	Wifi MAC model	NqosWifiMac
	WAVE MAC model	NqosWaveMac	with
				OcbWifiMac

https://interactivepython.org/runestone/static/pythonds/SortSearch/ Hashing.html

The OCB (Outside the Context of a BSS) enables all the mobiles in the range to directly communicate with each other. Neither authentication/association procedures nor security mechanisms are often supported. Thus the data exchange should (need to) be established in fractions of seconds.

http://www.ilikebigbits.com/2016_08_28_hash_table.html

https://www.gatevidyalay.com/time-complexity-of-bst-binary-search-tree/

An offline animator based on the Qt toolkit, which animates the simulation using an XML trace file collected during simulation. https://www.nsnam.org/wiki/NetAnim_3.108

https://github.com/eclipse/sumo

https://en.wikipedia.org/wiki/Intelligent_driver_model

Acknowledgements

This work was supported by the University of Reims Champagne-Ardenne in partnership with VEDECOM institute.