Vehicular Mobility Management for IP-Based Vehicular Networks
Department of Software
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 299 4957+82 31 290 7996pauljeong@skku.eduhttp://iotlab.skku.edu/people-jaehoon-jeong.php
Department of Electrical and Computer Engineering
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 299 4106+82 31 290 7996chrisshen@skku.edu
Department of Electrical and Computer Engineering
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 10 9895 1211+82 31 290 7996xz618@skku.edu
Internet
IPWAVE Working GroupInternet-Draft
This document specifies a vehicular mobility management scheme for IP-based vehicular networks.
The vehicular mobility management scheme takes advantage of a vehicular link model
based on a multi-link subnet. With a vehicle's mobility information (e.g., position, speed,
and direction) and navigation path (i.e., trajectory), it can provide a moving vehicle with
proactive and seamless handoff along with its trajectory.
This document proposes a mobility management scheme for IP-based vehicular networks, which is
called vehicular mobility management (VMM). This vehicular mobility management is tailored
for a vehicular network architecture and a vehicular link model described in IPWAVE problem
statement document .
To support the interaction between vehicles or between vehicles and Rode-Side Units (RSUs),
Vehicular Neighbor Discovery (VND) is proposed as an enhanced IPv6 Neighbor Discovery (ND)
for IP-based vehicular networks .
For an efficient IPv6 Stateless Address Autoconfiguration (SLAAC) ,
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 that consists of multiple wireless subnets with the same IP prefix,
which corresponds to wireless coverage of multiple Road-Side Units (RSUs). Also, VND
supports IP packet routing via a connected Vehicular Ad Hoc Network (VANET) by letting
vehicles 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 vehicular mobility management 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 into a Traffic Control Center (TCC) in the vehicular cloud.
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 .
This document uses the terminology described in and .
In addition, the following new terms are defined as below:
DMM: Acronym for "Distributed Mobility Management" .
Mobility Anchor (MA): A node that maintains 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 has a network interface (e.g., IEEE 802.11-OCB and
Cellular V2X (C-V2X) )
for wireless communications with other OBUs and RSUs, and may be connected to
in-vehicle 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" .
Road-Side Unit (RSU): A node that has physical communication devices
(e.g., IEEE 802.11-OCB and C-V2X) for wireless communications
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 car parking areas.
Traffic Control Center (TCC): A node that maintains 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"
.
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.
A vehicular network architecture for V2I and V2V is illustrated in
. In this figure, there is a vehicular
cloud having a Traffic Control Center (TCC). The TCC has Mobility Anchors (MAs)
for the mobility management of vehicles under its control. 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 .
A vehicular network is a wireless network consisting of RSUs and vehicles. RSUs
are interconnected with each other through a wired network, and vehicles can
construct Vehicular Ad Hoc Networks (VANET).
In , three RSUs are deployed
either at intersections or along roadways. They are connected to an MA through
wired networks.
In the vehicular network, there are two subnets such as Subnet1 and Subnet2.
Subnet1 is a multi-link subnet consisting of multiple wireless coverage areas of
multiple RSUs, and those areas share the same IPv6 prefix to construct a single
logical subnet .
That is, the wireless links of RSU1 and RSU2 belong to Subnet1.
Thus, since Vehicle2 and Vehicle2 use the same prefix for Subnet1 and they are
within the wireless communication range, they can communicate directly with
each other. Note that in a multi-link subnet, a vehicle (e.g., Vehicle1 and
Vehicle2 in ) can configure
its global IPv6 address through an address registration procedure including
a multihop Duplicate Address Detection (DAD), which is specified in Vehicular
Neighbor Discovery (VND) .
On the other hand, Subnet2 uses a prefix different from Subnet1's. Vehicle4
residing in Subnet2 cannot talk to Vehicle3 directly because they belong to
different subnets.
Vehicles can construct a connected VANET, so they can communicate with each other
without the relaying of an RSU, but 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 , even though Vehicle2 are
disconnected from Vehicle3, they can communicate indirectly with each other
through RSUs such as RSU1 and RSU2.
In , it is assumed that
Vehicle2 communicates with the corresponding node denoted as CN1 where 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
shares the same prefix, the packets sent by CN1 should be routed toward 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 packets of CN1 should
be delivered to Vehicle2. With a handoff procedure, a sender's packets can be
delivered to a destination vehicle which the destination vehicle is moving
in the wireless coverage areas. Thus, this document specifies a mobility
management scheme in the vehicular network architecture, as shown in
.
This section explains the detailed procedure of mobility management
of a vehicle in a vehicular network as shown in
.
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, resulting in the reconfiguration of transport-layer
session information (i.e., an end-point's IP address) to avoid service
disruption. Considering this issue, this document proposes a handoff mechanism
for seamless communication.
In , the authors constructed a network-based mobility
management scheme using Proxy Mobile IPv6 (PMIPv6) ,
which is highly suitable to vehicular networks. This document uses a mobility
management procedure similar to PMIPv6 along with prefix discovery.
shows the binding update flow when
a vehicle entered the subnet of an RSU. RSUs act as Mobility Anchor Gateway
(MAG) defined in . When it receives an RS message
from a vehicle containing its mobility information (e.g., position, speed, and
direction), an RSU sends its MA a Proxy Binding Update (PBU) message
, which contains a Mobility
Option for 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
)
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, which 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 .
In PMIPv6, a unique prefix is allocated to each vehicle by an MA (i.e., LMA),
but in this document, a unique IP address is allocated to each vehicle by
an MA through the multihop-DAD-based address registration. This unique IP
address allocation can reduce the waste of IP prefixes by the legacy PMIPv6
because vehicles in a multi-link is allocated with a unique IP address based on
the same prefix.
When the vehicle changes its location and its current RSU (denoted as c-RSU)
detects that the vehicles moves out of its coverage, c-RSU needs to report
the movement of the vehicle into the coverage of another RSU to the MA.
With this report, the MA can change the end-point of the tunnel for the vehicle
into the new RSU's IP address.
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 new RSU,
it changes the tunnel's end-point from the current RSU (c-RSU) to the new
RSU (n-RSU). If there is 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.
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 bidirectional tunnel directly between them (cancel the intervention
of MA) to alleviate the traffic flow in MA as well as reduce handoff delay.
shows the handoff of a vehicle
within one prefix domain (as a multi-link subnet) with DMM .
RSUs are in charge of detecting when a node joins or moves through
its domain. If 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 handoff of vehicle. 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 for its current prefix.
If the vehicle sends an RS message to n-RSU, n-RSU responds to the RA message by
sending an RA to the vehicle.
When the vehicle moves from a prefix domain to another prefix domain,
a handoff between multiple prefix domains is required.
As shown in ,
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.
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 current RSU (denoted as c-RSU) belonging to
Subnet1, and moves into the next RSU (n-RSU) belonging to Subnet2,
c-RSU detects that the vehicles moves out of its coverage. c-RSU reports
the movement of the vehicle into the coverage of another RSU (n-RSU) to MA1.
MA1 sends MA2 a PBU message to inform MA2 that the vehicle will enter
the coverage of n-RSU belonging to MA2. MA2 send n-RSU a PBA 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 MA2, it sets up
a bi-directional tunnel with MA2, and generates RA messages with c-RSU's context information.
That is, n-RSU pretents to be a router belonging to Subnet1.
When the vehicle receives the 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 the 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 bidirectional tunnel directly between them (cancel the intervention
of MA) to alleviate the traffic flow in MA as well as reduce handoff delay.
shows the handoff of a vehicle
within two prefix domains (as two multi-link subnets) with DMM .
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 the 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 the communication with
neighboring vehicles under the coverage of n-RSU.
This document shares all the security issues of Vehicular ND
, Proxy MIPv6 , and
DMM .
Key words for use in RFCs to Indicate Requirement LevelsNeighbor Discovery for IP Version 6 (IPv6)IPv6 Stateless Address AutoconfigurationProxy Mobile IPv6Mobility Support in IPv6Requirements for Distributed Mobility ManagementDistributed Mobility Management: Current Practices and Gap AnalysisIP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use CasesIPv6 Neighbor Discovery for IP-Based Vehicular NetworksVIP-WAVE: On the Feasibility of IP Communications in 802.11p Vehicular NetworksPart 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) SpecificationsIEEE Guide for Wireless Access in Vehicular Environments (WAVE) - ArchitectureArchitecture Enhancements for V2X Services
3GPP
Proxy Mobile IPv6 extensions for Distributed Mobility Management
This work was supported by Basic Science Research Program through the
National Research Foundation of Korea (NRF) funded by the Ministry of
Education (2017R1D1A1B03035885).