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.

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.