Internet DRAFT - draft-petrescu-its-scenarios-reqs
draft-petrescu-its-scenarios-reqs
Network Working Group A. Petrescu
Internet-Draft C. Janneteau
Intended status: Informational M. Boc
Expires: April 6, 2014 CEA
W. Klaudel
Renault
October 3, 2013
Scenarios and Requirements for IP in Intelligent Transportation Systems
draft-petrescu-its-scenarios-reqs-03.txt
Abstract
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 6, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Petrescu, et al. Expires April 6, 2014 [Page 1]
Internet-Draft Scenarios and Reqs for IP in ITS October 2013
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Intra-Vehicular (V) . . . . . . . . . . . . . . . . . . . 5
3.2. Vehicle-to-Infrastructure (V2I) . . . . . . . . . . . . . 7
3.3. Vehicle-to-Vehicle (V2V) and V2RSU . . . . . . . . . . . . 7
3.4. Vehicle-to-Vehicle-to-Infrastructure (V2V2I) . . . . . . . 9
3.5. Infrastructure Support . . . . . . . . . . . . . . . . . . 9
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Petrescu, et al. Expires April 6, 2014 [Page 2]
Internet-Draft Scenarios and Reqs for IP in ITS October 2013
1. Introduction
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.
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.
The use of Internet protocols in the vehicular scenarios may prove
advantageous from several standpoints:
o immediate availability of a large number of applications with an
established customer base.
o scalability: large numbers of inter-communicating vehicles can be
accommodated across large distances.
o accessing heterogeneous, mixed and multiple-standard link layer
technologies.
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
[I-D.ietf-mext-nemo-ro-automotive-req].)
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
Petrescu, et al. Expires April 6, 2014 [Page 3]
Internet-Draft Scenarios and Reqs for IP in ITS October 2013
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.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Scenarios
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.)
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.
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.
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.
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.
Petrescu, et al. Expires April 6, 2014 [Page 4]
Internet-Draft Scenarios and Reqs for IP in ITS October 2013
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.
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.
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.
3.1. Intra-Vehicular (V)
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.
One illustration of an intra-vehicular network is depicted in the
next figure:
| | ... | n interfaces to the outside of vehicle
---------------
| Mobile Router |
---------------
/ | \ m IP subnets within the vehicle
/ | \
|
---------
| D.Router|
/---------\
/ | \---CAN--
/ |
sensors \-----entertainment subnet
subnet
Figure 1: Topology for Vehicle-to-Infrastructure V2I Communications
This figure tries to illustrate the complexity of a intra-vehicular
network. Even though the first deployments of intra-vehicular
Petrescu, et al. Expires April 6, 2014 [Page 5]
Internet-Draft Scenarios and Reqs for IP in ITS October 2013
networks were being constructed using a single IP subnet, the most
recent advancements propose the use of multiple subnets within one
vehicle.
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).
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).
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).
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.
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.
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.
Some scenarios considered for vehicle communications need to take
Petrescu, et al. Expires April 6, 2014 [Page 6]
Internet-Draft Scenarios and Reqs for IP in ITS October 2013
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).
3.2. Vehicle-to-Infrastructure (V2I)
This section describes the communication scenario in which one mobile
vehicle connects to a fixed infrastructure.
Topology:
-------- /--------------+
| Vehicle|--- ---/Fixed |------>Internet
-------- wireless \Infrastructure |
link \--------------+
(long range)
Figure 2: Topology for Vehicle-to-Infrastructure V2I Communications
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.
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.
3.3. Vehicle-to-Vehicle (V2V) and V2RSU
Topology:
-------- --------
| Vehicle|-- --| Vehicle|
-------- wireless --------
link
(short-range)
Figure 3: Topology for Vehicle-to-Vehicle V2V Communications
Petrescu, et al. Expires April 6, 2014 [Page 7]
Internet-Draft Scenarios and Reqs for IP in ITS October 2013
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. The link IEEE 802.11p may benefit from longer range
transmissions: spectrum regulators in certain regions allow for power
levels as high as 33 dBM (Europe) or 44 dBm (US) which corresponds to
distances in the order of magnitude of kilometers (as compared to
tens of meters for 802.11b).
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. When the link is 802.11p, the operation may be similar to
the ad-hoc mode of 802.11b, and simplified even further: the
operation outside the context of a BSS ('OCB') involves total absence
of beacons and association or authentication messages.
One potential application of the V2V topology is the communication
between a Vehicle and a Road-Side Unit; this RSU may be disconnected
from the Internet.
+--------+ +-------+
| Mobile | | Fixed |
| Vehicle|-- --| RSU |
+--------+ wireless +-------+
link
(short-range)
Figure 4: V2RSU Topology (similar to V2V)
In this topology, the Vehicle communicates directly with the RSU
which is fixed. The RSU may 'broadcast' IP packets (disseminate,
without request, to everybody in range) information which is
pertinent to the particular location of that RSU.
A set of possible scenarios 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
Petrescu, et al. Expires April 6, 2014 [Page 8]
Internet-Draft Scenarios and Reqs for IP in ITS October 2013
disallowed for V2V communications, and the short-range communications
are completely disallowed between vehicles which perform V2I. Along
the set of scenarios, one scenario is possible where fixed
infrastructure is deployed with the goal to support V2V
communications but without offering Internet access. Also along this
set of values the V2RSU is a topology where the vehicle communicates
direclty with a fixed RSU, in the same manner it would communicate in
a V2V topology. At the other extreme of this set of values, V2I
communications may be realized by building a complete infrastructure
with moving vehicles.
3.4. Vehicle-to-Vehicle-to-Infrastructure (V2V2I)
Topology:
-------- -------- /-------------+
| Vehicle|-- --| Vehicle|-- --/Fixed |----->Internet
-------- wireless -------- w \Infrastructure|
link link \-------------+
(short range) (long range)
Figure 5: Topology for Vehicle-to-Vehicle-to-Infrastructure V2V2I
Communications
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.
3.5. Infrastructure Support
4. Requirements
o R0. IP addressing within each vehicle.
o R1. IP addressing on the interface between vehicles.
o R2. Sub-networks support: Mobile router support several sub-
networks hosting stakeholder networks,
o R3. Support of multiple interfaces: The vehicle (not restricted
to the MR physically) should support several interfaces towards
the infrastructure.
Petrescu, et al. Expires April 6, 2014 [Page 9]
Internet-Draft Scenarios and Reqs for IP in ITS October 2013
o R4. Quality of Service: One stakeholder may request for a minimum
bandwidth for its applications. QoS should ensure those minimums
are taken into accounts.
o R5. Broadcasted Alerts support: Along the highway, the MR may
receive alerts about accident through 802.11p.
o R6. Store, Carry and Forward: Improve communication efficiency by
delaying transfer of information.
o R7. Geographic information support: Efficient inter-vehicular
routing may take advantage of geographic information (not
restricted to geonetworking).
o R8. Security: MR must prevent routing of packets between sub
networks and ensure protection of those data within the vehicle.
o 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.
o 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.
o 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.
5. Acknowledgements
The authors would like to acknowledge colleagues who commented and
thus helped improving this document.
6. IANA Considerations
No particular requirements to IANA.
7. Security Considerations
Connecting a vehicle to the Internet poses a number of significant
problems related to security: new attacks are possible and the
Petrescu, et al. Expires April 6, 2014 [Page 10]
Internet-Draft Scenarios and Reqs for IP in ITS October 2013
vehicle should be protected.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.ietf-mext-nemo-ro-automotive-req]
Baldessari, R., Ernst, T., Festag, A., and M. Lenardi,
"Automotive Industry Requirements for NEMO Route
Optimization", draft-ietf-mext-nemo-ro-automotive-req-02
(work in progress), January 2009.
Appendix A. ChangeLog
The changes are listed in reverse chronological order, most recent
changes appearing at the top of the list.
From draft-petrescu-its-scenarios-reqs-02.txt to -03:
o Added the use of 802.11p in V2V scenario, and added the V2RSU
scenario.
From draft-petrescu-its-scenarios-reqs-01.txt to -02:
o No change.
From draft-petrescu-its-scenarios-reqs-00.txt to -01:
o Added requirements from R2 and up.
o Better description of V2V, V2I terms. Introduction of the intra-
vehicular scenario.
o Enumeration of scenarios.
o Expanded authorship.
From -- to draft-petrescu-its-scenarios-reqs-00.txt:
o First version of draft issued.
Petrescu, et al. Expires April 6, 2014 [Page 11]
Internet-Draft Scenarios and Reqs for IP in ITS October 2013
Authors' Addresses
Alexandru Petrescu
CEA
Communicating Systems Laboratory, Point Courrier 173
Palaiseau, F-91120
France
Phone: +33(0)169089223
Email: alexandru.petrescu@cea.fr
Christophe Janneteau
CEA
Communicating Systems Laboratory, Point Courrier 173
Palaiseau, F-91120
France
Phone: +33(0)169089182
Email: christophe.janneteau@cea.fr
Michael Mathias Boc
CEA, LIST
Communicating Systems Laboratory, Point Courrier 173
Palaiseau, F-91120
France
Phone: +33 (0) 169083976
Email: michael.boc@cea.fr
Witold Klaudel
Renault
1 Av. du Golf
Guyancourt, F-78288
France
Phone: +33(0)176845680
Email: witold.klaudel@renault.com
Petrescu, et al. Expires April 6, 2014 [Page 12]
