One document matched: draft-petrescu-its-scenarios-reqs-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<?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 category="info"
docName="draft-petrescu-its-scenarios-reqs-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="Scenarios and Reqs for IP in ITS">
Scenarios and Requirements
for IP in Intelligent Transportation
Systems
</title>
<author initials='A.' surname="Petrescu" fullname='Alexandru Petrescu'>
<organization>CEA</organization>
<address>
<postal>
<street>
Communicating Systems Laboratory, Point Courrier 173
</street>
<city>
Palaiseau
</city>
<region>
</region>
<code>
F-91120
</code>
<country>
France
</country>
</postal>
<phone>
+33(0)169089223
</phone>
<email>
alexandru.petrescu@cea.fr
</email>
</address>
</author>
<author initials='C.' surname="Janneteau"
fullname='Christophe Janneteau'>
<organization>CEA</organization>
<address>
<postal>
<street>
Communicating Systems Laboratory, Point Courrier 173
</street>
<city>
Palaiseau
</city>
<region>
</region>
<code>
F-91120
</code>
<country>
France
</country>
</postal>
<phone>
+33(0)169089182
</phone>
<email>
christophe.janneteau@cea.fr
</email>
</address>
</author>
<author initials='M. M. B.' surname="Boc"
fullname='Michael Mathias Boc'>
<organization abbrev='CEA'>CEA, LIST</organization>
<address>
<postal>
<street>
Communicating Systems Laboratory, Point Courrier 173
</street>
<city>
Palaiseau
</city>
<region>
</region>
<code>
F-91120
</code>
<country>
France
</country>
</postal>
<phone>
+33 (0) 169083976
</phone>
<email>
michael.boc@cea.fr
</email>
</address>
</author>
<author initials='W.' surname="Klaudel"
fullname='Witold Klaudel'>
<organization>Renault</organization>
<address>
<postal>
<street>
1 Av. du Golf
</street>
<city>
Guyancourt
</city>
<region>
</region>
<code>
F-78288
</code>
<country>
France
</country>
</postal>
<phone>
+33(0)176845680
</phone>
<email>
witold.klaudel@renault.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>
IP, Internet Protocol, ITS, Intelligent Transportation Systems,
Mobile IPv6, Neighbor Discovery, Vehicle-to-Vehicle
communications, Vehicle-to-Vehicle-to-Infrastructure
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 draft describes scenarios of vehicular communications
that are considered pertinent to Intelligent Transportation
Systems. In these scenarios, the necessity of using IP
networking technologies and protocols is exposed.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The field of vehicular communications is encompassing a
large number of wired and wireless technologies. In
particular, the breakthrough advancements in wide-area
cellular telecommunications, the advent of inexpensive
hardware, impressively high bandwidth and low-cost data
subscription plans make possible new paradigms which put the
vehicle at the center of a communications ecosystem. It can
be observed that whereas only in the recent past linking
vehicles in a robust manner to a fixed infrastructure
represented endeavors available only to top categories, more
and more middle category vehicles are announced to take
advantage of data connectivity.
</t>
<t>
Communication protocols used in the fixed and mobile
(terminal) Internet can be applied in the scenarios
employing vehicles which communicate. A number of
particular aspects make vehicular communications different,
not least being the that mobility is the norm, rather than
the exception. At the same time, several protocols
developped at IETF are good candidates to form basis of
further development of IP protocols for vehicular
communications.
</t>
<t>
The use of Internet protocols in the vehicular scenarios may
prove advantageous from several standpoints:
<list style='symbols'>
<t>
immediate availability of a large number of applications
with an established customer base.
</t>
<t>
scalability: large numbers of inter-communicating
vehicles can be accommodated across large distances.
</t>
<t>
accessing heterogeneous, mixed and multiple-standard
link layer technologies.
</t>
</list>
</t>
<t>
The context of vehicular communications considers the use of
several classes of Internet protocols for vehicular
applications. One particular family of protocols is Mobile
IP. Its salient features characterize well several mobility
aspects such as reachability at permanent addresses,
seamless handovers and group mobility management. Earlier
documents at IETF idenfitied a number of scenarios and
potential requirements for further work towards improving
the Mobile IP protocols for a better adaptation in vehicular
environments (see for example the draft titled "Automotive
Industry Requirements for NEMO Route Optimization" edited
in 2009 <xref
target="I-D.ietf-mext-nemo-ro-automotive-req"/>.)
</t>
<t>
A Vehicle-to-Infrastructure scenario (V2I) is a typical
setting in which a vehicle uses a long-range wireless
interface (cellular, sattelite) to connect to a fixed
infrastructure. As a separate matter, scenarios of
Vehicle-to-Vehicle (V2V) communications consider direct
communications between vehicles, without, or with minimal,
assistance from the infrastructure. In areas where wireless
coverage is absent, Vehicle-to-Vehicle-to-Infrastructure
communications are scenarios where covered vehicles offer
access to non covered vehicles, in a multi-hop manner.
</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>
</section>
<section title="Scenarios">
<t>
Several scenarios of vehicular communications are described.
We choose a set of illustrative scenarios, described next, and
then followed by a list of high-level topologies which may be
considered in terms of IP communications (V2V, V2I, etc.)
</t>
<t>
Scenario 1: A rented car (for instance a autolib as in
Paris) is (will be) equipped with the car manufacturer
network (sensors, CAN bus monitoring, infotainement), the
car rental owner network (accidents detection, geolocation,
etc.), the insurer network for behavior detection (speed,
location, distance, etc.), and other stakeholders network
such as highway company, municipality public service company
(detection of free parking for instance), etc. Those
sub-networks may be interconnected together by one (mobile)
router that ensures stable IP connectivity.
</t>
<t>
Scenario 2: Because of the wide variety of available
wireless technologies, the vehicle should dispose of more
than one wireless interface towards the infrastructure. In
city center, Wi-Fi hotspots may provide Internet access at
crossing roads stops. In the suburbs, Internet Access may
only be available with LTE or 3G.
</t>
<t>
Scenario 3: An ambulance may need to stream video to the
main hospital requesting minimum bandwidth during the whole
operation. The mobile router should consider this
requirement and prevent other less important traffic from
the vehicle to have a negative impact on the stream.
</t>
<t>
Scenario 4: 802.11p may support the broadcast of alerts to
vehicles. If the mobile router hosts a 802.11p interface,
such alerts should be handled accordingly and routed to the
right subnetworks.
</t>
<t>
Scenario 5: The vehicle may have a large amount of data to
transfer to another vehicle but have only an Edge connection
with the infrastructure. The transmission of the data may
be delayed until a WiFi, 3G, or LTE connection becomes
available.
</t>
<t>
Scenario 6: MANET routing between vehicles may be
inefficient if the two communicating vehicles are not in
vicinity. By using geographical information, the mobile
router may know how to route data towards the destination
efficiently.
</t>
<t>
Scenario 7: The insurer (generic term), the car
manufacturer, and other stakeholder do not want to share
their (private) data. The insurer do not want to let data
coming from a network where the driver is active to have an
influence on the reported behavioral information.
</t>
<section title="Intra-Vehicular (V)">
<t>
Within one particular vehicle, an entire network may and
will be deployed. This network is constituted of routers,
hosts and other entities configured each with one or several
IP addresses. Devices within vehicles are reachable to
other vehicles and to Internet at large.
</t>
<t>
One illustration of an intra-vehicular network is depicted
in the next figure:
</t>
<figure align="center"
anchor="xml_topo0"
title="Topology for Vehicle-to-Infrastructure V2I Communications">
<artwork align="center">
<![CDATA[
| | ... | n interfaces to the outside of vehicle
---------------
| Mobile Router |
---------------
/ | \ m IP subnets within the vehicle
/ | \
|
---------
| D.Router|
/---------\
/ | \---CAN--
/ |
sensors \-----entertainment subnet
subnet
]]></artwork>
</figure>
<t>
This figure tries to illustrate the complexity of a
intra-vehicular network. Even though the first deployments
of intra-vehicular networks were being constructed using a
single IP subnet, the most recent advancements propose the
use of multiple subnets within one vehicle.
</t>
<t>
In this example deployment, the moving vehicle holds
on-board a Mobile Router. The MR is in charge of
communicating to the outside world. It is equipped with one
or several wireless interfaces towards the outside world
(the world 'wireless' should be understood largely as
'without wires'; near-field contact-less communications are
proposed for vehicular communications as well).
</t>
<t>
Within a vehicle, a dedicated router (D.Router) is in charge
of subnets whose purpose is more application specific. The
applications are typical vehicular, like the applications
communicating on CAN (Car Area Network). This router may
also be forwarding packets of less importance (less
constrained in terms of real time) which are related to
entertainment (e.g. video stream to a screen built into a
front seat).
</t>
<t>
Within one vehicle, there may thus be deployed several IP
subnets, with traffic separated, dedicated to particular
applications. The network within a vehicle may be formed by
Routers, Switches and Hosts. It is also very probable that
mobile devices carried by passengers connect to the
vehicle's network, in a dynamic manner (users would expect
and IP session ongoing on their personal terminal to
continue working when getting into and outside of a vehicle).
</t>
<t>
The IP addressing scheme for deployment in a vehicle is not
straightforward. The addresses should follow the pattern of
use of applications: constrained applications may need to be
separated from the entertainment applications right at the
addressing level. For example, it may be needed to assign
ULAs to some devices dedicated to some applications, Global
addresses to other devices and link-local addresses on links
where communication is local.
</t>
<t>
The topology of the intra-vehicular network may be
interpreted as a multi-stage deployment; the multiplicity of
stages is serving to protect against external attacks from
the Internet to the inherent mechanisms of the vehicle
dedicated CAN.
</t>
<t>
The Mobile Router deployed in a vehicle is in charge of
communications to the outside world. One example
application on the MR is the following: in case that two
versions of the IP protocol need to be deployed and
interoperable, then the MR may run a proxy HTTP function to
allow IPv6 clients on-board to query IPv4 servers in the
fixed Internet.
</t>
<t>
Some scenarios considered for vehicle communications need to
take into account that the vehicle is powered by very
complex schemes which include power-saving mechanisms as
well as eventual power distribution. It is important to
consider mechanisms to wake-up the vehicle by messages
coming from the outside network (IP Router Alert, or SMS of
LTE).
</t>
</section>
<section title="Vehicle-to-Infrastructure (V2I)">
<t>
This section describes the communication scenario in which
one mobile vehicle connects to a fixed infrastructure.
</t>
<t>
Topology:
</t>
<figure align="center"
anchor="xml_topo1"
title="Topology for Vehicle-to-Infrastructure V2I Communications">
<artwork align="center">
<![CDATA[
-------- /--------------+
| Vehicle|--- ---/Fixed |------>Internet
-------- wireless \Infrastructure |
link \--------------+
(long range)
]]></artwork>
</figure>
<t>
In this figure, the wireless link used between the vehicle
and the fixed infrastructure is of type 'long range' -
typically a cellular link terminal-infrastructure,
alternatively named a Wireless Metropolitan Area Network. A
vehicle-to-infrastructure scenario considers often that the
vehicle uses a cellular interface attached to an on-board
router.
</t>
<t>
A different V2I scenario involves the use of short-range
wireless links between the vehicle and the infrastructure.
For example, it is possible to use interfaces of type IEEE
802.11b, or 802.11p to connect to a fixed infrastructure,
which is itself connected to the Internet. The first IP hop
between the vehicle and the infrastructure is using a
short-range communication link.
</t>
</section>
<section title="Vehicle-to-Vehicle (V2V)">
<t>
Topology:
</t>
<figure align="center"
anchor="xml_topo2"
title="Topology for Vehicle-to-Vehicle V2V Communications">
<artwork align="center">
<![CDATA[
-------- --------
| Vehicle|-- --| Vehicle|
-------- wireless --------
link
(short-range)
]]></artwork>
</figure>
<t>
In this figure, the wireless link is of type short range.
One vehicle uses a interface of kind IEEE 802.11b, for
example, and communicates to another vehicle using same kind
of interface. Contrary to cellular links, the short-range
wireless links are active in smaller areas (in terms of
square meters of area). Typical examples of short-range
wireless links are IEEE 802.11b, or IEEE 802.11p.
</t>
<t>
There are several possibilities of using short-range
wireless between vehicles. In one scenario, the link uses
the ad-hoc mode of operation between the egress interfaces
of on-board vehicles. This works without the use of a fixed
infrastructure. In another scenario, the link may use the
'managed' mode of operation between the egress interfaces of
on-board vehicles; an Access Point is necessary for this to
operate; the Access Point may be elected among one of the
vehicles, or it may be deployed in a fixed manner along the
road.
</t>
<t>
A distinctive factor may be constructed between the V2V and
the V2I scenarios with respect to fixed infrastructure. At
one extreme, the presence of fixed infrastructure is
completely disallowed for V2V communications, and the
short-range communications are completely disallowed between
vehicles which perform V2I. Along the spectrum of
scenarios, one scenario is possible where fixed
infrastructure is deployed with the goal to support V2V
communications but without offering Internet access; this is
often the case with the scenarios currently described with
IEEE 802.11p. At another extreme, V2I communications may be
realized by building a complete infrastructure with moving
vehicles.
</t>
</section>
<section title="Vehicle-to-Vehicle-to-Infrastructure (V2V2I)">
<t>
Topology:
</t>
<figure align="center"
anchor="xml_topo3"
title="Topology for Vehicle-to-Vehicle-to-Infrastructure V2V2I Communications">
<artwork align="center">
<![CDATA[
-------- -------- /-------------+
| Vehicle|-- --| Vehicle|-- --/Fixed |----->Internet
-------- wireless -------- w \Infrastructure|
link link \-------------+
(short range) (long range)
]]></artwork>
</figure>
<t>
In Vehicle-to-Vehicle-to-Infrastructure (V2V2I)
communications a mix is realized between V2V communications
and V2I communications. For example, a subnet is
established between two vehicles in a V2V manner (e.g. using
the ad-hoc mode between egress interfaces of on-board
routers of vehicles), and one of the vehicles is
simultaneously connected to the fixed infrastructure (and to
the Internet) using a V2I cellular link.
</t>
</section>
<section title="Infrastructure Support">
</section>
</section>
<section title="Requirements">
<t>
<list style='symbols'>
<t>
R0. IP addressing within each vehicle.
</t>
<t>
R1. IP addressing on the interface between vehicles.
</t>
<t>
R2. Sub-networks support: Mobile router support several
sub-networks hosting stakeholder networks,
</t>
<t>
R3. Support of multiple interfaces: The vehicle (not
restricted to the MR physically) should support several
interfaces towards the infrastructure.
</t>
<t>
R4. Quality of Service: One stakeholder may request for a
minimum bandwidth for its applications. QoS should ensure
those minimums are taken into accounts.
</t>
<t>
R5. Broadcasted Alerts support: Along the highway, the MR
may receive alerts about accident through 802.11p.
</t>
<t>
R6. Store, Carry and Forward: Improve communication
efficiency by delaying transfer of information.
</t>
<t>
R7. Geographic information support: Efficient
inter-vehicular routing may take advantage of geographic
information (not restricted to geonetworking).
</t>
<t>
R8. Security: MR must prevent routing of packets between
sub networks and ensure protection of those data within
the vehicle.
</t>
<t>
R9. Continuity of ongoing sessions: it is desirable that
ongoing sessions between one device within the vehicle and
one device in the Internet is maintained ongoing during
vehicle movements, and upon handovers between
heterogeneous access points.
</t>
<t>
R10. Reachability at permanent home addresses: it is
desirable that each device connected inside a vehicle to
be reachable at a permanent fixed address, for all other
IP devices deployed in the Internet.
</t>
<t>
R11. It is desirable that devices connected in one
vehicle to be able to communicate directly to other
devices in a vehicle nearby, even when the infrastructure
is absent, and without using artificially long IP paths.
</t>
</list>
</t>
</section>
<section anchor="Acknowledgements"
title="Acknowledgements">
<t>
The authors would like to acknowledge colleagues who commented
and thus helped improving this document.
</t>
<!-- Possibly a 'Contributors' section ... -->
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
No particular requirements to IANA.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
Connecting a vehicle to the Internet poses a number of
significant problems related to security: new attacks are
possible and the vehicle should be protected.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119" ?>
</references>
<references title="Informative References">
<?rfc
include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mext-nemo-ro-automotive-req"
?>
</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 draft-petrescu-its-scenarios-reqs-01.txt to -02:
<list style='symbols'>
<t>
No change.
</t>
</list>
</t>
<t>
From draft-petrescu-its-scenarios-reqs-00.txt to -01:
<list style='symbols'>
<t>
Added requirements from R2 and up.
</t>
<t>
Better description of V2V, V2I terms. Introduction of the
intra-vehicular scenario.
</t>
<t>
Enumeration of scenarios.
</t>
<t>
Expanded authorship.
</t>
</list>
</t>
<t>
From -- to draft-petrescu-its-scenarios-reqs-00.txt:
<list style='symbols'>
<t>
First version of draft issued.
</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:02:21 |