idnits 2.17.1 draft-ietf-ipwave-vehicular-networking-survey-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 3, 2017) is 2488 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Jeong 3 Internet-Draft Sungkyunkwan University 4 Intended status: Informational S. Cespedes 5 Expires: January 4, 2018 Universidad de Chile 6 N. Benamar 7 Moulay Ismail University 8 J. Haerri 9 EURECOM 10 M. Wetterwald 11 FBConsulting 12 July 3, 2017 14 Survey on IP-based Vehicular Networking for Intelligent Transportation 15 Systems 16 draft-ietf-ipwave-vehicular-networking-survey-00 18 Abstract 20 This document surveys the general problem area on IP-based vehicular 21 networks, which are considered a key component of Intelligent 22 Transportation Systems (ITS). The main topics of vehicular 23 networking are vehicle-to-vehicle (V2V), vehicle-to-infrastructure 24 (V2I), and infrastructure-to-vehicle (I2V) networking. This document 25 deals with some critical aspects in vehicular networking, such as IP 26 address autoconfiguration, vehicular network architecture, routing, 27 mobility management, and security. This document also surveys 28 standard activities for vehicular networks. In addition, this 29 documment surveys the use cases of IP-based vehicular networking for 30 ITS. Finally, this document summarizes and analyzes the previous 31 research activities that use IPv4 or IPv6 for vehicular networking. 33 Status of This Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt. 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html. 54 This Internet-Draft will expire on January 4, 2018. 56 Copyright Notice 58 Copyright (c) 2017 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 75 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 4. IP Address Autoconfiguration . . . . . . . . . . . . . . . . . 5 77 4.1. Automatic IP Address Configuration in VANETs . . . . . . . 5 78 4.2. Routing and Address Assignment using Lane/Position 79 Information in a Vehicular Ad-hoc Network . . . . . . . . 6 80 4.3. GeoSAC: Scalable Address Autoconfiguration for VANET 81 Using Geographic Networking Concepts . . . . . . . . . . . 6 82 4.4. Cross-layer Identities Management in ITS Stations . . . . 7 83 4.5. Key Observations . . . . . . . . . . . . . . . . . . . . . 8 84 5. Vehicular Network Architecture . . . . . . . . . . . . . . . . 8 85 5.1. VIP-WAVE: On the Feasibility of IP Communications in 86 802.11p Vehicular Networks . . . . . . . . . . . . . . . . 8 87 5.2. IPv6 Operation for WAVE - Wireless Access in Vehicular 88 Environments . . . . . . . . . . . . . . . . . . . . . . . 9 89 5.3. A Framework for IP and non-IP Multicast Services for 90 Vehicular Networks . . . . . . . . . . . . . . . . . . . . 10 91 5.4. Joint IP Networking and Radio Architecture for 92 Vehicular Networks . . . . . . . . . . . . . . . . . . . . 11 93 5.5. Mobile Internet Access in FleetNet . . . . . . . . . . . . 12 94 5.6. A Layered Architecture for Vehicular Delay-Tolerant 95 Networks . . . . . . . . . . . . . . . . . . . . . . . . . 13 96 5.7. Key Observations . . . . . . . . . . . . . . . . . . . . . 13 98 6. Vehicular Network Routing . . . . . . . . . . . . . . . . . . 14 99 6.1. An IP Passing Protocol for Vehicular Ad Hoc Networks 100 with Network Fragmentation . . . . . . . . . . . . . . . . 14 101 6.2. Experimental Evaluation for IPv6 over VANET Geographic 102 Routing . . . . . . . . . . . . . . . . . . . . . . . . . 15 103 6.3. Key Observations . . . . . . . . . . . . . . . . . . . . . 15 104 7. Mobility Management in Vehicular Networks . . . . . . . . . . 16 105 7.1. A Hybrid Centralized-Distributed Mobility Management 106 for Supporting Highly Mobile Users . . . . . . . . . . . . 16 107 7.2. A Hybrid Centralized-Distributed Mobility Management 108 Architecture for Network Mobility . . . . . . . . . . . . 16 109 7.3. NEMO-Enabled Localized Mobility Support for Internet 110 Access in Automotive Scenarios . . . . . . . . . . . . . . 17 111 7.4. Network Mobility Protocol for Vehicular Ad Hoc Networks . 18 112 7.5. Performance Analysis of PMIPv6-Based Network MObility 113 for Intelligent Transportation Systems . . . . . . . . . . 18 114 7.6. A Novel Mobility Management Scheme for Integration of 115 Vehicular Ad Hoc Networks and Fixed IP Networks . . . . . 19 116 7.7. SDN-based Distributed Mobility Management for 5G 117 Networks . . . . . . . . . . . . . . . . . . . . . . . . . 19 118 7.8. IP Mobility Management for Vehicular Communication 119 Networks: Challenges and Solutions . . . . . . . . . . . . 21 120 7.9. Key Observations . . . . . . . . . . . . . . . . . . . . . 22 121 8. Vehicular Network Security . . . . . . . . . . . . . . . . . . 22 122 8.1. Securing Vehicular IPv6 Communications . . . . . . . . . . 22 123 8.2. Providing Authentication and Access Control in 124 Vehicular Network Environment . . . . . . . . . . . . . . 23 125 8.3. Key Observations . . . . . . . . . . . . . . . . . . . . . 23 126 9. Standard Activities for Vehicular Networks . . . . . . . . . . 24 127 9.1. IEEE Guide for Wireless Access in Vehicular 128 Environments (WAVE) - Architecture . . . . . . . . . . . . 24 129 9.2. IEEE Standard for Wireless Access in Vehicular 130 Environments (WAVE) - Networking Services . . . . . . . . 24 131 9.3. ETSI Intelligent Transport Systems: Transmission of 132 IPv6 Packets over GeoNetworking Protocols . . . . . . . . 25 133 9.4. ISO Intelligent Transport Systems: Communications 134 Access for Land Mobiles (CALM) Using IPv6 Networking . . . 26 135 10. The Use Cases of Vehicular Networking . . . . . . . . . . . . 26 136 10.1. The Use Cases of V2I Networking . . . . . . . . . . . . . 26 137 10.2. The Use Cases of V2V Networking . . . . . . . . . . . . . 27 138 11. Summary and Analysis . . . . . . . . . . . . . . . . . . . . . 28 139 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29 140 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 141 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 142 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 143 15.1. Normative References . . . . . . . . . . . . . . . . . . . 29 144 15.2. Informative References . . . . . . . . . . . . . . . . . . 30 146 1. Introduction 148 Nowadays vehicular networks have been focused on the driving safety, 149 driving efficiency, and entertainment in road networks. For the 150 driving safety, IEEE has standardized Wireless Access in Vehicular 151 Environments (WAVE) standards, such as IEEE 802.11p [IEEE-802.11p], 152 IEEE 1609.2 [WAVE-1609.2], IEEE 1609.3 [WAVE-1609.3], and IEEE 1609.4 153 [WAVE-1609.4]. Note that IEEE 802.11p has been finalized as IEEE 154 802.11 Outside the Context of a Basic Service Set (OCB) 155 [IEEE-802.11-OCB] in 2012. Along with these WAVE standards, IPv6 and 156 Mobile IP protocols (e.g., MIPv4 and MIPv6) can be extended to 157 vehicular networks. 159 This document surveys the general problem area on IP-based vehicular 160 networking for Intelligent Transportation Systems (ITS), such as IP 161 address autoconfiguration, vehicular network architecture, vehicular 162 network routing (for multi-hop V2V, V2I, and I2V), mobility 163 management, and security. Also, this document surveys standard 164 activities for vehicular networks. In addition, this documment 165 surveys the use cases of IP-based vehicular networking for ITS. 166 Finally, this document summarizes and analyzes the previous research 167 activities using IPv4 or IPv6 for vehicular networking. 169 Based on the survey of this document, we can specify the requirements 170 for vehicular networks for the intended purposes, such as the driving 171 safety, driving efficiency, and entertainment. As a consequence, 172 this will make it possible to design the network architecture and 173 protocols for vehicular networking. 175 2. Requirements Language 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in RFC 2119 [RFC2119]. 181 3. Terminology 183 This document defines the following new terms: 185 o Road-Side Unit (RSU): A node that has Dedicated Short-Range 186 Communications (DSRC) device for wireless communications with 187 vehicles and is also connected to the Internet as a router or 188 switch for packet forwarding. An RSU is deployed either at an 189 intersection or in a road segment. 191 o On-Board Unit (OBU): A node that has a DSRC device for wireless 192 communications with other OBUs and RSUs. An OBU is mounted on a 193 vehicle. It is assumed that a radio navigation receiver (e.g., 194 Global Positioning System (GPS)) is included in a vehicle with an 195 OBU for efficient navigation. 197 o Traffic Control Center (TCC): A node that maintains road 198 infrastructure information (e.g., RSUs, traffic signals, and loop 199 detectors), vehicular traffic statistics (e.g., average vehicle 200 speed and vehicle inter-arrival time per road segment), and 201 vehicle information (e.g., a vehicle's identifier, position, 202 direction, speed, and trajectory as a navigation path). TCC is 203 included in a vehicular cloud for vehicular networks. Exemplary 204 functions of TCC include the management of evacuation routes, the 205 monitoring of pedestrians and bike traffic, the monitoring of 206 real-time transit operations, and real-time responsive traffic 207 signal systems. Thus, TCC is the nerve center of most freeway 208 management sytems such that data is collected, processed, and 209 fused with other operational and control data, and is also 210 synthesized to produce "information" distributed to stakeholders, 211 other agencies, and traveling public. TCC is called Traffic 212 Management Center (TMC) in the US. TCC can communicate with road 213 infrastructure nodes (e.g., RSUs, traffic signals, and loop 214 detectors) to share measurement data and management information by 215 an application-layer protocol. 217 4. IP Address Autoconfiguration 219 This section surveys IP address autoconfiguration schemes for 220 vehicular networks. 222 4.1. Automatic IP Address Configuration in VANETs 224 Fazio et al. proposed a vehicular address configuration called VAC 225 for automatic IP address configuration in Vehicular Ad Hoc Networks 226 (VANET) [Address-Autoconf]. VAC uses a distributed dynamic host 227 configuration protocol (DHCP). This scheme uses a leader playing a 228 role of a DHCP server within a cluster having connected vehicles 229 within a VANET. In a connected VANET, vehicles are connected with 230 each other with the communication range. In this VANET, VAC 231 dynamically elects a leader-vehicle to quickly provide vehicles with 232 unique IP addresses. The leader-vehicle maintains updated 233 information on configured addressed in its connected VANET. It aims 234 at the reduction of the frequency of IP address reconfiguration due 235 to mobility. 237 VAC defines the concept of SCOPE as a delimited geographic area where 238 IP addresses are guaranteed to be unique. When it is allocated an IP 239 address from a leader-vehicle with a scope, a vehicle is guaranteed 240 to have a unique IP address while moving within the scope of the 241 leader-vehicle. If it moves out of the scope of the leader vehicle, 242 it needs to ask for another IP address from another leader-vehicle so 243 that its IP address can be unique within the scope of the new leader- 244 vehicle. This approach may allow for less frequent change of an IP 245 address than the address allocation from a fixed Internet gateway. 247 Thus, VAC can support a feasible address autoconfiguration for V2V 248 scenarios, but the overhead to guarantee the uniqueness of IP 249 addresses is not ignorable under high-speed mobility. 251 4.2. Routing and Address Assignment using Lane/Position Information in 252 a Vehicular Ad-hoc Network 254 Kato et al. proposed an IPv6 address assignment scheme using lane and 255 position information [Address-Assignment]. In this addressing 256 scheme, each lane of a road segment has a unique IPv6 prefix. When 257 it moves in a lane in a road segment, a vehicle autoconfigures its 258 IPv6 address with its MAC address and the prefix assigned to the 259 lane. A group of vehicles constructs a connected VANET within the 260 same subnet such that their IPv6 addresses have the same prefix. 261 Whenever it moves to another lane, a vehicle updates its IPv6 address 262 with the prefix corresponding to the new lane and also joins the 263 group corresponding to the lane. 265 However, this address autoconfiguration scheme may have much overhead 266 in the case where vehicles change their lanes frequently in highway. 268 4.3. GeoSAC: Scalable Address Autoconfiguration for VANET Using 269 Geographic Networking Concepts 271 Baldessari et al. proposed an IPv6 scalable address autoconfiguration 272 scheme called GeoSAC for vehicular networks [GeoSAC]. GeoSAC uses 273 geographic networking concepts such that it combines the standard 274 IPv6 Neighbor Discovery (ND) and geographic routing functionality. 275 It matches geographically-scoped network partitions to individual 276 IPv6 multicast-capable links. In the standard IPv6, all nodes within 277 the same link must communicate with each other, but due to the 278 characteristics of wireless links, this concept of a link is not 279 clear in vehicular networks. GeoSAC defines a link as a geographic 280 area having a network partition. This geographic area can have a 281 connected VANET. Thus, vehicles within the same VANET in a specific 282 geographic area are regarded as staying in the same link, that is, an 283 IPv6 multicast link. 285 This paper identifies four key requirements of IPv6 address 286 autoconfiguration for vehicular networks: (i) the configuration of 287 globally valid addresses, (ii) a low complexity for address 288 autoconfiguration, (iii) a minimum signaling overhead of address 289 autoconfiguration, (iv) the support of network mobility through 290 movement detection, (v) an efficient gateway selection from multiple 291 RSUs, (vi) a fully distributed address autoconfiguration for network 292 security, (vii) the authentication and integrity of signaling 293 messages, and (viii) the privacy protection of vehicles' users. 295 To support the proposed link concept, GeoSAC performs ad hoc routing 296 for geographic networking in a sub-IP layer called Car-to-Car (C2C) 297 NET. Vehicles within the same link can receive an IPv6 router 298 advertisement (RA) message transmitted by an RSU as a router, so they 299 can autoconfigure their IPv6 address based on the IPv6 prefix 300 contained in the RA and perform Duplicate Address Detection (DAD) to 301 verify the uniqueness of the autoconfigured IP address by the help of 302 the geographic routing within the link. 304 For location-based applications, to translate between a geographic 305 area and an IPv6 prefix belonging to an RSU, this paper takes 306 advantage of an extended DNS service, using GPS-based addressing and 307 routing along with geographic IPv6 prefix format [GeoSAC]. 309 Thus, GeoSAC can support the IPv6 link concept through geographic 310 routing within a specific geographic area. 312 4.4. Cross-layer Identities Management in ITS Stations 314 ITS and vehicular networks are built on the concept of an ITS station 315 (e.g., vehicle and RSU), which is a common reference model inspired 316 from the Open Systems Interconnection (OSI) standard 317 [Identities-Management]. In vehicular networks using multiple access 318 network technologies through a cross-layer architecture, a vehicle 319 with an OBU may have multiple identities corresponding to the access 320 network interfaces. Wetterwald et al. conducted a comprehensive 321 study of the cross-layer identity management in vehicular networks 322 using multiple access network technologies, which constitutes a 323 fundamental element of the ITS architecture [Identities-Management]. 325 Besides considerations related to the case where ETSI GeoNetworking 326 [ETSI-GeoNetworking] is used, this paper analyzes the major 327 requirements and constraints weighing on the identities of ITS 328 stations, e.g., privacy and compatibility with safety applications 329 and communications. The concerns related to security and privacy of 330 the users need to be addressed for vehicular networking, considering 331 all the protocol layers simultaneously. In other words, for security 332 and privacy constraints to be met, the IPv6 address of a vehicle 333 should be derived from a pseudonym-based MAC address and renewed 334 simultaneously with that changing MAC address. This dynamically 335 changing IPv6 address can prevent the ITS station from being tracked 336 by a hacker. However, this address renewal cannot be applied at any 337 time because in some situations, the continuity of the knowledge 338 about the surrounding vehicles is required. 340 Also, this paper defines a cross-layer framework that fulfills the 341 requirements on the identities of ITS stations and analyzes 342 systematically, layer by layer, how an ITS station can be identified 343 uniquely and safely, whether it is a moving station (e.g., car and 344 bus using temporary trusted pseudonyms) or a static station (e.g., 345 RSU and central station). This paper has been applied to the 346 specific case of the ETSI GeoNetworking as the network layer, but an 347 identical reasoning should be applied to IPv6 over 802.11 in Outside 348 the Context of a Basic Service Set (OCB) mode now. 350 4.5. Key Observations 352 High-speed mobility should be considered for a light-overhead address 353 autoconfiguration. A cluster leader can have an IPv6 prefix 354 [Address-Autoconf]. Each lane in a road segment can have an IPv6 355 prefix [Address-Assignment]. A geographic region under the 356 communication range of an RSU can have an IPv6 prefix [GeoSAC]. 358 IPv6 ND should be extended to support the concept of a link for an 359 IPv6 prefix in terms of multicast. Ad Hoc routing is required for 360 the multicast in a connected VANET with the same IPv6 prefix 361 [GeoSAC]. A rapid DAD should be supported to prevent or reduce IPv6 362 address conflicts. 364 In the ETSI GeoNetworking, for the sake of security and privacy, an 365 ITS station (e.g., vehicle) can use pseudonyms for its network 366 interface identities and the corresponding IPv6 addresses 367 [Identities-Management]. For the continuity of an end-to-end 368 transport session, the cross-layer identity management should be 369 performed carefully. 371 5. Vehicular Network Architecture 373 This section surveys vehicular network architectures based on IP 374 along with various radio technologies. 376 5.1. VIP-WAVE: On the Feasibility of IP Communications in 802.11p 377 Vehicular Networks 379 Cespedes et al. proposed a vehicular IP in WAVE called VIP-WAVE for 380 I2V and V2I networking [VIP-WAVE]. IEEE 1609.3 specified a WAVE 381 stack of protocols and includes IPv6 as a network layer protocol in 382 data plane [WAVE-1609.3]. The standard WAVE does not support DAD, 383 seamless communications for Internet services, and multi-hop 384 communications between a vehicle and an infrastructure node (e.g., 385 RSU). To overcome these limitations of the standard WAVE for IP- 386 based networking, VIP-WAVE enhances the standard WAVE by the 387 following three schemes: (i) an efficient mechanism for the IPv6 388 address assignment and DAD, (ii) on-demand IP mobility based on Proxy 389 Mobile IPv6 (PMIPv6), and (iii) one-hop and two-hop communications 390 for I2V and V2I networking. 392 In WAVE, IPv6 ND protocol is not recommended due to the overhead of 393 ND against the timely and prompt communications in vehicular 394 networking. By WAVE service advertisement (WAS) management frame, an 395 RSU can provide vehicles with IP configuration information (e.g., 396 IPv6 prefix, prefix length, gateway, router lifetime, and DNS server) 397 without using ND. However, WAVE devices may support readdressing to 398 provide pseudonymity, so a MAC address of a vehicle may be changed or 399 randomly generated. This update of the MAC address may lead to the 400 collision of an IPv6 address based on a MAC address, so VIP-WAVE 401 includes a light-weight, on-demand ND to perform DAD. 403 For IP-based Internet services, VIP-WAVE adopts PMIPv6 for network- 404 based mobility management in vehicular networks. In VIP-WAVE, RSU 405 plays a role of mobile anchor gateway (MAG) of PMIPv6, which performs 406 the detection of a vehicle as a mobile node in a PMIPv6 domain and 407 registers it into the PMIPv6 domain. For PMIPv6 operations, VIP-WAVE 408 requires a central node called local mobility anchor (LMA), which 409 assigns IPv6 prefixes to vehicles as mobile nodes and forwards data 410 packets to the vehicles moving in the coverage of RSUs under its 411 control through tunnels between MAGs and itself. 413 For two-hop communications between a vehicle and an RSU, VIP-WAVE 414 allows an intermediate vehicle between the vehicle and the RSU to 415 play a role of a packet relay for the vehicle. When it becomes out 416 of the communication range of an RSU, a vehicle searches for another 417 vehicle as a packet relay by sending a relay service announcement. 418 When it receives this relay service announcement and is within the 419 communication range of an RSU, another vehicle registers itself into 420 the RSU as a relay and notifies the relay-requester vehicle of a 421 relay maintenance announcement. 423 Thus, VIP-WAVE is a good candidate for I2V and V2I networking, 424 supporting an enhanced ND, handover, and two-hop communications 425 through a relay. 427 5.2. IPv6 Operation for WAVE - Wireless Access in Vehicular 428 Environments 430 Baccelli et al. provided an analysis of the operation of IPv6 as it 431 has been described by the IEEE WAVE standards 1609 [IPv6-WAVE]. 432 Although the main focus of WAVE has been the timely delivery of 433 safety related information, the deployment of IP-based entertainment 434 applications is also considered. Thus, in order to support 435 entertainment traffic, WAVE supports IPv6 and transport protocols 436 such as TCP and UDP. 438 In the analysis provided in [IPv6-WAVE], it is identified that the 439 IEEE 1609.3 standard's recommendations for IPv6 operation over WAVE 440 are rather minimal. Protocols on which the operation of IPv6 relies 441 for IP address configuration and IP-to-link-layer address translation 442 (e.g., IPv6 NP protocol) are not recommended in the standard. 443 Additionally, IPv6 works under certain assumptions for the link model 444 that do not necessarily hold in WAVE. For instance, IPv6 assumes 445 symmetry in the connectivity among neighboring interfaces. However, 446 interference and different levels of transmission power may cause 447 unidirectional links to appear in a WAVE link model. Also, in an 448 IPv6 link, it is assumed that all interfaces which are configured 449 with the same subnet prefix are on the same IP link. Hence, there is 450 a relationship between link and prefix, besides the different scopes 451 that are expected from the link-local and global types of IPv6 452 addresses. Such a relationship does not hold in a WAVE link model 453 due to node mobility and highly dynamic topology. 455 Baccellii et al. concluded that the use of the standard IPv6 protocol 456 stack, as the IEEE 1609 family of specifications stipulate, is not 457 sufficient. Instead, the addressing assignment should follow 458 considerations for ad-hoc link models, defined in [RFC5889], which 459 are similar to the characteristics of the WAVE link model. In terms 460 of the supporting protocols for IPv6, such as ND, DHCP, or stateless 461 auto-configuration, which rely largely on multicast, do not operate 462 as expected in the case where the WAVE link model does not have the 463 same behavior expected for multicast IPv6 traffic due to nodes' 464 mobility and link variability. Additional challenges such as the 465 support of pseudonimity through MAC address change along with the 466 suitability of traditional TCP applications are discussed by the 467 authors since they require the design of appropriate solutions. 469 5.3. A Framework for IP and non-IP Multicast Services for Vehicular 470 Networks 472 Jemaa et al. presented a framework that enables deploying multicast 473 services for vehicular networks in Infrastructure-based scenarios 474 [Vehicular-Network-Framework]. This framework deals with two phases: 475 (i) Initialization or bootstrapping phase that includes a geographic 476 multicast auto-configuration process and a group membership building 477 method and (ii) Multicast traffic dissemination phase that includes a 478 network selecting mechanism on the transmission side and a receiver- 479 based multicast delivery in the reception side. To this end, authors 480 define a distributed mechanism that allows the vehicles to configure 481 a common multicast address: Geographic Multicast Address Auto- 482 configuration (GMAA), which allows a vehicle to configure its own 483 address without signaling. A vehicle may also be able to change the 484 multicast address to which it is subscribed when it changes its 485 location. 487 This framework suggests a network selecting approach that allows IP 488 and non-IP multicast data delivery in the sender side. Then, to meet 489 the challenges of multicast address auto-configuration, the authors 490 propose a distributed geographic multicast auto-addressing mechanism 491 for multicast groups of vehicles, and a simple multicast data 492 delivery scheme in hybrid networks from a server to the group of 493 moving vehicles. However, this study lacks simulations related to 494 performance assessment. 496 5.4. Joint IP Networking and Radio Architecture for Vehicular Networks 498 Petrescu et al. defined the joined IP networking and radio 499 architecture for V2V and V2I communication in [Joint-IP-Networking]. 500 The paper proposes to consider an IP topology in a similar way as a 501 radio link topology, in the sense that an IP subnet would correspond 502 to the range of 1-hop vehicular communication. The paper defines 503 three types of vehicles: Leaf Vehicle (LV), Range Extending Vehicle 504 (REV), and Internet Vehicle (IV). The first class corresponds to the 505 largest set of communicating vehicles (or network nodes within a 506 vehicle), while the role of the second class is to build an IP relay 507 between two IP-subnet and two sub-IP networks. Finally, the last 508 class corresponds to vehicles being connected to Internet. Based on 509 these three classes, the paper defines six types of IP topologies 510 corresponding to V2V communication between two LVs in direct range, 511 or two LVs over a range extending vehicle, or V2I communication again 512 either directly via an IV, via another vehicles being IV, or via an 513 REV connecting to an IV. 515 Considering a toy example of a vehicular train, where LV would be in- 516 wagon communicating nodes, REV would be inter-wagon relays, and IV 517 would be one node (e.g., train head) connected to Internet. Petrescu 518 et al. defined the required mechanisms to build subnetworks, and 519 evaluated the protocol time that is required to build such networks. 520 Although no simulation-based evaluation is conducted, the initial 521 analysis shows a long initial connection overhead, which should be 522 alleviated once the multi-wagon remains stable. However, this 523 approach does not describe what would happen in the case of a dynamic 524 multi-hop vehicular network, where such overhead would end up being 525 too high for V2V/V2I IP-based vehicular applications. 527 One other aspect described in this paper is to join the IP-layer 528 relaying with radio-link channels. This paper suggests to separate 529 different subnetworks in different WiFi/ITS-G5 channels, which could 530 be advertised by the REV. Accordingly, the overall interference 531 could be controlled within each subnetwork. This statement is 532 similar to multi-channel topology management proposals in multi-hop 533 sensor networks, yet adapted to an IP topology. 535 In conclusion, this paper proposes to classify an IP multi-hop 536 vehicular network in three classes of vehicles: Leaf Vehicle (LV), 537 Range Extending Vehicle (REV), and Internet Vehicle (IV). It 538 suggests that the generally complex multi-hop IP vehicular topology 539 could be represented by only six different topologies, which could be 540 further analyzed and optimized. A prefix dissemination protocol is 541 proposed for one of the topologies. 543 5.5. Mobile Internet Access in FleetNet 545 Bechler et al. described the FleetNet project approach to integrate 546 Internet Access in future vehicular networks [FleetNet]. The paper 547 is most probably one of the first paper to address this aspect, and 548 in many ways, introduces concepts that will be later used in MIPv6 or 549 other subsequent IP mobility management schemes. The paper describes 550 a V2I architecture consisting of Vehicles, Internet Gateways (IGW), 551 Proxy, and Corresponding Nodes (CN). Considering that vehicular 552 networks are required to use IPv6 addresses and also the new wireless 553 access technology ITS-G5 (new at that time), one of the challenges is 554 to bridge the two different networks (i.e., VANET and IP4/IPv6 555 Internet). Accordingly, the paper introduces a Fleetnet Gateway 556 (FGW), which allows vehicles in IPv6 to access the IPv4 Internet and 557 to bridge two types of networks and radio access technologies. 558 Another challenge is to keep the active addressing and flows while 559 vehicles move between FGWs. Accordingly, the paper introduces a 560 proxy node, a cranked-up MIP Home Agent, which can re-route flows to 561 the new FGW as well as acting as a local IPv4-IPv6 NAT. 563 The authors from the paper mostly observed two issues that VANET 564 brings into the traditional IP mobility. First, VANET vehicles must 565 mostly be addressed from the Internet directly, and do not 566 specifically have a Home Network. Accordingly, VANET vehicles 567 require a globally (predefined) unique IPv6 address, while an IPv6 568 co-located care-of address (CCoA) is a newly allocated IPv6 address 569 every time a vehicle would enter a new IGW radio range. Second, 570 VANET links are known to be unreliable and short, and the extensive 571 use of IP tunneling on-the-air was judged not efficient. 572 Accordingly, the first major architecture innovation proposed in this 573 paper is to re-introduce a foreign agent (FA) in MIP located at the 574 IGW, so that the IP-tunneling would be kept in the back-end (between 575 a Proxy and an IGW) and not on the air. Second, the proxy has been 576 extended to build an IP tunnel and be connected to the right FA/IWG 577 for an IP flow using a global IPv6 address. 579 This is a pioneer paper, which contributed to changing MIP and led to 580 the new IPv6 architecture currently known as Proxy-MIP and the 581 subsequent DMM-PMIP. Three key messages can be yet kept in mind. 582 First, unlike the Internet, vehicles can be more prominently directly 583 addressed than the Internet traffic, and do not have a Home Network 584 in the traditional MIP sense. Second, IP tunneling should be avoided 585 as much as possible over the air. Third, the protocol-based mobility 586 (induced by the physical mobility) must be kept hidden to both the 587 vehicle and the correspondent node (CN). 589 5.6. A Layered Architecture for Vehicular Delay-Tolerant Networks 591 Soares et al. addressed the case of delay tolerant vehicular network 592 [Vehicular-DTN]. For delay tolerant or disruption tolerant networks, 593 rather than building a complex VANET-IP multi-hop route, vehicles may 594 also be used to carry packets closer to the destination or directly 595 to the destination. The authors built the well-accepted DTN Bundle 596 architecture and protocol to propose a VANET extension. They 597 introduced three types of VANET nodes: (i) terminal nodes (requiring 598 data), (ii) mobile nodes (carrying data along their routes), and 599 (iii) relay nodes (storing data at cross-roads of mobile nodes as 600 data hotspot). 602 The major innovation in this paper is to propose a DTN VANET 603 architecture separating a Control plane and a Data plane. The 604 authors claimed it to be designed to allow full freedom to select the 605 most appropriate technology, as well as allow to use out-of-band 606 communication for small Control plane packets and use DTN in-band for 607 the Data plane. The paper then further describes the different 608 layers from the Control and the Data planes. One interesting aspect 609 is the positioning of the Bundle layer between L2 and L3, rather than 610 above TCP/IP as for the DTN Bundle architecture. The authors claimed 611 this to be required first to keep bundle aggregation/disaggregation 612 transparent to IP, as well as to allow bundle transmission over 613 multiple access technologies (described as MAC/PHY layers in the 614 paper). 616 Although the DTN architectures evolved since the paper has been 617 written, this paper addresses IP mobility management from a different 618 approach. An important aspect is to separate the Control plane from 619 the Data plane to allow a large flexibility in a Control plane to 620 coordinate a heterogeneous radio access technology (RAT) Data plane. 622 5.7. Key Observations 624 Unidirectional links exist and must be considered. Control Plane 625 must be separated from Data Plane. ID/Pseudonym change requires a 626 lightweight DAD. IP tunneling should be avoided. Vehicles do not 627 have a Home Network. Protocol-based mobility must be kept hidden to 628 both the vehicle and the correspondent node (CN). An ITS 629 architecture may be composed of three types of vehicles: Leaf 630 Vehicle, Range Extending Vehicle, and Internet Vehicle. 632 6. Vehicular Network Routing 634 This section surveys routing in vehicular networks. 636 6.1. An IP Passing Protocol for Vehicular Ad Hoc Networks with Network 637 Fragmentation 639 Chen et al. tackled the issue of network fragmentation in VANET 640 environments [IP-Passing-Protocol]. The paper proposes a protocol 641 that can postpone the time to release IP addresses to the DHCP server 642 and select a faster way to get the vehicle's new IP address, when the 643 vehicle density is low or the speeds of vehicles are varied. In such 644 circumstances, the vehicle may not be able to communicate with the 645 intended vehicle either directly or through multi-hop relays as a 646 consequence of network fragmentation. 648 The paper claims that although the existing IP passing and mobility 649 solutions may reduce handoff delay, but they cannot work properly on 650 VANET especially with network fragmentation. This is due to the fact 651 that messages cannot be transmitted to the intended vehicles. When 652 network fragmentation occurs, it may incur longer handoff latency and 653 higher packet loss rate. The main goal of this study is to improve 654 existing works by proposing an IP passing protocol for VANET with 655 network fragmentation. 657 The paper makes the assumption that on the highway, when a vehicle 658 moves to a new subnet, the vehicle will receive broadcast packet from 659 the target Base Station (BS), and then perform the handoff procedure. 660 The handoff procedure includes two parts, such as the layer-2 handoff 661 (new frequency channel) and the layer-3 handover (a new IP address). 662 The handoff procedure contains movement detection, DAD procedure, and 663 registration. In the case of IPv6, the DAD procedure is time 664 consuming and may cause the link to be disconnected. 666 This paper proposes another handoff mechanism. The handoff procedure 667 contains the following phases. The first is the information 668 collecting phase, where each mobile node (vehicle) will broadcast its 669 own and its neighboring vehicles' locations, moving speeds, and 670 directions periodically. The remaining phases are, the fast IP 671 acquiring phase, the cooperation of vehicle phase, the make before 672 break phase, and the route redirection phase. 674 Simulations results show that for the proposed protocol, network 675 fragmentation ratio incurs less impact. Vehicle speed and density 676 has great impact on the performance of the IP passing protocol 677 because vehicle speed and vehicle density will affect network 678 fragmentation ratio. A longer IP lifetime can provide a vehicle with 679 more chances to acquire its IP address through IP passing. 680 Simulation results show that the proposed scheme can reduce IP 681 acquisition time and packet loss rate, so extend IP lifetime with 682 extra message overhead. 684 6.2. Experimental Evaluation for IPv6 over VANET Geographic Routing 686 Tsukada et al. presented a work that aims at combining IPv6 687 networking and a Car-to-Car Network routing protocol (called C2CNet) 688 proposed by the Car2Car Communication Consortium (C2C-CC), which is 689 an architecture using a geographic routing protocol 690 [VANET-Geo-Routing]. In C2C-CC architecture, C2CNet layer is located 691 between IPv6 and link layers. Thus, an IPv6 packet is delivered with 692 outer C2CNet header, which introduces the challenge of how to support 693 the communication types defined in C2CNet in IPv6 layer. 695 The main goal of GeoNet is to enhance these specifications and create 696 a prototype software implementation interfacing with IPv6. C2CNet is 697 specified in C2C-CC as a geographic routing protocol. 699 In order to assess the performance of this protocol, the authors 700 measured the network performance with UDP and ICMPv6 traffic using 701 iperf and ping6. The test results show that IPv6 over C2CNet does 702 not have too much delay (less than 4ms with a single hop) and is 703 feasible for vehicle communication. In the outdoor testbed, they 704 developed AnaVANET to enable hop-by-hop performance measurement and 705 position trace of the vehicles. 707 The combination of IPv6 multicast and GeoBroadcast was implemented, 708 however, the authors did not evaluate the performance with such a 709 scenario. One of the reasons is that a sufficiently high number of 710 receivers are necessary to properly evaluate multicast but 711 experimental evaluation is limited in the number of vehicles (4 in 712 this study). 714 6.3. Key Observations 716 IP address autoconfiguration should be manipulated to support the 717 efficient networking. Due to network fragmentation, vehicles cannot 718 communicate with each other temporarily. IPv6 ND should consider the 719 temporary network fragmentation. IPv6 link concept can be supported 720 by Geographic routing to connect vehicles with the same IPv6 prefix. 722 7. Mobility Management in Vehicular Networks 724 This section surveys mobility management schemes in vehicular 725 networks to support handover. 727 7.1. A Hybrid Centralized-Distributed Mobility Management for 728 Supporting Highly Mobile Users 730 Nguyen et al. proposed a hybrid centralized-distributed mobility 731 management called H-DMM to support highly mobile vehicles [H-DMM]. 732 The legacy DMM is not suitable for high-speed scenarios because it 733 requires additional registration delay proportional to the distance 734 between a vehicle and its anchor network. H-DMM is designed to 735 satisfy a set of requirements, such as service disruption time, end- 736 to-end delay, packet delivery cost, and tunneling cost. 738 H-DMM adopts a central node called central mobility anchor (CMA), 739 which plays the role of a local mobility anchor (LMA) in PMIPv6. 740 When it enters a mobile access router (MAR) as an access router, a 741 vehicle obtains a prefix from the MAR (called MAR-prefix) according 742 to the legacy DMM protocol. In addition, it obtains another prefix 743 from the CMA (called LMA-prefix) for a PMIPv6 domain. Whenever it 744 performs a handover between the subnets for two adjacent MARs, a 745 vehicle keeps the LMA-prefix while obtaining a new prefix from the 746 new MAR. For a new data exchange with a new CN, the vehicle can 747 select the MAR-prefix or the LMA-prefix for its own source IPv6 748 address. If the number of active prefixes is greater than a 749 threshold, the vehicle uses the LMA-prefix-based IPv6 address as its 750 source address. In addition, it can continue receiving data packets 751 with the destination IPv6 addresses based on the previous prefixes 752 through the legacy DMM protocol. 754 Thus, H-DMM can support an efficient tunneling for a high-speed 755 vehicle that moves fast across the subnets of two adjacent MARs. 756 However, when H-DMM asks a vehicle to perform DAD for the uniqueness 757 test of its configured IPv6 address in the subnet of the next MAR, 758 the activation of the configured IPv6 address for networking will 759 take a delay. This indicates that a proactive DAD by a network 760 component (i.e., MAR and LMA) can shorten the address configuration 761 delay of the current DAD triggered by a vehicle. 763 7.2. A Hybrid Centralized-Distributed Mobility Management Architecture 764 for Network Mobility 766 Nguyen et al. proposed H-NEMO, a hybrid centralized-distributed 767 mobility management scheme to handle IP mobility of moving vehicles 768 [H-NEMO]. The standard Network Mobility (NEMO) basic support, which 769 is a centralized scheme for network mobility, provides IP mobility 770 for a group of users in a moving vehicle, but also inherits the 771 drawbacks from Mobile IPv6, such as suboptimal routing and signaling 772 overhead in nested scenarios as well as reliability and scalability 773 issues. On the contrary, distributed schemes such as the recently 774 proposed Distributed Mobility Management (DMM) locates the mobility 775 anchor at the network edge and enables mobility support only to 776 traffic flows that require such support. However, in high speed 777 moving vehicles, DMM may suffer from high signaling cost and high 778 handover latency. 780 The proposed H-NEMO architecture is not designed for a specific 781 wireless technology. Instead, it defines a general architecture and 782 signaling protocol so that a mobile node can obtain mobility from 783 fixed locations or mobile platforms, and also allows the use of DMM 784 or Proxy Mobile IPv6 (PMIPv6), depending on flow characteristics and 785 mobility patterns of the node. For IP addressing allocation, a 786 mobile router (MR) or the mobile node (MN) connected to an MR in a 787 NEMO obtain two sets of prefixes: one from the central mobility 788 anchor and one from the mobile access router (MAR). In this way, the 789 MR/MN may choose a more stable prefix for long-lived flows to be 790 routed via the central mobility anchor and the MAR-prefix for short- 791 lived flows to be routed following the DMM concept. The multi-hop 792 scenario is considered under the concept of a nested-NEMO. 794 Nguyen et al. did not provide simulation-based evaluations, but they 795 provided an analytical evaluation that considered signaling and 796 packet delivery costs, and showed that H-NEMO outperforms the 797 previous proposals, which are either centralized or distributed ones 798 with NEMO support. In particular cases, such as the signaling cost, 799 H-NEMO is more costly than centralized schemes when the velocity of 800 the node is increasing, but behaves better in terms of packet 801 delivery cost and handover delay. 803 7.3. NEMO-Enabled Localized Mobility Support for Internet Access in 804 Automotive Scenarios 806 In [NEMO-LMS], authors proposed an architecture to enable IP mobility 807 for moving networks in a network-based mobility scheme based on 808 PMIPv6. In PMIPv6, only mobile terminals are provided with IP 809 mobility. Different from host-based mobility, PMIPv6 shifts the 810 signaling to the network side, so that the mobile access gateway 811 (MAG) is in charge of detecting connection/disconnection of the 812 mobile node, upon which the signaling to the Local Mobility Anchor 813 (LMA) is triggered to guarantee a stable IP addressing assignment 814 when the mobile node performs handover to a new MAG. 816 Soto et al. proposed NEMO support in PMIPv6 (N-PMIP). In this 817 scheme, the functionality of the MAG is extended to the mobile router 818 (MR), also called a mobile MAG (mMAG). The functionality of the 819 mobile terminal remains unchanged, but it can receive an IPv6 prefix 820 belonging to the PMIPv6 domain through the new functionality of the 821 mMAG. Therefore, in N-PMIP, the mobile terminal connects to the MR 822 as if it is connecting to a fixed MAG, and the MR connects to the 823 fixed MAG with the standardized signaling of PMIPv6. When the mobile 824 terminal roams to a new MAG or a new MR, the network forwards the 825 packets through the LMA. Hence, N-PMIP defines an extended 826 functionality in the LMA that enables a recursive lookup. First, it 827 locates the binding entry corresponding to the mMAGr. Next, it 828 locates the entry corresponding to the fixed MAG, after which the LMA 829 can encapsulate packets to the mMAG to which the mobile terminal is 830 currently connected. 832 The performance of N-PMIP was evaluated through simulations and 833 compared to a NEMO+MIPv6+PMIPv6 scheme, with better results obtained 834 in N-PMIP. The work did not consider the case of multi-hop 835 connectivity in the vehicular scenario. In addition, since the MR 836 should be a trusted entity in the PMIP domain, it requires specific 837 security associations that were not addressed in [NEMO-LMS]. 839 7.4. Network Mobility Protocol for Vehicular Ad Hoc Networks 841 Chen et al. proposed a network mobility protocol to reduce handoff 842 delay and maintain Internet connectivity to moving vehicles in a 843 highway [NEMO-VANET]. In this work, vehicles can acquire IP 844 addresses from other vehicles through V2V communications. At the 845 time the vehicle goes out of the coverage of the base station, 846 another vehicle may assist the roaming car to acquire a new IP 847 address. Also, cars on the same or opposite lane are entitled to 848 assist the vehicle to perform a pre-handoff. 850 Authors assumed that the wireless connectivity is provided by WiFi 851 and WiMAX access networks. Also, they considered scenarios in which 852 a single vehicle, i.e., a bus, may need two mobile routers in order 853 to have an effective pre-handoff procedure. Evaluations are 854 performed through simulations and the comparison schemes are the 855 standard NEMO Basic Support protocol and the fast NEMO Basic Support 856 protocol. Authors did not mention applicability of the scheme in 857 other scenarios such as in urban transport schemes. 859 7.5. Performance Analysis of PMIPv6-Based Network MObility for 860 Intelligent Transportation Systems 862 Lee et al. proposed P-NEMO, which is an IP mobility management scheme 863 to maintain the Internet connectivity at the vehicle as a mobile 864 network, and provides a make-before-break mechanism when vehicles 865 switch to a new access network [PMIPv6-NEMO-Analysis]. Since the 866 standard PMIPv6 only supports mobility for a single node, the 867 solution in [PMIPv6-NEMO-Analysis] adapts the protocol to reduce the 868 signaling when a local network is to be served by the in-vehicle 869 mobile router. To achieve this, P-NEMO extends the binding update 870 lists at both MAG and LMA, so that the mobile router (MR) can receive 871 a home network prefix (HNP) and a mobile network prefix (MNP). The 872 latter prefix enables mobility for the moving network, instead of a 873 single node as in the standard PMIPv6. 875 An additional feature is proposed by Lee et al. named fast P-NEMO 876 (FP-NEMO). It adopts the fast handover approach standardized for 877 PMIPv6 in [RFC5949] with both predictive and reactive modes. The 878 difference of the proposed feature with the standard version is that 879 by using the extensions provided by P-NEMO, the predictive 880 transferring of the context from the old MAG to the new MAG also 881 includes information for the moving network, i.e., the MNP, so that 882 mobility support can be achieved not only for the mobile router, but 883 also for mobile nodes traveling with the vehicle. 885 The performance of P-NEMO and F-NEMO is only evaluated through an 886 analytical model that is compared to the standard NEMO-BS. No 887 comparison was provided to other schemes that enable network mobility 888 in PMIPv6 domains, such as the one presented in [NEMO-LMS]. 890 7.6. A Novel Mobility Management Scheme for Integration of Vehicular Ad 891 Hoc Networks and Fixed IP Networks 893 Peng et al. proposed a novel mobility management scheme for 894 integration of VANET and fixed IP networks [Vehicular-Network-MM]. 895 The proposed scheme deals with mobility of vehicles based on a street 896 layout instead of a general two dimensional ad hoc network. This 897 scheme makes use of the information provided by vehicular networks to 898 reduce mobility management overhead. It allows multiple base 899 stations that are close to a destination vehicle to discover the 900 connection to the vehicle simultaneously, which leads to an 901 improvement of the connectivity and data delivery ratio without 902 redundant messages. The performance was assessed by using a road 903 traffic simulator called SUMO (Simulation of Urban Mobility). 905 7.7. SDN-based Distributed Mobility Management for 5G Networks 907 Nguyen et al. extended their previous works on a vehicular adapted 908 DMM considering a Software-Defined Networking (SDN) architecture 909 [SDN-DMM]. On one hand, in their previous work, Nguyen et al. 910 proposed DMM-PMIP and DMM-MIP architectures for VANET. The major 911 innovation behind DMM is to distribute the Mobility Functions (MF) 912 through the network instead of concentrating them in one bottleneck 913 MF, or in a hierarchically organized backbone of MF. Highly mobile 914 vehicular networks impose frequent IP route optimizations that lead 915 to suboptimal routes (detours) between CN and vehicles. The 916 suboptimality critically increases by nested or hierarchical MF 917 nodes. Therefore, flattening the IP mobility architecture 918 significantly reduces detours, as it is the role of the last MF to 919 get the closest next MF (in most cases nearby). Yet, with an MF 920 being distributed throughout the network, a Control plane becomes 921 necessary in order to provide a solution for CN to address vehicles. 922 The various solutions developed by Nguyen at al. not only showed the 923 large benefit of a DMM approach for IPv6 mobility management, but 924 also emphasized the critical role of an efficient Control plane. 926 One the other hand, SDN recently appeared and gained a big attention 927 from the Internet Networking community due to its capacity to provide 928 a significantly higher scalability of highly dynamic flows, which is 929 required by future 5G dynamic networks. In particular, SDN also 930 suggests a strict separation between a Control plane (SDN-Controller) 931 and a Data plane (OpenFlow Switches) based on the OpenFlow standard. 932 Such an architecture has two advantages that are critical for IP 933 mobility management in VANET. First, unlike traditional routing 934 mechanisms, OpenFlow focuses on flows rather than optimized routes. 935 Accordingly, they can optimize routing based on flows (grouping 936 multiple flows in one route, or allowing one flow to have different 937 routes), and can detect broken flows much earlier than the 938 traditional networking solutions. Second, SDN controllers may 939 dynamically reprogram (reconfigure) OpenFlow Switches (OFS) to always 940 keep an optimal route between CN and a vehicular node. 942 Nguyen et. al observed the mutual benefits IPv6 DMM could obtain from 943 an SDN architecture, and then proposed an SDN-based DMM for VANET. 944 In their proposed architecture, a PMIP-DMM is used, where MF is OFS 945 for the Data plane, and one or more SDN controllers handle the 946 Control plane. The evaluation and prototype in the paper prove that 947 the proposed architecture can provide a higher scalability than the 948 standard DMM. 950 This paper makes several observations leading to a strong suggestions 951 that IP mobility management should be based on an SDN architecture. 952 First, SDN will be integrated into future Internet and 5G in a near 953 future. Second, after separating the Identity and Routing 954 addressing, IP mobility management further requires to separate the 955 Control from the Data plane if it needs to remain scalable for VANET. 956 Finally, Flow-based routing (in particular OpenFlow standard) will be 957 required in future heterogeneous vehicular networks (e.g., multi-RAT 958 and multi-protocol) and the SDN coupled with DMM provides a double 959 benefit of dynamic flow detection/reconfiguration and short(-er) 960 route optimizations. 962 7.8. IP Mobility Management for Vehicular Communication Networks: 963 Challenges and Solutions 965 Cespedes et al. provided a survey of the challenges for NEMO Basic 966 Support for VANET [Vehicular-IP-MM]. NEMO allows the management of a 967 group of nodes (a mobile network) rather than a single node. 968 However, although a vehicle and even a platoon of vehicles could be 969 seen as a group of nodes, NEMO has not been designed considering the 970 particularities of VANET. For example, NEMO builds a tunnel between 971 an MR (on board of a vehicle) and its HA, which in a VANET context is 972 suboptimal, for instance due to over-the-air tunneling cost, the 973 detour taken to pass by the MR's HA even if the CN is nearby, or the 974 route optimization when the MR moves to a new AR. 976 Cespedes et al. first summarize the requirements of IP mobility 977 management, such as reduced power at end-device, reduced handover 978 event, reduced complexity, or reduced bandwidth consumption. VANET 979 adds the following requirements, such as minimum signaling for route 980 optimization (RO), per-flow separability, security and binding 981 privacy protection, multi-homing, and switching HA. As observed, 982 these provide several challenges to IP mobility and NEMO BS for 983 VANET. 985 Cespedes et al. then describe various optimization schemes available 986 for NEMO BS. Considering a single hop connection to CN, one major 987 optimization direction is to avoid the HA detour and reach the CN 988 directly. In that direction, a few optimizations are proposed, such 989 as creating an IP tunnel between the MR and the CR directly, creating 990 an IP tunnel between the MR and a CR (rather than the HA), a 991 delegation mechanism allowing Visiting Nodes to use MIPv6 directly 992 rather than NEMO or finally intra-NEMO optimization for a direct path 993 within NEMO bypassing HAs. 995 Specific to VANET, multi-hop connection is possible to the fixed 996 network. In that case, NEMO BS must be enhanced to avoid that the 997 path to immediate neighbors must pass by the respective HAs instead 998 of directly. More specifically, two approaches are proposed to rely 999 on VANET sub-IP multi-hop routing to hide a NEMO complex topology 1000 (e.g., Nested NEMO) and provide a direct route between two VANET 1001 nodes. Generally, one major challenge is security and privacy when 1002 opening a multi-hop route between a VANET and a CN. Heterogeneous 1003 multi-hop in a VANET (e.g., relying on various access technologies) 1004 corresponds to another challenge for NEMO BS as well. 1006 Cespedes et al. conclude their paper with an overview of critical 1007 research challenges, such as Anchor Point location, the optimized 1008 usage of geographic information at the subIP as well as at the IP 1009 level to improve NEMO BS, security and privacy, and the addressing 1010 allocation schema for NEMO. 1012 In summary, this paper illustrates that NEMO BS for VANET should 1013 avoid the HA detour as well as opening IP tunnels over the air. 1014 Also, NEMO BS could use geographic information for subIP routing when 1015 a direct link between vehicles is required to reach an AR, but also 1016 anticipate handovers and optimize ROs. From an addressing 1017 perspective, dynamic MNP assignments should be preferred, but should 1018 be secured in particular during binding update (BU). 1020 7.9. Key Observations 1022 Mobility Management (MM) solution design varies, depending on 1023 scenarios: highway vs. urban roadway. Hybrid schemes (NEMO + PMIP, 1024 PMIP + DMM, etc.) usually show better performance than pure schemes. 1025 Most schemes assume that IP address configuration is already set up. 1026 Most schemes have been tested only at either simulation or analytical 1027 level. SDN can be considered as a player in the MM solution. 1029 8. Vehicular Network Security 1031 This section surveys security in vehicular networks. 1033 8.1. Securing Vehicular IPv6 Communications 1035 Fernandez et al. proposed a secure vehicular IPv6 communication 1036 scheme using Internet Key Exchange version 2 (IKEv2) and Internet 1037 Protocol Security (IPsec) [Securing-VCOMM]. This scheme aims at the 1038 security support for IPv6 Network Mobility (NEMO) for in-vehicle 1039 devices inside a vehicle via a Mobile Router (MR). An MR has 1040 multiple wireless interfaces, such as 3G, IEEE 802.11p, WiFi, and 1041 WiMAX. The proposed architecture consists of Vehicle ITS Station 1042 (Vehicle ITS-S), Roadside ITS Station (Roadside ITS-S), and Central 1043 ITS Station (Central ITS-S). Vehicle ITS-S is a vehicle having a 1044 mobile Network along with an MR. Roadside ITS-S is an RSU as a 1045 gateway to connect vehicular networks to the Internet. Central ITS-S 1046 is a TCC as a Home Agent (HA) for the location management of vehicles 1047 having their MR. 1049 The proposed secure vehicular IPv6 communication scheme sets up IPsec 1050 secure sessions for control and data traffic between the MR in a 1051 Vehicle ITS-S and the HA in a Central ITS-S. Roadside ITS-S plays a 1052 role of an Access Router (AR) for Vehicle ITS-S's MR to provide the 1053 Internet connectivity for Vehicle ITS-S via wireless interfaces, such 1054 as IEEE 802.11p, WiFi, and WiMAX. In the case where Roadside ITS-S 1055 is not available to Vehicle ITS-S, Vehicle ITS-S communicates with 1056 Central ITS-S via cellular networks (e.g., 3G). The secure 1057 communication scheme enhances the NEMO protocol that interworks with 1058 IKEv2 and IPsec in network mobility in vehicular networks. 1060 The authors implemented their scheme and evaluated its performance in 1061 a real testbed. This testbed supports two wireless networks, such as 1062 IEEE 802.11p and 3G. The in-vehicle devices (or hosts) in Vehicle 1063 ITS-S are connected to an MR of Vehicle ITS-S via IEEE 802.11g. The 1064 test results show that their scheme supports promising secure IPv6 1065 communications with a low impact on communication performance. 1067 8.2. Providing Authentication and Access Control in Vehicular Network 1068 Environment 1070 Moustafa et al. proposed a security scheme providing authentication, 1071 authorization, and accounting (AAA) services in vehicular networks 1072 [VNET-AAA]. This secuirty scheme aims at the support of safe and 1073 reliable data services in vehicular networks. It authenticates 1074 vehicles as mobile clients to use the network access and various 1075 services that are provided by service providers. Also, it ensures a 1076 confidential data transfer between communicating parties (e.g., 1077 vehicle and infrastructure node) by using IEEE 802.11i (i.e., WPA2) 1078 for secure layer-2 links. 1080 The authors proposed a vehicular network architecture consisting of 1081 three entities, such as Access network, Wireless mobile ad hoc 1082 networks (MANETs), and Access Points (APs). Access network is the 1083 fixed network infrastructure forming the back-end of the 1084 architecture. Wireless MANETs are constructed by moving vehicles 1085 forming the front-end of the architecture. APs is the IEEE 802.11 1086 WLAN infrastructure forming the interface between the front-end and 1087 back-end of the architecture. 1089 For AAA services, the proposed architecture uses a Kerberos 1090 authentication model that authenticates vehicles at the entry point 1091 with the AP and also authorizes them to the access of various 1092 services. Since vehicles are authenticated by a Kerberos 1093 Authentication Server (AS) only once, the proposed security scheme 1094 can minimize the load on the AS and reduce the delay imposed by layer 1095 2 using IEEE 802.11i. 1097 8.3. Key Observations 1099 The security for vehicular networks should provide vehicles with AAA 1100 services in an efficient way. It should consider not only horizontal 1101 handover, but also vertical handover since vehicles have multiple 1102 wireless interfaces. 1104 9. Standard Activities for Vehicular Networks 1106 This section surveys standard activities for vehicular networks in 1107 standards developing organizations. 1109 9.1. IEEE Guide for Wireless Access in Vehicular Environments (WAVE) - 1110 Architecture 1112 IEEE 1609 is a suite of standards for Wireless Access in Vehicular 1113 Environments (WAVE) developed in the IEEE Vehicular Technology 1114 Society (VTS). They define an architecture and a complementary 1115 standardized set of services and interfaces that collectively enable 1116 secure vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) 1117 wireless communications. 1119 IEEE 1609.0 provides a description of the WAVE system architecture 1120 and operations (called WAVE reference model) [WAVE-1609.0]. The 1121 reference model of a typical WAVE device includes two data plane 1122 protocol stacks (sharing a common lower stack at the data link and 1123 physical layers): (i) the standard Internet Protocol Version 6 (IPv6) 1124 and (ii) the WAVE Short Message Protocol (WSMP) designed for 1125 optimized operation in a wireless vehicular environment. WAVE Short 1126 Messages (WSM) may be sent on any channel. IP traffic is only 1127 allowed on service channels (SCHs), so as to offload high-volume IP 1128 traffic from the control channel (CCH). 1130 The Layer 2 protocol stack distinguishes between the two upper stacks 1131 by the Ethertype field. Ethertype is a 2-octet field in the Logical 1132 Link Control (LLC) header, used to identify the networking protocol 1133 to be employed above the LLC protocol. In particular, it specifies 1134 the use of two Ethertype values (i.e., two networking protocols), 1135 such as IPv6 and WSMP. 1137 Regarding the upper layers, while WAVE communications use standard 1138 port numbers for IPv6-based protocols (e.g., TCP, UDP), they use a 1139 Provider Service Identifier (PSID) as an identifier in the context of 1140 WSMP. 1142 9.2. IEEE Standard for Wireless Access in Vehicular Environments (WAVE) 1143 - Networking Services 1145 IEEE 1609.3 defines services operating at the network and transport 1146 layers, in support of wireless connectivity among vehicle-based 1147 devices, and between fixed roadside devices and vehicle-based devices 1148 using the 5.9 GHz Dedicated Short-Range Communications/Wireless 1149 Access in Vehicular Environments (DSRC/WAVE) mode [WAVE-1609.3]. 1151 WAVE Networking Services represent layer 3 (networking) and layer 4 1152 (transport) of the OSI communications stack. The purpose is then to 1153 provide addressing and routing services within a WAVE system, 1154 enabling multiple stacks of upper layers above WAVE Networking 1155 Services and multiple lower layers beneath WAVE Networking Services. 1156 Upper layer support includes in-vehicle applications offering safety 1157 and convenience to users. 1159 The WAVE standards support IPv6. IPv6 was selected over IPv4 because 1160 IPv6 is expected to be a viable protocol into the foreseeable future. 1161 Although not described in the WAVE standards, IPv4 has been tunnelled 1162 over IPv6 in some WAVE trials. 1164 The document provides requirements for IPv6 configuration, in 1165 particular for the address setting. It specifies the details of the 1166 different service primitives, among which is the WAVE Routing 1167 Advertisement (WRA), part of the WAVE Service Advertisement (WSA). 1168 When present, the WRA provides information about infrastructure 1169 internetwork connectivity, allowing receiving devices to be 1170 configured to participate in the advertised IPv6 network. For 1171 example, an RSU can broadcast in the WRA portion of its WSA all the 1172 information necessary for an OBU to access an application-service 1173 available over IPv6 through the RSU as a router. This feature 1174 removes the need for an IPv6 Router Advertisement message, which are 1175 based on ICMPv6. 1177 9.3. ETSI Intelligent Transport Systems: Transmission of IPv6 Packets 1178 over GeoNetworking Protocols 1180 ETSI published a standard specifing the transmission of IPv6 packets 1181 over the ETSI GeoNetworking (GN) protocol [ETSI-GeoNetworking] 1182 [ETSI-GeoNetwork-IPv6]. IPv6 packet transmission over GN is defined 1183 in ETSI EN 302 636-6-1 [ETSI-GeoNetwork-IPv6] using a protocol 1184 adaptation sub-layer called "GeoNetworking to IPv6 Adaptation Sub- 1185 Layer (GN6ASL)". It enables an ITS station (ITS-S) running the GN 1186 protocol and an IPv6-compliant protocol layer to: (i) exchange IPv6 1187 packets with other ITS-S; (ii) acquire globally routable IPv6 unicast 1188 addresses and communicate with any IPv6 host located in the Internet 1189 by having the direct connectivity to the Internet or via other relay 1190 ITS stations; (iii) perform operations as a Mobile Router for network 1191 mobility [RFC3963]. 1193 The document introduces three types of virtual link, the first one 1194 providing symmetric reachability by means of stable geographically 1195 scoped boundaries and two others that can be used when the dynamic 1196 definition of the broadcast domain is required. The combination of 1197 these three types of virtual link in the same station allows running 1198 the IPv6 ND protocol including Stateless Address Autoconfiguration 1199 (SLAAC) [RFC4862] as well as distributing other IPv6 link-local 1200 multicast traffic and, at the same time, reaching nodes that are 1201 outside specific geographic boundaries. The IPv6 virtual link types 1202 are provided by the GN6ASL to IPv6 in the form of virtual network 1203 interfaces. 1205 The document also describes how to support bridging on top of the 1206 GN6ASL, how IPv6 packets are encapsulated IN GN packets and 1207 delivered, as well as the support of IPv6 multicast and anycast 1208 traffic, and neighbor discovery. For latency reasons, the standard 1209 strongly recommends to use SLAAC for the address configuration. 1211 Finally, the document includes the required operations to support the 1212 change of pseudonym, e.g., changing IPv6 addresses when the GN 1213 address is changed, in order to prevent attackers from tracking the 1214 ITS-S. 1216 9.4. ISO Intelligent Transport Systems: Communications Access for Land 1217 Mobiles (CALM) Using IPv6 Networking 1219 ISO published a standard specifying the IPv6 network protocols and 1220 services [ISO-ITS-IPv6]. These services are necessary to support the 1221 global reachability of ITS-S, the continuous Internet connectivity 1222 for ITS-S, and the handover functionality required to maintain such 1223 connectivity. This functionality also allows legacy devices to 1224 effectively use an ITS-S as an access router to connect to the 1225 Internet. Essentially, this specification describes how IPv6 is 1226 configured to support ITS-S and provides the associated management 1227 functionality. 1229 The requirements apply to all types of nodes implementing IPv6: 1230 personal, vehicle, roadside, or central node. The standard defines 1231 IPv6 functional modules that are necessary in an IPv6 ITS-S, covering 1232 IPv6 forwarding, interface between IPv6 and lower layers (e.g., LAN 1233 interface), mobility management, and IPv6 security. It defines the 1234 mechanisms to be used to configure the IPv6 address for static nodes 1235 as well as for mobile nodes, while maintaining the addressing 1236 reachability from the Internet. 1238 10. The Use Cases of Vehicular Networking 1240 This section surveys the use cases of IP-based vehicular networking 1241 for ITS. 1243 10.1. The Use Cases of V2I Networking 1245 The use cases of V2I networking include navigation service, fuel- 1246 efficient speed recommendation service, and accident notification 1247 service. 1249 A navigation service, such as Self-Adaptive Interactive Navigation 1250 Tool (called SAINT) [SAINT], using V2I networking interacts with TCC 1251 for the global road traffic optimization and can guide individual 1252 vehicles for appropriate navigation paths in real time. The enhanced 1253 SAINT (called SAINT+) [SAINTplus] can give the fast moving paths for 1254 emergency vehicles (e.g., ambulance and fire engine) toward accident 1255 spots while providing efficient detour paths to vehicles around the 1256 accidents spots. 1258 The emergency communication between accident vehicles (or emergency 1259 vehicles) and TCC can be performed via either RSU or 4G-LTE networks. 1260 The First Responder Network Authority (FirstNet) [FirstNet] is 1261 provided by the US government to establish, operate, and maintain an 1262 interoperable public safety broadband network for safety and security 1263 network services, such as emergency calls. The construction of the 1264 nationwide FirstNet network requires each state in the US to have a 1265 Radio Access Network (RAN) that will connect to FirstNet's network 1266 core. The current RAN is mainly constructed by 4G-LTE, but DSRC- 1267 based vehicular networks can be used in near future. 1269 A pedestrian protection service, such as Safety-Aware Navigation 1270 Application (called SANA) [SANA], using V2I networking can reduce the 1271 collision of a pedestrian and a vehicle, which have a smartphone, in 1272 a road network. Vehicles and pedestrians can communicate with each 1273 other via an RSU that delivers scheduling information for wireless 1274 communication to save the smartphones' battery. 1276 10.2. The Use Cases of V2V Networking 1278 The use cases of V2V networking include context-aware navigator for 1279 driving safety, cooperative adaptive cruise control in an urban 1280 roadway, and platooning in a highway. These are three techniques 1281 that will be important elements for self-driving. 1283 Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers 1284 to drive safely by letting the drivers recognize dangerous obstacles 1285 and situations. That is, CASD navigator displays obstables or 1286 neighboring vehicles relevant to possible collisions in real-time 1287 through V2V networking. CASD provides vehicles with a class-based 1288 automatic safety action plan, which considers three situations, such 1289 as the Line-of-Sight unsafe, Non-Line-of-Sight unsafe and safe 1290 situations. This action plan can be performed among vehicles through 1291 V2V networking. 1293 Cooperative Adaptive Cruise Control (CACC) [CA-Cuise-Control] helps 1294 vehicles to adapt their speed autonomously through V2V communication 1295 among vehicles according to the mobility of their predecessor and 1296 successor vehicles in an urban roadway or a highway. CACC can help 1297 adjacent vehicles to efficiently adjust their speed in a cascade way 1298 through V2V networking. 1300 Platooning [Truck-Platooning] allows a series of vehicles (e.g., 1301 trucks) to move together with a very short inter-distance. Trucks 1302 can use V2V communication in addition to forward sensors in order to 1303 maintain constant clearance between two consecutive vehicles at very 1304 short gaps (from 3 meters to 10 meters). This platooning can 1305 maximize the throughput of vehicular traffic in a highway and reduce 1306 the gas consumption because the leading vehicle can help the 1307 following vehicles to experience less air resistance. 1309 11. Summary and Analysis 1311 This document surveyed state-of-the-arts technologies for IP-based 1312 vehicular networks, such as IP address autoconfiguration, vehicular 1313 network architecture, vehicular network routing, and mobility 1314 management. 1316 Through this survey, it is learned that IPv6-based vehicular 1317 networking can be well-aligned with IEEE WAVE standards for various 1318 vehicular network applications, such as driving safety, efficient 1319 driving, and entertainment. However, since the IEEE WAVE standards 1320 do not recommend to use the IPv6 ND protocol for the communication 1321 efficiency under high-speed mobility, it is necessary to adapt the ND 1322 for vehicular networks with such high-speed mobility. 1324 The concept of a link in IPv6 does not match that of a link in VANET 1325 because of the physical separation of communication ranges of 1326 vehicles in a connected VANET. That is, in a linear topology of 1327 three vehicles (Vehicle-1, Vehicle-2, and Vehicle-3), Vehicle-1 and 1328 Vehicle-2 can communicate directly with each other. Vehicle-2 and 1329 Vehicle-3 can communicate directly with each other. However, 1330 Vehicle-1 and Vehicle-3 cannot communicate directly with each other 1331 due to the out-of-communication range. For the link in IPv6, all of 1332 three vehicles are on a link, so they can communicate directly with 1333 each other. On the other hand, in VANET, this on-link communication 1334 concept is not valid in VANET. Thus, the IPv6 ND should be extended 1335 to support this multi-link subnet of a connected VANET through either 1336 ND proxy or VANET routing. 1338 For IP-based networking, IP address autoconfiguration is a 1339 prerequisite function. Since vehicles can communicate intermittently 1340 with TCC via RSUs through V2I communications, TCC can play a role of 1341 a DHCP server to allocate unique IPv6 addresses to the vehicles. 1342 This centralized address allocation can remove the delay of the DAD 1343 procedure for testing the uniqueness of IPv6 addresses. 1345 For routing and mobility management, most of vehicles are equipped 1346 with a GPS navigator as a dedicated navigation system or a smartphone 1347 App. With this GPS navigator, vehicles can share their current 1348 position and trajectory (i.e., navigation path) with TCC. TCC can 1349 predict the future positions of the vehicles with their mobility 1350 information (i.e., the current position, speed, direction, and 1351 trajectory). With the prediction of the vehicle mobility, TCC 1352 supports RSUs to perform data packet routing and handover 1353 proactively. 1355 12. Security Considerations 1357 Security and privacy are important aspects in vehicular networks. 1358 Only valid vehicles should be allowed to participate in vehicular 1359 networking. Vehicle Identification Number (VIN) and user certificate 1360 can be used to authenticate a vehicle and user through road 1361 infrastructure, such as Road-Side Unit (RSU) connected to an 1362 authentication server in Traffic Control Center (TCC). 1364 13. Contributors 1366 IPWAVE is a group effort. The following people actively contributed 1367 to the survey text: Rex Buddenberg (Naval Postgraduate School), 1368 Thierry Ernst (YoGoKo), Bokor Laszlo (Budapest University of 1369 Technology and Economics), Jose Santa Lozanoi (Universidad of 1370 Murcia), and Richard Roy (MIT). 1372 14. Acknowledgements 1374 This work was supported by Basic Science Research Program through the 1375 National Research Foundation of Korea (NRF) funded by the Ministry of 1376 Education (2017R1B1A1B03035885). This work was supported in part by 1377 the Global Research Laboratory Program (2013K1A1A2A02078326) through 1378 NRF and the DGIST Research and Development Program (CPS Global 1379 Center) funded by the Ministry of Science, ICT & Future Planning. 1380 This work was supported in part by the French research project 1381 DataTweet (ANR-13-INFR-0008) and in part by the HIGHTS project funded 1382 by the European Commission I (636537-H2020). 1384 15. References 1386 15.1. Normative References 1388 [RFC2119] Bradner, S., "Key words for use in 1389 RFCs to Indicate Requirement Levels", 1390 BCP 14, RFC 2119, March 1997. 1392 [RFC5889] Baccelli, E. and M. Townsley, "IP 1393 Addressing Model in Ad Hoc Networks", 1394 RFC 5889, September 2010. 1396 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., 1397 Patil, B., and F. Xia, "Fast Handovers 1398 for Proxy Mobile IPv6", RFC 5949, 1399 September 2010. 1401 [RFC3963] Devarapalli, V., Wakikawa, R., 1402 Petrescu, A., and P. Thubert, "Network 1403 Mobility (NEMO) Basic Support 1404 Protocol", RFC 3963, January 2005. 1406 [RFC4862] Thomson, S., Narten, T., and T. 1407 Jinmei, "IPv6 Stateless Address 1408 Autoconfiguration", RFC 4862, 1409 September 2007. 1411 15.2. Informative References 1413 [Address-Autoconf] Fazio, M., Palazzi, C., Das, S., and 1414 M. Gerla, "Automatic IP Address 1415 Configuration in VANETs", 1416 ACM International Workshop on 1417 Vehicular Inter-Networking, 1418 September 2016. 1420 [Address-Assignment] Kato, T., Kadowaki, K., Koita, T., and 1421 K. Sato, "Routing and Address 1422 Assignment using Lane/Position 1423 Information in a Vehicular Ad-hoc 1424 Network", IEEE Asia-Pacific Services 1425 Computing Conference, December 2008. 1427 [GeoSAC] Baldessari, R., Bernardos, C., and M. 1428 Calderon, "GeoSAC - Scalable Address 1429 Autoconfiguration for VANET Using 1430 Geographic Networking Concepts", 1431 IEEE International Symposium on 1432 Personal, Indoor and Mobile Radio 1433 Communications, September 2008. 1435 [Identities-Management] Wetterwald, M., Hrizi, F., and P. 1436 Cataldi, "Cross-layer Identities 1437 Management in ITS Stations", The 10th 1438 International Conference on ITS 1439 Telecommunications, November 2010. 1441 [VIP-WAVE] Cespedes, S., Lu, N., and X. Shen, 1442 "VIP-WAVE: On the Feasibility of IP 1443 Communications in 802.11p Vehicular 1444 Networks", IEEE Transactions on 1445 Intelligent Transportation Systems, 1446 March 2013. 1448 [IPv6-WAVE] Baccelli, E., Clausen, T., and R. 1449 Wakikawa, "IPv6 Operation for WAVE - 1450 Wireless Access in Vehicular 1451 Environments", IEEE Vehicular 1452 Networking Conference, December 2010. 1454 [Vehicular-Network-Framework] Jemaa, I., Shagdar, O., and T. Ernst, 1455 "A Framework for IP and non-IP 1456 Multicast Services for Vehicular 1457 Networks", Third International 1458 Conference on the Network of the 1459 Future, November 2012. 1461 [Joint-IP-Networking] Petrescu, A., Boc, M., and C. Ibars, 1462 "Joint IP Networking and Radio 1463 Architecture for Vehicular Networks", 1464 11th International Conference on ITS 1465 Telecommunications, August 2011. 1467 [FleetNet] Bechler, M., Franz, W., and L. Wolf, 1468 "Mobile Internet Access in FleetNet", 1469 13th Fachtagung Kommunikation in 1470 verteilten Systemen, February 2001. 1472 [Vehicular-DTN] Soares, V., Farahmand, F., and J. 1473 Rodrigues, "A Layered Architecture for 1474 Vehicular Delay-Tolerant Networks", 1475 IEEE Symposium on Computers and 1476 Communications, July 2009. 1478 [IP-Passing-Protocol] Chen, Y., Hsu, C., and W. Yi, "An IP 1479 Passing Protocol for Vehicular Ad Hoc 1480 Networks with Network Fragmentation", 1481 Elsevier Computers & Mathematics with 1482 Applications, January 2012. 1484 [VANET-Geo-Routing] Tsukada, M., Jemaa, I., Menouar, H., 1485 Zhang, W., Goleva, M., and T. Ernst, 1486 "Experimental Evaluation for IPv6 over 1487 VANET Geographic Routing", 1488 IEEE International Wireless 1489 Communications and Mobile Computing 1490 Conference, June 2010. 1492 [H-DMM] Nguyen, T. and C. Bonnet, "A Hybrid 1493 Centralized-Distributed Mobility 1494 Management for Supporting Highly 1495 Mobile Users", IEEE International 1496 Conference on Communications, 1497 June 2015. 1499 [H-NEMO] Nguyen, T. and C. Bonnet, "A Hybrid 1500 Centralized-Distributed Mobility 1501 Management Architecture for Network 1502 Mobility", IEEE International 1503 Symposium on a World of Wireless, 1504 Mobile and Multimedia Networks, 1505 June 2015. 1507 [NEMO-LMS] Soto, I., Bernardos, C., Calderon, M., 1508 Banchs, A., and A. Azcorra, "NEMO- 1509 Enabled Localized Mobility Support for 1510 Internet Access in Automotive 1511 Scenarios", IEEE Communications 1512 Magazine, May 2009. 1514 [NEMO-VANET] Chen, Y., Hsu, C., and C. Cheng, 1515 "Network Mobility Protocol for 1516 Vehicular Ad Hoc Networks", 1517 Wiley International Journal of 1518 Communication Systems, November 2014. 1520 [PMIPv6-NEMO-Analysis] Lee, J., Ernst, T., and N. 1521 Chilamkurti, "Performance Analysis of 1522 PMIPv6-Based Network MObility for 1523 Intelligent Transportation Systems", 1524 IEEE Transactions on Vehicular 1525 Technology, January 2012. 1527 [Vehicular-Network-MM] Peng, Y. and J. Chang, "A Novel 1528 Mobility Management Scheme for 1529 Integration of Vehicular Ad Hoc 1530 Networks and Fixed IP Networks", 1531 Springer Mobile Networks and 1532 Applications, February 2010. 1534 [SDN-DMM] Nguyen, T., Bonnet, C., and J. Harri, 1535 "SDN-based Distributed Mobility 1536 Management for 5G Networks", 1537 IEEE Wireless Communications and 1538 Networking Conference, April 2016. 1540 [Vehicular-IP-MM] Cespedes, S., Shen, X., and C. Lazo, 1541 "IP Mobility Management for Vehicular 1542 Communication Networks: Challenges and 1543 Solutions", IEEE Communications 1544 Magazine, May 2011. 1546 [Securing-VCOMM] Fernandez, P., Santa, J., Bernal, F., 1547 and A. Skarmeta, "Securing Vehicular 1548 IPv6 Communications", 1549 IEEE Transactions on Dependable and 1550 Secure Computing, January 2016. 1552 [VNET-AAA] Moustafa, H., Bourdon, G., and Y. 1553 Gourhant, "Providing Authentication 1554 and Access Control in Vehicular 1555 Network Environment", IFIP TC- 1556 11 International Information Security 1557 Conference, May 2006. 1559 [IEEE-802.11p] IEEE 802.11 Working Group, "Part 11: 1560 Wireless LAN Medium Access Control 1561 (MAC) and Physical Layer (PHY) 1562 Specifications - Amendment 6: Wireless 1563 Access in Vehicular Environments", 1564 IEEE Std 802.11p-2010, June 2010. 1566 [IEEE-802.11-OCB] IEEE 802.11 Working Group, "Part 11: 1567 Wireless LAN Medium Access Control 1568 (MAC) and Physical Layer (PHY) 1569 Specifications", IEEE Std 802.11-2012, 1570 February 2012. 1572 [WAVE-1609.0] IEEE 1609 Working Group, "IEEE Guide 1573 for Wireless Access in Vehicular 1574 Environments (WAVE) - Architecture", 1575 IEEE Std 1609.0-2013, March 2014. 1577 [WAVE-1609.2] IEEE 1609 Working Group, "IEEE 1578 Standard for Wireless Access in 1579 Vehicular Environments - Security 1580 Services for Applications and 1581 Management Messages", IEEE Std 1609.2- 1582 2016, March 2016. 1584 [WAVE-1609.3] IEEE 1609 Working Group, "IEEE 1585 Standard for Wireless Access in 1586 Vehicular Environments (WAVE) - 1587 Networking Services", IEEE Std 1609.3- 1588 2016, April 2016. 1590 [WAVE-1609.4] IEEE 1609 Working Group, "IEEE 1591 Standard for Wireless Access in 1592 Vehicular Environments (WAVE) - Multi- 1593 Channel Operation", IEEE Std 1609.4- 1594 2016, March 2016. 1596 [ETSI-GeoNetworking] ETSI Technical Committee Intelligent 1597 Transport Systems, "Intelligent 1598 Transport Systems (ITS); Vehicular 1599 Communications; GeoNetworking; Part 4: 1600 Geographical addressing and forwarding 1601 for point-to-point and point-to- 1602 multipoint communications; Sub-part 1: 1603 Media-Independent Functionality", 1604 ETSI EN 302 636-4-1, May 2014. 1606 [ETSI-GeoNetwork-IPv6] ETSI Technical Committee Intelligent 1607 Transport Systems, "Intelligent 1608 Transport Systems (ITS); Vehicular 1609 Communications; GeoNetworking; Part 6: 1610 Internet Integration; Sub-part 1: 1611 Transmission of IPv6 Packets over 1612 GeoNetworking Protocols", ETSI EN 302 1613 636-6-1, October 2013. 1615 [ISO-ITS-IPv6] ISO/TC 204, "Intelligent Transport 1616 Systems - Communications Access for 1617 Land Mobiles (CALM) - IPv6 1618 Networking", ISO 21210:2012, 1619 June 2012. 1621 [SAINT] Jeong, J., Jeong, H., Lee, E., Oh, T., 1622 and D. Du, "SAINT: Self-Adaptive 1623 Interactive Navigation Tool for Cloud- 1624 Based Vehicular Traffic Optimization", 1625 IEEE Transactions on Vehicular 1626 Technology, Vol. 65, No. 6, June 2016. 1628 [SAINTplus] Shen, Y., Lee, J., Jeong, H., Jeong, 1629 J., Lee, E., and D. Du, "SAINT+: Self- 1630 Adaptive Interactive Navigation Tool+ 1631 for Emergency Service Delivery 1632 Optimization", IEEE Transactions on 1633 Intelligent Transportation Systems, 1634 June 2017. 1636 [SANA] Hwang, T. and J. Jeong, "SANA: Safety- 1637 Aware Navigation Application for 1638 Pedestrian Protection in Vehicular 1639 Networks", Springer Lecture Notes in 1640 Computer Science (LNCS), Vol. 9502, 1641 December 2015. 1643 [FirstNet] U.S. National Telecommunications and 1644 Information Administration (NTIA), 1645 "First Responder Network Authority 1646 (FirstNet)", [Online] 1647 Available: https://www.firstnet.gov/, 1648 2012. 1650 [CASD] Shen, Y., Jeong, J., Oh, T., and S. 1651 Son, "CASD: A Framework of Context- 1652 Awareness Safety Driving in Vehicular 1653 Networks", International Workshop on 1654 Device Centric Cloud (DC2), 1655 March 2016. 1657 [CA-Cuise-Control] California Partners for Advanced 1658 Transportation Technology (PATH), 1659 "Cooperative Adaptive Cruise Control", 1660 [Online] Available: http:// 1661 www.path.berkeley.edu/research/ 1662 automated-and-connected-vehicles/ 1663 cooperative-adaptive-cruise-control, 1664 2017. 1666 [Truck-Platooning] California Partners for Advanced 1667 Transportation Technology (PATH), 1668 "Automated Truck Platooning", [Online] 1669 Available: http:// 1670 www.path.berkeley.edu/research/ 1671 automated-and-connected-vehicles/ 1672 truck-platooning, 2017. 1674 Authors' Addresses 1676 Jaehoon Paul Jeong 1677 Department of Software 1678 Sungkyunkwan University 1679 2066 Seobu-Ro, Jangan-Gu 1680 Suwon, Gyeonggi-Do 440-746 1681 Republic of Korea 1683 Phone: +82 31 299 4957 1684 Fax: +82 31 290 7996 1685 EMail: pauljeong@skku.edu 1686 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1688 Sandra Cespedes 1689 Department of Electrical Engineering 1690 Universidad de Chile 1691 Av. Tupper 2007, Of. 504 1692 Santiago, 8370451 1693 Chile 1695 Phone: +56 2 29784093 1696 EMail: scespede@niclabs.cl 1698 Nabil Benamar 1699 Department of Computer Sciences 1700 High School of Technology of Meknes 1701 Moulay Ismail University 1702 Morocco 1704 Phone: +212 6 70 83 22 36 1705 EMail: benamar73@gmail.com 1707 Jerome Haerri 1708 Communication Systems Department 1709 EURECOM 1710 Sophia-Antipolis 1711 France 1713 Phone: +33 4 93 00 81 34 1714 EMail: jerome.haerri@eurecom.fr 1715 Michelle Wetterwald 1716 FBConsulting 1717 21, Route de Luxembourg 1718 Wasserbillig, Luxembourg L-6633 1719 Luxembourg 1721 EMail: Michelle.Wetterwald@gmail.com