draft-ietf-ipwave-vehicular-networking-00.txt   draft-ietf-ipwave-vehicular-networking-01.txt 
Network Working Group J. Jeong, Ed. Network Working Group J. Jeong, Ed.
Internet-Draft Sungkyunkwan University Internet-Draft Sungkyunkwan University
Intended status: Informational October 30, 2017 Intended status: Informational November 13, 2017
Expires: May 3, 2018 Expires: May 17, 2018
IP-based Vehicular Networking: Use Cases, Survey and Problem Statement IP-based Vehicular Networking: Use Cases, Survey and Problem Statement
draft-ietf-ipwave-vehicular-networking-00 draft-ietf-ipwave-vehicular-networking-01
Abstract Abstract
This document discusses use cases, survey, and problem statement on This document discusses use cases, survey, and problem statement on
IP-based vehicular networks, which are considered a key component of IP-based vehicular networks, which are considered a key component of
Intelligent Transportation Systems (ITS). The main topics of Intelligent Transportation Systems (ITS). The main topics of
vehicular networking are vehicle-to-vehicle (V2V), vehicle-to- vehicular networking are vehicle-to-vehicle (V2V), vehicle-to-
infrastructure (V2I), and infrastructure-to-vehicle (I2V) networking. infrastructure (V2I), and infrastructure-to-vehicle (I2V) networking.
First, this document surveys use cases using V2V and V2I networking. First, this document surveys use cases using V2V and V2I networking.
Second, this document deals with some critical aspects in vehicular Second, this document deals with some critical aspects in vehicular
skipping to change at page 1, line 31 skipping to change at page 1, line 31
activities, IP address autoconfiguration, routing, mobility activities, IP address autoconfiguration, routing, mobility
management, DNS naming service, service discovery, and security and management, DNS naming service, service discovery, and security and
privacy. For each aspect, this document discusses problem statement privacy. For each aspect, this document discusses problem statement
to analyze the gap between the state-of-the-art techniques and to analyze the gap between the state-of-the-art techniques and
requirements in IP-based vehicular networking. Finally, this requirements in IP-based vehicular networking. Finally, this
document articulates discussions including the summary and analysis document articulates discussions including the summary and analysis
of vehicular networking aspects and raises deployment issues. of vehicular networking aspects and raises deployment issues.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on May 17, 2018.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. V2V Use Cases . . . . . . . . . . . . . . . . . . . . . . 6 3.1. V2I Use Cases . . . . . . . . . . . . . . . . . . . . . . 5
3.2. V2I Use Cases . . . . . . . . . . . . . . . . . . . . . . 7 3.2. V2V Use Cases . . . . . . . . . . . . . . . . . . . . . . 6
4. Vehicular Network Architectures . . . . . . . . . . . . . . . 8 4. Vehicular Network Architectures . . . . . . . . . . . . . . . 7
4.1. Existing Architectures . . . . . . . . . . . . . . . . . . 8 4.1. Existing Architectures . . . . . . . . . . . . . . . . . 7
4.1.1. VIP-WAVE: On the Feasibility of IP Communications 4.1.1. VIP-WAVE: IP in 802.11p Vehicular Networks . . . . . 7
in 802.11p Vehicular Networks . . . . . . . . . . . . 8 4.1.2. IPv6 Operation for WAVE . . . . . . . . . . . . . . . 8
4.1.2. IPv6 Operation for WAVE - Wireless Access in 4.1.3. Multicast Framework for Vehicular Networks . . . . . 9
Vehicular Environments . . . . . . . . . . . . . . . . 9 4.1.4. Joint IP Networking and Radio Architecture . . . . . 9
4.1.3. A Framework for IP and non-IP Multicast Services 4.1.5. Mobile Internet Access in FleetNet . . . . . . . . . 10
for Vehicular Networks . . . . . . . . . . . . . . . . 10 4.1.6. A Layered Architecture for Vehicular DTNs . . . . . . 11
4.1.4. Joint IP Networking and Radio Architecture for 4.2. V2I and V2V Internetworking Problem Statement . . . . . . 12
Vehicular Networks . . . . . . . . . . . . . . . . . . 10 4.2.1. V2I-based Internetworking . . . . . . . . . . . . . . 13
4.1.5. Mobile Internet Access in FleetNet . . . . . . . . . . 11 4.2.2. V2V-based Internetworking . . . . . . . . . . . . . . 16
4.1.6. A Layered Architecture for Vehicular 5. Standardization Activities . . . . . . . . . . . . . . . . . 16
Delay-Tolerant Networks . . . . . . . . . . . . . . . 12 5.1. IEEE Guide for WAVE - Architecture . . . . . . . . . . . 16
4.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 13 5.2. IEEE Standard for WAVE - Networking Services . . . . . . 17
4.2.1. V2I-based Internetworking . . . . . . . . . . . . . . 14 5.3. ETSI Intelligent Transport Systems: GeoNetwork-IPv6 . . . 18
4.2.2. V2V-based Internetworking . . . . . . . . . . . . . . 17 5.4. ISO Intelligent Transport Systems: IPv6 over CALM . . . . 18
5. Standardization Activities . . . . . . . . . . . . . . . . . . 17 6. IP Address Autoconfiguration . . . . . . . . . . . . . . . . 19
5.1. IEEE Guide for Wireless Access in Vehicular 6.1. Existing Protocols for Address Autoconfiguration . . . . 19
Environments (WAVE) - Architecture . . . . . . . . . . . . 17 6.1.1. Automatic IP Address Configuration in VANETs . . . . 19
5.2. IEEE Standard for Wireless Access in Vehicular 6.1.2. Using Lane/Position Information . . . . . . . . . . . 20
Environments (WAVE) - Networking Services . . . . . . . . 18 6.1.3. GeoSAC: Scalable Address Autoconfiguration . . . . . 20
5.3. ETSI Intelligent Transport Systems: Transmission of 6.1.4. Cross-layer Identities Management in ITS Stations . . 21
IPv6 Packets over GeoNetworking Protocols . . . . . . . . 19 6.2. Problem Statement for IP Address Autoconfiguration . . . 22
5.4. ISO Intelligent Transport Systems: Communications 6.2.1. Neighbor Discovery . . . . . . . . . . . . . . . . . 22
Access for Land Mobiles (CALM) Using IPv6 Networking . . . 19 6.2.2. IP Address Autoconfiguration . . . . . . . . . . . . 22
6. IP Address Autoconfiguration . . . . . . . . . . . . . . . . . 20 7. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1. Existing Protocols . . . . . . . . . . . . . . . . . . . . 20 7.1. Existing Routing Protocols . . . . . . . . . . . . . . . 24
6.1.1. Automatic IP Address Configuration in VANETs . . . . . 20 7.1.1. Experimental Evaluation for IPv6 over GeoNet . . . . 24
6.1.2. Routing and Address Assignment using Lane/Position 7.1.2. Location-Aided Gateway Advertisement and Discovery . 24
Information in a Vehicular Ad-hoc Network . . . . . . 21 7.2. Routing Problem Statement . . . . . . . . . . . . . . . . 25
6.1.3. GeoSAC: Scalable Address Autoconfiguration for 8. Mobility Management . . . . . . . . . . . . . . . . . . . . . 25
VANET Using Geographic Networking Concepts . . . . . . 21 8.1. Existing Protocols . . . . . . . . . . . . . . . . . . . 25
6.1.4. Cross-layer Identities Management in ITS Stations . . 22 8.1.1. Vehicular Ad Hoc Networks with Network Fragmentation 25
6.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 23 8.1.2. Hybrid Centralized-Distributed Mobility Management . 26
6.2.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . 23 8.1.3. Hybrid Architecture for Network Mobility Management . 27
6.2.2. IP Address Autoconfiguration . . . . . . . . . . . . . 23 8.1.4. NEMO-Enabled Localized Mobility Support . . . . . . . 28
7. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1.5. Network Mobility for Vehicular Ad Hoc Networks . . . 29
7.1. Existing Protocols . . . . . . . . . . . . . . . . . . . . 25 8.1.6. Performance Analysis of P-NEMO for ITS . . . . . . . 29
7.1.1. Experimental Evaluation for IPv6 over VANET 8.1.7. Integration of VANets and Fixed IP Networks . . . . . 30
Geographic Routing . . . . . . . . . . . . . . . . . . 25 8.1.8. SDN-based Mobility Management for 5G Networks . . . . 30
7.1.2. Location-Aided Gateway Advertisement and Discovery 8.1.9. IP Mobility for VANETs: Challenges and Solutions . . 31
Protocol for VANets . . . . . . . . . . . . . . . . . 25 8.2. Problem Statement for Mobility-Management . . . . . . . . 32
7.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 26 9. DNS Naming Service . . . . . . . . . . . . . . . . . . . . . 33
8. Mobility Management . . . . . . . . . . . . . . . . . . . . . 26 9.1. Existing Protocols . . . . . . . . . . . . . . . . . . . 33
8.1. Existing Protocols . . . . . . . . . . . . . . . . . . . . 26 9.1.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 33
8.1.1. An IP Passing Protocol for Vehicular Ad Hoc 9.1.2. DNS Name Autoconfiguration for IoT Devices . . . . . 33
Networks with Network Fragmentation . . . . . . . . . 26 9.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 34
8.1.2. A Hybrid Centralized-Distributed Mobility 10. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 35
Management for Supporting Highly Mobile Users . . . . 27 10.1. Existing Protocols . . . . . . . . . . . . . . . . . . . 35
8.1.3. A Hybrid Centralized-Distributed Mobility 10.1.1. mDNS-based Service Discovery . . . . . . . . . . . . 35
Management Architecture for Network Mobility . . . . . 28 10.1.2. ND-based Service Discovery . . . . . . . . . . . . . 35
8.1.4. NEMO-Enabled Localized Mobility Support for 10.2. Problem Statement . . . . . . . . . . . . . . . . . . . 35
Internet Access in Automotive Scenarios . . . . . . . 29 11. Security and Privacy . . . . . . . . . . . . . . . . . . . . 36
8.1.5. Network Mobility Protocol for Vehicular Ad Hoc 11.1. Existing Protocols . . . . . . . . . . . . . . . . . . . 36
Networks . . . . . . . . . . . . . . . . . . . . . . . 30 11.1.1. Securing Vehicular IPv6 Communications . . . . . . . 36
8.1.6. Performance Analysis of PMIPv6-Based Network 11.1.2. Authentication and Access Control . . . . . . . . . 37
MObility for Intelligent Transportation Systems . . . 30 11.2. Problem Statement . . . . . . . . . . . . . . . . . . . 37
8.1.7. A Novel Mobility Management Scheme for Integration 12. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 38
of Vehicular Ad Hoc Networks and Fixed IP Networks . . 31 12.1. Summary and Analysis . . . . . . . . . . . . . . . . . . 38
8.1.8. SDN-based Distributed Mobility Management for 5G 12.2. Deployment Issues . . . . . . . . . . . . . . . . . . . 39
Networks . . . . . . . . . . . . . . . . . . . . . . . 31 13. Security Considerations . . . . . . . . . . . . . . . . . . . 39
8.1.9. IP Mobility Management for Vehicular Communication 14. Informative References . . . . . . . . . . . . . . . . . . . 40
Networks: Challenges and Solutions . . . . . . . . . . 32 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 47
8.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 34 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 47
9. DNS Naming Service . . . . . . . . . . . . . . . . . . . . . . 34 Appendix C. Changes from draft-ietf-ipwave-vehicular-
9.1. Existing Protocols . . . . . . . . . . . . . . . . . . . . 34 networking-00 . . . . . . . . . . . . . . . . . . . 49
9.1.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 34 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49
9.1.2. DNS Name Autoconfiguration for Internet-of-Things
Devices . . . . . . . . . . . . . . . . . . . . . . . 34
9.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 35
10. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 36
10.1. Existing Protocols . . . . . . . . . . . . . . . . . . . . 36
10.1.1. mDNS-based Service Discovery . . . . . . . . . . . . . 36
10.1.2. ND-based Service Discovery . . . . . . . . . . . . . . 36
10.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 36
11. Security and Privacy . . . . . . . . . . . . . . . . . . . . . 37
11.1. Existing Protocols . . . . . . . . . . . . . . . . . . . . 37
11.1.1. Securing Vehicular IPv6 Communications . . . . . . . . 37
11.1.2. Providing Authentication and Access Control in
Vehicular Network Environment . . . . . . . . . . . . 38
11.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 39
12. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 39
12.1. Summary and Analysis . . . . . . . . . . . . . . . . . . . 39
12.2. Deployment Issues . . . . . . . . . . . . . . . . . . . . 40
13. Security Considerations . . . . . . . . . . . . . . . . . . . 41
14. Informative References . . . . . . . . . . . . . . . . . . . . 41
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 48
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
Nowadays vehicular networks have been focused on the driving safety, Vehicular networks have been focused on the driving safety, driving
driving efficiency, and entertainment in road networks. Federal efficiency, and entertainment in road networks. The Federal
Communications Commission (FCC) in the US allocated wireless channels Communications Commission (FCC) in the US allocated wireless channels
for Dedicated Short-Range Communications (DSRC) service in the for Dedicated Short-Range Communications (DSRC) service in the
Intelligent Transportation Systems (ITS) Radio Service in the 5.850- Intelligent Transportation Systems (ITS) Radio Service in the
5.925 GHz band (5.9 GHz band). DSRC-based wireless communications 5.850-5.925 GHz band (5.9 GHz band). DSRC-based wireless
can support vehicle-to-vehicle (V2V), vehicle-to-infrastructure communications can support vehicle-to-vehicle (V2V), vehicle-to-
(V2I), and infrastructure-to-vehicle (I2V) networking. infrastructure (V2I), and infrastructure-to-vehicle (I2V) networking.
For the driving safety service based on the DSRC, IEEE has For driving safety services based on the DSRC, IEEE has standardized
standardized Wireless Access in Vehicular Environments (WAVE) Wireless Access in Vehicular Environments (WAVE) standards, such as
standards, such as IEEE 802.11p [IEEE-802.11p], IEEE 1609.2 IEEE 802.11p [IEEE-802.11p], IEEE 1609.2 [WAVE-1609.2], IEEE 1609.3
[WAVE-1609.2], IEEE 1609.3 [WAVE-1609.3], and IEEE 1609.4 [WAVE-1609.3], and IEEE 1609.4 [WAVE-1609.4]. Note that IEEE 802.11p
[WAVE-1609.4]. Note that IEEE 802.11p has been finalized as IEEE has been published as IEEE 802.11 Outside the Context of a Basic
802.11 Outside the Context of a Basic Service Set (OCB) Service Set (OCB) [IEEE-802.11-OCB] in 2012. Along with these WAVE
[IEEE-802.11-OCB] in 2012. Along with these WAVE standards, IPv6 and standards, IPv6 and Mobile IP protocols (e.g., MIPv4 and MIPv6) can
Mobile IP protocols (e.g., MIPv4 and MIPv6) can be extended to be extended to vehicular networks [RFC2460][RFC6275].
vehicular networks [RFC2460][RFC6275].
This document discusses use cases, survey, and problem statement on This document discusses use cases, survey, and problem statements
IP-based vehicular networking for Intelligent Transportation Systems related to IP-based vehicular networking for Intelligent
(ITS). First, This document surveys the use cases using V2V and V2I Transportation Systems (ITS). This document first surveys the use
networking in the ITS. Second, this document deals with some cases for using V2V and V2I networking in the ITS. Second, this
critical aspects in vehicular networking, such as vehicular network document deals with some critical aspects in vehicular networking,
architectures, standardization activities, IP address such as vehicular network architectures, standardization activities,
autoconfiguration, routing, mobility management, DNS naming service, IP address autoconfiguration, routing, mobility management, DNS
service discovery, and security and privacy. For each aspect, this naming service, service discovery, and security and privacy. For
document shows problem statement to analyze the gap between the each aspect, this document shows problem statement to analyze the gap
state-of-the-art techniques and requirements in IP-based vehicular between the state-of-the-art techniques and requirements in IP-based
networking. Finally, this document addresses discussions including vehicular networking. Finally, this document addresses discussions
the summary and analysis of vehicular networking aspects, raising including the summary and analysis of vehicular networking aspects,
deployment issues in road environments. raising deployment issues in road environments.
Based on the use cases, survey, and problem statement of this Based on the use cases, survey, and problem statement of this
document, we can specify the requirements for vehicular networks for document, we can specify the requirements for vehicular networks for
the intended purposes, such as the driving safety, driving the intended purposes, such as the driving safety, driving
efficiency, and entertainment. As a consequence, this will make it efficiency, and entertainment. As a consequence, this will make it
possible to design a network architecture and protocols for vehicular possible to design a network architecture and protocols for vehicular
networking. networking.
2. Terminology 2. Terminology
This document defines the following new terms: This document uses the following definitions:
o Road-Side Unit (RSU): A node that has Dedicated Short-Range o Road-Side Unit (RSU): A node that has Dedicated Short-Range
Communications (DSRC) device for wireless communications with Communications (DSRC) device for wireless communications with
vehicles and is also connected to the Internet as a router or vehicles and is also connected to the Internet as a router or
switch for packet forwarding. An RSU is deployed either at an switch for packet forwarding. An RSU is deployed either at an
intersection or in a road segment. intersection or in a road segment.
o On-Board Unit (OBU): A node that has a DSRC device for wireless o On-Board Unit (OBU): A node that has a DSRC device for wireless
communications with other OBUs and RSUs. An OBU is mounted on a communications with other OBUs and RSUs. An OBU is mounted on a
vehicle. It is assumed that a radio navigation receiver (e.g., vehicle. It is assumed that a radio navigation receiver (e.g.,
Global Positioning System (GPS)) is included in a vehicle with an Global Positioning System (GPS)) is included in a vehicle with an
OBU for efficient navigation. OBU for efficient navigation.
o Vehicle Detection Loop (or Loop Detector): An inductive device
used for detecting vehicles passing or arriving at a certain
point, for instance approaching a traffic light or in motorway
traffic. The relatively crude nature of the loop's structure
means that only metal masses above a certain size are capable of
triggering the detection.
o Traffic Control Center (TCC): A node that maintains road o Traffic Control Center (TCC): A node that maintains road
infrastructure information (e.g., RSUs, traffic signals, and loop infrastructure information (e.g., RSUs, traffic signals, and loop
detectors), vehicular traffic statistics (e.g., average vehicle detectors), vehicular traffic statistics (e.g., average vehicle
speed and vehicle inter-arrival time per road segment), and speed and vehicle inter-arrival time per road segment), and
vehicle information (e.g., a vehicle's identifier, position, vehicle information (e.g., a vehicle's identifier, position,
direction, speed, and trajectory as a navigation path). TCC is direction, speed, and trajectory as a navigation path). TCC is
included in a vehicular cloud for vehicular networks. Exemplary included in a vehicular cloud for vehicular networks. Example
functions of TCC include the management of evacuation routes, the functions of TCC include the management of evacuation routes, the
monitoring of pedestrians and bike traffic, the monitoring of monitoring of real-time mass transit operations, and real-time
real-time transit operations, and real-time responsive traffic responsive traffic signal systems. Thus, TCC is the nerve center
signal systems. Thus, TCC is the nerve center of most freeway of most freeway management sytems such that data is collected,
management sytems such that data is collected, processed, and processed, and fused with other operational and control data, and
fused with other operational and control data, and is also is also synthesized to produce "information" distributed to
synthesized to produce "information" distributed to stakeholders, stakeholders, other agencies, and traveling public. TCC is called
other agencies, and traveling public. TCC is called Traffic Traffic Management Center (TMC) in the US. TCC can communicate
Management Center (TMC) in the US. TCC can communicate with road with road infrastructure nodes (e.g., RSUs, traffic signals, and
infrastructure nodes (e.g., RSUs, traffic signals, and loop loop detectors) to share measurement data and management
detectors) to share measurement data and management information by information by an application-layer protocol.
an application-layer protocol.
o WAVE: Acronym for "Wireless Access in Vehicular Environments"
3. Use Cases 3. Use Cases
This section shows use cases of V2V and V2I networking. This section provides use cases of V2V and V2I networking.
3.1. V2V Use Cases 3.1. V2I Use Cases
The use cases of V2I networking include navigation service, fuel- The use cases of V2I networking include navigation service, fuel-
efficient speed recommendation service, and accident notification efficient speed recommendation service, and accident notification
service. service.
A navigation service, such as Self-Adaptive Interactive Navigation A navigation service, such as the Self-Adaptive Interactive
Tool (called SAINT) [SAINT], using V2I networking interacts with TCC Navigation Tool (called SAINT) [SAINT], using V2I networking
for the global road traffic optimization and can guide individual interacts with TCC for the global road traffic optimization and can
vehicles for appropriate navigation paths in real time. The enhanced guide individual vehicles for appropriate navigation paths in real
SAINT (called SAINT+) [SAINTplus] can give the fast moving paths for time. The enhanced SAINT (called SAINT+) [SAINTplus] can give the
emergency vehicles (e.g., ambulance and fire engine) toward accident fast moving paths for emergency vehicles (e.g., ambulance and fire
spots while providing efficient detour paths to vehicles around the engine) toward accident spots while providing other vehicles with
accidents spots. efficient detour paths.
The emergency communication between accident vehicles (or emergency The emergency communication between accident vehicles (or emergency
vehicles) and TCC can be performed via either RSU or 4G-LTE networks. vehicles) and TCC can be performed via either RSU or 4G-LTE networks.
The First Responder Network Authority (FirstNet) [FirstNet] is The First Responder Network Authority (FirstNet) [FirstNet] is
provided by the US government to establish, operate, and maintain an provided by the US government to establish, operate, and maintain an
interoperable public safety broadband network for safety and security interoperable public safety broadband network for safety and security
network services, such as emergency calls. The construction of the network services, such as emergency calls. The construction of the
nationwide FirstNet network requires each state in the US to have a nationwide FirstNet network requires each state in the US to have a
Radio Access Network (RAN) that will connect to FirstNet's network Radio Access Network (RAN) that will connect to FirstNet's network
core. The current RAN is mainly constructed by 4G-LTE, but DSRC- core. The current RAN is mainly constructed by 4G-LTE, but DSRC-
based vehicular networks can be used in near future. based vehicular networks can be used in near future.
A pedestrian protection service, such as Safety-Aware Navigation A pedestrian protection service, such as Safety-Aware Navigation
Application (called SANA) [SANA], using V2I networking can reduce the Application (called SANA) [SANA], using V2I networking can reduce the
collision of a pedestrian and a vehicle, which have a smartphone, in collision of a pedestrian and a vehicle, which have a smartphone, in
a road network. Vehicles and pedestrians can communicate with each a road network. Vehicles and pedestrians can communicate with each
other via an RSU that delivers scheduling information for wireless other via an RSU that delivers scheduling information for wireless
communication to save the smartphones' battery. communication to save the smartphones' battery.
3.2. V2I Use Cases 3.2. V2V Use Cases
The use cases of V2V networking include context-aware navigator for The use cases of V2V networking include context-aware navigation for
driving safety, cooperative adaptive cruise control in an urban driving safety, cooperative adaptive cruise control in an urban
roadway, and platooning in a highway. These are three techniques roadway, and platooning in a highway. These three techniques will be
that will be important elements for self-driving. important elements for self-driving vehicles.
Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers
to drive safely by letting the drivers recognize dangerous obstacles to drive safely by letting the drivers recognize dangerous obstacles
and situations. That is, CASD navigator displays obstables or and situations. That is, CASD navigator displays obstables or
neighboring vehicles relevant to possible collisions in real-time neighboring vehicles relevant to possible collisions in real-time
through V2V networking. CASD provides vehicles with a class-based through V2V networking. CASD provides vehicles with a class-based
automatic safety action plan, which considers three situations, such automatic safety action plan, which considers three situations, such
as the Line-of-Sight unsafe, Non-Line-of-Sight unsafe and safe as the Line-of-Sight unsafe, Non-Line-of-Sight unsafe and safe
situations. This action plan can be performed among vehicles through situations. This action plan can be performed among vehicles through
V2V networking. V2V networking.
skipping to change at page 8, line 19 skipping to change at page 7, line 19
4. Vehicular Network Architectures 4. Vehicular Network Architectures
This section surveys vehicular network architectures based on IP This section surveys vehicular network architectures based on IP
along with various radio technologies, and then discusses problem along with various radio technologies, and then discusses problem
statement for a vehicular network architecture for IP-based vehicular statement for a vehicular network architecture for IP-based vehicular
networking. networking.
4.1. Existing Architectures 4.1. Existing Architectures
4.1.1. VIP-WAVE: On the Feasibility of IP Communications in 802.11p 4.1.1. VIP-WAVE: IP in 802.11p Vehicular Networks
Vehicular Networks
Cespedes et al. proposed a vehicular IP in WAVE called VIP-WAVE for Cespedes et al. proposed a vehicular IP in WAVE called VIP-WAVE for
I2V and V2I networking [VIP-WAVE]. IEEE 1609.3 specified a WAVE I2V and V2I networking [VIP-WAVE]. IEEE 1609.3 specified a WAVE
stack of protocols and includes IPv6 as a network layer protocol in stack of protocols and includes IPv6 as a network layer protocol in
data plane [WAVE-1609.3]. The standard WAVE does not support data plane [WAVE-1609.3]. The standard WAVE does not support
Duplicate Address Detection (DAD), seamless communications for Duplicate Address Detection (DAD) of IPv6 Stateless Address
Internet services, and multi-hop communications between a vehicle and Autoconfiguration (SLAAC) [RFC4862] due to its own efficient IP
an infrastructure node (e.g., RSU). To overcome these limitations of address configuration based on a WAVE Service Advertisement (WSA)
management frame [WAVE-1609.3], seamless communications for Internet
services, and multi-hop communications between a vehicle and an
infrastructure node (e.g., RSU). To overcome these limitations of
the standard WAVE for IP-based networking, VIP-WAVE enhances the the standard WAVE for IP-based networking, VIP-WAVE enhances the
standard WAVE by the following three schemes: (i) an efficient standard WAVE by the following three schemes: (i) an efficient
mechanism for the IPv6 address assignment and DAD, (ii) on-demand IP mechanism for the IPv6 address assignment and DAD, (ii) on-demand IP
mobility based on Proxy Mobile IPv6 (PMIPv6), and (iii) one-hop and mobility based on Proxy Mobile IPv6 (PMIPv6), and (iii) one-hop and
two-hop communications for I2V and V2I networking. two-hop communications for I2V and V2I networking.
In WAVE, IPv6 Neighbor Discovery (ND) protocol is not recommended due In WAVE, IPv6 Neighbor Discovery (ND) protocol is not recommended due
to the overhead of ND against the timely and prompt communications in to the overhead of ND against the timely and prompt communications in
vehicular networking. By WAVE service advertisement (WAS) management vehicular networking. By WAVE service advertisement (WAS) management
frame, an RSU can provide vehicles with IP configuration information frame, an RSU can provide vehicles with IP configuration information
skipping to change at page 9, line 22 skipping to change at page 8, line 24
vehicle as a packet relay by sending a relay service announcement. vehicle as a packet relay by sending a relay service announcement.
When it receives this relay service announcement and is within the When it receives this relay service announcement and is within the
communication range of an RSU, another vehicle registers itself into communication range of an RSU, another vehicle registers itself into
the RSU as a relay and notifies the relay-requester vehicle of a the RSU as a relay and notifies the relay-requester vehicle of a
relay maintenance announcement. relay maintenance announcement.
Thus, VIP-WAVE is a good candidate for I2V and V2I networking, Thus, VIP-WAVE is a good candidate for I2V and V2I networking,
supporting an enhanced ND, handover, and two-hop communications supporting an enhanced ND, handover, and two-hop communications
through a relay. through a relay.
4.1.2. IPv6 Operation for WAVE - Wireless Access in Vehicular 4.1.2. IPv6 Operation for WAVE
Environments
Baccelli et al. provided an analysis of the operation of IPv6 as it Baccelli et al. provided an analysis of the operation of IPv6 as it
has been described by the IEEE WAVE standards 1609 [IPv6-WAVE]. has been described by the IEEE WAVE standards 1609 [IPv6-WAVE].
Although the main focus of WAVE has been the timely delivery of Although the main focus of WAVE has been the timely delivery of
safety related information, the deployment of IP-based entertainment safety related information, the deployment of IP-based entertainment
applications is also considered. Thus, in order to support applications is also considered. Thus, in order to support
entertainment traffic, WAVE supports IPv6 and transport protocols entertainment traffic, WAVE supports IPv6 and transport protocols
such as TCP and UDP. such as TCP and UDP.
In the analysis provided in [IPv6-WAVE], it is identified that the In the analysis provided in [IPv6-WAVE], it is identified that the
IEEE 1609.3 standard's recommendations for IPv6 operation over WAVE IEEE 1609.3 standard's recommendations for IPv6 operation over WAVE
are rather minimal. Protocols on which the operation of IPv6 relies are rather minimal. Protocols on which the operation of IPv6 relies
for IP address configuration and IP-to-link-layer address translation for IP address configuration and IP-to-link-layer address translation
(e.g., IPv6 ND protocol) are not recommended in the standard. (e.g., IPv6 ND protocol) are not recommended in the standard.
Additionally, IPv6 works under certain assumptions for the link model Additionally, IPv6 implementations work under certain assumptions for
that do not necessarily hold in WAVE. For instance, IPv6 assumes the link model that do not necessarily hold in WAVE. For instance,
symmetry in the connectivity among neighboring interfaces. However, some IPv6 implementations assume symmetry in the connectivity among
interference and different levels of transmission power may cause neighboring interfaces. However, interference and different levels
unidirectional links to appear in a WAVE link model. Also, in an of transmission power may cause unidirectional links to appear in a
IPv6 link, it is assumed that all interfaces which are configured WAVE link model. Also, in an IPv6 link, it is assumed that all
with the same subnet prefix are on the same IP link. Hence, there is interfaces which are configured with the same subnet prefix are on
a relationship between link and prefix, besides the different scopes the same IP link. Hence, there is a relationship between link and
that are expected from the link-local and global types of IPv6 prefix, besides the different scopes that are expected from the link-
addresses. Such a relationship does not hold in a WAVE link model local and global types of IPv6 addresses. Such a relationship does
due to node mobility and highly dynamic topology. not hold in a WAVE link model due to node mobility and highly dynamic
topology.
Baccellii et al. concluded that the use of the standard IPv6 protocol Baccelli et al. concluded that the use of the standard IPv6 protocol
stack, as the IEEE 1609 family of specifications stipulate, is not stack, as the IEEE 1609 family of specifications stipulate, is not
sufficient. Instead, the addressing assignment should follow sufficient. Instead, the addressing assignment should follow
considerations for ad-hoc link models, defined in [RFC5889], which considerations for ad-hoc link models, defined in [RFC5889], which
are similar to the characteristics of the WAVE link model. In terms are similar to the characteristics of the WAVE link model. In terms
of the supporting protocols for IPv6, such as ND, DHCP, or stateless of the supporting protocols for IPv6, such as ND, DHCP, or stateless
auto-configuration, which rely largely on multicast, do not operate auto-configuration, which rely largely on multicast, do not operate
as expected in the case where the WAVE link model does not have the as expected in the case where the WAVE link model does not have the
same behavior expected for multicast IPv6 traffic due to nodes' same behavior expected for multicast IPv6 traffic due to nodes'
mobility and link variability. Additional challenges such as the mobility and link variability. Additional challenges such as the
support of pseudonimity through MAC address change along with the support of pseudonimity through MAC address change along with the
suitability of traditional TCP applications are discussed by the suitability of traditional TCP applications are discussed by the
authors since they require the design of appropriate solutions. authors since those challenges require the design of appropriate
solutions.
4.1.3. A Framework for IP and non-IP Multicast Services for Vehicular 4.1.3. Multicast Framework for Vehicular Networks
Networks
Jemaa et al. presented a framework that enables deploying multicast Jemaa et al. presented a framework that enables deploying multicast
services for vehicular networks in Infrastructure-based scenarios services for vehicular networks in Infrastructure-based scenarios
[VNET-Framework]. This framework deals with two phases: (i) [VNET-Framework]. This framework deals with two phases: (i)
Initialization or bootstrapping phase that includes a geographic Initialization or bootstrapping phase that includes a geographic
multicast auto-configuration process and a group membership building multicast auto-configuration process and a group membership building
method and (ii) Multicast traffic dissemination phase that includes a method and (ii) Multicast traffic dissemination phase that includes a
network selecting mechanism on the transmission side and a receiver- network selecting mechanism on the transmission side and a receiver-
based multicast delivery in the reception side. To this end, authors based multicast delivery in the reception side. To this end, the
define a distributed mechanism that allows the vehicles to configure authors define a distributed mechanism that allows the vehicles to
a common multicast address: Geographic Multicast Address Auto- configure a common multicast address: Geographic Multicast Address
configuration (GMAA), which allows a vehicle to configure its own Auto-configuration (GMAA), which allows a vehicle to configure its
address without signaling. A vehicle may also be able to change the own address without signaling. A vehicle may also be able to change
multicast address to which it is subscribed when it changes its the multicast address to which it is subscribed when it changes its
location. location.
This framework suggests a network selecting approach that allows IP This framework suggests a network selecting approach that allows IP
and non-IP multicast data delivery in the sender side. Then, to meet and non-IP multicast data delivery on the sender side. Then, to meet
the challenges of multicast address auto-configuration, the authors the challenges of multicast address auto-configuration, the authors
propose a distributed geographic multicast auto-addressing mechanism propose a distributed geographic multicast auto-addressing mechanism
for multicast groups of vehicles, and a simple multicast data for multicast groups of vehicles, and a simple multicast data
delivery scheme in hybrid networks from a server to the group of delivery scheme in hybrid networks from a server to the group of
moving vehicles. However, this study lacks simulations related to moving vehicles. However, the GMAA study lacks simulations related
performance assessment. to performance assessment.
4.1.4. Joint IP Networking and Radio Architecture for Vehicular 4.1.4. Joint IP Networking and Radio Architecture
Networks
Petrescu et al. defined the joined IP networking and radio Petrescu et al. defined the joint IP networking and radio
architecture for V2V and V2I communication in [Joint-IP-Networking]. architecture for V2V and V2I communication in [Joint-IP-Networking].
The paper proposes to consider an IP topology in a similar way as a The paper proposes to consider an IP topology in a similar way as a
radio link topology, in the sense that an IP subnet would correspond radio link topology, in the sense that an IP subnet would correspond
to the range of 1-hop vehicular communication. The paper defines to the range of 1-hop vehicular communication. The paper defines
three types of vehicles: Leaf Vehicle (LV), Range Extending Vehicle three types of vehicles: Leaf Vehicle (LV), Range Extending Vehicle
(REV), and Internet Vehicle (IV). The first class corresponds to the (REV), and Internet Vehicle (IV). The first class corresponds to the
largest set of communicating vehicles (or network nodes within a largest set of communicating vehicles (or network nodes within a
vehicle), while the role of the second class is to build an IP relay vehicle), while the role of the second class is to build an IP relay
between two IP-subnet and two sub-IP networks. Finally, the last between two IP-subnet and two sub-IP networks. Finally, the last
class corresponds to vehicles being connected to Internet. Based on class corresponds to vehicles being connected to Internet. Based on
these three classes, the paper defines six types of IP topologies these three classes, the paper defines six types of IP topologies
corresponding to V2V communication between two LVs in direct range, corresponding to V2V communication between two LVs in direct range,
or two LVs over a range extending vehicle, or V2I communication again or two LVs over a range extending vehicle, or V2I communication again
either directly via an IV, via another vehicles being IV, or via an either directly via an IV, via another vehicles being IV, or via an
REV connecting to an IV. REV connecting to an IV.
Considering a toy example of a vehicular train, where LV would be in- Consider a simplified example of a vehicular train, where LV would be
wagon communicating nodes, REV would be inter-wagon relays, and IV in-wagon communicating nodes, REV would be inter-wagon relays, and IV
would be one node (e.g., train head) connected to Internet. Petrescu would be one node (e.g., train head) connected to Internet. Petrescu
et al. defined the required mechanisms to build subnetworks, and et al. defined the required mechanisms to build subnetworks, and
evaluated the protocol time that is required to build such networks. evaluated the protocol time that is required to build such networks.
Although no simulation-based evaluation is conducted, the initial Although no simulation-based evaluation is conducted, the initial
analysis shows a long initial connection overhead, which should be analysis shows a long initial connection overhead, which should be
alleviated once the multi-wagon remains stable. However, this alleviated once the multi-wagon remains stable. However, this
approach does not describe what would happen in the case of a dynamic approach does not describe what would happen in the case of a dynamic
multi-hop vehicular network, where such overhead would end up being multi-hop vehicular network, where such overhead would end up being
too high for V2V/V2I IP-based vehicular applications. too high for V2V/V2I IP-based vehicular applications.
One other aspect described in this paper is to join the IP-layer One other aspect described in their paper is to join the IP-layer
relaying with radio-link channels. This paper suggests to separate relaying with radio-link channels. Their paper proposes separating
different subnetworks in different WiFi/ITS-G5 channels, which could different subnetworks in different WiFi/ITS-G5 channels, which could
be advertised by the REV. Accordingly, the overall interference be advertised by the REV. Accordingly, the overall interference
could be controlled within each subnetwork. This statement is could be controlled within each subnetwork. This approach is similar
similar to multi-channel topology management proposals in multi-hop to multi-channel topology management proposals in multi-hop sensor
sensor networks, yet adapted to an IP topology. networks, yet adapted to an IP topology.
In conclusion, this paper proposes to classify an IP multi-hop Their paper concludes that the generally complex multi-hop IP
vehicular network in three classes of vehicles: Leaf Vehicle (LV), vehicular topology could be represented by only six different
Range Extending Vehicle (REV), and Internet Vehicle (IV). It topologies, which could be further analyzed and optimized. A prefix
suggests that the generally complex multi-hop IP vehicular topology dissemination protocol is proposed for one of the topologies.
could be represented by only six different topologies, which could be
further analyzed and optimized. A prefix dissemination protocol is
proposed for one of the topologies.
4.1.5. Mobile Internet Access in FleetNet 4.1.5. Mobile Internet Access in FleetNet
Bechler et al. described the FleetNet project approach to integrate Bechler et al. described the FleetNet project approach to integrate
Internet Access in future vehicular networks [FleetNet]. The paper Internet Access in future vehicular networks [FleetNet]. The
is most probably one of the first paper to address this aspect, and FleetNet paper is probably one of the first papers to address this
in many ways, introduces concepts that will be later used in MIPv6 or aspect, and in many ways, introduces concepts that will be later used
other subsequent IP mobility management schemes. The paper describes in MIPv6 or other subsequent IP mobility management schemes. The
a V2I architecture consisting of Vehicles, Internet Gateways (IGW), paper describes a V2I architecture consisting of Vehicles, Internet
Proxy, and Corresponding Nodes (CN). Considering that vehicular Gateways (IGW), Proxy, and Corresponding Nodes (CN). Considering
networks are required to use IPv6 addresses and also the new wireless that vehicular networks are required to use IPv6 addresses and also
access technology ITS-G5 (new at that time), one of the challenges is the new wireless access technology ITS-G5 (new at that time), one of
to bridge the two different networks (i.e., VANET and IP4/IPv6 the challenges is to bridge the two different networks (i.e., VANET
Internet). Accordingly, the paper introduces a Fleetnet Gateway and IPv4/IPv6 Internet). Accordingly, the paper introduces a
(FGW), which allows vehicles in IPv6 to access the IPv4 Internet and Fleetnet Gateway (FGW), which allows vehicles in IPv6 to access the
to bridge two types of networks and radio access technologies. IPv4 Internet and to bridge two types of networks and radio access
Another challenge is to keep the active addressing and flows while technologies. Another challenge is to keep the active addressing and
vehicles move between FGWs. Accordingly, the paper introduces a flows while vehicles move between FGWs. Accordingly, the paper
proxy node, a cranked-up MIP Home Agent, which can re-route flows to introduces a proxy node, a hybrid MIP Home Agent, which can re-route
the new FGW as well as acting as a local IPv4-IPv6 NAT. flows to the new FGW as well as acting as a local IPv4-IPv6 NAT.
The authors from the paper mostly observed two issues that VANET The authors from the paper mostly observed two issues that VANET
brings into the traditional IP mobility. First, VANET vehicles must brings into the traditional IP mobility. First, VANET vehicles must
mostly be addressed from the Internet directly, and do not mostly be addressed from the Internet directly, and do not
specifically have a Home Network. Accordingly, VANET vehicles specifically have a Home Network. Accordingly, VANET vehicles
require a globally (predefined) unique IPv6 address, while an IPv6 require a globally (predefined) unique IPv6 address, while an IPv6
co-located care-of address (CCoA) is a newly allocated IPv6 address co-located care-of address (CCoA) is a newly allocated IPv6 address
every time a vehicle would enter a new IGW radio range. Second, every time a vehicle would enter a new IGW radio range. Second,
VANET links are known to be unreliable and short, and the extensive VANET links are known to be unreliable and short, and the extensive
use of IP tunneling on-the-air was judged not efficient. use of IP tunneling on-the-air was judged not efficient.
skipping to change at page 12, line 41 skipping to change at page 11, line 39
This is a pioneer paper, which contributed to changing MIP and led to This is a pioneer paper, which contributed to changing MIP and led to
the new IPv6 architecture currently known as Proxy-MIP and the the new IPv6 architecture currently known as Proxy-MIP and the
subsequent DMM-PMIP. Three key messages can be yet kept in mind. subsequent DMM-PMIP. Three key messages can be yet kept in mind.
First, unlike the Internet, vehicles can be more prominently directly First, unlike the Internet, vehicles can be more prominently directly
addressed than the Internet traffic, and do not have a Home Network addressed than the Internet traffic, and do not have a Home Network
in the traditional MIP sense. Second, IP tunneling should be avoided in the traditional MIP sense. Second, IP tunneling should be avoided
as much as possible over the air. Third, the protocol-based mobility as much as possible over the air. Third, the protocol-based mobility
(induced by the physical mobility) must be kept hidden to both the (induced by the physical mobility) must be kept hidden to both the
vehicle and the correspondent node (CN). vehicle and the correspondent node (CN).
4.1.6. A Layered Architecture for Vehicular Delay-Tolerant Networks 4.1.6. A Layered Architecture for Vehicular DTNs
Soares et al. addressed the case of delay tolerant vehicular network Soares et al. addressed the case of delay tolerant vehicular network
[Vehicular-DTN]. For delay tolerant or disruption tolerant networks, [Vehicular-DTN]. For delay tolerant or disruption tolerant networks,
rather than building a complex VANET-IP multi-hop route, vehicles may rather than building a complex VANET-IP multi-hop route, vehicles may
also be used to carry packets closer to the destination or directly also be used to carry packets closer to the destination or directly
to the destination. The authors built the well-accepted DTN Bundle to the destination. The authors built the well-accepted DTN Bundle
architecture and protocol to propose a VANET extension. They architecture and protocol to propose a VANET extension. They
introduced three types of VANET nodes: (i) terminal nodes (requiring introduced three types of VANET nodes: (i) terminal nodes (requiring
data), (ii) mobile nodes (carrying data along their routes), and data), (ii) mobile nodes (carrying data along their routes), and
(iii) relay nodes (storing data at cross-roads of mobile nodes as (iii) relay nodes (storing data at cross-roads of mobile nodes as
skipping to change at page 13, line 20 skipping to change at page 12, line 19
communication for small Control plane packets and use DTN in-band for communication for small Control plane packets and use DTN in-band for
the Data plane. The paper then further describes the different the Data plane. The paper then further describes the different
layers from the Control and the Data planes. One interesting aspect layers from the Control and the Data planes. One interesting aspect
is the positioning of the Bundle layer between L2 and L3, rather than is the positioning of the Bundle layer between L2 and L3, rather than
above TCP/IP as for the DTN Bundle architecture. The authors claimed above TCP/IP as for the DTN Bundle architecture. The authors claimed
this to be required first to keep bundle aggregation/disaggregation this to be required first to keep bundle aggregation/disaggregation
transparent to IP, as well as to allow bundle transmission over transparent to IP, as well as to allow bundle transmission over
multiple access technologies (described as MAC/PHY layers in the multiple access technologies (described as MAC/PHY layers in the
paper). paper).
Although the DTN architectures evolved since the paper has been Although DTN architectures have evolved since the paper was written,
written, this paper addresses IP mobility management from a different the Vehicular-DTN paper takes a different approach to IP mobility
approach. An important aspect is to separate the Control plane from management. An important aspect is to separate the Control plane
the Data plane to allow a large flexibility in a Control plane to from the Data plane to allow a large flexibility in a Control plane
coordinate a heterogeneous radio access technology (RAT) Data plane. to coordinate a heterogeneous radio access technology (RAT) Data
plane.
4.2. Problem Statement 4.2. V2I and V2V Internetworking Problem Statement
This section provides a problem statement of a vehicular network This section provides a problem statement of a vehicular network
architecture of IPv6-based V2I and V2V networking. The main focus in architecture of IPv6-based V2I and V2V networking. The main focus in
this document is one-hop networking between a vehicle and an RSU or this document is one-hop networking between a vehicle and an RSU or
between two neighboring vehicles. However, this document does not between two neighboring vehicles. However, this document does not
address all multi-hop networking scenarios of vehicles and RSUs. address all multi-hop networking scenarios of vehicles and RSUs.
Also, the problems focus on the network layer (i.e., IPv6 protocol Also, the focus is on the network layer (i.e., IPv6 protocol stack)
stack) rather than the MAC layer and the transport layer (e.g., TCP, rather than the MAC layer and the transport layer (e.g., TCP, UDP,
UDP, and SCTP). and SCTP).
Figure 1 shows a vehicular network architecture for V2I and V2V Figure 1 shows an architecture for V2I and V2V networking in a road
networking in a road network. The two RSUs (RSU1 and RSU2) are network. The two RSUs (RSU1 and RSU2) are deployed in the road
deployed in the road network and are connected to a Vehicular Cloud network and are connected to a Vehicular Cloud through the Internet.
through the Internet. TCC is connected to the Vehicular Cloud and TCC is connected to the Vehicular Cloud and the two vehicles
the two vehicles (Vehicle1 and Vehicle2) are wirelessly connected to (Vehicle1 and Vehicle2) are wirelessly connected to RSU1, and the
RSU1, and the last vehicle (Vehicle3) is wirelessly connected to last vehicle (Vehicle3) is wirelessly connected to RSU2. Vehicle1
RSU2. Vehicle1 can communicate with Vehicle2 via V2V communication, can communicate with Vehicle2 via V2V communication, and Vehicle2 can
and Vehicle2 can communicate with Vehicle3 via V2V communication. communicate with Vehicle3 via V2V communication. Vehicle1 can
Vehicle1 can communicate with Vehicle3 via RSU1 and RSU2 via V2I communicate with Vehicle3 via RSU1 and RSU2 via V2I communication.
communication.
*-------------* *-------------*
* * .-------. * * .-------.
* Vehicular Cloud *<------>| TCC | * Vehicular Cloud *<------>| TCC |
* * ._______. * * ._______.
*-------------* *-------------*
^ ^ ^ ^
| | | |
| | | |
v v v v
skipping to change at page 14, line 31 skipping to change at page 13, line 31
.--------. .--------. .--------. .--------. .--------. .--------.
|Vehicle1|=> |Vehicle2|=> |Vehicle3|=> |Vehicle1|=> |Vehicle2|=> |Vehicle3|=>
| |<....>| |<....>| | | |<....>| |<....>| |
.________. .________. .________. .________. .________. .________.
<----> Wired Link <....> Wireless Link => Moving Direction <----> Wired Link <....> Wireless Link => Moving Direction
Figure 1: A Vehicular Network Architecture for V2I and V2V Networking Figure 1: A Vehicular Network Architecture for V2I and V2V Networking
In vehicular networks, unidirectional links exist and must be In vehicular networks, unidirectional links exist and must be
considered. Control Plane must be separated from Data Plane. ID/ considered. The control plane must be separated from data plane.
Pseudonym change requires a lightweight DAD. IP tunneling should be ID/Pseudonym change requires a lightweight DAD. IP tunneling should
avoided. Vehicles do not have a Home Network. Protocol-based be avoided. The mobility information of a mobile device (e.g.,
mobility must be kept hidden to both the vehicle and the vehicle), such as trajectory, position, speed, and direction, can be
correspondent node (CN). A vehicular network architecture may be used by the mobile device and infrastructure nodes (e.g., TCC and
composed of three types of vehicles: Leaf Vehicle, Range Extending RSU) for the accommodation of proactive protocols because it is
Vehicle, and Internet Vehicle[Joint-IP-Networking]. usually equipped with a GPS receiver. Vehicles can use the TCC as
its Home Network, so the TCC maintains the mobility information of
vehicles for location management. A vehicular network architecture
may be composed of three types of vehicles in Figure 1: Leaf Vehicle,
Range Extending Vehicle, and Internet Vehicle[Joint-IP-Networking].
This section also discusses the internetworking between a vehicle's This section also discusses the internetworking between a vehicle's
moving network and an RSU's fixed network. moving network and an RSU's fixed network.
4.2.1. V2I-based Internetworking 4.2.1. V2I-based Internetworking
As shown in Figure 2, the vehicle's moving network and the RSU's As shown in Figure 2, the vehicle's moving network and the RSU's
fixed network are internal networks having multiple subnets and fixed network are self-contained networks having multiple subnets and
having an edge router for the communication with another vehicle or having an edge router for the communication with another vehicle or
RSU. The method of prefix assignment for each subnet inside the RSU. The method of prefix assignment for each subnet inside the
vehicle's mobile network and the RSU's fixed network is out of scope vehicle's mobile network and the RSU's fixed network is out of scope
for this document. The internetworking between two internal networks for this document. Internetworking between two internal networks via
via either V2I or V2V communication requires an exchange of network either V2I or V2V communication requires an exchange of network
prefix and other parameters. prefix and other parameters.
The network parameter discovery collects networking information for
an IP communication between a vehicle and an RSU or between two
neighboring vehicles, such as link layer, MAC layer, and IP layer
information. The link layer information includes wireless link layer
parameters, such as wireless media (e.g., IEEE 802.11 OCB, LTE D2D,
Bluetooth, and LiFi) and a transmission power level. The MAC layer
information includes the MAC address of an external network interface
for the internetworking with another vehicle or RSU. The IP layer
information includes the IP address and prefix of an external network
interface for the internetworking with another vehicle or RSU.
(*)<..........>(*) (*)<..........>(*)
| | 2001:DB8:1:1::/64 | | 2001:DB8:1:1::/64
.------------------------------. .---------------------------------. .------------------------------. .---------------------------------.
| | | | | | | | | | | |
| .-------. .------. .-------. | | .-------. .------. .-------. | | .-------. .------. .-------. | | .-------. .------. .-------. |
| | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | |
| ._______. .______. ._______. | | ._______. .______. ._______. | | ._______. .______. ._______. | | ._______. .______. ._______. |
| ^ ^ ^ | | ^ ^ ^ | | ^ ^ ^ | | ^ ^ ^ |
| | | | | | | | | | | | | | | | | | | |
| v v v | | v v v | | v v v | | v v v |
skipping to change at page 15, line 34 skipping to change at page 14, line 49
| v v | | v v v | | v v | | v v v |
| ---------------------------- | | ------------------------------- | | ---------------------------- | | ------------------------------- |
| 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 |
.______________________________. ._________________________________. .______________________________. ._________________________________.
Vehicle1 (Moving Network1) RSU1 (Fixed Network1) Vehicle1 (Moving Network1) RSU1 (Fixed Network1)
<----> Wired Link <....> Wireless Link (*) Antenna <----> Wired Link <....> Wireless Link (*) Antenna
Figure 2: Internetworking between Vehicle Network and RSU Network Figure 2: Internetworking between Vehicle Network and RSU Network
The network parameter discovery collects networking information for
an IP communication between a vehicle and an RSU or between two
neighboring vehicles, such as link layer, MAC layer, and IP layer
information. The link layer information includes wireless link layer
parameters, such as wireless media (e.g., IEEE 802.11 OCB, LTE D2D,
Bluetooth, and LiFi) and a transmission power level. The MAC layer
information includes the MAC address of an external network interface
for the internetworking with another vehicle or RSU. The IP layer
information includes the IP address and prefix of an external network
interface for the internetworking with another vehicle or RSU.
Once the network parameter discovery and prefix exchange operations Once the network parameter discovery and prefix exchange operations
are performed, unicast of packets can be supported between the have been performed, packets can be transmitted between the vehicle's
vehicle's moving network and the RSU's fixed network. The DNS naming moving network and the RSU's fixed network. DNS should be supported
service should be supported for the DNS name resolution for hosts or to enable name resolution for hosts or servers residing either in the
servers residing either in the vehicle's moving network or the RSU's vehicle's moving network or the RSU's fixed network.
fixed network.
Figure 2 shows internetworking between the vehicle's moving network Figure 2 shows internetworking between the vehicle's moving network
and the RSU's fixed network. There exists an internal network and the RSU's fixed network. There exists an internal network
(Moving Network1) inside Vehicle1. Vehicle1 has the DNS Server (Moving Network1) inside Vehicle1. Vehicle1 has the DNS Server
(RDNSS1), the two hosts (Host1 and Host2), and the two routers (RDNSS1), the two hosts (Host1 and Host2), and the two routers
(Router1 and Router2). There exists another internal network (Fixed (Router1 and Router2). There exists another internal network (Fixed
Network1) inside RSU1. RSU1 has the DNS Server (RDNSS2), one host Network1) inside RSU1. RSU1 has the DNS Server (RDNSS2), one host
(Host3), the two routers (Router3 and Router4), and the collection of (Host3), the two routers (Router3 and Router4), and the collection of
servers (Server1 to ServerN) for various services in the road servers (Server1 to ServerN) for various services in the road
networks, such as the emergency notification and navigation. networks, such as the emergency notification and navigation.
Vehicle1's Router1 (called mobile router) and RSU1's Router3 (called Vehicle1's Router1 (called mobile router) and RSU1's Router3 (called
fixed router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) fixed router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC)
for I2V networking. for I2V networking.
This document addresses the internetworking between the vehicle's This document addresses the internetworking between the vehicle's
moving network and the RSU's fixed network in Figure 2 and the moving network and the RSU's fixed network in Figure 2 and the
required enhancement of IPv6 protocol suite for the V2I networking required enhancement of IPv6 protocol suite for the V2I networking.
service.
(*)<..........>(*) (*)<..........>(*)
| | 2001:DB8:1:1::/64 | | 2001:DB8:1:1::/64
.------------------------------. .---------------------------------. .------------------------------. .---------------------------------.
| | | | | | | | | | | |
| .-------. .------. .-------. | | .-------. .------. .-------. | | .-------. .------. .-------. | | .-------. .------. .-------. |
| | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | |
| ._______. .______. ._______. | | ._______. .______. ._______. | | ._______. .______. ._______. | | ._______. .______. ._______. |
| ^ ^ ^ | | ^ ^ ^ | | ^ ^ ^ | | ^ ^ ^ |
| | | | | | | | | | | | | | | | | | | |
skipping to change at page 17, line 24 skipping to change at page 16, line 24
two hosts (Host1 and Host2), and the two routers (Router1 and two hosts (Host1 and Host2), and the two routers (Router1 and
Router2). There exists another internal network (Moving Network2) Router2). There exists another internal network (Moving Network2)
inside Vehicle2. Vehicle2 has the DNS Server (RDNSS2), the two hosts inside Vehicle2. Vehicle2 has the DNS Server (RDNSS2), the two hosts
(Host3 and Host4), and the two routers (Router3 and Router4). (Host3 and Host4), and the two routers (Router3 and Router4).
Vehicle1's Router1 (called mobile router) and Vehicle2's Router3 Vehicle1's Router1 (called mobile router) and Vehicle2's Router3
(called mobile router) use 2001:DB8:1:1::/64 for an external link (called mobile router) use 2001:DB8:1:1::/64 for an external link
(e.g., DSRC) for V2V networking. (e.g., DSRC) for V2V networking.
This document describes the internetworking between the moving This document describes the internetworking between the moving
networks of two neighboring vehicles in Figure 3 and the required networks of two neighboring vehicles in Figure 3 and the required
enhancement of IPv6 protocol suite for the V2V networking service. enhancement of IPv6 protocol suite for the V2V networking.
5. Standardization Activities 5. Standardization Activities
This section surveys standard activities for vehicular networks in This section surveys standard activities for vehicular networks in
standards developing organizations. standards developing organizations.
5.1. IEEE Guide for Wireless Access in Vehicular Environments (WAVE) - 5.1. IEEE Guide for WAVE - Architecture
Architecture
IEEE 1609 is a suite of standards for Wireless Access in Vehicular IEEE 1609 is a suite of standards for Wireless Access in Vehicular
Environments (WAVE) developed in the IEEE Vehicular Technology Environments (WAVE) developed in the IEEE Vehicular Technology
Society (VTS). They define an architecture and a complementary Society (VTS). They define an architecture and a complementary
standardized set of services and interfaces that collectively enable standardized set of services and interfaces that collectively enable
secure vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) secure vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I)
wireless communications. wireless communications.
IEEE 1609.0 provides a description of the WAVE system architecture IEEE 1609.0 provides a description of the WAVE system architecture
and operations (called WAVE reference model) [WAVE-1609.0]. The and operations (called WAVE reference model) [WAVE-1609.0]. The
skipping to change at page 18, line 15 skipping to change at page 17, line 14
Link Control (LLC) header, used to identify the networking protocol Link Control (LLC) header, used to identify the networking protocol
to be employed above the LLC protocol. In particular, it specifies to be employed above the LLC protocol. In particular, it specifies
the use of two Ethertype values (i.e., two networking protocols), the use of two Ethertype values (i.e., two networking protocols),
such as IPv6 and WSMP. such as IPv6 and WSMP.
Regarding the upper layers, while WAVE communications use standard Regarding the upper layers, while WAVE communications use standard
port numbers for IPv6-based protocols (e.g., TCP, UDP), they use a port numbers for IPv6-based protocols (e.g., TCP, UDP), they use a
Provider Service Identifier (PSID) as an identifier in the context of Provider Service Identifier (PSID) as an identifier in the context of
WSMP. WSMP.
5.2. IEEE Standard for Wireless Access in Vehicular Environments (WAVE) 5.2. IEEE Standard for WAVE - Networking Services
- Networking Services
IEEE 1609.3 defines services operating at the network and transport IEEE 1609.3 defines services operating at the network and transport
layers, in support of wireless connectivity among vehicle-based layers, in support of wireless connectivity among vehicle-based
devices, and between fixed roadside devices and vehicle-based devices devices, and between fixed roadside devices and vehicle-based devices
using the 5.9 GHz Dedicated Short-Range Communications/Wireless using the 5.9 GHz Dedicated Short-Range Communications/Wireless
Access in Vehicular Environments (DSRC/WAVE) mode [WAVE-1609.3]. Access in Vehicular Environments (DSRC/WAVE) mode [WAVE-1609.3].
WAVE Networking Services represent layer 3 (networking) and layer 4 WAVE Networking Services represent layer 3 (networking) and layer 4
(transport) of the OSI communications stack. The purpose is then to (transport) of the OSI communications stack. The purpose is then to
provide addressing and routing services within a WAVE system, provide addressing and routing services within a WAVE system,
skipping to change at page 18, line 47 skipping to change at page 17, line 45
The document provides requirements for IPv6 configuration, in The document provides requirements for IPv6 configuration, in
particular for the address setting. It specifies the details of the particular for the address setting. It specifies the details of the
different service primitives, among which is the WAVE Routing different service primitives, among which is the WAVE Routing
Advertisement (WRA), part of the WAVE Service Advertisement (WSA). Advertisement (WRA), part of the WAVE Service Advertisement (WSA).
When present, the WRA provides information about infrastructure When present, the WRA provides information about infrastructure
internetwork connectivity, allowing receiving devices to be internetwork connectivity, allowing receiving devices to be
configured to participate in the advertised IPv6 network. For configured to participate in the advertised IPv6 network. For
example, an RSU can broadcast in the WRA portion of its WSA all the example, an RSU can broadcast in the WRA portion of its WSA all the
information necessary for an OBU to access an application-service information necessary for an OBU to access an application-service
available over IPv6 through the RSU as a router. This feature available over IPv6 through the RSU as a router. This feature
removes the need for an IPv6 Router Advertisement message, which are removes the need for IPv6 Router Advertisement messages, which are
based on ICMPv6. based on ICMPv6.
5.3. ETSI Intelligent Transport Systems: Transmission of IPv6 Packets 5.3. ETSI Intelligent Transport Systems: GeoNetwork-IPv6
over GeoNetworking Protocols
ETSI published a standard specifing the transmission of IPv6 packets ETSI published a standard specifying the transmission of IPv6 packets
over the ETSI GeoNetworking (GN) protocol [ETSI-GeoNetworking] over the ETSI GeoNetworking (GN) protocol [ETSI-GeoNetworking]
[ETSI-GeoNetwork-IP]. IPv6 packet transmission over GN is defined in [ETSI-GeoNetwork-IP]. IPv6 packet transmission over GN is defined in
ETSI EN 302 636-6-1 [ETSI-GeoNetwork-IP] using a protocol adaptation ETSI EN 302 636-6-1 [ETSI-GeoNetwork-IP] using a protocol adaptation
sub-layer called "GeoNetworking to IPv6 Adaptation Sub-Layer sub-layer called "GeoNetworking to IPv6 Adaptation Sub-Layer
(GN6ASL)". It enables an ITS station (ITS-S) running the GN protocol (GN6ASL)". It enables an ITS station (ITS-S) running the GN protocol
and an IPv6-compliant protocol layer to: (i) exchange IPv6 packets and an IPv6-compliant protocol layer to: (i) exchange IPv6 packets
with other ITS-S; (ii) acquire globally routable IPv6 unicast with other ITS-S; (ii) acquire globally routable IPv6 unicast
addresses and communicate with any IPv6 host located in the Internet addresses and communicate with any IPv6 host located in the Internet
by having the direct connectivity to the Internet or via other relay by having the direct connectivity to the Internet or via other relay
ITS stations; (iii) perform operations as a Mobile Router for network ITS stations; (iii) perform operations as a Mobile Router for network
mobility [RFC3963]. mobility [RFC3963].
The document introduces three types of virtual link, the first one The document introduces three types of virtual link, the first one
providing symmetric reachability by means of stable geographically providing symmetric reachability by means of stable geographically
scoped boundaries and two others that can be used when the dynamic scoped boundaries and two others that can be used when the dynamic
definition of the broadcast domain is required. The combination of definition of the broadcast domain is required. The combination of
these three types of virtual link in the same station allows running these three types of virtual link in the same station allows running
the IPv6 ND protocol including Stateless Address Autoconfiguration the IPv6 ND protocol including SLAAC [RFC4862] as well as
(SLAAC) [RFC4862] as well as distributing other IPv6 link-local distributing other IPv6 link-local multicast traffic and, at the same
multicast traffic and, at the same time, reaching nodes that are time, reaching nodes that are outside specific geographic boundaries.
outside specific geographic boundaries. The IPv6 virtual link types The IPv6 virtual link types are provided by the GN6ASL to IPv6 in the
are provided by the GN6ASL to IPv6 in the form of virtual network form of virtual network interfaces.
interfaces.
The document also describes how to support bridging on top of the The document also describes how to support bridging on top of the
GN6ASL, how IPv6 packets are encapsulated IN GN packets and GN6ASL, how IPv6 packets are encapsulated in GN packets and
delivered, as well as the support of IPv6 multicast and anycast delivered, as well as the support of IPv6 multicast and anycast
traffic, and neighbor discovery. For latency reasons, the standard traffic, and neighbor discovery. For latency reasons, the standard
strongly recommends to use SLAAC for the address configuration. strongly recommends to use SLAAC for the address configuration.
Finally, the document includes the required operations to support the Finally, the document includes the required operations to support the
change of pseudonym, e.g., changing IPv6 addresses when the GN change of pseudonym, e.g., changing IPv6 addresses when the GN
address is changed, in order to prevent attackers from tracking the address is changed, in order to prevent attackers from tracking the
ITS-S. ITS-S.
5.4. ISO Intelligent Transport Systems: Communications Access for Land 5.4. ISO Intelligent Transport Systems: IPv6 over CALM
Mobiles (CALM) Using IPv6 Networking
ISO published a standard specifying the IPv6 network protocols and ISO published a standard specifying the IPv6 network protocols and
services [ISO-ITS-IPv6]. These services are necessary to support the services for Communications Access for Land Mobiles (CALM)
global reachability of ITS-S, the continuous Internet connectivity [ISO-ITS-IPv6]. These services are necessary to support the global
for ITS-S, and the handover functionality required to maintain such reachability of ITS-S, the continuous Internet connectivity for ITS-
S, and the handover functionality required to maintain such
connectivity. This functionality also allows legacy devices to connectivity. This functionality also allows legacy devices to
effectively use an ITS-S as an access router to connect to the effectively use an ITS-S as an access router to connect to the
Internet. Essentially, this specification describes how IPv6 is Internet. Essentially, this specification describes how IPv6 is
configured to support ITS-S and provides the associated management configured to support ITS-S and provides the associated management
functionality. functionality.
The requirements apply to all types of nodes implementing IPv6: The requirements apply to all types of nodes implementing IPv6:
personal, vehicle, roadside, or central node. The standard defines personal, vehicle, roadside, or central node. The standard defines
IPv6 functional modules that are necessary in an IPv6 ITS-S, covering IPv6 functional modules that are necessary in an IPv6 ITS-S, covering
IPv6 forwarding, interface between IPv6 and lower layers (e.g., LAN IPv6 forwarding, interface between IPv6 and lower layers (e.g., LAN
interface), mobility management, and IPv6 security. It defines the interface), mobility management, and IPv6 security. It defines the
mechanisms to be used to configure the IPv6 address for static nodes mechanisms to be used to configure the IPv6 address for static nodes
as well as for mobile nodes, while maintaining the addressing as well as for mobile nodes, while maintaining reachability from the
reachability from the Internet. Internet.
6. IP Address Autoconfiguration 6. IP Address Autoconfiguration
This section surveys IP address autoconfiguration schemes for This section surveys IP address autoconfiguration schemes for
vehicular networks, and then discusses problem statement for IP vehicular networks, and then discusses problem statement for IP
addressing and address autoconfiguration for vehicular networking. addressing and address autoconfiguration for vehicular networking.
6.1. Existing Protocols 6.1. Existing Protocols for Address Autoconfiguration
6.1.1. Automatic IP Address Configuration in VANETs 6.1.1. Automatic IP Address Configuration in VANETs
Fazio et al. proposed a vehicular address configuration called VAC Fazio et al. proposed a vehicular address configuration called VAC
for automatic IP address configuration in Vehicular Ad Hoc Networks for automatic IP address configuration in Vehicular Ad Hoc Networks
(VANET) [Address-Autoconf]. VAC uses a distributed dynamic host (VANET) [Address-Autoconf]. VAC uses a distributed dynamic host
configuration protocol (DHCP). This scheme uses a leader playing a configuration protocol (DHCP). This scheme uses a leader playing a
role of a DHCP server within a cluster having connected vehicles role of a DHCP server within a cluster having connected vehicles
within a VANET. In a connected VANET, vehicles are connected with within a VANET. In a connected VANET, vehicles are connected with
each other with the communication range. In this VANET, VAC each other within communication range. In this VANET, VAC
dynamically elects a leader-vehicle to quickly provide vehicles with dynamically elects a leader-vehicle to quickly provide vehicles with
unique IP addresses. The leader-vehicle maintains updated unique IP addresses. The leader-vehicle maintains updated
information on configured addressed in its connected VANET. It aims information on configured addresses in its connected VANET. It aims
at the reduction of the frequency of IP address reconfiguration due at the reduction of the frequency of IP address reconfiguration due
to mobility. to mobility.
VAC defines the concept of SCOPE as a delimited geographic area where VAC defines "SCOPE" to be a delimited geographic area within which IP
IP addresses are guaranteed to be unique. When it is allocated an IP addresses are guaranteed to be unique. When a vehicle is allocated
address from a leader-vehicle with a scope, a vehicle is guaranteed an IP address from a leader-vehicle with a scope, it is guaranteed to
to have a unique IP address while moving within the scope of the have a unique IP address while moving within the scope of the leader-
leader-vehicle. If it moves out of the scope of the leader vehicle, vehicle. If it moves out of the scope of the leader vehicle, it
it needs to ask for another IP address from another leader-vehicle so needs to ask for another IP address from another leader-vehicle so
that its IP address can be unique within the scope of the new leader- that its IP address can be unique within the scope of the new leader-
vehicle. This approach may allow for less frequent change of an IP vehicle. This approach may allow for less frequent change of an IP
address than the address allocation from a fixed Internet gateway. address than the address allocation from a fixed Internet gateway.
Thus, VAC can support a feasible address autoconfiguration for V2V Thus, VAC can support a feasible address autoconfiguration for V2V
scenarios, but the overhead to guarantee the uniqueness of IP scenarios, but the overhead to guarantee the uniqueness of IP
addresses is not ignorable under high-speed mobility. addresses is not ignorable under high-speed mobility.
6.1.2. Routing and Address Assignment using Lane/Position Information 6.1.2. Using Lane/Position Information
in a Vehicular Ad-hoc Network
Kato et al. proposed an IPv6 address assignment scheme using lane and Kato et al. proposed an IPv6 address assignment scheme using lane and
position information [Address-Assignment]. In this addressing position information [Address-Assignment]. In this addressing
scheme, each lane of a road segment has a unique IPv6 prefix. When scheme, each lane of a road segment has a unique IPv6 prefix. When
it moves in a lane in a road segment, a vehicle autoconfigures its it moves in a lane in a road segment, a vehicle autoconfigures its
IPv6 address with its MAC address and the prefix assigned to the IPv6 address with its MAC address and the prefix assigned to the
lane. A group of vehicles constructs a connected VANET within the lane. A group of vehicles constructs a connected VANET within the
same subnet such that their IPv6 addresses have the same prefix. same subnet such that their IPv6 addresses have the same prefix.
Whenever it moves to another lane, a vehicle updates its IPv6 address Whenever it moves to another lane, a vehicle updates its IPv6 address
with the prefix corresponding to the new lane and also joins the with the prefix corresponding to the new lane and also joins the
group corresponding to the lane. group corresponding to the lane.
However, this address autoconfiguration scheme may have much overhead However, this address autoconfiguration scheme may have too much
in the case where vehicles change their lanes frequently in highway. overhead when vehicles change their lanes frequently on the highway.
6.1.3. GeoSAC: Scalable Address Autoconfiguration for VANET Using 6.1.3. GeoSAC: Scalable Address Autoconfiguration
Geographic Networking Concepts
Baldessari et al. proposed an IPv6 scalable address autoconfiguration Baldessari et al. proposed an IPv6 scalable address autoconfiguration
scheme called GeoSAC for vehicular networks [GeoSAC]. GeoSAC uses scheme called GeoSAC for vehicular networks [GeoSAC]. GeoSAC uses
geographic networking concepts such that it combines the standard geographic networking concepts such that it combines the standard
IPv6 Neighbor Discovery (ND) and geographic routing functionality. IPv6 Neighbor Discovery (ND) and geographic routing functionality.
It matches geographically-scoped network partitions to individual It matches geographically-scoped network partitions to individual
IPv6 multicast-capable links. In the standard IPv6, all nodes within IPv6 multicast-capable links. In the standard IPv6, all nodes within
the same link must communicate with each other, but due to the the same link must communicate with each other, but due to the
characteristics of wireless links, this concept of a link is not characteristics of wireless links, this concept of a link is not
clear in vehicular networks. GeoSAC defines a link as a geographic clear in vehicular networks. GeoSAC defines a link as a geographic
area having a network partition. This geographic area can have a area having a network partition. This geographic area can have a
connected VANET. Thus, vehicles within the same VANET in a specific connected VANET. Thus, vehicles within the same VANET in a specific
geographic area are regarded as staying in the same link, that is, an geographic area are regarded as staying in the same link, that is, an
IPv6 multicast link. IPv6 multicast link.
This paper identifies four key requirements of IPv6 address The GeoSAC paper identifies eight key requirements of IPv6 address
autoconfiguration for vehicular networks: (i) the configuration of autoconfiguration for vehicular networks: (i) the configuration of
globally valid addresses, (ii) a low complexity for address globally valid addresses, (ii) a low complexity for address
autoconfiguration, (iii) a minimum signaling overhead of address autoconfiguration, (iii) a minimum signaling overhead of address
autoconfiguration, (iv) the support of network mobility through autoconfiguration, (iv) the support of network mobility through
movement detection, (v) an efficient gateway selection from multiple movement detection, (v) an efficient gateway selection from multiple
RSUs, (vi) a fully distributed address autoconfiguration for network RSUs, (vi) a fully distributed address autoconfiguration for network
security, (vii) the authentication and integrity of signaling security, (vii) the authentication and integrity of signaling
messages, and (viii) the privacy protection of vehicles' users. messages, and (viii) the privacy protection of vehicles' users.
To support the proposed link concept, GeoSAC performs ad hoc routing To support the proposed link concept, GeoSAC performs ad hoc routing
skipping to change at page 22, line 22 skipping to change at page 21, line 18
area and an IPv6 prefix belonging to an RSU, this paper takes area and an IPv6 prefix belonging to an RSU, this paper takes
advantage of an extended DNS service, using GPS-based addressing and advantage of an extended DNS service, using GPS-based addressing and
routing along with geographic IPv6 prefix format [GeoSAC]. routing along with geographic IPv6 prefix format [GeoSAC].
Thus, GeoSAC can support the IPv6 link concept through geographic Thus, GeoSAC can support the IPv6 link concept through geographic
routing within a specific geographic area. routing within a specific geographic area.
6.1.4. Cross-layer Identities Management in ITS Stations 6.1.4. Cross-layer Identities Management in ITS Stations
ITS and vehicular networks are built on the concept of an ITS station ITS and vehicular networks are built on the concept of an ITS station
(e.g., vehicle and RSU), which is a common reference model inspired (ITS-S) (e.g., vehicle and RSU), which is a common reference model
from the Open Systems Interconnection (OSI) standard inspired from the Open Systems Interconnection (OSI) standard
[Identity-Management]. In vehicular networks using multiple access [Identity-Management]. In vehicular networks using multiple access
network technologies through a cross-layer architecture, a vehicle network technologies through a cross-layer architecture, a vehicle
with an OBU may have multiple identities corresponding to the access with an OBU may have multiple identities corresponding to the access
network interfaces. Wetterwald et al. conducted a comprehensive network interfaces. Wetterwald et al. conducted a comprehensive
study of the cross-layer identity management in vehicular networks study of the cross-layer identity management in vehicular networks
using multiple access network technologies, which constitutes a using multiple access network technologies, which constitutes a
fundamental element of the ITS architecture [Identity-Management]. fundamental element of the ITS architecture [Identity-Management].
Besides considerations related to the case where ETSI GeoNetworking Besides considerations related to the case where ETSI GeoNetworking
[ETSI-GeoNetworking] is used, this paper analyzes the major [ETSI-GeoNetworking] is used, this paper analyzes the major
requirements and constraints weighing on the identities of ITS requirements and constraints weighing on the identities of ITS
stations, e.g., privacy and compatibility with safety applications stations, e.g., privacy and compatibility with safety applications
and communications. The concerns related to security and privacy of and communications. The concerns related to security and privacy of
the users need to be addressed for vehicular networking, considering the users need to be addressed for vehicular networking, considering
all the protocol layers simultaneously. In other words, for security all the protocol layers. In other words, for security and privacy
and privacy constraints to be met, the IPv6 address of a vehicle constraints to be met, the IPv6 address of a vehicle should be
should be derived from a pseudonym-based MAC address and renewed derived from a pseudonym-based MAC address and renewed simultaneously
simultaneously with that changing MAC address. This dynamically with that changing MAC address. By dynamically changing its IPv6
changing IPv6 address can prevent the ITS station from being tracked address, an ITS-S can avoid being tracked by a hacker. However,
by a hacker. However, this address renewal cannot be applied at any sometimes this address update cannot be applied; in some situations,
time because in some situations, the continuity of the knowledge continuous knowledge about the surrounding vehicles is required.
about the surrounding vehicles is required.
Also, this paper defines a cross-layer framework that fulfills the Also, the ITS-S Identity Management paper defines a cross-layer
requirements on the identities of ITS stations and analyzes framework that fulfills the requirements on the identities of ITS
systematically, layer by layer, how an ITS station can be identified stations and analyzes systematically, layer by layer, how an ITS
uniquely and safely, whether it is a moving station (e.g., car and station can be identified uniquely and safely, whether it is a moving
bus using temporary trusted pseudonyms) or a static station (e.g., station (e.g., car or bus using temporary trusted pseudonyms) or a
RSU and central station). This paper has been applied to the static station (e.g., RSU and central station). This paper has been
specific case of the ETSI GeoNetworking as the network layer, but an applied to the specific case of the ETSI GeoNetworking as the network
identical reasoning should be applied to IPv6 over 802.11 in Outside layer, but an identical reasoning should be applied to IPv6 over
the Context of a Basic Service Set (OCB) mode now. 802.11 in Outside the Context of a Basic Service Set (OCB) mode now.
6.2. Problem Statement 6.2. Problem Statement for IP Address Autoconfiguration
This section discusses IP addressing for the V2I and V2V networking. This section discusses IP addressing for the V2I and V2V networking.
There are two approaches for IPv6 addressing in vehicular networks. There are two approaches for IPv6 addressing in vehicular networks.
The first is to use unique local IPv6 unicast addresses (ULAs) for The first is to use unique local IPv6 unicast addresses (ULAs) for
vehicular networks [RFC4193]. The other is to use global IPv6 vehicular networks [RFC4193]. The other is to use global IPv6
addresses for the interoperability with the Internet [RFC4291]. The addresses for the interoperability with the Internet [RFC4291]. The
former approach is often used by Mobile Ad Hoc Networks (MANET) for former approach has been used sometimes by Mobile Ad Hoc Networks
an isolated subnet. This approach can support the emergency (MANET) for an isolated subnet. This approach can support the
notification service and navigation service in road networks. emergency notification service and navigation service in road
However, for general Internet services (e.g., email access, web networks. However, for general Internet services (e.g., email
surfing and entertainment services), the latter approach is required. access, web surfing and entertainment services), the latter approach
is required.
For global IP addresses, there are two choices: a multi-link subnet For global IP addresses, there are two choices: a multi-link subnet
approach for multiple RSUs and a single subnet approach per RSU. In approach for multiple RSUs and a single subnet approach per RSU. In
the multi-link subnet approach, which is similar to ULA for MANET, the multi-link subnet approach, which is similar to ULA for MANET,
RSUs play a role of layer-2 (L2) switches and the router RSUs play a role of layer-2 (L2) switches and the router
interconnected with the RSUs is required. The router maintains the interconnected with the RSUs is required. The router maintains the
location of each vehicle belonging to an RSU for L2 switching. In location of each vehicle belonging to an RSU for L2 switching. In
the single subnet approach per RSU, which is similar to the legacy the single subnet approach per RSU, which is similar to the legacy
subnet in the Internet, each RSU plays the role of a (layer-3) subnet in the Internet, each RSU plays the role of a (layer-3)
router. router.
6.2.1. Neighbor Discovery 6.2.1. Neighbor Discovery
Neighbor Discovery (ND) is a core part of IPv6 protocol suite Neighbor Discovery (ND) [RFC4861] is a core part of the IPv6 protocol
[RFC4861]. This section discusses an extension of ND for V2I suite. This section discusses the need for modifying ND for use with
networking. The vehicles are moving fast within the communication V2I networking. The vehicles are moving fast within the
coverage of an RSU. The external link between the vehicle and the communication coverage of an RSU. The external link between the
RSU can be used for V2I networking, as shown in Figure 2. vehicle and the RSU can be used for V2I networking, as shown in
Figure 2.
ND time-related parameters such as router lifetime and Neighbor ND time-related parameters such as router lifetime and Neighbor
Advertisement (NA) interval should be adjusted for high-speed Advertisement (NA) interval should be adjusted for high-speed
vehicles and vehicle density. As vehicles move faster, the NA vehicles and vehicle density. As vehicles move faster, the NA
interval should decrease for the NA messages to reach the neighboring interval should decrease for the NA messages to reach the neighboring
vehicles promptly. Also, as vehicle density is higher, the NA vehicles promptly. Also, as vehicle density is higher, the NA
interval should increase for the NA messages to collide with other NA interval should increase for the NA messages to collide with other NA
messages with lower collision probability. messages with lower collision probability.
6.2.2. IP Address Autoconfiguration 6.2.2. IP Address Autoconfiguration
skipping to change at page 24, line 24 skipping to change at page 23, line 21
periodically report their movement information (e.g., position, periodically report their movement information (e.g., position,
trajectory, speed, and direction) to TCC, TCC can coordinate the RSUs trajectory, speed, and direction) to TCC, TCC can coordinate the RSUs
under its control for the proactive IP address configuration of the under its control for the proactive IP address configuration of the
vehicles with the mobility information of the vehicles. DHCPv6 (or vehicles with the mobility information of the vehicles. DHCPv6 (or
Stateless DHCPv6) can be used for the IP address autoconfiguration Stateless DHCPv6) can be used for the IP address autoconfiguration
[RFC3315][RFC3736]. [RFC3315][RFC3736].
In the case of a single subnet per RSU, the delay to change IPv6 In the case of a single subnet per RSU, the delay to change IPv6
address through DHCPv6 procedure is not suitable since vehicles move address through DHCPv6 procedure is not suitable since vehicles move
fast. Some modifications are required for the high-speed vehicles fast. Some modifications are required for the high-speed vehicles
that quickly crosses the communication coverages of multiple RSUs. that quickly traverses the communication coverages of multiple RSUs.
Some modifications are required for both stateless address Some modifications are required for both stateless address
autoconfiguration and DHCPv6. Mobile IPv6 (MIPv6) can be used for autoconfiguration and DHCPv6. Mobile IPv6 (MIPv6) can be used for
the fast update of a vehicle's care-of address for the current RSU to the fast update of a vehicle's care-of address for the current RSU to
communicate with the vehicle [RFC6275]. communicate with the vehicle [RFC6275].
For IP address autoconfiguration in V2V, vehicles can autoconfigure For IP address autoconfiguration in V2V, vehicles can autoconfigure
their address using prefixes for ULAs for vehicular networks their address using prefixes for ULAs for vehicular networks
[RFC4193]. [RFC4193].
High-speed mobility should be considered for a light-overhead address High-speed mobility should be considered for a light-overhead address
skipping to change at page 24, line 50 skipping to change at page 23, line 47
IPv6 ND should be extended to support the concept of a link for an IPv6 ND should be extended to support the concept of a link for an
IPv6 prefix in terms of multicast. Ad Hoc routing is required for IPv6 prefix in terms of multicast. Ad Hoc routing is required for
the multicast in a connected VANET with the same IPv6 prefix the multicast in a connected VANET with the same IPv6 prefix
[GeoSAC]. A rapid DAD should be supported to prevent or reduce IPv6 [GeoSAC]. A rapid DAD should be supported to prevent or reduce IPv6
address conflicts. address conflicts.
In the ETSI GeoNetworking, for the sake of security and privacy, an In the ETSI GeoNetworking, for the sake of security and privacy, an
ITS station (e.g., vehicle) can use pseudonyms for its network ITS station (e.g., vehicle) can use pseudonyms for its network
interface identities and the corresponding IPv6 addresses interface identities and the corresponding IPv6 addresses
[Identity-Management]. For the continuity of an end-to-end transport [Identity-Management]. For the continuity of an end-to-end transport
session, the cross-layer identity management should be performed session, the cross-layer identity management has to be performed
carefully. carefully.
7. Routing 7. Routing
This section surveys routing in vehicular networks, and then This section surveys routing in vehicular networks, and then
discusses problem statement for routing in vehicular networks. discusses problem statement for routing in vehicular networks.
7.1. Existing Protocols 7.1. Existing Routing Protocols
7.1.1. Experimental Evaluation for IPv6 over VANET Geographic Routing 7.1.1. Experimental Evaluation for IPv6 over GeoNet
Tsukada et al. presented a work that aims at combining IPv6 Tsukada et al. presented a work that aims at combining IPv6
networking and a Car-to-Car Network routing protocol (called C2CNet) networking and a Car-to-Car Network routing protocol (called C2CNet)
proposed by the Car2Car Communication Consortium (C2C-CC), which is proposed by the Car2Car Communication Consortium (C2C-CC), which is
an architecture using a geographic routing protocol an architecture using a geographic routing protocol
[VANET-Geo-Routing]. In C2C-CC architecture, C2CNet layer is located [VANET-Geo-Routing]. In the C2C-CC architecture, the C2CNet layer is
between IPv6 and link layers. Thus, an IPv6 packet is delivered with located between IPv6 and link layers. Thus, an IPv6 packet is
outer C2CNet header, which introduces the challenge of how to support delivered with an outer C2CNet header, which introduces the challenge
the communication types defined in C2CNet in IPv6 layer. of how to support the communication types defined in C2CNet in IPv6
layer.
The main goal of GeoNet is to enhance these specifications and create The main goal of GeoNet is to enhance the C2C specifications and
a prototype software implementation interfacing with IPv6. C2CNet is create a prototype software implementation interfacing with IPv6.
specified in C2C-CC as a geographic routing protocol. C2CNet is specified in C2C-CC as a geographic routing protocol.
In order to assess the performance of this protocol, the authors In order to assess the performance of C2CNet, the authors measured
measured the network performance with UDP and ICMPv6 traffic using the network performance with UDP and ICMPv6 traffic using iperf and
iperf and ping6. The test results show that IPv6 over C2CNet does ping6. The test results show that IPv6 over C2CNet does not have too
not have too much delay (less than 4ms with a single hop) and is much delay (less than 4ms with a single hop) and is feasible for
feasible for vehicle communication. In the outdoor testbed, they vehicle communication. In the outdoor testbed, they developed
developed AnaVANET to enable hop-by-hop performance measurement and AnaVANET to enable hop-by-hop performance measurement and position
position trace of the vehicles. trace of the vehicles.
The combination of IPv6 multicast and GeoBroadcast was implemented, The combination of IPv6 multicast and GeoBroadcast was implemented;
however, the authors did not evaluate the performance with such a however, the authors did not evaluate the performance with such a
scenario. One of the reasons is that a sufficiently high number of scenario. One of the reasons is that a sufficiently high number of
receivers are necessary to properly evaluate multicast but receivers are necessary to properly evaluate multicast but
experimental evaluation is limited in the number of vehicles (4 in experimental evaluation is limited in the number of vehicles (4 in
this study). this study).
7.1.2. Location-Aided Gateway Advertisement and Discovery Protocol for 7.1.2. Location-Aided Gateway Advertisement and Discovery
VANets
Abrougui et al. presented a gateway discovery scheme for VANET, Abrougui et al. presented a gateway discovery scheme for VANET,
called Location-Aided Gateway Advertisement and Discovery (LAGAD) called Location-Aided Gateway Advertisement and Discovery (LAGAD)
mechanism[LAGAD]. LAGAD enables vehicles to route packets toward the mechanism[LAGAD]. LAGAD enables vehicles to route packets toward the
closest gateway quickly by discovering nearby gateways. The major closest gateway quickly by discovering nearby gateways. The major
problem that LAGAD tackles is to determin the radius of advertisement problem that LAGAD tackles is to determine the radius of
zone of a gateway, which considers location and velocity of a advertisement zone of a gateway, which depends on the location and
vehicle. velocity of a vehicle.
A gateway sends advertisement (GAdv) messages perodically to one-hop A gateway sends advertisement (GAdv) messages perodically to
vehicles. When receiving a request message from a vehicle, the neighboring vehicles. When receiving a request message from a
gateway replies to the source vehicle by a gateway reply (GRep) vehicle, the gateway replies to the source vehicle by a gateway reply
message. The GRep message contains the location information of the (GRep) message. The GRep message contains the location information
gateway and the subnet prefix of the gateway by which the source of the gateway and the subnet prefix of the gateway by which the
vehicle can send data packet via the gateway. Then, the gateway source vehicle can send data packet via the gateway. The gateway
sends GAdv messages through all vehicles within an advertisement zone sends GAdv messages through all vehicles within an advertisement zone
built based on the velocity of the source vehicle. built based on the velocity of the source vehicle.
The source vehicle starts gateway discovery process by sending The source vehicle starts gateway discovery process by sending
routing request packets. The routing request packets is encapsulated routing request packets. The routing request packet is encapsulated
into a Gateway Reactive Discovery (GRD) packet or a GReq message to into a Gateway Reactive Discovery (GRD) packet or a GReq message to
send to the sourrounding vehilces. The GRD contains both discovery send to the surrounding vehicles. The GRD contains both discovery
and routing information as well as the location and the velocity of and routing information as well as the location and the velocity of
the source vehicle. Meanwhile, the intermediate vehicles in an the source vehicle. Meanwhile, the intermediate vehicles in an
advertisement zone of the gateway forward packets sent from the advertisement zone of the gateway forward packets sent from the
source vehicle. The gateway continuously updates the advertisement source vehicle. The gateway continuously updates the advertisement
zone whenever receiving a new data packet from the source vehicle. zone whenever receiving a new data packet from the source vehicle.
7.2. Problem Statement 7.2. Routing Problem Statement
IP address autoconfiguration should be manipulated to support the IP address autoconfiguration should be modified to support the
efficient networking. Due to network fragmentation, vehicles cannot efficient networking. Due to network fragmentation, vehicles
communicate with each other temporarily. IPv6 ND should consider the sometimes cannot communicate with each other temporarily. IPv6 ND
temporary network fragmentation. IPv6 link concept can be supported should consider the temporary network fragmentation. IPv6 link
by Geographic routing to connect vehicles with the same IPv6 prefix. concept can be supported by Geographic routing to connect vehicles
with the same IPv6 prefix.
The gateway advertisement and discovery process for routing in VANET The gateway advertisement and discovery process for routing in VANET
can work probably when the density of vehicle in a road network is can probably work when the density of vehicle in a road network is
not sparse. A sparse vehicular network challenges the gateway not sparse. A sparse vehicular network challenges the gateway
discovery since the network fragmentation interrupts the discovery discovery since network fragmentation interrupts the discovery
process. process.
8. Mobility Management 8. Mobility Management
This section surveys mobility management schemes in vehicular This section surveys mobility management schemes in vehicular
networks to support handover, and then discusses problem statement networks to support handover, and then discusses problem statement
for mobility management in vehicular networks. for mobility management in vehicular networks.
8.1. Existing Protocols 8.1. Existing Protocols
8.1.1. An IP Passing Protocol for Vehicular Ad Hoc Networks with 8.1.1. Vehicular Ad Hoc Networks with Network Fragmentation
Network Fragmentation
Chen et al. tackled the issue of network fragmentation in VANET Chen et al. tackled the issue of network fragmentation in VANET
environments [IP-Passing-Protocol]. The paper proposes a protocol environments [IP-Passing-Protocol]. The paper proposes a protocol
that can postpone the time to release IP addresses to the DHCP server that can postpone the time to release IP addresses to the DHCP server
and select a faster way to get the vehicle's new IP address, when the and select a faster way to get the vehicle's new IP address, when the
vehicle density is low or the speeds of vehicles are varied. In such vehicle density is low or the speeds of vehicles are varied. In such
circumstances, the vehicle may not be able to communicate with the circumstances, the vehicle may not be able to communicate with the
intended vehicle either directly or through multi-hop relays as a intended vehicle either directly or through multi-hop relays as a
consequence of network fragmentation. consequence of network fragmentation.
skipping to change at page 27, line 45 skipping to change at page 26, line 45
Simulations results show that for the proposed protocol, network Simulations results show that for the proposed protocol, network
fragmentation ratio incurs less impact. Vehicle speed and density fragmentation ratio incurs less impact. Vehicle speed and density
has great impact on the performance of the IP passing protocol has great impact on the performance of the IP passing protocol
because vehicle speed and vehicle density will affect network because vehicle speed and vehicle density will affect network
fragmentation ratio. A longer IP lifetime can provide a vehicle with fragmentation ratio. A longer IP lifetime can provide a vehicle with
more chances to acquire its IP address through IP passing. more chances to acquire its IP address through IP passing.
Simulation results show that the proposed scheme can reduce IP Simulation results show that the proposed scheme can reduce IP
acquisition time and packet loss rate, so extend IP lifetime with acquisition time and packet loss rate, so extend IP lifetime with
extra message overhead. extra message overhead.
8.1.2. A Hybrid Centralized-Distributed Mobility Management for 8.1.2. Hybrid Centralized-Distributed Mobility Management
Supporting Highly Mobile Users
Nguyen et al. proposed a hybrid centralized-distributed mobility Nguyen et al. proposed a hybrid centralized-distributed mobility
management called H-DMM to support highly mobile vehicles [H-DMM]. management called H-DMM to support highly mobile vehicles [H-DMM].
The legacy DMM is not suitable for high-speed scenarios because it Legacy mobility management systems are not suitable for high-speed
requires additional registration delay proportional to the distance scenarios because a registration delay is imposed proportional to the
between a vehicle and its anchor network. H-DMM is designed to distance between a vehicle and its anchor network. H-DMM is designed
satisfy a set of requirements, such as service disruption time, end- to satisfy requirements such as service disruption time, end-to-end
to-end delay, packet delivery cost, and tunneling cost. delay, packet delivery cost, and tunneling cost.
H-DMM adopts a central node called central mobility anchor (CMA), H-DMM proposes a central node called central mobility anchor (CMA),
which plays the role of a local mobility anchor (LMA) in PMIPv6. which plays the role of a local mobility anchor (LMA) in PMIPv6.
When it enters a mobile access router (MAR) as an access router, a When it enters a mobile access router (MAR) as an access router, a
vehicle obtains a prefix from the MAR (called MAR-prefix) according vehicle obtains a prefix from the MAR (called MAR-prefix) according
to the legacy DMM protocol. In addition, it obtains another prefix to the legacy DMM protocol. In addition, it obtains another prefix
from the CMA (called LMA-prefix) for a PMIPv6 domain. Whenever it from the CMA (called LMA-prefix) for a PMIPv6 domain. Whenever it
performs a handover between the subnets for two adjacent MARs, a performs a handover between the subnets for two adjacent MARs, a
vehicle keeps the LMA-prefix while obtaining a new prefix from the vehicle keeps the LMA-prefix while obtaining a new prefix from the
new MAR. For a new data exchange with a new CN, the vehicle can new MAR. For a new data exchange with a new CN, the vehicle can
select the MAR-prefix or the LMA-prefix for its own source IPv6 select the MAR-prefix or the LMA-prefix for its own source IPv6
address. If the number of active prefixes is greater than a address. If the number of active prefixes is greater than a
threshold, the vehicle uses the LMA-prefix-based IPv6 address as its threshold, the vehicle uses the LMA-prefix-based IPv6 address as its
source address. In addition, it can continue receiving data packets source address. In addition, it can continue receiving data packets
with the destination IPv6 addresses based on the previous prefixes with the destination IPv6 addresses based on the previous prefixes
through the legacy DMM protocol. through the legacy DMM protocol.
Thus, H-DMM can support an efficient tunneling for a high-speed Thus, H-DMM can support an efficient tunneling for a high-speed
vehicle that moves fast across the subnets of two adjacent MARs. vehicle that moves fast across the subnets of two adjacent MARs.
However, when H-DMM asks a vehicle to perform DAD for the uniqueness However, when H-DMM asks a vehicle to perform DAD for the uniqueness
test of its configured IPv6 address in the subnet of the next MAR, test of its configured IPv6 address in the subnet of the next MAR,
the activation of the configured IPv6 address for networking will the activation of the configured IPv6 address for networking will be
take a delay. This indicates that a proactive DAD by a network delayed. This indicates that a proactive DAD by a network component
component (i.e., MAR and LMA) can shorten the address configuration (i.e., MAR and LMA) can shorten the address configuration delay of
delay of the current DAD triggered by a vehicle. the current DAD triggered by a vehicle.
8.1.3. A Hybrid Centralized-Distributed Mobility Management 8.1.3. Hybrid Architecture for Network Mobility Management
Architecture for Network Mobility
Nguyen et al. proposed H-NEMO, a hybrid centralized-distributed Nguyen et al. proposed H-NEMO, a hybrid centralized-distributed
mobility management scheme to handle IP mobility of moving vehicles mobility management scheme to handle IP mobility of moving vehicles
[H-NEMO]. The standard Network Mobility (NEMO) basic support, which [H-NEMO]. The standard Network Mobility (NEMO) basic support, which
is a centralized scheme for network mobility, provides IP mobility is a centralized scheme for network mobility, provides IP mobility
for a group of users in a moving vehicle, but also inherits the for a group of users in a moving vehicle, but also inherits the
drawbacks from Mobile IPv6, such as suboptimal routing and signaling drawbacks from Mobile IPv6, such as suboptimal routing and signaling
overhead in nested scenarios as well as reliability and scalability overhead in nested scenarios as well as reliability and scalability
issues. On the contrary, distributed schemes such as the recently issues. On the contrary, distributed schemes such as the recently
proposed Distributed Mobility Management (DMM) locates the mobility proposed Distributed Mobility Management (DMM) locates the mobility
skipping to change at page 29, line 20 skipping to change at page 28, line 18
anchor and one from the mobile access router (MAR). In this way, the anchor and one from the mobile access router (MAR). In this way, the
MR/MN may choose a more stable prefix for long-lived flows to be MR/MN may choose a more stable prefix for long-lived flows to be
routed via the central mobility anchor and the MAR-prefix for short- routed via the central mobility anchor and the MAR-prefix for short-
lived flows to be routed following the DMM concept. The multi-hop lived flows to be routed following the DMM concept. The multi-hop
scenario is considered under the concept of a nested-NEMO. scenario is considered under the concept of a nested-NEMO.
Nguyen et al. did not provide simulation-based evaluations, but they Nguyen et al. did not provide simulation-based evaluations, but they
provided an analytical evaluation that considered signaling and provided an analytical evaluation that considered signaling and
packet delivery costs, and showed that H-NEMO outperforms the packet delivery costs, and showed that H-NEMO outperforms the
previous proposals, which are either centralized or distributed ones previous proposals, which are either centralized or distributed ones
with NEMO support. In particular cases, such as the signaling cost, with NEMO support. For some measures, such as the signaling cost,
H-NEMO is more costly than centralized schemes when the velocity of H-NEMO may be more costly than centralized schemes when the velocity
the node is increasing, but behaves better in terms of packet of the node is increasing, but behaves better in terms of packet
delivery cost and handover delay. delivery cost and handover delay.
8.1.4. NEMO-Enabled Localized Mobility Support for Internet Access in 8.1.4. NEMO-Enabled Localized Mobility Support
Automotive Scenarios
In [NEMO-LMS], authors proposed an architecture to enable IP mobility In [NEMO-LMS], the authors proposed an architecture to enable IP
for moving networks in a network-based mobility scheme based on mobility for moving networks using a network-based mobility scheme
PMIPv6. In PMIPv6, only mobile terminals are provided with IP based on PMIPv6. In PMIPv6, only mobile terminals are provided with
mobility. Different from host-based mobility, PMIPv6 shifts the IP mobility. In contrast to from host-based mobility, PMIPv6 shifts
signaling to the network side, so that the mobile access gateway the signaling to the network side, so that the mobile access gateway
(MAG) is in charge of detecting connection/disconnection of the (MAG) is in charge of detecting connection/disconnection of the
mobile node, upon which the signaling to the Local Mobility Anchor mobile node, upon which the signaling to the Local Mobility Anchor
(LMA) is triggered to guarantee a stable IP addressing assignment (LMA) is triggered to guarantee a stable IP addressing assignment
when the mobile node performs handover to a new MAG. when the mobile node performs handover to a new MAG.
Soto et al. proposed NEMO support in PMIPv6 (N-PMIP). In this Soto et al. proposed NEMO support in PMIPv6 (N-PMIP). In this
scheme, the functionality of the MAG is extended to the mobile router scheme, the functionality of the MAG is extended to the mobile router
(MR), also called a mobile MAG (mMAG). The functionality of the (MR), also called a mobile MAG (mMAG). The functionality of the
mobile terminal remains unchanged, but it can receive an IPv6 prefix mobile terminal remains unchanged, but it can receive an IPv6 prefix
belonging to the PMIPv6 domain through the new functionality of the belonging to the PMIPv6 domain through the new functionality of the
mMAG. Therefore, in N-PMIP, the mobile terminal connects to the MR mMAG. Therefore, in N-PMIP, the mobile terminal connects to the MR
as if it is connecting to a fixed MAG, and the MR connects to the as if it is connecting to a fixed MAG, and the MR connects to the
fixed MAG with the standardized signaling of PMIPv6. When the mobile fixed MAG using PMIPv6 signaling. When the mobile terminal roams to
terminal roams to a new MAG or a new MR, the network forwards the a new MAG or a new MR, the network forwards the packets through the
packets through the LMA. Hence, N-PMIP defines an extended LMA. Hence, N-PMIP defines an extended functionality in the LMA that
functionality in the LMA that enables a recursive lookup. First, it enables a recursive lookup. First, it locates the binding entry
locates the binding entry corresponding to the mMAGr. Next, it corresponding to the mMAG. Next, it locates the entry corresponding
locates the entry corresponding to the fixed MAG, after which the LMA to the fixed MAG, after which the LMA can encapsulate packets to the
can encapsulate packets to the mMAG to which the mobile terminal is mMAG to which the mobile terminal is currently connected.
currently connected.
The performance of N-PMIP was evaluated through simulations and The performance of N-PMIP was evaluated through simulations and
compared to a NEMO+MIPv6+PMIPv6 scheme, with better results obtained compared to a NEMO+MIPv6+PMIPv6 scheme, with better results obtained
in N-PMIP. The work did not consider the case of multi-hop in N-PMIP. The work did not consider the case of multi-hop
connectivity in the vehicular scenario. In addition, since the MR connectivity in the vehicular scenario. In addition, since the MR
should be a trusted entity in the PMIP domain, it requires specific should be a trusted entity in the PMIP domain, it requires specific
security associations that were not addressed in [NEMO-LMS]. security associations that were not addressed in [NEMO-LMS].
8.1.5. Network Mobility Protocol for Vehicular Ad Hoc Networks 8.1.5. Network Mobility for Vehicular Ad Hoc Networks
Chen et al. proposed a network mobility protocol to reduce handoff Chen et al. proposed a network mobility protocol to reduce handoff
delay and maintain Internet connectivity to moving vehicles in a delay and maintain Internet connectivity to moving vehicles in a
highway [NEMO-VANET]. In this work, vehicles can acquire IP highway [NEMO-VANET]. In this work, vehicles can acquire IP
addresses from other vehicles through V2V communications. At the addresses from other vehicles through V2V communications. At the
time the vehicle goes out of the coverage of the base station, time the vehicle goes out of the coverage of the base station,
another vehicle may assist the roaming car to acquire a new IP another vehicle may assist the roaming car to acquire a new IP
address. Also, cars on the same or opposite lane are entitled to address. Also, cars on the same or opposite lane are authorized to
assist the vehicle to perform a pre-handoff. assist the vehicle to perform a pre-handoff.
Authors assumed that the wireless connectivity is provided by WiFi The authors assumed that the wireless connectivity is provided by
and WiMAX access networks. Also, they considered scenarios in which WiFi and WiMAX access networks. Also, they considered scenarios in
a single vehicle, i.e., a bus, may need two mobile routers in order which a single vehicle, i.e., a bus, may need two mobile routers in
to have an effective pre-handoff procedure. Evaluations are order to have an effective pre-handoff procedure. Evaluations are
performed through simulations and the comparison schemes are the performed through simulations and the comparison schemes are the
standard NEMO Basic Support protocol and the fast NEMO Basic Support standard NEMO Basic Support protocol and the fast NEMO Basic Support
protocol. Authors did not mention applicability of the scheme in protocol. Authors did not mention applicability of the scheme in
other scenarios such as in urban transport schemes. other scenarios such as in urban transport schemes.
8.1.6. Performance Analysis of PMIPv6-Based Network MObility for 8.1.6. Performance Analysis of P-NEMO for ITS
Intelligent Transportation Systems
Lee et al. proposed P-NEMO, which is an IP mobility management scheme Lee et al. proposed P-NEMO, which is a PMIPv6-based IP mobility
to maintain the Internet connectivity at the vehicle as a mobile management scheme to maintain the Internet connectivity at the
network, and provides a make-before-break mechanism when vehicles vehicle as a mobile network, and provides a make-before-break
switch to a new access network [PMIP-NEMO-Analysis]. Since the mechanism when vehicles switch to a new access network
standard PMIPv6 only supports mobility for a single node, the [PMIP-NEMO-Analysis]. Since the standard PMIPv6 only supports
solution in [PMIP-NEMO-Analysis] adapts the protocol to reduce the mobility for a single node, the solution in [PMIP-NEMO-Analysis]
signaling when a local network is to be served by the in-vehicle adapts the protocol to reduce the signaling when a local network is
mobile router. To achieve this, P-NEMO extends the binding update to be served by an in-vehicle mobile router. To achieve this, P-NEMO
lists at both MAG and LMA, so that the mobile router (MR) can receive extends the binding update lists at both MAG and LMA, so that the
a home network prefix (HNP) and a mobile network prefix (MNP). The mobile router (MR) can receive a home network prefix (HNP) and a
latter prefix enables mobility for the moving network, instead of a mobile network prefix (MNP). The latter prefix enables mobility for
single node as in the standard PMIPv6. the moving network, instead of a single node as in the standard
PMIPv6.
An additional feature is proposed by Lee et al. named fast P-NEMO An additional feature is proposed by Lee et al. named fast P-NEMO
(FP-NEMO). It adopts the fast handover approach standardized for (FP-NEMO). It adopts the fast handover approach standardized for
PMIPv6 in [RFC5949] with both predictive and reactive modes. The PMIPv6 in [RFC5949] with both predictive and reactive modes. The
difference of the proposed feature with the standard version is that difference of the proposed feature with the standard version is that
by using the extensions provided by P-NEMO, the predictive by using the extensions provided by P-NEMO, the predictive
transferring of the context from the old MAG to the new MAG also transferring of the context from the old MAG to the new MAG also
includes information for the moving network, i.e., the MNP, so that includes information for the moving network, i.e., the MNP. In that
mobility support can be achieved not only for the mobile router, but way, mobility support can be achieved not only for the mobile router,
also for mobile nodes traveling with the vehicle. but also for mobile nodes traveling with the vehicle.
The performance of P-NEMO and F-NEMO is only evaluated through an The performance of P-NEMO and F-NEMO is evaluated through an
analytical model that is compared to the standard NEMO-BS. No analytical model that is compared only to the standard NEMO-BS. No
comparison was provided to other schemes that enable network mobility comparison was provided to other schemes that enable network mobility
in PMIPv6 domains, such as the one presented in [NEMO-LMS]. in PMIPv6 domains, such as the one presented in [NEMO-LMS].
8.1.7. A Novel Mobility Management Scheme for Integration of Vehicular 8.1.7. Integration of VANets and Fixed IP Networks
Ad Hoc Networks and Fixed IP Networks
Peng et al. proposed a novel mobility management scheme for Peng et al. proposed a novel mobility management scheme for
integration of VANET and fixed IP networks [VNET-MM]. The proposed integration of VANET and fixed IP networks [VNET-MM]. The proposed
scheme deals with mobility of vehicles based on a street layout scheme deals with mobility of vehicles based on a street layout
instead of a general two dimensional ad hoc network. This scheme instead of a general two dimensional ad hoc network. This scheme
makes use of the information provided by vehicular networks to reduce makes use of the information provided by vehicular networks to reduce
mobility management overhead. It allows multiple base stations that mobility management overhead. It allows multiple base stations that
are close to a destination vehicle to discover the connection to the are close to a destination vehicle to discover the connection to the
vehicle simultaneously, which leads to an improvement of the vehicle simultaneously, which leads to an improvement of the
connectivity and data delivery ratio without redundant messages. The connectivity and data delivery ratio without redundant messages. The
performance was assessed by using a road traffic simulator called performance was assessed by using a road traffic simulator called
SUMO (Simulation of Urban Mobility). SUMO (Simulation of Urban Mobility).
8.1.8. SDN-based Distributed Mobility Management for 5G Networks 8.1.8. SDN-based Mobility Management for 5G Networks
Nguyen et al. extended their previous works on a vehicular adapted Nguyen et al. extended their previous works on a vehicular adapted
DMM considering a Software-Defined Networking (SDN) architecture DMM considering a Software-Defined Networking (SDN) architecture
[SDN-DMM]. On one hand, in their previous work, Nguyen et al. [SDN-DMM]. On one hand, in their previous work, Nguyen et al.
proposed DMM-PMIP and DMM-MIP architectures for VANET. The major proposed DMM-PMIP and DMM-MIP architectures for VANET. The major
innovation behind DMM is to distribute the Mobility Functions (MF) innovation behind DMM is to distribute the Mobility Functions (MFs)
through the network instead of concentrating them in one bottleneck through the network instead of concentrating them in one bottleneck
MF, or in a hierarchically organized backbone of MF. Highly mobile MF, or in a hierarchically organized backbone of MFs. Highly mobile
vehicular networks impose frequent IP route optimizations that lead vehicular networks impose frequent IP route optimizations that lead
to suboptimal routes (detours) between CN and vehicles. The to suboptimal routes (detours) between CN and vehicles. The
suboptimality critically increases by nested or hierarchical MF suboptimality critically increases when there are nested or
nodes. Therefore, flattening the IP mobility architecture hierarchical MF nodes. Therefore, flattening the IP mobility
significantly reduces detours, as it is the role of the last MF to architecture significantly reduces detours, as it is the role of the
get the closest next MF (in most cases nearby). Yet, with an MF last MF to get the closest next MF (in most cases nearby). Yet, with
being distributed throughout the network, a Control plane becomes an MF being distributed throughout the network, a Control plane
necessary in order to provide a solution for CN to address vehicles. becomes necessary in order to provide a solution for CN to address
The various solutions developed by Nguyen at al. not only showed the vehicles. The various solutions developed by Nguyen at al. not only
large benefit of a DMM approach for IPv6 mobility management, but showed the large benefit of a DMM approach for IPv6 mobility
also emphasized the critical role of an efficient Control plane. management, but also emphasized the critical role of an efficient
Control plane.
One the other hand, SDN recently appeared and gained a big attention One the other hand, SDN has recently gained attention from the
from the Internet Networking community due to its capacity to provide Internet Networking community due to its capacity to provide a
a significantly higher scalability of highly dynamic flows, which is significantly higher scalability of highly dynamic flows, which is
required by future 5G dynamic networks. In particular, SDN also required by future 5G dynamic networks In particular, SDN also
suggests a strict separation between a Control plane (SDN-Controller) suggests a strict separation between a Control plane (SDN-Controller)
and a Data plane (OpenFlow Switches) based on the OpenFlow standard. and a Data plane (OpenFlow Switches) based on the OpenFlow standard.
Such an architecture has two advantages that are critical for IP Such an architecture has two advantages that are critical for IP
mobility management in VANET. First, unlike traditional routing mobility management in VANET. First, unlike traditional routing
mechanisms, OpenFlow focuses on flows rather than optimized routes. mechanisms, OpenFlow focuses on flows rather than optimized routes.
Accordingly, they can optimize routing based on flows (grouping Accordingly, they can optimize routing based on flows (grouping
multiple flows in one route, or allowing one flow to have different multiple flows in one route, or allowing one flow to have different
routes), and can detect broken flows much earlier than the routes), and can detect broken flows much earlier than the
traditional networking solutions. Second, SDN controllers may traditional networking solutions. Second, SDN controllers may
dynamically reprogram (reconfigure) OpenFlow Switches (OFS) to always dynamically reprogram (reconfigure) OpenFlow Switches (OFS) to always
keep an optimal route between CN and a vehicular node. keep an optimal route between CN and a vehicular node.
Nguyen et. al observed the mutual benefits IPv6 DMM could obtain from Nguyen et. al observed the mutual benefits IPv6 DMM could obtain from
an SDN architecture, and then proposed an SDN-based DMM for VANET. an SDN architecture, and then proposed an SDN-based DMM for VANET.
In their proposed architecture, a PMIP-DMM is used, where MF is OFS In their proposed architecture, a PMIP-DMM is used, where MF is OFS
for the Data plane, and one or more SDN controllers handle the for the Data plane, and one or more SDN controllers handle the
Control plane. The evaluation and prototype in the paper prove that Control plane. The evaluation and prototype in the paper prove that
the proposed architecture can provide a higher scalability than the the proposed architecture can provide a higher scalability than the
standard DMM. standard DMM.
This paper makes several observations leading to a strong suggestions The SDN-DMM paper makes several observations leading to a strong
that IP mobility management should be based on an SDN architecture. suggestion that IP mobility management should be based on an SDN
First, SDN will be integrated into future Internet and 5G in a near architecture. First, SDN will be integrated into future Internet and
future. Second, after separating the Identity and Routing 5G in the near future. Second, after separating the Identity and
addressing, IP mobility management further requires to separate the Routing addressing, IP mobility management further requires to
Control from the Data plane if it needs to remain scalable for VANET. separate the Control from the Data plane if it needs to remain
Finally, Flow-based routing (in particular OpenFlow standard) will be scalable for VANET. Finally, Flow-based routing (in particular
required in future heterogeneous vehicular networks (e.g., multi-RAT OpenFlow standard) will be required in future heterogeneous vehicular
and multi-protocol) and the SDN coupled with DMM provides a double networks (e.g., multi-RAT and multi-protocol) and the SDN coupled
benefit of dynamic flow detection/reconfiguration and short(-er) with DMM provides a double benefit of dynamic flow detection/
route optimizations. reconfiguration and short(-er) route optimizations.
8.1.9. IP Mobility Management for Vehicular Communication Networks: 8.1.9. IP Mobility for VANETs: Challenges and Solutions
Challenges and Solutions
Cespedes et al. provided a survey of the challenges for NEMO Basic Cespedes et al. provided a survey of the challenges for NEMO Basic
Support for VANET [Vehicular-IP-MM]. NEMO allows the management of a Support for VANET [Vehicular-IP-MM]. NEMO allows the management of a
group of nodes (a mobile network) rather than a single node. group of nodes (a mobile network) rather than a single node.
However, although a vehicle and even a platoon of vehicles could be However, although a vehicle and even a platoon of vehicles could be
seen as a group of nodes, NEMO has not been designed considering the seen as a group of nodes, NEMO has not been designed considering the
particularities of VANET. For example, NEMO builds a tunnel between particularities of VANET. For example, NEMO builds a tunnel between
an MR (on board of a vehicle) and its HA, which in a VANET context is an MR (on board of a vehicle) and its HA, which in a VANET context is
suboptimal, for instance due to over-the-air tunneling cost, the suboptimal, for instance due to over-the-air tunneling cost. Also, a
detour taken to pass by the MR's HA even if the CN is nearby, or the detour may be taken by the MR's HA, even if the CN is nearby.
route optimization when the MR moves to a new AR. Furthermore, route optimization is needed when the MR moves to a new
AR.
Cespedes et al. first summarize the requirements of IP mobility Cespedes et al. first summarize the requirements of IP mobility
management, such as reduced power at end-device, reduced handover management, such as reduced power at end-device, reduced handover
event, reduced complexity, or reduced bandwidth consumption. VANET event, reduced complexity, or reduced bandwidth consumption. VANET
adds the following requirements, such as minimum signaling for route adds the following requirements, such as minimum signaling for route
optimization (RO), per-flow separability, security and binding optimization (RO), per-flow separability, security and binding
privacy protection, multi-homing, and switching HA. As observed, privacy protection, multi-homing, and switching HA. As observed,
these provide several challenges to IP mobility and NEMO BS for these provide several challenges to IP mobility and NEMO BS for
VANET. VANET.
Cespedes et al. then describe various optimization schemes available Cespedes et al. then describe various optimization schemes available
for NEMO BS. Considering a single hop connection to CN, one major for NEMO BS. Considering a single hop connection to CN, one major
optimization direction is to avoid the HA detour and reach the CN optimization direction is to avoid the HA detour and reach the CN
directly. In that direction, a few optimizations are proposed, such directly. In that direction, a few optimizations are proposed, such
as creating an IP tunnel between the MR and the CR directly, creating as creating an IP tunnel between the MR and the CR directly, creating
an IP tunnel between the MR and a CR (rather than the HA), a an IP tunnel between the MR and a CR (rather than the HA), a
delegation mechanism allowing Visiting Nodes to use MIPv6 directly delegation mechanism allowing visiting nodes to use MIPv6 directly
rather than NEMO or finally intra-NEMO optimization for a direct path rather than NEMO or finally intra-NEMO optimization for a direct path
within NEMO bypassing HAs. within NEMO bypassing HAs.
Specific to VANET, multi-hop connection is possible to the fixed Specific to VANET, multi-hop connection is possible to the fixed
network. In that case, NEMO BS must be enhanced to avoid that the network. In that case, NEMO BS must be enhanced to avoid requiring
path to immediate neighbors must pass by the respective HAs instead that the path to immediate neighbors must pass by the respective HAs
of directly. More specifically, two approaches are proposed to rely instead of directly. More specifically, two approaches are proposed
on VANET sub-IP multi-hop routing to hide a NEMO complex topology to rely on VANET sub-IP multi-hop routing to hide a NEMO complex
(e.g., Nested NEMO) and provide a direct route between two VANET topology (e.g., Nested NEMO) and provide a direct route between two
nodes. Generally, one major challenge is security and privacy when VANET nodes. Generally, one major challenge is security and privacy
opening a multi-hop route between a VANET and a CN. Heterogeneous when opening a multi-hop route between a VANET and a CN.
multi-hop in a VANET (e.g., relying on various access technologies) Heterogeneous multi-hop in a VANET (e.g., relying on various access
corresponds to another challenge for NEMO BS as well. technologies) corresponds to another challenge for NEMO BS as well.
Cespedes et al. conclude their paper with an overview of critical Cespedes et al. conclude their paper with an overview of critical
research challenges, such as Anchor Point location, the optimized research challenges, such as Anchor Point location, the optimized
usage of geographic information at the subIP as well as at the IP usage of geographic information at the subIP as well as at the IP
level to improve NEMO BS, security and privacy, and the addressing level to improve NEMO BS, security and privacy, and the addressing
allocation schema for NEMO. allocation schema for NEMO.
In summary, this paper illustrates that NEMO BS for VANET should In summary, this paper illustrates that NEMO BS for VANET should
avoid the HA detour as well as opening IP tunnels over the air. avoid the HA detour as well as opening IP tunnels over the air.
Also, NEMO BS could use geographic information for subIP routing when Also, NEMO BS could use geographic information for subIP routing when
a direct link between vehicles is required to reach an AR, but also a direct link between vehicles is required to reach an AR, but also
anticipate handovers and optimize ROs. From an addressing anticipate handovers and optimize ROs. From an addressing
perspective, dynamic MNP assignments should be preferred, but should perspective, dynamic MNP assignments should be preferred, but should
be secured in particular during binding update (BU). be secured in particular during binding update (BU).
8.2. Problem Statement 8.2. Problem Statement for Mobility-Management
This section discusses an IP mobility support in V2I networking. In This section discusses an IP mobility support in V2I networking. In
a single subnet per RSU, vehicles continually cross the communication a single subnet per RSU, vehicles continually cross the communication
coverages of adjacent RSUs. During this crossing, TCP/UDP sessions coverages of adjacent RSUs. During this crossing, TCP/UDP sessions
can be maintained through IP mobility support, such as MIPv6 can be maintained through IP mobility support, such as MIPv6
[RFC6275], Proxy MIPv6 [RFC5213][RFC5949], and Distributed Mobility [RFC6275], Proxy MIPv6 [RFC5213][RFC5949], and Distributed Mobility
Management (DMM) [RFC7333][RFC7429]. Since vehicles move fast along Management (DMM) [RFC7333][RFC7429]. Since vehicles move fast along
roadways, high speed should be enabled by the parameter configuration roadways, high speed should be enabled by the parameter configuration
in the IP mobility management. With the periodic reports of the in the IP mobility management. With the periodic reports of the
movement information from the vehicles, TCC can coordinate RSUs and movement information from the vehicles, TCC can coordinate RSUs and
other network compoments under its control for the proactive mobility other network compoments under its control for the proactive mobility
management of the vehicles along the movement of the vehicles. management of the vehicles along the movement of the vehicles.
To support the mobility of a vehicle's moving network, Network To support the mobility of a vehicle's moving network, Network
Mobility Basic Support Protocol (NEMO) can be used [RFC3963]. Like Mobility Basic Support Protocol (NEMO) can be used [RFC3963]. Like
skipping to change at page 34, line 49 skipping to change at page 33, line 43
9.1.1. Multicast DNS 9.1.1. Multicast DNS
Multicast DNS (mDNS)[RFC6762] allows devices in one-hop communication Multicast DNS (mDNS)[RFC6762] allows devices in one-hop communication
range to resolve each other's DNS name into the corresponding IP range to resolve each other's DNS name into the corresponding IP
address in multicast. Each device has a DNS resolver and a DNS address in multicast. Each device has a DNS resolver and a DNS
server. The DNS resolver generates a DNS query for the device's server. The DNS resolver generates a DNS query for the device's
application and the DNS server responds to a DNS query corresponding application and the DNS server responds to a DNS query corresponding
to its device's DNS name. to its device's DNS name.
9.1.2. DNS Name Autoconfiguration for Internet-of-Things Devices 9.1.2. DNS Name Autoconfiguration for IoT Devices
DNS Name Autoconfiguration (DNSNA) [ID-DNSNA] proposes a DNS naming DNS Name Autoconfiguration (DNSNA) [ID-DNSNA] proposes a DNS naming
service for Internet-of-Things (IoT) devices in a large-scale service for Internet-of-Things (IoT) devices in a large-scale
network. network.
The DNS naming service of DNSNA consists of four steps, such as DNS The DNS naming service of DNSNA consists of four steps, such as DNS
name generation, DNS name duplication detection, DNS name name generation, DNS name duplication detection, DNS name
registration, and DNS name list retrieval. registration, and DNS name list retrieval.
First, in DNS name generation, DNSNA allows each IoT device to First, in DNS name generation, DNSNA allows each IoT device to
skipping to change at page 38, line 14 skipping to change at page 37, line 9
role of an Access Router (AR) for Vehicle ITS-S's MR to provide the role of an Access Router (AR) for Vehicle ITS-S's MR to provide the
Internet connectivity for Vehicle ITS-S via wireless interfaces, such Internet connectivity for Vehicle ITS-S via wireless interfaces, such
as IEEE 802.11p, WiFi, and WiMAX. In the case where Roadside ITS-S as IEEE 802.11p, WiFi, and WiMAX. In the case where Roadside ITS-S
is not available to Vehicle ITS-S, Vehicle ITS-S communicates with is not available to Vehicle ITS-S, Vehicle ITS-S communicates with
Central ITS-S via cellular networks (e.g., 3G). The secure Central ITS-S via cellular networks (e.g., 3G). The secure
communication scheme enhances the NEMO protocol that interworks with communication scheme enhances the NEMO protocol that interworks with
IKEv2 and IPsec in network mobility in vehicular networks. IKEv2 and IPsec in network mobility in vehicular networks.
The authors implemented their scheme and evaluated its performance in The authors implemented their scheme and evaluated its performance in
a real testbed. This testbed supports two wireless networks, such as a real testbed. This testbed supports two wireless networks, such as
IEEE 802.11p and 3G. The in-vehicle devices (or hosts) in Vehicle IEEE 802.11p and 3G. The in-vehicle devices (or hosts) in Vehicle
ITS-S are connected to an MR of Vehicle ITS-S via IEEE 802.11g. The ITS-S are connected to an MR of Vehicle ITS-S via IEEE 802.11g. The
test results show that their scheme supports promising secure IPv6 test results show that their scheme supports promising secure IPv6
communications with a low impact on communication performance. communications with a low impact on communication performance.
11.1.2. Providing Authentication and Access Control in Vehicular 11.1.2. Authentication and Access Control
Network Environment
Moustafa et al. proposed a security scheme providing authentication, Moustafa et al. proposed a security scheme providing authentication,
authorization, and accounting (AAA) services in vehicular networks authorization, and accounting (AAA) services in vehicular networks
[VNET-AAA]. This secuirty scheme aims at the support of safe and [VNET-AAA]. This secuirty scheme aims at the support of safe and
reliable data services in vehicular networks. It authenticates reliable data services in vehicular networks. It authenticates
vehicles as mobile clients to use the network access and various vehicles as mobile clients to use the network access and various
services that are provided by service providers. Also, it ensures a services that are provided by service providers. Also, it ensures a
confidential data transfer between communicating parties (e.g., confidential data transfer between communicating parties (e.g.,
vehicle and infrastructure node) by using IEEE 802.11i (i.e., WPA2) vehicle and infrastructure node) by using IEEE 802.11i (i.e., WPA2)
for secure layer-2 links. for secure layer-2 links.
skipping to change at page 41, line 20 skipping to change at page 40, line 11
Section 11 discusses security and privacy for IP-based vehicular Section 11 discusses security and privacy for IP-based vehicular
networking. networking.
The security for key components in vehicular networking, such as IP The security for key components in vehicular networking, such as IP
address autoconfiguration, routing, mobility management, DNS naming address autoconfiguration, routing, mobility management, DNS naming
service, and service discovery, needs to be analyzed in depth. service, and service discovery, needs to be analyzed in depth.
14. Informative References 14. Informative References
[RFC5889] Baccelli, E. and M. Townsley, "IP Addressing [Address-Assignment]
Model in Ad Hoc Networks", RFC 5889, Kato, T., Kadowaki, K., Koita, T., and K. Sato, "Routing
September 2010. and Address Assignment using Lane/Position Information in
a Vehicular Ad-hoc Network", IEEE Asia-Pacific Services
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., Computing Conference, December 2008.
and P. Thubert, "Network Mobility (NEMO) Basic
Support Protocol", RFC 3963, January 2005.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., [Address-Autoconf]
Chowdhury, K., and B. Patil, "Proxy Mobile Fazio, M., Palazzi, C., Das, S., and M. Gerla, "Automatic
IPv6", RFC 5213, August 2008. IP Address Configuration in VANETs", ACM International
Workshop on Vehicular Inter-Networking, September 2016.
[RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, [CA-Cuise-Control]
B., and F. Xia, "Fast Handovers for Proxy California Partners for Advanced Transportation Technology
Mobile IPv6", RFC 5949, September 2010. (PATH), "Cooperative Adaptive Cruise Control", [Online]
Available:
http://www.path.berkeley.edu/research/automated-and-
connected-vehicles/cooperative-adaptive-cruise-control,
2017.
[RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and [CASD] Shen, Y., Jeong, J., Oh, T., and S. Son, "CASD: A
J. Korhonen, "Requirements for Distributed Framework of Context-Awareness Safety Driving in Vehicular
Mobility Management", RFC 7333, August 2014. Networks", International Workshop on Device Centric Cloud
(DC2), March 2016.
[RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and [ETSI-GeoNetwork-IP]
CJ. Bernardos, "Distributed Mobility ETSI Technical Committee Intelligent Transport Systems,
Management: Current Practices and Gap "Intelligent Transport Systems (ITS); Vehicular
Analysis", RFC 7429, January 2015. Communications; GeoNetworking; Part 6: Internet
Integration; Sub-part 1: Transmission of IPv6 Packets over
GeoNetworking Protocols", ETSI EN 302 636-6-1, October
2013.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, [ETSI-GeoNetworking]
Version 6 (IPv6) Specification", RFC 2460, ETSI Technical Committee Intelligent Transport Systems,
December 1998. "Intelligent Transport Systems (ITS); Vehicular
Communications; GeoNetworking; Part 4: Geographical
addressing and forwarding for point-to-point and point-to-
multipoint communications; Sub-part 1: Media-Independent
Functionality", ETSI EN 302 636-4-1, May 2014.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, [FirstNet]
"Mobility Support in IPv6", RFC 6275, U.S. National Telecommunications and Information
July 2011. Administration (NTIA), "First Responder Network Authority
(FirstNet)", [Online]
Available: https://www.firstnet.gov/, 2012.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 [FleetNet]
Unicast Addresses", RFC 4193, October 2005. Bechler, M., Franz, W., and L. Wolf, "Mobile Internet
Access in FleetNet", 13th Fachtagung Kommunikation in
verteilten Systemen, February 2001.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 [GeoSAC] Baldessari, R., Bernardos, C., and M. Calderon, "GeoSAC -
Addressing Architecture", RFC 4291, Scalable Address Autoconfiguration for VANET Using
February 2006. Geographic Networking Concepts", IEEE International
Symposium on Personal, Indoor and Mobile Radio
Communications, September 2008.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. [H-DMM] Nguyen, T. and C. Bonnet, "A Hybrid Centralized-
Soliman, "Neighbor Discovery for IP Version 6 Distributed Mobility Management for Supporting Highly
(IPv6)", RFC 4861, September 2007. Mobile Users", IEEE International Conference on
Communications, June 2015.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 [H-NEMO] Nguyen, T. and C. Bonnet, "A Hybrid Centralized-
Stateless Address Autoconfiguration", Distributed Mobility Management Architecture for Network
RFC 4862, September 2007. Mobility", IEEE International Symposium on a World of
Wireless, Mobile and Multimedia Networks, June 2015.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, [ID-DNSNA]
T., Perkins, C., and M. Carney, "Dynamic Host Jeong, J., Ed., Lee, S., and J. Park, "DNS Name
Configuration Protocol for IPv6 (DHCPv6)", Autoconfiguration for Internet of Things Devices", draft-
RFC 3315, July 2003. jeong-ipwave-iot-dns-autoconf-01 (work in progress),
October 2017.
[RFC3736] Droms, R., "Stateless Dynamic Host [ID-Vehicular-ND]
Configuration Protocol (DHCP) Service for Jeong, J., Ed., Shen, Y., Jo, Y., Jeong, J., and J. Lee,
IPv6", RFC 3736, April 2004. "IPv6 Neighbor Discovery for Prefix and Service Discovery
in Vehicular Networks", draft-jeong-ipwave-vehicular-
neighbor-discovery-01 (work in progress), October 2017.
[Address-Autoconf] Fazio, M., Palazzi, C., Das, S., and M. Gerla, [Identity-Management]
"Automatic IP Address Configuration in Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer
VANETs", ACM International Workshop on Identities Management in ITS Stations", The 10th
Vehicular Inter-Networking, September 2016. International Conference on ITS Telecommunications,
November 2010.
[Address-Assignment] Kato, T., Kadowaki, K., Koita, T., and K. [IEEE-802.11-OCB]
Sato, "Routing and Address Assignment using IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium
Lane/Position Information in a Vehicular Ad- Access Control (MAC) and Physical Layer (PHY)
hoc Network", IEEE Asia-Pacific Services Specifications", IEEE Std 802.11-2012, February 2012.
Computing Conference, December 2008.
[GeoSAC] Baldessari, R., Bernardos, C., and M. [IEEE-802.11p]
Calderon, "GeoSAC - Scalable Address IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium
Autoconfiguration for VANET Using Geographic Access Control (MAC) and Physical Layer (PHY)
Networking Concepts", IEEE International Specifications - Amendment 6: Wireless Access in Vehicular
Symposium on Personal, Indoor and Mobile Radio Environments", IEEE Std 802.11p-2010, June 2010.
Communications, September 2008.
[Identity-Management] Wetterwald, M., Hrizi, F., and P. Cataldi, [IP-Passing-Protocol]
"Cross-layer Identities Management in ITS Chen, Y., Hsu, C., and W. Yi, "An IP Passing Protocol for
Stations", The 10th International Conference Vehicular Ad Hoc Networks with Network Fragmentation",
on ITS Telecommunications, November 2010. Elsevier Computers & Mathematics with Applications,
January 2012.
[VIP-WAVE] Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: [IPv6-WAVE]
Baccelli, E., Clausen, T., and R. Wakikawa, "IPv6
Operation for WAVE - Wireless Access in Vehicular
Environments", IEEE Vehicular Networking Conference,
December 2010.
On the Feasibility of IP Communications in [ISO-ITS-IPv6]
802.11p Vehicular Networks", IEEE Transactions ISO/TC 204, "Intelligent Transport Systems -
on Intelligent Transportation Systems, Communications Access for Land Mobiles (CALM) - IPv6
March 2013. Networking", ISO 21210:2012, June 2012.
[IPv6-WAVE] Baccelli, E., Clausen, T., and R. Wakikawa, [Joint-IP-Networking]
"IPv6 Operation for WAVE - Wireless Access in Petrescu, A., Boc, M., and C. Ibars, "Joint IP Networking
Vehicular Environments", IEEE Vehicular and Radio Architecture for Vehicular Networks",
Networking Conference, December 2010. 11th International Conference on ITS Telecommunications,
August 2011.
[VNET-Framework] Jemaa, I., Shagdar, O., and T. Ernst, "A [LAGAD] Abrougui, K., Boukerche, A., and R. Pazzi, "Location-Aided
Framework for IP and non-IP Multicast Services Gateway Advertisement and Discovery Protocol for VANets",
for Vehicular Networks", Third International IEEE Transactions on Vehicular Technology, Vol. 59, No. 8,
Conference on the Network of the Future, October 2010.
November 2012.
[Joint-IP-Networking] Petrescu, A., Boc, M., and C. Ibars, "Joint IP [NEMO-LMS]
Networking and Radio Architecture for Soto, I., Bernardos, C., Calderon, M., Banchs, A., and A.
Vehicular Networks", 11th International Azcorra, "NEMO-Enabled Localized Mobility Support for
Conference on ITS Telecommunications, Internet Access in Automotive Scenarios",
August 2011. IEEE Communications Magazine, May 2009.
[FleetNet] Bechler, M., Franz, W., and L. Wolf, "Mobile [NEMO-VANET]
Internet Access in FleetNet", 13th Fachtagung Chen, Y., Hsu, C., and C. Cheng, "Network Mobility
Kommunikation in verteilten Systemen, Protocol for Vehicular Ad Hoc Networks",
February 2001. Wiley International Journal of Communication Systems,
November 2014.
[Vehicular-DTN] Soares, V., Farahmand, F., and J. Rodrigues, [PMIP-NEMO-Analysis]
"A Layered Architecture for Vehicular Delay- Lee, J., Ernst, T., and N. Chilamkurti, "Performance
Tolerant Networks", IEEE Symposium on Analysis of PMIPv6-Based Network Mobility for Intelligent
Computers and Communications, July 2009. Transportation Systems", IEEE Transactions on Vehicular
Technology, January 2012.
[IP-Passing-Protocol] Chen, Y., Hsu, C., and W. Yi, "An IP Passing [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
Protocol for Vehicular Ad Hoc Networks with RFC 1034, November 1987.
Network Fragmentation", Elsevier Computers &
Mathematics with Applications, January 2012.
[VANET-Geo-Routing] Tsukada, M., Jemaa, I., Menouar, H., Zhang, [RFC1035] Mockapetris, P., "Domain Names - Implementation and
W., Goleva, M., and T. Ernst, "Experimental Specification", RFC 1035, November 1987.
Evaluation for IPv6 over VANET Geographic
Routing", IEEE International Wireless
Communications and Mobile Computing
Conference, June 2010.
[LAGAD] Abrougui, K., Boukerche, A., and R. Pazzi, [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
"Location-Aided Gateway Advertisement and (IPv6) Specification", RFC 2460, December 1998.
Discovery Protocol for VANets",
IEEE Transactions on Vehicular Technology,
Vol. 59, No. 8, October 2010.
[H-DMM] Nguyen, T. and C. Bonnet, "A Hybrid [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
Centralized-Distributed Mobility Management Specifying the Location of Services (DNS SRV)", RFC 2782,
for Supporting Highly Mobile Users", February 2000.
IEEE International Conference on
Communications, June 2015.
[H-NEMO] Nguyen, T. and C. Bonnet, "A Hybrid [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
Centralized-Distributed Mobility Management C., and M. Carney, "Dynamic Host Configuration Protocol
Architecture for Network Mobility", for IPv6 (DHCPv6)", RFC 3315, July 2003.
IEEE International Symposium on a World of
Wireless, Mobile and Multimedia Networks,
June 2015.
[NEMO-LMS] Soto, I., Bernardos, C., Calderon, M., Banchs, [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
A., and A. Azcorra, "NEMO-Enabled Localized (DHCP) Service for IPv6", RFC 3736, April 2004.
Mobility Support for Internet Access in
Automotive Scenarios", IEEE Communications
Magazine, May 2009.
[NEMO-VANET] Chen, Y., Hsu, C., and C. Cheng, "Network [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Mobility Protocol for Vehicular Ad Hoc Thubert, "Network Mobility (NEMO) Basic Support Protocol",
Networks", Wiley International Journal of RFC 3963, January 2005.
Communication Systems, November 2014.
[PMIP-NEMO-Analysis] Lee, J., Ernst, T., and N. Chilamkurti, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Performance Analysis of PMIPv6-Based Network "Randomness Requirements for Security", RFC 4086, June
MObility for Intelligent Transportation 2005.
Systems", IEEE Transactions on Vehicular
Technology, January 2012.
[VNET-MM] Peng, Y. and J. Chang, "A Novel Mobility [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Management Scheme for Integration of Vehicular Addresses", RFC 4193, October 2005.
Ad Hoc Networks and Fixed IP Networks",
Springer Mobile Networks and Applications,
February 2010.
[SDN-DMM] Nguyen, T., Bonnet, C., and J. Harri, "SDN- [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
based Distributed Mobility Management for 5G Architecture", RFC 4291, February 2006.
Networks", IEEE Wireless Communications and
Networking Conference, April 2016.
[Vehicular-IP-MM] Cespedes, S., Shen, X., and C. Lazo, "IP [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
Mobility Management for Vehicular "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861,
Communication Networks: Challenges and September 2007.
Solutions", IEEE Communications Magazine,
May 2011.
[Securing-VCOMM] Fernandez, P., Santa, J., Bernal, F., and A. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Skarmeta, "Securing Vehicular IPv6 Address Autoconfiguration", RFC 4862, September 2007.
Communications", IEEE Transactions on
Dependable and Secure Computing, January 2016.
[VNET-AAA] Moustafa, H., Bourdon, G., and Y. Gourhant, [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
"Providing Authentication and Access Control Extensions for Stateless Address Autoconfiguration in
in Vehicular Network Environment", IFIP TC- IPv6", RFC 4941, September 2007.
11 International Information Security
Conference, May 2006.
[IEEE-802.11p] IEEE 802.11 Working Group, "Part 11: Wireless [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
LAN Medium Access Control (MAC) and Physical and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
Layer (PHY) Specifications - Amendment 6:
Wireless Access in Vehicular Environments",
IEEE Std 802.11p-2010, June 2010.
[IEEE-802.11-OCB] IEEE 802.11 Working Group, "Part 11: Wireless [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad
LAN Medium Access Control (MAC) and Physical Hoc Networks", RFC 5889, September 2010.
Layer (PHY) Specifications", IEEE Std 802.11-
2012, February 2012.
[WAVE-1609.0] IEEE 1609 Working Group, "IEEE Guide for [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
Wireless Access in Vehicular Environments Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949,
(WAVE) - Architecture", IEEE Std 1609.0-2013, September 2010.
March 2014.
[WAVE-1609.2] IEEE 1609 Working Group, "IEEE Standard for [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Wireless Access in Vehicular Environments - Support in IPv6", RFC 6275, July 2011.
Security Services for Applications and
Management Messages", IEEE Std 1609.2-2016,
March 2016.
[WAVE-1609.3] IEEE 1609 Working Group, "IEEE Standard for [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
Wireless Access in Vehicular Environments February 2013.
(WAVE) - Networking Services", IEEE Std
1609.3-2016, April 2016.
[WAVE-1609.4] IEEE 1609 Working Group, "IEEE Standard for [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Wireless Access in Vehicular Environments Discovery", RFC 6763, February 2013.
(WAVE) - Multi-Channel Operation", IEEE Std
1609.4-2016, March 2016.
[ETSI-GeoNetworking] ETSI Technical Committee Intelligent Transport [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
Systems, "Intelligent Transport Systems (ITS); "Requirements for Distributed Mobility Management",
Vehicular Communications; GeoNetworking; Part RFC 7333, August 2014.
4: Geographical addressing and forwarding for
point-to-point and point-to-multipoint
communications; Sub-part 1: Media-Independent
Functionality", ETSI EN 302 636-4-1, May 2014.
[ETSI-GeoNetwork-IP] ETSI Technical Committee Intelligent Transport [RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ.
Systems, "Intelligent Transport Systems (ITS); Bernardos, "Distributed Mobility Management: Current
Vehicular Communications; GeoNetworking; Part Practices and Gap Analysis", RFC 7429, January 2015.
6: Internet Integration; Sub-part 1:
Transmission of IPv6 Packets over
GeoNetworking Protocols", ETSI EN 302 636-6-1,
October 2013.
[ISO-ITS-IPv6] ISO/TC 204, "Intelligent Transport Systems - [SAINT] Jeong, J., Jeong, H., Lee, E., Oh, T., and D. Du, "SAINT:
Communications Access for Land Mobiles (CALM) Self-Adaptive Interactive Navigation Tool for Cloud-Based
- IPv6 Networking", ISO 21210:2012, June 2012. Vehicular Traffic Optimization", IEEE Transactions on
Vehicular Technology, Vol. 65, No. 6, June 2016.
[SAINT] Jeong, J., Jeong, H., Lee, E., Oh, T., and D. [SAINTplus]
Du, "SAINT: Self-Adaptive Interactive Shen, Y., Lee, J., Jeong, H., Jeong, J., Lee, E., and D.
Navigation Tool for Cloud-Based Vehicular Du, "SAINT+: Self-Adaptive Interactive Navigation Tool+
Traffic Optimization", IEEE Transactions on for Emergency Service Delivery Optimization",
Vehicular Technology, Vol. 65, No. 6, IEEE Transactions on Intelligent Transportation Systems,
June 2016. June 2017.
[SAINTplus] Shen, Y., Lee, J., Jeong, H., Jeong, J., Lee, [SANA] Hwang, T. and J. Jeong, "SANA: Safety-Aware Navigation
E., and D. Du, "SAINT+: Self-Adaptive Application for Pedestrian Protection in Vehicular
Interactive Navigation Tool+ for Emergency Networks", Springer Lecture Notes in Computer Science
Service Delivery Optimization", (LNCS), Vol. 9502, December 2015.
IEEE Transactions on Intelligent
Transportation Systems, June 2017.
[SANA] Hwang, T. and J. Jeong, "SANA: Safety-Aware [SDN-DMM] Nguyen, T., Bonnet, C., and J. Harri, "SDN-based
Navigation Application for Pedestrian Distributed Mobility Management for 5G Networks",
Protection in Vehicular Networks", IEEE Wireless Communications and Networking Conference,
Springer Lecture Notes in Computer Science April 2016.
(LNCS), Vol. 9502, December 2015.
[FirstNet] U.S. National Telecommunications and [Securing-VCOMM]
Information Administration (NTIA), "First Fernandez, P., Santa, J., Bernal, F., and A. Skarmeta,
Responder Network Authority (FirstNet)", "Securing Vehicular IPv6 Communications",
[Online] Available: https://www.firstnet.gov/, IEEE Transactions on Dependable and Secure Computing,
2012. January 2016.
[CASD] Shen, Y., Jeong, J., Oh, T., and S. Son, [Truck-Platooning]
"CASD: A Framework of Context-Awareness Safety California Partners for Advanced Transportation Technology
Driving in Vehicular Networks", International (PATH), "Automated Truck Platooning", [Online] Available:
Workshop on Device Centric Cloud (DC2), http://www.path.berkeley.edu/research/automated-and-
March 2016. connected-vehicles/truck-platooning, 2017.
[CA-Cuise-Control] California Partners for Advanced [VANET-Geo-Routing]
Transportation Technology (PATH), "Cooperative Tsukada, M., Jemaa, I., Menouar, H., Zhang, W., Goleva,
Adaptive Cruise Control", [Online] Available: M., and T. Ernst, "Experimental Evaluation for IPv6 over
http://www.path.berkeley.edu/research/ VANET Geographic Routing", IEEE International Wireless
automated-and-connected-vehicles/ Communications and Mobile Computing Conference, June 2010.
cooperative-adaptive-cruise-control, 2017.
[Truck-Platooning] California Partners for Advanced [Vehicular-DTN]
Transportation Technology (PATH), "Automated Soares, V., Farahmand, F., and J. Rodrigues, "A Layered
Truck Platooning", [Online] Available: http:// Architecture for Vehicular Delay-Tolerant Networks",
www.path.berkeley.edu/research/ IEEE Symposium on Computers and Communications, July 2009.
automated-and-connected-vehicles/
truck-platooning, 2017.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. [Vehicular-IP-MM]
Crocker, "Randomness Requirements for Cespedes, S., Shen, X., and C. Lazo, "IP Mobility
Security", RFC 4086, June 2005. Management for Vehicular Communication Networks:
Challenges and Solutions", IEEE Communications Magazine,
May 2011.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, [VIP-WAVE]
"Privacy Extensions for Stateless Address Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the
Autoconfiguration in IPv6", RFC 4941, Feasibility of IP Communications in 802.11p Vehicular
September 2007. Networks", IEEE Transactions on Intelligent Transportation
Systems, March 2013.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and [VNET-AAA]
Facilities", RFC 1034, November 1987. Moustafa, H., Bourdon, G., and Y. Gourhant, "Providing
Authentication and Access Control in Vehicular Network
Environment", IFIP TC-11 International Information
Security Conference, May 2006.
[RFC1035] Mockapetris, P., "Domain Names - [VNET-Framework]
Implementation and Specification", RFC 1035, Jemaa, I., Shagdar, O., and T. Ernst, "A Framework for IP
November 1987. and non-IP Multicast Services for Vehicular Networks",
Third International Conference on the Network of the
Future, November 2012.
[ID-DNSNA] Jeong, J., Ed., Lee, S., and J. Park, "DNS [VNET-MM] Peng, Y. and J. Chang, "A Novel Mobility Management Scheme
Name Autoconfiguration for Internet of Things for Integration of Vehicular Ad Hoc Networks and Fixed IP
Devices", Networks", Springer Mobile Networks and Applications,
draft-jeong-ipwave-iot-dns-autoconf-01 (work February 2010.
in progress), October 2017.
[ID-Vehicular-ND] Jeong, J., Ed., Shen, Y., Jo, Y., Jeong, J., [WAVE-1609.0]
and J. Lee, "IPv6 Neighbor Discovery for IEEE 1609 Working Group, "IEEE Guide for Wireless Access
Prefix and Service Discovery in Vehicular in Vehicular Environments (WAVE) - Architecture", IEEE Std
Networks", draft-jeong-ipwave-vehicular- 1609.0-2013, March 2014.
neighbor-discovery-01 (work in progress),
October 2017.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", [WAVE-1609.2]
RFC 6762, February 2013. IEEE 1609 Working Group, "IEEE Standard for Wireless
Access in Vehicular Environments - Security Services for
Applications and Management Messages", IEEE Std
1609.2-2016, March 2016.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based [WAVE-1609.3]
Service Discovery", RFC 6763, February 2013. IEEE 1609 Working Group, "IEEE Standard for Wireless
Access in Vehicular Environments (WAVE) - Networking
Services", IEEE Std 1609.3-2016, April 2016.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A [WAVE-1609.4]
DNS RR for Specifying the Location of Services IEEE 1609 Working Group, "IEEE Standard for Wireless
(DNS SRV)", RFC 2782, February 2000. Access in Vehicular Environments (WAVE) - Multi-Channel
Operation", IEEE Std 1609.4-2016, March 2016.
Appendix A. Acknowledgments Appendix A. Acknowledgments
This work was supported by Basic Science Research Program through the This work was supported by Basic Science Research Program through the
National Research Foundation of Korea (NRF) funded by the Ministry of National Research Foundation of Korea (NRF) funded by the Ministry of
Education (2017R1D1A1B03035885). This work was supported in part by Education (2017R1D1A1B03035885). This work was supported in part by
the Global Research Laboratory Program (2013K1A1A2A02078326) through the Global Research Laboratory Program (2013K1A1A2A02078326) through
NRF and the DGIST Research and Development Program (CPS Global NRF and the DGIST Research and Development Program (CPS Global
Center) funded by the Ministry of Science and ICT. This work was Center) funded by the Ministry of Science and ICT. This work was
supported in part by the French research project DataTweet (ANR-13- supported in part by the French research project DataTweet (ANR-13-
skipping to change at page 48, line 30 skipping to change at page 47, line 26
Appendix B. Contributors Appendix B. Contributors
This document is a group work of IPWAVE working group, greatly This document is a group work of IPWAVE working group, greatly
benefiting from inputs and texts by Rex Buddenberg (Naval benefiting from inputs and texts by Rex Buddenberg (Naval
Postgraduate School), Thierry Ernst (YoGoKo), Bokor Laszlo (Budapest Postgraduate School), Thierry Ernst (YoGoKo), Bokor Laszlo (Budapest
University of Technology and Economics), Jose Santa Lozanoi University of Technology and Economics), Jose Santa Lozanoi
(Universidad of Murcia), Richard Roy (MIT), and Francois Simon (Universidad of Murcia), Richard Roy (MIT), and Francois Simon
(Pilot). The authors sincerely appreciate their contributions. (Pilot). The authors sincerely appreciate their contributions.
The following are contributing authors of this document as co- The following are co-authors of this document:
authors:
Nabil Benamar Nabil Benamar
Department of Computer Sciences Department of Computer Sciences
High School of Technology of Meknes High School of Technology of Meknes
Moulay Ismail University Moulay Ismail University
Morocco Morocco
Phone: +212 6 70 83 22 36 Phone: +212 6 70 83 22 36
EMail: benamar73@gmail.com EMail: benamar73@gmail.com
skipping to change at page 49, line 31 skipping to change at page 48, line 28
Tae (Tom) Oh Tae (Tom) Oh
Department of Information Sciences and Technologies Department of Information Sciences and Technologies
Rochester Institute of Technology Rochester Institute of Technology
One Lomb Memorial Drive One Lomb Memorial Drive
Rochester, NY 14623-5603 Rochester, NY 14623-5603
USA USA
Phone: +1 585 475 7642 Phone: +1 585 475 7642
EMail: Tom.Oh@rit.edu EMail: Tom.Oh@rit.edu
Charles E. Perkins Charles E. Perkins
Futurewei Inc. Futurewei Inc.
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Phone: +1 408 330 4586 Phone: +1 408 330 4586
EMail: charliep@computer.org EMail: charliep@computer.org
Alex Petrescu Alex Petrescu
CEA, LIST CEA, LIST
skipping to change at page 50, line 24 skipping to change at page 49, line 23
URI: http://iotlab.skku.edu/people-chris-shen.php URI: http://iotlab.skku.edu/people-chris-shen.php
Michelle Wetterwald Michelle Wetterwald
FBConsulting FBConsulting
21, Route de Luxembourg 21, Route de Luxembourg
Wasserbillig, Luxembourg L-6633 Wasserbillig, Luxembourg L-6633
Luxembourg Luxembourg
EMail: Michelle.Wetterwald@gmail.com EMail: Michelle.Wetterwald@gmail.com
Author's Address Appendix C. Changes from draft-ietf-ipwave-vehicular-networking-00
The following changes are made from draft-ietf-ipwave-vehicular-
networking-00:
o In Section 4.2, The mobility information of a mobile device (e.g.,
vehicle) can be used by the mobile device and infrastructure nodes
(e.g., TCC and RSU) for enhancing protocol performance.
o In Section 4.2, Vehicles can use the TCC as its Home Network, so
the TCC maintains the mobility information of vehicles for
location management.
o The contents are clarified with typo corrections and rephrasing.
Author's Address
Jaehoon Paul Jeong (editor) Jaehoon Paul Jeong (editor)
Department of Software Department of Software
Sungkyunkwan University Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu 2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419 Suwon, Gyeonggi-Do 16419
Republic of Korea Republic of Korea
Phone: +82 31 299 4957 Phone: +82 31 299 4957
Fax: +82 31 290 7996 Fax: +82 31 290 7996
EMail: pauljeong@skku.edu EMail: pauljeong@skku.edu
 End of changes. 191 change blocks. 
761 lines changed or deleted 727 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/