One document matched: draft-petrescu-its-cacc-sdo-02.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-02.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>
" "
</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 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 developped at least 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 is understood as a
formation of chains of automobiles following each other at
constant speed, in an automated manner. This is to offer
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 related ISO standards. 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 a 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 data packet exchanges
between vehicles (in addition to more immediate indices 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 C-ACC and Platooning use-cases as
described at ETSI, IEEE, SAE, ISO, 3GPP and more. These
use-cases are widely accepted as Vehicle-to-Vehicle
applications.
</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>
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 case, 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>
</section>
<section anchor="IEEE" title="IEEE P1609 perspective on
communications for C-ACC and Platooning">
<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 (under development) towards realization of a reference
architecture.
</t>
<t>
The SAE DSRC TC activities are in cooperative agreement to
ETSI ITS WG1, as there are information exchanges between the
two bodies.
</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 "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 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>
<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>
For example, the IEEE 1609.3 WSMP and WSA messages have
recently been harmonized with ISO 29281-1 FNTP and ISO 24102-5
FSAP.
</t>
<t>
C-ACC and Platooning are (C-)ITS services that will get
deployed as ITS applications involving ITS application
instances being installed on ITS stations in vehicles. These
applications can and will make use of any and all available
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="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="gap" title="Gap Analysis">
<t>
It is generally agreed that an entire IP network is 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 fixed along the road, 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 the gap of the ND protocol
- it can not realize 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 is 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>
</section>
<section title="AODV protocol">
<t>
The AODV protocol is a routing protocol used to build and
find IP paths in a MANET network. However, this protocol
does not take into account default routes. Default routes
are extensively used in current networks carried in
vehicles. The good administration of these routes simplify
to a large extent the 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 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>
Jim Misener (Qualcomm, SAE DSRC TC Chair), Masanori Misumi
(Mazda, ISO TC204/WG14 Convenor), Michelle Wetterwald
(FBConsulting, ETSI active member), Hans-Joachim Fischer,
Richard "Dick" Roy.
</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 -01 to -02:
<list style='symbols'>
<t>
Added perspectives on C-ACC and Platooning from ETSI, SAE,
IEEE P1609 and ISO-IEEE Harmonization. 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>
<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:30:24 |