idnits 2.17.1 draft-petrescu-its-cacc-sdo-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 18, 2016) is 2901 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-manet-aodvv2-14 == Outdated reference: A later version (-06) exists of draft-petrescu-ipv6-over-80211p-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Petrescu, Ed. 3 Internet-Draft CEA, LIST 4 Intended status: Informational J. Huang 5 Expires: October 20, 2016 Huawei Technologies 6 T. Ernst 7 Mines ParisTech 8 R. Buddenberg 9 Retired 10 C. Perkins 11 Futurewei 12 April 18, 2016 14 Cooperative Adaptive Cruise Control and Platooning at SDOs and Gap 15 Analysis 16 draft-petrescu-its-cacc-sdo-05.txt 18 Abstract 20 This document describes the use-cases of Cooperative Adaptive Cruise 21 Control, and Platooning, as defined by several Standards Development 22 Organizations such as ETSI, IEEE P1609, SAE, 3GPP, ISO and FirstNet. 24 C-ACC and Platooning involve concepts of direct vehicle-to-vehicle, 25 and device-to-device communications, which are developed by 3GPP 26 following on work done within the METIS EU project. They are 27 illustrated very clearly in emergency settings such as FirstNet. 29 IP packets - instead of link-layer frames - are pertinent for C-ACC 30 and Platooning use-cases because applications for road safety such as 31 WAZE, iRezQ and Coyote (currently involving infrastructure) make use 32 of IP messages, and have proved successful in deployments. 33 Applications such as Sentinel operate directly between vehicles, but 34 currently use messages not carried over IP. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on October 20, 2016. 53 Copyright Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. ETSI ITS C-ACC and Platooning use-case and reqs . . . . . . . 7 73 4. The C-ACC Use of Protocols specified by IEEE 1609 Standards . 7 74 5. SAE perspective on C-ACC and Platooning . . . . . . . . . . . 8 75 6. 3GPP and EU projects using LTE Device-to-Device concepts . . 8 76 6.1. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 6.2. METIS . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 7. ISO perspective on V2V . . . . . . . . . . . . . . . . . . . 10 79 8. ISO-IEEE Harmonization . . . . . . . . . . . . . . . . . . . 11 80 9. V2V communications at ITU . . . . . . . . . . . . . . . . . . 12 81 10. ARIB and ITS Info-comm use of CACC and V2V concepts . . . . . 13 82 11. FirstNet EMS use of LTE and IP in V2I2V . . . . . . . . . . . 13 83 12. Internet apps: WAZE, iRezQ, Coyote, Sentinel . . . . . . . . 14 84 13. Car manufacturer labels with V2V features . . . . . . . . . . 14 85 14. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 15 86 14.1. Neighbor Discovery protocol . . . . . . . . . . . . . . 15 87 14.2. Mobile IP protocol . . . . . . . . . . . . . . . . . . . 15 88 14.3. AODVv2 protocol . . . . . . . . . . . . . . . . . . . . 16 89 15. Security Considerations . . . . . . . . . . . . . . . . . . . 16 90 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 91 17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 92 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 18.1. Normative References . . . . . . . . . . . . . . . . . . 17 94 18.2. Informative References . . . . . . . . . . . . . . . . . 17 95 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 19 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 98 1. Introduction 100 Cooperative Adaptive Cruise Control (C-ACC) and Platooning are two 101 use-cases described recently by other Standards Development 102 Organizations (SDOs). C-ACC [CACC-def] is understood as a automated 103 formation of chains of automobiles following each other at constant 104 speed. This offers more comfort for human drivers on long journeys 105 on straight roads. 107 Simple 'cruise control' was the automation of speed maintenance at a 108 single automobile (increase torque if uphill, smoothly brake 109 downhill, such as to maintain constant speed). The term "Adaptive 110 Cruise Control" was used earlier in the literature [ACC-def]. The 111 concept of C-ACC aims at the same level of automation but in a 112 cooperative manner between several vehicles: while in CC mode, when a 113 vehicle in front slowly decelerates, this vehicle will also do, such 114 as to maintain distance, and relieve driver from taking control over. 116 Platooning is another concept related to larger vehicles following 117 each other. The goal in this case is more than just comfort - large 118 gains are expected in terms of gas consumption: when large vehicles 119 can follow each other at small distance the air-drag is much lower, 120 reducing gas consumption, tyre use, and more. 122 Both C-ACC and Platooning must rely on wireless communications 123 between vehicles (in addition to more immediate indicators like 124 signal echoes - radars and cameras). These exchanges may happen in a 125 direct manner (direct vehicle to vehicle communications) or with 126 assistance from a fixed communication infrastructure (vehicle-to- 127 infrastructure-to-vehicle communications). 129 This document presents the V2V-based C-ACC and Platooning use-cases 130 as described at ETSI [ETSI-CACC], SAE [SAE-V2V], ISO [ISO-CACC], 3GPP 131 [GPP-TR-22-885], ITU [ITU-V2V], ITS Info-communications Forum of 132 Japan [its-infocomm-CACC] and more. These use-cases are widely 133 accepted as examples of Vehicle-to-Vehicle applications. 135 In emergency settings the concepts of direct vehicle-to-vehicle 136 communications are of paramount importance. FirstNet, as described 137 later in this document, covers V2V, V2I and V2I2V communication 138 needs, together with strong security requirements. 140 In the market, several systems for vehicular communications have 141 demonstrated a number of benefits in the context of vehicle-to- 142 vehicle communications. 144 o The Sentinel system is used between vehicles to warn each other 145 about approach; 147 o WAZE on smartphones created a community where users influence 148 others about the route choice; 150 o iRezQ and Coyote communicate between vehicles, via infrastructure, 151 about route risks. 153 In [I-D.petrescu-ipv6-over-80211p] the use of IPv6 over 802.11p is 154 described. This link layer is potentially to be used in direct 155 vehicle-to-vehicle communications, among several other possibilities. 157 2. Terminology 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in RFC 2119 [RFC2119]. 163 3GPP: Third Generation Partnership Project. 165 3G: Third Generation. 167 4G: Fourth Generation. 169 5G: Fifth Generation of mobile networks. 171 apps: applications. 173 AODV: Ad-hoc On-demand Distance Vector. 175 ARIB: Association of Radio Industries and Businesses. 177 BSS: Basic Service Set. 179 C-ACC: Cooperative Adaptive Cruise Control. 181 CAM: Cooperative Awareness Message. 183 CC: Cruise Control. 185 CEN: European Committee for Standardizatin (Comite europeen de 186 normalisation, fr.) 188 DeNM: Decentralized Environmental Notification Message. 190 DMM: Distributed Mobility Management. 192 DSRC: Dedicated Short Range Communications, as referenced in the 193 United States FCC Report and Order for the frequency allocation for 194 5.9GHz band in North America, which refers to "DSRC" as the ASTM 195 (earlier "American Society for Testing and Materials") standard 196 "E2213". Other interpretations of "DSRC" include the DSRC standard 197 developed in ISO TC204 WG17 and CEN TC278 which uses a different 198 frequency spectrum than the one used in North America. 200 E2E: end-to-end. 202 EMS: Emergency and Medical System providers. 204 EPC: Evolved Packet Core. 206 ETSI: European Telecommunications Standards Institute. 208 E-UTRAN: Evolved Universal Terrestrial Radio Access Network. 210 EU: European Union. 212 FAST: fast. 214 FCC: Federal Communications Commision. 216 FNTP: Fast Networking and Transport layer Protocol. 218 FSAP: Fast Service Advertisement Protocol. 220 I2V: Infrastructure to Vehicle. 222 ICT: Information and Communication Technologies. 224 IEEE: Institute of Electrical and Electronics Engineers. 226 IoT: Internet of Things. 228 IP: Internet Protocol. 230 IPv6: Internet Protocol version 6. 232 IPTV: Internet Protocol Television 234 ISO: International Organization for Standardization. 236 ITS: Intelligent Transportation Systems. 238 ITS-G5: ITS Gigahertz Five. 240 ITU: International Telecommunication Union. 242 ITU-T: Telecommunication Standardization Sector of the International 243 Telecommunication Union. 245 IVC-RVC: 247 LiFi: Light Fidelity. 249 LTE : Long-Term Evolution. 251 METIS: Mobile and wireless communications Enablers for Twenty-twenty 252 (2020) Information Society. 254 OBU: On-Board Unit. 256 OCB: Outside the Context of a BSS identifier. 258 PHY: physical layer. 260 ProSe: Proximity Service. 262 PSAP: Public Safety Answering Points. 264 RA: Router Advertisement. 266 SAE: Society of Automotive Engineers. 268 SDO: Standards Development Organization. 270 SG: Study Group. 272 TC: Technical Committee. 274 TR: Technical Report. 276 UE: User Equipment. 278 US: United States. 280 V2V: Vehicle-to-Vehicle communications. 282 V2X: Vehicle-to-'other' communications. E.g. Vehicle-to- 283 Infrastructure (V2I), Vehicle-to-Pedestrian (V2P), Vehicle-to- 284 Nomadic[device] (V2N), Vehicle-to-Device (V2D) and more. 286 V2I2V: Vehicle to Infrastructure to Vehicle. 288 WAVE: Wireless Access for Vehicular Environments. 290 WG1: Work Group 1. 292 WiFi: Wireless Fidelity. 294 WLAN: Wireless Local Area Network. 296 3. ETSI ITS C-ACC and Platooning use-case and reqs 298 ETSI Technical Committee Intelligent Transportation Systems (ETSI TC 299 ITS) is responsible for the development and maintenance of standards, 300 specifications and other reports on the implementation of V2V 301 communications in Cooperative ITS. Its scope extends from the 302 wireless access (excluding issues in radio frequency) to generic 303 services and corresponding applications. Security and tests 304 specifications are also covered. This responsibility is reflected in 305 the organization with five working groups that make up the committee. 306 Among them, WG1 is responsible of the facilities and applications 307 needs. 309 Under the EU Mandate M/453, TC ITS has developed a minimum set of 310 standards (Release 1) for systems interoperability during initial 311 deployment. The list of standards and specifications are provided in 312 the publicly available report ETSI TR 101 607. A second release of 313 the standards is being prepared. It should support more complex use 314 cases, possible integration with other technologies as well as a more 315 elaborate consideration of access networks other than the ITS-G5 316 (European profile of IEEE 802.11p). The TC ITS WG1 is currently 317 working on two separate work items for pre-standardization studies on 318 C-ACC (DTR/ITS-00164) and Platooning (DTR/ITS-00156). The scope of 319 the target technical reports is to describe the relevant use cases 320 that could be enabled by Cooperative ITS, to survey the existing 321 related standards and to identify what new features and standards are 322 needed to support these use cases. 324 The C-ACC definition in TR 103 299 will soon be made public. 326 4. The C-ACC Use of Protocols specified by IEEE 1609 Standards 328 The C-ACC interacts with the presentation layer services which in 329 turn use the communication protocols specified in IEEE 1609 330 standards. 332 One perspective from IEEE P1609 is that Cooperative Adaptive Cruise 333 Control (CACC) represents an "application". An application is 334 typically software whose communication needs are situated at the 335 upper layers of a communication stack - e.g. the Application Layer. 337 As such it is little relevant to IEEE P1609; P1609 is concerned more 338 with physical, data-link and network communication layers. On 339 another hand, a perspective well considered in IEEE P1609 is that 340 C-ACC and Platooning may be more relevant to the Society of 341 Automotive Engineers. 343 5. SAE perspective on C-ACC and Platooning 345 The Society of Automotive Engineers (SAE) concerns itself with data 346 exchanges and host system requirements for applications. The SAE 347 DSRC Technical Committee (DSRC: Dedicated Short-Range Communications) 348 is working on C-ACC within the Cooperative Vehicle Task Force. In 349 addition, the SAE On-Road Vehicle Automation Committee is working on 350 a use-case relevant to C-ACC towards realization of a reference 351 architecture. 353 In addition to C-ACC, SAE is completing performance requirements for 354 V2V Safety Communications to profile a probable US-mandated 355 implementation. The concept is that a vehicle would send a link- 356 layer message set (Basic Safety Message, plus path history and path 357 prediction extensions) to a host vehicle to enable the host vehicle 358 to use the transmitted information in a driver warning or alert 359 algorithm. Because it is used for safety, it is of paramount 360 importance that the messages are authenticated through a Security 361 Credential Management System. 363 The SAE DSRC TC activities are in cooperative agreement to ETSI ITS 364 WG1, as there are information exchanges between the two bodies 365 [SAE-V2V]. 367 6. 3GPP and EU projects using LTE Device-to-Device concepts 369 6.1. 3GPP 371 The Proximity Service (ProSe) allows a UE to discover and communicate 372 with other UEs that are in proximity directly or with the network 373 assistance. This may also be called as Device-to-Device (D2D) 374 communication. ProSe is intended for purposes such as public 375 security, network offloading, etc [GPP-TR-22-803]. 377 The ProSe Communication path could use E-UTRAN or WLAN. In the case 378 of WLAN, only ProSe-assisted WLAN direct communication (i.e. when 379 ProSe assists with connection establishment management and service 380 continuity) is considered [GPP-TS-22-278]. 382 The work on ProSe is initiated in 3GPP Release 12. Some enhancements 383 are being added in Release 13, e.g. Restricted ProSe Discovery. 384 Some use cases are identified in [GPP-TR-22-803], but most of which 385 are intended for common mobile users, e.g. pedestrians, but not for 386 vehicles moving at high speed. The latency in ProSe communication 387 may be a problem for V2X. 389 ProSe does not support V2X communication until at least Release 14, 390 but it has some very good characteristics which makes it a good 391 candidate for V2X besides DSRC. ProSe communication does not have to 392 go through the EPC, which will significantly reduce the latency. 393 ProSe also supports group and broadcast communication by means of a 394 common communication path established between the UEs. 396 There are some efforts within 3GPP Release 14, trying to address V2X 397 communication. The efforts are proposed by experts in the industry, 398 and may be subject to change. These efforts include the following, 399 not an exhaustive list: 401 o To address the V2X use cases in 3GPP. Some use cases have been 402 defined by other SDOs, e.g. ETSI ITS; 3GPP can reference to them. 403 Requirements for V2X communication should also be considered, for 404 example network delay, packet loss rate, etc. [METIS-D1.1] 405 already propose some requirements, but those are intended for 406 future mobile network, which may be too critical for LTE. 408 o To address V2X applications and messages. The messages may 409 include message defined in SAE J2735, ETSI Cooperative Awareness 410 Message (CAM) and ETSI Decentralized Environmental Notification 411 Message (DeNM). The messages defined by different SDOs might be 412 similar to each other. 414 o Study of possibility to add enhancements to ProSe, and to make it 415 able to support and enhance DSRC. 417 o Study of using existing LTE technologies for unicast/multicast/ 418 broadcast communication. 420 [GPP-TR-22-885] studies many V2X services using LTE. These services 421 include V2V communication (e.g. Cooperative Adaptive Cruise Control, 422 Forwarding Collision Warning, etc), V2I/V2N communication (e.g. Road 423 Safety Services) and vehicle to pedestrian communication. The 424 services' pre-condition, service flow, post-condition, including some 425 network communication requirements, such as delay, messages frequency 426 and message size, are ayalyzed. 428 In [GPP-TR-22-885], Cooperative Adaptive Cruise Control (CACC) allows 429 a vehicle to join a group of CACC vehicles; the benefits are to 430 improve road congestion and fuel efficiency. Member vehicles of CACC 431 group should periodically broadcast messages including the CACC group 432 information, such as speed and gap policies, etc. If a vehicle 433 outside the group wants to join, it should send a request to the 434 group. If a member of the CACC group accepts the request, it should 435 send a confirm message and provide necessary distance gap; and 436 members of the group will update their group information. When a 437 member wants to leave the CACC group, it broadcasts a goodbye 438 message, and the driver once again assumes control of the vehicle. 440 6.2. METIS 442 METIS is co-funded by the European Commission as an Integrated 443 Project under the Seventh Framework Programme for research and 444 development (FP7). 446 METIS defines test cases and requirements of "Traffic safety and 447 efficiency", as depicted in [METIS-D1.1], which is intended for 5G in 448 2020 but may also be applicable for LTE and subsequent systems. 450 The use cases include: 452 1. Dangerous situation that can be avoided by means of V2V 453 communications. 455 2. Dangerous situation with vulnerable road users (i.e. pedestrians, 456 cyclists,...) that can be avoided by means of V2D communications. 457 "D" can denote any cellular device that the vulnerable road user 458 may carry (e.g. smart phone, tablet, sensor tag). 460 3. Assistance services that can improve traffic efficiency by means 461 of V2X communications, e.g. traffic sign recognition and green 462 light assistance. 464 4. Autonomous platooning increase traffic flow and reduce fuel 465 consumption and emissions. 467 5. Automated vehicles. 469 To support the above use cases, METIS works out the corresponding 470 network requirements. For instance, for some applications the E2E 471 latency must be within 5ms; other requirements include data rates for 472 various scenarios, service ranges in highway/rural/urban scenarios, 473 etc. 475 7. ISO perspective on V2V 477 The International Standards Organization's Technical Committee 204 478 "Intelligent transport systems" (ISO TC204, in short) has specified a 479 communication architecture known as the "ITS station reference 480 communication architecture" [ISO-21217]. This communication 481 architecture covers all protocol stack layers (access technologies, 482 network, transport, facilities and applications). It is designed to 483 accommodate communications between ITS stations engaged in ITS 484 services. ITS stations can be deployed in vehicles of any type, 485 roadside infrastructure (traffic lights, variable message signs, toll 486 road gantries, etc.), urban infrastructure (parking gates, bus stops, 487 etc.) nomadic devices (smartphones, tablets) and control centers 488 (traffic control center, emergency call centers, data centers and 489 services centers). The ITS stations can be distributed in several 490 nodes (e.g. an in-vehicle gateway and a set of hosts attached to the 491 internal in-vehicle network). The ITS station architecture is 492 designed to support many kinds of wired and wireless access 493 technologies (vehicular WiFi 802.11p, urban WiFi 802.11b/g/n/ac/ad; 494 cellular networks; satellite; infra-red, LiFi, millimeter wave, etc.) 496 The ISO ITS station architecture can thus support both broadcast and 497 unicast types of communication, vehicle-to-infrastructure 498 communications (road infrastructure using e.g. WiFi, or cellular 499 infrastructure using e.g. 3G/4G) and, most notably, direct vehicle- 500 to-vehicle communications. 502 The architecture includes the possibility to communicate using IPv6 503 [ISO-21210] or non-IP (ISO FNTP, currently being harmonized with IEEE 504 WAVE). 506 The ISO TC204/WG14 (Work Group 14 "Vehicle/Roadway Warning and 507 Control Systems") is developing a draft of international standard for 508 C-ACC systems. The focus is on vehicular system control, rather than 509 on communication media. The potential work item is in an early stage 510 of development; it may describe performance requirements or 511 validation through test procedures. It is considered that "C-ACC" to 512 be an expansion to the existing ACC concepts which have been 513 previously described in the document ISO 15622 "Adaptive Cruise 514 Control Systems". The potential C-ACC work item may require the 515 specific involvement of Vehicle-to-Vehicle communications and other 516 types of communications (I2V and more), in addition to requiring 517 active sensing involving radars and camera systems. 519 8. ISO-IEEE Harmonization 521 The intent is to harmonize the IEEE 1609 and ISO FAST protocols at 522 5.9GHz to avoid having to support region-dependent protocols (e.g. 523 different protocols in Europe and the US), and this intention is not 524 dependent on any particular application or service. 526 The IEEE 1609.3 WG developed a version 3 draft of 1609.3 such that 527 after publication of this version 3, and after subsequent appropriate 528 updates of ISO 29281-1 and ISO 24102-5 an interoperability mode with 529 ISO 29281-1 v2 FNTP and ISO 24102-5 v2 FSAP will be given. This 530 interoperability in the first step will be limited to broadcast of 531 messages (e.g. for road safety) such that an ITS station unit can 532 properly receive messages sent out by a WAVE device, and vice versa. 534 C-ACC and Platooning are (C-)ITS services that will be deployed as 535 ITS applications on ITS stations in vehicles. These applications can 536 and will make use of ITS station communication services (network and 537 transport protocols, data link layer protocols, and physical layer 538 protocols) that have the necessary characteristics/properties (e.g. 539 V2V, low-latency, moderate bandwidth, etc.) to achieve their goals. 540 The IEEE 1609 and ISO protocols and communication services, whether 541 or not they are ultimately "harmonized", can be used by either or 542 both of these ITS applications as they generally meet the 543 requirements for these apps. 545 Some communication tasks in C-ACC and Platooning will use IPv6, 546 whereas others will not. For example some vendors of WAVE devices 547 and ITS station units consider the use of the short messages protocol 548 (not IPv6) for C-ACC and Platooning scenarios. 550 9. V2V communications at ITU 552 The International Telecommunication Union (ITU) is the United Nations 553 specialized agency for information and communication technologies. 554 It is an early standards development organization known for example, 555 among other things, for spectrum or stationary orbit allocations to 556 countries. 558 Within ITU, the Telecommunication Standardization Sector (ITU-T) is 559 composed of Study Groups (SGs) which make Recommendations which lead 560 to standards for countries' Information and Communication 561 Technologies (ICT) networks. 563 The ITU-T SG 16 leads ITU's standardization work on multimedia coding 564 and it is also the lead group for promissing topics such as the 565 Internet of Things activities (IoT), Internet Protocol Television 566 (IPTV) and Intelligent Transportation Systems (ITS). 568 The Question 27/16 of ITU-T SG 16 titled "Vehicle gateway platform 569 for telecommunication/ITS services/applications" is a group motivated 570 by the observation that, among others, the information generated by 571 vehicles has an important role in the chain of telecommunications and 572 ITS. 574 Currently under discussion, the proposed study items include the 575 definition of a gateway (aka OBU) and the functions and requirements 576 to support vehicle-to-vehicle and vehicle-to-intrastructure 577 tellecommunications. Another study item is to define scenarios for 578 such gateways acting as bridges (presumably "IP routers" , Ed.) 579 between cars and between cars and the infrastructure. 581 The description of ITU-T Question 27/16 is publicly available on the 582 web on the itu.int website. 584 10. ARIB and ITS Info-comm use of CACC and V2V concepts 586 In Japan, the Association of Radio Industries and Businesses (ARIB) 587 and the ITS Info-communications Forum produce standards and 588 guidelines for Intelligent Transportation Systems. Whereas US and EU 589 standards focus mainly on the 5.9GHz bands for ITS, the Japanese 590 standards operate initially in a 700MHz band. 592 The publicly and freely available document RC-013 version 1.0 titled 593 "Experimental Guideline for Inter-Vehicle Communication Messages" 594 considers that inter-vehicle communications (presumably V2V, Ed.) are 595 realized with Basic Messages. A Basic Message is generated by an 596 application layer running on top of a "IVC-RVC" layer (at the typical 597 network-layer place, Ed.) which runs itself on top of a Layer 2 598 "data-link" and of a Layer 1 PHY. The contents of a Basic Message 599 can be any one of the following: time information, position 600 information, vehicle status, and more. A particular data frame 601 representing status information is the 602 "DE_CooperativeAdaptiveCruiseControlStatus" represented on 2 bits. 604 11. FirstNet EMS use of LTE and IP in V2I2V 606 FirstNet is a corporation housed inside the US Department of 607 Commerce. It gets capitalization budget from, among other sources, 608 sale of spectrum by the US FCC. It gets operating budget from sale 609 of services to state emergency services entities. 611 The communications architectures for FirstNet include vehicle-to- 612 vehicle, vehicle-to-infrastructure and vehicle-to-infrastructure-to- 613 vehicle communications using, in certain cases, LTE and IP: 615 o Emergency communications to vehicles from government entities 616 conveying, for example: weather warnings, road conditions, 617 evacuation orders. The government entities might include PSAPs or 618 mobile vehicles such as police cruisers. 620 o Instrumented emergency services vehicles such as ambulances. An 621 example is the ability to telemeter casualty (patient) data from 622 sensors attached to the casualty to a hospital emergency room. 624 o Emergency communications from vehicles' occupants to government 625 entities such as Public Safety Access Points (PSAPs, also known as 626 911 operators in US). 628 The National Public Safety Telecommunications Council describes 629 FirstNet as an emergency communications system (largely viewed 630 through the prism of the familiar Land Mobile Radio systems most 631 emergency services use.) The cellular telephone industry views 632 FirstNet as supplementary to an existing commercial cellphone system 633 (e.g. reusing the same towers and backhaul). Perhaps a better view 634 of FirstNet is as an extension of the Internet to emergency services 635 vehicles (including pedestrian). 637 It is clear that FirstNet overlaps with a large extent to the 638 concepts that have been discussed in vehicle-to-vehicle 639 communications for other purposes. 641 FirstNet has not been clear about its communication technology 642 choices to date. But LTE has been discussed as the most likely layer 643 2 protocol. A segregated segment of spectrum in the 700MHz band has 644 been set aside by Congressional action for emergency services and 645 control of that spectrum has been passed to FirstNet. There appear 646 to be no new protocols developed by FirstNet. Several Internet 647 applications would need rework to handle high availability, security 648 and assured access needs of emergency services. 650 12. Internet apps: WAZE, iRezQ, Coyote, Sentinel 652 Applications using the Internet have been developed in the particular 653 context of vehicular communications. These applications are designed 654 for parties situated in vehicles. Their profile is less of client- 655 server kind, but more of peer-to-peer kind (vehicle to vehicle). 657 Some use vehicle-to-infrastructure-to-vehicle IP paths, whereas 658 others involve direct vehicle-to-vehicle paths (without 659 infrastructure). 661 These applications are described in more detail in a recent Internet 662 Draft titled "Scenario of Intelligent Transportation System" 663 [I-D.liu-its-scenario]. 665 13. Car manufacturer labels with V2V features 667 Toyota "ITS Connect" is a feature advertised for high-end automobile 668 models set to hit the roads by the end of 2015. This includes the 669 Crown as well as two other lower level models. The "ITS Connect" 670 features which exhibit V2V characteristics are Right Turn Collision 671 Caution, Red Light Caution and Emergency Vehicle Proximity 672 Notification. One particular V2V feature which illustrates a 673 possible migration from exclusively radar signals to bidirectional 674 data exchanges is the Communicating Radar Cruise Control. A publicly 675 available description of this feature mentions that it integrates 676 Radar Cruise Control and V2V information from the preceding vehicle 677 to help follow it smoothly. Toyota "ITS Connect" is using Japanese 678 ARIB standards STD-Txxx and ITS Info-communications Forum Guidelines 679 RC-xxx in the 700MHz band. 681 14. Gap Analysis 683 It is generally agreed that one or more IP subnets are embedded in an 684 automobile. The embedded network is formed by at least two (and 685 generally up to 5) distinct IP subnets. In each of the subnets 686 several IP-addressable computers are currently enabled with IP 687 stacks. 689 The realization of V2V communications can happen by connecting 690 together two such embedded networks, each carried by a distinct 691 vehicle. With a direct connection, an IP Router in one vehicle 692 connects to an IP Router in another vehicle nearby. The maximum 693 distance between two such vehicles is dictated by the link layer 694 technology (e.g., with IEEE 802.11p OCB mode the distance may be up 695 to 800 metres). On another hand, an indirect connection may involve 696 the use of a Road-Side Unit, or a longer IP path through a cellular 697 network. It is expected that the shortest latencies to be obtained 698 with the most straightforward (direct) connections rather than 699 through-fixed-RSU through-cellular. 701 When two vehicles are connected to each other in this way, an IP 702 subnet is formed between the egress interfaces of Router embedded in 703 vehicles. There are several ways in which the IP path can be 704 established across this 1-hop subnet. 706 14.1. Neighbor Discovery protocol 708 Routers exchange Router Advertisement messages. An RA message 709 contains prefixes announced to be valid on one link. On another 710 hand, the prefix announced by an RA can not be equal to the prefix of 711 a same router but of one of its other interfaces. And this 712 represents a shortcoming of the ND protocol - it can not support V2V 713 topologies. 715 14.2. Mobile IP protocol 717 There are two modes of operation of a V2V topology. With a link 718 technology like IEEE 802.11b it is possible that one vehicle attaches 719 to another vehicle in "Access Point" mode, or alternatively in "ad- 720 hoc" mode. In "Access Point" mode (or Client-Server), the first 721 vehicle allocates an address, and potentially a prefix, to the second 722 vehicle. This latter may then use the Mobile IP protocol to inform 723 the first vehicle about in-car prefix (use a Binding Update message 724 as if the Access Point vehicle were a Correspondent Node). The gap 725 is in that currently the Mobile IP protocol is not fully specified to 726 send BUs in that way. 728 This Mobile IP gap depends largely on the situation (physical 729 location) of the Home Agent entity. The placement of the Home Agent 730 in the fixed infrastructure is assumed by the most common deployments 731 of connected vehicles. The Home Agent in charge of the vehicle is 732 situated in a data center owned and administered by the vehicle 733 manufacturer. Other similar placements consider the fixed network of 734 a regional representative of the manufacturer, or a local dealer. 735 Further, in theory, it can be considered that a Home Agent be placed 736 inside a vehicle as well, although this has not been tested. 737 Depending on this placement of the HA, the Mobile IP gap can vary. 739 Note a new requirement has been developped recently in the DMM 740 Working Group. The distributed mobility management requirement REQ1 741 in [RFC7333] states that DMM solutions must enable traffic to avoid 742 traversing a single mobility anchor far from the optimal route. This 743 may help placing a Home Agent nearer to the access network (rather 744 than in a data center). In addition to this requirement, it may be 745 necessary to dynamically migrate the Home Agent to a place near the 746 vehicle, as it moves across borders or travel long distances. 748 14.3. AODVv2 protocol 750 The AODVv2 protocol [I-D.ietf-manet-aodvv2] is a routing protocol 751 used to build and find IP paths in an ad hoc network. However, 752 AODVv2 does not take into account preconfiguration of default routes. 753 Default routes are extensively used in current networks carried in 754 vehicles. Good administration of default routes can greatly simplify 755 routing in such networks. This represents a gap. 757 15. Security Considerations 759 All government-to-vehicle and vehicle-to-government communications, 760 without exception, require authentication. 762 Some, but not all, communications from government-to-vehicle and 763 vehicle-to-government require confidentiality to protect the content 764 of the messages. Some of these requirements, such as medical data, 765 have the force of law. Others are customary, or are based on common 766 respect as requirements. 768 Protocol information shared between the cooperating vehicles MUST 769 also be protected in order to avoid disruption or attack on the 770 vehicles operation. Any modification or malicious insertion of 771 protocol messages would carry with it a high risk of death and injury 772 as well as tremendous disruption of other vehicular traffic. 774 16. IANA Considerations 776 mandatory 778 17. Contributors 780 Jim Misener (Qualcomm, SAE DSRC TC Chair), Masanori Misumi (Mazda, 781 ISO TC204/WG14 Convenor), Michelle Wetterwald (Consult Europe), Tom 782 Kurihara (mindspring). 784 18. References 786 18.1. Normative References 788 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 789 Requirement Levels", BCP 14, RFC 2119, 790 DOI 10.17487/RFC2119, March 1997, 791 . 793 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 794 Korhonen, "Requirements for Distributed Mobility 795 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 796 . 798 18.2. Informative References 800 [ACC-def] Liang, C-Y. and H. Peng, "Optimal Adaptive Cruise Control 801 with Guaranteed String Stability", April 1999. 803 [CACC-def] 804 Shladover, E., Nowakowski, C., Lu, X-Y., and X-Y. Ferlis, 805 "Cooperative Adaptive Cruise Control (CACC) Definitions 806 and Operating Concepts", April 2015. 808 [ETSI-CACC] 809 ETSI Technical Report TR 103 299, "Cooperative Adaptive 810 Cruise Control (C-ACC) prestandardization study (ETSI-SAE 811 join WI proposal); ongoing at the time of writing of this 812 Internet Draft", 2015. 814 [GPP-TR-22-803] 815 3GPP, "Feasibility study for Proximity Services (ProSe)", 816 June 2013. 818 [GPP-TR-22-885] 819 3GPP, "Study on LTE Support for V2X Services", April 2015. 821 [GPP-TS-22-278] 822 3GPP, "Service requirements for the Evolved Packet System 823 (EPS)", December 2014. 825 [I-D.ietf-manet-aodvv2] 826 Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L., and 827 V. Mercieca, "Ad Hoc On-demand Distance Vector Version 2 828 (AODVv2) Routing", draft-ietf-manet-aodvv2-14 (work in 829 progress), April 2016. 831 [I-D.liu-its-scenario] 832 Liu, D., "Scenario of Intelligent Transportation System", 833 draft-liu-its-scenario-00 (work in progress), March 2015. 835 [I-D.petrescu-ipv6-over-80211p] 836 Petrescu, A., Benamar, N., and T. Leinmueller, 837 "Transmission of IPv6 Packets over IEEE 802.11 Networks 838 Outside the Context of a Basic Service Set", draft- 839 petrescu-ipv6-over-80211p-03 (work in progress), October 840 2015. 842 [ISO-21210] 843 ISO, "21210: TC ITS - WG CALM - IPv6 Networking - 844 International Standard", 2014. 846 [ISO-21217] 847 ISO, "21217: TC ITS - WG CALM - Architecture - 848 International Standard", 2014. 850 [ISO-CACC] 851 ISO, "PWI 20035 Intelligent Transport Systems - 852 Cooperative Adaptive Cruise Control Systems (CACC) - 853 Performance requirements and test procedures, Reference 854 number 20035; ongoing work at the time of writing of this 855 Internet Draft.", 2015. 857 [its-infocomm-CACC] 858 ITS Info-communications Forum of Japan, "Experimental 859 Guideline for Inter-vehicle Communication Messages; ITS 860 Forum RC-013 Ver. 1.0", 2014. 862 [ITU-V2V] ITU, "Question 27/16 - Vehicle gateway platform for 863 telecommunications/ITS services/applications; ongoing work 864 at the time of writing this Internet Draft.", 2015. 866 [METIS-D1.1] 867 Fallgren, M. and B. Timus, "Scenarios, requirements and 868 KPIs for 5G mobile and wireless system", April 2013. 870 [SAE-V2V] SAE International (Society for Automotive Engineering), 871 J2945/1; ongoing work at the time of writing this Internet 872 Draft., "On-board System Requirements for V2V Safety 873 Communications", 2015. 875 Appendix A. ChangeLog 877 The changes are listed in reverse chronological order, most recent 878 changes appearing at the top of the list. 880 From -04 to -05: 882 o Minor updates. 884 From -03 to -04: 886 o Updated the perspective from SAE with respect to work on V2V 887 requirements for safety. 889 o Clarified the IEEE 1609 point of view by which C-ACC use IEEE 1609 890 protocols. 892 o Added authors' point of view of IEEE-ISO harmonization, which may 893 have a relationship to vehicle-to-vehicle communications. 895 o Added ITU-T Question 27 of Study Group 16 description mentioning 896 V2V communications. 898 o Added a section on Japan's ARIB and ITS info-comm documents which 899 describe C-ACC and other inter-vehicle services in the 700MHz 900 band. Added an example of car manufacturer with product on the 901 market at the time of writing implementing some of these features. 903 o Clarification of HA placement conditioning the Mobile IP gap 904 discussion. 906 o Editorial improvements, citations added, terminology section 907 improved. 909 From -01 to -02: 911 o Added perspectives on C-ACC and Platooning from ETSI, SAE, and 912 IEEE P1609. Updated the perspective from ISO. 914 o Added Gap Analysis: what are the gaps between what existing 915 protocols ND, Mobile IP and AODV can do and what is needed to 916 realize a C-ACC and Platooning use-case with a V2V topology? 918 Authors' Addresses 920 Alexandre Petrescu (editor) 921 CEA, LIST 922 CEA Saclay 923 Gif-sur-Yvette , Ile-de-France 91190 924 France 926 Phone: +33169089223 927 Email: Alexandre.Petrescu@cea.fr 929 James Huang 930 Huawei Technologies 931 Shenzhen 932 China 934 Email: james.huang@huawei.com 936 Thierry Ernst 937 Mines ParisTech 938 Paris 75006 939 France 941 Email: Thierry.Ernst@mines-paristech.fr 943 Rex Buddenberg 944 Retired 945 US 947 Email: buddenbergr@gmail.com 948 Charles E. Perkins 949 Futurewei Inc. 950 2330 Central Expressway 951 Santa Clara, CA 95050 952 USA 954 Phone: +1-408-330-4586 955 Email: charliep@computer.org