SP3 – SINTECH – Innovative Technologies Key Concepts and ... · 1.1 20/04/2010 Chap 2.1.3....

Deliverable D3.5.4 Dissemination Level PUBLIC Copyright SAFESPOT

Contract N. IST-4-026963-IP

SF_D3.5.4_KeyConceptsAndExploitation_v1.2.doc of 63 SINTECH

SAFESPOT INTEGRATED PROJECT - IST-4-026963-IP

DELIVERABLE

SP3 – SINTECH – Innovative Technologies

Deliverable No. (use the number indicated on technical annex)

D3.5.4

SubProject No. SP3 SubProject Title SINTECH

Workpackage No. WP3.5 Workpackage Title Evaluation

Task No. -- Task Title --

Authors (per company, if more than one company provide it together)

Achim Brakemeier (DAI), Norman Mattern, Robin Schubert (TUC), Oliver Kannenberg (TA) Christian Zott (BOSCH), Dzmitry Kliazovich (CREATE-NET) Tim Edwards (MIRA),

Status (F: final; D: draft; RD: revised draft): F

Version No: 1.2

File Name: SF_D3.5.4_KeyConceptsAndExploitation_v1.2.doc

Planned Date of submission according to TA: 31/01/2009

Issue Date: 31/03/2009

Project start date and duration 01 February 2006, 48 Months

Key Concepts and Exploitation




Revision Log Version Date Reason Name and Company

0.0 5/02/2009 Initial A.Brakemeier (DAI)

0.05 16/02/2009 Chap. 2, Architecture Chap. 5.1, Comm. Architecture

A.Brakemeier (DAI)

0.06 18/02/2009 Chap. 5.2, Geocast A.Brakemeier (DAI)

0.09 11/03/2009 Chap. 3, Positioning N.Mattern, R.Schubert (TUC)

0.10 11/03/2009 Multihop GPSR-MA, Chap. 0, 8.4

D. Kliazovich (CREATE-NET)

0.20 17/03/2009 Annex 8.1, Security A.Brakemeier (DAI)

0.50 17/03/2009 Chap. 4, LDM A.Brakemeier (DAI) O.Kannenberg (TA)

0.60 27/03/2009 comments C.Zott (BOSCH) 0.70 27/03/2009 Chap. 5.4 VANET Validation T.Edwards (MIRA)

0.8 30/03/2009 Annex 8.2 LDM Impl., Summary / Conclusion A.Brakemeier (DAI)

0.9 31/03/2009 Peer Review Version A.Brakemeier (DAI)

1.0 23/04/2009 Including peer reviewers comments A.Brakemeier (DAI)

1.1 20/04/2010 Chap 2.1.3. SAFESPOT results and EC mandate M/453

A.Brakemeier (DAI)

1.2 29/04/2010 Peer reading G.Vivo (CRF)




Abbreviation List AbC Approval by correspondance

ACI Adjacent channel interference

API Application programming interface

CAM Cooperative awareness message

C2C-CC Car-to-Car Communication Consortium

CCH Control channel

CEPT Conférence Européenne des administrations des postes et des télécommunications

CSMA/CA Carrier sense multiple access with collision avoidance

CVIS Cooperative vehicle-infrastructure systems (EC project)

C2C Car-to-Car

C2I Car-to-Infrastructure

EC European commission

ETSI European Telecommunications Standards Institute

ETCI TC ITS ETSI Technical Committee, responsible for ITS

ECC Electronic communications committee

FOT Field operational test

GNSS Global navigation satellite system

GPS Global positioning system

GPSR-MA Greedy perimeter stateless routing with mobile awareness

HMI Human machine interface

INS Inertial Navigation System

ITS Intelligent transportation systems

JDL Joint directors laboratories - data fusion model

MAC media access control (communication layer)

NTP Network time protocol

PPS Pulse per second

PSD Power spectral density

QoS Quality of service

RF Radio frequency

RSU Roadside unit

SCH1 First service channel




SCHx service channel x

SINTECH SAFESPOT Innovative Technologies

SMA Safety margin assistant

SPx SAFESPOT subproject x

STF Specialist task force

TUE Transmitter unwanted emission

UTC Universal time, coordinated

UWB Ultra wide band




Table of contents Revision Log ............................................................................................................................................2 Abbreviation List......................................................................................................................................3 Table of contents ......................................................................................................................................5 List of Figures ..........................................................................................................................................7 List of Tables............................................................................................................................................7 EXECUTIVE SUMMARY ......................................................................................................................8 1. Introduction ......................................................................................................................................9

1.1. Contribution to the SAFESPOT Objectives ...........................................................................10 1.2. General Methodology .............................................................................................................10 1.3. Deliverable structure...............................................................................................................11

2. Architecture ....................................................................................................................................12 2.1. European ITS Communication Architecture ..........................................................................12

2.1.1. Frequency Allocation......................................................................................................12 ECC Decision .............................................................................................................................12 Channel Usage............................................................................................................................13

2.1.2. COMeSafety and ETSI TC ITS......................................................................................14 2.1.3. SAFESPOT results and EC mandate M/453 ..................................................................15

2.2. SAFESPOT General Architecture ..........................................................................................17 2.3. Communication Paradigm ......................................................................................................18

2.3.1. Cooperative Awareness ..................................................................................................18 2.3.2. The push principle ..........................................................................................................19 2.3.3. No query of raw sensor data ...........................................................................................20 2.3.4. Timing of Messages........................................................................................................20 2.3.5. Emergency Messages......................................................................................................20

2.4. Message Manager ...................................................................................................................21 2.5. Local Dynamic Map and Data Fusion ....................................................................................22 2.6. Sensor Abstraction..................................................................................................................24

3. Positioning......................................................................................................................................25 3.1. Ego-Positioning ......................................................................................................................25 3.2. Positioning Components.........................................................................................................26 3.3. Trajectories .............................................................................................................................26 3.4. Time Server ............................................................................................................................27

4. Local Dynamic Map .......................................................................................................................28 4.1. Central Data Store ..................................................................................................................28 4.2. Object Model ..........................................................................................................................29 4.3. Interfaces ................................................................................................................................31

4.3.1. T-API, Q-API .................................................................................................................31 4.3.2. Level 1 API.....................................................................................................................32 4.3.3. Level 2 API.....................................................................................................................33 4.3.4. Notification Mechanism .................................................................................................33

4.4. Static Maps .............................................................................................................................34 5. Vehicular Ad Hoc Network............................................................................................................35

5.1. Communication Architecture..................................................................................................35 5.1.1. SAFESPOT Router.........................................................................................................35 5.1.2. Functional Components ..................................................................................................35 5.1.3. Generic Message Format ................................................................................................37 5.1.4. Cooperative Awareness Message ...................................................................................38

5.2. Geocast Communication.........................................................................................................39 5.2.1. Single Hop Broadcast .....................................................................................................39 5.2.2. Geo-Address ...................................................................................................................40

Destination Area.........................................................................................................................40 Position Relevance Function ......................................................................................................42 Enhanced Destination Area ........................................................................................................43 Default values and Constraints ...................................................................................................44

5.2.3. Geocast Functionalities...................................................................................................44 Geo-Broadcast, Simple Flooding................................................................................................44




Multihop, Geo-Anycast, Geo-Unicast ........................................................................................45 Movement-Aware Routing .........................................................................................................46 Stored Lineforwarding................................................................................................................46 Stored Geo-Broadcast.................................................................................................................47

5.2.4. Time Relevance Function ...............................................................................................47 5.3. Congestion Control and Priorities ..........................................................................................48 5.4. VANET Router Validation.....................................................................................................49

6. Conclusions ....................................................................................................................................51 7. References ......................................................................................................................................52 8. Annex .............................................................................................................................................54

8.1. Security...................................................................................................................................54 8.2. LDM Implementations ...........................................................................................................56

8.2.1. PG-LDM (Bosch / Teleatlas)..........................................................................................56 8.2.2. NAVTEQ-LDM..............................................................................................................57

8.3. Cooperative Awareness Message ...........................................................................................59 8.4. Greedy Perimeter Stateless Routing with Mobile Awareness (GPSR-MA) ...........................60 8.5. UWB positioning....................................................................................................................62




List of Figures Figure 1 EGO-Positioning ..............................................................................................................9 Figure 2 LDM .................................................................................................................................9 Figure 3 VANET...........................................................................................................................10 Figure 4 Exploitation and Standardization....................................................................................11 Figure 5 European Frequency Allocation .....................................................................................12 Figure 6 Channel Definitions (from D3.4.3, [8]) ..........................................................................13 Figure 7 ITS Station Reference Architecture................................................................................15 Figure 8 SAFESPOT general architecture (from D7.3.1, Fig. 6)..................................................17 Figure 9 SAFESPOT system monitor ESPOSYTOR (bird view).................................................19 Figure 10 SAFESPOT’s Cooperative Engine .................................................................................21 Figure 11 JDL DF functional model (from D1.3.3)........................................................................22 Figure 12 Architecture of the positioning system ...........................................................................25 Figure 13 Distribution of accurate time ..........................................................................................27 Figure 14 LDM Architecture (from [36]) .......................................................................................28 Figure 15 Conceptual LDM scheme (from [34]) ............................................................................29 Figure 16 LDM Object Model ........................................................................................................30 Figure 17 Level of detail in static maps ..........................................................................................34 Figure 18 SAFESPOT Router.........................................................................................................35 Figure 19 VANET functional components (from D3.3.4) ..............................................................36 Figure 20 Generic Message Format ................................................................................................37 Figure 22 Probability of Reception (from [31], [32]) .....................................................................39 Figure 23 Geo-Address ⇔ Destination Area ⇔ Relevance Function ............................................40 Figure 24 Ellipse as Geo-Address...................................................................................................41 Figure 25 Enhanced Destination Area ............................................................................................43 Figure 26 Geo-Anycast, Geo-Unicast .............................................................................................45 Figure 27 PG-LDM architecture .....................................................................................................56 Figure 28 OpenJump visualisation of the Orbassano Test Track....................................................57 Figure 29 ADASRP server architecture..........................................................................................58 Figure 30 Visualisation of l-tolerance=di –transmission range.......................................................61 Figure 31 RF positioning system architecture.................................................................................62 Figure 32 Transmission pattern in a system including four IPUs ...................................................62

List of Tables Table 1 Guide to LDM data model (from [35]) ..........................................................................31 Table 2 Basic Parameter of the geo-address ................................................................................42 Table 3 VANET test activities.....................................................................................................49 Table 4 Cooperative Awareness Message (from [20]) ................................................................59




EXECUTIVE SUMMARY SAFESPOT contributed to the harmonized communication architecture in ETSI TC ITS and COMeSafety with a special focus on safety requirements.

The Local Dynamic Map (LDM) that represents the vehicles surrounding is the key element of the SAFESPOT architecture. It contains static (e. g. map data) and dynamic objects (e. g. vehicles) as well as services to search relate and perform spatial operation on all objects.

Although the LDM is not directly part of the communication architecture its influence on what is communicated is tremendous. It stimulates the introduction of the communication paradigms (push principle) and the Message Manager. As a consequence the Cooperative Awareness Message has been defined that can be regarded as the default output of the Message Manager.

On the other side the Positioning of the ego vehicle is an example for data fusion (object refinement) and reliability management. Communicating aggregated data (objects of the LDM, after object/situation data fusion) minimizes the needed communication bandwidth thus supporting the robustness and availability of the vehicular ad hoc network (VANET).

The Vehicular Ad-Hoc Network (VANET) is in the main focus of the standardization at ETSI TC ITS and the Car-to-Car Communication Consortium. LDM, Positioning and VANET are handled inside SAFESPOT’s subproject SINTECH (SAFESPOT INnovative TECHnologies).

The SAFESPOT / SINTECH architecture is harmonized with the European ITS communication architecture at the time of writing. The geocast functionalities of SAFESPOT can be used to overcome the limited direct communication range.

The key concepts as described in this report emphasizes that it is necessary to consider the whole chain of data flow: From sensor data (GNSS) via data fusion (EGO-POSITION) to objects (EGO-Vehicle), central storage (LDM), scenario detection (Application), selection of information to transmit (Message Manager) and the transmission itself (VANET). At the receiving station the received information is inserted via data fusion (OTHER-VEHICLES) into the central storage (LDM).

This document includes material from other SAFESPOT deliverables, mainly from the subproject SINTECH. But the SINTECH concepts are deeply integrated into the SAFESPOT architecture. Therefore this document also refers to the core architecture subproject SCORE and the other SAFESPOT subprojects.




1. Introduction SAFESPOT is working to design cooperative systems for road safety based vehicle to vehicle (V2V) and vehicle to infrastructure (V2I) communication. The main objective of SAFESPOT is to prevent road accidents by developing a SAFETY MARGIN ASSISTANT.

In SAFESPOT the subproject SINTECH developed innovative technologies for cooperative road safety systems in three fields:

• Positioning : As the knowledge of the exact current position of a vehicle is crucial for any safety application, much effort is spend on the development of accurate and reliable positioning technologies which enable vehicle localization in highway, rural, and urban environments.

Figure 1 EGO-Positioning

• Local Dynamic Map (LDM) For the representation of the vehicles surrounding, local dynamic maps (LDM) are developed which provide higher accuracy and an enhanced set of features, containing also dynamic objects as well as services to search, relate and perform spatial operation on all objects.

.

Figure 2 LDM

• Vehicular ad hoc Network (VANET) The core of cooperative systems is the communication between vehicles (V2V) and between vehicles and infrastructure (V2I). For that, fast and reliable routing algorithms for vehicular ad-hoc networks (VANET) are investigated.




Figure 3 VANET

1.1. Contribution to the SAFESPOT Objectives The innovative technologies of SINTECH build the core of the SAFESPOT architecture which has been designed to fulfill the requirements of safety applications.

The SAFESPOT architecture (Figure 8) fits into the European ITS architecture that is developed as part of the European Commission’s Intelligent Car Intitiative i2010 ([27]). A big step forward has been the allocation of a 30 MHz frequency band in the 5.9 GHz range for safety applications all over Europe ([24]).

The European ITS communication architecture currently is at standardization at ETSI TC ITS ([28]).The work at ETSI depends on active contributions from many partners and the European projects like COMeSafety, SAFESPOT, CVIS etc.

This public report describes SAFESPOT’s key concept of the architecture and SINTECH’s innovative technologies that are considered to be relevant for standardization. It is intended as an input document to ETSI TC ITS for further exploitation.

1.2. General Methodology SAFESPOT started with the collection of user needs and (safety) requirements from user perspective in an top-down approach. In parallel the technological subprojects draw the attention to technological constraints and requirements as bottom-up approach. Then the consolidation of user needs and requirements ([1], [2]) leads to the SAFESPOT architecture ([17]) that has been the basis for the specifications of the innovative technologies Positioning, LDM and VANET.

These technologies play a central role and act as enabling factors for the safety applications. In SAFESPOT the safety applications are bundled to the Safety Marging Assistant (SMA).




Figure 4 Exploitation and Standardization

The exploitation of the results of SAFESPOT are two-folded:

• The safety applications (SMA) show how the SAFESPOT architecture can be used to efficiently integrate safety functionalities. The SMA will be demonstrated at the test sites and are prepared to show the capabilities in FOTs.

• The results are input to the standardization at ETSI TC ITS and the C2C-CC and they contribute to the European harmonization process for safety applications in cooperative systems.

This report recalls SINTECH’s contribution to the architecture ([17], [22]). It summarizes the key concepts of the innovative technologies. Therefore this document supports the exploitation of the results in the standardization process at ETSI TC ITS and in future European projects.

1.3. Deliverable structure This document is structured as follows:

In the following chap.2 we summarize SAFESPOT’s architecture especially the relation to the European ITS communication architecture, the communication paradigm and the central role of the LDM.

In chap. 3 SAFESPOT’s Positioning concept is presented that relies on an efficient use and combination of the results of different positioning sensors and the calculation of trajectories for the own vehicle.

In chap. 4 the concept of the Local Dynamic Map is described. The LDM is a central data store that contains all relevant objects in the vicinity of the station. The LDM contains a consistent object model of the station’s environment including static and dynamic objects that are geo-referenced to a static map. Further, it is a spatial database server providing functions to search, relate and perform spatial operation on all stored objects.

In chap. 5 SAFESPOT’s approach for a vehicular ad-hoc network is presented. This has been harmonized as far as possible with the C2C-CC approach, the COMeSafety architecture and the ongoing standardization at ETSI TC ITS.

Technology Constaints

SAFESPOT Architecture

VANET

LDM

Positioning Standardization European ITS Architecture

User Needs SAFESPOT Implementation Exploitation

Safety Requirements

Safety Applications

SMA




Some remarks on testing and transversal topics like security and multi channel operation conclude this report.

2. Architecture

2.1. European ITS Communication Architecture

2.1.1. Frequency Allocation

ECC Decision

The ECC Decision [24] of March 14, 2008 on the harmonised use of the 5875-5925 MHz frequency band for Intelligent Transport Systems (ITS) deals with a frequency band of 50 MHz that is designated for safety applications.

The CEPT/ECC compatibility studies addressed in ECC Report 101 [25] concludes that:

• Between 5875 MHz and 5905 MHz ITS will not suffer from excessive interference resulting from other systems/services ⇒ channels CCH, SCH1, SCH2 in Figure 5.

• Between 5875 MHz and 5925 MHz, ITS is compatible with all other services providing that their unwanted emissions levels are less than -55 dBm/MHz e.i.r.p. below 5850 MHz, less than -65 dBm/MHz e.i.r.p. below 5815 MHz and are less than -65 dBm/MHz e.i.r.p. above 5925 MHz. ⇒ red curve in Figure 5, called Transmitter Unwanted Emission (TUE) Limits.

Figure 5 European Frequency Allocation

SCH3

SCH1

SCH2

CCH

ACI Limits

TUE Limits




In Figure 5 the current proposal at ETSI TC ITS (work item DTS/ITS-0040016) for Harmonised Channel Specifications for Intelligent Transport Systems operating in the 5 GHz range is shown.

Within the frequency band 5875 MHz and 5905 MHz the control channel CCH and the first service channel SCH1 are shown with higher power spectral density. This means that these channels have additional protection from adjacent channel interference.

Channel Usage

The European frequency allocation has been adopted by SAFESPOT.

Figure 6 Channel Definitions (from D3.4.3, [8])

Furthermore (in [8]) the following channel usage scheme is proposed by SAFESPOT:

• CCH: optimized for low latency o Network layer beacons o 1-hop broadcast high priority safety messages o 1st hop of high priority Multihop/Geocast Messages

• SCH1: optimized for high throughput o Safety Messages o Multihop Messages (≥ 2nd hop) o Geocast Messages (≥ 2nd hop)

• SCH2: optimized for peer-to-peer communication o reserved for short distance peer-to-peer communication at

reduced power level (currently unused in SAFESPOT)

This proposal is still in discussion at ETSI TC ITS (work item DTS/ITS-0040016). SAFESPOT / SINTECH assumes an introduction strategy using the following principles: Phase 1: Single receiver

When the number of equipped vehicles is low, the stations may use the CCH for all messages, given that the observed channel load is below a given threshold.

Phase 2: Mixed single/dual receiver1 When the number of equipped vehicles exceeds a given number (at some point in time), newly equipped vehicles will redirect multihop and geocast messages and messages of lower priority to SCH1. The older stations will continue using CCH for forwarding.

1 The term dual receiver is used in the sense that the stations permanently listen to CCH and SCH1 in parallel. This can also be achieved with a multi channel broadband receiver.




Phase 3: Multi channel receiver With only two receivers it is difficult to operate the SCH2. Therefore finally it is assumed that a multi channel receiver is used, implemented e.g. by a broadband receiver where all required channels are digital extracted from the broadband receive signal.

Phase 4: Multi channel receiver only Finally all stations that are not equipped with dual receivers stop forwarding messages on the CCH.

Currently all SAFESPOT messages are sent on the control channel (Phase 1). This is done for the following reasons:

• lack of dual receivers with sufficient ACI rejection;

• compliance with CVIS that only listens to the CCH;

• introduction strategy.

Latest at Phase 2 powerful decentralized congestion control mechanisms must be in operation. In chap. 5.3 the SAFESPOT SINTECH approach for such algorithms is summarized. This is still a research topic and under discussion at ETSI TC ITS (e.g. work item DTS/ITS-0040014).

2.1.2. COMeSafety and ETSI TC ITS

At ETSI TC IT’S (WG2 meeting, July 2008, document) the ITS station reference architecture (Figure 7) has been developed with contributions from SAFESPOT and CVIS partners.

The communication architecture has been adopted and further developed by COMeSafety. The COMeSafety European ITS Communication Architecture document ([22]) contains a comprehensive description of the architecture.




Figure 7 ITS Station Reference Architecture

The scope of an ITS station is much broader than what is needed for safety applications. It also includes other applications and other media such as WiFi (Hotspot communication). The SAFESPOT system can be regarded as a special implementation of the ITS Station Reference architecture with a strong focus on safety requirements ([1]). The colored bordered blocks in Figure 7 highlight the SAFESPOT contributions that corresponds to the SAFESPOT architecture (chap. 2.2).

2.1.3. SAFESPOT results and EC mandate M/453

Meanwhile the European Commission has issued a Standardisation Mandate (EC mandate M/453) on cooperative ITS 6 October 2009. The Mandate is an important element in the European Commission ITS action plan and is a strong political support to the ITS standardisation work with requirements to ETSI and CEN/CENELEC to produce a minimum set of

Facilities

Station-ExternalInterfaces

MI-

SA

P

IN-SAP

Man

agem

ent I

nfor

mat

ion

Bas

e (M

IB)

Station-InternalInterfaces

Cong-estion

Control

IN-SAP

MN

-SA

P

Networking & Transport

Access Technologies (PHY&DLL)

...IPv6 +Mobility

Extensions

NF-SAP

Geo-Routing

MI-

SA

PM

N-S

AP

MF

-SA

P

Man

agem

ent

Application Support

NF-SAP

MF

-SA

P

Other protocols

e.g.GPS

e.g.2G/3G/...

e.g.BlueTooth

e.g.Ethernet

e.g.5.9GHz

Sec

urity

SI-

SA

P

SI-

SA

P

SN

-SA

P

SN

-SA

P

SF

-SA

P

SF

-SA

P

Sec

urity

Info

rmat

ion

Bas

e(I

dent

ity a

nd C

ertif

icat

e M

anag

men

t)Session Support

SM-SAP

ITS Transport TCP/UDP

e.g.WiFi

Information Support

ApplicationsTraffic

EfficiencyRoadSafety

OtherApplications

FA-SAP

SA

-SA

P

SA

-SA

P

MA

-SA

P

MA

-SA

PFA-SAP

SM-SAP

Bordered blocks: SAFESPOT contributions




standards in the field of cooperative systems to ensure interoperability for vehicle to vehicle communications (V2V), for vehicle to infrastructure communications (V2I) and for communications between infrastructure operators. The standardisation activities should be divided into communication, information and security standards.

The Mandate requires EN standards (European Norm based on national votes) but also related technical specifications and Reports to cover also test specifications for the standards to be developed. Special focus on the EC Decision for the 5.9 GHz spectrum for ITS safety related applications is underlined in the Mandate. CEN and ETSI have formally accepted the Mandate. CEN and ETSI will develop the standards (EN) and technical specifications and guidelines requested within the timescale required in the Mandate. CEN and ETSI have agreed to jointly develop the 1st phase of the Mandate report including a work program, a list of “minimum set of standards” for interoperability and a roadmap for the execution of the Mandate with proposed timelines and milestones. SAFESPOT contributed to the development of the European standardization at ETSI that now are part of the EC mandate. Meanwhile the following ETSI standardization documents have been developed in ETSI using (partly) the concepts of SAFESPOT (status April 2010):

• European profile standard for the physical and medium access control layer of Intelligent Transport Systems operating in the 5 GHz frequency band. ETSI ES 202 663 V1.1.0 (2010-01) − published

• Communications Architecture. Draft ETSI EN 302 665 V1.0.0 (2010-03) − public enquiry

• Transmitter Power Control Mechanism for Intelligent Transport Systems operating in the 5 GHz range. Draft ETSI TS 102 687V<0.0.6> (2009-09) − draft, STF 395

• Specialist Task Force on Local Dynamic Map standardization scoping and classification/management of applications. SA/ETSI/ENTR/000/2009-13− started April 2010, STF 404

• Vehicular Communications; Basic Set of Applications; Part 2: Specification of Cooperative Awareness Basic Service . Draft ETSI TS 102 637-2 V<1.0.4> (2010-03) − draft, AbC

• Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 3: Specifications of Decentralized Environmental Notification Basic Service. Draft ETSI TS 102 637-3 V<2.0.9> (2010-03) − draft, AbC

• Intelligent Transportation Systems (ITS); Vehicular Communications; Part 4: Geographical Addressing and Forwarding for Point-to-Point and Point-to-Multipoint Communications; Sub-part 1: Media-Independent Functionality Draft ETSI TS 102 636-4-1 V0.0.5 (2010-01) − draft




Furthermore the minimum set of standards as agreed between CEN and ETSI contains (among others) the “Common data dictionary” where the LDM data model is valuable input.

2.2. SAFESPOT General Architecture The SAFESPOT general architecture (D7.3.1,[17], Figure 8) has been established in April 2007 during a SP7-SCORE meeting in Guyancourt. It has been the guideline for the implementation of the SAFESPOT and SINTECH modules.

Data Processing / Fusion

Message Generation Message Router

Message Stack

This Node's Application #1

This Node's Application #N

Application Coordination

External Application, e.g.

CVIS

VANET Transmitter

VANET Receiver

Actuator, HMI, VMS, ...

LDM

This Vehicle /Infrastructure Node's

Sensing & Data Sources

common LDMev aluation, for

all SFapplications

contextrelev ancechecking

relevancechecking, e.g.position based

SP1/2

SP3

SP4/5

Q-API

T-API

Q-API

Q-API

messages relevant to this node

messagesnotrelevantfor thisnode

Q-API

determinesat designtime byrules

Figure 8 SAFESPOT general architecture (from D7.3.1 , Fig. 6)

The SAFESPOT general architecture highlights fundamental SAFESPOT architectural decisions:

• LDM - Local Dynamic Map There is a need for a central data store (LDM, chap. 4). The LDM is part of the facilities layer of an ITS station (Figure 7). The LDM also provides services to search relate and perform spatial operation on all objects.

• LDM Update Inserting, deleting and modifying the objects in the LDM (via T-API) is only possible from the data processing / data fusion block of the technological platforms (SP1-SAFEPROBE, SP2-INFRASENSE).

• Incoming data from sensors and VANET must be verified and processed by the data processing / fusion block before entering the LDM.




• No direct access to sensors from applications The node’s applications are solely based on the contents of the LDM (Q-API).

• The applications are split into two parts. Both parts perform a situation analysis based on the LDM contents, but with different focus:

o Node’s application for HMI, considering what is visible in the own HMI (SP4/SP5).

o Node’s Message Generation (Message Manager), considering what is communicated to other nodes (chap. 2.4) and considering congestion control (chap. 5.3).

• Message Router The message router provides the functionalities to efficiently distribute the information (georouting, chap. 5.2). It considers the congestion control policies.

• External Application External applications are supported. They may access the LDM, but all input to the LDM must go through the data processing / data fusion block.

The SAFESPOT architecture is the result of the safety requirements (e.g. as collected in [1]). It has been derived based on the following facts and requirements:

• The communication channel capacity is limited and packet losses occur if the channel load is high.

• High priority messages should be transmitted with low delay.

• The importance of a message depends of the situation / scenario at the receiver. Even an emergency message (emergency braking) received by many vehicles is only of high relevance for a few vehicles (the vehicle behind).

2.3. Communication Paradigm

2.3.1. Cooperative Awareness

SAFESPOT adopted and further developed (together with the C2C-CC) consortium the concept of the Cooperative Awareness Message (CAM, chap. 8.3). The CAM is used to establish Cooperative Awareness, i.e. the vehicles and RSUs know about other vehicles and RSUs in communication range.

The CAM has been designed to support a variety of applications. In fact many applications can directly use the contents of the CAM and build their HMI based on the CAM only without the necessity to transmit extra messages. The default rate of the CAM is currently configured to 2 Hz. It can be decreased by the congestion control functions (chap. 5.3).




SAFESPOT’s system monitor called ESPOSYTOR ([10]) is an example for an application that does not transmit additional messages. ESPOSYTOR monitors vehicles, detected objects and RSUs in the neighbourhood of the ego vehicle, using the LDM dynamic data.

The bird view (Figure 9) is mainly built from the received CAM messages. According SAFESPOT’s architecture the CAM messages are used to update the neighbour table of the vehicles / stations in the LDM. Then this table is visualized by ESPOSYTOR. The SAFESPOT’s LDM may also contain information about other road users and non-equipped vehicles. These objects could be detected by other means (or stations), e.g. radar, camera etc. and communicated to other vehicles.

Figure 9 SAFESPOT system monitor ESPOSYTOR (bird vi ew)

The CAM is under standardization at ETSI TC ITS (work item DTS/ITS-0010002-2) as part of the Facilities layer of the ITS Station (Figure 7).

2.3.2. The push principle

SAFESPOT decided to use the push principle for communications. After analysing the current situation by evaluating the LDM contents the stations decides on the information that might be useful for other vehicles.

This information is pro actively distributed to the other vehicles in case the relevance of that information is high enough (chap. 5.2).

ITS Stations in the neighbourhood of the ego vehicles (red) are shown. ESPOSYTOR extracts the information from the LDM. Attributes of the objects can be displayed e.g. RSU (blue), direct communication range (green), non-equipped (black) etc.

The status of the ego vehicles is available in the LDM and it is displayed on ESPOSYTOR’s main page.




2.3.3. No query of raw sensor data

The push principle also means that a direct query of raw sensor data is not foreseen in SAFESPOT.

The applications of the receiving stations cannot command a higher transmission rate for some information or request a higher precision.

Instead it is assumed that the vehicles already do their best to transmit all relevant information following the policies of the system.

2.3.4. Timing of Messages

The push principle also means that the applications only have a limited influence on the exact timing of a message. Only emergency messages are sent nearly immediately without further delay.

The other information snippets have to wait until they enter a generated message and then the message is sent according the channel access policies. This may result in delays of the order of several tens or hundreds of milliseconds, because the congestion control might require a minimum time interval between subsequent transmissions.

Obviously some information might be outdated after that time interval. Therefore the SAFESPOT router is capable either to directly send the (static) payload or – if it is requested by the applications – to fill the content of the payload dynamically just before transmitting with updated data from the LDM. Otherwise a message that is delayed by the congestion control would contain old values. This update service is very useful for those vehicle physical parameters that are changing continuously, e.g. position and speed.

The described timing of the message is valid for all recurrent safety messages e.g. a work zone warning.

2.3.5. Emergency Messages

Emergency information, e.g. emergency braking, have the highest available priority. These messages are broadcast without further delay. Such messages are rare events and their influence on channel congestion is negligible especially because they are only transmitted once2.

For that reason transient emergency messages are ignored by the congestion control algorithm. They do not have to wait a predefined time interval after the end of the last transmission. But they have to go through the standard IEEE 802.11 channel access scheme (CSMA/CA).

It has been shown in [26] that the delay caused by CSMA/CA is in the order of a few milliseconds (e.g. < 2 ms) in case that the congestion control keeps the channel load below a given threshold (e.g. 25 % on the CCH).

2 Emergency messages may also be repeated (e.g. transmitted twice) to increase the probability of reception.




2.4. Message Manager In Figure 10 the concept of the message generation is displayed. The cooperative part of the applications uses the VANET functionalities to distribute the information that is recognised as most valuable for other SAFESPOT nodes, i.e. other vehicles or RSUs. The HMI part of the applications expects information from other vehicles inside the LDM. Logically this requires that the cooperative part of the applications transmits the corresponding information of the own (EGO) vehicle.

Figure 10 SAFESPOT’s Cooperative Engine

Normally there are many applications running in parallel and all have to transmit their specific pieces of information. The task of the message generation is to structure the messages that are transmitted on the communication channel. Due to the restricted channel capacity and the channel access policies the message generation will order the information pieces and delete duplicates. Furthermore the appropriate communication channel is selected.

The ordering of the messages is based on priorities. An application, that throws a piece of information into the message generation process, is characterized by an application class that translates to a priority value. With this mechanism it is guaranteed that emergency notifications are sent out nearly immediately.

For a proper functioning of the VANET network layer beacons are used. It has been recognised that the contents of the beacons are a subset of the CAM. Therefore there are several possible views:

Congestion Control

Applications

Map fromprovider

Landmarks for referencing

TreeTree

Com. nodes,fusion result

Temporaryregional info !

AccidentAccident

FogFog

CongestionCongestion

EgoVehicle

EgoVehicle

Road side unit

Road side unit

VehiclesVehicles

Map fromproviderMap fromprovider

Landmarks for referencing

TreeTree

Com. nodes,fusion result

Temporaryregional info !!

AccidentAccident

FogFog

CongestionCongestion

EgoVehicle

EgoVehicle

Road side unit

Road side unit

VehiclesVehicles

Cooperative Part speed

size

position

emergency

emergency

Network Layer Beacon id position speed timestamp

Message Generation

light status

acceleration

friction

work zone warning

speed

Local Dynamic Map

Sensors

time

beacon interval

HMI

receive

transmit

piggybacked information




• The CAM messages are equivalent to network layer beacons but with piggybacked information.

• The CAM messages replace the network layer beacons. The contents is determined by the cooperative part of the applications and the timing is controlled by the message manager and especially the congestion control functions.

• The CAM message is the default output message of the message manager.

It is shown in Figure 10 that information can be piggybacked to the network layer beacons to form the CAM message. For this purpose the CAM message (chap. 8.3) contains mandatory fields (Header), station dependant fields (Vehicle/RSU Payload) and a taggedList to include other data (e.g. workzone warnings).

Due to the different roles of SAFESPOT stations – vehicle or RSU – SAFESPOT proposes to use two different CAM messages (chap. 8.3):

• Vehicles: Header + VehicleBeaconPayload;

• RSUs: Header + RsuBeaconPayload.

These are the default output messages of the message manager.

2.5. Local Dynamic Map and Data Fusion In SAFESPOT’s architecture the LDM acts as a central data store. But it is more than that, it links the applications, sensors and the scenarios. This is done by supporting Data Fusion in close cooperation with the in-vehicle platform (SAFEPROBE, [18]) and the infrastructure platform (INFRASENS, [19]).

SAFESPOT adopted the JDL data fusion model as shown in Figure 11.

• GPS Signals• Proprioceptive

Sensors• Exteroceptive

Sensors• Distributed Sensing

V2V & V2I•• A priori InformationA priori Information

HumanComputer Interaction

Level 0ProcessingSub-object DataAssociation &

Estimation

Level 1Processing

ObjectRefinement

Level 2Processing

SituationRefinement

Level 3Processing

ImpactAssessment

Level 4Processing

ProcessRefinement

Data BaseManagement System

SupportDatabase

FusionDatabase

DATA FUSION DOMAINDATA FUSION DOMAIN

Figure 11 JDL DF functional model (from D1.3.3)

From SAFESPOT architecture it is seen that only the output of the Data Processing / Data Fusion is allowed to write into the LDM. The reason for that is that the LDM should only contain consolidated, non-contradictory objects.




The JDL model divided the data-fusion process into a series of steps, which make up a sort of hierarchy of processing.

• Level 0 – Sub-object Data Association & Estimation It is the features-signals level, namely pixel intensities, range readings, encoder readings, steering wheel angle and so on.

• Level 1 – Object Refinement it deals with entities, e.g. location, track, identity, activity state, etc. Levels 0 and 1 depend only on data generated within the vehicle.

• Level 2 – Situation Refinement It is the entity situation, namely the relationship of the entity with other entities, an aggregation of information, the association of the subject vehicle with the map/map matching. Level 2 is the one where:

o the digital road map information are used and the data from vehicles are included;

o data from the neighbouring vehicles is inserted, together with their position and speeds.

• Level 3 – Impact Assessment It deals with the evaluation of the entity situation with respect to the subject vehicle (threat assessment), it is the understanding of the situation.

• Level 4 – Process Refinement it looks into the effectiveness of the information inferred configures the system so as to enhance output of the different levels. Enhances the level of confidence.

In SAFESPOT the data fusion levels 0…1 are handled by the technological platforms (SAFEPROBE and INFRASENS) and the LDM provides the functionality to insert and modify objects related to level 0…2.

Therefore the LDM contains information from the own sensors, but abstracted from raw sensor data to some aggregated data (e.g. “raining” instead of “wiper switched on”).

The impact assessment (data fusion level 3) is seen as the task of the applications. Here the information generated by data fusion of the own sensors and the information received from other vehicles is evaluated with criteria “relevant for the own station” and “relevant to other stations”.

The LDM supports the impact assessment by providing advanced functionalities (LDM Level2 API) that allows more complex queries to the LDM. This includes geographical queries (give me all objects within a specific region) and specific calculations (trajectory of the ego-vehicle).

In SAFESPOT there is no link back from the applications to the LDM. This is due to the fact that the LDM content is highly dynamic and such a link could cause instabilities. The direct link is substituted by the role of the VANET. Whenever a message is generated this message could be feed back to the




data fusion module which checks if that information can be safely inserted into the LDM.

Furthermore the message manager can be regarded as a specific implementation of the data fusion level 4, process refinement.

2.6. Sensor Abstraction The adoption of the JDL data fusion model leads to an abstraction of the sensor information. This goes in line with the renunciation of queries of raw sensor data (chap. 2.3.3).

An example for that is the positioning (Figure 1). Many sensors and components contribute to the position, e.g. GNSS, inertial sensors, camera, laserscanner, map, communication etc. The sensors are not standardized. They have their specific timings and precisions. Furthermore not all sensors are always available. In SAFESPOT the positioning subsystem is responsible to deliver the most accurate position information at a given time. This is done without a specific reference to a sensor. After object refinement there is no “position from GPS”, “position after map matching” and “position from landmark detection” etc. Instead of the raw sensor information the general attribute POSITION is available for the ego-vehicle together with an estimate of the precision and the time when this information has been valid.

The sensor abstraction hides the specific properties of the sensor. Instead of some artificial sensor output, the aggregated information should be used, whenever appropriate, e.g.

• POSITION now, instead of (last GPS position);

• RAINING, instead of (wiper status ON).




3. Positioning

3.1. Ego-Positioning

The idea of the positioning subsystem is to use a basic position estimator fusing data of a GNSS (Global Navigation Satellite System, e.g. GPS) and data of inertial and vehicle sensors. This position estimate may be improved by enhances positioning technologies, if they are available (Figure 12). In doing so there is always the optimal position estimate available for the ego vehicles, nevertheless the accuracy depends on the technology and its availability.

Figure 12 Architecture of the positioning system

In standard motion models of state estimators like Kalman filters, the vehicle’s dynamic parameters (velocity, acceleration, yaw rate, etc.) might be influenced by the incorporation of position measurements, like obtained from the GNSS or from an enhanced positioning technology. This is a side-effect which is critical for subsequent state evaluation tasks which use this dynamics resp. ego motion information, like manoeuvre prediction. Therefore, the vehicle ego motion is additionally estimated in a parallel filter using only the vehicle sensors as input. This approach produces smooth estimates of vehicle dynamics values.

The output of the positioning system is a state estimate which consists of

• Latitude, • Longitude, • Heading, • Velocity, • Yaw rate, • Acceleration • and significant values of the corresponding covariance matrix.

This state estimate is the result of the data fusion of the GPS/INS solution with the enhanced technology, while velocity, yaw rate, and acceleration are replaced by the values of the ego motion filter. Note that there is no additional map matching in the positioning system, as the parameters of and the




requirements to such algorithms are very application dependent. Anyhow, the enhanced positioning technologies use the map as source for the landmark positions. The sensor raw data input of the enhanced technologies is not transmitted in the in-vehicle network, but the particular position estimates. One exception is the transmission of some satellite raw data, like pseudoranges. This data is also transmitted via the VANET to enable a high accurate relative positioning based just on GNSS data.

3.2. Positioning Components

In Figure 12 the essential positioning components are identified. The basic positioning technologies are assumed to be available in all vehicles. They rely on satellite positioning using GNSS combined with inertial navigation system (INS). The enhanced positioning technologies are divided into landmark based positioning and RF based positioning.

In SAFESPOT the following enhanced positioning technologies were considered (see [8], [12]):

• Landmark based positioning using:

o Camera;

o Laserscanner.

• RF based positioning:

o GNSS-based relative positioning (by exchanging pseudoranges via the VANET);

o UWB system (research topic, see annex, chap. 8.5).

The Positioning Data Fusion in SAFESPOT combines the output of the different positioning sensors to always provide (an d communicate) the best known position of the ego-vehicle. The reliabi lity of the information is also transparent to other stations, because the significant values of the covariance matrix are transmitted as part of th e beacon payload (

Table 4 in the annex, chap. 8.3)

Note: In SAFESPOT the positioning information is referenced to a common digital map, the lowest layer of the LDM (Figure 2). In case that a common map cannot be used (different map versions or maps from different map providers), it is recommended not to communicate map matched positions.

3.3. Trajectories

A state and position estimate is available for the time of query. If this time is not equal to the current time, the state is propagated to the query time using the underlying motion model of the vehicle. By means of this approach it is not




necessary to store positions of the past. Furthermore, future states can be predicted. Anyhow, this works only for a limited interval of time. The position of other vehicles is not done by the positioning subsystem, as it is only responsible for the ego positioning task.

3.4. Time Server

Many applications using C2C and C2I communication include the time dimension into their algorithms. Especially for this cooperative approach it is a crucial factor to have on common and synchronous time base, which is very accurate. Therefore, all timestamps of all messages of the participants refer UTC as time standard. The synchronous time is provided by the GNSS. Its messages include full date and time information. Furthermore, GNSS receivers may provide a PPS signal, which is signalled every ‘start’ of a second, synchronous at all receivers (having a position solution). As the GNSS receivers with the PPS signal are connected via a serial port to the positioning subsystem, they are used to set the local clock according to this data. After setting the time, the positioning subsystem is a high accurate time source and it provides this time to other participants using protocols like NTP (Network Time Protocol, see Figure 13).

Figure 13 Distribution of accurate time

Limited periods of satellite signal outages where no GNSS time source is available, might be bridged using the just the local clock. Furthermore, plausibility checks can be done comparing the local clock with the timestamp of the received packet, where the difference should not exceed a certain processing delay.




4. Local Dynamic Map

4.1. Central Data Store The SAFESPOT architecture relies on a central data store – the LDM – as shown in Figure 8. The LDM holds information about the own station (ego vehicle or ego RSU) and the environment. The information is stored as objects or object attributes as described in chap. 4.2. The information can be categorized in several dimensions:

• rate of change (static, slow changing, dynamic);

• Source of Information (configuration data, own sensor data, learned by communication);

• Aggregation level (raw sensor data, fused data (chap.2.5);

• Type of information (movement, roads and lanes, status).

The information is accessible across hardware boundaries (e.g. in a network of computers) by implementing a client server model based on SQL data base systems. Currently two exemplary LDM implementations are available (annex, chap. 8.2).

Figure 14 LDM Architecture (from [36])

Both implementations use the same interfaces LDM Level1 API and LDM Level2 API as described in chap. 4.3.

LDM Bundle

LDM Level 2 API

LDM Level 1 API Communication Layer

LDM

Service

LDM User Bundle

Network

Database LDM Server




4.2. Object Model The intelligent-vehicle applications can be described as a collection of interacting, highly autonomous, complex dynamical systems, i.e. the individual vehicles (and RSUs). The vehicles implement onboard a wide spectrum of possibly cooperative functionalities. In order for an application to do the right thing it should have a formal representation and understanding of the relevant surrounding world to implement the proper (e.g. efficient, safe) behaviour. SAFESPOT’s Local Dynamic Map forms a key element of the onboard system responsible for representing and maintaining a real-time world model. From the applications’ point of view, the LDM is the model of the world as known by the vehicle: it contains objects characterized by attributes, uncertainties and relevant relationships between objects. The world model in the LDM is created based on high resolution digital maps, sensory inputs and communication (Figure 15). The LDM implements an abstraction layer between the data interpretation and the higher level behavioural functions.

Figure 15 Conceptual LDM scheme (from [34])

The LDM contains the object oriented representation of the world model constructed by the data interpretation system based on static map data, sensory and communication inputs. This representation is an instantiation of an object model. Everything, which should be represented from the real world, is an object in LDM (Figure 16). The WorldObject is the most generic object, every object in LDM extends WorldObject in an indirect way (i.e. an object is either a StaticObject, DynamicObject or CompoundObject).

Object types are defined in an inheritance hierarchy: this way the characterization of the individual types and categorization of the objects can




be easily managed. Furthermore the object inheritance supports easy extendibility with more specialized object types without disturbing the existing object scheme:

Figure 16 LDM Object Model

The LDM objects their attributes and relationships are described in [4], [35]. Basically there are five categories: StaticFeatures, MovingObjects, ConceptualObjects, Relationships and Others as shown in Table 1 below.




Table 1 Guide to LDM data model (from [35])

Staticfeatures Movingobjects Conceptualobjects arealandmarks egomotorvehicle accidenthotspot crossing motorvehicle dynamicblackspot crossingforreferencetracks uo dynamicreferencetrackattributes crossingsignalgroup trailer dynamicroadelementattribute detectionarea dynamicsensorattributes detectionareaforcrossing dynamicsensorstatus junction Relationships dynamictrafficsign linelandmarks alongroadelement dynamictrafficsigninformation pointlandmarks conceptualalongroadelement environmentalevent referencetrack trajectory fcdevent roadelement meteodetection roadintersection Others roadconditionevent sensor gatewaycommunication roadconditionmeasurement sensorfordetectionarea messagebox signalgroupstate signalgroup trafficevent signalgroupforreferencetrack trafficobject trafficsign dynamicreferencetrack trafficsigninformation egorsu rsu

A SAFESPOT system is either configured as StaticObject EgoRSU or as MovingObject EgoMotorVehicle .

Each moving object has a MotionState that describes the current movement of the object with respect to the reference point of the object. As with all physical values, this information is stored as physical quantity, i.e., together with a physical measurement based on sensor data, data fusion or communicated information, an uncertainty measure and a time stamp can be stored.

4.3. Interfaces

4.3.1. T-API, Q-API

SAFESPOT modules access the LDM through a defined interface. The LDM API is divided into two parts:

• Level 1 functions which provide flexible, generic access to the LDM through low-level operations;

• Level 2 functions designed to provide specialised access to the database.

Furthermore the functionality is splitted into writing into the LDM via the T-API (T=Transaction) and querying the contents via the Q-API (Q=Query).




All components of the system may perform queries to the LDM and they will get the information even across hardware boundaries, since the LDM is designed as client-server system.

Only the Data Processing / Data Fusion unit is allowed to write into the LDM. for keeping consistency. With that approach the LDM contains only consolidated, non-contradictory objects.

4.3.2. Level 1 API

The Level 1 API provides a very generic and flexible API that draws on SQL syntax. It essentially maps the query directly (i.e. without syntactic or semantic checking) to an SQL statement that is run on the LDM server. Due to its simplicity, and the fact that both LDM implementations in SAFESPOT utilise an SQL DBMS, it is relatively quick and easy to implement.

A common feature of the Level 1 API is that input and output arguments are provided as strings. This emphasises the flexible nature of these methods. Strings arguments can be used to represent single values or lists of numeric quantities, boolean flags or character strings. From a Level 1 query’s string arguments, the corresponding SQL statement can be formed by concatenating the input string arguments with relevant SQL keywords (possibly with basic string operations to separate list elements). Clearly, without the syntactic or semantic checking of the arguments, this approach is unable to prevent/catch incorrectly formed queries from being made by clients to the LDM server. Therefore, it must be used with care by SAFESPOT modules.

The Level 1 API consists of methods that can be grouped into the following categories:

• data modification: insert, update, delete. These operations modify the contents of the LDM – i.e. they form the T-API.

• attribute recall: query. This generic method provides attribute values stored in the LDM (it is mapped to a SELECT SQL statement).

• spatial feature generation: e.g. intersection, geomUnion, difference, envelope, convexhull, buffer, boundary, centroid. New geometries are generated by these methods based on one or more existing or explicitly defined geometries.

• spatial predicates: e.g. intersects, contains, equals. Spatial tests on the relationships between the geometries of two objects or on the properties of a single geometry.

• spatial metering: e.g. distance, length, area. Metrics of a geometry or between two geometries.

• return value processing: next, previous, first, last, size, value. These functions do not access the LDM, rather they allow the processing of the results of the operations listed above.




• transaction handling: begin, commit, rollback. These functions allow a propose transaction handling to guarantee that all corresponding LDM tables are updated in a consistent way.

As the level 1 API is low-level, in addition to the software functions provided, users should be aware of the object model used by the LDM.

4.3.3. Level 2 API

The level 2 API consists of specialised/predefined queries. Predefined queries consider more specific application needs and terms of performance and comfort.

Whilst the Level 1 API is sufficient to allow full access to the contents of the LDM (with knowledge of the object model), it was deemed desirable to provide an additional group of functions that provided higher level access. The level 2 API methods aim to provide some of the more complicated queries used by clients. A level 2 API may be advantageous when, by exploiting its internal implementation, the LDM may be more efficient at evaluating a query than a series of level 1 queries that then need to be externally processed by the client. By implementing a series of queries internally, the LDM server may be able to reduce overall computation time and also reduce inter-component messaging (i.e. reducing LAN traffic). The cost of this is that computational load is redistributed from the clients (of which there may be many) to the LDM server. This trade-off was carefully considered when deciding which level 2 queries were to be implemented.

With this in mind, at least one of the following criteria needs to be fulfilled to create a predefined query:

• The query is a complex construction that is used many times by several applications &/or functional components.

• The level 1 API does not fulfil processing time requirements and improvements for the LDM implementations are needed.

4.3.4. Notification Mechanism

A notification mechanism is available in the LDM. This allows clients to ask to be notified when a particular condition in the LDM is fulfilled. This fundamentally differs from the other API functions mentioned above, as results are “pushed” from the LDM to the clients, rather than being “pulled”.

Due to the finite resources available on the SAFESPOT platforms, care must be taken to ensure appropriate use of this feature. That is, there must be a positive overall effect on the system from using the notification mechanism. Of course this is difficult to assess since it involves trade-offs between computing resources on the clients’ and LDM server’s computers, LAN bandwidth and the timing requirements of applications. In general, the view was taken that computational load is preferred on the clients’ computers than on the LDM server’s – this is due to the fact that there is only one LDM to service the whole platform, whereas (in most SAFESPOT platforms) there are multiple




PCs hosting all of the LDM clients (e.g. separate VANET, Laserscanner, Positioning, Application PCs).

In light of this, the notification conditions should ideally be:

• simple to assess – thus not imposing too high a load on the LDM server, and

• relatively rare – thus unsuitable for the alternative approach of regular polling (using the level 1 or 2 API).

4.4. Static Maps The LDM is built upon static map data from the map providers. The navigation map is enriched with many additional information, especially lane information and landmarks. This makes it unlikely that standard navigation maps can be used. Therefore SAFESPOT foresees the following procedure:

SAFESPOT is using a static map data of the test sites and all vehicles use the same static map. In field operational tests this can be achieved e.g. by downloading the static map when approaching an intersection or a black spot, i.e. a section of roadway that has been designated as being particularly accident-prone.

The downloading task is out of scope of SAFESPOT, but it can be handled e.g. by combining the SAFESPOT and the CVIS approach using additional communication media, e.g. an UMTS link to a download server or downloading the information from a RSU using standard hotspot communication well before the vehicle enters the intersection or black spot.

Figure 17 Level of detail in static maps




5. Vehicular Ad Hoc Network

5.1. Communication Architecture

5.1.1. SAFESPOT Router

The SAFESPOT Router is responsible for all communication in SAFESPOT. It is designed in order to interact with the vehicle or RSU based applications, the LDM and others SAFESPOT routers.

Figure 18 SAFESPOT Router

The main router characteristics that distinguish it from an ordinary router are periodical beacons, payload update and geocast functionalities

The routers periodically send out network layer beacons. The beacon transmission is functional to the maintenance of the network, due to the mobility of the nodes and therefore it is done automatically, without any request from the applications. A beacon can have additional application data piggy-back. This data is chosen according the requirements of the cooperative awareness message (chap. 5.1.3).

The router is capable either to directly send the (static) payload or – if it is requested by the applications – to fill the content of the payload dynamically just before transmitting with updated data from the LDM. Otherwise a message that is delayed by the congestion control would contain old values. This update service is very useful for those vehicle physical parameters that are changing continuously, e.g. position and speed.

The router support geo-cast functionalities, mainly geo-broadcast, geo-anycast and geo-unicast via multi-hop communication.

5.1.2. Functional Components

The functional components of the SAFESPOT Router are displayed in Figure 19.




NeighborTableVANET Router

GeoAddressing

Geocast

Message Stack

Default Relev ance Function

Stored Geocast

Beaconing

Location Lookup

Single Hop Broadcast/Unicast

CommunicationHardware

Message Generation

LDM

Application Relev ance Function

message check withscenario analysis

Congestion Control

message check withlocation Information

«use»

«use» «use»

GeocastMessages

«flow»

«use»

NewMessages

«flow»

ActualMessage

«flow»

«use»«flow»

«control» «flow»

«use»

Figure 19 VANET functional components (from D3.3.4)

The functional view highlights the following important features:

• Congestion Control Since the communication channel capacity is limited all VANET functionalities are supervised by the congestion control algorithms (chap. 5.3).

• Message Generation If a station intends to transmit, it composes the message in a message generation block. The information is taken from the LDM or it is built by the cooperative part of the applications. Message Generation and Message Stack form the Message Manager. The default output of the Message Generation block is the Cooperative Awareness Message. Normally only a few messages per second will be generated, because with many (N) vehicles in the VANET the station can only transmit for a small fraction of time (1/N).

• Message Stack The message stack serves as an interface between message generation and VANET router. This is necessary because the transmit wishes of the own vehicle compete with transmit wishes that result from advanced geo-routing functionalities (chap. 5.2). The messages in the message stack can be reordered such that the most relevant message is transmitted when the congestion control gives the green flag for transmission.

• Beaconing The beaconing is implemented as part of the VANET router. Beaconing is the periodic transmission of the cooperative awareness message (chap. 5.1.3).




• Neighbour Table The neighbour table contains the header information (network layer beacon information) of the received messages. This is necessary for geocast transmission. The neighbour table in the VANET router is not available to the applications because it is like “raw sensor data”. It contains the sensed stations before data fusion.

• Relevance Checking The default relevance checking uses the header information and the geo-address of the messages only. It is applicable to all packets in the message stack. The application relevance checking may also use information from the LDM.

• Geocast Support The VANET router support geocast functionalities, especially single hop broadcast (default), geo-broadcast, multihop communication (geo-anycast and stored geocast (line forwarding).

5.1.3. Generic Message Format

SAFESPOT defined the generic message format as shown in Figure 20 that should be used for all transmissions on the VANET. The generic message format is made out of three sections:

• The SAFESPOT header It is equivalent to the IEEE802p PHY/MAC header. Currently this is under standardization at ETSI TC ITS([29]).

• Originator Section The originator of a message compiles and transmits the originator section. This is the standard message for single hop broadcast.

• Forwarder Section For geocast transmission the forwarder section is introduced. Forwarders retransmit the originator section but they also append their own section. In case that the forwarder section is already present this is replaced. Geocast transmission also requires that a destination description is available in the originator’s section.

SAFESPOT

Header

Originator

Header

Destination

Description

Originator

Payload

Originator

Security

Forwarder

Header

Forwarder

Payload

Forwarder

Security

Figure 20 Generic Message Format Originator section and forwarder section could be secured separately (e.g. by using certificates and signatures, annex 8.1).

Originator Section Forwarder Section

Yellow: Geocast Section




For single hop messages the Originator Header and the SAFESPOT header are combined to form an extended SAFESPOT header. Header and Payload have fixed fields, that are compiled when the message is generated by the message generation and dynamic fields that are updated just before the message is sent.

5.1.4. Cooperative Awareness Message

The cooperative awareness message is the most prominent example for a single hop message. It is distributed in broadcast mode and evaluated by all receiving stations. SAFESPOT proposes to use different CAM messages dependant on the role of a station, i.e. Vehicle or RSU. In SAFESPOT the CAM is defined as:

MsgBeacon ::= SEQUENCE { header HeaderVI3, payload BeaconPayloadVI, satelliteData SatelliteRawDataInBeacon OPTIONAL /* Ego Satellite Raw Data */

} BeaconPayloadVI ::= CHOICE {

vehicleBeaconPayload VehicleBeaconPayloadVI, rsuBeaconPayload RSUBeaconPayloadVI }

This is displayed in the figure below. A more detailed description is given in chap.8.3. For a comprehensive description see [20].

Figure 21 reveals a specific SAFESPOT property, namely the possibility of direct support of the POSITIONING by communicating raw satellite data (chap. 3.1). This optional satellite data field could also been seen as an optional lengthy field of the vehicle / RSU payload. The satellite data will not be forwarded. The CAM is generated using at least the dynamic fields: position, timestamp and speed. These fields are filled immediately before the message is fed into the MAC queue of the communication hardware. When the CAM message is to be transmitted, the timestamp is set to the now = current time and the position and speed is fetched from the LDM predicted to time instant now4.

3 The suffix VI (Roman numeral) indicates version of beacon 4 Please note that dependant on the positioning subsystem the position measurements normally occur with a different update rate than the CAM. Therefore the last positioning measurement might be outdated. That’s why predictions and trajectories could be used.

Vehicle Payload

or

Ext. SAFESPOT

Header

RSU Payload

Satellite Data

Figure 21 Cooperative Awareness Message




5.2. Geocast Communication

5.2.1. Single Hop Broadcast

A station that transmits a message in broadcast mode does not expect an acknowledgment. In SAFESPOT most messages – and especially the CAM – are transmitted in Single Hop Broadcast mode. This means that only those stations receive the messages that are in direct communication range. The message is not forwarded as in multihop / geocast communications (chap. 5.2.2).

The transmitter has a guess about the actual communication range, but this is a stochastic parameter. The transmitter never knows if the message is really received, since acknowledgements are not used5 due to the architectural decision that other stations should not be queried.

It depends on the actual scenario (e.g. quality of radio link, radio parameters, channel congestion) if a message is received. The probability of reception dependant on the distance between transmitter and receiver is a research topics, although some models are available (e.g. Nakagami model, [30]).

Figure 22 Probability of Reception (from [31], [32] )

In Figure 22 some simulation results for the probability of reception dependant on the communication distance are displayed. More details are given in [32]. Figure 22 and the other results [32] are a clear indication that a data rate of 6 Mbit/s on the physical channel (using 802.11p) is the best choice to be used 5 except for unicast transmissions when using Stored Lineforwarding (chap. 0)

Channel Load ≈ 40 %

CD = Communication Dens ity Detected Packets ≅ 2.82 * CD Channel Load ≈ 2.82 * MsgSize * CD




for distributing safety messages. Obviously a single message (emergency) could be transmitted with 3 Mbit/s that increases the probability of reception for that specific message. But this would also introduce higher interference to all other communications in the VANET, because the message (and interference) duration would be nearly doubled.

Consequently SAFEPOT proposes to use 6 Mbit/s as default data rate for the CCH and the SCH1. The 3 Mbit/s data rate should be reserved for non-recurrent emergency messages only.

5.2.2. Geo-Address

Destination Area

In most cases safety information is relevant inside a geographic region, called destination area. This region might be larger than the communication range. SAFESPOT follows the paradigm of equivalence between Destination Area, Geo-Address and (Default) Relevance Function (chap. 0) as shown in Figure 23.

Figure 23 Geo-Address ⇔⇔⇔⇔ Destination Area ⇔⇔⇔⇔ Relevance Function

The geo-address is specified as part of the Destination Description field of the general message format (Figure 20). It is transmitted over the air. It is possible to derive the shape of the destination area from the geo-address and vice versa. Furthermore a relevance function is defined that structures the inside of the destination area in an analytical manner.

SAFESPOT’s basic approach for a geo-address is shown in Figure 24. A geo-address is specified by the originator point POrig in one focal point of an ellipse and the destination point PDest in the other focal point of this ellipse (Figure 24).

Destination Area

Relevance Function

Geo-Address




Figure 24 Ellipse as Geo-Address

The destination point is given relative to the originator point which is specified as part of the Originator Header information.

The shape of the ellipse is defined by the shape parameter αααα which is defined as large semi axis a normalized to the focal value f:

αααα = a / f with αααα > 1.0

The scaling parameter λλλλ defines a scaled ellipse, i.e. the semi-axis a and b enlarged by the factor λλλλ. The basic ellipse parameters are summarized in Table 2.

POrig

PDest

North

West

East

South

x y

θ νννν

a b r




Table 2 Basic Parameter of the geo-address

Parameter Described by Comment

latitude POrig Originator Point

longitude

Geo

-O

rigin

tOrig Timestamp of P0 t0rig

Information taken from message header

f Focal value of the ellipse

PDest

Destination point

θθθθ Azimuth angle of destination point (νννν = 90° - θ)

tDest Latest time when message must reach the destination point

∆∆∆∆t Valid Time of validity default (0.0)

α Shape parameter

Geo

-Add

ress

Area Ellipse λλλλ Scaling parameter

default (1.0)

∆∆∆∆latitude

Opt

iona

l

∆∆∆∆Tx Offset vector ∆∆∆∆longitude

vector to virtual originator in focal point,

default: (0.0, 0.0)

The destination area should not be confused with the spatial queries (convex hull) of the LDM. These queries are intended for scenario analysis. If a safety information should be distributed inside a (convex) polygon the destination area is selected as the outer ellipse of that polygon.

Please note that according the uncertainty of the communication range it does not make sense to specify the destination area with many details.

Position Relevance Function

The (default) position relevance function structures the inside of the destination area in an analytical manner. The relevance function is defined according the following rules:

• The relevance is zero at the border of the destination area;

• The relevance is positive inside the destination area;

• The relevance is negative outside the destination area.




This behaviour is achieved by deriving the default Position Relevance Function from the canonical form of the ellipse with semi axis a and b as:

ΓEllipse (x,y) = 22

1

−

−b

y

a

x

A second relevance function ΓCircle(x,y) measures the (sqared) distance to the destination point.

ΓCircle(x,y) =

22

1

−

−−r

y

r

fx

It specifies a circle around the destination point with a default radius r = f.

Enhanced Destination Area

Scaled Ellipse

The usage of the scaling parameter λλλλ enables modifications for the destination area, e. g. the definition of enlarged or reduced ellipses as shown in Figure 25, or the specification of a circle with radius λλλλ⋅⋅⋅⋅f, specifying a near destination property.

Figure 25 Enhanced Destination Area

General Circle The circle relevance function can also be used with the setting αααα = −−−−(f+r)/f. In this case the sign of αααα specifies if the destination area is a basic ellipse (αααα > 1) or a circle around the destination point (αααα < −−−−1).

Scaled Ellipses

Destination Area

Tx’ Rx

Near Destination

λ<1

λ>1

Tx

Offset Vector ∆∆∆∆Tx

f




Offset vector An optional offset vector can be used to point from the true originator to the virtual originator in one focal point of the ellipse.

Equivalent ellipse descriptions There are several possibilities to specify ellipses. In Table 2 the description by focal value f and shape α is used. An equivalent description is e.g. the description by large semi axis a and the eccentricity e=f/a = 1/α.

Furthermore different definitions of the offset vector might be used, e.g. specifying the centre point of the ellipse instead of a focal point (the virtual originator).

Instead of describing offset vector ∆∆∆∆Tx and focal value f absolute positions can be used, although this is not recommended, because this would require more byte for representing the values.

Default values and Constraints

By default the (cooperative part of the) applications specify the destination point relative to the own position. The offset vector is set to zero and the small semi axis is set to the expected single hop communication range cr that could be set by configuration.

If the large semi axis does not exceed the communication range cr, the geocast transmission is transformed to a single hop transmission.

By configuration also the large semi axis or the focal value are limited.

5.2.3. Geocast Functionalities

Geo-Broadcast, Simple Flooding

The basic geo-broadcast mechanism is Simple Flooding. In this case the originator node is located in one focal point of the ellipse of the geo-address. The ellipse is described by specifying the destination point as the other focal point and the shape factor, i.e. the quotient of large semi axes and focal value (Table 2).

The originator of the message generates the geo-address which is equivalent to a destination area. Obviously a geo-broadcast message shall not be generated unless at least one neighbour is within the expected communication distance and inside the destination area.

Receiving nodes outside the destination area discard the message. Receiving nodes inside the destination area behave as forwarders.

If a node receives the message for the first time (normally on the CCH) it checks the position relevance. If the position relevance is negative, the node is outside the destination area and the node discards the message. If the node is inside the destination area, the message is delivered for further processing to the own system, i.e. data fusion and application layers.




Furthermore the message is retransmitted, i.e. the message enters the message stack for retransmission. The message generation procedure replaces the last forwarder information with the information of the own vehicle (EGO) and the message is sent out on the communication channel (normally the SCH1). Obviously the message is only sent if there are other nodes in the neighbour table than originator and last forwarder.

In SAFESPOT also more advanced mechanisms for geo-broadcast have been investigated [6], avoiding the need that all stations inside the destination area retransmit the message.

Multihop, Geo-Anycast, Geo-Unicast

Geo-anycast and geo-unicast are also known as multihop communication schemes. In contrast to geo-broadcast, the stations inside the destination area only retransmit if they are directly addressed. The current forwarding node selects the next forwarder that is best located with respect to the destination point. For that purpose the circle relevance function can be used (chap. 0).

The message is directly forwarded in Unicast6 mode to the selected node. Unicast has the advantage that no message duplication occurs. Furthermore an acknowledgment could be configured.

Figure 26 Geo-Anycast, Geo-Unicast

In Figure 26 the originator specifies the geo-address (the ellipse) and the near destination circle around the destination point (e.g. using the scaling parameter λ).

The forwarders for multihop communications are selected from all nodes in the destination area. The geo-anycast communication stops if the message reaches the first node in the near destination range (node 4 in Figure 26).

6 Unicast can be realised by directly using the MAC address of the next forwarder instead of using the broadcast MAC address. MAC layer repetitions should not be used, acknowledgements are optional, but shall be part of the congestion control.

1st Hop

Originator Sender EGO-Vehicle Receiver Destination Node Previous Current Next Node Forwarder Forwarder Forwarder

1

2

30

5 4

Near Destination

Destination Area




Geo-unicast is an extension to geo-anycast. Geo-unicast stops if the destination node is reached that is specified as part of the destination description of the general message format.

The selection of the forwarders is part of the routing algorithm, e.g. the movement aware routing as described in chap. 0 and annex 8.4.

Receiving nodes check if they have the destination node (node 5 in Figure 26) in their neighbour tables. In that case the message is directly forwarded to the destination node. Otherwise the next forwarder is selected according the rules of geo-anycast.

If the near destination area is reached, the end-node of the geo-anycast communication (node 4 in Figure 26) forward the message to the destination node if this is part of its neighbour table. Otherwise geo-unicast fails.

As indicated in Figure 26 geo-unicast is of special interest if the destination node is a roadside station.

Movement-Aware Routing

As an enhanced routing scheme for geo-anycast and geo-unicast SAFESPOT considers Greedy Perimeter Stateless Routing with Mobile Awareness (GPSR-MA) approach. GPSR-MA extends the set of parameters originally used by GPSR approach with the inclusion speed of the node, and the direction of node’s movement.

The speed is an absolute value measured in m/s, while the movement direction is an absolute angle between node’s movement direction and line connecting it to the destination. Alternatively, speed and direction of movement components can be derived using node’s movement history. This approach does not require reporting speed and direction of movement parameters in routing protocol headers. However, taking into account that the corresponding overhead can be as low as two octets the node’s speed and direction of movement are explicitly reported in the broadcasted beacon frames (e.g. the CAM message).

The GPSR-MA functionality is fully consistent with the original GPSR specification – including the stateless property where every node relies only on local state information associated with its direct neighbours. GPSR-MA enhancements are constituted in two following add-ons: position prediction and routing metric.

The details of the movement-aware routing scheme are given in annex 8.4.

Stored Lineforwarding

Stored Lineforwarding is an extension to geo-unicast or geo-anycast which fails if there is no better located node than the current node. With stored lineforwarding the message is stored inside the current vehicle until an appropriate next forwarder is found.

This property is especially useful in sparse traffic density. When no next forwarder can be found stored lineforwarding is triggered for that message.




Stored lineforwarding performs the following tasks:

• Periodically checks the own position. Stored lineforwarding fails (message dropped) if the node is outside the destination area or if it is in the near destination area and the destination node is still not found.

• Periodically checks the residual lifetime of the message (checking timestamps and parameter ∆∆∆∆t Valid of Table 2). Stored lineforwarding fails if the lifetime has expired and the destination node is still not found.

• Periodically checks new neighbours which are sensed by receiving their CAM. If a new neighbour is in a better position this node is selected as next forwarder and stored lineforwarding proceeds as normal geo-unicast or geo-anycast.

Enhancements for stored lineforwarding are e.g. the consideration of the movement of the nodes. Nodes that are moving towards the destination point are favoured.

Stored Geo-Broadcast

The purpose of stored geo-broadcast is keeping a message alive inside a geographical region. Several methods for stored geo-broadcast have been investigated [6], but still there is no convincing decentralized method that keeps the broadcast storm under control. Therefore a node has to be identified that is responsible for future retransmissions. Obviously the RSUs are the favoured stations for that purpose.

Stored geo-broadcast needs context information. Consequently the retransmissions are under the control of the applications (cooperative part).

This idea has been taken by PRE_DRIVE C2X ([23]) that locates Store & Forward as part of the application layer.

5.2.4. Time Relevance Function

All generated messages have a maximum lifetime. This is specified by the parameter ∆∆∆∆t Valid (time of validity) relative to the timestamp Table 2.

In dense traffic scenario a message travels in a few milliseconds from station to station. Therefore with a (configurable) maximum hop count of e.g. 10 and under normal conditions a message receives the destination in less than one second.

Consequently the time of validity is only essential for Stored Lineforwarding and Stored Geo-Broadcast. These information distribution schemes stop if the residual lifetime has expired.

The other geocast schemes can use the default value ∆∆∆∆t Valid=0, which implies that the forwarding stops if no appropriate next forwarder can be found immediately or a maximum number of hops is reached.




5.3. Congestion Control and Priorities The objective of congestion control is to best exploit the available network resources while preventing sustained overloads of network nodes and links. Appropriate congestion control mechanisms are essential to maintain the efficient operation of a network system. The congestion indicators are the size of the neighbour table, the number of retransmissions "heard", the message transmission delay, the size of the messages stack, etc. Ensuring congestion control within vehicular ad hoc networks should address special challenges and issues, due to the characteristic and specificities of such environments, i.e. high dynamic and mobility of nodes, high rate of topology changes, high variability in nodes density and neighbourhood, broadcast/geocast communication nature …

The conception of a congestion control approach within VANETs should ensure the following objectives, according to the SAFESPOT project. First, the congestion control approach should be dynamically adaptable to the context of VANETs, while taking into account the required QoS metrics (in terms of reliability and delays). In addition, to take into account relay nodes, and in order to manipulate sending queues, congestion control should be a cross-layered hop-by-hop approach. And finally, no additional equipments are required, or bandwidth consumption due to communication overhead could be generated.

We present in the following the basic policies of the congestion control approach within VANETs, considered in the SAFESPOT project:

Priorities assignment

For each message is evaluated a priority. The priority is composed of 2 fields: the first is static, deduced from the application type, and the second is dynamic, obtained from the specific context of the VANET (vehicles density, variance of the mean speed of the neighbourhood,). The dynamic and the static fields are combined to obtain the overall priority indicator.

The dynamic factor takes into account of:

• The node speed, according to the covered zone at each dt. The priority of a message increases when the speed of the sender increases.

• The utility of the sent message, according to the number of its re transmissions in the case of periodic or geocast messages.

• The message size. The priority of a message decreases when its size exceeds a defined threshold.

• The message validity (maximum duration of the message). As for the EDF scheduling approach (Earliest Deadline First), the message whose deadline is earliest, holds the highest priority.

Messages scheduling and transmission

Each node schedules its messages stack, in order to send packets according to their priorities. Moreover, two messages queues are considered, one for each transmission channel (CCH and SCH1). Note that sending higher priorities packets (via the control channel) is pre-emptive, compared to lower




priorities packets via control or service channels. Finally, the maximum duration of a transmission and the maximum number of transmissions per time interval are defined, and could not be exceeded, except by ermergency messages (messages with highest priority) that are emitted on an event basis in single hop mode.

5.4. VANET Router Validation Testing and validation has become a major concern in R&D projects. The consequence is the emergence of many methodological frameworks. A common Verification & Validation process and tools have been defined and agreed as the transversal method to be adopted in all the subprojects of SAFESPOT ([21]). The method follows the ISO 9001 procedures, the system engineering V-Model development process and the experiences gained in PReVAL7, CONVERGE and APROSYS projects.

The VANET Router validation considers the VANET router as the system under development but it must be taken into account that this operates as part of a larger system, the vehicle, which in turn is only one element in a co-operative network of vehicles and infrastructure.

Table 3 illustrates some of the system functionality and the different stages of integration at which test and validation is possible, and appropriate.

Table 3 VANET test activities

Component System n Systems Vehicle n Vehicles

High level applications e.g. Road traffic management

N N N N Y

Co-operative communication e.g. Multi-hop routing

N N Y N Y

Position-based communications e.g. MORA, Geocast

N N - Y Y

Basic communications e.g. Beaconing, Single Hop

N Y Y - -

ESPOSYTOR diagnostics

N N N Y Y Vehicle integration

N N N Y Y Unit tests / Test cases

Y N N N N Static analysis

Y N N N N

Y : Recommended. N : Not applicable/appropriate. - : Possible but not recommended

7 PReVAL was a subproject of the PReVENT Integrated Project funded by the European Commission.




Low-level test and validation activities (highlighted in light blue) can be conducted using standard procedures, such as static code analysis and unit testing. This should logically be done as part of the component development.

Many of the higher-level functions require interactions with other systems, both on and off-board the vehicle. In some cases an equipped vehicle must be tested in a realistic environment (highlighted in yellow). Tests at the n Vehicles level will be expensive and controlling the test conditions will be complex. It is often desirable to test at the earliest available stage (examples are highlighted in bright blue).

Wireless Data Player

Treating the VANET router as a black box can be an effective mechanism for feature validation, benchmarking and stress testing. Tests range from passive monitoring of wireless traffic, to validating functionality such as multi-hop routing and geo-addressing schemes that requires complex interactions with a number of devices.

For development purposes SAFESPOT data players, that emulate on-board message transactions, are provided for many of the system modules. For wireless communications, the data player concept is being extended using customised routers. Transmit power of the wireless data players can be varied to simulate different positions. This enables “n System” scenarios, testing routing algorithms, and congestion control, to be run in a controlled environment. Stress tests with high network loads and/or malformed messages can test the robustness of the system.

This approach can be extended for vehicle level trials. Wireless data players could be used to simulate high traffic densities or safety related events (e.g. hard braking warning), around a moving vehicle. This may play a role in future certification tests.




6. Conclusions SAFESPOT contributed to the harmonized communication architecture in ETSI TC ITS and COMeSafety with a special focus on safety requirements.

The key concepts of SAFESPOT / SINTECH as described in this document enrich the ETSI TC ITS communication architecture with many details. The exploitation of the results supports the standardization at ETSI TC ITS, namely:

• Cooperative Awareness Message (Work item DTS/ITS-0010002-2)

• Local Dynamic Map (Work item DTS/ITS-0010002)

• Geocast functionalities (Work item DTS/ITS-0030002)

• Congestion Control (Work item DTS/ITS-0040014)

• Channel usage scheme (Work item DTS/ITS-0040016)

• Positioning concepts (related to CAM and LDM)




7. References SINTECH Deliverables

[1] D3.2.3 – Consolidation of User Needs and Requirements

[2] D3.3.1 – Mapping Report

[3] D3.3.2 – Specifications Positioning

[4] D3.3.3 – Specifications LDM

[5] D3.3.4 – Specifications VANET

[6] D3.4.1 – Algorithmic and Performance Simulations

[7] D3.4.2 – Implementation Plan

[8] D3.4.3 – Prototypical Implementation

[9] D3.4.4 – ESPOSYTOR Architecture and SW Design

[10] D3.4.5 – ESPOSYTOR Prototypical Implementation

[11] D4.3.5 – Specifications Vehicle Diagnostics and Monitoring (Esposytor)

[12] D3.5.1 – Validation Report for Positioning

[13] D3.5.2 – Validation Report for LDM

[14] D3.5.3 – Validation Report for VANET

[15] D3.5.4 – Key Concepts and Exploitation (this document)

[16] D3.5.5 – ESPOSYTOR Validation Report

Other References

[17] D7.3.1 – Global System Reference Architecture (v1.3)

[18] D1.3.3 – Data-fusion Specifications (PUBLIC)

[19] D2.3.2 –Specifications for Infrastructure based Sensing

[20] SAFESPOT data format and messages. (SAFESPOT document: SF_SP7_Data_format&messages_v2.14.doc)

[21] Functional Non Compliance Management. (SAFESPOT document: SF_NonComplianceManagementTrackingForm_Tutorial.v1.2.doc

[22] COMeSafety European ITS Communication Architecture (v2.0) http://www.comesafety.org

[23] PRE_DRIVE C2X, Deliverable D1.2, Refined Architecture, 2009.

[24] ECC/DEC/(08)01: ECC Decision of 14 March 2008 on the harmonised use of the 5875-5925 MHz frequency band for Intelligent Transport Systems (ITS) .

[25] ECC Report 101 Compatibility Studies in the Band 5855– 5925 MHz between Intelligent Transport Systems (ITS) and other Systems, Bern, February 2007.




[26] Achim Brakemeier. White Paper on Network Design Limits and VANET Performance. ETSI document ITSWG4-05d014, January 2009.

[27] European Commission, Intelligent Car Initiative i2010 http://ec.europa.eu/information_society/activities/intelligentcar/icar/index_en.htm

[28] ETSI – Intelligent Transport Systems http://www.etsi.org/WebSite/technologies/IntelligentTransportSystems.aspx

[29] European profile standard, ETSI document ES 202 663.

[30] Marc Torrent-Moreno, Hannes Hartenstein (University of Karlsruhe), Daniel Jiang (DaimlerChrysler, Palo Alto, USA). Broadcast Reception Rates and Effects of Priority Access in 802.11-Based Vehicular Ad-Hoc Networks. VANET 04, Philadelphia, USA 2004.

[31] Achim Brakemeier, Daimler AG. Harmonised Channel Specifications for ITS (5.9 GHz). Car-2-Car Forum, Dudenhofen, Germany, 2008.

[32] Daniel Jiang, Qi Chen, Luca Delgrossi . Optimal Data Rate Selection for Vehicle SafetyCommunications, Mercedes-Benz R&D North America, Inc., VANET’08, September 15, 2008, San Francisco, California, USA.

[33] SEVECOM Deliverable 2.1, Baseline security specification.

[34] Z. Papp, Member, IEEE, C. Brown, Member, IEEE, and C. Bartels . World Modeling for Cooperative Intelligent Vehicles. IEEE IV 2008, Eindhoven, The Netherlands, June 2008.

[35] LDM data model release 10.0.8, SINTECH LDM specification.

[36] Stéphane Dreher. The Local Dynamic Map from a Map makers point of view. CVIS workshop 10. Dec. Berlin, 2008.




8. Annex

8.1. Security SAFESPOT’s security mechanisms rely on the SEVECOM approach as described by the SEVECOM baseline security architecture document ([33]). SEVECOM implements the security functions as multiple modules that each contribute to a specific security functionality:

• Security System Manager The Security Manager is responsible for overall system organization, instantiation and configuration of components, hooking of the security subsystem into the communication stack, and dispatching of (some) calls between components.

• Identification and Trust Management Module The Identification and Trust Management Module defines components that are responsible for handling identities and credentials, with various operations including provision, renewal, or revocation of credentials.

• Privacy Management Module The Privacy Management Module provides privacy-enabled vehicular communications while still fulfilling necessary secure requirements. It leverages on resolvable pseudonyms (i.e., certified short-term public keys) to achieve a defined level of privacy for individual vehicles and yet allow the identification of valid vehicles and public bodies to resolve pseudonyms to vehicle long-term identities under well-defined conditions. Vehicles are loaded with sets of pseudonyms they can then use for message signing. By switching pseudonyms and using them only for a limited amount of time, privacy attacks are impeded significantly, notably in the presence of an adversary (eavesdropper) that does not cover the entire network area.

• Secure Communication Module The Secure Communication module deals with aspects of assuring security of the communication network. This means that the module takes care of the actual communication processes in order to ensure their reliability. For that, it also utilizes and cooperates with practically all other modules. As components, we distinguish between several, typical types of communication in vehicular networks, which all have particular properties in terms of security. The component descriptions are somehow more generic than the other modules, as parts of these components need to be specifically tailored to the communication stack used.

• In-car Security Module The in-car security module protects the interface of the wireless communication system to the in-car networks. Besides controlling the access to vehicle sensor data and services it also comprises mechanisms to ensure a correct provision of the data and services to the V2V/V2I applications.




• Crypto Support Module The general purpose of the Crypto Support Module is to provide the implementation of the cryptographic operations needed by the applications running on the OBU. The applications can call these cryptographic operations through the APIs provided by the components of the Crypto Support Module.

In SAFESPOT the following security requirements are supported ([1]):

• Firewal l between vehicle / RSU and the SAFESPOT System corresponding to SEVECOM’s In-car security module. It is realised as a vehicle or RSU gateway as part of the in-vehicle (SAFEPROBE) or infrastructure (INFRASENSE) platform.

• Privacy by using pseudorandom temporary vehicle identifier, corresponding to SEVECOM’s Privacy Management Module.

• Checking the authentication and integrity by specifying the security fields in the general message format (Figure 20). This corresponds to SEVECOM’s Secure Communication Module, especially the Secure Beaconing Component.

But in a pure SAFESPOT system not all of SEVECOM’s security concepts can be fully integrated because there is no public key infrastructure and no end-to-end security . It is expected that these functionality can be inherited by integrating SAFESPOT with other communication media (e.g. as provided by CVIS).

Currently SEVECOM’s Identification and Trust Management module is conceptually reduced to pre-stored credentials and keys in SAFESPOT and end-to-end security is seen as a task of the applications.




8.2. LDM Implementations For the representation of the vehicles surrounding, local dynamic maps (LDM) are developed which provide higher accuracy and an enhanced set of features, containing also dynamic objects as well as services to search, relate and perform spatial operation on all objects.

The concept of the LDM is not related to a specific implementation and in fact in SAFESPOT there already exist two implementations ([8]). Both implementations realize the LDM object model (Table 1), the LDM API (Level 1 and Level 2) and the networking capability.

8.2.1. PG-LDM (Bosch / Teleatlas)

The PG-LDM consists of a PostgreSQL database especially for static and dynamic data handling, a non-standard PSF for static map data retrieval and AGORA-C support for CVIS and a Level 1 and Level 2 API which provides suited functionalities for the lookup of geospatial data as well as geospatial analysis. The PG-LDM is implemented under Windows and Linux with a Java and C++ interface.

The PG-LDM is implemented by Bosch and Tele Atlas.

Figure 27 PG-LDM architecture

In CVIS, the PG-LDM bundle is an extension of the Tele Atlas Automotive Research Platform which provides further CVIS related functions for AGORA-C, map matching and routing. The Tele Atlas Automotive Research Platform can be provided under Windows in C++ as well. For all platforms Tele Atlas provides the map data files for PostgreSQL databases and a non-standard PSF.

PostgreSQL is used as the datastore layer of the PG-LDM. PostgreSQL is an open source relational database system available for multiple operating systems, including Windows XP and Linux. It is SQL compliant and offers a stable platform for developing databases. It has obtained a high level of acceptance and a large number of users world-wide. It claims to have high reliability, scalability and speed.




Importantly, the PostGIS add-on provides support for geographic objects following the OpenGIS Simple Feature Specification. PostgreSQL-PostGIS provides an open source spatial database with all that this implies – support for geographic data objects as well as spatial functionality. Considering the spatial context of (almost) all objects in the LDM, this built-in spatial support is seen to be attractive.

As visualization and analysis software, OpenJump has been selected for the PG-LDM. OpenJump is developed within an umbrella project called the JUMP Pilot Project and distributed under the GPL license. It is an open source GIS (geo-information system) software implemented in Java based on JUMP GIS by Vivid Solutions.

Figure 28 OpenJump visualisation of the Orbassano T est Track

8.2.2. NAVTEQ-LDM

As with the PG-LDM, the NAVTEQ LDM client delivery is a single static library file (ldmapi.lib for Windows XP or ldmapi.a for Linux) and associated header files that define the API classes and methods.

However, the Windows based LDM Server is implemented as a component (referred to as a plug-in) of the NAVTEQ ADAS Research Platform (ADASRP). This application platform provides the server with access to both a static map database (in the MMF physical storage format) and an SQLite dynamically updateable embedded database. The LDM Server provides a single interface for accessing data from either of these two data sources, and for writing data to the SQLite database.




Figure 29 ADASRP server architecture

The Linux based LDM Server is a standalone service that provides this same LDM functionality. Both implementations communicate equally with either the Windows or Linux client library.

Neither the SQLite database or the MMF map database contain the full LDM data tables and attributes. Only when accessed via the LDM Server are all attributes visible.Numerous free third party tools are available for inspecting the contents of the SQLite portion of the NAVTEQ LDM database.




8.3. Cooperative Awareness Message The SAFESPOT implementation of the cooperative awar eness message (CAM) uses the formats of

Table 4 (from [20]). The full type delarations (blue italic) are given in [20]. SAFESPOT proposes to use different CAM messages dependant on the role of the ITS Station, mainly:

• Header + VehicleBeaconPayload for a vehicle or

• Header + RSUBeaconPayload for a RSU

Table 4 Cooperative Awareness Message (from [20])

NAME TYPE LENGTH

HeaderVI ::= SEQUENCE { headerVersion INTEGER (0..255) -- 1 byte messageType VanetMessageType, -- 1 byte sequenceNumber INTEGER (0..65535), -- 2 bytes nodeID NodeID -- 8 bytes nodeType NodeType -- 1 byte timestamp VanetTimeStamp -- 6 bytes position Position2D -- 8 bytes positionVariance PositionVariance -- 2 bytes nodeSpeed FilteredSpeed -- 4 bytes txPower TxPower -- 1 byte priority Priority -- 1 byte } -- 35 bytes with byte alignment

VehicleBeaconPayloadVI ::= SEQUENCE {

messageID INTEGER(0.. 65535), -- 2 bytes protocolVersion INTEGER(0..255), -- 1 byte vehicleElevation Elevation -- 2 bytes vehicleType VehicleType -- 1 byte vehicleSize VehicleSize -- 5 bytes longitudinalAcceleration FilteredLongitudinalAcceleration -- 2 bytes yawRate FilteredYawRate -- 2 bytes exteriorLights ExteriorLights -- 1 byte accelerationControl AccelerationControl -- 1 byte covarianceMatrix IncompleteCovarianceMatrix -- 13 bytes numOfItemsInTaggedList INTEGER (0..32), -- 1 byte taggedList BeaconTaggedList OPTIONAL -- variable length }

RSUBeaconPayloadVI ::= SEQUENCE {

messageID INTEGER(0..65535), -- 2 bytes protocolVersion INTEGER(0..255), -- 1 byte nearestRSU NearestRSU -- 32 bytes linkType LinkType -- 1 byte temperature Temperature -- 1 byte visibilityRange VisibilityRange -- 1 byte trafficDensity TrafficDensity -- 3 bytes weather Weather -- 1 bytes positionCovariance PositionCovariance -- 1 byte numOfItemsInTaggedList INTEGER (0..32), -- 1 byte taggedList BeaconTaggedList OPTIONAL -- variable length




}

8.4. Greedy Perimeter Stateless Routing with Mobile Awareness (GPSR-MA)

Position Prediction

As an enhanced routing scheme for geo-anycast and geo-unicast SAFESPOT considers Greedy Perimeter Stateless Routing with Mobile Awareness (GPSR-MA) approach.

As soon as movement speed and direction become available, every node is able to instantaneously update location coordinates of its neighbours without the need for communication. In order to do so each node is provided with a high resolution timer (at msec. level) upon expiration of which it traverses the neighbour node table adjusting neighbours’ positions accounting for the range they moved since the last position update beacon was received from them.

Assuming beaconing interval B implemented with a 1 sec. resolution timers, a node is not able to change its speed and movement direction greatly between beacon updates. As a result, the adjusted positioning information of the neighbours is highly accurate.

Two cases are considered for GPSR-MA operation: when location service may or may not be provided in the VANET. If provided, the destination can be mobile. However, if not provided, information is delivered to vehicles which are currently resided inside a geographical region defined by fixed coordinates.

Metric

The main idea behind GPSR-MA metric is to exploit information about moving directions of neighbouring nodes in order to route the data over an optimal path. VANET hosts are moving in directions that can introduce unpredictable changes in the network topology affecting already established routes and network connectivity in general and therefore exploiting information about the speed and direction of movement increases path robustness.

GPSR-MA metric is designed to favour relatively stable paths and not necessarily those with smaller number of hops. It depends on the speed, on the distance from the destination and on the movement direction (defined as absolute angle from the line connecting the node to destination) in the following way:

)()()(),,( tan θαααθ hdgsfdsm movementcedisspeed ++=

where αspeed, αdistance, αmovement are parameters which allow to give different weight to speed, distance and movement direction and )(),(),( θhdgsf are three suitable functions.




The factor related to speed is defined in such a way to favour the selection of the next forwarding node moving with a speed close to the speed of the current node:

( )

−−= 2

2

2exp)(

σisx

sf

where si is the reference speed of current node i.

Considering the distance from destination, GPSR-MA selects next forwarder located closer to the destination, taking into consideration that the next hop must be within the transmission range and preferably not to close to its perimeter:

))(exp()( lddg −−=

where l = di – transmission range + tolerance, di is the distance of current node i from destination and tolerance is a parameter designed to compensate on signal strength uncertainty at the edge of node’s transmission range.

Figure 30 Visualisation of l-tolerance=di –transmis sion range Focusing on movement direction, GPSR-MA favours nodes moving towards the destination (θ=0):

≥=elsewhere

ifh

)(cos2

0)(

2 θ

πθθ

D

di –transmission range




8.5. UWB positioning Positioning based on radio frequencies is a complete solution, able to deliver information on the vehicle location. Therefore it can fulfil most requirements concerning vehicle positioning identified in SAFESPOT project. The basic architecture of the proposed positioning system is shown in Figure 31. The system consists of:

• A set of IPUs (Infrastructure Positioning Units) mounted on road infrastructure objects,

• The VPUs (Vehicle Positioning Units) mounted in SAFESPOT vehicles.

Figure 31 RF positioning system architecture

All IPUs transmit signals contain unique IPU identifiers. Exemplary transmission schedule is presented in Figure 32. Transmission pattern is repeated periodically. During one period all IPUs emit their signals one after another (there are predefined delays between successive transmissions).

Figure 32 Transmission pattern in a system including four IPU s

The VPU is a receiver able to decode IPU identifiers, measure time delay between successive signals and finally to calculate the position using TDOA




(Time Difference of Arrival) algorithm. Data necessary for position calculation (i.e. transmitter locations, transmission delays) are delivered via VANET. The proposed positioning system solution offers several advantages:

• Due to separation of transmit and receive functions (in fact VPUs are receivers, IPU – transmitters) the equipment is significantly simplified;

• The number of vehicles using the system is not limited ( there is no need for complex system access procedures);

• The system offers high scalability (adding new IPUs is very simple); • The rate of position evaluation can be very high; it mainly depends on

the number of IPUs, length of transmissions and delays between them; • Limiting the VPU role to signal reception increases on-board

electromagnetic compatibility (it does not interfere with other sensitive devices e.g. GPS receiver);

• The implementation of sequential transmissions improves intra-system compatibility; there are no problems with collisions of transmitted packets coming from different transmitters;

• The implementation of sequential transmissions, and low duty transmissions improves overall electromagnetic compatibility;

• IPUs have lower power requirements (they have only to transmit); they can be battery operated or supplied from solar cells.

Disadvantages of proposed solution:

• The transmission of IPU signals should be synchronized, synchronization errors deteriorate positioning accuracy;

• The accuracy of positioning is strongly affected by the number and location of IPUs (the lower distance between transmitters the higher accuracy), so the cost of system implementation becomes an important factor limiting coverage.

Taking into account all pros & cons the proposed RF positioning system idea is an attractive solution. Such systems could be used in places where precise determination of object position is especially important i.e. intersections or places where location with other means is impossible e.g. tunnels. The presented concept of positioning system was successfully tested within the frames of SAFESPOT. A positioning system demonstrator based on UWB technology was developed; its specification can be found in D3.3.2, [3]. The demonstrator is comprised of five IPUs and one VPU operating in 3.4 – 4.8 GHz band. The performed test results proved the system efficiency. According to the test results in D3.5.1 ([12]) the demonstrator is able to calculate 200 positions per second and provides sub-meter accuracy.

SP3 – SINTECH – Innovative Technologies Key Concepts and ... · 1.1 20/04/2010 Chap 2.1.3....

Documents

Transcript of SP3 – SINTECH – Innovative Technologies Key Concepts and ... · 1.1 20/04/2010 Chap 2.1.3....