The Use-Case of Disseminating to
Road-Side Units
TNO
Brassersplein 2
Delft
2612 CT
The Netherlands
+31888664252
bastiaan.wissingh@tno.nl
CEA, LIST
CEA Saclay
Gif-sur-Yvette
Ile-de-France
91190
France
+33169089223
Alexandru.Petrescu@cea.fr
University of Twente
P.O. Box 217
Enschede
7500 AE
The Netherlands
g.karagiannis@utwente.nl
University of Twente
P.O. Box 217
Enschede
7500 AE
The Netherlands
geert.heijenk@utwente.nl
Internet
Network Working Group
Disseminate to RSUs
This document describes use cases related to disseminating
Intelligent Transport System (ITS) information to Road-Side Units. The
described use cases relate to the concept of disseminating ITS
information from a back-office to vehicles as well as to the concept of
disseminating ITS information from vehicles to the back-office and/or
vehicles.
GeoNetworking mechanisms provide the capability to communicate data
packets in a manner qualified by geographical coordinates. For example,
one such mechanism may allow a server in the fixed infrastructure to
direct an IP packet flow to receivers situated in a distinct
geographical area. Variations of such a mechanism may use several
distinct or overlapping areas. Other variations may involve mobile
(instead of fixed) servers as sources and receivers.
One of the applications for which GeoNetworking mechanisms can used,
is the dissemination of ITS to Road-Side Units. This document describes
multiple use cases related to this dissemination of information. These
use cases are categorised into two categories, namely "Sending ITS
information from the back-office to the vehicles via Road-Side Units"
and "Sending ITS information from vehicles to the back-office/vehicles
via Road-Side Units and/or via direct communication".
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.
RSU stands for Road Side Unit.
ITS stands for Intelligent Transport Systems Information
Vehicular communications are characterized by a strong mobility
component. Most if not all computing entities are mobile - embedded in
vehicles, carried by passengers. However, despite the difficulties
brought in by the inherent mobility characteristics and wireless
communications, the vehicular communications are far from following
chaotic patterns, because they are subject to rather constant mobility
patterns: the laws of road use impose rules such as vehicles following
each other in one particular direction which leads to platooning,
mandatory presence of road signs which offers many wireless
communication opportunities, etc.
The mobility characteristics of vehicular communications impose a
strong need for qualifying the position of entities (by e.g.
coordinate distance to an agreed reference) and communicate
accordingly. In Intelligent Transportation Systems (ITS) many
use-cases have been described that make use of communicating
applications which rely on the positions of entities. Among these
use-cases, the dissemination of ITS-specific data from a server in the
infrastructure to one particular geographical area is a use-case
exhibited in many applications. An example put very simple is that of
a well-informed Command Center sending warning messages to vehicles
approaching a particularly hazardous area (and to them only).
Currently mass instant communications are dominated by voice
encoding on FM frequencies (analog frequency modulation); in this, the
vehicular hazard warning application mentioned above has a very coarse
geographical dimension: the FM stations are broadcasting over very
large areas (all vehicles on the road are informed and the human
listener performs filtering). On another hand, mass instant
communications may be realized on a finer manner by employing advanced
packet-based digital communications. It may offer a more performant
service in terms of reliability and response time.
If TCP/IP packet data communications were used, then a relatively
straightforward manner to achieve this geonetworking (send data
packets to a particular area) is to employ a trivial 'mapping' system
between an IP address and its geographical coordinates, and
vice-versa. In this manner, application software may be written that
sends IP packets to IP address destinations qualified by geographical
coordinates. This straightforward manner has certain drawbacks.
Certain 'mapping' mechanisms exist already in the family of Internet
protocols - witness DNS - and their advantages and drawbacks are well
understood with respect to scalability. Rather than a trivial mapping,
a more dynamic mechanism is needed which scales to the size of current
and future Internet.
In this document we do not propose designing new GeoNetworking
mechanisms, but express the thought that if it existed then a set of
particular ITS vehicular communications use-cases may benefit from
them.
The end-to-end need is to send data packets from a server to
vehicles. On another hand, given the strong wired-wireless
dichotomy, sending packets to a particular set of vehicles in a
particular area may involve a two-step operation: (1) send the data
packets to the RSUs (Road-Side Units) which are closest, or whose
wireless capabilities cover best the set of vehicles, and followed
by a second step (2) the respective RSUs send the data received in
the first step, to the vehicles.
The wired-wireless dichotomy mentioned above is considering that
the Road-Side Unit (or other entities deployed in vehicles) are
equipped with at least one wireless interface that is able to deal
with contraints of communication at high speeds (channel fading,
Doppler effects). Such interfaces include the IEEE 802.11p links and also cellular links.
In vehicular communications, there are many kinds of information
that need to be sent to designated entities in designated
geographical areas. In such
information is divided in four classes of V2X messages depending on
the services made possible by their contents (messages for active
road safety, for co-operative traffic efficiency, for co-operative
local services and for global Internet services). In particular, the
co-operative local services (or "location-based" services) are the
notification of POI, automatice access control and parking
management, ITS local electronic commerce and Media downloading.
The notification of POI to vehicle is sent, in principle a fixed
unit, a server, in the fixed infrastructure.
In general, a Point of Interest (POI) is a conceptual mark of a
place with a particular signification. In most uses, the
signification means a potential service to customer (e.g. a
restaurant POI, or a museum POI). The POIs are frequently used as a
list of private collection of information that may be queried by a
user when situated in a new geographical area. The POI list is
downloaded in advance on a portable device and, when arriving in the
new area, its POI list helps to situate precisely the restaurants,
museums, etc. A single POI identifies a single place (e.g. a set of
POIs are not used to build larger structures such as shapes, neither
is a sequence of POIs used to describe a route - other concepts are
used for describing shapes, areas and routes).
A POI data structure typically stores parameters such as
latitude, longitude and altitude, together with additional labels
such as name or civic address and various description of the
service.
In the case of Electrical Vehicle scenarios, the user of the EV
is well interested to learn in advance the situation of various
Charging Stations (CS). The user may download the CS placements as a
POI list. In addition, while driving, the user may receive
dynamically the most recent information about the CS placement.
ETSI topology for POI distribution
In project eCo-FEV, it is considered as useful to distribute the
POIs relevant to a Fully Electrical Vehicle (FEV) which are situated
along a pre-planned route .
Described in .
broadcast of all POIs => the vehicle filters based on its
position.
vehicle requests using its position as key => the response
may be broadcast.
dissemination of POIs from server to a particular RSU which
is in the vicinity of the POI in question (not the vehicle
question).
As the text in described fixed
RSUs, there is also the type of mobile RSUs which are also being used
for sending data packets from a server to vehicles. These mobile RSUs
have different characterisicts in comparison with the fixed versions.
One of these characteristics of a mobile RSU is that such a RSU is not
'bound' to a fixed geographical position but instead the geographical
position may change more dynamically.
With a dynamically changing geographical position, the requirements
for a 'mapping' system between an IP address and the corresponding
dynamic geographical coordinates may differ from the requirements for
a 'mapping' system between an IP address and fixed geographical
coordinates. For example the requirements with regards to the
frequency with which a 'mapping' is updated may be higher for dynamic
geographical coordinates then for fixed geographical coordinates. So
indeed rather than a trivial 'mapping', a more dynamic mechanism is
needed which scales to the size of current and future Internet.
As a RSU being mobile, where mobile means 'not fixed to a
geographical position', it provides advantages over fixed RSUs in
different use-cases. A use-case for which a mobile RSU provides
additional advantages over a fixed RSU is for example so called
'Incident Warning'.
An example of 'Incident Warning' is the application of Road Works
Warning. With Road Works Warning, vehicles and road users can be
informed of ongoing road works along a road. Vehicles and road users
could be informed about the geographical position of the road works,
the distance over which the road works is ongoing, speed limits,
etc. While this road works related information can be send from a
server to vehicles and road users via fixed RSUs, using a mobile RSU
can provide advantages. One of the advantages of using a mobile RSU
for sending road works related information to vehicles and road
users is that there is more flexibilty in reaching certain
geographical positions.
When for example at a certain geographical position road works is
planned for which vehicles and road users should be informed but no
fixed RSU is present at that location, a mobile RSU could be
positioned at that location in order to be able to send road works
relation information to approaching vehicles. In order for a road
operator to be able to send the information to the geographical area
of the road works, the road operator should somehow keep track of
the relation between RSUs IP addresses and their geographical
position. So this use case would also benefit from a more dynamic
mechanism in which these relations between IP addresses and
geographical positions can be maintained.
Such an implementation of a mobile RSU with a Road Works Warning
application has been developed within an European EIT ICT Labs
project during 2013.
The use cases considered in this section are vehicular networking
use cases. However, Internet-wide geo-networking can be applied to any
use case that is similar to these vehicular use cases where source
nodes anywhere in the Internet are able to geo(broad/any)cast packets
to all/any node(s) with geo-location awareness within an arbitrary,
source-specified destination area.
Vehicular networking can be considered as one of the most important
enabling technologies needed to support various types of traffic
applications, such as infotainment type of applications, traffic
efficiency & management and traffic safety applications.
Traffic safety applications are those that are primarily applied to
decrease the probability of traffic accidents and the loss of life of
the occupants of vehicles. Note that VSC and VSC-A projects focus on
vehicle-to-vehicle safety. Another project called CICAS-V (Cooperative
Intersection Collision Avoidance Systems - Violation) discuss the
traffic safety application over vehicle-to-infrastructure
communication.
Traffic efficiency & management applications are focusing on
improving the vehicle traffic flow, traffic coordination and traffic
assistance. Moreover, traffic efficiency & management applications
are focusing on providing updated local information, maps and in
general messages of relevance limited in space and/or time.
Infotainment types of applications are the applications that are
neither traffic safety applications nor traffic efficiency &
management applications. Such applications are supported by e.g.,
media downloading use cases. Such vehicular applications are defined
by several initiatives:
the USA VSC (Vehicular Safety Communications) and VSC-A (VSC-
Applications) projects.
the European Car-to-Car Communication Consortium (C2C-CC)
[C2C-CC] and the ETSI TC ITS [ETSI TC ITS], [ETSI-TR-102-638] with
the additional support of some EU funded research projects, such
as SEVECOM [SEVECOM], SAFESPOT [SAFESPOT], CVIS [CVIS].
PREDRIVE-C2x [PREDRIVE-C2x], GEONET [GEONET].
The USA Vehicle Safety Communications (VSC) consortium, see [VSC],
is supported among others by CAMP (Crash Avoidance Metrics
Partnership). CAMP is a partnership that has been formed in 1995 by
Ford Motor Company and General Motors Corporation. The objective of
CAMP is to accelerate the implementation of crash avoidance
countermeasures to improve traffic safety by investigating and
developing new technologies. VSC has been realized in two phases.
The first phase, denoted as VSC started in 2002 and ended in 2004.
The second phase started in 2006 and ends in 2009. VSC focused and is
focusing on traffic safety related applications. In 2006, The VSC 2
consortium in cooperation with USDOT initiated a three-year
collaborative effort in the area of wireless-based safety applications
under the Vehicle Safety Communications - Applications (VSC-A)
project, see [VSC-A]. The VSC2 consortium consists of the following
members; Mercedes-Benz, Ford, General Motors, Honda & Toyota. The
main goal of this project is to develop and test communications-based
vehicle safety systems to determine whether vehicle positioning in
combination with the DSRC at 5.9 GHz can improve the autonomous
vehicle-based safety systems and/or enable new communication-based
safety applications.
The WAVE Short Message Protocol [IEEE 1609.3] was designed
specifically to offer a more efficient (smaller size) alternative to
TCP or UDP over IP, for 1-hop messages that require no routing.
The European Car-to-Car Communication Consortium (C2C-CC) is an
industry consortium of car manufacturers and electronics suppliers
that focuses on the definition of an European standard for vehicular
communication protocols.
The European Telecommunications Standards Institute (ETSI)
Technical Committee (TC) Intelligent Transport Systems (ITS) was
established in October 2007 with the goal of developing and
maintaining standards, specifications and other deliverables to
support the development and the implementation of ITS service
provision. It is foreseen that ETSI ITS will be the reference
standardization body of the future European ITS standards, and
actually the C2C-CC provides recommendations to the ETSI TC ITS.
The following subsections describe use cases that can be
implemented using either V2I or V2V. When V2V is applied, the use of
Internet- wide Geo-networking solution is not required.
In VSC, see [VSC] 34 vehicle application scenarios have been
identified, evaluated and ranked. From this evaluation, a subset of
eight significant near- and mid-term traffic safety applications
have been selected: (1) cooperative forward collision warning, (2)
curve speed warning, (3) pre-crash sensing, (4) traffic signal
violation warning, (5) lane-change warning, (6) emergency electronic
brake light, (7) left turn assistant, (8) stop sign movement
assistant. A brief description of these applications is given below
(for more details, see [VSC]):
Traffic signal violation warning: it informs and warns the
driver to stop at a legally prescribed location in the situation
that the traffic signal indicates a stop and it is estimated
that the driver will be in violation.
Curve speed warning - Rollover Warning: aids the driver in
negotiating speeds at appropriate curves.
Emergency Electronic Brake Lights: it is used to inform
vehicles that a vehicle brakes hard. In particular in this
situation a warning message is sent to the vehicles moving
behind the vehicle that brakes hard.
Pre-crash sensing: it prepares the driver for an unavoidable
and imminent collision.
Cooperative Forward Collision Warning: aids the driver in
mitigating or avoiding collisions with the rear-end vehicles in
the forward path of travel through driver notification or
warnings of an unavoidable collision. This application does not
attempt to control the vehicle to avoid an unavoidable
collision.
Left Turn Assistant: it informs the driver about oncoming
traffic in order to assist him in making a left turn at a
signalized intersection without a phasing left turn arrow.
Lane Change Warning: it warns the driver if an intended lane
change may cause a crash with a nearby moving vehicle.
Stop Sign Movement Assistance: it warns the driver that the
vehicle is nearby an intersection, which will be passed after
having stopped at a stop sign.
In the VSC-A project an additional investigation has been
performed, on traffic safety applications that can be used in crash
immitment scenarios, see [VSC-A]. The following 7 traffic safety
applications have been selected for implementation in the VSC-A test
bed.
Emergency Electronic Brake Light: is a traffic safety
application that is the same as the Emergency Electronic Brake
Light application defined in the VSC project, see above.
Forward Collision warning: is a traffic safety application
that is the same as the Cooperative Forward Collision Warning
application defined in the VSC project, see above.
Intersection Movement Assist: is a traffic is intended to
warn the driver of a vehicle when it is not safe to enter an
intersection due to high collision probability with other
vehicles. It is similar to the Stop Sign Movement Assistance
application defined in the VSC project, see above.
Blind Spot Warning & Lane Change Warning: it is similar
to the Lane Change Warning application defined in the VSC
project, see above. In the Blind Spot Warning application the
driver of a host vehicle is informed that another vehicle is
moving in an adjacent lane and that this vehicle is positioned
in a blind spot zone of the host vehicle.
Do Not Pass Warning: this is an application that was not
investigated in the VSC project. It is intended to warn the
driver of a host vehicle during a passing maneuver attempt when
a slower vehicle, ahead and in the same lane, cannot be safely
passed using a passing zone which is occupied by vehicles with
the opposite direction of travel. In addition, the application
provides advisory information that is intended to inform the
driver of the host vehicle that the passing zone is occupied
when a passing maneuver is not being attempted.
Control Loss Warning: this is an application that was not
investigated in the VSC project. It is intended to enable the
driver of a host vehicle to generate and broadcast a control-
loss event to surrounding vehicles. Upon receiving this
information the surrounding vehicle determines the relevance of
the event and provides a warning to the driver, if
appropriate.
The Car to Car Communication Consortium specified a number of
traffic safety use cases. The following three are considered as
being the main traffic safety use cases, see [C2C-CC_Manifesto]:
Cooperative Forward Collision Warning: this use case tries to
provide assistance to the driver. Vehicles share (anonymously)
information such as position, speed and direction. This enables
the prediction of an imminent rear-end collision, by each
vehicle monitoring the behavior of its own driver and the
information of neighboring vehicles. If a potential risk is
detected, the vehicle warns the driver. This use case requires:
the ability for all vehicles to share Information with each
other over a distance of about 20 to 200 meters, accurate
relative positioning of the vehicles, trust relationships among
the vehicles and a reasonable market penetration (at least
10%).
Pre-Crash Sensing/Warning: this use case is similar to the
previous one, but in this case the collision is identified as
unavoidable, and then the involved vehicles exchange more
precise information to optimize the usage of actuators such as
airbags, seat belt pre-tensors, etc... This use case requires
basically the same abilities that the previous one, restricting
the needed communication range to 20 to 100 meters, and adding
the requirement of a fast and reliable connection between the
involved cars.
Hazardous Location V2V Notification: this use case is based
on the share of information that relates to dangerous locations
on the road, among vehicles, and also among vehicles and the
road infrastructure. On one hand, vehicles may detect the
dangerous locations from sensors in the vehicle or from events
such as the actuation of the ESP (Electronic Stability Program).
On the other hand, recipients of this information may use it to
properly configure active safety systems and/or warn the driver.
This use case requires: vehicles to trust other vehicles and
roadside units, reasonable market penetration, the ability of
vehicles to share information about a specific geographic
location over multiple-hops and the ability to validate
information propagated through multiple hops.
Such applications are focusing on improving the vehicle traffic
flow, traffic coordination and traffic assistance and provide
updated local information, maps and in general, messages of
relevance bounded in space and/or time. Two typical groups of this
type of applications are speed management and co-operative
navigation are two typical groups of this type of applications
[ETSI-TR-102-638], [KaAl11].
Speed management; Speed management applications aim to assist
the driver to manage the speed of his/her vehicle for smooth
driving and to avoid unnecessary stopping. Regulatory/contextual
speed limit notification and green light optimal speed advisory
are two examples of this type.
Co-operative navigation; This type of applications is used to
increase the traffic efficiency by managing the navigation of
vehicles through cooperation among vehicles and through
cooperation between vehicles and road side units. Some examples
of this type are traffic information and recommended itinerary
provisioning, co-operative adaptive cruise control and
platooning.
Such applications are neither traffic safety applications nor
traffic efficiency & management applications and are mainly
supported by e.g., media downloading use cases, see [CVIS],
[C2C-CC_Manifesto], [ETSI-TR-102-638], [PREDRIVE-C2x], [KaAl11]:
Co-operative local services; This type of applications focus
on infotainment that can be obtained from locally based services
such as point of interest notification, local electronic
commerce and media downloading.
Global Internet services; In this type of applications the
focus is on data that can be obtained from global Internet
services. Typical examples are Communities services, which
include insurance and financial services, fleet management and
parking zone management, and ITS station life cycle, which focus
on software and data updates.
No security considerations are considered in this document.
No IANA considerations are considered in this document.
Part of this work was supported by the European Commission under the
collaborative project eCo-FEV. The authors would like to thank all
partners within eCo-FEV for their cooperation and contribution.
We would like to thank the members of the IETF ITS and GeoNet
community for their comments and discussions. Furthermore, we would like
to thank the authors of the Internet draft
[draft-karagiannis-traffic-safety-requirements], G. Karagiannis, R.
Wakikawa, J. Kenney, C. J. Bernardos and F. Kargl, since some parts of
the traffic safety application descriptions are taken from the mentioned
draft.
IEEE Std 802.11p(TM)-2010, IEEE Standard for Information
Technology - Telecommunications and information exchange between
systems - Local and metropolitan area networks - Specific
requirements, Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications, Amendment 6: Wireless Access in
Vehicular Environments; document freely available at URL
http://standards.ieee.org/getieee802/download/802.11p-2010.pdf
retrieved on September 20th, 2013.
ETSI Technical Specification; Intelligent Transport Systems
(ITS); Infrastructure to Vehicle Communication; Electric Vehicle
Charging Spot Notification Specification, ETSI TS 101 556-1 V1.1.1
(2012-07), file name ts_10155601v010101p.pdf, freely available at
URL http://www.etsi.org/deliver/etsi_ts/101500_101599/
10155601/01.01.01_60/ts_10155601v010101p.pdf downloaded on June
10th, 2014.
ETSI Technical Specification; Intelligent Transport Systems
(ITS); Vehicular Communication; Basic Set of Applications, ETSI TS
102 637-1 V1.1.1 (2010-09), file name ts_10263701v010101p.pdf,
freely available at URL
http://www.etsi.org/deliver/etsi_ts/102600_102699/
10263701/01.01.01_60/ts_10263701v010101p.pdf downloaded on June
11th, 2014.
eCo-FEV Deliverable D200.1, Use cases and requirements for an
efficient cooperative platform, version 2.3, dissemination PU,
www.eco-fev.eu, 28 February 2013, file name
eCo-FEV-WP200-20140321v2.3-DL-D200.1 Use cases and
requirements_web.pdf, freely available at URL
http://www.eco-fev.eu/deliverables.html?f
ile=files/eco-fev/content/PDFs/ eCo-FEV-WP200-20140321v2.3-DL-D200.
1%20Use%20cases%20and%20requirements_web.pdf downloaded on June
11th, 2014.
C2C-CC official website, http://www.car-2-car.org/, (visited
in October 2009).
Car to Car Communication Consortium, "Car to Car
Communication Consortium Manifesto: Overview of the C2C-CC System",
C2C-CC, version 1.1, 2007.
CVIS EU FP6 project website, http://www.cvisproject.org,
(visited in October 2009).
Karagiannis, G., Wakikawa, R., Kenney, J., Bernardos, C.J.,
Kargl, F.,"Traffic safety applications requirements, IETF Internet
draft (work in progress), draft-karagiannis-
traffic-safety-requirements-02.txt, February 2010;
ETSI official website, http://www.etsi.org/, (visited in
October 2009).
ETSI TR 102 638, "Intelligent Transport System (ITS);
Vehicular Communications; Basic Set of Applications; Definition",
ETSI specification TR 102 638, v.1.1.1, June 2009.
ETSI TS 102 636-4-1, "Intelligent Transport Systems (ITS);
Vehicular communications; GeoNetworking; Part 4: Geographical
addressing and forwarding for point-to-point and point-
to-multipoint communications; Sub-part 1: Media-Independent
Functionality", ETSI specification ETSI TS 102 636-4-1 V1.1.1, June
2011.
GeoNet EU FP7 project website, http://www.geonet-project.eu,
(visited in October 2009).
IEEE Std P1609.3, "IEEE Trial-Use Standard for Wireless
Access in Vehicular Environments (WAVE)-Networking Services",
2007.
Karagiannis, G. Altintas, O., Ekici,E., Heijenk, G.J.,
Jarupan, B., Lin, K., Weil, T., "Vehicular networking: A survey and
tutorial on requirements, architectures, challenges, standards and
solutions", IEEE Communications Surveys & Tutorials, 13 (4). pp.
584- 616. ISSN 1553-877X, 2011.
Pre-Drive C2X EU FP7 project website,
http://www.pre-drive-c2x.eu, (visited in October 2009).
SAFESPOT EU FP6 project website, http://www.safespot-eu.org,
(visited in October 2009).
SEVECOM EU FP6 project website, http://www.sevecom.org,
(visited in October 2009).
Vehicle Safety Communications Project, Final Report, DOT HS
810 591, April 2006.
Vehicle Safety Communications - Applications (VSC-A) Project,
Final Annual Report, DOT HS 811 073, January 2009.
VSC-A presentation, "Security in VSC-A", slides presented at
IEEE 1609 meeting on August 26 - 28, 2008, to be found via:
http://vii.path.berkeley.edu/1609_wave/aug08/presentations/
VSCA-1609_080827.pdf
The changes are listed in reverse chronological order, most recent
changes appearing at the top of the list.
From draft-petrescu-disseminate-to-RSU-00.txt to
draft-wissingh-disseminate-to-RSU-00.txt
Added section "Dissemination of ITS information to mobile
RSUs"
Added section "vehicle to RSU dissemination"
Added section references
From draft-petrescu-disseminate-to-RSU-00.txt to
draft-petrescu-disseminate-to-RSU-00.txt:
first version.