rsu placement guidelines - intercor · 2020. 4. 7. · rsu placement guidelines | 27 october 2016...

RSU Placement Guidelines

Datum 27-10-2016

Status Final

Colofon

Published by Rijkswaterstaat | Programma's, Projecten en Onderhoud |

Realisatiebureau ITS

Written by MAPtm

Date 27-10-2016

Status Final

Version number 1.0

RSU PLACEMENT GUIDELINES | 27 OCTOBER 2016

Inhoud

1 Introduction—4 1.1 Purpose of this Document—4 1.2 Approach—4 1.3 Assumptions—4 1.4 Document Structure—5

2 Functional perspective—6 2.1 Long-term scenario—6 2.2 Service quality—7 2.3 Dissemination areas—7 2.4 Planned and unplanned events—8

3 RSU perspective—9 3.1 Transmission range—9 3.1.1 Sending range—9 3.1.2 Reception range—9 3.1.3 Unidirectional reception—10 3.2 External factors—10 3.2.1 Surrounding factors—10 3.2.2 Installation factors—10 3.2.3 Technical factors—11 3.3 RSU capacity—11 3.3.1 Channel Load—11

4 Recommendations—13 4.1 Conformance testing—13 4.2 Probe vehicle data—13 4.3 Learn from other domains—13 4.4 Integrate experience from pilot projects and demonstrations—13 4.5 Additional tests—13 4.6 Advance start of broadcasting—14

5 References, Definitions and Abbreviations—15 5.1 References—15 5.2 Sources—15 5.3 Respondents to interviews—15 5.4 Abbreviations—16


Pagina 4 van 16

1 Introduction

1.1 Purpose of this Document

The purpose of this document is to provide guidelines to determine the position of

cooperative roadside ITS stations (Roadside Unit, RSU). These are stations equipped

with ITS-G5 technology to enable wireless exchange of information with ITS-G5

enabled vehicles.

Based on a functional use case perspective and specifications of RSUs, this

document provides insights and guidelines on where an RSU should be placed. As a

result, with the help of this document, it can be determined where to deploy their

C-ITS roadside stations.

1.2 Approach

The content of this document is based on literature review (see sections 6.1 and

6.2) and interviews (see section 6.3 for a list of the respondents). Interviews were

held with experts from roadside unit manufacturers and suppliers, knowledge

centres and Rijkswaterstaat.

To a large extent, the guideline and requirements formulated in this document are

of a functional nature. They do not prescribe the exact position and specifications of

the RSU, but remain on the level of dissemination areas, i.e. areas of the road

network where messages can be received by the potentially targeted vehicles. The

main reasons for not being more precise, are the situation and equipment variables

at play as described in chapter 3. Within the boundaries defined by this guideline, it

is up to, for example, the contractor to choose the most suitable solution, related

equipment type (e.g. antenna type(s)) and exact positions.

The aim of this first version of a placement guideline for RSU is to initiate a

discussion on the subject with a larger community. For that reason, it will be

submitted to the Dutch round table on Architecture and Interoperability. Based on

the outcome of such discussions the document will be adapted and completed

iteratively. Similarly, the lessons learned from on-going and upcoming pilot projects

will be incorporated.

1.3 Assumptions

This document was prepared with the following assumptions and limitations in mind: For now, the purpose of this document is to provide placement guidelines

for day 1 applications. Thus, it focusses on an optimal service level given a

limited number of RSUs (and OBUs). Also, it is therefore accepted C-ITS

equipped vehicles might miss messages due to limited coverage (temporal

and spatial).

For day 1 deployment, without 100% coverage, it is unavoidable that events

may be missed by some vehicles and/or that some vehicles will arrive at an

event position without or with outdated information. This also means that

the information provided by roadside signals may differ from information

available in the vehicle. The guideline is intended for the road network of Rijkswaterstaat: the

highway network.

Rules, statements, and advice should be interpreted as guidelines and not

requirements, unless it is explicitly stated that they are requirements.

Specific situations are always possible in which recommendations do not

hold and a different approach is advisable.


Pagina 5 van 16

Message forwarding is not used. Message forwarding means that ITS

stations can repeat and thus forward a message down- or upstream, also

known as multi-hop. Within the C-ITS community there is a lively debate

whether multi-hop offers an advantage or is a burden to the channel

capacity.

Vehicle ITS stations (Onboard Units, OBUs) can temporarily store incoming

messages and data. Messages may be received some distance upstream of

an event position, while the information can be shown to the driver at a

later point. It is not assumed that, for the extended PVD use case, probe

vehicle data can be stored until the vehicle comes in range of an RSU and

then transmits the PVD packet.

All vehicles must be able to pass a relevant dissemination area to receive

event data (see paragraph “Service quality” in chapter 2).

For day 1, the likelihood of false negatives must be favoured over false

positives (see paragraph “Service quality” in chapter 2).

1.4 Document Structure

The next chapter derives requirements on RSU placement from the functional

perspective of use cases. Thereafter, chapter 2.4 provides information on

specifications of RSUs and external factors which affect the performance of RSUs.

Chapter 4 provides recommendations. Finally, chapter 5 provides an overview of

references, sources, respondents, definitions and abbreviations.


Pagina 6 van 16

2 Functional perspective

The RSU placement guideline has to facilitate day 1 deployment of Road Works

Warning (RWW), Probe Vehicle Data (PVD), In-Vehicle Signage (IVS) and Collision

Risk Warning (CRW). A description of these use cases is given in [1]. While RWW,

IVS and CRW are all I2V based use cases, PVD is V2I centred, but all services are

based on message broadcast which means unidirectional communication. Although

I2V and V2I use cases may pose different requirements on RSU placement, it is for

the time being assumed, and until the requirements of PVD are better understood,

that the RSU placement resulting from the first three use cases will also serve the

purpose of PVD.

RWW, IVS and CRW are all targeted to event positions, being a road work, a road

sign or a hazardous location. In the dictionary of in-vehicle information (IVI) data

structure [2] these are referred to as ‘relevance zone’ which is preceded by a driver

awareness zone and a detection zone. The former describes parts of road network

on which a message is presented to inform drivers about upcoming situations,

whereas the latter describes a part of the road network that is passed by a vehicle

in approach of the relevance zone. Together these zones must ensure a timely

detection of the event and timely informing of the driver. As a general rule, the

more safety-centred a use case is, the higher the requirements on timeliness and

reliability are. Current road signalling guidelines [3] indicate that drivers must first

be informed about events such as road works 1000-500 meters upstream of the

event position. Human machine interface guidelines [4] indicate that in-vehicle

signalling should start at 2000-1400 meters before the event position.

Req.1: V-ITS-S shall receive messages latest 500 meters upstream

of the event position, preferably 2000-1400 meters upstream of the

event position.

It is important to note that these distances are general recommendations for

minimum radio coverage in relation to an event position. From the perspective of

the profile of certain use cases (e.g. RWW) a more elaborate coverage could be

desired. For example, for the RWW use case traces of up to 1.5 km are

recommended. The minimum distance of 500 meters is insufficient to fully utilize

those traces. Similarly, to be able to send updates about the road works, a more

elaborate coverage of the road works area is needed.

Thus, the profiles give the full desired specification, but practical implementation is

dictated by the physical C-ITS infrastructure. The distances mentioned in Req. 1 are

therefore the distances that enable most use cases, be it with a minimum service

level.

2.1 Long-term scenario

On the long-term it is expected that vehicles will continuously interact with other

vehicles and infrastructure. In this scenario, the density of RSUs along highways is

sufficient to support continuous coverage of the radio signal, i.e. continuous

connectivity, with sufficient signal strength and successful transmission ratio (see

chapter 4). RSUs can interact with all vehicles and send information updates

whenever required. For day 1 deployment full coverage is not realistic and the

number of RSUs will be limited to a subset of these. This subset is a set of locations

which ensures the highest attainable service quality at the least investment cost.


Pagina 7 van 16

2.2 Service quality

Compromising the number of RSUs along highways inevitably affects the service

quality in term of availability and reliability of in-car information. RWW, IVS and

CRW all aim to inform drivers about event positions, being a road work location, a

road sign location or a hazardous location. For safety, liability and regulatory

reasons, all C-ITS equipped vehicles that will pass an event position must be able to

obtain associated message(s) timely. In the dictionary of in-vehicle information

(IVI) data structure [2], a dissemination area is defined as part of the road network

where messages can be received by the potentially targeted vehicles. To ensure

such minimum availability of information about event positions and since it is not

known where, over time, event positions will be located, such a dissemination area

must at least be located at each entrance of the highway, i.e. at all on-ramps and

junctions.

Req.2: a dissemination area must be located at each highway on-

ramp and junction.

It is important to note that passing a dissemination area does not guarantee that all

vehicles will receive the necessary messages. Communication failure for reasons like

malfunction, packet loss or occlusion may prevent message reception.

In addition, having dissemination areas only at on-ramps and junctions for day 1

implies that two consecutive dissemination areas may be multiple kilometres apart.

As a consequence, and due to the nature of some use cases, the validity of the

information that is available in the vehicle may expire and therefore not reflect

reality. This may lead to one of three situations: false positives, false negatives or

incorrect information. In case of a false positive the driver is warned about an event

which is not there, whereas in case of a false negative the driver is not warned

about an event which in fact is present. Incorrect information may concern, for

example, the wrong (dynamic) legal speed limit.

For day 1, there are only a few situations in which C-ITS messages are broadcasted.

Most of the time, no messages are received / displayed by C-ITS equipped vehicles

(i.e. not getting a message could be seen as the default situation). Therefore, for

day 1, false negatives are favoured over false positives. In the long term when C-

ITS messages are more common, when making a trade-off, false positives arguably

are less harmful and therefore to be favoured over false negatives, especially when

considering the risk of accidents.

2.3 Dissemination areas

As stated earlier, all vehicles must pass a relevant dissemination area to receive

event data. Consequently, a dissemination area must, at least, be located at each

highway on-ramp and junction. In addition, when on-ramps are far apart, the

service quality can be improved by placing additional RSUs. A suitable interval can

be derived from common practice in roadside signalling or human machine interface

guidelines [3, 4]. As mentioned earlier, events requiring action from the driver

should preferably be announced 2000-1400 meters upstream of the event position.

Considering that OBUs can store relevant information for a short period, three times

this distance seems acceptable for C-ITS equipped vehicles. The factor three is

currently a best guess and should be tested and evaluated in upcoming projects.

One approach to determine the factor is to look at the validityDuration of certain C-

ITS messages (i.e. the duration the message is valid). For example, the maximum

distance should be such that the duration a message is valid is equal to or longer

than the time a vehicle needs to cover that distance during congestion.

Currently, the validityDuration for RWW (DENM) messages is profiled at 720

seconds (i.e. 12 minutes). That duration, when combined with a congested speed of


Pagina 8 van 16

30 km/h, results in a distance of 6 kilometres. Given the announcement distance of

2000-1400 meters, that results in the previously mentioned factor of three (6 km /

2000 meters). In free flow conditions (120 km/h) this would imply that a vehicle

passes a dissemination area at least every 3 minutes.

Req.3: a dissemination area must be present at least every 6

kilometres.

2.4 Planned and unplanned events

From this perspective, it is useful to distinguish between planned and unplanned

events. Planned events are associated with information and awareness use cases

like road works, whereas unplanned events are associated with warning and active-

safety use cases like temporary hazardous locations. Consequently, unplanned

events have a much shorter time-to-collision (i.e. the time between signalling and

the arrival at the event position) than planned events.

In case of planned events, a portable RSU could be placed near the event position

(i.e. the start of work zone) to ensure that vehicles also receive the latest

information in case the information changed since passing the previous RSU.

However, in case of unplanned events, when the presence of a third party (e.g. road

authority, emergency services, contractors, etc.) is not required, a temporary

portable RSU is impractical and probably uneconomical. C-ITS use cases based on

such events (e.g. slow vehicle indication, black ice, etc.) are foreseen only after day

1.

For day 1, portable RSUs should always be considered, whereas in the long term,

portable RSUs shall only be considered for unplanned events in case the presence of

the road authority, contractor, emergency vehicles or other special vehicles is

required (i.e. unplanned road works (repair), major accidents, certain diversions,

etc.).

Req.4: the use of portable RSUs shall be considered in the case of

planned events and for unplanned events as well, when the

presence of the road authority, contractor, emergency vehicles or

other special vehicles is required.


Pagina 9 van 16

3 RSU perspective

This chapter describes specifications of RSUs and factors affecting the performance

of RSUs. Both can be used to evaluate the appropriateness of the exact location of

an RSU.

3.1 Transmission range

There are different perspectives to the transmission range of RSUs. These are

discussed in this section.

3.1.1 Sending range

Many surrounding factors affect the transmission range of an RSU. As a

consequence, none of the suppliers guarantees a default transmission range. In

addition, the transmission range depends on the type and number of antennas that

are used. The two types of antennas that are most common are directional antennas

and omnidirectional antennas. The former has a larger transmission range but a

weaker signal near the antenna, whereas the latter has a uniform signal strength in

all directions but a smaller – though generally sufficient – transmission range. One

option is to use three antennas for a single channel: one directional antennas for

each direction of travel (two in total) and one omnidirectional antenna to

compensate for the weaker signal near the RSU. Indications of the average

transmission range vary from 500 meters for omnidirectional antennas, up to 2

kilometres for directional antennas. Factors affecting the transmission range are

listed in section 3.2.

3.1.2 Reception range

Tests revealed that the V2I and I2V transmission range is asymmetric, i.e. the

transmission range of RSUs was on average larger than the transmission range of

OBUs. This implies that the transmission range is a product of both the OBU as

sender and the RSU as receiver, and different for the reversed case. As a result,

requirements for RSU placement might be different for I2V and V2I based use

cases. Figures 1 and 2 schematically shows the difference in transmission ranges for

an OBU and an RSU. The outer circles represent the default transmission ranges,

i.e. under normal surrounding conditions. The inner striped circles represent the

minimum transmission range resulting from surrounding factors like weather and

obstruction and possible Decentralized Congestion Control (Transmit Power Control

specifically) [5]. Depending on the needs of the deployed services, this knowledge

can be used to decide to place RSUs closer or farther apart.

Figure 1: asymmetric transmission range OBU and RSU Figure 2: sender and receiver ranges for RSU


Pagina 10 van 16

3.1.3 Unidirectional reception

Another finding from field tests is that some vehicles are unable to receive

messages which are transmitted to them in the downstream direction. Due to

placement of the antenna behind the windscreen of the vehicle the sight of the

antenna is limited to the front of the vehicle, which prevents receiving messages

coming from the rear (i.e. upstream). Nonetheless, during day 1 deployment and

especially in the case of after-market OBUs it is likely that antennas will be placed

behind the windscreen. Therefore, to increase the likelihood that vehicles are

physically able to receive messages, the RSU placement should be such that the

antenna beam is directed into the upstream direction, i.e. that messages are

transmitted to the front of the vehicles.

Req.5: placement of RSUs must ensure that the antenna beam is

directed to the front of the vehicles.

3.2 External factors

Within the spatial boundaries defined by dissemination areas and functional

requirements of use cases (see chapter 2), it is up to contractors to determine the

exact positions of RSUs in combination with the choice of antennas. Nevertheless,

based on field tests there are several known external factors that may steer the

decision which are listed below. These factors were obtained through literature

review and interview with experts and suppliers.

3.2.1 Surrounding factors Viaducts: usually requires an RSU on both sides to ensure line of sight.

Tunnels: as GPS-based services will not work in tunnels, an RSU should at

best be placed at the entrance of a tunnel.

Road incline: antennas should be directed parallel to the road surface.

Weather conditions:

o Humidity (e.g. rain, snow, fog) reduces performance. Due to the

surface structure snow reduces performance more than rain and fog.

o To a lesser extent, high temperature reduces performance, but low

temperature can have a positive effect.

Foliage: leaves and vegetation have a strong absorbing effect on the radio

signal.

Constructions: buildings and especially metal have an obstructing/disrupting

effect.

Surface: reflection or absorption is likely based on type of surface.

3.2.2 Installation factors Line of sight with vehicles is necessary to ensure connectivity.

A minimum height of the antenna of 3.9 meters allows to exceed the height

of trucks. Also, 4 meters is the ideal height for the antenna with respect to

the Fresnel zone [6] which maximizes the transmission range.

A fixed network connection is recommended, preferably with fibreglass.

However, a wireless connection is also possible, but less preferable, since it

results in a lower service level.

All RSU's need some form of energy source. In practice nearby energy

sources frequently determine the definitive position of road side equipment.

The presence of existing power sources is therefore an important factor

when considering RSU locations.


Pagina 11 van 16

Different setups and configurations for the control and service channel can

exist in parallel (i.e. because of the different channel frequencies they do

not interfere with each other).

Distance between router and antenna should be kept to the minimum

(preferably less than 1 m) as antenna cables cause 0.5 dBi loss per meter

cable (unless extremely expensive cables).

3.2.3 Technical factors Type of antenna(s), e.g. omnidirectional or directional.

If there are many antennas in the same area, they can disrupt each other’s

signal. Given that there are two solutions with a similar level of radio

coverage, it is therefore preferable to opt for the one with the least number

of antennas.

Based on the experience of several experts (see 5.3), a signal strength of

12-15 dBm is recommended. A strong signal reaches further, but is also

noisier. A weaker signal is clearer, but has a lesser reach. The control

channel has a limit of 33 dBm [11].

Successful transmission ratio (STR) (i.e. % of arrived packets, 90%

recommended). This is the net number of packages that are successfully

received. At certain distances it is possible that not all bits are received

(correctly) and a package is corrupt. In practice a STR of 90% results in a

reliable performance. Therefore, a STR of 90% is recommended at the

desired (maximum) distance.

RSUs should not interfere and/or disrupt each other.

Network channel capacity (see section 3.3.1).

Public Key Infrastructure (see section 3.3.2).

Note: the transmission range of an RSU is subject to many internal and external

factors. To quantify the performance of an RSU one should examine the successful

transmission ratio at different distances from the RSU. The successful transmission

ratio is the product of interdependent factors like signal strength, packet size, traffic

density and surrounding factors.

3.3 RSU capacity

3.3.1 Channel Load

There is a maximum amount of information that can be transmitted via ITS-G5 from

a physics perspective. In other words, based on the used frequency and protocols,

there is a limited capacity of the ITS-G5 medium. As a figure to determine how

much of the capacity is used, one can look at the channel load. This channel load is

dependent on a number of factors: - The number of generated packets by both OBUs and RSUs

o Which is dependent on the number of vehicles within transmission

range

- The size of the packets

Currently, there are two main mechanisms for counteracting high network channel

loads. - Decentralised Congestion Control (DCC) [5] acts based on an estimation of

the number of neighbours using the Channel Busy Ratio (CBR). It has three

strategies to counteract a busy channel:

o Transmit Rate Control: restricts the number of generated packets in

each and every vehicle as the CBR increases (output power and


Pagina 12 van 16

transfer rate are kept constant). For example, at a channel load

<30% the transmit rate is 10 Hz, while at a channel load >60% the

transmit rate is 2 Hz.

o Transmit Power Control: reduces the output power as the CBR

increases. This shortens the effective transmission range and thus

fewer vehicles will receive the message.

o Transmit Data Rate Control: uses a higher transfer rate for

increasing CBR, keeping the channel less busy because the packets

will be in the air shorter.

For day 1 applications only Transmit Rate Control has been selected. In

addition, a priority mechanism is adopted that does not restrict DENMs and

applies DCC primarily to CAM. It is planned to revisit DCC for day 2

applications. - The CAM generation frequency is managed by the CA basic service; it

defines the time interval between two consecutive CAM generations [9]. The

upper limit of the transmission interval is 10 Hz and the lower limit of the

transmission interval is 1 Hz. CAM generation – and transmission – is

subject to the changes in vehicle heading, position or speed, and channel

usage requirement of DCC. The definition of the CAM rate is such that it

allows each OBU to broadcast a reasonable minimum number of CAMs for

Day 1 applications, more or less equal to other OBUs in the same area, and

also in congested situations.

In the C-ITS platform report [7] it is stated that predictability of DCC must be

further developed, especially because the CBR does not consider the number of

vehicles within radio range. It suggests a kind of differentiation of V2I application

from I2V applications, the latter being based on infrastructural messages that are

critical for safe operation of the vehicles. Consequently, different DCC mechanisms

could apply for RSUs and for OBUs, but this is to be further explored with relevant

stakeholders as discussions on this subject are ongoing.

While the DCC algorithm still must be further developed, it is clear that the transmit

power might be reduced in the future. Thus, the radio coverage in effect becomes

smaller. If that is a possibility it might be desirable to place multiple weaker RSU’s

in contrast to a few strong ones. An additional benefit of multiple RSU’s is that the

workload (e.g. security key validation) of the message handling is distributed among

them.


Pagina 13 van 16

4 Recommendations

4.1 Conformance testing

There are many standards from ETSI, ISO and CEN that provide requirements

and/or restrictions to ensure interoperability on the level of ITS-G5 over-the-air

communication. For the Dutch context, the “Dutch ITS Profile” [10] provides

additional requirements and/or restrictions.

Conformance testing is currently arranged by ETSI through plug-tests. In plug-tests,

engineers get together to test the interoperability of their implementations. Whether

an RSU conforms to the standards (i.e. is interoperable), should, in the future, be

further extended. For example, these tests should go beyond interoperability and

include tests on communication performance. Metrics for communication

performance could be: Transmission range.

Signal strength (dBm).

Successful transmission ratio (i.e. % of arrived packets) given a certain

packet size.

As noted earlier the performance of communication is the result of the performance

on both the sender and the receiver side. Specifically, the communication

performance of an RSU may be experienced differently by different OBU

configurations, i.e. the hardware used and the placement of antennas. Therefore, to

objectively evaluate the communication performance of an RSU, a reference OBU is

required. It has been suggested that the Car2Car Consortium could provide such a

reference OBU, but that has to be verified.

4.2 Probe vehicle data

The PVD use cases may benefit from specific placement of RSU’s, for example

before and after each on-ramp and off-ramp. This was not considered in this report.

It is recommended to explore in more detail what is most effective.

4.3 Learn from other domains

When planning for placement of RSUs in longer term scenarios, i.e. full coverage, it

is recommended to look into common practice and lessons learned from wireless

networks based on 5 GHz Wi-Fi and cellular (3G/4G) networks. For example, in both

domains there are experts in determining optimal antenna positions to cover the

surrounding area best.

4.4 Integrate experience from pilot projects and demonstrations

Given the novelty of C-ITS, learning by doing is another strategy. Nationally and

internationally more and more experience is gained with respect to ITS-G5 radio

signals through pilot projects, demonstrations and tests. It is very important to

collect the lessons learned during those projects. Moreover, relevant stakeholders

like equipment manufacturers and system integrators were interviewed to prepare

this document, but they continue to gain new insights. Also, once the structure and

approach proposed in this document is adopted by a larger part of the industry, new

questions might arise based on what is already written and is still required.

4.5 Additional tests

It is strongly recommended to perform some “on street” tests, as follow-up on the

first experiences of the corridor pilots. In these tests, some specific configurations


Pagina 14 van 16

and conditions can be tested including the usage of different on-board units. There

are several equipped test facilities in the EU, like the test site in Helmond.

4.6 Advance start of broadcasting

Given the limited signal coverage in day 1, for planned situations, one might choose

to advance the broadcasting of messages about an event so that it is certain that all

vehicles passing the event location have received information upstream about the

event. For example, an RSU upstream of the event location could inform about a

lane closure five minutes before the lane is actually closed (note that in case of a

lane opening the approach is to be reversed, i.e. first open the lane and then start

signalling). Such an approach minimizes the number of false negatives. It should be

noted, however, that he timing of messages is a profiling issue and not a RSU

placement issue. It is obvious, nonetheless, that the two are closely related.


Pagina 15 van 16

5 References, Definitions and Abbreviations

5.1 References

# Reference

1 Cooperative ITS Corridor. Description of the System Concept. Version 1.0 –

4 July 2016. Rijkswaterstaat.

2 ISO TS 19321:2015 (2015-04-15). Dictionary of in-vehicle information (IVI)

data structures.

3 Handboek wegafzettingen Autosnelwegen (CROW 96a)

4 Human factor guidelines for the design of safe in-car traffic information

services (2014). Rijkswaterstaat.

5 ETSI TS 102 687 (2011-07). Decentralized Congestion Control Mechanisms

for ITS-G5 (DCC)

6 https://en.wikipedia.org/wiki/Fresnel_zone

7 C-ITS platform final report

8 TS 102 687 V1.1.1. Intelligent Transport Systems (ITS); Decentralized

Congestion Control Mechanisms for Intelligent Transport Systems operating

in the 5 GHz range; Access layer part

9 ETSI EN 302 637-2 V1.3.2. Intelligent Transport Systems (ITS); Vehicular

Communications; Basic Set of Applications; Part 2: Specification of

Cooperative Awareness Basic Service

10 Dutch ITS Profile: http://ditcm.eu/its-round-tables/architecture-

interoperability

11 ETSI EN 302 663 V.1.2.1. Access layer specification for Intelligent Transport

Systems operating in the 5 GHz frequency band.

5.2 Sources

# Source

1 Wi-Fi Location-Based Services 4.1 Design Guide

2 Verkeerskundige richtlijnen autosnelweginstrumentatie

3 Stichting Wireless Leiden. URL: https://www.wirelessleiden.nl/over-wireless-leiden

4 Draadloos Groningen. URL: http://draadloosgroningen.nl/wordpress/

5 https://en.wikipedia.org/wiki/Municipal_wireless_network

6 simTD project. URL: http://www.simtd.de/index.dhtml/deDE/index.html

7 FOTsis project. URL: http://www.fotsis.com/

5.3 Respondents to interviews

# Respondent

1 Cohda, Peter Hierholzer

2 Commsignia, András Váradi

3 Dynniq, Nuno Rodrigues

4 RWS, Henk Stoelhorst

5 RWS, Michel Kusters

6 Siemens, Eddy Verhoeven

7 Swarco, Peter Smit

8 TASS International, Igor Passchier


Pagina 16 van 16

5.4 Abbreviations

CACC Cooperative Adaptive Cruise Control

C2C Car to Car

CAM Cooperative Awareness Messages

C-ITS Cooperative ITS

C-ITS-S Central ITS Station

CBR Channel Busy Ratio

CEN European Committee for Standardization

CRW Collision Risk Warning

CZ Communication Zone

DCC Decentralized Congestion Control

DENM Decentralized environmental Notification Message

ETSI European Telecommunications Standards Institute

I2V Infrastructure to vehicle

ISO International Organization for Standardization

IVI In-Vehicle Information

IVS In-Vehicle Signage

ITS Intelligent Transport Systems

ITS-S ITS Station (e.g. V-ITS-S, R-ITS-S, C-ITS-S)

MTM Motorway Traffic Management

OBU On-Board Unit

PKI Public Key Infrastructure

PVD Probe Vehicle Data

RIS Roadside ITS Station

R-ITS-S Roadside ITS Station

RSU Roadside ITS Station

RWS Rijkswaterstaat

RWW Road Works Warning

V2I Vehicle to Infrastructure

V2V Vehicle to Vehicle

V-ITS-S Vehicle ITS Station

rsu placement guidelines - intercor · 2020. 4. 7. · rsu placement guidelines | 27 october 2016...

Documents