REDUCTION 2011 2014 Deliverable 6.3.3 Final Report on Contributions to Standards … ·...

REDUCTION 2011‐2014

Deliverable 6.3.3

Final Report on Contributions to Standards

31‐01‐2015

D6.3.3 [Final Report on Contributions to Standards]

II

Public Document


III

Project acronym: REDUCTION

Project full title: Reducing Environmental Footprint based on Multi‐Modal Fleet management Systems for Eco‐Routing and Driver Behaviour Adaptation

Work Package: WP6

Document title: Final Report on Contributions to Standards

Version: 3.0

Official delivery date: 31/01/2015

Actual publication date: 31/01/2015

Type of document: Report

Nature: Public

Authors: Dimitrios Katsaros (UTH), Katerina Pechivanidou (UTH), Marcel Vale (TRI), S. Ghosh (DEL), Chris Hedges (DEL), A. Mika‐Kurosawa (DEL)

Approved by: REDUCTION consortium partners


IV

Version Date Sections Affected

1.0 31/07/2014 Initial version

2.0 14/08/2014 Review comments processed

3.0 29/01/2015 Minor changes were introduced

Executive Summary

Implementation of car‐2‐car requires interoperability between all the communication equipment that will be available in the market. Hence a standardization of the protocols is urgently needed for such an implementation. Delphi being an international company, have decided to work in the standardization effort in the US and in the EU so that standards are monitored in the major markets and common grounds are found and used.

The first part of this deliverable describes the development process of the DVM‐Exchange ([1]) standard, which will be an open standard for the interoperability of road traffic management systems, especially in the context of Network Management. Trinité is one of the initiating companies developing this standard. The standard is needed in order to deploy a larger area of Traffic management with traffic management systems from different vendors. This deliverable relates the current status of the standard, the key choices made in the course of 2011 and 2012, and the key challenges encountered. It also describes the Network Management approach on which the standard is based. Then, this deliverable documents DELPHI’s efforts towards standardization. Then, it includes a detailed description of UTH’s efforts related to the implementation and improvement of the Geonetworking protocols, which comprises the first concrete effort towards REDUCTION’s contribution to standards. Finally, it presents UTH’s efforts related to the implementation and evaluation of a dissemination protocol for network‐wide broadcasting operations; it is an improvement over the well‐known standard routing OLSR (Optimized Link‐State Routing) protocol, which is the IETF RFC3626 standard routing protocol for mobile ad hoc networks.


5

Table of Contents Executive Summary.................................................................................................................................IV

Table of Contents ....................................................................................................................................... 5

List of Tables ............................................................................................................................................... 7

List of Figures ............................................................................................................................................. 8

Glossary..................................................................................................................................................... 11

1. Introduction .......................................................................................................................................... 16

1.1 Project Overview............................................................................................................................ 16

1.2 Work Package Objectives and Tasks ........................................................................................... 16

1.3 Objective of this Deliverable......................................................................................................... 17

2. Related Work and REDUCTION....................................................................................................... 18

2.1 The DVM‐Exchange Standard...................................................................................................... 18

2.1.1 Introduction ............................................................................................................................. 18

2.1.2 Overview of the DVM‐Exchange standard ......................................................................... 19

2.2 The Datex II standard .................................................................................................................... 21

2.3 Intra‐Vehicle communications standard .................................................................................... 22

2.3.1 Overview.................................................................................................................................. 22

2.3.2 FMS – Fleet Management Systems ....................................................................................... 22

2.4 V2X communications standards .................................................................................................. 22

2.4.1 SAE Standardizations efforts for V2X.................................................................................. 24

3. Framework and Methodology ........................................................................................................... 31


6

3.1 REDUCTION and DVM Exchange.............................................................................................. 31

3.1.1 Requirements for DVM Exchange ........................................................................................ 31

3.1.2 High‐level description............................................................................................................ 31

3.1.3 How to use the standard........................................................................................................ 34

3.2 REDUCTION and DATEX II ........................................................................................................ 35

3.2.1 Description of the DATEX II adoption to Reduction ......................................................... 36

3.3 REDUCTION and V2X standards ............................................................................................... 38

3.3.1 DELPHI’s active involvement in standards: 4.5.1 Car‐2‐car consortium standardization work ................................................................................................................................................... 40

4. Extensions to Geonetworking protocol............................................................................................. 47

4.1 Proposed contributions to the standard ETSI TS 102 636‐4‐1 .................................................. 47

4.2 Implementation of the Geonetworking protocol....................................................................... 48

4.2.1 Intelligent Transport Systems Architecture ........................................................................ 48

4.2.2 Facilities Layer protocols ....................................................................................................... 52

4.2.3 Network and Transport Layer protocols ............................................................................. 53

4.2.4 Access Layer protocols ........................................................................................................... 56

4.2.5 GeoNetworking Implementation.......................................................................................... 60

4.2.6 GeoNetworking Packets......................................................................................................... 64

4.2.7 Defining a Geographical area................................................................................................ 72

4.2.8 Communication with upper layer ........................................................................................ 75

4.2.9 Communication with the management layer ..................................................................... 78

4.2.10 Other Implementation Details............................................................................................. 79


7

4.2.11 Evaluation of the GeoNetworking Daemon.................................................................... 104

4.2.12 Testbed Related extensions................................................................................................ 107

5. Protocols for network‐wide broadcasting ...................................................................................... 112

5.1 Influential nodes in complex networks..................................................................................... 113

5.1.1 Control Centrality ................................................................................................................. 113

5.1.2 From Control Centrality to pCoCe ..................................................................................... 114

5.1.3 pCoCe relay set selection ..................................................................................................... 115

5.1.4 OLSR MPR set selection ....................................................................................................... 116

5.2 Performance Evaluation.............................................................................................................. 117

5.2.1 Simulation design ................................................................................................................. 117

5.2.2 Dissemination to the entire grid ......................................................................................... 118

5.3 Concluding remarks .................................................................................................................... 123

6. REDUCTION and standards ............................................................................................................ 124

7. Final Assessment................................................................................................................................ 125

8. Conclusion .......................................................................................................................................... 126

References ............................................................................................................................................... 127

List of Tables Table 1. Summary table for the objectives of the deliverable. ........................................................... 17

Table 2. DATEX II data message structure and fields. ....................................................................... 37

Table 3. DATEX II data message reply structure and fields. ............................................................. 38

Table 4. Specification of minimum antenna performance. ................................................................ 44


8

Table 5. Test scenario parameters. ......................................................................................................... 46

Table 6 : Frequencies and applications on ITS ..................................................................................... 57

Table 7 : MIB values and their initial configuration............................................................................ 86

Table 8. Exploitation and extensions to standards by REDUCTION. ............................................ 124

Table 9. Standards used/developed in the context of REDUCTION. ............................................. 126

List of Figures Figure 1. Present situation in traffic management.………………………...……………………. 19

Figure 2. Two TM systems connected via DVM Exchange ……………………………………. 20

Figure 3. Red marked cells describe DELPHI’s efforts in SAE.......................................................... 23

Figure 4. C2CCC basic system components. ........................................................................................ 26

Figure 5. C2CCC extended basic system components........................................................................ 26

Figure 6. Cooperation overview ‐ Mandate M/453 context................................................................ 28

Figure 7. REDUCTION message exchange flow. ................................................................................ 35

Figure 8. Abstract C2C link..................................................................................................................... 41

Figure 9. A generic test scenario. ........................................................................................................... 45

Figure 10: ITS Network Architecture .................................................................................................... 48

Figure 11 : ITS Network architecture (general).................................................................................... 50

Figure 12 : ITS Station Architecture: Application Unit and Control and Communication Units in a single On Board Unit ............................................................................................................................ 51

Figure 13 : General ITS Station protocol stack ..................................................................................... 51

Figure 14 : ITS Network and Transport Layer protocols.................................................................... 54

Figure 15 : The GeoNetworking protocol stack ................................................................................... 55


9

Figure 16 : ITS IPv6 protocol stack ........................................................................................................ 55

Figure 17 : ITS GeoNetworking with IPv6 support protocol stack................................................... 56

Figure 18 : ITS‐G5 Elements.................................................................................................................... 56

Figure 19: Requirements for spectral power density in the 5 GHz range for ITS stations ............ 58

Figure 20 : Modulation scheme and data rates for ITS G5 applications........................................... 58

Figure 21 : MAC header of IEEE 802.11 ................................................................................................ 59

Figure 22 : EDCA parameters for Contention Window in IEEE 802.11 ........................................... 59

Figure 23 : GeoNetworking Address format........................................................................................ 60

Figure 24 : Configuration parameters of the GN address .................................................................. 61

Figure 25 : LPV format ............................................................................................................................ 61

Figure 26 : Configguration Parameters of LPV.................................................................................... 63

Figure 27 : SPV format............................................................................................................................. 63

Figure 28 : GN packet structure ............................................................................................................. 64

Figure 29 : Common Header Format..................................................................................................... 65

Figure 30 : Configuration Parameters for Common Header ............................................................. 66

Figure 31 : TSB packet header ................................................................................................................ 67

Figure 32 : TSB Extended Header configuration parameters ............................................................ 68

Figure 33 : GeoBroadcast/GeoAnycast packet header ........................................................................ 68

Figure 34 : GeoBroadcast/GeoAnycast Extended Header configuration parameters .................... 69

Figure 35 : GeoUnicast packet header................................................................................................... 69

Figure 36 : GeoUnicast Extended Header configuration parameters............................................... 70

Figure 37 : Location Service example .................................................................................................... 71

Figure 38 : Common Header Location Service parameters ............................................................... 71


10

Figure 39 : Definition of a Circular Area............................................................................................... 72

Figure 40 : Definition of a Rectangular Area........................................................................................ 73

Figure 41 : Definition of an Elliptical Area ........................................................................................... 73

Figure 42 : The GeoNetworking SAPs .................................................................................................. 75

Figure 43 : GeoNetworking implementation architecture ................................................................. 79

Figure 44 : DELPHIʹs OBU...................................................................................................................... 80

Figure 45: SHB transmission flowchart................................................................................................. 89

Figure 46 : TSB transmission flowchart ................................................................................................ 91

Figure 47 : GeoBroadcasst transmission flowchart ............................................................................. 93

Figure 48 : GeoAnycast transmission flowchart .................................................................................. 94

Figure 49 : GeoUnicast transmission flowchart ................................................................................... 96

Figure 50 : Common actions upon reception of GN packets ............................................................. 97

Figure 51 : TSB/SHB packet reception flowchart................................................................................. 98

Figure 52 : GeoBroadcast/GeoAnycast packet reception flowchart.................................................. 99

Figure 53 : GeoUnicast packet reception flowchart .......................................................................... 101

Figure 54 : Starting the gpsfake application....................................................................................... 104

Figure 55 : Transmission of Beacons ................................................................................................... 105

Figure 56 : Starting facility layer .......................................................................................................... 105

Figure 57 : Capturing CAM messages ................................................................................................ 106

Figure 58 : GeoBroadcast packet transmission .................................................................................. 106

Figure 59: NITOS testbed deployment................................................................................................ 108

Figure 60 : NITOS testbed architecture............................................................................................... 109

Figure 61. OMF architecture. ............................................................................................................... 110


11

Figure 62. In and out neighborhoods in a typical vehicular network. ........................................... 114

Figure 63. Pseudo‐code for pCoCe relay set selection . .................................................................... 116

Figure 64. Pseudo‐code OLSR MPR set selection. ............................................................................. 117

Figure 65. OLSR versus 2pCoCe with vehicle velocity at 14m/s..................................................... 119



Figure 68. Normalized coverage by number of selected mprs of each method............................ 121

Figure 69. Comparing pCoCe’s performance with 2 and 3 hops distance. ................................... 122

Figure 70. Communication range at 250m for frequency of vehicles every 1 seconds. ............... 123

Glossary AASHTO American Association of State Highway and Transportation Officials API Application Programming Interface ASL Adaptation Sub Layer AU Application Unit BRAN Broadband Radio Access Networks BSA Basic Set of Applications BSM Basic Safety Message BTP Basic Transport Protocol C2C Car‐to‐Car C2X Car‐to‐X (Infrastructure or Vehicle) C2I Car‐to‐Infrastructure C2CCC Car‐to‐Car Communication Consortium C2P Child‐to‐Parent CAM Cooperative Awareness Message CALM Communications access for land mobiles CAN Controller Area Network CBF Contention Based Forwarding CCU Control and Communication Unit


12

CEN Comité Européen de Normalisation; (European Committee for Standardization) CENELEC Comité Européen de Normalisation Électrotechnique; (European Committee for

Electrotechnical Standardization) CW Contention Window DENM Decentralized Environment Notification Message DFS Dynamic Frequency Selection DG‐INFSO Directorate General for Information Society and Media DSRC Dedicated Short Range Communications DVM Dynamic Verkeers (Traffic) Management ECC European Control Conference EDCA Enhanced Distributed Channel Access EFC Electronic Fee Collections ERC Energy Regulatory Commission ESO European Standardization Organization ETC Electronic Tall Collections ETSI European Telecommunications Standards Institute FIRE Future Internet Research and Experimentation FCS Frame Check Summary GF Greedy Forwarding GN GeoNetworking GN_ADDR GeoNetworking Address GPL General Public Licence HCCA Hybrid Coordination Function Controlled Channel Access HCF Hybrid Coordination Function HL Hop Limit HST Header Subtype HT Header Type HTG Harmonization Task Group HTTP HyperText Transfer Protocol IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force ISO International Standardization Organization IP Internet Protocol IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 ITE Institute of Transportation Engineers


13

ITS Intelligent Transportation Systems LAN Local Area Network LL Link Layer LL_ADDR Link Layer Address LoT Location Table LPV Long Position Vector LS Location Service LT Lifetime LTE Long Term Evolution MAC Medium Access Control MANET Mobile Adhoc Networks MFR Most Forward within Radius MGMT Management MIB Management Information Base MID MAC ID MLME MAC sublayer Management Entity NEMA National Electrical Manufacturers Association NFP Nearest with Forward Process NH Next Header NITOS Network Implementation Testbed using Open Source code NM Network Management NMEA National Marine Electronics Association NTCIP National Transportation Communications for ITS Protocol OBU On Board Unit OCIT Open Communication Interface for Road Traffic Control Systems OEM Original Equipment Manufacturer OMF cOntrol and Management Framework OML OMF Measurement Library OSI Open Systems Interconnection P2C Peer‐to‐Child P2P Peer‐to‐Peer PCF Point Coordination Function PDU Protocol Data Unit PHY Physical Layer PKI Public Key Infrastructure PL Payload Length


14

PLME PHY layer Management Entity POS Position POTI Position and Time PV Position Vector QoS Quality of Service R&D Research and Development RHW Road Hazard Warning RDS Radio Data System RHW Road Hazard Warning RLAN Radio Local Area Network RSU Road Side Unit SAE Society of Automotive Engineers SAP Service Access Point SDN Software Defined Networking SDO Standardization Organization SDR Software Defined Radios SDU Service Data Unit SE Sender SHB Single Hop Broadcast SLA Service Level Agreements SN Sequence Number SO Source SPAT Signal Phase and Timing SPN Short Position Vector STA Station TMC Traffic Message Channel TNM Traffic Network Management TOPO Topology Message TPC Transmission Power Control TSB Topologically Scoped Broadcast TST Timestamp USRP Universal Serial Radio Peripheral V2I Vehicle‐to‐Infrastructure V2V Vehicle‐to‐Vehicle V2X Vehicle‐to‐X (Infrastructure or Vehicle)


15

USDOT United States Department of Transportation WAVE Wireless Access in Vehicular Environments WIFI Wireless‐Fidelity WIMAX Worldwide Interoperability for Microwave Access WLAN Wireless LAN XML eXtensive Markup Language


16

1. Introduction

1.1 Project Overview

Reduction of CO2 emissions is a great challenge for the transport sector nowadays. Despite recent progress in vehicle manufacturing and fuel technology, still a significant fraction of CO2 emissions in EU cities is resulting from vehicular transportation. Therefore, additional innovative technologies are needed to address the challenge of reducing emissions. The REDUCTION project focuses on advanced ICT solutions for managing multi‐modal fleets and reducing their environmental footprint. REDUCTION collects historic and real‐time data about driving behavior, routing information, and emissions measurements that are processed by advanced predictive analytics to enable fleets enhancing their current services as follows:

1) Optimizing driving behavior: supporting effective decision making for the enhancement of drivers’ education and the formation of effective policies about optimal traffic operations (speeding, braking, etc.), based on the analytical results over the data that associate driving‐behavior patterns with CO2 emissions;

2) Eco‐routing: suggesting environmental‐friendly routes and allowing multi‐modal lets to reduce their overall mileage automatically; and

3) Support for multi‐modality: offering a transparent way to support multiple transportation modes and enabling co‐modality.

REDUCTION follows an interdisciplinary approach and brings together expertise from several communities. Its innovative, decentralized architecture allows scalability to large fleets by combining both V2V and V2I approaches. Its planned commercial exploitation, based on its proposed cutting edge technology, aims at providing a major breakthrough in the fast growing market of services for ʺgreenʺ fleets in EU and worldwide, and present substantial impact to the challenging environmental goals of EU.

1.2 Work Package Objectives and Tasks The goal of work package WP6 is to make the results of REDUCTION publicly available through peer‐reviewed publications, conference presentations, press releases, Web pages, and contributions to standards. It consists of tasks relevant to dissemination (T6.1), exploitation (T6.2), and contribution to standards (T6.3). As far as the peer‐reviewed publications are concerned, the academic partners of REDUCTION have set as their target to publish their work in premium quality IEEE journals, transactions and magazines. As far as the exploitation is concerned, the REDUCTION partners have set as their target to incorporate the ideas developed in the context of this three year period into industrial products, and train young researchers


17

(offer PhD and MSc studies). Finally, as far as the contributions to standards is concerned, since the acceptance of a standards proposal is a time‐consuming process, and it is not expected that it will happen within the running‐time of the project, the partners of REDUCTION have set as a realistic target to develop new ideas, and measure their performance with respect to the currently established standards and submit these ideas for publication in journals/conferences, and afterwards to work them for a standards submission. In summary, partners will search for and use existing and contribute if possible to fleet‐management standards used in the EU. Of particular importance is the effort of the partners involved in wireless communication tasks to detect any shortcomings of the established standards in that area, and improve them.

1.3 Objective of this Deliverable

This deliverable aims at task T6.3 which is coordinated by DELPHI, and its objective is two fold: a) to review all available standards to see which are the most suitable to use and build upon, and b) to describe our efforts (i.e., UTH’s efforts) during the lifetime of the project on the implementation and extension of the Geonetworking protocol, as well as on dissemination protocols. As far as the former goal is concerned, the results will feed into the standards being used in all work packages to be highly interoperable with other passenger fleet‐management systems not developed in REDUCTION. Solutions delivered by REDUCTION will build, wherever possible, upon existing open source/freely available standards. If for any scenario no current standard is sufficient, the most promising one will be extended accordingly. As far as the latter goal is concerned, contributions to standards have arisen by making extensions to existing standards (i.e., Geonetworking protocol) or developing new solutions (i.e., pCoCe protocol). These will be communicated with the expert sub‐committees of standard issuing organisations (e.g., ISO, SAE, IEEE) and approval of suggested extensions will be sought.

Objective to achieve Task Methodology

Traffic information exchange Setting a common set of data exchange specifications

Use of DATEX II standard

Network management Interoperability of road traffic management systems

Further development of the DVM‐Exchange standard

V2X communication (SAE J2735, SAE 2945)

Support for application processes DRSC message sublayer

V2V multi‐hop vehicle communication Georouting capabilities Extensions to the Geonetworking protocol (IEEE 1609.3)

V2V network‐wide communication Network‐wide broadcasting A better alternative than IETF RFC3626

Table 1. Summary table for the objectives of the deliverable.


18

2. Related Work and REDUCTION In this section we will describe the basics of three standards that will play a crucial role in the design of REDUCTION. Although, REDUCTION’s areas of interest are quite broad and the standards developed there are could also be part of this deliverable, we focus here exclusively on the standards that are absolutely related/necessary to REDUCTION.

2.1 The DVM‐Exchange Standard

2.1.1 Introduction Network Management (NM) manages road traffic in a way that takes the network context into account. It contrasts with the more common local measures for traffic management, such as traffic signals, ramp metering, and variable message signs, that have a geographic scope of at most one node in the network or just a short road segment. It is easy to solve congestion at one place by shifting it to some other place. This is what local measures often do and what NM tries to prevent. But NM is not a well‐established method of traffic management. It is in the middle of the process of development, a process started in the mid‐nineties and which is rather slow, due to a number of reasons, the most important one being the sheer complexity of traffic behavior in a network, especially dense traffic. The increasing levels of congestion in many densely populated areas in the world urgently need an effective NM, because local traffic management measures are limited in their capabilities for structural reduction of congestion. Speeding up the development process of NM would be welcomed by traffic management authorities at many places in the world.

A second important reason for the slow development of NM is that implementing NM systems is currently a tedious and expensive endeavor. This is due to the fact that one has to deal with the legacy roadside equipment, which stems from many different manufacturers and from different periods in the past and which was never designed to be part of a comprehensive NM system. Without a connectivity and interoperability standard, huge numbers of ad‐hoc interfaces have to be built and maintained, which makes implementation attempts rarely viable beyond a limited pilot period [13]. There is a broad consensus that such a standard is needed. The key challenge in developing such a standard is however the fact that the theory of NM is itself under development. This is a difficult chicken‐egg dependency [12]. Current descriptions of NM ([2][3][4][5][6][7][8][9][10][11][14][15][16][17][18]), of which we fully and unequivocally acknowledge their pioneering contributions, usually lack sufficient detail and formality and were mostly written by traffic engineers, not by multi‐disciplinary teams.

An interesting approach is to have all “entities” communicate via a shared database which is the approach followed by UTMC (http://www.utmc.uk.com/index.php). However this


19

technique complicates the situation since the ownership of the database might cause legacy issues and it is contrary to the policy of many enterprises that refuse to outsource their business‐critical data to third‐party systems.

Happily enough, not all details of an NM theory are relevant to the standard. Below, a more formalized description is given of an approach to NM, for the purpose of standard development. It encompasses the key notions found in the aforementioned descriptions, fills in some necessary extra details, and is not, in any essential way, inconsistent with these descriptions. A key property of the standard is that it defines cooperation between systems in terms of effects on traffic and not in terms of system‐specific details. The latter would greatly reduce the general applicability of the standard. On the other hand, especially in case of legacy systems, this property may cause loss of functionality, when certain system‐specific interactions between two systems are hard to translate into effects on traffic. To that end, a user defined part has been included in the standard.

DVM Exchange [1] offers a standardized way to allow traffic management in the situation given below. DVM Exchange uses an open protocol and an accepted traffic management methodology. The effectiveness of traffic network management (TNM) will increase tremendously if systems of different vendors and administrators work together.

Figure 1 demonstrates the present situation where traffic management services are invoked in the blue area, (see increase outflow and reduce inflow near the green arrows). If only one area is managed it can lead to a propagation of the problem to adjacent areas.

2.1.2 Overview of the DVM‐Exchange standard Usually, connecting traffic management systems is part of an overall plan for a given area, in which many systems have to be made interoperable. The standard is however described from the bilateral point of view: connecting two systems (Figure 2). These systems may comprise two traffic control centers or two systems within the same traffic control center. The standard makes

Figure 1. Present situation in traffic management.


20

a number of assumptions about the two individual systems, and about their relationships.

Each system has:

an owner;

a management area;

a capability and a responsibility for traffic in its management area;

in that area there are no other systems with overlapping responsibilities (case of connecting systems with overlapping responsibilities that share the same management area will be covered by the standard, but is omitted in this article).

The two systems have the following relationships:

They are neighbors: management areas are non‐overlapping and share part of their boundary (peer to peer case), or one area falls within the other area (child to parent case);

They share one owner or the two owners know each other and interact;

The two systems have a shared clock;

The two systems are not otherwise connected.

For legacy systems, these assumptions are usually not fulfilled. It will often be necessary to make adaptations to the legacy systems to comply with these requirements. Often, for legacy systems, management areas are not defined, or if they are defined, they are overlapping. There can be several unrelated legacy systems having comparable effects on traffic without proper definition how they are related (which breaks the one‐captain‐per‐ship principle). This spaghetti will have to be cleared first, before much can be done with the standard. It is tempting to leave existing management system configurations untouched and just replace the existing system‐specific connections by DVM‐Exchange connections. This may work in the short term, but this is not how the standard is meant to be used. In such cases, it will be hard to describe the interactions between systems in terms of desired effects on traffic that fit well within an overall

Figure 2. Two TM systems connected via DVM Exchange.


21

TM approach for the given area. The standard includes a ʺuser definedʺ section, that may server a purpose in this case, but is should be clear that objectives of the standard are not served by overloading the ʺuser definedʺ part. User defined parts are usually ad‐hoc for each pair of systems, and therefore will cause much interaction between system owners, for first realization and for maintenance.

2.2 The Datex II standard Datex II is a set of specifications for exchanging traffic information in a standard format between disparate systems. It is aimed at harmonising the exchange of traffic and travel information across Europe, at all levels applicable to road operators (non‐urban and urban) and service providers. Datex II covers all traffic information which is related to non‐urban and urban road networks. This ranges from traffic events such as accidents and road works to traffic flow, occupancy and travel times. The implementation of Datex II links enables the exchange of real‐time traffic data between the Highways Agency’s NTCC and Local Transport Authorities. It facilitates the electronic exchange of traffic and travel related data between traffic centres including cross border exchange. Datex II is a structured data model using UML, this features a platform independent model that can be mapped to multiple implementation platforms.

Datex II is used for machine to machine exchanges of operational data both within and between organisations to:

Exchange real time traffic & travel data with other highway authorities;

Facilitate a co‐ordinated approach to incident & traffic management;

Harmonise the exchange of traffic and travel information across Europe at all levels applicable to road authorities & service providers;

Enable road authorities to supply service providers with real time traffic data;

Support the co‐ordination of cross‐jurisdictional boundary incident management or diversion measures;

An organisation adopting the Datex II approach can exchange traffic information and data between its own systems and those of other organisations. Machine to machine exchanges enable highway authorities to view traffic conditions and events on neighbouring networks without the need to rekey large amounts of data.

More information about DATEX II can be retrieved from www.datex2.eu/.


22

2.3 Intra‐Vehicle communications standard

2.3.1 Overview The J/1939 standard defined by the Society of Automotive Engineers is a recommended practice used for communication among vehicle components. This standard is very commonly in heavy duty vehicles as well as omnibuses in public transportation. Controller Area Network (CAN) is used for the physical layer and data‐link layer. The bus‐speed is 250kBit/s (defined in J1939/11 and J1939/15, generally used on trucks as well as omnibuses).

2.3.2 FMS – Fleet Management Systems The FMS‐Extension to the SAE J/1939 is based on and fully compliant to the standards J/1939‐21 and J/1939‐71. The FMS‐extension has been created by a group of market‐leading heavy‐duty manufacturers (IVECO, Daimler Trucks, SCANIA, MAN, and VOLVO) with the purpose in mind to have a common way to communicate with automotive components (ECUs) and the core FMS‐component that manages large flees of heavy duty vehicles or public transport vehicles. For the scope of the REDUCTION project only a subset of available data is useful, which is namely the fuel consumption and vehicle motion information (yaw‐rate and velocity). The fuel consumption information is carried by the parameter group numbers PGN 64777 (SPN 5053 & SPN 5054) as well as PGN 65257 (SPN 182 & SPN 250) of the J/1939 standard. The FMS‐standard extension utilized in the Daimler EvoBus GmbH CITARO omnibus FMS‐interface unfortunately does neither support information requesting nor trip fuel information. Also, any information about the data format within the Daimler EvoBus GmbH CITARO omnibus FMS‐interface was obtained while researching the SCANIA FMS documentation, due to lack of support and strong resistance of the Daimler Company to provide any information on this matter.

2.4 V2X communications standards

Wireless vehicular communication has the potential to enable a host of new applications. The automotive industry is working to develop the dedicated short‐range communication (DSRC) technology, for use in vehicle‐to‐vehicle and vehicle‐to‐roadside communication. The effectiveness of this technology is highly dependent on cooperative standards for interoperability. This section will briefly explain the content and status of the DSRC standards being developed for deployment. Although the standard includes IEEE 802.11p amendment for wireless access in vehicular environments (WAVE), the IEEE 1609.2, 1609.3, and 1609.4 standards for Security, Network Services and Multi‐Channel Operation, the SAE J2735 Message Set Dictionary, and the emerging SAE J2945.1 Communication Minimum Performance Requirements standard, we will discuss in this deliverable only the SAE message sublayers,


23

since it the area where DELPHI and UTH will work thoroughly.

For the V2X area the networks can be divided in the following way (Figure 3):

Figure 3. Red marked cells describe DELPHI’s efforts in SAE.

Delphi will continually be active in the development of EU and USA standards by participating in committee activities in SAE, ETSI, etc. Due to Delphi’s global presence, harmonized standards are desirable that allow common products to deploy world‐wide with minimal configuration differences. Our intent is not to create closed standards, and we support open standards that enable quick adoption on a large scale. A specific example of such a harmonization is the use of SAE’s Basic Safety Message (BSM) and the ETSI Cooperative Awareness Message (CAM). The exact format of both messages need not be identical but the essence of content and performance requirements should be compatible.

Within the SAE subcommittee, Delphi tried to address the same difficulty that the consortium REDUCTION is facing. We called it the standard J2922, which was chaired by Dave Anton. Here we lobbied the car manufacturer to give the market (suppliers and others) the CAN data, the reason being that the aftermarket safety devices and companies producing energy saving devices will benefit from this message information. For example: when it’s known the fixed amount of energy is being used to travel from point A to point B, then the energy saving can be


24

shown using such aftermarket devices. This effort by Delphi and others was not successful, since the OEMs resisted.

2.4.1 SAE Standardizations efforts for V2X

J2735 – DSRC Message Set Dictionary

Scope: This SAE Standard specifies a message set, and its data frames and data elements specifically for use by applications intended to utilize the 5.9 GHz Dedicated Short Range Communications for Wireless Access in Vehicular Environments (DSRC/WAVE, referenced in this document simply as “DSRC”), communications systems. Although the scope of this Standard is focused on DSRC, this message set, and its data frames and data elements have been designed, to the extent possible, to also are of potential use for applications that may be deployed in conjunction with other wireless communications technologies. This Standard therefore specifies the definitive message structure and provides sufficient background information to allow readers to properly interpret the message definitions from the point of view of an application developer implementing the messages according to the DSRC Standards.

In addition to being members of the major technical committee, a Delphi employee served terms as vice‐chair and chair of the Traffic Information Subcommittee. This subcommittee focuses on traveler advisories, traffic probe reporting, vehicle platooning, and commercial vehicle communications.

Here the European car‐2‐car consortium reports the following standard:

The European ITS standards are defined by ETSI and CEN, as describe below. The over the air message set in split into several documents, mainly:

ETSI TS 102 637‐2 “Specification of Cooperative Awareness Basic Service”

The Cooperative Awareness Messages (CAMs) are distributed within the ITS‐G5 (802.11p) network and provide information of presence, positions as well as basic status of communicating ITS stations to neighboring ITS stations that are located within a single hop distance. All ITS stations shall be able to generate, send and receive CAMs, as long as they participate in V2X networks. By receiving CAMs, the ITS station is aware of other stations in its neighborhood area as well as their positions, movement, basic attributes and basic sensor information. At receiver side, reasonable efforts can be taken to evaluate the relevance of the messages and the information. This allows ITS stations to get information about its situation and act accordingly.

ETSI TS 102 637‐3 “Specifications of Decentralized Environmental Notification Basic Service”


25

This document provides the specification of the DEN basic service, which mainly supports the road hazard (RHW) warning application. More specifically, the document specifies the semantics of the Decentralized Environmental Notification Message (DENM) and the DENM handling. A DENM transmission is triggered by a cooperative RHW use case to provide information about a specific driving environment event or traffic event to other ITS stations. The ITS station that receives the DENM is able to provide appropriate HMI information to the end user, who makes use of these information or takes actions in its driving and travelling. The concept of the DEN basic service is derived from the functional requirements of BSA as defined in ETSI TS 102 637‐1: ʺ Basic Set of Applications; Part 1: Functional Requirementsʺ and operational requirements of BSA as defined in ETSI TS 102 637‐4: ʺBasic set of applications; Part 4: Operational Requirementsʺ.

Further messages Signal Phase and Timing (SPAT) and Topology Message (TOPO) are currently only available in draft versions.

J2945 – DSRC Minimum Performance Requirements

Scope: This document specifies the minimum communication performance requirements of the DSRC message sets, the associated data frames and data elements defined in SAE J2735 DSRC Message Set Dictionary. The document consists of multiple sections. Each section describes a specific message setʹs requirements. For example, J2945‐1 represents Basic Safety Message communication minimum performance requirements

Rationale: The SAE J2735 DSRC Message Set Dictionary defines the message and data format. However it does not standardize how the data and message shall be used, such as message transmission rate, channel usage, optional data usage in various situations. In order to achieve full interoperability, a minimum performance document is necessary.

Here the European car‐2‐car consortium reports the following standard:

By the nature of co‐operative systems ITS station may need to rely on some performance metric of other cooperating stations. The profile working group of the Car‐2‐2Car Communication Consortium (C2CCC) is working on the definition of basic system addressing the need of market introduction. This Basic System (Figure 4) is a Vehicle ITS sub‐system enabling a set of Day‐One Use Cases. In the “C2CCC Basic System Standards Profile” document, C2CCC defines a Standards Profile as guideline for specification of the C2CCC Basic System. The resulting Standards Profile shall enable interoperability among implementations in vehicles of different partners with regards to the Day‐One Use Cases, taking into account requirements such as security, information quality, and efficient use of spectrum in the 5.9 GHz range. Thereby, the


26

profile is targeting the European market.

Figure 4. C2CCC basic system components.

An extended version of the Basic System is shown in Figure 5. The extension supports multi‐channel, multi‐interface operation, service management and IP‐based Addressing.

Figure 5. C2CCC extended basic system components.

The Standards Profile for the Vehicle ITS sub‐system can then serve as basis for discussion and orientation for the definition of Standards Profiles for Personal and Roadside ITS sub‐systems in joint efforts with other stakeholders. Because of very similar system requirements, it can be expected that many of the standards in the Basic System Standards Profile are also used in the Standards Profiles of Roadside and Personal ITS sub‐system.

The European Commission invited on October 2009 the European Standardization Organizations CEN, CENELEC and ETSI to prepare a coherent set of standards, specifications and guidelines to support European Community wide implementation and deployment of Co‐operative Intelligent Transport Systems (ITS).

CEN and ETSI formally accepted the Mandate M/453 in January 2010 and provided a joint Response to the Mandate in April 2010. The Response to the Mandate included a list of


27

minimum set of standards for interoperability and the split of responsibility between these two European standards organizations (ESO). In April 2011 CEN and ETSI provided a status report on the standardization activities in accordance with the agreed split of responsibilities in the first response to the Mandate M/453.

CEN and ETSI have agreed to jointly develop the response and work program under this Mandate with a list of minimum set of standards for interoperability and other identified standards and technical specifications to support Co‐operative ITS services. This work program also defines an agreed split of responsibility between CEN and ETSI as well as a detailed description of the ongoing cooperation between the two ESOs. A task force has been established for this purpose and the ITS‐SG monitors the activity.

As requested in the Mandate, the standardization work will require extensive cooperation and liaisons with European and National R&D projects, European industry and other stakeholders including the automotive industry, road operators and road authorities in order to ensure that the results of ongoing R&D activities and stakeholder knowledge and experience are brought into the standardization process.

As mentioned in the Mandate, standardization is a priority area for the European Commission in the ITS Action Plan1 in order to achieve European and global cooperation and coordination. Standardization for Co‐operative ITS is already initiated within standardization organizations such as ISO, IEEE and SAE as well as in CEN and ETSI. The standardization activity in accordance with Mandate M/453 will therefore take account of the existing achievements worldwide and include these activities in the European standardization with the aim of achieving globally accepted technical standards for Co‐operative ITS supporting future implementation.

Objective and policy background of the Mandate

The policy objectives that form the background for the Mandate are supported by CEN and ETSI and shape the proposed standardization activities. This includes, in particular, the European Commission Communication on i2010, the intelligent Car initiative and the European Parliament resolution towards European‐wide safer, cleaner and more efficient mobility. Furthermore standardization is a key priority area of the ITS Action Plan and efficient steering of the European standardization activities for Co‐operative Systems is important to achieve the objectives of the Action Plan. CEN and ETSI support the objective to develop and adopt common European Standards for Co‐operative Systems and have taken the general policy objectives into account in the detailed planning of the standardization activities in accordance with the Mandate.


28

Minimum set of standards to ensure interoperability to be developed as ENs

The minimum set of standards is understood as a set of standards which forms the essential basis for the realization of Co‐operative systems and simultaneously is open for extension with regard to applications and as well with regard to other technologies. Therefore a framing is defined by both a framework architecture and a communication architecture which supports the implementation of a basic set of applications as described in ETSI TR 102 638.

Division of Responsibility between CEN and ETSI

The long list of required standards indicates the division of responsibilities to lead work items between CEN and ETSI. The lead organization will establish the work item including a time schedule according to the overall roadmap of this Mandate. Contributions from the other organization and stakeholders are always welcome and, in some cases, necessary.

The division of responsibilities is centered on primary capabilities, with the competence of ETSI in the field of communications and the relation of ETSI to the Car‐2‐Car Communication Consortium with the experience of vehicle‐to‐vehicle applications. CEN has a focus on the overall framework architecture and on the roadside and traffic management applications, which mainly involve vehicle‐to‐road‐infrastructure and infrastructure communications (Figure 6).

Figure 6. Cooperation overview ‐ Mandate M/453 context.

A number of technical committees are actively providing standards for ITS:

CEN TC278 Road Transport and Travel Technology (www.nen.nl/cen278/) was the first purely ITS committee and started in 1992. This is a European organization with official national participation, and as such under governmental control. Active participation comes mainly from administrations, transport operators and their supplier industry. TC278 have produced 112


29

standards with about 30 more in various stages in completion. 16 working groups have been active throughout its lifetime, and produced standards for Electronic Fee Collections (EFC/ETC), Freight and Fleet Management, Public Transport, Travel and Traffic Information (RDS‐TMC), Dedicated Short‐Range Communication (DSRC), Human Machine Interaction, Automatic Vehicle and Equipment Identification and Architecture. Within the last few years some new working groups have been established on Recovery of Stolen Vehicles, eSafety (eCall) and the latest on Cooperative Systems.

ETSI TC ITS (www.etsi.org/its) is the most recent TC with active participation from governmental organizations and industrial stakeholders such as car manufacturers, their component suppliers and telecommunication network operators. TC ITS is continuing the work started in TC ERM TG 37, founded in 2004. Some work items are directed towards communications subsystems, with a special focus on communications within the spectrum dedicated for ITS by the Commission Decision 2008/671/EC. Other work items cover aspects such as application facilities, testing and data structures. There are about 75 work items under way in ETSI with some standards already being published and some being in the approval process including the first dedicated co‐operative ITS standard (EN 302 665) as response to the Mandate 453.

Here (click) we can see a list of published ETSI TC ITS standards that are related to the European Commission Mandate M/453 on Cooperative ITS. By today (Feb. 11, 2014), the list includes 76 documents published.

ISO TC 204 Intelligent Transport Systems has started in 1993. There is a direct relationship with CEN TC 278. Some working groups of these two technical committees are joint groups under the Vienna Agreement so that finished Work Items automatically become both European and International Standards (EN IS). Among others TC 204 has working groups covering Integrated Traffic Management, Information and Control Systems, Wide area Communications (CALM), Nomadic Devices and Cooperative Systems.

In addition to these three committees, there are several other organizations that produce standards relevant to ITS as part of their work:

IETF is producing Internet standards with relevance to ITS, in particular the MEXT group is producing Mobility EXTensions for IPv6 which support the rapidly changing network topology and addressing in a car/roadside environment. These extensions have been incorporated in CALM and ETSI standards.

IEEE P1609 is dedicated to the upper communications layer for 802.11p with a focus on


30

North American needs.

IEEE also provides the essential base standard for 5.9GHz communications, known as 802.11p.

SAE has a group defining data elements for the payload of ITS applications (SAE J2735).

ISO TC211 Geomatics covers maps, location referencing and basic data formats.

ISO TC22 works on standards related to land vehicles and cooperates closely with ISO TC204. Several vehicle‐internal ITS standards have been developed there, in particular HMI and sensor standards.

ITU‐T and ITU‐R have some activities, but these are mostly coordination and not currently producing technical standards.


31

3. Framework and Methodology

3.1 REDUCTION and DVM Exchange The primary goal of the DVM Exchange is to reduce the amount of interaction between system owners concerning the details of connecting the two systems, especially the IT‐technical details. This includes interaction for first realization and for maintenance. The standard offers a framework in which it is easier to make the necessary agreements on the cooperation of the two systems for purposes of traffic management.

3.1.1 Requirements for DVM Exchange A number of requirements have been formulated, that guide the development of the standard. We mention only the most important requirements:

Generality and Extensibility: the standard is intended for all types of systems involved in traffic management, for current and for future TM measures. The standard is such that it can be extended with new TM measures, while remaining backwards compatible with earlier versions of the standard.

Using the standard should not cause any functional loss.

In order to achieve this, the standard includes a ʺuser definedʺ part, which guarantees that existing, system‐specific connections, that are hard to express in effects on traffic, can still be expressed in the standard.

The standard supports SLA (Service Level Agreements)‐based cooperation between two owners, including those in which one party pays for the services of the other.

3.1.2 High‐level description Seen at a high level, the standard defines asynchronous Client‐Server interaction between systems. Interactions exist of request‐reply pairs, together called an exchange. The terms client and server only have meaning the context of such an exchange: the client takes the initiative and sends the first message, the server answers to this, and executes the request or rejects it. Requests are formulated such that they are idempotent: requests can be repeated many times without changing the intended effect on traffic. The protocol is stateless, or at least as stateless as possible. The standard allows for system failures or partial failures, but this behavior is not within the scope of this deliverable.


32

Structure of the DVM Exchange interface

The DE interface has the following parts:

The content (= the data exchanged), in which there is a generic part and a specific part. The specific part in turn consists of a regular part, and a user defined part.

Semantics: the meaning of the exchange. The regular part always has a meaning in terms of an effect on traffic at points (cross sections of roads in one direction).

The sequence of messages.

The underlying interface.

The sequence of messages is kept simple: just request‐reply interactions. The underlying interface is chosen to consist of the Web Services interface over HTTP. This is a well‐known, mature and well supported interface which covers the required functionality. This choice means that the content part is expressed in XML, following XML schemas. Technically the standard consists largely of xsd‐files, just like the comparable OCIT standard (XXX). XML also plays an important role for the extensibility requirement mentioned above, as it offers an inherently extensible data format.

Content of Requests

The content part consists of a generic part and a specific part. The generic part consists of basic administrative data that are needed in all requests: identifications for the client and the request and the time stamp for the request, to mention the most important ones.

The specific part has regular content, which fits within the intentions of the standard, and a user defined part. The latter cannot be described in further detail. It is really user defined. It should be kept well separated from the regular part. In the XML code, there is a separate element containing this part.

For the regular part, we distinguish three different cases:

p2p (peer to peer) requests

p2c (parent to child) requests

c2p (child to parent) requests.

Orthogonally to these 3 cases, we distinguish the following types of requests, although not all types are relevant in all cases:


33

Traffic management (TM) requests

Information requests

Administrative requests

Configuration requests

Escalation requests.

The TM requests are relevant in the cases p2p and p2c. Their meaning is that the client asks for an effect on traffic at one or several boundary points of the serverʹs management area. In the case p2p, the points are on the shared boundary between client and server. In the case p2c, the points are on the boundary of the child. A TM request contains the following fields:

a point (or set of points);

an effect on traffic at that point (or set of points), expressed as a quantity and an absolute value;

a characterization of traffic to which the effect applies (all traffic or trucks or public transport, etc., and/or the intended destination);

a priority;

an indication of time (starting time, end time, duration, etc.).

In the case of p2p, the server may consider to execute the request or to reject it. This depends on the serverʹs configuration. In the case of p2c, the request is mandatory, and can only be rejected if the child is unable to execute it. In the reply the server tells the client whether the request is going to be executed or is rejected.

The content of the priority field is still under discussion. Currently, it is a numerical value which expresses the priority of the clientʹs management area, to be compared with the priority of the server. Other ways are under consideration but not yet available in detail. Higher values mean higher priority. A server may be instructed by its parent to execute requests from higher priority clients.

Information requests are requests in which the client asks for the traffic state (current or near future) at a boundary point, known by the server. This applies to all three cases (p2p, p2c and c2p). Usually, the smallest area that has the point on its boundary is most likely to have information about it.


34

Administrative requests serve the functioning of the interface. It may include requests about the status of previous requests, may stop previous requests, may define shared names to be used in future requests, etc.

Configuration requests apply to the p2c case. In a configuration request, a parent instructs one of its children how to handle external requests. For instance, a parent can set priority values for its children. This is still largely to be defined. Until then, in operational use of the standard, configurations will have to be set by hand.

Finally, in the c2p case, there is yet another category of requests, namely the escalation requests. They deal with cases in which two peers have a problem they cannot solve with p2p requests and ask a common parent to solve the problem. The details of this kind of requests are still to be defined.

3.1.3 How to use the standard The typical way to apply the standard is as follows. Again we describe this as if it were a bilateral affair, which in reality will usually involve more than two TM authorities. In addition, we will only consider the peer to peer case (i.e. two authorities are at an equal level; TM authorities may also have authority relationships). We assume there are two TM authorities that would like to cooperate in the union of their neighboring TM areas. They both own TM systems, which need to be made interoperable for this cooperation. The two owners make agreements about how they will manage traffic together in their joint area, which priority settings are appropriate for their areas and which requests are needed between their systems. If things turn out well, and the legacy systems are not too far from the assumptions mentioned above, then most of these requests will fit into the regular part of the standard. Remaining requests will be included in the user defined part. Once this set of requests is defined, each owner procures or develops a DVM Exchange interface (or DE‐wrapper) for its own system, covering the defined set. The interface does not need to cover the complete DVM Exchange interface, but only a subset. In the DE interface, each request is translated into a system specific request that approximates the desired effect on traffic (or the information requested) as well as possible.

The user defined parts are communicated to the DE organization, in order to serve the further development of the standard. The same holds for the way the interfaces are implemented. This information obligation is required by the license that is needed in order to make use of the standard.

When using the standard, one should keep in mind that for any two systems, it will be easier to realize interoperability by an ad‐hoc connection, specific for the two systems. It is a considerable


35

effort to fit the connection into the format prescribed by the standard. One will have to resist this temptation, lest one will end up with many ad‐hoc connections and a huge maintenance problem (thatʹs the current situation and the main reason the DVM Exchange standard is being developed). Making sure that the connection fits with the standard, will make it easier to realize other and future connections with the system, because then, the bulk of the work for the DE‐wrapper has already been done, and it only needs to be extended with additional requests, if any.

3.2 REDUCTION and DATEX II Recall that in REDUCTION the different partners work on models for eco routing, multi modal eco routing, eco‐driving, prediction, V2V and V2I devices and communication. The information delivered from these systems is in essence the CO2 emission, fuel consumption, location, speed and travel time on certain segments/routes of the area’s that are measured. A schematic illustration of this exchange is depicted in .

Figure 7. REDUCTION message exchange flow.


36

The European standard for traffic systems to exchange data is Datex II. The Area Traffic Manager can use through the Datex II exchange, all the information from the partners to calculate an optimised Eco‐friendly route.

3.2.1 Description of the DATEX II adoption to Reduction The interface description is based on the Datex II definition. There are some information fields needed for this interface, that are not defined in the Datex II standard. For those fields some information records are defined on top of the standard. For security and authentication the standard VPN connection between two communicating systems is proposed.

There are two messages defined that needs to be exchanged between two communicating systems:

A data message, containing data values that needs to be exchanged and

A message reply, indicating the data message has been received successful or not successful.

The essential information that is exchanged within the data message is:

CO2 emission, fuel consumption, travel time and velocity.

Identifier of the measured trajectory, to relate the same trajectory in two different systems.

Location, length and geographical form of the trajectory, to allow display on a geographical map.

De data message structure makes it possible to exchange one or more trajectories within one message and for each trajectory one or more measurements.

The data message contains the following structure and field definition (see Table 2):

XML Name (DatexII) Remarks

Record: ReductionInformation

ModelVersion (integer) Fixed value “1”

SequenceNr (Int64) sequence number

Record: ReductionSupplierIdentification

Country (string) Two letter country indentification. “nl, du, fr”, etc

NationalIdentifier (string) Fixed value: “REDUCTION”

Language (string) Fixed value: “en”

MeasurementType Enumeration with values: traject or point


37

SensorType Enumeration with values: CO2 detector, calculated, ...

Record: PolutionMeasurement

PublicationTime (datetime) Current time

StartTime (datetime) Start time of the the measurement series

EndTime (datetime) End time of th measurement series

Record: ReductionLocation (there can be multiple locations or trajects)

LocationId (string) Identifier of the location

TrajectDistance (double) Unit: km. Distance of the measurement traject. Only filled in when it is a traject.

Record: ReductionLocationForDisplay (a location can have multiple points when it is a traject. This can be used to visually display the traject)

Latitude (double) Latitude of the coordinate in WSG84

Longitude (double) Longitude of the coordinate in WSG84

Zvalue (double) Height in meters above sea level (optional)

Record: GeneralComment (multiple comments possible per traject)

Comment (string) Free text field

DateTime (DateTime) Datetime of the comment

CommentType (enum) Type of the comment

Record: ReductionMeasuredValue (multiple measurement records possible, for multiple start times). Each traject can have one measurement record for each minute or other time scale. The

measurements are over the whole track.

CO2Emission (double)

FuelConsumption (double)

Velocity (double) Speed in km/hour, of the measured vehicle

TravelTime (double) Traveltime over the traject in seconds.

CO2Exhaust (double) Specific exhaust value in ? Of the measured vehicle

VehicleType (enum) Typ of vehicle. Enum with the values: Car, Bus, Truck

MeasurementStartTime (datetime) Start of the specific measurement

MeasureMentEndTime (datetime) End of the specific measurement. (optional) when not filled in the start and end time are the same.

Table 2. DATEX II data message structure and fields.

The message reply is the answer to the previous data message, indicating that the data is received. The result can be an acknowledgement or an error. In case of an error, the reason field


38

can be used to give more information about the error condition that occurred.

The message reply contains the following structure and field definition (Table 3):

XML Name (DatexII) Remarks

Record: ReductionInformationReply

Ackowledge (Boolean) “0” (failed) or “1”

OrgSequenceNr (Int64) sequence number of message for which this is a reply

Reason (string) description of the error condition

DateTime (DateTime) Time reply send

Table 3. DATEX II data message reply structure and fields.

The Datex II definition of the above structures is described in an XSD Interface description, which is developed in detail in Deliverable 4.3.1. The partners of REDUCTION will use this XSD for implementation of the interface. REDUCTION is not going to extend DATEX II; this standard’s functionality covers adequately the traffic information exchange needs of our project.

3.3 REDUCTION and V2X standards Delphi observes the standardization process on ITS worldwide. In November 2009 the United States Department of Transportation (USDOT) and Directorate General for Information Society and Media (DG INFSO) signed a Joint Declaration of Intent on Research Cooperation. The goal of the declaration is to:

“Support, wherever possible, global open standards in order to ensure interoperability of cooperative systems worldwide and to preclude the development and adoption of redundant standards.”

The EU / US joint approach towards Cooperative ITS resulted in the creation of Harmonization Task Groups (HTG). Experts from the EU and the US with support from Japan are working on an analysis of existing standards from various standardization organizations (SDOs) used for system specifications in the EU, US and Japan. These HTGs have to deliver reports on gaps (missing standards), overlaps (conflicting standards), and interoperability test specifications for testing equipment designed for usage in the US and the EU. Further on these HTGs will provide recommendations to SDOs on how to improve the global situation with standards for C‐ITS.

Although a major focus of these HTGs is on systems using 5.9 GHz communication technology, the full scope of C‐ITS is to be considered. It was made very clear that C‐ITS is not at all limited to the 5.9 GHz access technology, and the car‐centric road‐safety and traffic‐efficiency applications currently under development at ETSI. Complementary elements of C‐ITS are


39

developed e.g. jointly at CEN TC278 WG16 (under EC mandate M/453) and ISO TC204 WG18, at ISO TC204 WG16.

Throughout 2012, the harmonization task groups #1 (Security and Management Protocols) and #3 (Joint protocols for safety and sustainability services) created a series of reports that discuss the status of harmonization of ITS standardization activities between the EU and the US. Furthermore, the HTG gave recommendations for future directions of standardization activities.

The goal of the harmonization effort is not to define interoperable systems. An ITS station equipped with an European ITS stack, won’t be able to cooperate without changes with an ITS stack in the US and vice versa. Development and adoption of coordinated harmonized international technical standards contribute to the following benefits:

Improved interoperability and interchangeability of Intelligent Transportation Systems (ITS) across operational boundaries;

Reduced development and deployment costs for manufacturers;

Greater accessibility to international markets for manufacturers of connectivity equipment;

Increased competition and innovation amongst manufacturers which can help lower costs and expand service for consumers;

The potential for a more rapid deployment of ITS systems;

Leveraging of international expertise and reducing redundant efforts.

Delphi, as a tier‐1 supplier, is focused on the practical impact on ITS harmonization. Since, frequency regulation in the 5.9 GHz area covers similar bands for EU and the US, similar hardware developments are expected for both markets. Frequency regulation is more restrictive in EU than in the US. So, on‐board equipment designed for the EU will also fulfill spectrum requirements in the US. Higher layer software stacks are similar, but slightly different. On one hand, direct interoperability is not addressed by harmonization. On the other hand, use cases and the security approach are very similar. If requirements for secure handling of security certificates are coherent, ITS vehicle systems might be switched from one system to the other by a firmware update. For example, messages defined in SAE J2735 for the US or by ETSI TS 102 637‐2 and ETSI TS 102 637‐3 for EU follow the same system design and require similar message handling and processing power. It is to be expected that OEM specific partitioning of the specific in‐vehicle system will have more influence in the design of mass market products than differences in the ITS stacks.


40

3.3.1 DELPHI’s active involvement in standards: 4.5.1 Car‐2‐car consortium standardization work

Delphi is also an active member in the car‐2‐car consortium. Here DELPHI is mainly involved in the architecture and communication standards. The block diagram below shows the basic ITS‐subsystem that the car‐2‐car consortium understands is that of Figure 4.

Present standards profile document, defines a minimum set of standards and fills missing gaps for creating an interoperable C2C‐CC basic system supporting cooperative intelligent transport system (C‐ITS) applications, with the aim of increasing road traffic safety and efficiency. Delphi is particularly interested and contributed to the positioning and timing sub‐charts: Positioning and timing protocol has several parts:

POS001 is fixed as the following: A car‐2‐car basic system should update its position at least 10 times /second when the vehicle is in safety related context.

The POS002 is fixed as the following: After at least one successful GPS fix, the Car‐2‐car basic system shall keep the system time deviation within 20 milliseconds of the ITS time as specified in the ITS guidelines published by the Car‐2‐car consortium. It was also decided that if the time cannot be updated due to missing GPS reception, the time deviation can be approximated based on the time passed from the last verified time synchronization, but only up to certain specified time which is not yet fixed.

The POS003 is fixed as the following: If a successful GPS fix is obtained, the C2C‐CC basic system shall keep the system position deviation within 40 meters with a probability of 95% as measured inside a time interval of 30 seconds.

Delphi is working on the standardization of the management layer. The management layer consists of configuration management, Congestion control management based on network design limits (NDL) and Cross‐layer information exchange via management. These standards are not set yet.

Delphi is also involved in the Car‐2‐Car Communication Consortium Antenna Task Force. The objective of this task force was the following:

To provide the specification of relevant antenna‐related quantities that determine the performance of V2V communications based on a chosen subset of relevant use cases and describes the testing procedures of the communication link for vehicle‐to‐vehicle (V2V) applications. It was the objective of the task force to provide the appropriate means to prepare standardization activities in the area of automotive antenna equipment for Car2Car


41

communications, as well as identify the limits of the system.

The key objectives of task forces white paper was the following:

Define critical use cases that provide quantitative numbers for the minimum requirements and pre‐warn times for safety‐relevant applications

Provide the subset of required propagation models for different environments and conditions (line‐of‐sight (LOS), non‐line‐of‐sight (NLOS)) in order to characterize defined use cases and realize detailed link budget analysis between transmitter and receiver.

Define all standardization relevant antenna performance parameters that have an impact on the link budget from an antenna’s perspective.

Description of measurements to be performed for the characterization of the antenna performance qualification and provide possible antenna patterns for the car to car communication.

Provide examples of Link Budget Computation, to define the packet success rate.

The reference Model that will be used is that of Figure 8, which depicts an abstract model of a car‐2‐car communication link.

Figure 8. Abstract C2C link.

The C2C communication link is composed of three parts: transmitter, radio channel and receiver.

The antenna frontend and its impact on the wireless channel predominantly define the available link budget between each node in a vehicular network.

V2V communications may only provide an improvement in traffic safety and reliability if every node within the vehicular network provides capabilities to attain a minimum communication


42

range, which in turn leads to specific requirements for antenna performance.

Definition of Antenna Performance

All parameters were summarized that have an impact on the antenna performance when the antennas are mounted on a vehicle. Some of the parameters are related to the communication channel itself. Other parameters depend on the aspects of vehicular integration, and they include:

Polarization loss.

Effect of finite sized roof‐top or other antenna mounting areas such as mirrors.

Effect of elevated roof top.

Influence of surrounding antenna hood.

Mutual coupling with additional antennas in the same mounting compartment.

Influence from roof insets, sun roofs or railings for roof antennas.

Additional implementation losses.

Work was also done to define parameters which are necessary to characterize the antennas for C2C deployment. It was also pointed out that by characterizing only the antennas there is no guarantee that a successful communication link will be achieved. Distinction needs to be therefore made between antenna and communication link performance.

Antenna

In order to guarantee link performance, two quantities need to be specified subsequently:

TX antenna gain

Minimum receive power at the receiver input port.

In order to combine antenna‐related parameters (e.g. antenna gain) to yield the minimum link requirements, it is straightforward to define explicit EIRP values. In terms of EIRP values, the TX antenna needs to fulfill the following conditions:

The minimum available antenna EIRP needs to provide sufficient link margin

Due to the fact that with the state‐of‐the‐art technology the maximum antenna EIRP of 33 dBm at any angular position according to ETSI standardization cannot currently be achieved,


43

we define as an accepted EIRP value 23 dBm to 25 dBm.

Due to limitations in antenna manufacturing and automotive mounting, the definition of a sharp minimum available antenna gain represents an unfeasible goal. Integration aspects may easily lead to a punctual degradation of antenna performance at a defined angular position in space. Therefore, stochastic metrics in terms of minimum antenna performance are to be defined.

To evaluate the performance of an antenna an additional stochastic metric which will be called level crossing rate is established. For each point on the measurement grid the TX antenna gain has to be determined and all values below a threshold PTH have to be included as follows:

( )∑=

<=N

nthnncr GGG

Np

1|1

In order to define the level crossing rate two additional quantities need to be specified:

the threshold value PTH which is set to 3dBi

the percentage value: pLCR which is set to 90%

The stochastic performance metrics need to be evaluated within a specific solid angle. The limits of the solid angle depend on the relative position between communicating TX‐ and RX entities in the V2V link. Using the antenna spherical coordination system, we suggest limiting the range between the co‐elevation angles of 80° (with 90° equivalent for the horizontal plane) and 110°. In azimuth, all angular values 0° ≤ � ≤ 360° need to be considered.

The purpose of the elevation solid angle is to take into consideration the communication link between vehicles of different heights (e.g. trucks) or communication in different traffic vehicle positions (e.g. up/down hills).

Table 4 defines the specification of antenna parameters. It was suggested by the group to evaluate the level crossing rate at a threshold value of PTH that completely consumes the available link margin at a percentile of 75%.

Practical implementations of single antennas suffer from notches in its polar diagrams. To overcome this problem multiple antenna systems can be used. The calculation of the level crossing rate shall consider this aspect by choosing the maximum gain value of all antennas at each grid points.


44

Average TX antenna gain

The average TX antenna gain is calculated by

∑=

=N

nnav G

NG

1

1 ,

where N is the number of grid points of TX antenna gain values and the gain in the given solid angle.

No. Performance Definition Unit Value 1 Average antenna TX gain in angular range

0°≤ϕ≤360° and 80°≤ϑ≤100° dBi 3

2 Percentile of level crossing rate in angular range 0°≤ϕ≤360° and 80°≤ϑ≤100

pLCR % 75

3 Maximum antenna TX EIRP in angular range 0°≤ϕ≤360° and 80°≤ϑ≤100°

EIRP 33dBm

Table 4. Specification of minimum antenna performance.

Polarization

A vertical polarization was recommended by the group.

Communication range

It is clear that an antenna or antenna array that meets all demands regarding average gain and percentile of level crossing rate is not the only factor to assure a successful communication link. Therefore aside from the antenna characterization, a metric that allows for the overall system verification in a given communication range is also defined.

The packet success ratio is defined as the percentage of correctly received packets by an arbitrary receiver which is sent by the C2C‐CC basic system.

For a vehicle to pass the communication range test, a packet success ratio of 90% is defined.

Measurement and Performance Qualification

Different measurements need to be performed for the characterization of the antenna with and without the system. The focus is the measurement of the communication range and the consequently verification of the level crossing rate and values given in the table above. Before doing these measurements, it should be ensured that in‐system sensitivity measurements have been done.


45

Antenna measurements

The gain measurements can be performed in an anechoic chamber where the antenna is placed on a roof phantom of a vehicle. Such typical measurements allow for both angle planes to be recorded and for the calculation both of the average antenna gain and the percentile of level crossing rate of the AUT (antenna under Test). The measuring procedure is the same standardized procedure used for all antenna measurements in anechoic chambers.

The angle resolution for the antenna radiation pattern both in the elevation and the azimuth plane must be as high as possible but at least one degree (��, ��≤ 1°) and the measured angle range should be performed for the angle range listed in table 2. The reason for wanting a high measurement resolution is to record as accurate as possible the radiation pattern of the antenna, when the antenna is mounted on a vehicle.

Communication range measurements

The communication range measurements will be conducted in a calibrated outdoor vehicular antenna measurement range test scenario. These measurements are also based on typical outdoor gain measurements techniques of antennas. A turn table allowing a 360° car rotation as well as an elevation angle setting facility must exist in the measurement site.

Test scenarios

The measurements can be performed under two different scenarios. These scenarios differ from each other by the distance between the transmitter (TRX) and the receiver (TRY) as well as between the transmit power Scal (e.i.r.p).

Figure 9 gives an overview of the general scenarios and Table 5 lists the main differences between them.

Figure 9. A generic test scenario.

Test Scenario Distance: D

Transmit Power: Scal

Threshold Sdrop

Reference Antenna height: H


46

1 400 m 23 dBm (EIRP) ‐85 dBm 1.5 m 2 850 m 25 dBm (EIRP) ‐92 dBm 1.5 m

Table 5. Test scenario parameters.

A stationary reference station TRX is located in D from the vehicle under test CAR. The reference station antenna is at height H above ground. TRX is calibrated using the transmit power Scal in the direction of CAR. In that case the received signal strength at CAR is given by Srx_cal. TRX shall be able to modify the transmit power quasi continuously, e.g. by using a tunable attenuator and also to transmit with high packet rate, i.e. not controlled by DCC.

The receiver of TRX must be able to drop all received packets with received signal strength below a tunable threshold Sdrop normally set to the CCA threshold SCCA.

TRX and CAR are started at least Twarmup = 5 s before the test run.

During the test the vehicle rotates slowly. Alternatively the vehicle may drive a small circle of radius r ≤ rmax=10 m.

The measurements need to be taken on an angular grid with M positions in elevation and N positions in azimuth. The angular grid has to be defined according to the measurements requirements and the plots representing the values of the EIRP shall be drawn with an angular resolution not larger than 2°.

EIRP shall be measured at least at three frequencies including the start, center and end frequency in a frequency interval between 5.875 GHz and 5.925 GHz. The EIRP value is measured from the transceiver output. This means that all relevant additional components (e.g. cables and connectors) are considered during the measurement.

In case of a multiple antenna system, the EIRP shall be determined in accordance with the used diversity method. For example in case of switching diversity, The EIRP outgoing from each antenna shall be measured. Consequently, the best antenna for each angle shall be chosen and the EIRP is then verified in accordance to table mentioned in page 29. The car‐2‐car consortium paper also mentions several other criteria, where other members worked.


47

4. Extensions to Geonetworking protocol During the project’s second year, UTH has implemented the Geonetworking protocol, as described in the standard ETSI TS 102 636‐4‐1. This implementation revealed several aspects of the protocol that can be enhanced in order to reap improved performance. In this section, we will briefly describe the enhancements, and then provide details about the implementation of the Geonetworking protocol.

4.1 Proposed contributions to the standard ETSI TS 102 636‐4‐1 Here, we address open issues to the existing ETSI TS 102 636‐4‐1 standard for media independent Geographical addressing and forwarding for point to point and point to multipoint communications. These issues will be briefly described in this deliverable and the detailed experimental evaluation of them will be presented in D6.3.3, i.e., the final deliverable about REDUCTION’s contributions to standards.

Based on an implementation of the Geonetworking protocol by UTH, and on its evaluation under a real testbed configuration (UTH’s NITlab testbed) we propose some amendments to the existing standard. Our propositions are targeting at a better network usage and the avoidance of unnecessary transmission of Geonetworking packets. Our suggestions are summarized as follows:

Cross layer optimizations. Geonetworking currently operates independently of the MAC layer of an ITS station. However, this can lead to unnecessary creation of packets based on the data collected by the GeoNetworking layer. For example, in the case of some Location Table Entries, which are not considered as invalid yet (the timer has not expired) the packet destined to them will be created and passed to the Link Layer entity for processing. However, when no neighboring stations are present, this may lead to unwanted transmissions. Based on the fact that the MAC layer of a station can collect real time data concerning the neighboring stations, we propose a scheme where either this real time data is used to invalidate the Location Table entries or that would discard the packets in the MAC layer.

Handling of the LS Request packets. An LS request packet is issued when the sought address is not present in the Location Table of the ITS Station. The packet sent out is a Topologically Scoped Broadcast (as defined by the standard). However, no extra care is taken in the case that the Location Table is empty or the station has currently no neighboring


48

stations, thus making an unnecessary transmission of a packet.

Handling of GeoBroadcast packets. GeoBroadcast packets are transmitted in a geographical region. The packets are meant to be received by all the stations present in one geographical region (either a circular, ellipsoidal or a rectangle region). In the current GeoNetworking specification, the retransmissions that might take place inside the region are meant to be handled by the duplicate packet detection and the sequence number of the packet. During a situation where vehicles remain stationary, the same packet could be exponentially retransmitted, depending on the number of the vehicles present. Thus, we propose an alteration of the duplicate packet detection in such cases; In the cases that no position updates are received in a specified period, all packets that are received from neighboring stations and are GeoBroadcast packets shall not be retransmitted, if the same packet has been received from all the neighboring stations.

4.2 Implementation of the Geonetworking protocol In the following subsection we present the implementation of the Geonetworking protocol, after providing some background information.

4.2.1 Intelligent Transport Systems Architecture

Figure 10: ITS Network Architecture

Figure 10 represents the highest level of abstraction of the ITS network architecture, where the external networks, represented by clouds are connected. The networks can be categorized into an ITS domain and a generic domain as specified in [19]. The external networks can be described as follows:

The ITS ad hoc network enables ad hoc communication among vehicle, roadside and personal ITS stations. The communication is based on wireless technologies, that typically provide a


49

limited communication range referred to as ʹshort‐range wireless technologyʹ) and allow for mobility of the ITS stations forming arbitrary network topologies without the need for a coordinating communication infrastructure. An example of an ITS ad hoc network is a network of vehicle, roadside and personal ITS stations interconnected by ITS‐G5 [20] wireless technology. Generally, an access network enables ITS stations to access networks.

An ITS access network is a dedicated network that provides access to specific ITS services and applications and can be operated by a road operator or other operators. The ITS access network also interconnects roadside ITS stations and provides communication in between these as well as among vehicle ITS stations via the roadside ITS stations that are interconnected in the ITS access network. This local network can then enable the vehicle ITS stations to communicate via a roadside infrastructure communication network instead directly in ad hoc mode. As an example, an ITS access network can connect roadside ITS stations along a highway with a central ITS station (e.g. a road traffic management centre). In the case that short‐range wireless technology is used for communication via roadside ITS stations, the connectivity to the ITS access network is typically provided intermittently.

A public access network provides access to general purpose networks that are publicly accessible. An example is an IMT‐2000 [21] network that connects vehicle ITS stations to the Internet and provides mobile Internet access. A private access network, in contrast to a public access network, provides data services to a closed user group for a secured access to another network. For example, a private access network can connect vehicle ITS stations to a companyʹs intranet.

The access networks and the core network provide access to various services:

• legacy services , such as WWW, email and many others; • ITS services provided by road traffic management centres and backend services; • ITS operational support services required to operate the ITS, such as security services.

Core component of the architecture is the ITS station, which has two main roles: In its first role, the ITS station is a network node and acts as a communication source or sink. Likewise an ITS station can be a forwarder of data, e.g. in the ITS ad hoc network. In its second role, the ITS station is placed at the network edge and connect the different networks via an ITS station internal network (see Figure 11).


50

Figure 11 : ITS Network architecture (general)

ITS stations shall be able to communicate via at least one of the following means (see Figure 11):

1. via an ITS ad hoc network; 2. via an ITS access network; 3. via a public access network; 4. via a private access network; 5. via one of the access networks into the core network (e.g. the Internet).

In addition to the networks listed above, an ITS station can also be attached to proprietary local networks of e.g. vehicle ITS sub‐systems and roadside ITS sub‐system as presented in [22]. Typical examples are:

a) Controller Area Network (CAN) in a vehicle ITS sub‐system. b) Legacy roadside infrastructure in a roadside ITS sub‐system.

According to ETSI TS 102 636‐3 [23] ITS standard, an ITS (Intelligent Transport System) Station is comprised out of two units (Figure 12):

• The Application Unit (AU) • The Computing and Communication Unit (CCU)

AU runs a single or a set of applications and utilizes the CCUʹs communication capabilities. In a possible implementation, the CCU executes the ITS access technology, ITS network & transport, and the ITS facilities layers, whereas the ITS application layer resides in the AU. The distinction between AU and OBU is logical; all layers can also be implemented in a single physical unit.


51

The CCU shall be equipped with at least a single ITS external communication interface to provide connectivity to the ITS ad hoc network or the different access networks (ITS access network, public access network, private access network). The CCU and the AU can be equipped with one or multiple ITS internal communication interfaces. Moreover, an AU can have an external communication interface for access to the proprietary local network. The ITS internal communication interface shall connect AUs with CCUs, AUs with other AUs, and CCUs with other CCUs via the ITS station‐internal network. AUs and CCUs can form a mobile network [24], where the AUs obtain connectivity to the networks via the external communication interface of the CCU. AU and CCU can reside in a single physical unit.

Figure 12 : ITS Station Architecture: Application Unit and Control and Communication Units in a single On Board Unit

Due to the different communication needs that a vehicular environment has, an ITS Station protocol stack has been proposed, based on the existing OSI protocol stack (Figure 13).

Figure 13 : General ITS Station protocol stack


52

ITS access technologies layer covers various communication media and related protocols for the physical and data link layers. The access technologies are not restricted to specific type of media, though most of the access technologies are based on wireless communication. The access technologies are used for communication inside of an ITS station (among its internal components) and for external communication (for example with other ITS stations). For external communication, some of the ITS access technologies represent complete, non‐ITS specific communication systems (such as GPRS, UMTS, WiMAX) that are regarded as ʹlogical links over which ITS data is transparently transported. The ITS network & transport layer comprises protocols for data delivery among ITS stations and from ITS stations to other network nodes, such as network nodes in the core network (e.g. the Internet). ITS network protocols particularly include the routing of data from source to destination through intermediate nodes and the efficient dissemination of data in geographical areas. ITS transport protocols provide the end‐to‐end delivery of data and, depending on requirements of ITS facilities and applications, additional services, such as reliable data transfer, flow control and congestion avoidance. A particular protocol in the ITS network & transport layer is the Internet protocol IP version 6 (IPv6). The usage of IPv6 includes the transmission of IPv6 packets over ITS network protocols, dynamic selection of ITS access technologies and handover between them, as well as interoperability issues of IPv6 and IPv4. The ITS facilities layer provides a collection of functions to support ITS applications. The facilities provide data structures to store, aggregate and maintain data of different type and source (such as from vehicle sensors and from data received by means of communication). As for communication, ITS facilities enable various types of addressing to applications, provide ITS‐specific message handling and support establishment and maintenance of communication sessions. An important facility is the management of services, including discovery and download of services as software modules and their management in the ITS station. The ITS applications layer refers to ITS applications and use cases for road safety, traffic efficiency, infotainment and business.

4.2.2 Facilities Layer protocols The protocols running on the facilities layer of an ITS station are based on the exchange of two types of messages:

• Cooperative Awareness Messages (CAM) • Decentralized Environment Notification Messages (DENM)

An overview of where these messages are applicable follows.

Cooperative Awareness Messages (CAM)

The Cooperative Awareness Messages (CAMs) are distributed within the ITS‐G5 (802.11p)


53

network and provide information of presence, positions as well as basic status of communicating ITS stations to neighbouring ITS stations that are located within a single hop distance. All ITS stations shall be able to generate, send and receive CAMs, as long as they participate in V2X networks. By receiving CAMs, the ITS station is aware of other stations in its neighbourhood area as well as their positions, movement, basic attributes and basic sensor information. At receiver side, reasonable efforts can be taken to evaluate the relevance of the messages and the information. This allows ITS stations to get information about its situation and act accordingly.

Information distributed by CAM Management is commonly used by related use cases and therefore the CAM Management is a mandatory facility. The Approaching Emergency Vehicle and Slow Vehicle Warning are just two use cases which benefit from CAM.

Decentralized Environment Notification Messages (DENM)

Decentralized Environmental Notification Messages (DENMs) are mainly used by the Cooperative Road Hazard Warning (RHW) application in order to alert road users of the detected events. The RHW application is an event‐based application composed of multiple use cases. The general processing procedure of a RHW use case is as follows:

• Upon detection of an event that corresponds to a RHW use case, the ITS station immediately broadcasts a DENM to other ITS stations located inside a geographical area and which are concerned by the event.

• The transmission of a DENM is repeated with a certain frequency. • This DENM broadcasting persists as long as the event is present. • The termination of the DENM broadcasting is either automatically achieved once the

event disappears after a predefined expiry time, or by an ITS station that generates a special DENM to inform that the event has disappeared.

• ITS stations, which receive the DENMs, process the information and decide to present appropriate warnings or information to users, as long as the information in the DENM is relevant for the ITS station.

4.2.3 Network and Transport Layer protocols The ITS network & transport layer comprises several network and transport protocols (Figure 14). In detail an ITS station can execute the following protocols at the ITS network & transport layer:

• GeoNetworking protocol. For usage of the GeoNetworking over different ITS access technologies, the specification of the protocol is split into a media‐independent part and a media‐dependent part (potentially multiple parts), such as for ITS‐G5 [20].

• Transport protocols over GeoNetworking, such as the Basic Transport Protocol and


54

other GeoNetworking transport protocols as they may be defined later. • Internet protocol IP version 6 [25] with IP mobility support [26] and optionally support

for network mobility • (NEMO) [27] or other approaches depending on the deployment scenario. • Internet protocol IP version 4 for transition to IPv6 [28]. • User Datagram Protocol UDP [25]. • Transmission Control Protocols TCP [26]. • Other network protocols. • Other transport protocols, such as SCTP.

Figure 14 : ITS Network and Transport Layer protocols

Assembly of network and transport protocols in the ITS station protocol stack

For protocol stacks involving the GeoNetworking protocol and IPv6, protocols shall be assembled in one of the following ways described.

For the GeoNetworking protocol, the underlying ITS access technologies are limited to short‐range wireless technologies, such as ITS‐G5.

GeoNetworking protocol stack

The GeoNetworking protocol stack may be assembled with the GeoNetworking protocol and ITS‐specific transport protocols as envisaged in TS 102 636‐5 [29] at the top of the GeoNetwork protocol as depicted in Figure 15.


55

Figure 15 : The GeoNetworking protocol stack

ITS IPv6 stack

The IPv6 stack may be assembled with the IPv6 protocol and related transport protocols UDP [30], TCP [31] and others as depicted in Figure 16.

Figure 16 : ITS IPv6 protocol stack

Combination of the GeoNetworking protocol and IPv6

This protocol stack combines the stacks in the previous clauses. In this protocol stack (Figure 17), IP shall run at the top of the GeoNetworking protocol or directly at the top of the ITS access technologies.


56

Figure 17 : ITS GeoNetworking with IPv6 support protocol stack

Protocol stacks for other network protocols

Further protocol stacks can be defined for other network protocols. In order to meet application and system requirements, the usage of other network protocols in parallel to the protocol stacks defined in the previous clauses can be restricted. For example, other network protocols must not be used at the top of ITS‐G5 operating in the ITS‐G5A frequency band.

4.2.4 Access Layer protocols Figure 10 shows the part of the ITS AL that is covered by the present document. It is based on the OSI layered communications model with a detailed view of the ITS Access Technology layer. The mapping between the ITS‐G5 elements specified in the present document and the ITS AL model is shown in Figure 18.

Figure 18 : ITS‐G5 Elements

The following elements of ITS‐G5 are defined:

• a physical layer,


57

• a medium access control sub‐layer, • a MAC sub‐layer Management Entity (MLME) • and a Physical Layer Management entity (PLME).

ITS‐G5 also includes the SAPs MAC_SAP and MLME_SAP (depicted in black in figure 10). The internal SAPs PHY_SAP and PMD_SAP (depicted in white in figure 10) are not part of ITS‐G5 specification, which implies that an ITS‐G5 STA may not implement these SAPs. However, a STA implementing these SAPs in compliance with 802.11 [32] is also considered compliant to ITS‐G5.

In Figure 10 the ITS‐G5 physical layer is composed of the two sub‐layers PLCP and PMD. The distinction of the two sub‐layers is only presented for homogeneity with [33]. In fact, ITS‐G5 only supports the OFDM PHY specification. Consequently, ITS‐G5 STAs may not have the two sub‐layers PLCP and PMD and, instead, may have one single physical layer.

As compared to [33], ITS‐G5 does not provide the SME‐PLME_SAP. Consequently, only the MLME can access the PHY MIB via the MLME‐PLME_SAP. The MLME‐PLME_SAP is therefore part of ITS‐G5.

Physical Layer Requirements

1. Frequency Allocation Table 6 shows the frequency ranges and related regulatory requirements and harmonized standards.

Table 6 : Frequencies and applications on ITS

Frequency Range Usage Regulation Harmonized Standard

5.905‐5.925 GHz Future ITS applications

ECC Decision [36]

5.875‐5.905 GHz ITS Road Safety ECC Decision [36], Commission Decision [37]

5.855‐5.875 GHz ITS non‐safety applications

ECC Recommendation [38]

ETSI EN 302 571 [34]

5.475‐5.725 GHz RLAN (BRAN, WLAN)

ERC Decision [39], Commission Decisions [40][41]

ETSI EN 301 893 [35]


58

Figure 19 illustrates the requirements for spectral power density in the 5 GHz range for the frequency bands listed in Table 6. It also shows the European bands for Dedicated Short Range Communication (DSRC) (Figure 20).

Figure 19: Requirements for spectral power density in the 5 GHz range for ITS stations

Figure 20 : Modulation scheme and data rates for ITS G5 applications

2. Transmit Power Control (TPC) TPC limits shall be as specified in [34] for ITS‐G5A and ITS‐G5B, and as specified in [35] for ITS‐G5C. Additional TPC requirements are provided by the DCC. These additional requirements for ITS‐G5A and ITS‐G5B are encompassed in [42].


59

Medium Access Control Sub‐layer

The medium access control sub‐layer of the ITS‐G5 shall be compliant with the profile of IEEE 802.11 [33]. A MAC frame shall consist of the following basic components:

• a MAC header (Figure 21); • a frame body of variable length; • and a frame check sequence (FCS).

Figure 13 shows the MAC header as specified in [33]:

Figure 21 : MAC header of IEEE 802.11

1. Quality of Service Since ITS‐G5 STAs always operate outside the context of a BSS, mechanisms such as Point Coordination Function (PCF) and hybrid coordination function (HCF) controlled channel access (HCCA) are not applicable. Enhanced Distributed Channel Access (EDCA) shall be applied. The set of EDCA parameters as specified in Figure 22 must not be negotiated over the air link, but shall be statically set.

Figure 22 : EDCA parameters for Contention Window in IEEE 802.11

2. Dynamic Frequency Selection (DFS) Dynamic frequency selection (DFS) is required for communications in the RLAN band [35] and [41]. Only a DFS master/slave mode of operation shall be supported. A fixed ITS‐G5 STA operating as a service provider shall provide the DFS master functionality. Mobile ITS‐G5 STAs operating as a service client shall provide the DFS slave function functionality. The frequency band inside ITS‐G5C actually to be used as the G5SC shall be announced in the service advertisement frame broadcasted in the G5CC.


60

4.2.5 GeoNetworking Implementation In this report, we start from scratch and build an implementation of the ETSI TS 102 636‐4‐1 standard, where the GeoNetworking protocol is defined. Along with GeoNetworking, Basic Transport protocol A and B (BTP‐A, BTP‐B) are implemented as a transport layer protocol.

The goals for this implementation is the ability to interact with a higher facility layer, able to generate either CAM or DENM messages, that then are encapsulated in proper GeoNetworking packets and passed to a lower layer through a defined Application Interface (API).

This implementation is developed as a user space daemon process, which is able to communicate with already existing applications developed by Delphi Co., simulating a facilities layer or a lower layer. Initially, for testing purposes only the applications of Delphi were used, but then we moved to new lightweight implementations of the facilities and management layer, able to allow for proper protocol operation.

In the following section, the protocol operation is described, how addressing is defined and the type of messages supported.

GeoNetworking Addressing

Every GeoAdhoc router shall have a unique GeoNetworking address. This address shall be used in the header of a GeoNetworking packet and identify the communicating GeoNetworking entities. The format of the GeoNetworking address is described in Figure 23:

Figure 23 : GeoNetworking Address format

The fields of the GeoNetworking address shall be configured according to Figure 24:


61

Figure 24 : Configuration parameters of the GN address

The first bit is reserved for the recognition of manual configured GeoNetworking addresses. The allocation of ITS Station Country Codes (SCC) is administered by the ITU‐T. The MID field corresponds to the access layer address. In case of IEEE 802.11p MAC layer, the 48‐bit MAC layer address shall be used.

GeoNetworking Long Position Vectors (LPVs)

The LPVs are used complementary to the GeoNetworking address, and are used in the messages sent out of a single GeoNetworking station. They contain geographical information of a GeoNetworking Station. Their format is described in Figure 25 and Figure 26:

Figure 25 : LPV format


62


63

Figure 26 : Configguration Parameters of LPV

Similar to LPVs are the Short Position Vectors (SPVs) that are used in some specific packet exchanges. SPVs have the following format (Figure 27):

Figure 27 : SPV format

GeoNetworking Location Table

Similar to other routing protocols, that have a routing table, the GeoNetworking implementation should hold a location table that will contain information about each ITS STA that participates in a message exchange. The location table should contain a flag of whether another ITS STA is a neighbor or not, and the pending operations to a specific station (such as if the location service is invoked).

The location table is used for taking all the forwarding decisions, so it should be as more precise as possible. The minimum location table elements, as defined by ETSI TS 102 636‐4‐1 are the following:

• GeoNetwork address of the ITS station GN_ADDR. • LL address of the ITS station LL_ADDR.


64

• Type of the ITS station (vehicle ITS station, roadside ITS station). • Position vector, i.e. Long Position Vector of the ITS station, comprised of:

o Geographical position POS(GN_ADDR). o Speed S(GN_ADDR). o Heading H(GN_ADDR). o Timestamp of the geographical position TST(POS, GN_ADDR). o Accuracy of the geographical position Acc(POS, GN_ADDR). o Accuracy of the speed Acc(S, GN_ADDR). o Accuracy of the heading Acc(H, GN_ADDR).

• Flag LS_PENDING(GN_ADDR): Flag indicating that a Location Service (LS) (clause 9.2.4) is in progress.

• Flag IS_NEIGHBOUR(GN_ADDR): Flag indicating that the GeoAdhoc router is in direct communication range, i.e. is a neighbour.

• Sequence number SN(GN_ADDR): The sequence number of the last packet from the source GN_ADDR that was identified as ʹnot duplicatedʹ.

4.2.6 GeoNetworking Packets The packet structure of GeoNetworking protocol messages shall follow the format depicted in Figure 28:

Figure 28 : GN packet structure

The GeoNetworking packets are encapsulated from the MAC layer protocol, according to what protocol has been adopted at the network access layer. Every GeoNetworking packet has a common header (which is the same for all the types of GN packets) and a packet specific extended header. The packet’s common header is depicted in Figure 29:


65

Figure 29 : Common Header Format

The common header consists of the following fields (Figure 30):


66

Figure 30 : Configuration Parameters for Common Header

The different packet types supported by the protocol are the following:

• Beacons • Single Hop Broadcast packets (SHB) • Topologically scoped Broadcast packets (TSB) • GeoBroadcast packets • GeoAnycast packets • GeoUnicast packets


67

• Location Service Packets

Each one of the aforementioned packets, the packet structure and every operation is described in the following session:

Beacons

A beacon packet is consists of only the common header part of a packet. It is sent by any ITS STA to advertise its position at certain time intervals, if no other packet transmission has happened in this interval.

Single Hop Broadcast packets

SHB packets are broadcasted in all ITS stations within a 1‐hop distance. They are used to encapsulate packets received from upper layers if indicated so by the “next header” field. Usually, they are used to encapsulate CAM messages.

Topologically Scoped Broadcast packets

TSB packets are packets broadcasted within a distance indicated by a hop limit. Due to multiple retransmissions of a packet by several ITS stations in the same geographical area, a duplicate packet detection mechanism should exist.

The extended packet header should contain the following fields, as indicated by Figure 31 and Figure 32:

Figure 31 : TSB packet header


68

Figure 32 : TSB Extended Header configuration parameters

GeoBroadcast/GeoAnycast packets

Geobroadcast/GeoAnycast packets perform the operation of broadcasting/anycasting (as anycast is defined in IPv6) in a specific geographical area. The definition of a geographical area is described in the next sections.

The GeoBroadcast and GeoAnycast packets shall have the same header structure. They are distinguished by the HT field in the Common Header. The header shall be comprised of the Common Header and the Extended Header as shown in Figure 33.

Figure 33 : GeoBroadcast/GeoAnycast packet header

The fields should carry the information indicated by Figure 34:


69

Figure 34 : GeoBroadcast/GeoAnycast Extended Header configuration parameters

As one can easily see, a geographical area is defined using three fields; distance a, distance b and angle. Specifically in the case of a circular area, a is the radius distance of the area, b is set to zero, and angle is set to zero.

GeoUnicast packets

GeoUnicast packets are used for unicast transmission to an ITS STA which we know the geographical characteristics of it. GeoUnicast header is defined as follows (Figure 35):

Figure 35 : GeoUnicast packet header


70

GeoUnicast extended header fields should be filled according to Figure 36:

Figure 36 : GeoUnicast Extended Header configuration parameters

Location Service

The location service is used if a GeoAdhoc router needs to determine the position of another GeoAdhoc router. This is the case if a GeoAdhoc router is in the process to send a T/GN6‐SDU as a GeoUnicast packet to another GeoAdhoc router, i.e. from the source to the destination, and does not have the position information for the destination in its LocT. The execution of a location service is fully transparent to protocol entities of higher layers. The location service function resides on top of the forwarding functions and can therefore use any forwarding type. The location service is based on the exchange of control packets between GeoAdhoc routers. The querying GeoAdhoc router (source) issues a LS Request packet with the GN_ADDR of the sought GeoAdhoc router (destination). The LS Request packet is forwarded by intermediate GeoAdhoc routers (forwarders) until it reaches the destination. The destination replies with a LS Reply packet. The procedure is illustrated in Figure 37.


71

Figure 37 : Location Service example

The fields of the Common Header in the case of a Location Service message are defined in Figure 38:

Figure 38 : Common Header Location Service parameters


72

4.2.7 Defining a Geographical area The definition of a geographical area is done in the standard ETSI EN 302 931. Geographical areas shall be specified by geometric shapes. The following geographical areas are defined:

• circular area; • rectangular area; and • elliptical area

Circular Area

The circular area shall be described by a circular shape with a single point A that represents the center of the circle and a radius r as shown in Figure 39.

Figure 39 : Definition of a Circular Area

Rectangular Area

The rectangular area shall be defined by a rectangular shape (Figure 40) with point A that represents the center of the rectangle and the following parameters:

• a ‐ the distance between the center point and the short side of the rectangle (perpendicular bisector of the short side);

• b ‐ the distance between the center point and the long side of the rectangle (perpendicular bisector of the long side);

• θ ‐ azimuth angle of the long side of the rectangle.


73

Figure 40 : Definition of a Rectangular Area

Elliptical Area

The elliptical area shall be defined by an elliptical shape (Figure 41) with point A that represents the center of the ellipse and the following parameters:

• a ‐ the length of the long semi‐axis; • b ‐ the length of the short semi‐axis; • θ ‐ azimuth angle of the long semi‐axis.

Figure 41 : Definition of an Elliptical Area

Geometric Function to determine spatial characteristics of a point

A function F that an ITS station can use to determine whether a point P(x,y) is located inside, outside, at the centre, or at the border of a geographical area should have the following properties:


74

Function F(x,y) is depedent of the type of area defined. Therefore for each one of the available areas, we define the following functions:

1. For a circular area:

2. For a rectangular area:

3. For an elliptical area:


75

4.2.8 Communication with upper layer As we can deduce from Figure 42, the communication between different layer entities is done via Service Access Points (SAP). The functions defined by the GN SAP are the GN‐Data.request, the GN‐Data.confirm and the GN‐Data.indication messages.

Figure 42 : The GeoNetworking SAPs

The GN‐DATA.request primitive is used by the ITS transport protocol entity to request sending a GeoNetworking packet. Upon reception of the GN‐DATA.request primitive, the GeoNetworking protocol delivers the GeoNetworking packet to the LLC protocol entity via the IN_SAP.

The parameters of the GN‐DATA.request are as follows:

GN‐DATA.request ( Upper protocol entity,


76

Packet transport type, Destination, Communication profile, Maximum packet lifetime, (optional) Repetition interval, (optional) Traffic class, Length, Data )

The Upper protocol entity parameter specifies whether the primitive was triggered by an ITS Transport protocol (e.g. BTP) or by the GeoNetworking to IPv6 Adaptation Sub‐Layer (GN6ASL).

The Packet transport type parameter specifies the packet transport type (GeoUnicast, SHB, TSB, GeoBroadcast, GeoAnycast).

The Destination parameter specifies the destination address for GeoUnicast or the geographical area for GeoBroadcast/GeoAnycast. The destination address for GeoUnicast can optionally contain the MID field only; with the other fields set to 0.

The Communication profile parameter determines the LL protocol entity (unspecified, ITS‐G5A). The Maximum lifetime parameter specifies the maximum tolerable time in [s] a GeoNetworking packet can be buffered until it reaches its destination. The parameter is optional. If it is not used, the MIB attribute itsGnMaxPacketLifetime is used.

The Repetition interval parameter specifies the duration between two consecutive transmissions of the same GeoNetworking packet during the lifetime of a packet in [ms]. The parameter is optional. If it is not used, the packet should not be repeated.

The Traffic class parameter specifies the traffic class for the message as a triple of Relevance, Reliability, and Latency. The Length parameter indicates the length of the Data parameter. The Data parameter represents the payload of the GeoNetworking packet to be sent, i.e. the T‐SDU/GN6‐SDU.

The GN‐DATA.confirm primitive is used to confirm that the GeoNetworking packet was successfully processed in response to a GN‐DATA.request. For the reception of the primitive, no behaviour is specified.

The parameters of the primitive are as follows:


77

GN‐DATA.confirm ( ResultCode )

The ResultCode parameter specifies whether the GN‐DATA.request primitive:

• has been accepted; • rejected due to maximum length exceeded if the size of the T/GN6‐PDU exceeds the MIB

attribute itsGnMaxSduSize; • reject due to maximum lifetime exceeded if the lifetime exceeds the maximum value of

the MIB attribute itsGnMaxPacketLifetime; • reject due to repetition interval too small, if the repetition interval is smaller than the

MIB attribute itsGnMinPacketRepetitionInterval; • rejected due to unsupported traffic class; or • rejected for unspecified reasons if the GN‐DATA.request primitive cannot accepted for

any other reason.

The GN‐DATA.indication primitive indicates to an upper protocol entity that a GeoNetworking packet has been received. The primitive is generated by the GeoNetworking protocol to deliver data contained in a received GeoNetworking packet to upper protocol entity. The data of the GeoNetworking packet are processed as determined by the receiving upper protocol entity.

The parameters of the GN‐DATA.indication primitive are as follows:

GN‐DATA.indication (

Upper protocol entity, Packet transport type, Destination Source position vector, Traffic class, Remaining packet lifetime (optional), Length, Data ‐‐ T/GN6‐PDU )

The Upper protocol entity parameter determines the protocol entity that processes the service primitive (BTP or GN6). The Packet transport type parameter is the packet transport type (GeoUnicast, SHB, TSB, GeoBroadcast, GeoAnycast) of the received packet.

The Destination parameter is the destination address for GeoUnicast or the geographical area


78

for GeoBroadcast/GeoAnycast, with which the GeoNetworking packet was generated by the source. The Source position vector parameter is the geographical position for the source of the received GeoNetworking packet. The Remaining packet lifetime parameter is the remaining lifetime of the packet. The Traffic Class parameter is the traffic class, with which the GeoNetworking packet was generated by the source. The Length parameter is the length of the Data parameter. The Data parameter is the payload of the received GeoNetworking packet, i.e. the T‐PDU/GN6‐PDU.

4.2.9 Communication with the management layer Communication with the management layer is done via the GN_MGMT_SAP. The messages exchanged are the GN‐MGMT.request and the GN‐MGMT.response.

The GN‐MGMT.request primitive is generated by the GeoNetworking protocol entity at the initialization phase in order to request management information, i.e. time, position vector, GeoNetworking address. After receiving the GN‐MGMT.request primitive, the ITS Network and Transport Layer Management entity is in charge of providing the GeoNetworking entity with the requested management information.

The parameters of the GN‐MGMT.request are as follows:

GN‐MGMT.request ( Request cause )

The Request cause parameter specifies the type of requested information, i.e. time, position vector, GeoNetworking address. In case the GeoNetworking address is requested, the parameter also indicates whether the address request is caused by duplicate address detection or is an initial request.

The GN‐MGMT.response primitive is generated by the ITS Network and Transport Layer Management entity to indicate an update of management information, i.e. time, position vector and GeoNetworking address. The primitive can be triggered upon reception of a GN‐MGMT.request primitive or can be generated unsolicited, i.e. without a GN‐MGMT.request primitive.

The parameters of the GN‐MGMT.response are as follows: GN‐MGMT.response ( Time (optional) Local position vector (optional) GeoNetworking address (optional)


79

)

The Time parameter specifies the timestamp that is used as a reference to determine the freshness of received information carried in packets. The Local position vector parameter specifies the ITS stationʹs most recent position vector (geographical position, speed, heading, timestamp when the position vector was generated, and corresponding accuracy information).

The GeoNetworking address parameter specifies the GeoNetworking address that shall be used by the GeoNetworking protocol entity. All parameters are optional, whereas at least one parameter should be present.

4.2.10 Other Implementation Details

Daemon Implementation details

For this thesis, we developed a user space daemon that provides full GeoNetworking capabilities to an ITS STA, by using its API. The architecture and the communication APIs that the GeoNetworking daemon has are depicted in Figure 43.

Figure 43 : GeoNetworking implementation architecture

The communication through the GNBTP‐API and the GN‐MGMT API are done using UDP sockets. As a communication scheme with the Link Layer, we used the pcap library.

1. Pcap Library The pcap library provides a high level interface to the programmer, to access several features of a network interface. These could be from directly cloning a stream on the card to an application, to directly injecting traffic over a networking interface.


80

Therefore, for the proper operation of the GeoNetworking daemon, we needed to make calls to the pcap library, once we build the GN packet, one for injecting the created packet on the network interface and one thread listening for incoming packets marked as GeoNetworking.

2. Target Platform The target platform for the evaluation of the system is DELPHI’s embedded ITS CCU unit which is depicted in Figure 44.

Figure 44 : DELPHIʹs OBU

It features an Intel Atom processor at 1GHz and 1 GB of RAM memory. It has integrated GPS receiver and a 2 GB SSD. It has an option of adding LTE communication interfaces on top of it. The operating system that it runs is a customized by Delphi Linux Operating System.

As a communication interface with other CCU’s it features an Atheros based WiFi card, supporting the IEEE 802.11p protocol. The frequency it is transmitting is at 5.9 GHz WAVE band with a channel bandwidth of 10MHz.

Management and POTI

For testing purposes, we used DELPHI’s implementation of a facilities and management layer. The implementation was in java, using the OSGi [43] framework. Since this implementation is under the copyright law, only a binary form was given of it. Howerver, the high processing and memory requirements that are needed to run it rendered it impossible to run on DELPHI’s


81

MyCCU.

Therefore, we developed lightweight versions of the facilities and management layer, written in C, which are able to provide basic support for some operations of these layers, and are able to operate on Delphi’s CCUs. The operations supported so far are:

• Generation of CAM messages, that are send via the GNBTP‐API to GeoNetworking layer via a GN‐Data.request format

• Reception of CAM messages, received from the GNBTP‐API in a GN‐Data.indication format

• Generation of time and position update messages send via the GN‐MGMT API as time and position update messages

• Generation of Address update messages sent to GN via the GN‐MGMT API.

These operations run as two separate application daemons, able to give full GeoNetworking capabilities to an ITS STA.

Specifically, the position and time update module (POTI) is using another interface to communicate with the gpsd service, that is serving position updates in a JSON format. These are translated properly to GN compatible messages for proper handling on the GeoNetworking side.

1. GPSD and gps.h library GPSD is a daemon that receives data from a GPS receiver, and provides the data back to multiple applications. It thus provides a unified interface to receivers of different types, and allows concurrent access by multiple applications.

GPSD provides a TCP/IP service by binding to port 2947. It accepts commands from that socket, and returns results back to it. These commands use a JSON‐based syntax and return JSON responses (older, now obsolete versions used single‐letter commands). Concurrent operation is supported. Most GPS receivers are supported, whether serial, USB, or Bluetooth. Additionally gpsd supports interfacing with the UNIX network time protocol daemon ntpd via shared memory to enable setting the host platformʹs time via the GPS clock.

The corresponding UNIX gps.h library provides an interface to the programmer to interact with the gpsd daemon and send or receive data to its listening socket. By sending a WATCH message, a JSON file is returned by gpsd containing current GPS data.


82

Logging Functions

For proper debugging of the protocol’s operation, we have implemented logging mechanisms at the different levels that the developed software operates. Logging support is provided not only for the Geonetworking layer, but for the management and the facilities layer as well. Each time a position update is sent (defined by a MIB value), it is logged by the logging thread running at this layer. Similar process is happening at the facilities layer, whenever a packet is sent to or received from the GeoNetworking layer.

For the implementation of the logging process, we engaged C++ file streams library. Log files are renewed in a circular way, and every time a timer expires (originally set to a daylong duration), the log files are archived. The compression of the files is happening using a system call to the `tar` and `gunzip` UNIX commands. For the compression of the files, we could have engaged the `zlib` library and actually implement the compression process using our own code. Since the logging archiving is done only once per day, we used the system calls solution, which can ensure interoperability among different UNIX based systems. Implementation of compression functions using the `zlib` library is one of our future goals.

Duplicate packet detection

As it is expected from the protocol’s operation, several of the packets are retransmitted over the network more than once, depending on the number of ITS Stations in a geographical area. Therefore, proper handling of duplicate packets shall be implemented.

The GeoNetworking protocol applies duplicate packet detection to multi‐hop packets (GeoUnicast, TSB, GeoBroadcast, GeoAnycast, LS Request, LS Reply). The mechanism is based on sequence numbers and implies that every GeoNetworking packet carries a sequence number in its header. For duplicate packet detection, a GeoAdhoc router maintains the sequence number of the last packet from the source that was identified as ʹnot duplicatedʹ in its LocT, i.e. SNGN_ADDR. When the GeoAdhoc router processes a GeoNetworking packet, it compares the value of the SN field carried in the GeoNetworking packet SN(P) and SNSO,SAV. If SN(P) is greater than SNGN_ADDR the received packet is regarded as ʹnot duplicatedʹ and SNSO,SAV is updated. The sequence numbers in the GeoNetworking protocol are limited in the number of bits that represent the sequence number. In order to handle the wrap‐around of sequence numbers (that the sequence number is incremented from the maximum possible value to zero), the following algorithm shall be used:


83

GeoNetworking Management Information Base (MIB)

In the protocol’s specification, a Management Information Base (MIB) is defined, with values that define its operation. However, in order to avoid adding more complexity to the developed daemon, we created a sample configuration file which is parsed at the beginning of execution of the daemon. This file is used to initialize a class that contains all the MIB values used by the protocol. The sample configuration file that is read by the GeoNetworking daemon and the MIB values stored are depicted in the following codebox and Table 7.


84

#################################################

# #

# GeoNetworking Daemon Configuration File #

# Proposal for Discussion #

# Version: 0.0.1 #

# #

#################################################

# $Rev: 0001 $

########## <Configuration Table>

# (1) Log Functionality

# (2) Device Confiuration

# (3) Data Communication API Settings

# (4) ITS Station Settings

# (5) Default Local Position Vector Settings

# (6) Protocol Configuration

# (7) Default Transmission Parameters

# (8) Testing Configuration

##########

## (1) Log Functionality

# File path

GN_SYSLOG_FILENM gn_sys_log

GN_USRLOG_FILENM gn_usr_log

## Log level

GN_SYSLOG_LV 3 # System log level (0-3)

GN_USRLOG_LV 2 # User log level (0-3)

# Log rotation parameters

GN_LOG_MAX_NLINES 50000 # Maximum # of lines by file (rotate mode = 1)

GN_LOG_MAX_SIZE 4000000 # Maximum size by file (rotate mode = 2)

GN_LOG_N_ROTATE 2 # Number of log rotate files (>= 2)

## (2) Device Confioguration

AL_CCH_IF eth0 # Interface name used for CCH

AL_SCH_IF eth0 # Interface name used for SCH

## (3) Data Communication API Settings

# Listen port for communication with Facility

GN_NWT_LISTEN_PORT 1301

# Destination Port for communication with Facility

GN_FAC_DEST_ADDR 127.0.0.1

GN_FAC_DEST_PORT 1302


85

# Listen port for communication with Management

GN_MNGT_LISTEN_PORT 1401

# Destination Port for communication with Management

GN_MNGT_DEST_ADDR 127.0.0.1

GN_MNGT_DEST_PORT 1402

## (4) Node Settings Configuration

# ITS Station Type

# (bike, motorbike, car, truck, bus, trafficlight, rsu)

GN_ITSST_TYPE rsu

# ITS Station SubType

# (public, private)

GN_ITSST_SUBTYPE private

# Address Configuration Mode (MIB.itsGnLocalAddrConfMethod)

# (auto, managed, manual)

GN_ADDRCONF_MODE auto

# MID of Geonetworking address (only if GN_ADDRCONF_MODE = manual)

# Format: XX:XX:XX:XX:XX:XX (X is hexdecimal character)

GN_ADDR_MID 00:00:00:00:00:00

## (5) Default LPV Settings

GN_DEF_LAT 40.4

GN_DEF_LON 10.2

GN_DEF_SPEED 10

GN_DEF_HEADING 0

GN_DEF_ALT 20

## (6) Protocol Configuration

# Algorithm Type Settings

# GeoUnicast Algorithm Type (MIB.itsGnGeoUnicastForwardingAlgorithm)

# (0: Unspecified, 1: Greedy, 2: ETSI-CBF, 3: Revised-CBF)

GN_UCALG_TYPE 0

# GeoBroadcast Algorithm Type (MIB.itsGnGeoBroadcastForwardingAlgorithm)

# (0: Unspecified, 1: Simple, 2: Advanced(not available now))

GN_BCALG_TYPE 0

# Default Hop Limit (0-255) (MIB.itsGnDefaultHopLimit)

GN_HOP_LIMIT 10

# Upper Limit of Packet Lifetime (1-6300000) [ms] (MIB.itsGnMaxPacketLifetime)

GN_MAX_PCKT_LIFETM 600000

# Lower Limit of the Packet Repetition Interval [ms] (MIB.itsGnMinPacketRepetitionInterval)

GN_MIN_PCKT_REPINT 100


86

Table 7 : MIB values and their initial configuration

MIB attribute value Default/Initial value Comment itsGnLocalGnAddr 1 GeoNetworking address of the

GeoAdhoc router itsGnLocalAddrConfMethod

AUTO (0) MANAGED (1)

AUTO: Local GN_ADDR is configured from MIB MANAGED: Local GN_ADDR is configured via the GN‐MGMTt primitive (annex I)

itsGnProtocolVersion TS 102 636‐4‐1 (V1.1.1) (0) Version of the GeoNetworking protocol set in the GeoNetworking protocol headers

itsGnStationType Vehicle ITS Station (0) Roadside ITS Station (1)

Type of ITS Station

itsGnMinimumUpdateFrequencyLPV

Vehicle ITS Station (1 000) Roadside ITS Station (0)

Minimum update frequency of local position vector (LPV) in ms

itsGnMaxSduSize 1 398 Maximum size of GN‐SDU [bytes] 1 500‐ GN_MAX (88) ‐ GNSEC_MAX (0)

itsGnMaxGeoNetworkingHeaderSize

88 GN_MAX: Maximum size of GeoNetworking header [bytes] Determined by the GeoUnicast header as defined in clause 8.6.2

itsGnLifetimeLocTE 20 Lifetime of location table entry [s]

## (8) Testing Configuration

### Radio Range Emulation

# Whether emulation functionality is enabled or not

# 0: Disabled, 1: Enabled

GN_RADIO_EMU_MODE 0

# Emulated radio range [m]

GN_RADIO_EMU_RANGE 300


87

itsGnLocationServiceMaxRetrans

10 Maximum number of retransmissions of LS Request packets

itsGnLocationServiceRetransmitTimer

1 000 Duration of Location service retransmit timer [ms]

itsGnLocationServicePacketBufferSize

1 024 Size of Location service packet buffer [Byte]

itsGnBeaconServiceRetransmitTimer

3 000 Duration of Beacon service retransmit timer [ms]

itsGnBeaconServiceMaxJitter

itsGnMaxPacketLifetime/4 Maximum beacon jitter [ms]

itsGnDefaultHopLimit 10 Default hop limit indicating the maximum number of hops a packet travels

itsGnMaxPacketLifetime 600 Upper limit of the maximum lifetime [s]

itsGnMinPacketRepetitionInterval

100 Lower limit of the packet repetition interval [ms]

itsGnGeoUnicastForwardingAlgorithm

UNSPECIFIED (0) GREEDY (1) CBF (2)

Default GeoUnicast forwarding algorithm

itsGnGeoBroadcastForwardingAlgorithm

UNSPECIFIED (0) SIMPLE (1)

Default GeoBroadcast forwarding algorithm

itsGnGeoUnicastCbfMinTime

1 Minimum duration a packet shall be buffered in the CBF packet buffer [ms]

itsGnGeoUnicastCbfMaxTime

100 Maximum duration a packet shall be buffered in the CBF packet buffer [ms]

itsGnDefaultMaxCommunicationRange

1 000 Default theoretical maximum communication range [m]

itsGnGeoAreaLineForwarding

DISABLED (0) ENABLED (1)

Forwarding of GeoBroadcast/GeoAnycast packet if GeoAdhoc router is located outside the GeoArea.

itsGnUcForwardingPacketBufferSize

256 Size of UC forwarding packet buffer [Kbytes].

itsGnBcForwardingPacketBufferSize

1 024 Size of BC forwarding packet buffer [Kbytes].

itsGnCbfPacketBufferSize

256 Size of CBF packet buffer [Kbytes]


88

itsGnTrafficClassRelevance

3 Forwarding: Default traffic class Relevance

itsGnTrafficClassReliability

Medium (10) Forwarding: Default traffic class Reliability

itsGnTrafficClassLatency

Medium (10) Forwarding: Default traffic class Latency

GeoNetworking Operation

The ETSI TS 102 636‐4‐1 standard, defines different operation of the protocol depending on the packet type sent, and whether the GeoNetworking STA is the transmitter, the forwarder or the receiver of the packet.

1. Transmission of packets In the case of receiving a GN‐Data.indication from an upper layer, the GeoNetworking daemon checks the type of the packet that shall be transmitted and performs some packet type specific actions that are defined in the following sections:

2. Single Hop Broadcast On reception of a GN‐DATA.request primitive with a Packet transport type parameter set to SHB (Figure 45), the source shall execute the following operations:

1) create a GN‐PDU with the T/GN6‐SDU as payload and a SHB packet header: a) set the fields of the Common Header (clause 9.3.2);

2) if no neighbour exists, i.e. the LocT does not contain a LocTE with the IS_NEIGHBOUR flag set to TRUE, then buffer the SHB packet in the BC forwarding packet buffer and omit the execution of further steps;

3) if the optional Repetition interval parameter in the GN‐DATA.request parameter is set: a) save the SHB packet; b) retransmit the packet with period as specified in Repetition interval until the

maximum lifetime of the packet is expired; 4) execute media‐dependent procedures: if the Communication profile parameter of the

GN‐DATA.request primitive is set to: a) UNSPECIFIED then omit this operation; b) is set to ITS‐G5A then execute the operations as specified;

5) pass the GN‐PDU to the LL protocol entity via the IN interface and set the destination address to the Broadcast address of the LL entity.


89

Figure 45: SHB transmission flowchart

2.1. Topologically Scoped Broadcast

On reception of a GN‐DATA.request primitive with a Packet transport type parameter set to


90

TSB (Figure 46), the source shall execute the following operations:

1) create a GN‐PDU with the T/GN6‐SDU as payload and a TSB packet header: a) set the fields of the Common Header b) set the fields of the TSB Extended Header

2) if no neighbour exists, i.e. the LocT does not contain a LocTE with the IS_NEIGHBOUR flag set to TRUE, then buffer the TSB packet in the BC forwarding packet buffer and omit the execution of further steps;

3) if the optional Repetition interval parameter in the GN‐DATA.request parameter is set: a) save the TSB packet b) retransmit the packet with period as specified in Repetition interval until the

maximum lifetime of the packet is expired; 4) execute media‐dependent procedures: if the Communication profile parameter of the

GN‐DATA.request primitive is set to: a) then omit this operation; b) is set to ITS‐G5A then execute the operations as specified



91

Figure 46 : TSB transmission flowchart

2.2. GeoBroadcast

On reception of a GN‐DATA.request primitive with a Packet transport type parameter set to GeoBroadcast (Figure 47), the source shall execute the following operations:


92

1) create a GN‐PDU with the T/GN6‐SDU as payload and a GeoBroadcast packet header: a) set the fields of the Common Header b) set the fields of the GeoBroadcast Extended Header

2) if no neighbour exists, i.e. the LocT does not contain a LocTE with the IS_NEIGHBOUR flag set to TRUE, then buffer the GeoBroadcast packet in the BC forwarding packet buffer and omit the execution of further steps;

3) if the optional Repetition interval parameter in the GN‐DATA.request parameter is set: a) save the GeoBroadcast packet b) retransmit the packet with period as specified in Repetition interval until the

maximum lifetime of the packet is expired 4) determine the link‐layer address LL_ADDR_NH of the next hop

a) if the MIB attribute itsGnGeoBroadcastForwardingAlgorithm is set to 0 (UNSPECIFIED), execute the Simple GeoBroadcast with line forwarding algorithm

b) if the MIB attribute itsGnGeoBroadcastForwardingAlgorithm is set to 1 (SIMPLE), execute the Simple GeoBroadcast with line forwarding algorithm

5) if LL_ADDR_NH = 0, then buffer the GeoBroadcast packet in the BC forwarding packet buffer and omit the execution of further steps;

6) execute media‐dependent procedures: if the Communication profile parameter of the GN‐DATA.request primitive is set to:

a) UNSPECIFIED then omit this operation b) is set to ITS‐G5A then execute the operations

7) pass the GN‐PDU to the LL protocol entity via the IN interface and set the destination address to the LL address of the next hop LL_ADDR_NH.


93

Figure 47 : GeoBroadcasst transmission flowchart

2.3. GeoAnycast

The operations (Figure 48) of the source of a GeoAnycast packet are identical with the source of a GeoBroadcast packet, except the operation in step 5. Instead, the source shall execute the following operation:

1) determine function F(x,y) a) if F (x, y) < 0 (GeoAdhoc router is outside the geographical area) and the MIB

attribute itsGnGeoAreaLineForwarding is set to TRUE, execute the GeoUnicast forwarding algorithm and determine the link‐layer address LL_ADDR_NH of the next hop.


94

b) if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to 0 (UNSPECIFIED), execute the GF algorithm

c) if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to 1 (GREEDY), execute the GF algorithm

d) if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to 2 (CBF), execute the CBF algorithm

Figure 48 : GeoAnycast transmission flowchart

2.4. GeoUnicast

On reception of a GN‐DATA.request primitive with a Packet transport type parameter set to


95

GeoUnicast (Figure 49), the source shall execute the following operations:

1) check whether it has a valid position vector for DE in its LocT: a) If no valid position vector information is available, the source shall invoke the

location service and omit the execution of further steps. Otherwise, the source shall proceed with step 2;

2) determine the link‐layer address LL_ADDR_NH of the next hop: a) if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to 0

(UNSPECIFIED), execute the GF algorithm b) if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to 1 (GREEDY),

execute the GF algorithm. c) if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to 2 (CBF), execute

the CBF algorithm. 3) create a GN‐PDU with the T/GN6‐SDU as payload and a GeoUnicast packet header:

a) set the fields of the Common Header. b) set the fields of the GeoUnicast Extended Header

4) if LL_ADDR_NH = 0, then buffer the GeoUnicast packet in the UC forwarding packet buffer and omit the execution of further steps;

5) if the optional Repetition interval parameter in the GN‐DATA.request parameter is set: a) save the GeoUnicast packet; b) retransmit the packet with period as specified in Repetition interval until the

maximum lifetime of the packet is expired; 6) execute media‐dependent procedures: if the Communication profile parameter of the GN‐

DATA.request primitive is set to: a) UNSPECIFIED then omit this operation b) ITS‐G5A then execute the operations.



96

Figure 49 : GeoUnicast transmission flowchart

3. Reception/Forwarding of packets Upon reception of a GeoNetworking packet, the GeoAdhoc STA should decide whether it is the intended recipient of the packet, or will act as a forwarder. Therefore, some common actions are defined for all types of packets, including duplicate packet detection, processing of the GeoNetworking Common Header, flushing buffers and checking if Location Service is pending for the sender GeoNetworking STA. In the following flowchart (Figure 50), the common actions applied upon reception of a GeoNetworking packet are shown:


97

Figure 50 : Common actions upon reception of GN packets


98

3.1. Single Hop Broadcast / Topologically Scoped Broadcast

SHB packets should not be retransmitted. Therefore, upon reception of an SHB packet, the GeoAdhoc router shall execute the following operations:

1) Common Header processing 2) pass the payload of the GN‐PDU to the upper protocol entity by means of a GN‐

DATA.indication primitive.

In the case of reception of a TSB packet, the GeoAdhoc router shall execute the following operations (Figure 51):

1) Common Header processing 2) execute duplicate packet detection. If the TSB packet is a duplicate, discard the packet and

omit the execution of further steps; 3) update the PV(SO) in the LocT with the SO PV fields of the TSB Extended Header. 4) set the IS_NEIGHBOUR(SO) flag to FALSE if SO GN_ADDR does not equal SE GN_ADDR; 5) pass the payload of the GN‐PDU to the upper protocol entity by means of a GN‐

DATA.indication primitive. 6) decrement the value of the HL field by one. If HL is decremented to zero, discard the GN‐

PDU and omit the execution of following operations: 7) update the fields of the Common Header, i.e.:

a) the HL field with the decremented HL value. b) the SE PV fields with the LPV.

8) execute media‐dependent procedures: if the Communication profile parameter of the GN‐DATA.request primitive is set to: a) UNSPECIFIED then omit this operation. b) ITS‐G5A then execute the operations.


Figure 51 : TSB/SHB packet reception flowchart

3.2. GeoBroadcast/GeoAnycast

On reception of a GeoBroadcast packet, the GeoAdhoc router shall execute the following


99

operations (Figure 52):

1) Common Header processing. 2) execute duplicate packet detection. If the GeoBroadcast packet is a duplicate, discard the

packet and omit the execution of further steps. 3) update the PV(SO) in the LocT with the SO PV fields of the GeoBroadcast Extended Header. 4) set the IS_NEIGHBOUR(SO) flag to FALSE if SO GN_ADDR does not equal SE GN_ADDR; 5) determine the link‐layer address LL_ADDR_NH of the next hop.

a) if the MIB attribute itsGnGeoBroadcastForwardingAlgorithm is set to 0 (UNSPECIFIED), execute the Simple GeoBroadcast with line forwarding algorithm.

b) if the MIB attribute itsGnGeoBroadcastForwardingAlgorithm is set to 1 (SIMPLE), execute the Simple GeoBroadcast with line forwarding algorithm.

6) if LL_ADDR_NH = 0, then buffer the GeoBroadcast packet in the BC forwarding packet buffer and omit the execution of further steps

7) if F (x, y) ≥ 0 (GeoAdhoc router is inside or at the border of the geographical area) pass the payload of the GN‐PDU to the upper protocol entity by means of a GN‐DATA.indication primitive with the parameter settings.

8) decrement the value of the HL field by one; if HL is decremented to zero, discard the GN‐PDU and omit the execution of following operations;

9) update the fields of the Common Header, i.e.: a) the HL field with the decremented HL value; b) the SE PV fields with the LPV.

10) execute media‐dependent procedures: if the Communication profile parameter of the GN‐DATA.request primitive is set to: a) UNSPECIFIED then omit this operation. b) ITS‐G5A then execute the operations.


Figure 52 : GeoBroadcast/GeoAnycast packet reception flowchart

On reception of a GeoAnycast packet, the GeoAdhoc router shall execute the following operations:


100

1) Common Header processing. 2) execute duplicate packet detection. If the GeoAnycast packet is a duplicate, discard the

packet and omit the execution of further steps. 3) update the PV(SO) in the LocT with the SO PV fields of the GeoAnycast Extended Header. 4) set the IS_NEIGHBOUR(SO) flag to FALSE if SO GN_ADDR does not equal SE GN_ADDR; 5) determine function F(x,y).

a) if F (x, y) < 0 (GeoAdhoc router is outside the geographical area) and the MIB attribute itsGnGeoAreaLineForwarding is set to TRUE, execute the GeoUnicast forwarding algorithm and determine the link‐layer address LL_ADDR_NH of the next hop. i) if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to 0

(UNSPECIFIED), execute the GF algorithm. ii) if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to 1 (GREEDY),

execute the GF algorithm. iii) if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to 2 (CBF), execute

the CBF algorithm. b) if F (x, y) ≥ 0 (GeoAdhoc router is inside or at the border of the geographical area) pass

the payload of the GN‐PDU to the upper protocol entity by means of a GN‐DATA.indication primitive.

3.3. GeoUnicast

In the case of GeoUnicast packet reception, the GeoAdhoc STA decides whether it is the recipient of a forwarder for the packet. Different cases are defined for the two cases.

3.3.1. ITS STA is the destination On reception of a GeoUnicast packet, the GeoAdhoc router shall check the GN_ADDR field in the DE PV of the GeoUnicast packet header. If this address does not match its GN_ADDR, the GeoAdhoc router shall execute the following operations (Figure 53):

1) Common Header processing. 2) execute duplicate packet detection. If the GeoUnicast packet is a duplicate, discard the

packet and omit the execution of further steps; 3) update the PV(SO) in the LocT with the SO PV fields of the GeoUnicast Extended Header. 4) set the IS_NEIGHBOUR(SO) flag to FALSE if SO GN_ADDR does not equal SE GN_ADDR. 5) flush packet buffers (SO LS packet buffer, SO UC forwarding packet buffer):

a) if LS_pending(SO) is TRUE: (1) flush the SO LS packet buffer. (2) forward the stored packets. (3) set LS_pending(SO) to false.


101

b) if the UC forwarding packet buffer for SO is not empty, flush the UC forwarding buffer and forward the stored packets;

6) update the DE PV(DE) in the LocT with DE PV fields in the GeoUnicast Extended Header. 7) update the fields of the Common Header, i.e.:

a) the HL field with the decremented HL value. b) the SE PV fields with the LPV.

8) update the DE PV fields with the PV(DE) in the LocT. 9) decrement the value of the HL field by one; if HL is decremented to zero, discard the GN‐

PDU and omit the execution of further steps; 10) determine the link‐layer address LL_ADDR_NH of the next hop.

a) if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to 0 (UNSPECIFIED), execute the GF algorithm.

b) if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to 1 (GREEDY), execute the GF algorithm.

c) if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to 2 (CBF), execute the CBF algorithm.

11) if LL_ADDR_NH = 0, then buffer the GeoUnicast packet in the UC forwarding packet buffer and omit the execution of further steps.

12) execute media‐dependent procedures: if the Communication profile parameter of the GN‐DATA.request primitive is set to: a) UNSPECIFIED then omit this operation; b) ITS‐G5A then execute the operations.


Figure 53 : GeoUnicast packet reception flowchart

3.3.2. ITS STA is a Forwarder On reception of a GeoUnicast packet, the GeoAdhoc router shall check the GN_ADDR field in the DE PV of the GeoUnicast packet header. If this address matches its GN_ADDR, the GeoAdhoc router shall execute the following operations:

1) Common Header processing.


102

2) execute duplicate packet detection. If the GeoUnicast packet is a duplicate, discard the packet and omit the execution of further steps.

3) update the PV(SO) in the LocT with the SO PV fields of the GeoUnicast Extended Header.

4) set the IS_NEIGHBOUR(SO) flag to FALSE if SO GN_ADDR does not equal the SE GN_ADDR.

5) flush packet buffers (SO LS packet buffer, SO UC forwarding packet buffer): a) if LS_pending(SO) is TRUE:

i. flush the SO LS packet buffer. ii. forward the stored packets. iii. set LS_pending(SO) to false.

b) if the UC forwarding packet buffer for SO is not empty, flush the UC forwarding buffer and forward the stored packets.

6) pass the payload of the GN‐PDU to the upper protocol entity by means of a GN‐DATA.indication primitive.

Forwarding Algorithms

Although in the standard defined by ETSI several forwarding algorithms are defined in the case of taking a routing decision, in order to keep our implementation as simple as possible we only implemented one for GeoUnicast transmissions and one for GeoBroadcast/Anycast packets. The algorithms are the “Greedy Forwarding” (GF) and the “Simple GeoBroadcast Algorithm”, that is dependent of the former.

1. Greedy Forwarding Algorithm With the Greedy Forwarding (GF) algorithm, the GeoAdhoc router uses the location information of the destination carried in the GeoUnicast packet header and selects one of the neighbors as the next hop.

The algorithm applies the most forward within radius (MFR) policy, which selects the neighbor with the smallest geographical distance to the destination, thus providing the greatest progress when the GeoUnicast packet is forwarded.

If no neighbor with greater progress than the local GeoAdhoc router exists, the packet has reached a local optimum.


103

2. Simple GeoBroadcast Algorithm The algorithm utilizes the function F(x,y) in order to determine whether the GeoAdhoc router is located inside, at the border or outside the geographical target area carried in the GeoBroadcast packet header. If the GeoAdhoc router is inside or at the border of the area, the packet shall be re‐broadcasted. If it is outside the area, the packet shall be forwarded by the GF algorithm.


104

4.2.11 Evaluation of the GeoNetworking Daemon For the evaluation of the overall platform, we engaged three of the NITOS nodes, setup with the tools described. In order to emulate mobility we used the gpsfake application, as we can see in Figure 54.

Figure 54 : Starting the gpsfake application

Once the GeoNetworking daemon starts, it prints out the MID that will be used in its GNADDR (Figure 55). By using the Wireshark packet sniffer, with ITS dissectors installed, we observe that every three seconds a beacon packet is sent, and correctly received on the receiver side.


105

Figure 55 : Transmission of Beacons

If we initialize the facility layer, that is used to create CAM packets every one second, we see that packets are correctly encapsulated in SHB packets, with a BTP‐A transport protocol (Figure 56 and Figure 57).

Figure 56 : Starting facility layer


106

Figure 57 : Capturing CAM messages

Once we change the facility layer, to send fake DENM messages, aiming for a Geobroadcast packet, we get the following packet transmission (Figure 58):

Figure 58 : GeoBroadcast packet transmission


107

4.2.12 Testbed Related extensions

NITOS testbed

For the evaluation of the Geonetworking implementation we used the NITOS Future Internet (FI) testbed and its corresponding control and management framework, OMF. NITOS (Network Implementation Testbed using Open Source code) FI is a key testbed in European research on Future Internet Research and Experimentation (FIRE) projects. It is a heterogeneous platform, where novel protocols and ideas can be evaluated under real conditions. The main experimental components of NITOS are the following:

1. A wireless experimentation testbed, which consists of powerful nodes (some of them mobile), that feature multiple wireless interfaces and allow for experimentation with heterogeneous (WiFi, Bluetooth, ZigBee) wireless technologies. NITOS has recently extended to a meso‐scale testbed, by acquiring a WiMAX Base Station and two LTE small cells and by also enabling WiMAX/LTE connectivity to the wireless nodes. NITOS’s 4G network spans throughout the metropolitan city of Volos.

2. A software defined radio (SDR) testbed that consists of Universal Software Radio Peripheral (USRP) devices attached to the NITOS wireless nodes. USRPs allow the researcher to program a number of physical layer features (e.g. modulation), thereby enabling dedicated PHY layer or cross‐layer research.

3. A Software Defined Networking (SDN) testbed that consists of multiple OpenFlow technology enabled switches, connected to the NITOS nodes, thus enabling experimentation with switching and routing networking protocols. Experimentation using the OpenFlow technology can be combined with the wireless networking one, hence enabling the construction of more heterogeneous experimental scenarios.

4. A testbed for conducting video‐transmission (wired or wireless) related experimentation, which consists of high definition digital cameras, mounted on the NITOS nodes. This component can be combined with the wired (OpenFlow) and wireless testbeds mentioned above, enabling the study of video transmission over heterogeneous communication technologies.

5. A distributed Wireless Sensor Network (WSN) testbed able to sense and gather environmental measurements from agricultural installations. The deployed facility consists of multiple clusters, each one comprised of wireless sensor devices and Gateway nodes, creating mesh networks utilizing the ZigBee technology. Measurements that are gathered by the sensor network are aggregated, stored and processed at a centralized cluster of servers, which controls the irrigating system. The distributed


108

wireless sensor infrastructure is located in the agricultural installation of UTH and enables experimentation on agricultural development by sensing environmental conditions as well as controlling multiple parameters on the agricultural process.

Figure 59: NITOS testbed deployment

NITOS testbed (Figure 59 and Figure 60) is open to the research community 24/7 and it is remotely accessible through the NITOS reservation tool. Parallel experimentation of different users is enabled, through the utilization of the NITOS scheduler software. The testbed is based on open‐source software that allows the design and implementation of new algorithms, enabling new functionalities on the existing hardware. Though OMF (cOntrol and Management Framework), NITOS supports evaluation of protocols and applications under real world settings. It is also designed to achieve reproducibility of experimentation though the CONCRETE (CONtrol and Classify REpeatable Testbed Experiments) tool developed in UTH.


109

Figure 60 : NITOS testbed architecture

OMF Framework

OMF [44] (Figure 61) is a free open‐source testbed control framework that manages over 20 testbeds worldwide, including the NITOS testbed in Europe and six WiMAX meso‐scale deployments in the US, along with the ORBIT facility at Rutgers University, the largest openly accessible wireless testbed facility in the world, for which OMF was originally developed in 2003. It provides an API for the experimenter to conduct experiments in a controlled manner, by using a simple experiment description written in OMF Experiment Description Language (OEDL), based on the Ruby language. OMF allows for organized control of a testbed’s resources (turning on/off the resources, loading an image on a node’s disk, saving the image, etc.) by using services running on an entity called Aggregate Manager (AM).


110

Figure 61. OMF architecture.

Moreover, two more entities are vital for the effective use of the framework: The OMF Resource Controller (RC) and the Experiment Controller (EC). The RC is actually controlling the testbed’s resources, and issues the appropriate commands needed for the effective setup of an experiment. The Experiment controller is used for the parsing the experiment’s parameters and sending them to the RC. The communication among all the entities of an experiment takes place over an XMPP server based on the Openfire tool [45] installed on the NITOS’s portal.

It provides an integrated measurement and instrumentation framework, as well powerful user tools and a portal that supports the entire experiment lifecycle.

OML Measurement Library

OMF’s accompanying library is called OML (OMF Measurement Library). It exploits a client‐server architecture and is used to send aggregated measurements from an application to a remote server side in an organized way. The server part of OML handles the measurements and passes them in a database file, to which the experimenter has access. OML can be used without using OMF, wherever an application creates measurements over a network. There are two ways of instrumenting an application with OML library:

• When we have the source code of the application, by using the open source libraries for OML


111

• By writing a wrapper around an existing application and parsing its output.

For the first case, implementations of the OML library exist for C/C++ language, Ruby and Python.

1. Instrumenting GeoNetworking with OML support For our case, since we had the source code of our application, we used the OML implementation for C/C++. The measurements we receive from the GeoNetworking application are actually the reported messages written to the logs of the application. Therefore, the experimenter that executes an experiment with GeoNetworking can have access to a database, containing the sequence number of each packet transmitted and if this was correctly received.

Integrating GeoNetworking on the NITOS testbed

In order to provide the GeoNetworking protocol as an experimentation tool in the NITOS FI, we set up an image containing the following:

• The gps‐clients and gps package from the Ubuntu repositories • Two files containing prerecorded routes in the NMEA language • OMF/OML support • The `GPSfake` application • gpsmm library.

Using the GPSfake application, the experimenter can emulate mobility conditions on the static NITOS node. GPSfake application parses the NMEA sentences and feeds them into gpsd (gps‐daemon) that runs on the node. Gpsd’s API provides us a JSON file with the current position of the “moving” object. This output is parsed by our POTI implementation, which then sends the data to the GeoNetworking daemon. Packets are sent every time they are triggered by our Facilities layer implementation


112

5. Protocols for network‐wide broadcasting Vehicular ad hoc networks provide peer to peer communication between vehicles. Some of the most challenging fields in VANETs include the routing of information messages among vehicles as well as the reliability in package delivery due to their dynamically changing topology. There are plausible circumstances were one to all communications is a great asset and may affect the entire network topology. Consider cases were a driver near a parking lot broadcasts a message concerning limited free spots. Nearby interested drivers may decide to follow to this location whereas further away vehicles are less likely to do so. Generally vehicles informed of unfavorable road conditions, for example of blocked roads, traffic jams or accidents will take prompt actions to alternate their route in order to avoid those locations and thus save time and fuel. To this direction the effective dissemination of messages (i.e., broadcasting a message to the largest possible portion of the vehicular network) plays an essential role.

The main goal of broadcasting in a one‐to‐all fashion is to deliver a message to the entire network or to a sufficiently large portion, while keeping the number of redundant retransmissions at minimum. This domain has rich literature. Centralized broadcasting (each node is aware of the entire network topology) [48] comes with unacceptable communication cost for maintenance, and thus cannot be utilized in dynamic networks such as VANETs. Geocasting [49] is another broadcasting approach for the delivery of messages to wireless nodes located in a specific geographic region, data dissemination and warning notifications. Other studies include the use of connecting dominating sets (CDS) as proposed in [50] to extract a `backboneʹ image of a network. Nevertheless, in vehicular networks with high mobility and intermittent connections maintaining an accurate backbone image is a costly strategy. More sophisticated approaches include those studied in [51]. For our project, we are interested in methods which do not induce significant additional communication costs such as by using CDSs.

Flooding a message throughout the network is a frequently used technique in wireless ad hoc structures. The simple flooding algorithm however causes the broadcast storm problem [52]. Other flooding based approaches include cases where nodes decide whether or not to rebroadcast a message based on some probability p. However this may results in occasions with either too few or too many retransmissions, which renders this flooding approach unreliable. In [53] the authors collected a list for the literature of small and large scale routing protocols and broadcasting methods. Among other studies, VDEB [54] and BPAB [55] are mentioned for selecting appropriate nodes to forward a message. However these approaches are not further modified for implementation in roads which include intersections.

OLSR [56] – our competitor – is a proactive or table‐driven routing protocol i.e., maintains a list


113

of destinations and routes by periodically exchanging topology messages and is widely used in mobile and vehicular ad hoc networks. This protocol relies on employing selected nodes to retransmit a message among the nodes of the network instead of pure flooding. The selected nodes are called multipoint relays (MPRs).

To address the shortcoming of OLSR, we exploit social inspired techniques for selecting appropriate sets of relay vehicles. We introduce the Probabilistic Control Centrality (pCoCe) as a one‐to‐all communication protocol with performance metric the total number of vehicles informed at the end of a notification message event. As a competing method we utilize the MPR set selection mechanism of the IETF standard OLSR. Our experimental results show that there are many occasions, where the minimum selected set of relays as identified by our competitor is not necessarily propitious to reach a sufficiently large part of a network.

In the sequel, we provide a brief coverage of the topic of influential spreaders as related to the relay selection process, and then we present the experimental design and obtained results.

5.1 Influential nodes in complex networks The analysis of complex networks has recently gathered the interest of the research society. A very important aspect lies in the identification of influential entities, i.e., detect those node‐entities in a complex structure where by exploiting their connection patterns, or their topological position in a graph, a sufficiently large portion of the network can be influenced. These `super spreaders` will be used to either boost spreading in case of fast dissemination of messages. Vehicular networks are also complex networks since their constantly changing topology creates network structures with non‐trivial topological features. Our objective in this study is to use vehicles that according to some criterion play an important role in a network and exploit them to maximize the spreading of messages. In [57] the authors argued that nodes positioned in the “core” of the network as identified by the k‐shell decomposition algorithm are capable of achieving the most efficient spreading; different and more local approaches are proposed in [58].

As mentioned earlier for vehicle networks the fast dissemination of a message that covers the largest possible portion of a network is a very important issue and finds fertile ground in many applications, from safety and precaution mechanisms to comfort and fuel saving applications. In our work we leveraged metrics from complex network theory used for the identification of influential nodes and particularly we developed a novel method the pCoCe based on Control Centrality [59] that efficiently detects potent vehicles for disseminating messages.

5.1.1 Control Centrality In [59] the authors introduce the concept of Control Centrality with view to identify nodes with


114

the ability to `controlʹ (drive to a specific state) a directed network based on an initial input and a `control goalʹ. To further investigate on the issue let us first note some definitions. A stem on a directed graph, is a directed path consisting of n nodes and n‐1 edges where no node appears more than once e.g., i→j→k→l→m. A cycle is noted as a stem ending on the initial node: i→j→k→i. A stem‐cycle disjoint subgraph, is a subgraph of the directed network where stems and cycles have no nodes in common. For any node i its control centrality is defined as the largest number of edges among all possible stem‐cycle disjoint subgraphs.

Our aim is to exploit vehicle‐nodes with high pCoCe values for use as multipoint relays. The intuition lies on the idea that those selected relays will rebroadcast a message on behalf of the initial sender and will likely cover a sufficiently large part of the vehicular network.

5.1.2 From Control Centrality to pCoCe As a first step we must define incoming and outgoing neighbors in vehicular networks. Since all connection links among vehicles are considered bidirectional, we use the relative direction between them to classify them either as in or out‐going neighbors. Generally vehicle A is considered an outgoing of vehicle B when A is moving either in front of B or away from B in a different direction. For instance in Figure 62 and for vehicle 7 the set of itʹs outgoing neighbors includes vehicles 1,3 and 6 while the rest synthesize itʹs ingoing vicinity.

Figure 62. In and out neighborhoods in a typical vehicular network.

With this consideration we can define stems and cycles in VANETS. However the use of cycles


115

to enhance a vehicleʹs importance in a vehicular network is very likely to overestimate the vehicles ability in disseminating a message to a large part of the network. Hence from here on we account only for stems, created from vehicle paths.

The original control centrality algorithm is computed with stems and cycles which cover the entire range of a network. However in VANETʹs due to their constantly changing topology and connection pattern (neighbor vehicles increase or decrease their distance in and out of the communication range or in‐neighbors become out and vise versa) we cannot utilize the method in full range. In this study we confined our selves to a range of two and three hops distance (2pCoCe, 3pCoCe).

Note that pCoCe uses all stems within our specified range and there are occasions were different stems have common edges. These stems will all contribute in the final pCoCe value for a vehicle‐node and form itʹs final index. At this point we would like to note that our new method is a novel approach that considers and combines different stems emanating from a particular vehicle and define its significance in the network.

The last part of pCoCe accounts for the strength of connections between vehicles (stem power) and incorporates this attribute in the formed stems. Depending on the quality of the connection for each out‐neighbor we assign a weight value between 0 to 1 depicting the strength of connection between the two vehicles. Weights close to 1 depict a perfect communication link whereas values close to 0 depict an almost absent connection. The stem power is computed as follows:

Sp = S x PW

where S depicts the size of a stem in edges and PW is the product of the weights that form it.

We consider all weight values to be equal to 1. Further investigation for the strength of connections and its incorporation in Sp is a very interesting task, but itʹs beyond the scope. Finally in order for a vehicle to accumulate its final pCoCe index it sums all the different Spʹs to a final value which will characterize its importance within its vicinity:

pCoCe(x)= ∑i

p iS )(

where i denotes the different stems emanating from vehicle x.

5.1.3 pCoCe relay set selection pCoCeʹs algorithm for selecting relays is straightforward. Every vehicle sorts its out one hop neighbors in descending order of their pCoCe values. The neighbor with the maximum value is


116

selected as a relay. In the sequence the next highest neighbor is examined. If additional out two hop neighbors are reached, this vehicle is included in the relay set and so on until the entire two hop neighborhood is covered. At this point we should note that only the out one and two hop neighbors are considered for the selection process. The pseudocode is given in Figure 63. One final modification of the pCoCe is needed in order for a sender to select an appropriate relay set. Some of the accumulated Spʹs that are used in order to form the pCoCe value may be incoming stems to the sender i.e., the final vehicle on a stem may be an incoming neighbor. Those vehicle stems should be excluded from the computation of the final index. To this end when a vehicle needs to broadcast or rebroadcast a message it dynamically asks from its out one hops to compute and respond with their pCoCe values excluding stems incoming to the sender. Finally the returned values are multiplied by the number of the two hops covered by each respective out‐neighbor. Note that at this point we introduce an additional communication phase and thus an additional delay before sending the message.

Figure 63. Pseudo‐code for pCoCe relay set selection .

5.1.4 OLSR MPR set selection The notion of in and out going neighbors is also induced into the MPR selection process of OLSR in order to select relays from identical vicinities in both approaches and thus only out one


117

and two hop neighbors are considered. OLSR first selects vehicles that provide unique access to some two hop neighbors. In the sequent the vehicle that covers the maximum remaining two hop vicinity is selected and so on until the entire two hop neighborhood is reached. The pseudocode for the MPR selection process is given in Figure 64.

Figure 64. Pseudo‐code OLSR MPR set selection.

5.2 Performance Evaluation For the evaluation purposes and for our experimentation we use the open source vehicular network simulation framework, VEINS [60], which uses SUMO for the traffic simulation and OMNET++ the network simulation framework.

5.2.1 Simulation design

Grid Network

We evaluated the performance of pCoCe in a grid road network topology (3X3). The network includes road segments with two direction flows and every 2km there are intersections with traffic lights providing a coordinated traffic flow. The competitors where evaluated under different circumstances concerning the range of communication, the velocity of vehicles and the density of cars on the road network. Particularly we experimented with vehicle velocities of 14, 20 and 28m/s and range of communication at 250 and 500m. For the density of the scenarios we introduce a vehicle every 1, 5, 10 and 15 seconds, ranging from very dense to very sparse network topologies. The average number of vehicles to the corresponding frequencies is 950,


118

250, 170 and 120 cars respectively. Vehicle flows enter the simulation from different road segments of the grid network.

Communication between vehicles

All vehicles are communicating through DSRC with range of communication as previously noted in 250 and 500m. For every vehicle in order to be aware of its vicinity, beacon messages are exchanged every 1 second. In order to maintain an updated image of its surroundings, every vehicle that has not received a beacon message from recoded neighbors for more than two seconds i.e., missed two consecutive beacons, updates its vicinity by removing those vehicles. This ensures that each vehicle has a clear and very recent image of its neighboring cars.

Notification message event

The dissemination of notification messages is triggered upon notification events. A notification event is generated from a random vehicle at a random position on the road network (the same vehicle for both approaches) with only one notification existing at a time. The results are averaged over 10 different events for each competing method.

5.2.2 Dissemination to the entire grid

Experimenting on vehicle density, 2pCoCe

The aim of this first experimentation set is to conclude whether the conservative MPR set selection of OLSR is adequate for informing a sufficiently large part of a vehicular network. The results are illustrated in Figure 65 to Figure 67. On the x‐axis we depict the frequency to which vehicles are introduced in the simulation in seconds, while keeping the velocity constant at 14, 20 and 28m/s respectively. Communication range is set to 500m. The results are given in percent depending on the number of vehicles present in the simulation at the time of the notification event.

In all but one cases OLSR fails to exceed the percentage of the vehicular network covered by 2pCoCe. The results in Figure 65, set with the lowest speed (14m/s) in our experimentation, show that the frequency of vehicles does not have a significant impact on our approach.

Our method manages to find the right paths for the spreading of messages and inform the vehicular network at near 80%. For our competitor the worst case performance is illustrated for the dense scenarios. This indicates that OLSR when faced with many options for selecting MPR vehicles cannot distinguish an appropriate MPR set for the most efficient spreading of messages. Considering the sparser scenarios in the same Figure, and thus with fewer choices, OLSRʹs performance is improved. Nevertheless the competitors show a difference in percent


119

coverage of more than 25% for the best case of OLSR.

Figure 65. OLSR versus 2pCoCe with vehicle velocity at 14m/s.


In Figure 66 and Figure 67 we repeat our experimentation with increased speeds to 20 and 28m/s respectively. Increasing the velocity of vehicles will result in a more frequently changing topology among a vehicleʹs surroundings and thus a more profound selection is crucial. As illustrated, 2pCoCe is performing extensively well when dealing with a large number of


120

potential choices for the relay set. The coverage rate rises up to more than 90%. OLSR significantly fails to keep up with our approach.


In the last illustrated example for this set of experimentation, Figure 67, 2pCoCe shows a decreasing performance as we move to sparser network topologies. This indicates a more reliable and trustworthy behavior in contrast to OLSR showing extensive fluctuations in coverage when changing the network density at a relative high speed.

Differences in the selected relays

In Figure 68 we normalize the size of the network that received the message with the number of MPRs selected by each competing method, through the entire spreading process. Since OLSR makes a conservative choice for his MPRs a frequent phenomenon is that the spreading dies after a few hops (due to false relay set selection) and thus covers a significantly lower portion of the network. Since the spreading for 2pCoCe continues in further broadcasting circles than our competitor, more vehicles are selected in subsequent steps as relays.

As far as the average number of MPRs per vehicle is concerned OLSR selects the minimum set of relays. However, as shown through our experimentation in many cases OLSR results into very poor spreading compared to our approach. For the dense scenarios with vehicles entering the simulation every 1 or 5 seconds, 2pCoCeʹs relay set is greater than OLSRʹs by one or two vehicles whereas for the cases of 10 and 15 seconds we have either equal sets or our set is greater by one. By equal or greater sets we are merely referring to the number of relays selected


121

by each method. Indeed there are occasions were the competitors select similar sets of vehicles, however on average different relays are chosen as identified by each algorithm. Reviewing the differences in coverage rates for both methods in Figure 65 to Figure 67 one or two additional relays is a good trade‐off when a significantly larger part of the network is reached.

Figure 68. Normalized coverage by number of selected mprs of each method.

Increasing the range of pCoCe to 3 hops distance

In this set of experiments we evaluate the performance of pCoCe when increasing the distance of interest from 2 to 3 hops. The results are illustrated in Figure 69. When vehicles enter the simulation every 1 seconds, regardless of their velocity, 3pCoCe covers a greater percent of the vehicular network than 2pCoCe and thus greater than OLSR. This indicates that 3pCoCe (and also 2pCoCe) performs extensively well in very dense scenarios by selecting potent vehicles for rebroadcasting with total percent of coverage over 85%. For vehicle frequencies of every 5 and 10 seconds as shown in our experimentation, 3pCoCeʹs coverage is constantly higher than 80%. Our algorithms performance seems to start getting affected by the vehicle velocities when examining the sparse scenario where vehicles enter the simulation every 15 seconds. Nevertheless the coverage percentage reached by 3pCoCe is about 63% for the worst case of its performance and up to approximately 73% at best. For OLSR the best coverage rate in this scenario rises up to about 56%.


122

Figure 69. Comparing pCoCe’s performance with 2 and 3 hops distance.

Reducing the communication range to 250m

Considering only out one hop vehicles as potential relays, it can be considered a `hazardousʹ approach. As noted earlier, out going neighbors are those who either move away from a sender to a different direction or positioned ahead of a sender and moving towards the same direction. Thus these are the vehicles which are most likely to `exitʹ the communication range of a sender, sooner than other neighbors. In Figure 70 we illustrate the obtained results with vehicle frequency set at 1 seconds and communication range at 250m. Excluding results at 28m/s, pCoCe provides a wider range of the network coverage than OLSR for 2 and 3 hops distance stems. Analogous results were obtained for 5 seconds frequency, however both the algorithms performance drop below 10% when considering the sparser scenarios. Let us elaborate a little more on the impact of the communication range on pCoCe. As mentioned earlier, our approach calculates stems of vehicles of 2 or 3 hops distance from a sender car. These stems are composed of outgoing neighbors (excluding paths incoming to the sender) and thus further expand the hazardness of outgoing vehicles to additional hops. Therefore, pCoCe, when limited to a very short communication range, performs best in minimum stem distance, i.e., 2 hops.


123

Figure 70. Communication range at 250m for frequency of vehicles every 1 seconds.

5.3 Concluding remarks In this section, we presented a novel approach for the selection of relay vehicles based on metrics from complex network theory and the identification of influentials. We proposed a novel broadcasting protocol which induces minimum additional communication cost and performs extensively well when dealing with a large number of potential relay choices. Our competitor fails to provide both an adequate coverage rate and reliability as illustrated under diverse simulation parameters. As future work incorporating the quality of links in the `stem powerʹ will provide valuable insights in broadcasting a message under harsh communication environments and different road topologies.


124

6. REDUCTION and standards Summarizing our discussion and recalling the outcome of D6.3.1 and D6.3.2, we show in Table 8 the standards used in REDUCTION, and the efforts made by the partners to improve them.

Standard WP Field trial

REDUCTION contribution

Specific contribution

Status

IEEE 802.11p WP1, WP5 CTL X N/A Used IEEE 1609.3 WP1, WP5 CTL X N/A Used

ETSI TS 102 636‐4‐1 WP1, WP5 CTL √

Extension to Geonetworking: a) cross‐layering, b) refrain from continuous retransmission when not needed

A) Geonetworking implementation: Ready ‐ Used B) Extensions to Geonetworking and evaluation of their efficiency: Ready – Used

SAE J2945 WP1, WP5 CTL X N/A Used SAE J2735 WP1, WP5 CTL X N/A Used

IETF RFC3626 (OLSR) protocol

WP1, WP5 CTL √ Extensions to OLSR

using complex network theory

A) OLSR used B) pCoCe protocol: Ready (evaluated by

simulations) Bluetooth WP4, WP5 TRI X N/A Used DATEX II WP1 CTL X N/A Not used

DVM Exchange WP4, WP5 TRI √ Initial definition of the

standard Not ready

Table 8. Exploitation and extensions to standards by REDUCTION.


125

7. Final Assessment As emphasized in D6.3.2 the late standardization of DVM Exchange did not affect REDUCTION’s operation. The work on the standard is ongoing, and there is still (as of August 1st, 2014) intense activity on it (http://www.dvm‐exchange.nl/).

DSRC technology has indeed the potential to support many different types of applications. This technology depends fundamentally on standards‐based interoperability. The core standards that were used in REDUCTION had reached a critical level of maturity. Several have been published within the past 3 years: IEEE 802.11p, IEEE 1609.2, IEEE 1609.3, and IEEE 1609.4. A version of SAE J2945.1 Minimum Performance Requirements had also been published. Recent testing of basic interoperability among independent DSRC implementations is encouraging. The state of development of DSRC was mature and used safely for the REDUCTION’s purposes. Since it is customary that all changes and amendments to standards do not radically modify the standard, we feel safe that our decisions of adopting these standards were wise and appropriate.

Our implementation of GeoNetworking is fully functional and was used in a (real, not simulated) video streaming application, which has been described in REDUCTION’s deliverable D5.3. GeoNetworking’s evaluation has also appeared in two articles [61] and [62]. However, we emphasize that all V2V technologies are very efficient when the communication involves communicating vehicles which are a few hops away. It is still a hard problem – for the car industry as well –to support multi‐hop communications for data‐hungry applications in a V2V fashion.

We have shown via our pCoCe routing protocol that, despite the high mobility of vehicles and the harsh conditions in vehicular environments, it is still possible to develop highly efficient routing protocols based on V2V activity that can support network‐wide operations, and beat existing standards. However, we must maintain some slight reservations, since we have only evaluated our protocol via simulations. We do not expect that our proposal will be defeated, but simply that its performance will be lower than that presented in the simulations.


126

8. Conclusion

In the context of REDUCTION, the partners were actively involved in the use, development and evolution of current standards concerning wireless communications and network management. All the objectives that were initially set were fully achieved.

In REDUCTION we focused on one specific wireless technology, i.e., Dedicated Short‐Range Communication (DSRC). UTH developed its own fully‐compliant with ETSI version of GeoNetworking making where needed slight improvements. Actually, this implementation is a significant contribution since there are not any other fully‐compliant implementations available publicly. Additionally, in the context of REDUCTION we recognized the inefficiencies of standard multi‐hop routing protocols, and developed a more efficient one. Trinite has also contributed to the initial definition of the DVM Exchange standard used for network management purposes. Overall, Table 9 presents which standards were used and how they were extended by the REDUCTION’s partners. Trinite, DELPHI and UTH will continue their efforts and involvement in the standardization procedures, but it should be made clear that such efforts can not “commit” within a three‐year period. They are time‐consuming processes that evolve over many rounds of consultation and discussion.

Standard WP Field trial

REDUCTION contribution

Specific contribution

Status

IEEE 802.11p WP1, WP5 CTL X N/A Used IEEE 1609.3 WP1, WP5 CTL X N/A Used

ETSI TS 102 636‐4‐1 WP1, WP5 CTL √ Extension to

Geonetworking Geonetworking: Ready ‐ Used

SAE J2945 WP1, WP5 CTL X N/A Used SAE J2735 WP1, WP5 CTL X N/A Used IETF RFC3626 (OLSR) protocol

WP1, WP5 CTL √ Extension to OLSR OLSR: used pCoCe: ready

Bluetooth WP4, WP5 TRI X N/A Used

DVM Exchange WP4, WP5 TRI √ Initial definition of the

standard Not ready

Table 9. Standards used/developed in the context of REDUCTION.


127

References

[1] The DVM Exchange website: http://www.dvm-exchange.nl/ [2] M.J. Cassidy, K. Jang, and C.F. Daganzo, “Macroscopic fundamental diagrams for freeway

networks: Theory and observation”, In 90th Annual Meeting of Transportation Research Board Compendium of Papers, January 2011.

[3] C.F. Daganzo and N. Geroliminis, “An analytical approximation for the macroscopic fundamental diagram of urban traffic, Transportation Research Part B: Methodological, 42(9):771 – 781, 2008.

[4] H. Etemadnia and K.F. Abdelghany, “A network partitioning methodology for distributed traffic management applications”, In 90th Annual Meeting of Transportation Research Board Compendium of Papers, January 2011.

[5] S. Hoogendoorn, S. Hoogendoorn-Lanser, J. van Kooten, and S. Polderdijk, “Integrated network management: Towards an operational control method”, In 90th Annual Meeting of Transportation Research Board Compendium of Papers, January 2011.

[6] Y. Li, J. Yang, X. Guo, and M.M. Abbas, “Urban traffic signal control network partitioning using self-organizing maps”, In 90th Annual Meeting of Transportation Research Board Compendium of Papers, January 2011.

[7] J.K. Marcuson, “The integration of ICM and ATM”, In: Proceedings of the 18th ITS World Congress, Orlando, Florida, USA, October 2011.

[8] P. Parthasarathi and D.M. Levinson, “Network structure and metropolitan mobility”, In 90th Annual Meeting of Transportation Research Board Compendium of Papers, January 2011.

[9] P. Parthasarathi, H. Hochmair, and D. M. Levinson, “Network structure and spatial separation”, In 90th Annual Meeting of Transportation Research Board Compendium of Papers, January 2011.

[10] F. Pooran and J.C.R. Martinez, “True adaptive control algorithms, a comparison of alternatives, In Proceedings of the 18th ITS World Congress, October 2011.

[11] J. L. M. Vrancken, J. H. van Schuppen, M. S. Soares, and F. Ottenhof, “A hierarchical network model for road traffic control”, Proceedings of the IEEE International Conference on Networking, pp. 340–344, 2009.

[12] J.L.M. Vrancken, F. Ottenhof, R.K. Boel, J.H.van Schuppen, L. Tassiulas, and M. Valé, “WP4 Road network control: Design of the measurement system” Technical report, Delft University of Technology, Deliverable D-WP4-3 of the C4C project, December 2009.

[13] J.L.M. Vrancken, F. Ottenhof, M. Valé, R. Lagerweij, and P. Goossens, “DVM Exchange, An interface standard for traffic management systems”, In Proceedings of the ITS World Congress, pages 1–4, October 2011.

[14] Y. Wang, F. Ottenhof, and J.L.M. Vrancken, “Integrating bottom-up traffic control into the scenario coordination module, In Proceedings of ITS Europe, June 2011.

[15] Y. Wang, J.L.M. Vrancken, F. Ottenhof, and M. Valé, “Next generation traffic control in the Netherlands”, In Proceedings of the 18th ITS World Congress, October 2011.

[16] Rijkswaterstaat: Handbook Sustainable Traffic Management, November 2003, ISBN 903693625X [17] J. van Kooten, K. Adams, “Module Gebiedsgericht Benutten Plus” In Handboek

Verkeersmanagement, CROW-publicatie 290, 2011. [18] B. van der Veen, R. Walhout, “Van Strategie naar een slagvaardig verkeersmanagement”,

Proceedings of the DVM Symposium, 2009. [19] ETSI EN 302 665: "Intelligent Transport Systems (ITS); Communications Architecture" [20] IETF RFC 5213: "Proxy Mobile IPv6". [21] ITU-R Recommendation M.687-2: "International Mobile Telecommunications 2000 (IMT-2000)".


128

[22] ETSI EN 302 665: "Intelligent Transport Systems (ITS); Communications Architecture" [23] ETSI TS 102 636-3: “Intelligent Transport Systems (ITS); Vehicular Communications;

GeoNetworking; Part 3: Network architecture” [24] IETF RFC 3753: "Mobility Related Terminology". [25] IETF RFC 2460: "Internet Protocol, Version 6 (IPv6) Specification" [26] IETF RFC 3775: "Mobility Support in IPv6". [27] IETF RFC 3963: "Network Mobility (NEMO) Basic Support Protocol". [28] IETF RFC 791: "Internet Protocol" [29] ETSI TS 102 636-5-1: “Intelligent Transport Systems (ITS); Vehicular Communications;

GeoNetworking; Part 5: Transport Protocols; Sub-part 1: Basic Transport Protocol” [30] IETF RFC 768: "User Datagram Protocol" [31] IETF RFC 793: "Transmission Control Protocol" [32] IEEE 802.11: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”

[33] IEEE 802.11:2007: "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".

[34] ETSI EN 302 571 (V1.1.1): "Intelligent Transport Systems (ITS); Radiocommunications equipment operating in the 5 855 MHz to 5 925 MHz frequency band; Harmonized EN covering the essential requirements of article 3.2 of the R&TTE Directive".

[35] ETSI EN 301 893 (V1.5.1): "Broadband Radio Access Networks (BRAN); 5 GHz high performance RLAN; Harmonized EN covering the essential requirements of article 3.2 of the R&TTE Directive".

[36] ECC/DEC(02)01: "ECC Decision of 15 March 2002 on the frequency bands to be designated for the co-ordinated introduction of Road Transport and Traffic Telematic Systems".

[37] Commission Decision 2008/671/EC of 5 August 2008 on the harmonised use of radio spectrum in the 5 875-5 905 MHz frequency band for safety-related applications of Intelligent Transport Systems (ITS).

[38] ECC/REC/(08)01: "ECC Recommendation (08)01 on the use of the band 5855-5875 MHz for Intelligent Transport Systems (ITS)".

[39] ERC/DEC(99)23: "ERC Decision of 29 November 1999 on the harmonised frequency bands to be designated for the introduction of High Performance Radio Local Area Networks (HIPERLANs)".

[40] Commission Decision 2005/513/EC of 11 July2005 on the harmonised use of radio spectrum in the 5 GHz frequency band for the implementation of wireless access systems including radio local area networks (WAS/RLANs).

[41] Commission Decision 2007/90/EC of 12 February 2007 amending Decision 2005/513/EC on the harmonized use of radio spectrum in the 5 GHz frequency band for the implementation of Wireless Access Systems including Radio Local Area Networks (WAS/RLANs).

[42] ETSI TS 102 687 (V1.1.1): "Intelligent Transport Systems (ITS); Transmitter Power Control Mechanism for Intelligent Transport Systems operating in the 5 GHz range".

[43] OSGi™ - The Dynamic Module System for Java – http://www.osgi.org [44] cOntrol and Management Framework (OMF) – http://omf.mytestbed.net [45] Openfire - Ignite Realtime: Openfire Server – http://www.igniterealtime.org/projects/openfire/ [46] An Open Source GeoNetworking Implementation - http://hal.inria.fr/hal-00760724/ [47] Click Modular Router - http://www.read.cs.ucla.edu/click [48] I. Gaber and Y. Mansour, “Centralized broadcast in multihop radio networks”, Journal of

Algorithms, vol. 46, pp. 1–20, 2003. [49] Y. A. Daraghmi, I. Stojmenovic, and C. W. Yi, “A taxonomy of data communication protocols for


129

vehicular ad hoc networks”, Mobile Ad Hoc Networking: Cutting Edge Directions, pp. 517–544, 2013.

[50] I. Stojmenovic, A. Khan, and N. Zaguia, “Broadcasting with seamless transition from static to highly mobile wireless ad hoc, sensor and vehicular networks”, International Journal of Parallel, Emergent and Distributed Systems, vol. 27, pp.225–234, 2012.

[51] A. M. Vegni, A. Stramacci, and E. Natalizio, “SRB: A selective reliable broadcast protocol for safety applications in VANETs”, Proceedinsg of the International Conference on Selected Topics in Mobile & Wireless Networking, 2012.

[52] S. Y. Ni, Y. C. Tseng, Y. S. Chen, and J. P. Sheu, “The broadcast storm problem in a mobile ad hoc network”, Proceedings of ACM/IEEE MOBICOM Conference, pp. 151–162, 1999.

[53] Y. A. Daraghmi, C.W. Yi, I. Stojmenovic, and K. Abdulaziz, “Forwarding methods in data dissemination and routing protocols for vehicular ad hoc networks”, IEEE Network, vol. 27, pp. 74–79, 2013.

[54] Y. T. Tseng, R. H. Jan, C. Chen, C. F. Wang, and H. H. Li, “A vehicle-density-based forwarding scheme for emergency message broadcasts in VANETs”, Proceedings of the 7th IEEE International Conference on Mobile Adhoc and Sensor Systems, pp. 703–708, 2010.

[55] J. Sahoo, E. H.-K. Wu, P. K. Sahu, and M. Gerla, “Binary-partition-assisted AMC-layer broadcast for emergency message dissemination in VANETs”, IEEE Transactions on Intelligent Transportation Systems, vol. 12, pp. 757–770, 2011.

[56] P. Jacquet, P. Muhlethaler, T. Clausen, A. Laouiti, A. Qayyum, and L. Viennot, “Optimized Link State Routing protocol for ad hoc networks”, Proceedings of the IEEE International Multi Topic Conference, pp. 62–68, 2001.

[57] M. Kitsak, L. K. Gallos, S. Havlin, F. Liljeros, L. Muchnik, H. E. Stanley, and H. A. Makse, “Identification of influential spreaders in complex networks”, Nature Physics, vol. 6, pp. 888–893, 2010.

[58] P. Basaras, D. Katsaros, and L. Tassiulas, “Detecting influential spreaders in complex, dynamic networks”, IEEE Computer magazine, vol. 46, no. 4, pp. 26–31, 2013.

[59] Y.-Y. Liu, J.-J. Slotine, and A.-L. Barabasi, “Control centrality and hierarchical structure in complex networks”, PLOS One, vol. 7, no. 9, 2012.

[60] C. Sommer, R. German, and F. Dressler, “Bidirectionally coupled network and road traffic simulation for improved IVC analysis”, IEEE Transactions on Mobile Computing, vol. 10, no. 1, 2011.

[61] N. Makris, T. Korakis, D. Katsaros, L. Tassiulas, “Enabling ITS Real World Experimentation in NITOS Future Internet facility”, Proceedings of the 11th IEEE/IFIP Annual Conference on Wireless On-demand Network Systems and Services (WONS), pp. 97-103, 2014.

[62] N. Makris, C. Zarafetas, T. Korakis, D. Katsaros, L. Tassiulas, “Enabling Intelligent Transport System Experimentation in the NITOS networking testbed”, IEEE Internet of Things Journal (Special Issue on Internet of Vehicles), submitted, May, 2014.

REDUCTION 2011 2014 Deliverable 6.3.3 Final Report on Contributions to Standards … ·...

Documents

Transcript of REDUCTION 2011 2014 Deliverable 6.3.3 Final Report on Contributions to Standards … ·...