One document matched: draft-petrescu-its-cacc-sdo-05.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- <?xml version="1.0" encoding="US-ASCII"?> -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"
[
<!ENTITY RFC2119 PUBLIC ""
"http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC7333 PUBLIC ""
"http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7333.xml">
<!ENTITY DRAFT-IPv6-over-11p SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.petrescu-ipv6-over-80211p.xml">
<!ENTITY DRAFT-liu-its-scenario SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.liu-its-scenario.xml">
<!ENTITY DRAFT-ietf-manet-aodvv2 SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-manet-aodvv2.xml">
]
>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<rfc category="info"
docName="draft-petrescu-its-cacc-sdo-05.txt"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic ipr values:
trust200902, noModificationTrust200902,
noDerivativesTrust200902, or pre5378Trust200902 you can add the
attributes updates="NNNN" and obsoletes="NNNN" they will
automatically be output with "(if approved)" -->
<front>
<title abbrev="C-ACC at SDOs and IP Gap Analysis">
Cooperative Adaptive Cruise Control and Platooning at SDOs and
Gap Analysis
</title>
<author initials='A.' surname="Petrescu" fullname='Alexandre Petrescu'
role="editor">
<organization>CEA, LIST</organization>
<address>
<postal>
<street>
CEA Saclay
</street>
<city>
Gif-sur-Yvette
</city>
<region>
Ile-de-France
</region>
<code>
91190
</code>
<country>
France
</country>
</postal>
<phone>
+33169089223
</phone>
<email>
Alexandre.Petrescu@cea.fr
</email>
</address>
</author>
<author initials='J.' surname="Huang" fullname='James Huang'>
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city>Shenzhen</city>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone></phone>
<email>james.huang@huawei.com</email>
</address>
</author>
<author initials='T.' surname="Ernst" fullname='Thierry Ernst'>
<organization>
Mines ParisTech
</organization>
<address>
<postal>
<street>
</street>
<city>
Paris
</city>
<region>
</region>
<code>
75006
</code>
<country>
France
</country>
</postal>
<phone>
</phone>
<email>
Thierry.Ernst@mines-paristech.fr
</email>
</address>
</author>
<author initials='R.' surname="Buddenberg" fullname="Rex Buddenberg">
<organization>
Retired
</organization>
<address>
<postal>
<street>
</street>
<city>
</city>
<region>
</region>
<code>
</code>
<country>
US
</country>
</postal>
<phone>
</phone>
<email>
buddenbergr@gmail.com
</email>
</address>
</author>
<author fullname="Charles E. Perkins" initials="C.E." surname="Perkins">
<organization abbrev="Futurewei">Futurewei Inc. </organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<code>95050</code>
<region>CA</region>
<country>USA</country>
</postal>
<phone>+1-408-330-4586</phone>
<email>charliep@computer.org</email>
</address>
</author>
<date/>
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>Network Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc, IETF is fine for
individual submissions. If this element is not present, the
default is "Network Working Group", which is used by the RFC
Editor as a nod to the history of the IETF. -->
<keyword>
C-ACC, Platooning, V2V, Vehicle-to-Vehicle communications, LTE
D2D, device-to-device communications
</keyword>
<!-- Keywords will be incorporated into HTML output files in a
meta tag but they have no effect on text or nroff output. If
you submit your draft to the RFC Editor, the keywords will be
used for the search engine. -->
<abstract>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Cooperative Adaptive Cruise Control (C-ACC) and Platooning
are two use-cases described recently by other Standards
Development Organizations (SDOs). C-ACC <xref
target='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.
</t>
<t>
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 <xref target='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.
</t>
<t>
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.
</t>
<t>
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).
</t>
<t>
This document presents the V2V-based C-ACC and Platooning
use-cases as described at ETSI <xref target='ETSI-CACC'/>,
SAE <xref target="SAE-V2V"/>, ISO <xref target="ISO-CACC"/>,
3GPP <xref target="GPP-TR-22-885"/>, ITU <xref
target="ITU-V2V"/>, ITS Info-communications Forum of Japan
<xref target="its-infocomm-CACC"/> and more. These
use-cases are widely accepted as examples of
Vehicle-to-Vehicle applications.
</t>
<t>
In emergency settings the concepts of direct
vehicle-to-vehicle communications are of paramount
importance. FirstNet, as described
<!-- CEP: Citation needed. -->
later in this document, covers V2V, V2I and V2I2V
communication needs, together with strong security
requirements.
</t>
<t>
In the market, several systems for vehicular communications
have demonstrated a number of benefits in the context of
vehicle-to-vehicle communications.
<!-- CEP: Citations needed. -->
<list style='symbols'>
<t>
The Sentinel system is used between vehicles to warn each other
about approach;
</t>
<t>
WAZE on smartphones created a community where
users influence others about the route choice;
</t>
<t>
iRezQ and Coyote communicate between vehicles, via
infrastructure, about route risks.
</t>
</list>
</t>
<!-- <t> -->
<!-- <figure align="center"> -->
<!-- <artwork align="center"> -->
<!-- <![CDATA[ -->
<!-- the figure verbatim -->
<!-- ]]> -->
<!-- </artwork> -->
<!-- </figure> -->
<!-- </t> -->
<t>
In <xref target="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.
</t>
</section>
<section title="Terminology">
<t>
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
<xref target="RFC2119">RFC 2119</xref>.
</t>
<t>
3GPP: Third Generation Partnership Project.
</t>
<t>
3G: Third Generation.
</t>
<t>
4G: Fourth Generation.
</t>
<t>
5G: Fifth Generation of mobile networks.
</t>
<t>
apps: applications.
</t>
<t>
AODV: Ad-hoc On-demand Distance Vector.
</t>
<t>
ARIB: Association of Radio Industries and Businesses.
</t>
<t>
BSS: Basic Service Set.
</t>
<t>
C-ACC: Cooperative Adaptive Cruise Control.
</t>
<t>
CAM: Cooperative Awareness Message.
</t>
<t>
CC: Cruise Control.
</t>
<t>
CEN: European Committee for Standardizatin (Comité européen de
normalisation, fr.)
</t>
<t>
DeNM: Decentralized Environmental Notification Message.
</t>
<t>
DMM: Distributed Mobility Management.
</t>
<t>
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.
</t>
<t>
E2E: end-to-end.
</t>
<t>
EMS: Emergency and Medical System providers.
</t>
<t>
EPC: Evolved Packet Core.
</t>
<t>
ETSI: European Telecommunications Standards Institute.
</t>
<t>
E-UTRAN: Evolved Universal Terrestrial Radio Access Network.
</t>
<t>
EU: European Union.
</t>
<t>
FAST: fast.
</t>
<t>
FCC: Federal Communications Commision.
</t>
<t>
FNTP: Fast Networking and Transport layer Protocol.
</t>
<t>
FSAP: Fast Service Advertisement Protocol.
</t>
<t>
I2V: Infrastructure to Vehicle.
</t>
<t>
ICT: Information and Communication Technologies.
</t>
<t>
IEEE: Institute of Electrical and Electronics Engineers.
</t>
<t>
IoT: Internet of Things.
</t>
<t>
IP: Internet Protocol.
</t>
<t>
IPv6: Internet Protocol version 6.
</t>
<t>
IPTV: Internet Protocol Television
</t>
<t>
ISO: International Organization for Standardization.
</t>
<t>
ITS: Intelligent Transportation Systems.
</t>
<t>
ITS-G5: ITS Gigahertz Five.
</t>
<t>
ITU: International Telecommunication Union.
</t>
<t>
ITU-T: Telecommunication Standardization Sector of the
International Telecommunication Union.
</t>
<t>
IVC-RVC:
</t>
<t>
LiFi: Light Fidelity.
</t>
<t>
LTE
: Long-Term Evolution.
</t>
<t>
METIS: Mobile and wireless communications Enablers for
Twenty-twenty (2020) Information Society.
</t>
<t>
OBU: On-Board Unit.
</t>
<t>
OCB: Outside the Context of a BSS identifier.
</t>
<t>
PHY: physical layer.
</t>
<t>
ProSe: Proximity Service.
</t>
<t>
PSAP: Public Safety Answering Points.
</t>
<t>
RA: Router Advertisement.
</t>
<t>
SAE: Society of Automotive Engineers.
</t>
<t>
SDO: Standards Development Organization.
</t>
<t>
SG: Study Group.
</t>
<t>
TC: Technical Committee.
</t>
<t>
TR: Technical Report.
</t>
<t>
UE: User Equipment.
</t>
<t>
US: United States.
</t>
<t>
V2V: Vehicle-to-Vehicle communications.
</t>
<t>
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.
</t>
<t>
V2I2V: Vehicle to Infrastructure to Vehicle.
</t>
<t>
WAVE: Wireless Access for Vehicular Environments.
</t>
<t>
WG1: Work Group 1.
</t>
<t>
WiFi: Wireless Fidelity.
</t>
<t>
WLAN: Wireless Local Area Network.
</t>
</section>
<section anchor="etsi"
title="ETSI ITS C-ACC and Platooning use-case and reqs">
<t>
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.
</t>
<t>
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.
</t>
<t>
The C-ACC definition in TR 103 299 will soon be made public.
</t>
</section>
<section anchor="IEEE"
title="The C-ACC Use of Protocols specified by IEEE 1609 Standards">
<t>
The C-ACC interacts with the presentation layer services which
in turn use the communication protocols specified in IEEE
1609 standards.
</t>
<t>
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. 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.
</t>
</section>
<section anchor="SAE" title="SAE perspective on C-ACC and Platooning">
<t>
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.
</t>
<t>
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.
</t>
<t>
The SAE DSRC TC activities are in cooperative agreement to
ETSI ITS WG1, as there are information exchanges between the
two bodies <xref target="SAE-V2V"/>.
</t>
</section>
<section title="3GPP and EU projects using LTE Device-to-Device concepts"
anchor="pp"
>
<section title="3GPP">
<t>
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
<xref target="GPP-TR-22-803"/>.
</t>
<t>
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 <xref target="GPP-TS-22-278"/>.
</t>
<t>
The work on ProSe is initiated in 3GPP Release 12. Some
enhancements are being added in Release 13,
<!-- CEP: Explanation needed. -->
e.g. Restricted ProSe Discovery. Some use cases are
identified in <xref target="GPP-TR-22-803"/>, but most of
which 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.
</t>
<t>
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.
</t>
<t>
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:
<list style='symbols'>
<t>
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. <xref target="METIS-D1.1"/>
already propose some requirements, but those are
intended for future mobile network, which may be too
critical for LTE.
</t>
<t>
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.
</t>
<t>
Study of possibility to add enhancements to ProSe, and
to make it able to support and enhance DSRC.
</t>
<t>
Study of using existing LTE technologies for
unicast/multicast/broadcast communication.
</t>
</list>
</t>
<t>
<xref target="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.
</t>
<t>
In <xref target="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 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.
</t>
</section>
<section title="METIS">
<t>
METIS is co-funded by the European Commission as an
Integrated Project under the Seventh Framework Programme for
research and development (FP7).
</t>
<t>
METIS defines test cases and requirements of "Traffic
safety and efficiency", as depicted in <xref
target="METIS-D1.1"/>, which is intended for 5G in 2020
but may also be applicable for LTE and subsequent systems.
</t>
<t>
The use cases include:
<list style='numbers'>
<t>
Dangerous situation that can be avoided by means of V2V
communications.
</t>
<t>
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).
</t>
<t>
Assistance services that can improve traffic efficiency
by means of V2X communications, e.g. traffic sign
recognition and green light assistance.
</t>
<t>
Autonomous platooning
increase traffic flow and reduce fuel consumption and
emissions.
</t>
<t>
Automated vehicles.
</t>
</list>
</t>
<t>
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.
</t>
</section>
</section>
<section anchor="iso" title="ISO perspective on V2V">
<t>
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" <xref
target='ISO-21217'/>. This communication 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.)
</t>
<t>
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.
</t>
<t>
The architecture includes the possibility to communicate using
IPv6 <xref target='ISO-21210'/> or non-IP (ISO FNTP, currently
being harmonized with IEEE WAVE).
</t>
<t>
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.
</t>
</section>
<section title="ISO-IEEE Harmonization">
<t>
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.
</t>
<t>
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 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor="itu" title="V2V communications at ITU">
<t>
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.
</t>
<t>
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.
</t>
<t>
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).
</t>
<t>
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.
</t>
<t>
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 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.
</t>
<t>
The description of ITU-T Question 27/16 is publicly available
on the web on the itu.int website.
</t>
</section>
<section anchor="arib-its"
title="ARIB and ITS Info-comm use of CACC and V2V concepts">
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor="firstnet"
title="FirstNet EMS use of LTE and IP in V2I2V">
<t>
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.
</t>
<t>
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:
<list style='symbols'>
<t>
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.
</t>
<t>
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.
</t>
<t>
Emergency communications from vehicles' occupants to
government entities such as Public Safety Access Points
(PSAPs, also known as 911 operators in US).
</t>
</list>
</t>
<t>
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).
</t>
<t>
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.
</t>
<t>
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.
</t>
<!-- CEP: noteworthy gap. -->
</section>
<section anchor="apps" title="Internet apps: WAZE, iRezQ, Coyote, Sentinel">
<t>
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).
</t>
<t>
Some use vehicle-to-infrastructure-to-vehicle IP paths,
whereas others involve direct vehicle-to-vehicle paths
(without infrastructure).
</t>
<t>
These applications are described in more detail in a recent
Internet Draft titled "Scenario of Intelligent Transportation
System" <xref target="I-D.liu-its-scenario"/>.
</t>
</section>
<section anchor="car-mf-v2v-logos"
title="Car manufacturer labels with V2V features">
<t>
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 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.
</t>
</section>
<section anchor="gap" title="Gap Analysis">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<section title="Neighbor Discovery protocol">
<t>
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.
</t>
</section>
<section title="Mobile IP protocol">
<t>
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-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.
</t>
<t>
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.
</t>
<t>
Note a new requirement has been developped recently in the
DMM Working Group. The distributed mobility management
requirement REQ1 in <xref target="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.
</t>
</section>
<section title="AODVv2 protocol">
<t>
The AODVv2 protocol <xref target="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.
</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>
All government-to-vehicle and vehicle-to-government
communications, without exception, require authentication.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
mandatory
</t>
</section>
<section anchor="Contributors"
title="Contributors">
<t>
Jim Misener (Qualcomm, SAE DSRC TC Chair), Masanori Misumi
(Mazda, ISO TC204/WG14 Convenor), Michelle Wetterwald
(Consult Europe), Tom Kurihara (mindspring).
</t>
</section>
<!-- <section anchor="Acknowledgements" -->
<!-- title="Acknowledgements"> -->
<!-- <t> -->
<!-- The authors would like to acknowledge . -->
<!-- </t> -->
<!-- </section> -->
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC2119;
&RFC7333;
</references>
<references title="Informative References">
&DRAFT-IPv6-over-11p;
&DRAFT-liu-its-scenario;
&DRAFT-ietf-manet-aodvv2;
<reference anchor='CACC-def'>
<front>
<title>
Cooperative Adaptive Cruise Control (CACC) Definitions and
Operating Concepts
</title>
<author initials='E.' surname='Shladover'
fullname='Steven Shladover'>
<organization>
California PATH, UC Berkeley
</organization>
</author>
<author initials='C.' surname='Nowakowski'
fullname='Christopher Nowakowski'>
<organization>
California PATH, UC Berkeley
</organization>
</author>
<author initials='X-Y.' surname='Lu'
fullname='Xiao-Yun Lu'>
<organization>
California PATH, UC Berkeley
</organization>
</author>
<author initials='X-Y.' surname='Ferlis'
fullname='Robert Ferlis'>
<organization>
Federal Highway Administration
</organization>
</author>
<date year='2015' month='April' />
</front>
<format type="PDF"
target='http://www.researchgate.net/publication/273204405_COOPERATIVE_ADAPTIVE_CRUISE_CONTROL_%28CACC%29_DEFINITIONS_AND_OPERATING_CONCEPTS' />
</reference>
<reference anchor='ACC-def'>
<front>
<title>
Optimal Adaptive Cruise Control with Guaranteed String
Stability
</title>
<author initials='C-Y.' surname='Liang'
fullname='Chi-Ying Liang'>
<organization>
Uni Michigan
</organization>
</author>
<author initials='H.' surname='Peng'
fullname='Huei'>
<organization>
Uni Michigan
</organization>
</author>
<date year='1999' month='April' />
</front>
<format type="PDF"
target='http://www-personal.umich.edu/~hpeng/VSD_1999_Liang.pdf' />
</reference>
<reference anchor='METIS-D1.1'>
<front>
<title>
Scenarios, requirements and KPIs for 5G mobile and
wireless system
</title>
<author initials='M.' surname='Fallgren'
fullname='Mikael Fallgren'>
<organization>
Ericsson AB
</organization>
</author>
<author initials='B.' surname='Timus' fullname='Bogdan Timus'>
<organization>
Ericsson AB
</organization>
</author>
<date year='2013' month='April' />
</front>
</reference>
<reference anchor="ETSI-CACC">
<front>
<title>
Cooperative Adaptive Cruise Control (C-ACC)
prestandardization study (ETSI-SAE join WI proposal);
ongoing at the time of writing of this Internet Draft
</title>
<author initials='' surname='' fullname=''>
<organization>
ETSI Technical Report TR 103 299
</organization>
</author>
<date year='2015' />
</front>
</reference>
<reference anchor="SAE-V2V">
<front>
<title>
On-board System Requirements for V2V Safety Communications
</title>
<author initials='' surname='' fullname=''>
<organization>
SAE International (Society for Automotive Engineering),
J2945/1; ongoing work at the time of writing this
Internet Draft.
</organization>
</author>
<date year='2015' />
</front>
</reference>
<reference anchor="ISO-CACC">
<front>
<title>
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.
</title>
<author initials='' surname='' fullname=''>
<organization>
ISO
</organization>
</author>
<date year='2015' />
</front>
</reference>
<reference anchor="ITU-V2V">
<front>
<title>
Question 27/16 - Vehicle gateway platform for
telecommunications/ITS services/applications; ongoing work
at the time of writing this Internet Draft.
</title>
<author initials='' surname='' fullname=''>
<organization>
ITU
</organization>
</author>
<date year='2015' />
</front>
</reference>
<reference anchor="its-infocomm-CACC">
<front>
<title>
Experimental Guideline for Inter-vehicle Communication
Messages; ITS Forum RC-013 Ver. 1.0
</title>
<author initials='' surname='' fullname=''>
<organization>
ITS Info-communications Forum of Japan
</organization>
</author>
<date year='2014' />
</front>
</reference>
<reference anchor="GPP-TR-22-803">
<front>
<title>
Feasibility study for Proximity Services (ProSe)
</title>
<author initials='' surname='' fullname=''>
<organization>
3GPP
</organization>
</author>
<date year='2013' month='June' />
</front>
<format type="zip"
target='http://www.3gpp.org/ftp/specs/archive/22_series/22.803/22803-c20.zip' />
</reference>
<reference anchor='GPP-TS-22-278'>
<front>
<title>
Service requirements for the Evolved Packet System (EPS)
</title>
<author initials='' surname='' fullname=''>
<organization>
3GPP
</organization>
</author>
<date year='2014' month='December' />
</front>
<format type="zip"
target='http://www.3gpp.org/ftp/specs/archive/22_series/22.278/22278-d20.zip' />
</reference>
<reference anchor='GPP-TR-22-885'>
<front>
<title>
Study on LTE Support for V2X Services
</title>
<author initials='' surname='' fullname=''>
<organization>
3GPP
</organization>
</author>
<date year='2015' month='April' />
</front>
<format type=""
target='' />
</reference>
<reference anchor='ISO-21217'>
<front>
<title>
21217: TC ITS - WG CALM - Architecture -
International Standard
</title>
<author initials='' surname='' fullname=''>
<organization>
ISO
</organization>
</author>
<date year='2014' month='' />
</front>
<format type=""
target='http://www.iso.org/iso/catalogue_detail.htm?csnumber=61570' />
</reference>
<reference anchor='ISO-21210'>
<front>
<title>
21210: TC ITS - WG CALM - IPv6 Networking -
International Standard
</title>
<author initials='' surname='' fullname=''>
<organization>
ISO
</organization>
</author>
<date year='2014' month='' />
</front>
<format type=""
target='http://www.iso.org/iso/catalogue_detail.htm?csnumber=46549' />
</reference>
</references>
<section anchor='changelog'
title='ChangeLog'>
<t>
The changes are listed in reverse chronological order, most
recent changes appearing at the top of the list.
</t>
<t>
From -04 to -05:
<list style='symbols'>
<t>
Minor updates.
</t>
</list>
</t>
<t>
From -03 to -04:
<list style='symbols'>
<t>
Updated the perspective from SAE with respect to work on
V2V requirements for safety.
</t>
<t>
Clarified the IEEE 1609 point of view by which C-ACC use
IEEE 1609 protocols.
</t>
<t>
Added authors' point of view of IEEE-ISO harmonization,
which may have a relationship to vehicle-to-vehicle
communications.
</t>
<t>
Added ITU-T Question 27 of Study Group 16 description
mentioning V2V communications.
</t>
<t>
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.
</t>
<t>
Clarification of HA placement conditioning the Mobile IP
gap discussion.
</t>
<t>
Editorial improvements, citations added, terminology
section improved.
</t>
</list>
</t>
<t>
From -01 to -02:
<list style='symbols'>
<t>
Added perspectives on C-ACC and Platooning from ETSI, SAE,
and IEEE P1609. Updated the perspective from ISO.
</t>
<t>
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?
</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 16:29:08 |