One document matched: draft-petrescu-its-cacc-sdo-01.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 DRAFT-IPv6-over-11p SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.petrescu-ipv6-over-80211p.xml">
<!-- <!ENTITY DRAFT-liu SYSTEM -->
<!-- "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.liu-its-scenario.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-01.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 and Platooning at SDOs">
Cooperative Adaptive Cruise Control and Platooning at SDOs
</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>
" "
</organization>
<address>
<postal>
<street>
</street>
<city>
</city>
<region>
</region>
<code>
</code>
<country>
US
</country>
</postal>
<phone>
</phone>
<email>
buddenbergr@gmail.com
</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 1609,
SAE and 3GPP.
</t>
<t>
C-ACC and Platooning involve concepts of direct
vehicle-to-vehicle, and device-to-device communications, which
are developped by 3GPP and precursory by the METIS EU project.
They are illustrated very clearly in emergency settings such
as FirstNet.
</t>
<t>
IP messages - instead of link-layer messages - are pertinent
for C-ACC and Platooning use-cases because applications for
road safety such as WAZE, iRezQ and Coyote (currently
involving infrastructure) are IP messages, and proved
succesful in deployments. Applications such as Sentinel are
direct between vehicles but are not IP, currently.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Cooperative Adaptive Cruise Control and Platooning are two
use-cases described recently at particular Standards
Development Organizations. C-ACC describes the formation of
chains of automobiles following each other at constant
speed, in an automatic manner. This is to offer 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). C-ACC aims at 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 a concept related to larger vehicles following
each other. The goal in this case is not necessarily
comfort, but the expected gains in terms of gas consumption:
when large vehicles can follow each other at small distance
the air-drag is much lower, directly influencing on gas
consumption, tyre use, and more.
</t>
<t>
Both C-ACC and Platooning are relying on information
exchange between vehicles. 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 describes the C-ACC and Platooning use-cases
as described at ETSI ITS. These use-cases are widely
accepted as Vehicle-to-Vehicle applications. For this
reason, we present the perspectives on V2V from IEEE, SAE,
ISO and LTE.
</t>
<t>
In emergency settings the concepts of direct
vehicle-to-vehicle communications are of paramount
importance. FirstNet, an overarching example described
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. The Sentinel system is
used between vehicles to warn each other about approach; the
WAZE application on smartphones created a community where
users influence others about the route choice; the iRezQ and
Coyote applications communicate between vehicles, via
infrastructure, about route risks.
</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 used in direct vehicle-to-vehicle
communications. It is obviously not the only link layer
pertinent for V2V.
</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>
C-ACC: Cooperative Adaptive Cruise Control.
</t>
<t>
V2V: Vehicle-to-Vehicle communications.
</t>
</section>
<section anchor="etsi"
title="ETSI ITS C-ACC and Platooning use-case and reqs">
<t>
</t>
</section>
<section anchor="IEEE" title="IEEE 1609 perspective on vehicle-to-vehicle communications">
<t>
</t>
</section>
<section anchor="SAE" title="SAE perspective on C-ACC and Platooning">
<t>
</t>
</section>
<section title="3GPP SDO and EU projects using LTE Device-to-Device concepts"
anchor="pp"
>
<section title="3GPP">
<t>
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,
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. walking
people, not for vehicles moving at high speed, for example
the latency in ProSe communication may be a problem for
V2X.
</t>
<t>
Although ProSe does not support V2X communication before
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 support group and broadcast communication by means of
a common communication path established between the UEs.
</t>
<t>
There are some efforts at 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:
<list style='numbers'>
<t>
To address the V2X use cases in 3GPP. The use cases may
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>
The above are just some examples, not an exhaustive 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, and 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 should broadcast a goodbye message,
and the driver 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 beyond.
</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>
Platooning (or road trains) in an autonomous manner to
increase traffic flows and reduce fuel consumption and
emissions.
</t>
<t>
Highly automated vehicles.
</t>
</list>
</t>
<t>
To support the above use cases, METIS works out the
corresponding network requirements, such as E2E latency
should be within 5ms, required 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 (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 layers (access technologies, network,
transport, facilities and applications) of a typical
communications protocol stack. 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>
</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 specific use-cases 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='numbers'>
<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 foot-borne).
</t>
<t>
It is clear that FirstNet overlaps to 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,
development of which is fostered by FirstNet. Several
Internet applications would need rework to handle high
availability, security and assured access needs of emergency
services.
</t>
</section>
<section anchor="apps" title="Internet apps: WAZE, iRezQ, Coyote, Sentinel">
<t>
Applications using the Internet have been developped 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
draft-liu-its-scenario-00.txt issued on March 9th, 2015,
authored by Dapeng Liu.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
All government-to-vehicle and vehicle-to-government
communications require authenticity; there will be no
exceptions.
</t>
<t>
Some, but not all, communications from government-to-vehicle
and vehicle-to-government require confidentiality (some of
these requirements, such as medical data, have the force of
law, many have custom or respect as the requirements base).
</t>
<t>
These requirements pertain to the content.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
mandatory
</t>
</section>
<section anchor="Contributors"
title="Contributors">
<t>
contributors
</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;
</references>
<references title="Informative References">
&DRAFT-IPv6-over-11p;
<!-- &DRAFT-liu; -->
<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>
<format type="PDF"
target='https://www.metis2020.com/wp-content/uploads/deliverables/METIS_D1.1_v1.pdf' />
</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 nil to draft-petrescu-its-cacc-sdo-00.xml:
<list style='symbols'>
<t>
initial version
</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 16:27:06 |