Internet DRAFT - draft-wissingh-disseminate-to-rsu
draft-wissingh-disseminate-to-rsu
Network Working Group B. Wissingh
Internet-Draft TNO
Intended status: Informational A. Petrescu
Expires: December 21, 2014 CEA, LIST
G. Karagiannis
G. Heijenk
University of Twente
June 19, 2014
The Use-Case of Disseminating to Road-Side Units
draft-wissingh-disseminate-to-rsu-00.txt
Abstract
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.
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 December 21, 2014.
Copyright Notice
Copyright (c) 2014 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
Wissingh, et al. Expires December 21, 2014 [Page 1]
Internet-Draft disseminate to RSUs June 2014
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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Back-office to RSU dissemination . . . . . . . . . . . . . . 3
3.1. Dissemination of ITS information to fixed RSUs . . . . . 3
3.1.1. Sending to RSUs and to Vehicles . . . . . . . . . . . 4
3.1.2. Sending POIs of CSs to EVs . . . . . . . . . . . . . 4
3.1.3. Sending POIs related to a EV planned route -
eCo-FEV . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.4. Different means of sending POIs . . . . . . . . . . . 5
3.2. Dissemination of ITS information to mobile RSUs . . . . . 6
3.2.1. usage for Incident Warning . . . . . . . . . . . . . 6
4. Vehicle to RSU dissemination . . . . . . . . . . . . . . . . 7
4.1. Vehicular Networking . . . . . . . . . . . . . . . . . . 7
4.1.1. Traffic safety use cases . . . . . . . . . . . . . . 9
4.1.2. Traffic efficiency and management use cases . . . . . 11
4.1.3. Infotainment applications . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
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,
Wissingh, et al. Expires December 21, 2014 [Page 2]
Internet-Draft disseminate to RSUs June 2014
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".
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].
RSU stands for Road Side Unit.
ITS stands for Intelligent Transport Systems Information
3. Back-office to RSU dissemination
3.1. Dissemination of ITS information to fixed RSUs
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
Wissingh, et al. Expires December 21, 2014 [Page 3]
Internet-Draft disseminate to RSUs June 2014
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.
3.1.1. Sending to RSUs and to Vehicles
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
[ieee802.11p-2010] links and also cellular links.
3.1.2. Sending POIs of CSs to EVs
In vehicular communications, there are many kinds of information that
need to be sent to designated entities in designated geographical
areas. In [etsi-ts-102-637-1] 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
Wissingh, et al. Expires December 21, 2014 [Page 4]
Internet-Draft disseminate to RSUs June 2014
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
3.1.3. Sending POIs related to a EV planned route - eCo-FEV
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 [ecofev-d200.1].
3.1.4. Different means of sending POIs
Described in [etsi-ts-101-556-1-2-12].
o broadcast of all POIs => the vehicle filters based on its
position.
Wissingh, et al. Expires December 21, 2014 [Page 5]
Internet-Draft disseminate to RSUs June 2014
o vehicle requests using its position as key => the response may be
broadcast.
o dissemination of POIs from server to a particular RSU which is in
the vicinity of the POI in question (not the vehicle question).
3.2. Dissemination of ITS information to mobile RSUs
As the text in Section 3.1 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'.
3.2.1. usage for 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
Wissingh, et al. Expires December 21, 2014 [Page 6]
Internet-Draft disseminate to RSUs June 2014
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.
4. Vehicle to RSU dissemination
4.1. Vehicular Networking
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.,
Wissingh, et al. Expires December 21, 2014 [Page 7]
Internet-Draft disseminate to RSUs June 2014
media downloading use cases. Such vehicular applications are defined
by several initiatives:
o the USA VSC (Vehicular Safety Communications) and VSC-A (VSC-
Applications) projects.
o 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
Wissingh, et al. Expires December 21, 2014 [Page 8]
Internet-Draft disseminate to RSUs June 2014
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.
4.1.1. Traffic safety use cases
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]):
o 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.
o Curve speed warning - Rollover Warning: aids the driver in
negotiating speeds at appropriate curves.
o 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.
o Pre-crash sensing: it prepares the driver for an unavoidable and
imminent collision.
o 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.
o 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.
o Lane Change Warning: it warns the driver if an intended lane
change may cause a crash with a nearby moving vehicle.
Wissingh, et al. Expires December 21, 2014 [Page 9]
Internet-Draft disseminate to RSUs June 2014
o 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.
o 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.
o 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.
o 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.
o 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.
o 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.
o 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.
Wissingh, et al. Expires December 21, 2014 [Page 10]
Internet-Draft disseminate to RSUs June 2014
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]:
o 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%).
o 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.
o 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.
4.1.2. Traffic efficiency and management use cases
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].
Wissingh, et al. Expires December 21, 2014 [Page 11]
Internet-Draft disseminate to RSUs June 2014
o 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.
o 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.
4.1.3. Infotainment applications
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]:
o 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.
o 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.
5. Security Considerations
No security considerations are considered in this document.
6. IANA Considerations
No IANA considerations are considered in this document.
7. Contributors
8. Acknowledgements
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.
Wissingh, et al. Expires December 21, 2014 [Page 12]
Internet-Draft disseminate to RSUs June 2014
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.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[C2C-CC] "C2C-CC official website, http://www.car-2-car.org/,
(visited in October 2009).", .
[C2C-CC_MANIFESTO]
"Car to Car Communication Consortium, "Car to Car
Communication Consortium Manifesto: Overview of the C2C-CC
System", C2C-CC, version 1.1, 2007.", .
[CVIS] "CVIS EU FP6 project website, http://www.cvisproject.org,
(visited in October 2009).", .
[ETSI-EN-302-636-4-1]
"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.", .
[ETSI-TC-ITS]
"ETSI official website, http://www.etsi.org/, (visited in
October 2009).", .
[ETSI-TR-102-638]
"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.", .
Wissingh, et al. Expires December 21, 2014 [Page 13]
Internet-Draft disseminate to RSUs June 2014
[GEONET] "GeoNet EU FP7 project website,
http://www.geonet-project.eu, (visited in October 2009).",
.
[IEEE-1609.3]
"IEEE Std P1609.3, "IEEE Trial-Use Standard for Wireless
Access in Vehicular Environments (WAVE)-Networking
Services", 2007.", .
[KaAl11] "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.", .
[PREDRIVE-C2x]
"Pre-Drive C2X EU FP7 project website,
http://www.pre-drive-c2x.eu, (visited in October 2009).",
.
[SAFESPOT]
"SAFESPOT EU FP6 project website,
http://www.safespot-eu.org, (visited in October 2009).", .
[SEVECOM] "SEVECOM EU FP6 project website, http://www.sevecom.org,
(visited in October 2009).", .
[VSC] "Vehicle Safety Communications Project, Final Report, DOT
HS 810 591, April 2006.", .
[VSC-A] "Vehicle Safety Communications - Applications (VSC-A)
Project, Final Annual Report, DOT HS 811 073, January
2009.", .
[VSC-A_1609.2]
"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", .
[draft-karagiannis-traffic-safety-requirements]
"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;", .
Wissingh, et al. Expires December 21, 2014 [Page 14]
Internet-Draft disseminate to RSUs June 2014
[ecofev-d200.1]
"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.", .
[etsi-ts-101-556-1-2-12]
"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-ts-102-637-1]
"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.", .
[ieee802.11p-2010]
"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.", .
Appendix A. ChangeLog
The changes are listed in reverse chronological order, most recent
changes appearing at the top of the list.
Wissingh, et al. Expires December 21, 2014 [Page 15]
Internet-Draft disseminate to RSUs June 2014
From draft-petrescu-disseminate-to-RSU-00.txt to draft-wissingh-
disseminate-to-RSU-00.txt
o Added section "Dissemination of ITS information to mobile RSUs"
o Added section "vehicle to RSU dissemination"
o Added section references
From draft-petrescu-disseminate-to-RSU-00.txt to draft-petrescu-
disseminate-to-RSU-00.txt:
o first version.
Authors' Addresses
Bastiaan Wissingh
TNO
Brassersplein 2
Delft 2612 CT
The Netherlands
Phone: +31888664252
Email: bastiaan.wissingh@tno.nl
Alexandru Petrescu
CEA, LIST
CEA Saclay
Gif-sur-Yvette, Ile-de-France 91190
France
Phone: +33169089223
Email: Alexandru.Petrescu@cea.fr
Georgios Karagiannis
University of Twente
P.O. Box 217
Enschede 7500 AE
The Netherlands
Email: g.karagiannis@utwente.nl
Wissingh, et al. Expires December 21, 2014 [Page 16]
Internet-Draft disseminate to RSUs June 2014
Geert Heijenk
University of Twente
P.O. Box 217
Enschede 7500 AE
The Netherlands
Email: geert.heijenk@utwente.nl
Wissingh, et al. Expires December 21, 2014 [Page 17]
