Vehicular Mobility Management for IP-Based Vehicular Networks
Jaehoon Paul Jeong, Ed.
Department of Computer Science and Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
+82 31 299 4957
+82 31 290 7996
pauljeong@skku.edu
http://iotlab.skku.edu/people-jaehoon-jeong.php
Bien Aime Mugabarigira
Department of Electrical and Computer Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
+82 10 5964 8794
+82 31 290 7996
bienaime@skku.edu
Yiwen Chris Shen
Department of Electrical and Computer Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
+82 31 299 4106
+82 31 290 7996
chrisshen@skku.edu
Hyeonah Jung
Department of Computer Science and Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
+82 31 299 4106
+82 31 290 7996
hyeonah214@skku.edu
25 July 2022
Internet
IPWAVE Working Group
Internet-Draft
This document specifies a Vehicular Mobility Management (VMM) scheme for IP-based vehicular networks. The VMM scheme takes advantage of a vehicular link model based on a multi-link subnet. With a vehicle's mobility information (e.g., position, speed, acceleration/deceleration, and direction) and navigation path (i.e., trajectory), it can provide a moving vehicle with proactive and seamless handoff along with its trajectory.

Introduction
This document proposes a mobility management scheme for IP-based vehicular networks, called Vehicular Mobility Management (VMM). The VMM is tailored for a vehicular network architecture and a vehicular link model described in the IPWAVE problem statement document [ID-IPWAVE-PS].
Vehicle Neighbor Discovery (VND) is proposed as Extended IPv6 Neighbor Discovery (ND) for IP-based vehicle networks [ID-IPWAVE-VND] to support the vehicle-to-vehicle or the vehicle to Road-Side Unit (RSU) interactions. For an efficient IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862], VND adopts an optimized Address Registration using a multihop Duplicate Address Detection (DAD). This multihop DAD enables a vehicle to have a unique IP address in a multi-link subnet consisting of multiple wireless subnets with the same IP prefix, which corresponds to wireless coverage of multiple RSUs. VND also supports IP packet routing over a connected Vehicular Ad Hoc Network (VANET) by allowing vehicles to exchange the prefixes of their internal networks through their external wireless interface.
The mobility management in this multi-link subnet needs a new approach from the legacy mobility management schemes. This document aims at an efficient mobility management scheme called VMM to support efficient V2V, V2I, and V2X communications in a road network. The VMM takes advantage of the mobility information (e.g.,a vehicle's speed, direction, and position) and trajectory (i.e., navigation path) of each vehicle registered in the Traffic Control Center (TCC) of the vehicular cloud.

Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

Terminology
This document uses the terminology described in [RFC4861] and [RFC4862]. In addition, the following new terms are defined as below:
- DMM: Acronym for "Distributed Mobility Management" [RFC7333][RFC7429].
- Mobility Anchor (MA): A node that maintains the IP addresses and mobility information of vehicles in a road network to support their address autoconfiguration and mobility management with a binding table. It has end-to-end connections with RSUs under its control.
- On-Board Unit (OBU): A node that with a network interface (e.g., IEEE 802.11-OCB and Cellular V2X (C-V2X) [TS-23.285-3GPP]) for wireless communications with other OBUs and RSUs, and may be connected to in-vehicle's devices or networks. An OBU is mounted on a vehicle. It is assumed that a radio navigation receiver (e.g., Global Positioning System (GPS)) is included in a vehicle with an OBU for efficient navigation.
- OCB: Acronym for "Outside the Context of a Basic Service Set" [IEEE-802.11-OCB].
- Road-Side Unit (RSU): A node that has physical communication devices (e.g., IEEE 802.11-OCB and C-V2X) for wireless communication with vehicles and is also connected to the Internet as a router or switch for packet forwarding. An RSU is typically deployed on the road infrastructure, either at an intersection or in a road segment, but may also be located in cars parking areas.
- Traffic Control Center (TCC): A node that maintains the road infrastructure information (e.g., RSUs, traffic signals, and loop detectors), vehicular traffic statistics (e.g., average vehicle speed and vehicle inter-arrival time per road segment), and vehicle information (e.g., a vehicle's identifier, position, direction, speed, and trajectory as a navigation path). TCC is included in a vehicular cloud for vehicular networks.
- Vehicular Cloud: A cloud infrastructure for vehicular networks, having compute nodes, storage nodes, and network nodes.
- WAVE: Acronym for "Wireless Access in Vehicular Environments" [WAVE-1609.0].

Vehicular Network Architecture
This section describes a vehicular network architecture for V2V and V2I communication. A vehicle and an RSU have their internal networks including in-vehicle devices or servers, respectively.

Vehicular Network
A vehicular network architecture for V2I and V2V is illustrated in Figure 1. In this figure, there is a vehicular cloud containing a TCC. The TCC has Mobility Anchors (MAs) responsible for the vehicles mobility management. Each MA is in charge of the mobility management of vehicles under its prefix domain, which is a multi-link subnet of RSUs sharing the same prefix [ID-IPWAVE-PS]. A vehicular network is a wireless network consisting of RSUs and vehicles. The RSUs are interconnected via a wired network, allowing vehicles to build VANETs via V2V and V2I communications.

A Vehicular Network Architecture for V2I and V2V Networking

                     *-----------------------------------------*
                    *          TCC in Vehicular Cloud           *
                   *   +-------------------------------------+   *
 +--------+       *    |   +---------+         +---------+   |    *
 |  CN1   |<---->*     |   |   MA1   |<------->|   MA2   |   |     *
 +--------+      *     |   +---------+         +---------+   |     *
                  *    +-------------------------------------+    *
                   *           ^                    ^            *
                    *          |      INTERNET      |           *
                     *---------v--------------------v----------*
                      ^               ^                     ^
                      | Ethernet      |                     |
                      |               |                     |
                      v               v                     v
                 +--------+ Ethernet +--------+ Ethernet +--------+
                 |  RSU1  |<-------->|  RSU2  |<-------->|  RSU3  |
                 +--------+          +--------+          +--------+
                    ^                   ^                   ^
                    :                   :                   :
             +-----------------------------------+  +-----------------+
             |      : V2I           V2I :        |  |   V2I :         |
             |      v                   v        |  |       v         |
+--------+   |   +--------+       +--------+     |  |  +--------+     |
|Vehicle1|===>   |Vehicle2|===>   |Vehicle3|===> |  |  |Vehicle4|===> |
|        |<.....>|        |<.....>|        |     |  |  |        |     |
+--------+  V2V  +--------+  V2V  +--------+     |  |  +--------+     |
             |                                   |  |                 |
             +-----------------------------------+  +-----------------+
                            Subnet1                       Subnet2

      <----> Wired Link   <....> Wireless Link   ===> Moving Direction

In Figure 1, three RSUs are deployed either at intersections or along roadways. They are connected to an MA through wired networks. The vehicular network has two subnets, such as Subnet1 and Subnet2. Subnet1 is a multi-link subnet consisting of multiple wireless coverage areas of multiple RSUs, which share the same IPv6 prefix to construct a single logical subnet [ID-IPWAVE-PS]. That is, the RSU1 and RSU2 wireless links belong to Subnet1. Thus, since Vehicle2 and Vehicle3 use the same prefix for Subnet1, and that are within the wireless communication range, they can communicate directly with each other. Note that in a multi-link subnet, a vehicle (e.g., Vehicle2 and Vehicle3 in Figure 1) can configure its global IPv6 address through an address registration procedure that includes the multihop DAD specified in VND [ID-IPWAVE-VND].
Subnet2 on the other hand, uses a different prefix than Subnet1. Vehicle4 residing in Subnet2 cannot communicate directly to Vehicle3 because it belongs to a different subnet. Vehicles can construct a connected VANET so they can communicate with each other without relaying on RSU, but on the forwarding over the VANET. In the case where two vehicles belong to the same multi-link subnet, but they are not connected in the same VANET, they can use RSUs. In Figure 1, even though Vehicle1 is disconnected from Vehicle3, they can communicate indirectly with each other through RSUs such as RSU1 and RSU2.
This document specifies a mobility management scheme for the vehicular network architecture, as shown in Figure 1. Vehicle2 is supposed to communicate with the corresponding node denoted as CN1, and Vehicle2 is moving in the wireless coverage of RSU1. When Vehicle2 moves out of the coverage of RSU1 and moves into the coverage of RSU2 where RSU1 and RSU2 share the same prefix, packets sent by CN1 should be routed through RSU2 to Vehicle2. Also, when Vehicle2 moves out of the coverage of RSU2 and moves into the coverage of RSU3 where RSU2 and RSU3 use two different prefixes, the CN1 packets should be delivered to Vehicle2 via RSU3. A handoff procedure allows a sender's packets to be delivered to a destination vehicle which is moving within the wireless coverage areas.

Mobility Management
This section explains the detailed procedure of mobility management of a vehicle in a road network as shown in Figure 1.

Network Attachment of a Vehicle
A mobility management is required for the seamless communication of vehicles moving between the RSUs. When a vehicle moves into the coverage of another RSU, a different IP address is assigned to the vehicle, the transport-layersession information (i.e., an end-point's IP address) is reconfigured to avoid service disruption. Considering this issue, this document proposes a handoff mechanism for seamless communication.
In [VIP-WAVE], the authors constructed a network-based mobility management scheme using Proxy Mobile IPv6 (PMIPv6) [RFC5213], which is highly suitable for vehicular networks. This document uses a mobility management procedure similar to PMIPv6, but uses a newly proposed Shared-Prefix model in which vehicles in the same subnet share the same prefix.

Message Interaction for a Vehicle's Network Attachment

          Vehicle                    RSU                MA
             |                        |                  |
             |-RS with Mobility Info->|                  |
             |         [VMI]          |                  |
             |                        |                  |
             |                        |--------PBU------>|
             |                        |                  |
             |                        |                  |
             |                        |<-------PBA-------|
             |                        |                  |
             |                        |                  |
             |                        |===Bi-Dir Tunnel==|
             |                        |                  |
             |                        |                  |
             |<----RA with prefix-----|                  |
             |                        |                  |

Figure 2 shows the binding update flow when a vehicle entered the RSU subnet. The RSUs act as Mobility Anchor Gateway (MAG) defined in [VIP-WAVE]. When it receives an RS message from a vehicle containing its mobility information (e.g., position, speed, and direction), an RSU sends a Proxy Binding Update (PBU) message to its MA [RFC5213][RFC3775]. This contains a Mobility Option including the vehicle's mobility information. The MA receives the PBU and sets up a Binding Cache Entry (BCE) as well as a bi-directional tunnel (denoted as Bi-Dir Tunnel in Figure 2) between the serving RSU and itself. Through this tunnel, all traffic packets to the vehicle are encapsulated toward the RSU. Simultaneously, the MA sends back a Proxy Binding Acknowledgment (PBA) message to the serving RSU. This serving RSU receives the PBA and sets up a bi-directional tunnel with the MA. After this binding update, the RSU sends back an RA message to the vehicle. This message includes the RSU's prefix for the address autoconfiguration of the vehicle.
When the vehicle receives the RA message, it performs the address registration procedure including a multihop DAD for its global IP address based on the prefix announced by the RA message according to the VND [ID-IPWAVE-VND].
In PMIPv6, an MA (i.e., LMA) allocates a unique prefix to each vehicle to guarantee the uniqueness of each address, but in this document, an MA allocates in its domain a unique IP address to each vehicle with the same prefix through the multihop-DAD-based address registration. This unique IP address allocation ensures that vehicles own unique IP addresses in a multi-link subnet and can reduce the waste of IP prefixes in legacy PMIPv6.

Handoff within One Prefix Domain
When the vehicle changes its location and its current RSU (denoted as c-RSU) detects that the vehicle is moving out of its coverage, the c-RSU reports the leaving of the vehicle to the MA and de-register the binding via PBU.

Handoff of a Vehicle within One Prefix Domain with PMIPv6

   Vehicle            c-RSU                MA               n-RSU
      |                  |                  |                  |
      |                  |===Bi-Dir Tunnel==|                  |
      |                  |                  |                  |
      |                  |                  |                  |
      |                  |----DeReg PBU---->|                  |
      |                  |                  |                  |
      |                  |                  |                  |
      |                  |<-------PBA-------|                  |
      |                  |                  |                  |
      |                  |                  |                  |
      |                  |                  |                  |
      |                  |                  |                  |
      |                  |                  |                  |
      |(------------------RS with Mobility Info-------------->)|
      |                          [VMI]      |                  |
      |                                     |<-------PBU-------|
      |                                     |                  |
      |                                     |                  |
      |                                     |--------PBA------>|
      |                                     |                  |
      |                                     |                  |
      |                                     |===Bi-Dir Tunnel==|
      |                                     |                  |
      |                                     |                  |
      |<--------------------RA with prefix---------------------|
      |                                                        |

With this report, the MA will send back a PBA to notice the de-register to c-RSU, and get ready to detect new binding requests. If MA can figure out the new RSU (denoted as n-RSU) based on the vehicle's trajectory, it will directly change the end-point of the tunnel into n-RSU's IP address for the vehicle.
Figure 3 shows the handoff of a vehicle within one prefix domain (i.e., a multi-link subnet) with PMIPv6. As shown in the figure, when the MA receives a new PBU from the n-RSU, it changes the tunnel's end-point from the c-RSU to n-RSU. If there are ongoing IP packets toward the vehicle, the MA encapsulates the packets and then forwards them towards n-RSU. Through this network-based mobility management, the vehicle is not aware of any changes at its network layer and can maintain its transport-layer sessions without any disruption.

Handoff of a Vehicle within One Prefix Domain with DMM

        Vehicle               c-RSU              n-RSU
           |                     |                  |
           |---------------------|                  |
           |c-RSU detects leaving|                  |
           |---------------------|                  |
           |                     |--------PBU------>|
           |                     |                  |
           |                     |===Bi-Dir Tunnel==|
           |                     |                  |
           |                     |<-------PBA-------|
           |                     |                  |
           |                     |                  |
           |(--------RS with Mobility Info-------->)|
           |                 [VMI]                  |
           |                                        |
           |<------------RA with prefix-------------|
           |                                        |

If c-RSU and n-RSU are adjacent, that is, vehicles are moving in specified routes with fixed RSU allocation, the procedure can be simplified by constructing the bidirectional tunnel directly between them (cancel the intervention of MA) to alleviate the traffic flow in MA as well as reduce handoff delay.
Figure 4 shows a vehicle handoff within one prefix domain (as a multi-link subnet) with DMM [RFC8885]. The RSUs are in charge of detecting when a node joins or moves to its domain. If the c-RSU detects that the vehicle is going to leave its coverage and to enter the area of an adjacent RSU, it sends a PBU message to inform n-RSU of the vehicle's handoff. If n-RSU receives the PBU message, it constructs a bidirectional tunnel between c-RSU and itself, and then sends back a PBA message as an acknowledgment to c-RSU. If there are ongoing IP packets toward the vehicle, c-RSU encapsulates the packets and then forwards them to n-RSU. When n-RSU detects the entrance of the vehicle, it directly sends an RA message to the vehicle so that the vehicle can assure that it is still connected to a router with its current prefix. If the vehicle sends an RS message to n-RSU, n-RSU responds to the RS message by replying to the vehicle with an RA .

Handoff between Multiple Prefix Domains
When a vehicle moves from a prefix domain to another prefix domain, a handoff between multiple prefix domains is required. As shown in Figure 1, when Vehicle3 moves from the subnet of RSU2 (i.e., Subnet1) to the subnet of RSU3 (i.e., Subnet2), a multiple domain handoff is performed through the cooperation of RSU2, RSU3, MA1 and MA2.

Handoff of a Vehicle between Multiple Prefix Domains with PMIPv6

Vehicle     c-RSU               MA1              MA2             n-RSU
  |            |                 |                |                 |
  |            |==Bi-Dir Tunnel==|                |                 |
  |            |                 |                |                 |
  |            |                 |                |                 |
  |            |---DeReg PBU---->|                |                 |
  |            |                 |-------PBU----->|                 |
  |            |                 |                |                 |
  |            |<------PBA-------|                |-------PBA------>|
  |            |                 |                |                 |
  |            |                 |                |==Bi-Dir Tunnel==|
  |            |                 |                |                 |
  |            |                 |                |                 |
  |(----------------------RS with Mobility Info------------------->)|
  |            |                [VMI]             |                 |
  |            |                 |                |                 |
  |            |                 |                |                 |
  |<----------------------RA with prefix1 (c-RSU)-------------------|
  |            |                 |                |                 |
  |<----------------------RA with prefix2 (n-RSU)-------------------|
  |            |                 |                |                 |

Figure 5 shows the handoff of a vehicle between two prefix domains (i.e., two multi-link subnets) with PMIPv6. When the vehicle moves out of its c-RSU belonging to Subnet1, and moves into the n-RSU belonging to Subnet2, c-RSU detects the vehicle's leaving and reports it to MA1. MA1 figures out that the vehicle will get into the coverage of the n-RSU based on its trajectory and sends MA2 a PBU message to inform MA2 that the vehicle will enter the coverage of n-RSU belonging to MA2. MA2 sends a PBA message to n-RSU to inform that the vehicle will enter the coverage of n-RSU along with handoff context such as c-RSU's context information (e.g., c-RSU's link-local address and prefix called prefix1), and the vehicle's context information (e.g., the vehicle's global IP address and MAC address). After n-RSU receives the PBA message including the handoff context from MA2, it sets up a bi-directional tunnel with MA2, and generates RA messages with c-RSU's context information. That is, n-RSU pretends to be a router belonging to Subnet1. When the vehicle receives RA from n-RSU, it can maintain its connection with its corresponding node (i.e., CN1). Note that n-RSU also sends RA messages with its domain prefix called prefix2. The vehicle configures another global IP address with prefix2, and can use it for communication with neighboring vehicles under the coverage of n-RSU.
If c-RSU and n-RSU are adjacent, that is, vehicles are moving in specified routes with fixed RSU allocation, the procedure can be simplified by constructing the bidirectional tunnel directly between them (cancel the intervention of MAs) to alleviate the traffic flow in MA as well as reduce handoff delay.

Handoff of a Vehicle within Multiple Prefix Domains with DMM

        Vehicle               c-RSU              n-RSU
           |                     |                  |
           |---------------------|                  |
           |c-RSU detects leaving|                  |
           |---------------------|                  |
           |                     |--------PBU------>|
           |                     |                  |
           |                     |===Bi-Dir Tunnel==|
           |                     |                  |
           |                     |<-------PBA-------|
           |                     |                  |
           |                     |                  |
           |(--------RS with Mobility Info-------->)|
           |                 [VMI]                  |
           |                                        |
           |<--------RA with prefix1 (c-RSU)--------|
           |                                        |
           |<--------RA with prefix2 (n-RSU)--------|
           |                                        |

Figure 6 shows the vehicle handoff within two prefix domains (as two multi-link subnets) with DMM [RFC8885]. If c-RSU detects that the vehicle is going to leave its coverage and to enter the area of an adjacent RSU (n-RSU) belonging to a different prefix domain, it sends a PBU message to inform n-RSU that the vehicle will enter the coverage of n-RSU along with handoff context such as c-RSU's context information (e.g., c-RSU's link-local address and prefix called prefix1), and the vehicle's context information (e.g., the vehicle's global IP address and MAC address). After n-RSU receives the PBA message including the handoff context from c-RSU, it sets up a bi-directional tunnel with c-RSU, and generates RA messages with c-RSU's context information. That is, n-RSU pretends to be a router belonging to Subnet1. When the vehicle receives RA from n-RSU, it can maintain its connection with its corresponding node (i.e., CN1). Note that n-RSU also sends RA messages with its domain prefix called prefix2. The vehicle configures another global IP address with prefix2, and can use it for communication with neighboring vehicles under the coverage of n-RSU.

Security Considerations
This document shares all the security issues of Vehicular ND [ID-IPWAVE-VND], Proxy MIPv6 [RFC5213], and DMM [RFC7333][RFC7429][RFC8885].

Normative References
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
[RFC4861]

Neighbor Discovery for IP Version 6 (IPv6)
T. Narten
E. Nordmark
W. Simpson
H. Soliman
September 2007
RFC 4861
[RFC4862]

IPv6 Stateless Address Autoconfiguration
S. Thomson
T. Narten
T. Jinmei
September 2007
RFC 4862
[RFC5213]

Proxy Mobile IPv6
S. Gundavelli
K. Leung
V. Devarapalli
K. Chowdhury
August 2008
RFC 5213
[RFC3775]

Mobility Support in IPv6
D. Johnson
C. Perkins
J. Arkko
June 2004
RFC 3775
[RFC7333]

Requirements for Distributed Mobility Management
H. Chan
D. Liu
P. Seite
H. Yokota
J. Korhonen
August 2014
RFC 7333
[RFC7429]

Distributed Mobility Management: Current Practices and Gap Analysis
D. Liu
JC. Zuniga
P. Seite
H. Chan
CJ. Bernardos
January 2015
RFC 7429
[RFC8885]

Proxy Mobile IPv6 Extensions for Distributed Mobility Management
CJ. Bernardos
A. de la Oliva
F. Giust
JC. Zuniga
A. Mourad
October 2020
RFC 8885
[ID-IPWAVE-PS]

IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases
J. Jeong, Ed.
May 2022
Internet-Draft draft-ietf-ipwave-vehicular-networking-29

Informative References
[ID-IPWAVE-VND]

Vehicular Neighbor Discovery for IP-Based Vehicular Networks
J. Jeong, Ed.
Y. Shen
Z. Xiang
S. Cespedes
February 2022
Internet-Draft draft-jeong-ipwave-vehicular-neighbor-discovery-13
[VIP-WAVE]

VIP-WAVE: On the Feasibility of IP Communications in 802.11p Vehicular Networks
S Cespedes
N. Lu
X. Shen
March 2013
IEEE Transactions on Intelligent Transportation Systems, vol. 14, no. 1
[IEEE-802.11-OCB]

Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications
IEEE 802.11 Working Group
December 2016
IEEE Std 802.11-2016
[WAVE-1609.0]

IEEE Guide for Wireless Access in Vehicular Environments (WAVE) - Architecture
IEEE 1609 Working Group
March 2014
IEEE Std 1609.0-2013
[TS-23.285-3GPP]

Architecture Enhancements for V2X Services
3GPP
June 2018
3GPP TS 23.285

Acknowledgments
This work was supported in part by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea Ministry of Science and ICT (MSIT) (2020-0-00395-003, Standard Development of Blockchain based Network Management Automation Technology).
This work was supported in part by the MSIT under the ITRC (Information Technology Research Center) support program (IITP-2022-2017-0-01633) supervised by the IITP.

Contributors
This document is made by the group effort of IPWAVE working group. Many people actively contributed to this document, such as Carlos J. Bernardos and Russ Housley. The authors sincerely appreciate their contributions.
The following are co-authors of this document:
Zhong Xiang -
Department of Electrical and Computer Engineering,
Sungkyunkwan University,
2066 Seobu-ro Jangan-gu,
Suwon, Gyeonggi-do 16419,
Republic of Korea.
EMail: xz618@skku.edu

Changes from draft-jeong-ipwave-vehicular-mobility-management-07
The following changes are made from draft-jeong-ipwave-vehicular-mobility-management-07
- This version updates the author list.