[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

Network Working Group                                   A. Petrescu, Ed.
Internet-Draft                                                 CEA, LIST
Intended status: Informational                                  J. Huang
Expires: April 21, 2016                              Huawei Technologies
                                                                T. Ernst
                                                         Mines ParisTech
                                                           R. Buddenberg
                                                                     " "
                                                              C. Perkins
                                                               Futurewei
                                                        October 19, 2015


   Cooperative Adaptive Cruise Control and Platooning at SDOs and Gap
                                Analysis
                   draft-petrescu-its-cacc-sdo-04.txt

Abstract

   This document describes the use-cases of Cooperative Adaptive Cruise
   Control, and Platooning, as defined by several Standards Development
   Organizations such as ETSI, IEEE P1609, SAE, 3GPP, ISO and FirstNet.

   C-ACC and Platooning involve concepts of direct vehicle-to-vehicle,
   and device-to-device communications, which are developed by 3GPP
   following on work done within the METIS EU project.  They are
   illustrated very clearly in emergency settings such as FirstNet.

   IP packets - instead of link-layer frames - are pertinent for C-ACC
   and Platooning use-cases because applications for road safety such as
   WAZE, iRezQ and Coyote (currently involving infrastructure) make use
   of IP messages, and have proved successful in deployments.
   Applications such as Sentinel operate directly between vehicles, but
   currently use messages not carried over IP.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any




Petrescu, et al.         Expires April 21, 2016                 [Page 1]


Internet-Draft      C-ACC at SDOs and IP Gap Analysis       October 2015


   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 21, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  ETSI ITS C-ACC and Platooning use-case and reqs . . . . . . .   7
   4.  The C-ACC Use of Protocols specified by IEEE 1609 Standards .   7
   5.  SAE perspective on C-ACC and Platooning . . . . . . . . . . .   8
   6.  3GPP and EU projects using LTE Device-to-Device concepts  . .   8
     6.1.  3GPP  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.2.  METIS . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   7.  ISO perspective on V2V  . . . . . . . . . . . . . . . . . . .  10
   8.  ISO-IEEE Harmonization  . . . . . . . . . . . . . . . . . . .  11
   9.  V2V communications at ITU . . . . . . . . . . . . . . . . . .  12
   10. ARIB and ITS Info-comm use of CACC and V2V concepts . . . . .  13
   11. FirstNet EMS use of LTE and IP in V2I2V . . . . . . . . . . .  13
   12. Internet apps: WAZE, iRezQ, Coyote, Sentinel  . . . . . . . .  14
   13. Car manufacturer labels with V2V features . . . . . . . . . .  14
   14. Gap Analysis  . . . . . . . . . . . . . . . . . . . . . . . .  15
     14.1.  Neighbor Discovery protocol  . . . . . . . . . . . . . .  15
     14.2.  Mobile IP protocol . . . . . . . . . . . . . . . . . . .  15
     14.3.  AODVv2 protocol  . . . . . . . . . . . . . . . . . . . .  16
   15. Security Considerations . . . . . . . . . . . . . . . . . . .  16
   16. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   17. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  17
   18. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     18.1.  Normative References . . . . . . . . . . . . . . . . . .  17
     18.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Appendix A.  ChangeLog  . . . . . . . . . . . . . . . . . . . . .  19



Petrescu, et al.         Expires April 21, 2016                 [Page 2]


Internet-Draft      C-ACC at SDOs and IP Gap Analysis       October 2015


   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

   Cooperative Adaptive Cruise Control (C-ACC) and Platooning are two
   use-cases described recently by other Standards Development
   Organizations (SDOs).  C-ACC [CACC-def] is understood as a automated
   formation of chains of automobiles following each other at constant
   speed.  This offers more comfort for human drivers on long journeys
   on straight roads.

   Simple 'cruise control' was the automation of speed maintenance at a
   single automobile (increase torque if uphill, smoothly brake
   downhill, such as to maintain constant speed).  The term "Adaptive
   Cruise Control" was used earlier in the literature [ACC-def].  The
   concept of C-ACC aims at the same level of automation but in a
   cooperative manner between several vehicles: while in CC mode, when a
   vehicle in front slowly decelerates, this vehicle will also do, such
   as to maintain distance, and relieve driver from taking control over.

   Platooning is another concept related to larger vehicles following
   each other.  The goal in this case is more than just comfort - large
   gains are expected in terms of gas consumption: when large vehicles
   can follow each other at small distance the air-drag is much lower,
   reducing gas consumption, tyre use, and more.

   Both C-ACC and Platooning must rely on wireless communications
   between vehicles (in addition to more immediate indicators like
   signal echoes - radars and cameras).  These exchanges may happen in a
   direct manner (direct vehicle to vehicle communications) or with
   assistance from a fixed communication infrastructure (vehicle-to-
   infrastructure-to-vehicle communications).

   This document presents the V2V-based C-ACC and Platooning use-cases
   as described at ETSI [ETSI-CACC], SAE [SAE-V2V], ISO [ISO-CACC], 3GPP
   [GPP-TR-22-885], ITU [ITU-V2V], ITS Info-communications Forum of
   Japan [its-infocomm-CACC] and more.  These use-cases are widely
   accepted as examples of Vehicle-to-Vehicle applications.

   In emergency settings the concepts of direct vehicle-to-vehicle
   communications are of paramount importance.  FirstNet, as described
   later in this document, covers V2V, V2I and V2I2V communication
   needs, together with strong security requirements.

   In the market, several systems for vehicular communications have
   demonstrated a number of benefits in the context of vehicle-to-
   vehicle communications.




Petrescu, et al.         Expires April 21, 2016                 [Page 3]


Internet-Draft      C-ACC at SDOs and IP Gap Analysis       October 2015


   o  The Sentinel system is used between vehicles to warn each other
      about approach;

   o  WAZE on smartphones created a community where users influence
      others about the route choice;

   o  iRezQ and Coyote communicate between vehicles, via infrastructure,
      about route risks.

   In [I-D.petrescu-ipv6-over-80211p] the use of IPv6 over 802.11p is
   described.  This link layer is potentially to be used in direct
   vehicle-to-vehicle communications, among several other possibilities.

2.  Terminology

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

   3GPP: Third Generation Partnership Project.

   3G: Third Generation.

   4G: Fourth Generation.

   5G: Fifth Generation of mobile networks.

   apps: applications.

   AODV: Ad-hoc On-demand Distance Vector.

   ARIB: Association of Radio Industries and Businesses.

   BSS: Basic Service Set.

   C-ACC: Cooperative Adaptive Cruise Control.

   CAM: Cooperative Awareness Message.

   CC: Cruise Control.

   CEN: European Committee for Standardizatin (Comite europeen de
   normalisation, fr.)

   DeNM: Decentralized Environmental Notification Message.

   DMM: Distributed Mobility Management.




Petrescu, et al.         Expires April 21, 2016                 [Page 4]


Internet-Draft      C-ACC at SDOs and IP Gap Analysis       October 2015


   DSRC: Dedicated Short Range Communications, as referenced in the
   United States FCC Report and Order for the frequency allocation for
   5.9GHz band in North America, which refers to "DSRC" as the ASTM
   (earlier "American Society for Testing and Materials") standard
   "E2213".  Other interpretations of "DSRC" include the DSRC standard
   developed in ISO TC204 WG17 and CEN TC278 which uses a different
   frequency spectrum than the one used in North America.

   E2E: end-to-end.

   EMS: Emergency and Medical System providers.

   EPC: Evolved Packet Core.

   ETSI: European Telecommunications Standards Institute.

   E-UTRAN: Evolved Universal Terrestrial Radio Access Network.

   EU: European Union.

   FAST: fast.

   FCC: Federal Communications Commision.

   FNTP: Fast Networking and Transport layer Protocol.

   FSAP: Fast Service Advertisement Protocol.

   I2V: Infrastructure to Vehicle.

   ICT: Information and Communication Technologies.

   IEEE: Institute of Electrical and Electronics Engineers.

   IoT: Internet of Things.

   IP: Internet Protocol.

   IPv6: Internet Protocol version 6.

   IPTV: Internet Protocol Television

   ISO: International Organization for Standardization.

   ITS: Intelligent Transportation Systems.

   ITS-G5: ITS Gigahertz Five.




Petrescu, et al.         Expires April 21, 2016                 [Page 5]


Internet-Draft      C-ACC at SDOs and IP Gap Analysis       October 2015


   ITU: International Telecommunication Union.

   ITU-T: Telecommunication Standardization Sector of the International
   Telecommunication Union.

   IVC-RVC:

   LiFi: Light Fidelity.

   LTE : Long-Term Evolution.

   METIS: Mobile and wireless communications Enablers for Twenty-twenty
   (2020) Information Society.

   OBU: On-Board Unit.

   OCB: Outside the Context of a BSS identifier.

   PHY: physical layer.

   ProSe: Proximity Service.

   PSAP: Public Safety Answering Points.

   RA: Router Advertisement.

   SAE: Society of Automotive Engineers.

   SDO: Standards Development Organization.

   SG: Study Group.

   TC: Technical Committee.

   TR: Technical Report.

   UE: User Equipment.

   US: United States.

   V2V: Vehicle-to-Vehicle communications.

   V2X: Vehicle-to-'other' communications.  E.g.  Vehicle-to-
   Infrastructure (V2I), Vehicle-to-Pedestrian (V2P), Vehicle-to-
   Nomadic[device] (V2N), Vehicle-to-Device (V2D) and more.

   V2I2V: Vehicle to Infrastructure to Vehicle.




Petrescu, et al.         Expires April 21, 2016                 [Page 6]


Internet-Draft      C-ACC at SDOs and IP Gap Analysis       October 2015


   WAVE: Wireless Access for Vehicular Environments.

   WG1: Work Group 1.

   WiFi: Wireless Fidelity.

   WLAN: Wireless Local Area Network.

3.  ETSI ITS C-ACC and Platooning use-case and reqs

   ETSI Technical Committee Intelligent Transportation Systems (ETSI TC
   ITS) is responsible for the development and maintenance of standards,
   specifications and other reports on the implementation of V2V
   communications in Cooperative ITS.  Its scope extends from the
   wireless access (excluding issues in radio frequency) to generic
   services and corresponding applications.  Security and tests
   specifications are also covered.  This responsibility is reflected in
   the organization with five working groups that make up the committee.
   Among them, WG1 is responsible of the facilities and applications
   needs.

   Under the EU Mandate M/453, TC ITS has developed a minimum set of
   standards (Release 1) for systems interoperability during initial
   deployment.  The list of standards and specifications are provided in
   the publicly available report ETSI TR 101 607.  A second release of
   the standards is being prepared.  It should support more complex use
   cases, possible integration with other technologies as well as a more
   elaborate consideration of access networks other than the ITS-G5
   (European profile of IEEE 802.11p).  The TC ITS WG1 is currently
   working on two separate work items for pre-standardization studies on
   C-ACC (DTR/ITS-00164) and Platooning (DTR/ITS-00156).  The scope of
   the target technical reports is to describe the relevant use cases
   that could be enabled by Cooperative ITS, to survey the existing
   related standards and to identify what new features and standards are
   needed to support these use cases.

   The C-ACC definition in TR 103 299 will soon be made public.

4.  The C-ACC Use of Protocols specified by IEEE 1609 Standards

   The C-ACC interacts with the presentation layer services which in
   turn use the communication protocols specified in IEEE 1609
   standards.

   One perspective from IEEE P1609 is that Cooperative Adaptive Cruise
   Control (CACC) represents an "application".  An application is
   typically software whose communication needs are situated at the
   upper layers of a communication stack - e.g. the Application Layer.



Petrescu, et al.         Expires April 21, 2016                 [Page 7]


Internet-Draft      C-ACC at SDOs and IP Gap Analysis       October 2015


   As such it is little relevant to IEEE P1609; P1609 is concerned more
   with physical, data-link and network communication layers.  On
   another hand, a perspective well considered in IEEE P1609 is that
   C-ACC and Platooning may be more relevant to the Society of
   Automotive Engineers.

5.  SAE perspective on C-ACC and Platooning

   The Society of Automotive Engineers (SAE) concerns itself with data
   exchanges and host system requirements for applications.  The SAE
   DSRC Technical Committee (DSRC: Dedicated Short-Range Communications)
   is working on C-ACC within the Cooperative Vehicle Task Force.  In
   addition, the SAE On-Road Vehicle Automation Committee is working on
   a use-case relevant to C-ACC towards realization of a reference
   architecture.

   In addition to C-ACC, SAE is completing performance requirements for
   V2V Safety Communications to profile a probable US-mandated
   implementation.  The concept is that a vehicle would send a link-
   layer message set (Basic Safety Message, plus path history and path
   prediction extensions) to a host vehicle to enable the host vehicle
   to use the transmitted information in a driver warning or alert
   algorithm.  Because it is used for safety, it is of paramount
   importance that the messages are authenticated through a Security
   Credential Management System.

   The SAE DSRC TC activities are in cooperative agreement to ETSI ITS
   WG1, as there are information exchanges between the two bodies
   [SAE-V2V].

6.  3GPP and EU projects using LTE Device-to-Device concepts

6.1.  3GPP

   The Proximity Service (ProSe) allows a UE to discover and communicate
   with other UEs that are in proximity directly or with the network
   assistance.  This may also be called as Device-to-Device (D2D)
   communication.  ProSe is intended for purposes such as public
   security, network offloading, etc [GPP-TR-22-803].

   The ProSe Communication path could use E-UTRAN or WLAN.  In the case
   of WLAN, only ProSe-assisted WLAN direct communication (i.e. when
   ProSe assists with connection establishment management and service
   continuity) is considered [GPP-TS-22-278].

   The work on ProSe is initiated in 3GPP Release 12.  Some enhancements
   are being added in Release 13, e.g.  Restricted ProSe Discovery.
   Some use cases are identified in [GPP-TR-22-803], but most of which



Petrescu, et al.         Expires April 21, 2016                 [Page 8]


Internet-Draft      C-ACC at SDOs and IP Gap Analysis       October 2015


   are intended for common mobile users, e.g. pedestrians, but not for
   vehicles moving at high speed.  The latency in ProSe communication
   may be a problem for V2X.

   ProSe does not support V2X communication until at least Release 14,
   but it has some very good characteristics which makes it a good
   candidate for V2X besides DSRC.  ProSe communication does not have to
   go through the EPC, which will significantly reduce the latency.
   ProSe also supports group and broadcast communication by means of a
   common communication path established between the UEs.

   There are some efforts within 3GPP Release 14, trying to address V2X
   communication.  The efforts are proposed by experts in the industry,
   and may be subject to change.  These efforts include the following,
   not an exhaustive list:

   o  To address the V2X use cases in 3GPP.  Some use cases have been
      defined by other SDOs, e.g.  ETSI ITS; 3GPP can reference to them.
      Requirements for V2X communication should also be considered, for
      example network delay, packet loss rate, etc.  [METIS-D1.1]
      already propose some requirements, but those are intended for
      future mobile network, which may be too critical for LTE.

   o  To address V2X applications and messages.  The messages may
      include message defined in SAE J2735, ETSI Cooperative Awareness
      Message (CAM) and ETSI Decentralized Environmental Notification
      Message (DeNM).  The messages defined by different SDOs might be
      similar to each other.

   o  Study of possibility to add enhancements to ProSe, and to make it
      able to support and enhance DSRC.

   o  Study of using existing LTE technologies for unicast/multicast/
      broadcast communication.

   [GPP-TR-22-885] studies many V2X services using LTE.  These services
   include V2V communication (e.g.  Cooperative Adaptive Cruise Control,
   Forwarding Collision Warning, etc), V2I/V2N communication (e.g.  Road
   Safety Services) and vehicle to pedestrian communication.  The
   services' pre-condition, service flow, post-condition, including some
   network communication requirements, such as delay, messages frequency
   and message size, are ayalyzed.

   In [GPP-TR-22-885], Cooperative Adaptive Cruise Control (CACC) allows
   a vehicle to join a group of CACC vehicles; the benefits are to
   improve road congestion and fuel efficiency.  Member vehicles of CACC
   group should periodically broadcast messages including the CACC group
   information, such as speed and gap policies, etc.  If a vehicle



Petrescu, et al.         Expires April 21, 2016                 [Page 9]


Internet-Draft      C-ACC at SDOs and IP Gap Analysis       October 2015


   outside the group wants to join, it should send a request to the
   group.  If a member of the CACC group accepts the request, it should
   send a confirm message and provide necessary distance gap; and
   members of the group will update their group information.  When a
   member wants to leave the CACC group, it broadcasts a goodbye
   message, and the driver once again assumes control of the vehicle.

6.2.  METIS

   METIS is co-funded by the European Commission as an Integrated
   Project under the Seventh Framework Programme for research and
   development (FP7).

   METIS defines test cases and requirements of "Traffic safety and
   efficiency", as depicted in [METIS-D1.1], which is intended for 5G in
   2020 but may also be applicable for LTE and subsequent systems.

   The use cases include:

   1.  Dangerous situation that can be avoided by means of V2V
       communications.

   2.  Dangerous situation with vulnerable road users (i.e. pedestrians,
       cyclists,...) that can be avoided by means of V2D communications.
       "D" can denote any cellular device that the vulnerable road user
       may carry (e.g. smart phone, tablet, sensor tag).

   3.  Assistance services that can improve traffic efficiency by means
       of V2X communications, e.g. traffic sign recognition and green
       light assistance.

   4.  Autonomous platooning increase traffic flow and reduce fuel
       consumption and emissions.

   5.  Automated vehicles.

   To support the above use cases, METIS works out the corresponding
   network requirements.  For instance, for some applications the E2E
   latency must be within 5ms; other requirements include data rates for
   various scenarios, service ranges in highway/rural/urban scenarios,
   etc.

7.  ISO perspective on V2V

   The International Standards Organization's Technical Committee 204
   "Intelligent transport systems" (ISO TC204, in short) has specified a
   communication architecture known as the "ITS station reference
   communication architecture" [ISO-21217].  This communication



Petrescu, et al.         Expires April 21, 2016                [Page 10]


Internet-Draft      C-ACC at SDOs and IP Gap Analysis       October 2015


   architecture covers all protocol stack layers (access technologies,
   network, transport, facilities and applications).  It is designed to
   accommodate communications between ITS stations engaged in ITS
   services.  ITS stations can be deployed in vehicles of any type,
   roadside infrastructure (traffic lights, variable message signs, toll
   road gantries, etc.), urban infrastructure (parking gates, bus stops,
   etc.) nomadic devices (smartphones, tablets) and control centers
   (traffic control center, emergency call centers, data centers and
   services centers).  The ITS stations can be distributed in several
   nodes (e.g. an in-vehicle gateway and a set of hosts attached to the
   internal in-vehicle network).  The ITS station architecture is
   designed to support many kinds of wired and wireless access
   technologies (vehicular WiFi 802.11p, urban WiFi 802.11b/g/n/ac/ad;
   cellular networks; satellite; infra-red, LiFi, millimeter wave, etc.)

   The ISO ITS station architecture can thus support both broadcast and
   unicast types of communication, vehicle-to-infrastructure
   communications (road infrastructure using e.g.  WiFi, or cellular
   infrastructure using e.g. 3G/4G) and, most notably, direct vehicle-
   to-vehicle communications.

   The architecture includes the possibility to communicate using IPv6
   [ISO-21210] or non-IP (ISO FNTP, currently being harmonized with IEEE
   WAVE).

   The ISO TC204/WG14 (Work Group 14 "Vehicle/Roadway Warning and
   Control Systems") is developing a draft of international standard for
   C-ACC systems.  The focus is on vehicular system control, rather than
   on communication media.  The potential work item is in an early stage
   of development; it may describe performance requirements or
   validation through test procedures.  It is considered that "C-ACC" to
   be an expansion to the existing ACC concepts which have been
   previously described in the document ISO 15622 "Adaptive Cruise
   Control Systems".  The potential C-ACC work item may require the
   specific involvement of Vehicle-to-Vehicle communications and other
   types of communications (I2V and more), in addition to requiring
   active sensing involving radars and camera systems.

8.  ISO-IEEE Harmonization

   The intent is to harmonize the IEEE 1609 and ISO FAST protocols at
   5.9GHz to avoid having to support region-dependent protocols (e.g.
   different protocols in Europe and the US), and this intention is not
   dependent on any particular application or service.

   The IEEE 1609.3 WG developed a version 3 draft of 1609.3 such that
   after publication of this version 3, and after subsequent appropriate
   updates of ISO 29281-1 and ISO 24102-5 an interoperability mode with



Petrescu, et al.         Expires April 21, 2016                [Page 11]


Internet-Draft      C-ACC at SDOs and IP Gap Analysis       October 2015


   ISO 29281-1 v2 FNTP and ISO 24102-5 v2 FSAP will be given.  This
   interoperability in the first step will be limited to broadcast of
   messages (e.g. for road safety) such that an ITS station unit can
   properly receive messages sent out by a WAVE device, and vice versa.

   C-ACC and Platooning are (C-)ITS services that will be deployed as
   ITS applications on ITS stations in vehicles.  These applications can
   and will make use of ITS station communication services (network and
   transport protocols, data link layer protocols, and physical layer
   protocols) that have the necessary characteristics/properties (e.g.
   V2V, low-latency, moderate bandwidth, etc.) to achieve their goals.
   The IEEE 1609 and ISO protocols and communication services, whether
   or not they are ultimately "harmonized", can be used by either or
   both of these ITS applications as they generally meet the
   requirements for these apps.

   Some communication tasks in C-ACC and Platooning will use IPv6,
   whereas others will not.  For example some vendors of WAVE devices
   and ITS station units consider the use of the short messages protocol
   (not IPv6) for C-ACC and Platooning scenarios.

9.  V2V communications at ITU

   The International Telecommunication Union (ITU) is the United Nations
   specialized agency for information and communication technologies.
   It is an early standards development organization known for example,
   among other things, for spectrum or stationary orbit allocations to
   countries.

   Within ITU, the Telecommunication Standardization Sector (ITU-T) is
   composed of Study Groups (SGs) which make Recommendations which lead
   to standards for countries' Information and Communication
   Technologies (ICT) networks.

   The ITU-T SG 16 leads ITU's standardization work on multimedia coding
   and it is also the lead group for promissing topics such as the
   Internet of Things activities (IoT), Internet Protocol Television
   (IPTV) and Intelligent Transportation Systems (ITS).

   The Question 27/16 of ITU-T SG 16 titled "Vehicle gateway platform
   for telecommunication/ITS services/applications" is a group motivated
   by the observation that, among others, the information generated by
   vehicles has an important role in the chain of telecommunications and
   ITS.

   Currently under discussion, the proposed study items include the
   definition of a gateway (aka OBU) and the functions and requirements
   to support vehicle-to-vehicle and vehicle-to-intrastructure



Petrescu, et al.         Expires April 21, 2016                [Page 12]


Internet-Draft      C-ACC at SDOs and IP Gap Analysis       October 2015


   tellecommunications.  Another study item is to define scenarios for
   such gateways acting as bridges (presumably "IP routers" , Ed.)
   between cars and between cars and the infrastructure.

   The description of ITU-T Question 27/16 is publicly available on the
   web on the itu.int website.

10.  ARIB and ITS Info-comm use of CACC and V2V concepts

   In Japan, the Association of Radio Industries and Businesses (ARIB)
   and the ITS Info-communications Forum produce standards and
   guidelines for Intelligent Transportation Systems.  Whereas US and EU
   standards focus mainly on the 5.9GHz bands for ITS, the Japanese
   standards operate initially in a 700MHz band.

   The publicly and freely available document RC-013 version 1.0 titled
   "Experimental Guideline for Inter-Vehicle Communication Messages"
   considers that inter-vehicle communications (presumably V2V, Ed.) are
   realized with Basic Messages.  A Basic Message is generated by an
   application layer running on top of a "IVC-RVC" layer (at the typical
   network-layer place, Ed.) which runs itself on top of a Layer 2
   "data-link" and of a Layer 1 PHY.  The contents of a Basic Message
   can be any one of the following: time information, position
   information, vehicle status, and more.  A particular data frame
   representing status information is the
   "DE_CooperativeAdaptiveCruiseControlStatus" represented on 2 bits.

11.  FirstNet EMS use of LTE and IP in V2I2V

   FirstNet is a corporation housed inside the US Department of
   Commerce.  It gets capitalization budget from, among other sources,
   sale of spectrum by the US FCC.  It gets operating budget from sale
   of services to state emergency services entities.

   The communications architectures for FirstNet include vehicle-to-
   vehicle, vehicle-to-infrastructure and vehicle-to-infrastructure-to-
   vehicle communications using, in certain cases, LTE and IP:

   o  Emergency communications to vehicles from government entities
      conveying, for example: weather warnings, road conditions,
      evacuation orders.  The government entities might include PSAPs or
      mobile vehicles such as police cruisers.

   o  Instrumented emergency services vehicles such as ambulances.  An
      example is the ability to telemeter casualty (patient) data from
      sensors attached to the casualty to a hospital emergency room.





Petrescu, et al.         Expires April 21, 2016                [Page 13]


Internet-Draft      C-ACC at SDOs and IP Gap Analysis       October 2015


   o  Emergency communications from vehicles' occupants to government
      entities such as Public Safety Access Points (PSAPs, also known as
      911 operators in US).

   The National Public Safety Telecommunications Council describes
   FirstNet as an emergency communications system (largely viewed
   through the prism of the familiar Land Mobile Radio systems most
   emergency services use.)  The cellular telephone industry views
   FirstNet as supplementary to an existing commercial cellphone system
   (e.g. reusing the same towers and backhaul).  Perhaps a better view
   of FirstNet is as an extension of the Internet to emergency services
   vehicles (including pedestrian).

   It is clear that FirstNet overlaps with a large extent to the
   concepts that have been discussed in vehicle-to-vehicle
   communications for other purposes.

   FirstNet has not been clear about its communication technology
   choices to date.  But LTE has been discussed as the most likely layer
   2 protocol.  A segregated segment of spectrum in the 700MHz band has
   been set aside by Congressional action for emergency services and
   control of that spectrum has been passed to FirstNet.  There appear
   to be no new protocols developed by FirstNet.  Several Internet
   applications would need rework to handle high availability, security
   and assured access needs of emergency services.

12.  Internet apps: WAZE, iRezQ, Coyote, Sentinel

   Applications using the Internet have been developed in the particular
   context of vehicular communications.  These applications are designed
   for parties situated in vehicles.  Their profile is less of client-
   server kind, but more of peer-to-peer kind (vehicle to vehicle).

   Some use vehicle-to-infrastructure-to-vehicle IP paths, whereas
   others involve direct vehicle-to-vehicle paths (without
   infrastructure).

   These applications are described in more detail in a recent Internet
   Draft titled "Scenario of Intelligent Transportation System"
   [I-D.liu-its-scenario].

13.  Car manufacturer labels with V2V features

   Toyota "ITS Connect" is a feature advertised for high-end automobile
   models set to hit the roads by the end of 2015.  This includes the
   Crown as well as two other lower level models.  The "ITS Connect"
   features which exhibit V2V characteristics are Right Turn Collision
   Caution, Red Light Caution and Emergency Vehicle Proximity



Petrescu, et al.         Expires April 21, 2016                [Page 14]


Internet-Draft      C-ACC at SDOs and IP Gap Analysis       October 2015


   Notification.  One particular V2V feature which illustrates a
   possible migration from exclusively radar signals to bidirectional
   data exchanges is the Communicating Radar Cruise Control.  A publicly
   available description of this feature mentions that it integrates
   Radar Cruise Control and V2V information from the preceding vehicle
   to help follow it smoothly.  Toyota "ITS Connect" is using Japanese
   ARIB standards STD-Txxx and ITS Info-communications Forum Guidelines
   RC-xxx in the 700MHz band.

14.  Gap Analysis

   It is generally agreed that one or more IP subnets are embedded in an
   automobile.  The embedded network is formed by at least two (and
   generally up to 5) distinct IP subnets.  In each of the subnets
   several IP-addressable computers are currently enabled with IP
   stacks.

   The realization of V2V communications can happen by connecting
   together two such embedded networks, each carried by a distinct
   vehicle.  With a direct connection, an IP Router in one vehicle
   connects to an IP Router in another vehicle nearby.  The maximum
   distance between two such vehicles is dictated by the link layer
   technology (e.g., with IEEE 802.11p OCB mode the distance may be up
   to 800 metres).  On another hand, an indirect connection may involve
   the use of a Road-Side Unit, or a longer IP path through a cellular
   network.  It is expected that the shortest latencies to be obtained
   with the most straightforward (direct) connections rather than
   through-fixed-RSU through-cellular.

   When two vehicles are connected to each other in this way, an IP
   subnet is formed between the egress interfaces of Router embedded in
   vehicles.  There are several ways in which the IP path can be
   established across this 1-hop subnet.

14.1.  Neighbor Discovery protocol

   Routers exchange Router Advertisement messages.  An RA message
   contains prefixes announced to be valid on one link.  On another
   hand, the prefix announced by an RA can not be equal to the prefix of
   a same router but of one of its other interfaces.  And this
   represents a shortcoming of the ND protocol - it can not support V2V
   topologies.

14.2.  Mobile IP protocol

   There are two modes of operation of a V2V topology.  With a link
   technology like IEEE 802.11b it is possible that one vehicle attaches
   to another vehicle in "Access Point" mode, or alternatively in "ad-



Petrescu, et al.         Expires April 21, 2016                [Page 15]


Internet-Draft      C-ACC at SDOs and IP Gap Analysis       October 2015


   hoc" mode.  In "Access Point" mode (or Client-Server), the first
   vehicle allocates an address, and potentially a prefix, to the second
   vehicle.  This latter may then use the Mobile IP protocol to inform
   the first vehicle about in-car prefix (use a Binding Update message
   as if the Access Point vehicle were a Correspondent Node).  The gap
   is in that currently the Mobile IP protocol is not fully specified to
   send BUs in that way.

   This Mobile IP gap depends largely on the situation (physical
   location) of the Home Agent entity.  The placement of the Home Agent
   in the fixed infrastructure is assumed by the most common deployments
   of connected vehicles.  The Home Agent in charge of the vehicle is
   situated in a data center owned and administered by the vehicle
   manufacturer.  Other similar placements consider the fixed network of
   a regional representative of the manufacturer, or a local dealer.
   Further, in theory, it can be considered that a Home Agent be placed
   inside a vehicle as well, although this has not been tested.
   Depending on this placement of the HA, the Mobile IP gap can vary.

   Note a new requirement has been developped recently in the DMM
   Working Group.  The distributed mobility management requirement REQ1
   in [RFC7333] states that DMM solutions must enable traffic to avoid
   traversing a single mobility anchor far from the optimal route.  This
   may help placing a Home Agent nearer to the access network (rather
   than in a data center).  In addition to this requirement, it may be
   necessary to dynamically migrate the Home Agent to a place near the
   vehicle, as it moves across borders or travel long distances.

14.3.  AODVv2 protocol

   The AODVv2 protocol [I-D.ietf-manet-aodvv2] is a routing protocol
   used to build and find IP paths in an ad hoc network.  However,
   AODVv2 does not take into account preconfiguration of default routes.
   Default routes are extensively used in current networks carried in
   vehicles.  Good administration of default routes can greatly simplify
   routing in such networks.  This represents a gap.

15.  Security Considerations

   All government-to-vehicle and vehicle-to-government communications,
   without exception, require authentication.

   Some, but not all, communications from government-to-vehicle and
   vehicle-to-government require confidentiality to protect the content
   of the messages.  Some of these requirements, such as medical data,
   have the force of law.  Others are customary, or are based on common
   respect as requirements.




Petrescu, et al.         Expires April 21, 2016                [Page 16]


Internet-Draft      C-ACC at SDOs and IP Gap Analysis       October 2015


   Protocol information shared between the cooperating vehicles MUST
   also be protected in order to avoid disruption or attack on the
   vehicles operation.  Any modification or malicious insertion of
   protocol messages would carry with it a high risk of death and injury
   as well as tremendous disruption of other vehicular traffic.

16.  IANA Considerations

   mandatory

17.  Contributors

   Jim Misener (Qualcomm, SAE DSRC TC Chair), Masanori Misumi (Mazda,
   ISO TC204/WG14 Convenor), Michelle Wetterwald (Consult Europe), Tom
   Kurihara (mindspring).

18.  References

18.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC7333]  Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
              Korhonen, "Requirements for Distributed Mobility
              Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
              <http://www.rfc-editor.org/info/rfc7333>.

18.2.  Informative References

   [ACC-def]  Liang, C-Y. and H. Peng, "Optimal Adaptive Cruise Control
              with Guaranteed String Stability", April 1999.

   [CACC-def]
              Shladover, E., Nowakowski, C., Lu, X-Y., and X-Y. Ferlis,
              "Cooperative Adaptive Cruise Control (CACC) Definitions
              and Operating Concepts", April 2015.

   [ETSI-CACC]
              ETSI Technical Report TR 103 299, "Cooperative Adaptive
              Cruise Control (C-ACC) prestandardization study (ETSI-SAE
              join WI proposal); ongoing at the time of writing of this
              Internet Draft", 2015.






Petrescu, et al.         Expires April 21, 2016                [Page 17]


Internet-Draft      C-ACC at SDOs and IP Gap Analysis       October 2015


   [GPP-TR-22-803]
              3GPP, "Feasibility study for Proximity Services (ProSe)",
              June 2013.

   [GPP-TR-22-885]
              3GPP, "Study on LTE Support for V2X Services", April 2015.

   [GPP-TS-22-278]
              3GPP, "Service requirements for the Evolved Packet System
              (EPS)", December 2014.

   [I-D.ietf-manet-aodvv2]
              Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L., and
              V. Mercieca, "Ad Hoc On-demand Distance Vector Routing
              Version 2 (AODVv2)", draft-ietf-manet-aodvv2-12 (work in
              progress), October 2015.

   [I-D.liu-its-scenario]
              Liu, D., "Scenario of Intelligent Transportation System",
              draft-liu-its-scenario-00 (work in progress), March 2015.

   [I-D.petrescu-ipv6-over-80211p]
              Petrescu, A., Pfister, P., Benamar, N., and T.
              Leinmueller, "Transmission of IPv6 Packets over IEEE
              802.11p Networks", draft-petrescu-ipv6-over-80211p-02
              (work in progress), June 2014.

   [ISO-21210]
              ISO, "21210: TC ITS - WG CALM - IPv6 Networking -
              International Standard", 2014.

   [ISO-21217]
              ISO, "21217: TC ITS - WG CALM - Architecture -
              International Standard", 2014.

   [ISO-CACC]
              ISO, "PWI 20035 Intelligent Transport Systems -
              Cooperative Adaptive Cruise Control Systems (CACC) -
              Performance requirements and test procedures, Reference
              number 20035; ongoing work at the time of writing of this
              Internet Draft.", 2015.

   [its-infocomm-CACC]
              ITS Info-communications Forum of Japan, "Experimental
              Guideline for Inter-vehicle Communication Messages; ITS
              Forum RC-013 Ver. 1.0", 2014.





Petrescu, et al.         Expires April 21, 2016                [Page 18]


Internet-Draft      C-ACC at SDOs and IP Gap Analysis       October 2015


   [ITU-V2V]  ITU, "Question 27/16 - Vehicle gateway platform for
              telecommunications/ITS services/applications; ongoing work
              at the time of writing this Internet Draft.", 2015.

   [METIS-D1.1]
              Fallgren, M. and B. Timus, "Scenarios, requirements and
              KPIs for 5G mobile and wireless system", April 2013.

   [SAE-V2V]  SAE International (Society for Automotive Engineering),
              J2945/1; ongoing work at the time of writing this Internet
              Draft., "On-board System Requirements for V2V Safety
              Communications", 2015.

Appendix A.  ChangeLog

   The changes are listed in reverse chronological order, most recent
   changes appearing at the top of the list.

   From -03 to -04:

   o  Updated the perspective from SAE with respect to work on V2V
      requirements for safety.

   o  Clarified the IEEE 1609 point of view by which C-ACC use IEEE 1609
      protocols.

   o  Added authors' point of view of IEEE-ISO harmonization, which may
      have a relationship to vehicle-to-vehicle communications.

   o  Added ITU-T Question 27 of Study Group 16 description mentioning
      V2V communications.

   o  Added a section on Japan's ARIB and ITS info-comm documents which
      describe C-ACC and other inter-vehicle services in the 700MHz
      band.  Added an example of car manufacturer with product on the
      market at the time of writing implementing some of these features.

   o  Clarification of HA placement conditioning the Mobile IP gap
      discussion.

   o  Editorial improvements, citations added, terminology section
      improved.

   From -01 to -02:

   o  Added perspectives on C-ACC and Platooning from ETSI, SAE, and
      IEEE P1609.  Updated the perspective from ISO.




Petrescu, et al.         Expires April 21, 2016                [Page 19]


Internet-Draft      C-ACC at SDOs and IP Gap Analysis       October 2015


   o  Added Gap Analysis: what are the gaps between what existing
      protocols ND, Mobile IP and AODV can do and what is needed to
      realize a C-ACC and Platooning use-case with a V2V topology?

Authors' Addresses

   Alexandre Petrescu (editor)
   CEA, LIST
   CEA Saclay
   Gif-sur-Yvette , Ile-de-France   91190
   France

   Phone: +33169089223
   Email: Alexandre.Petrescu@cea.fr


   James Huang
   Huawei Technologies
   Shenzhen
   China

   Email: james.huang@huawei.com


   Thierry Ernst
   Mines ParisTech
   Paris   75006
   France

   Email: Thierry.Ernst@mines-paristech.fr


   Rex Buddenberg
   " "
   US

   Email: buddenbergr@gmail.com


   Charles E. Perkins
   Futurewei Inc.
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Phone: +1-408-330-4586
   Email: charliep@computer.org




Petrescu, et al.         Expires April 21, 2016                [Page 20]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/