Geocast System

Ana Catarina Antunes dos Santos

Thesis to obtain the Master of Science Degree in

Electrical and Computer Engineering

Supervisor: Prof. Teresa Maria Sá Ferreira Vazão Vasques

Examination Committee

Chairperson: Prof. Pedro Manuel Urbano de Almeida LimaSupervisor: Prof. Teresa Maria Sá Ferreira Vazão Vasques

Member of the Committee: Prof. Alberto Manuel Ramos da Cunha

June 2019

2

I declare that this document is an original work of my own authorship and that it fulfills all the require-

ments of the Code of Conduct and Good Practices of the Universidade de Lisboa.

For my mom, to all the weekends spent at home waiting for me to finish my work...

For Guilherme, for always teaching me something new...

3

4

Resumo

A cada dia que passa, aproximamo-nos de um mundo em que os veıculos se deslocarao autonoma-

mente, sem precisar de qualquer auxılio humano para tomar decisoes. Para que os veıculos autonomos

se tornem uma realidade, e necessario que exista partilha de informacao entre todos os intervenientes

de uma rede veicular, como carros e infraestruturas. Esta partilha de informacao tem de ser confiavel,

assegurando que nenhuma informacao relevante seja perdida e, por outro lado, a entrega da informacao

tem de ser com uma latencia reduzida, para que todos os nos da rede estejam o mais atualizados

possıvel. Assim, existiu a necessidade de criar arquiteturas que suportem estes requisitos nas suas

aplicacoes de tomadas de decisoes. Na Europa, o ETSI desenvolveu a arquitetura C-ITS, onde o

modo de comunicacao entre os nos e bastante inovador, comparado com os modos tradicionais de

comunicacao. O modo de comunicacao implementado nesta arquitetura chama-se Geocast, que possi-

bilita o envio de informacao para uma area geografica, sem ser preciso ter conhecimento da identidade

dos nos que la se localizam. Dado que este modo de comunicacao e muito recente, nao existem estu-

dos suficientes para tirar conclusoes se funciona corretamente. Assim, este trabalho visa implementar

uma visao simplificada da arquitetura ETSI, com especial enfase na camada que implementa o modo

de comunicacao Geocast, para que estudantes possam utiliza-la como base do desenvolvimento das

suas aplicacoes C-ITS.

Palavras-chave: C-ITS, Geocast, GeoNetworking, Veıculos Autonomos, VANET

5

6

Abstract

Each day that goes by is a day closer to the day in which all vehicles will move autonomously, with

no need for any sort of human aid to make decisions. In order for autonomous vehicles to become a

reality, the sharing of information between all intervening parties in a vehicle network, such as vehicles

and infrastructures, is necessary. This share of information must be reliable, assuring that no relevant

information is lost, and, on the other hand, the information delivery must be done with a small latency,

in order for all the network nodes to be updated as best as possible. Thus, emerged the need to create

architectures that support these requirements for applications that can make decisions. In Europe,

ETSI developed the C-ITS architecture, on which the way of communicating between nodes is quite

innovative, when compared to traditional ways of communication.The name of this communication mode

is ’Geocast’, which enables the possibility of sending information to a geographical area, with no need

for the knowledge of the identity of the nodes that are in such location. Because this communication

mode is recent, there are not sufficient studies in order to take conclusions on whether it is correctly

working. As such, this work aims to implement a simplified vision of the ETSI architecture, with special

emphasis on the layer which implements the Geocast mode of communication, in order for students to

be able to use it as a foundation for their C-ITS applications.

Keywords: C-ITS, Geocast, GeoNetworking, Autonomous Vehicles, VANET

7

8

Contents

Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1 Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Background 5

2.1 Cooperative Intelligent Transport Systems (C-ITS) . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 General overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 C-ITS communication architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.3 ETSI reference architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.4 European Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 ETSI reference architecture layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 Application layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.2 Facilities layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.3 Network & Transport layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.4 Access layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Architecture 21

3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Global Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 GeoNetworking Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.1 LocalInfo Service component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.2 Beaconing Service component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3.3 Location Service component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3.4 GeoMessage Handling Service component . . . . . . . . . . . . . . . . . . . . . . 25

9

3.4 Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 Implementation 29

4.1 System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2 Implementation options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3 Software organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3.1 Code organization in files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3.2 Main Code - GeoNetworking.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3.3 Multicast Layer - Multicast.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3.4 GeoNetworking Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3.5 Facilities Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5 Results 49

5.1 Unit Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.1.1 Unit Tests scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.1.2 GeoMessage Handling Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.1.3 Location Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.2 Performance Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.2.1 Performance Tests scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.2.2 Beaconing Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6 Conclusions 59

6.1 Achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Bibliography 61

10

List of Tables

2.1 Road Safety Applications Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Road Safety Applications Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Traffic Management Applications Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 Main Traffic Management Applications Requisites . . . . . . . . . . . . . . . . . . . . . . . 12

2.5 CW and AIFS timing for each AC[i] queue. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.6 Comparision of 802.11p and Wi-Fi communication parameters. . . . . . . . . . . . . . . . 20

4.1 CommonHeader format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2 TSBHeader format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.3 GeoHeader format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4 GeoUHeader format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1 Average and standard deviation for the reception of beacons in node 8, from each node. . 56

5.2 Average and standard deviation for the reception of beacons in node 7, from each node. . 57

11

12

List of Figures

2.1 Reference Architecture for C-ITS applications [19]. . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Reference architecture for ITS communications. [18] . . . . . . . . . . . . . . . . . . . . . 7

2.3 Protocol Stack and its ETSI standards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Single-Hop Broadcast. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5 GeoBroadcast. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.6 Topologically-Scoped Broadcast. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.7 Comparision of forwarding techniques GeoUnicast e GeoAnycast. . . . . . . . . . . . . . 16

2.8 Reverse Direction GeoUnicast. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.9 Interface IN-SAP specification. [34] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.10 Access layer architecture [36] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Global Architecture with focus on GeoNetworking Layer [19] . . . . . . . . . . . . . . . . . 23

3.2 Node Info Service detailed architecture [19]. . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 Node Info Service detailed architecture [19]. . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4 Location Service message diagram [19]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.5 Location Service detailed architecture [19]. . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.6 GeoMessage Handling Service detailed architecture [19]. . . . . . . . . . . . . . . . . . . 27

3.7 GeoNetworking detailed architecture [19]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1 SmartMob system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2 Components and interactions of the main program GeoNetworking.py. . . . . . . . . . . . 32

4.3 pseudo-code of GeoNetworking.py. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4 pseudo-code of sendMulticast. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.5 pseudo-code of receiveMulticast. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.6 Components and interactions of Multicast.py. . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.7 pseudo-code of getGN ADDR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.8 pseudo-code of updateLPV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.9 pseudo-code of checkEntriesLocTable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.10 pseudo-code of checkIsNeighbour. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.11 pseudo-code of updateLocTable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.12 pseudo-code of removeEntry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

13

4.13 pseudo-code of readLocTable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.14 pseudo-code of checkLocation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.15 pseudo-code of writeBuffer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.16 pseudo-code of getPacketFromBuffer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.17 pseudo-code of validPkt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.18 Components and interactions of the functions that updates the node’s structures. . . . . . 37

4.19 pseudo-code of processCommonHeader. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.20 pseudo-code of receiveSHB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.21 pseudo-code of receiveTSB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.22 pseudo-code of receiveGeoB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.23 pseudo-code of receiveGeoA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.24 pseudo-code of receiveGeoU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.25 Components and interactions of GeoMessageReceiverHandler.py. . . . . . . . . . . . . . 42

4.26 pseudo-code of sendBeacon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.27 pseudo-code of receiveBeacon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.28 Components and interactions of BeaconingService.py. . . . . . . . . . . . . . . . . . . . . 43

4.29 pseudo-code of createLS Request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.30 pseudo-code of repeatLS Request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.31 pseudo-code of replyLS Request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.32 pseudo-code of createLS Reply. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.33 pseudo-code of receiveLS Reply. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.34 Components and interactions of LocationService.py. . . . . . . . . . . . . . . . . . . . . . 45

4.35 pseudo-code of sendSHB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.36 pseudo-code of sendTSB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.37 pseudo-code of sendGeoB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.38 pseudo-code of sendGeoA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.39 pseudo-code of sendGeoU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.40 Components and interactions of GeoMessageTransmissionHandler.py. . . . . . . . . . . . 47

4.41 Components and interactions of Facilities.py. . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.1 Unit tests scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2 Message diagram of SHB test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.3 Message diagram of TSB test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.4 Message diagram of GeoB test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.5 Message diagram of GeoA test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.6 Message diagram of GeoU test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.7 Message diagram of the first LS test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.8 Message diagram of the second LS test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.9 Performance test scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

14

5.10 Evolution of beacons’ reception through time in node 8, running in raspberry pi zero, with

100 ms of periodicity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.11 Evolution of beacons’ reception through time in node 7, running in macOS, with 100 ms

of periodicity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

15

16

Chapter 1

Introduction

In modern societies, mobility and transportation have a significant role in the organization of communities

and economy. The massive use of transportation systems created two major problems - road accidents

and traffic congestion - that need to be solved. According to [1], road accidents are currently one of the

leading causes of death and injuries across the globe. This has major socioeconomic impact, affecting

the well-being of communities and families, as well as health and labor systems. Even though efforts are

being made by the automotive industry and road operators to improve vehicle safety-systems, as well as

by authorities to develop adequate policies and educate citizens, the fact that accident’s statistics are far

from an acceptable level still remains as a problem that must be tackled in modern society, as stated in

[2]. From another perspective, nowadays, there is a huge percentage of population in urban centers, with

a massive use of private cars, especially in developed countries, which significantly contributes to traffic

congestion. This has a major environmental impact due to the CO2 emissions, but also on citizen’s

quality of life due to the increased travel time and the cost spent on transportation. The automotive

industry, road operators and municipalities are aware of these problems and join efforts to enhance

automatic driver assistance and traffic management systems.

The evolution of sensor technology, location systems and mobile wireless communications created

the opportunity to address these problems in a different and more efficient way under the scope of

Cooperative Intelligent Transport Systems (C-ITS). In C-ITS systems, the vehicles and infrastructures

(the Road-Side Units - RSU) autonomously create a network - a Vehicular Ad-hoc NETwork (VANET).

VANETs are designed to provide short range communication with very low latency and (almost) guaran-

teed delivery. In C-ITS systems, the nodes cooperate by sensing the environment and sharing their own

information with their neighbour so that they can improve the knowledge of the ”world”. The major goal

of this cooperation process is enhancing the information available for decisions, that would be otherwise

very complicated for the drivers to grasp, by consulting the neighbours in the node’s vicinity. These

systems allow vehicles to become less dependent of drivers’ decisions, leading to the evolution of au-

tonomous vehicles. It is foreseeable that vehicles will be able to drive autonomously for short periods of

time and under certain conditions most likely by 2020, and that by 2025 the duration of this autonomous

driving will be increased to longer periods, but it is still not possible to predict when vehicles will be able

1

to make decisions as sharply as a human is able to. [3].

Advanced road safety and traffic efficiency applications are the major goals of C-ITS systems, al-

though other applications may also be used. Examples of possible use cases of C-ITS applications

are pre-crash warning, platooning and optimal speed advisor. Although very different in their purpose

and usage, these applications share a common set of requirements, such as the need of very fast and

reliable dissemination of information to all nodes that are within a certain geographical area. Delivering

information to nodes based on their location requires a new type of communication - geocast commu-

nication, with the delivery of information being based on the node’s location instead of the IP address.

Neither geocast nor reliable and low-latency delivery are supported by current Internet Protocol Stack.

Throughout the years, several systems were created in order to operate in vehicular networks [4,

5], although these systems were designed under different structures and protocols, which became an

obstacle in applying such systems to create a standardized usage in every vehicular network node. To

prevent the appearance of vendor-dependents and non-interoperable solutions, there has been a huge

effort by the regulatory entities, namely the United States of America [6], Europe [7] and Japan [8] in

creating standards that allow the development of applications that can run in similar architectures and

across different manufacturers. The implementation of such applications in every node of a vehicular

network is only possible with the architecture’s standardization.

The standardization in Europe started in the beginning of 2010 by ETSI (European Telecommu-

nications Standards Institute) and some changes are still happening, despite the overall architecture

having been completed. ETSI proposes a completely new protocol architecture with just four layers -

Applications, Facilities, Transport & Network and Access - and management and security as vertical

entities that cross all layers. The Application layer is essentially focused in the road-safety and traffic

efficiency applications, although other sets of applications may also be supported. The Facilities layer

provides a middleware that allows the existence of shared services that support the common applica-

tion requirements. The Transport & Network layer provides support to all the communication modes

and performance requirements needed and, finally, the Access layer is tasked with handling all of the

communications with the media.

One of the core components of this architecture is the Network layer protocol, usually called Geonet-

working protocol, standardized in [9]. This protocol aims at supporting the entire set of communication

modes, including unicast, multicast and geocast, using location information to identify the nodes and en-

suring end-to-end delivery of data with very strict latency requirements, within the range of milliseconds.

Some geocast protocols have already been developed, being IVG [10], Cached Geocast [11], Abiding

Geocast [12], DRG [13], ROVER [14], DG-CastoR [15] the most relevant ones. Each protocol imple-

ments isolated and independent concepts of these new ways of communication, this is called Geocast,

while GeoNetworking intends to implement all the concepts, with every interaction idealized, towards

the unification of VANET’s communication.

2

1.1 Motivation

With the current state of the art, there aren’t sufficient studies and investigation that demonstrate the

correct performance of the overall architecture. Although there are already some systems implemented,

they are most commonly found in industrial companies, not being available for scientific studies in a wide

community.

Some components of the architecture have already been studied, for instance the protocols of the

lower layer [16, 17], and these studies are related to the American architecture, WAVE (Wireless Access

in the Vehicular Environment). The studies of these isolated protocols have made no effort to investigate

how the applications can use the features and neither have they been able to establish a protocol that

could implement Geocast. As a consequence, these tests are not suitable to make conclusions about

the evolution of ETSI’s architecture evolution.

Thus, with this thesis, it is necessary to develop an experimental platform that includes the core

principles of ETSI’s architecture and that allows quick and prototyped validation of applications, as well

as the architecture as a whole.

1.2 Objectives

The main objective of this work is to create an experimental platform to validate and test ETSI’s refer-

ence architecture. In terms of the focus of the thesis, the focal point is the overall organization of the

system specially in the GeoNetworking layer. This platform is intended for the development and tests of

applications, in advanced academic teaching and research.

1.3 Thesis Outline

On the Background chapter, the state of the art regarding this theme is discussed, as well as the char-

acteristics that are considered to be the most important to the ETSI architecture and to this work as well.

On the architecture chapter, a detailed description on the ETSI architecture that was implemented in

this work will be made and analyzed, especially on the topic of the GeoNetworking layer, as well as all

the services that are associated to this layer. Regarding the implementation chapter, all of the software

which was used and the implemented software will be described. This will be followed by the viewing

of the results that were obtained throughout the work with all the tests that were performed. Finally

conclusions on this work will be discussed and suggestions on new approaches to develop this work will

be remarked.

3

4

Chapter 2

Background

In this chapter the state-of-the-art of the systems that will be analyzed throughout this thesis is explained,

and also the ETSI standards that were used in the development of the architecture are explored.

2.1 Cooperative Intelligent Transport Systems (C-ITS)

2.1.1 General overview

C-ITS systems use technology that allow vehicles to communicate with each other and with other in-

frastructures of the road, such as traffic lights. These communications are made between cooperative

nodes, that have the ability to gather information about their surroundings and share this knowledge

with other nodes. Based on received information, these nodes know what is happening around them

and can make decisions [3]. Taking in the example of a vehicle that was circulating on a highway and

suddenly has an accident, if this vehicle is a cooperative node, it can send an alert with relevant data

about the accident (location, time of the accident...) to the other nodes of the network and the vehicles

that precede it can make a decision based on these alerts, like choosing other trajectories. Thus, the

nodes’ ability to obtain information about the environment that surrounds them led to new applications,

that create messages about events that should be spread across the nodes’ network, in order to know

real-time events and making decisions accordingly.

To support these new groups of applications, it was necessary to develop a new protocols’ archi-

tecture. There are three fundamental architectures design for these systems, namely WAVE system,

developed in the United States of America, the Japan system and C-ITS developed in Europe. This

work approaches C-ITS architecture, normalized by ETSI, that is described in the following sections.

2.1.2 C-ITS communication architecture

The cooperative vehicular environment where C-ITS applications will perform is schematized on figure

2.1 and is characterized in standard [18].

There are three domains in figure 2.1: in-vehicle domain, VANET domain and infrastructure domain.

5

Figure 2.1: Reference Architecture for C-ITS applications [19].

• In-Vehicle Domain - the components of in-vehicle domain are OBUs (On-Board Unit) and AUs

(Application Unit). An OBU is a device placed on vehicles, that allows short range communications,

enabling access to vehicles’ components, such as sensors. An AU is a device that uses the

communication abilities of an OBU to run applications. This device can integrate the vehicle itself,

being permanently connected to its OBU, or can be a mobile device, that connects dynamically

to the vehicles’ OBU. Therefore, the connection between the AU and the OBU can be wired or

wireless, like Bluetooth.

• Infrastructures Domain - the components of infrastructures domain are Road-Side Units (RSU).

RSUs are devices located on the roadside that provide connectivity support to passing vehicles.

These components are connected to the Internet via Gateway (GW), having very restricted control

processes (can be controlled by pubic authorities, for instances) and are able to provide wireless

communication to vehicles’ OBUs.

• VANET Domain - Vehicular Ad-Hoc Network is made of the In-Vehicle and Infrastructures Do-

mains union, making possible different types of communication in this network: Vehicle-to-Vehicle

(V2V), Vehicle-to-Infrastructure (V2I) or Infrastructure-to-Vehicle (I2V). In effect, V2V communi-

cation takes place between OBUs, and both V2I and I2V take place between OBUs and RSUs.

These communications can happen directly or through multiple steps, if the destination is out of

reach of the source. The existence of RSUs can increase a communication reach, making possible

Internet access. Vehicles can also access to the Internet through Wi-Fi (Hot Spot - HS) or cellular

networks (Base Stations - BS) like GSM, GPRS and 4G, usually when applications are road safety

non-related.

6

2.1.3 ETSI reference architecture

ETSI proposed a reference architecture, common to all type of network nodes. This architecture, pre-

sented in standard EN 302 665 [18] is represented in figure 2.2 and has six layers: Applications, Facili-

ties, Transport Network, Access, Security and Management.

Figure 2.2: Reference architecture for ITS communications. [18]

• Applications - layer responsible for enabling communications between C-ITS applications, through

available services for each one of these systems.

• Facilities - layer responsible to store applications’ common information, to both be accessed and

provided to other layers.

• Transport & Network - layer responsible for communication between processes and nodes, ad-

dressing and verifying if data to transport has no errors.

• Access - layer responsible to establish the transmission of data to the medium.

• Security - layer responsible to assure that communication in all the layers of the protocol stack is

safe.

• Management - layer responsible to manage the configuration of an C-ITS node.

2.1.4 European Protocols

In 2.3 the stack of protocols used accordingly to the European standards, that describe each layer of the

reference architecture.

Comparing figure 2.2 and figure 2.3, it is evident that the applications layer is divided in two, since

these systems have to support both traditional applications and cooperative applications. This division

is also common to both the transport and network layers, since traditional applications will use regular

Internet protocols, as new applications will use new protocols that have service requirements that are

not fulfilled with existing transport and routing protocols.

7

Figure 2.3: Protocol Stack and its ETSI standards.

2.2 ETSI reference architecture layers

In the next subsections each one of the layers are described accordingly to operating European stan-

dards.

2.2.1 Application layer

Throughout the years, cooperative applications have been classified in many different ways, confirmed

in the analysis of many scientific papers [20], [21]. As the standardization of this sector was improving,

these applications were classified in three groups: Road Safety, Traffic Efficiency and Other Applications

[22]. From each one of these groups, ETSI defined the set of applications that constitute the Basic Set of

Application (BSA)[22]. This set corresponds to the applications that must be initially provided to develop

C-ITS business growth.

In the next sections Road Safety and Traffic Management Applications will be described, since these

are the applications that have specific features of vehicle environments. The applications belonging to

the BSA will be further detailed according to the ETSI standard.

Road Safety

Road Safety applications have as their main goal to manage emergency situations and to prevent colli-

sions, dividing themselves in three categories:

• Cooperative awareness: any normal situation that might impact circulation conditions.

• Cooperative collision avoidance or mitigation: any circulation condition that might cause a

collision or notification about a collision.

• Road hazard warning: anything wrong in the road that might have a severe impact on safety.

Table 2.1 briefly outlines the road safety applications of the BSA, presenting the application name

and a small description of its goals.

8

Table 2.1: Road Safety Applications Summary.

Road Safety

Category Name Description

Prevention/Mitigation

of colli-

sions

Vulnerable road usersWarns the vehicles on the presence of vulner-

able users, such as pedestrians.

Previous collision detection

Braces the vehicles for an accident that will

happen and cannot be avoided.Diminishes

the impact felt on the accident.

Collision risk when crossing

through traffic

Informs the vehicles on an incoming vehi-

cle with an intention of cutting through traffic.

Prevents lateral collisions

Collision risk when merging with

traffic

Issues a notice destined to inform the right-

lane vehicles on the presence, position and

the movement of the vehicles that is ap-

proaching. Prevents lateral collisions

Danger

on the

road

signs

Electronic emergency breaking

lights

The vehicles announces when it is about to

come to an abrupt stop

Incoming traffic on the opposite

lane

Alerts the vehicles on an existing vehicle that

is circulating on oncoming traffic. Reduces

the possibility of a frontal collision.

Immobilized vehicle

Alerts the vehicles that an immobilized vehicle

is currently on the road. Prevents a chain of

collisions and also traffic management.

Traffic state

Alerts on the current state of traffic on the lo-

cation of a sensor. Reduces the probabilities

of a traffic jam occurring.

Traffic lights transgressions

Alerts the vehicles that a vehicle has made a

transgression in regards of a traffic light. Re-

duces the number of transgressions.

Road work

Alerts the vehicles on the presence of road

works in a certain location. Reduces the num-

ber of accidents near road work sites.

Dangerous obstacle on the

roads

Alerts all vehicles that a dangerous obstacle

is on the road, whether it is temporary or per-

manent. Reduces accident risks.

Cooperative Knowl-

edge

Presence of Emergency Vehi-

cles

Allows emergency vehicles to make their

presence known. Reduces the response

times for emergencies.

Presence of a slow vehicleA vehicle that is traveling at a slow speed

warns other vehicles. Improves traffic flow.

9

Road Safety

Category Name Description

Presence of a small bike

A small bike sends out it’s location in order to

avoid accidents, specially near sights with low

visibility.

Overtaking

A vehicle with the intention of overtak-

ing another vehicle announces it’s inten-

tion.Reduces the risk of an accident.

Changing lanes assistance

The information on vehicles moving on the

opposite lane is supplied, in order to help on

changing lanes.

Reducing light intensity

The vehicle is able to swap between the main-

beam headlamps and the dipped-beam head-

lamps automatically, according the other vehi-

cles’ proximity.

Possibility of collision on Inter-

sections

Vehicles are informed on an area where there

is a possibility of occurring an accident. Pre-

vents the risk of collision, or diminishes the

effects it may have.

Table 2.2 presents the basic requirements that need to be followed to assure proper functioning of

the Road Safety applications described in table 2.1.

Table 2.2: Road Safety Applications Summary.

Road Safety

Category Name Mode TypeMin.

Freq.

Max.

Lat.

Collision

Preven-

tion/

Mitigation

Vulnerable road user Broadcast I2V 1Hz 100ms

Previous collision detection Broadcast V2X 10Hz 50ms

Collision risk when cross-

ing through trafficBroadcast V2X 10Hz 50ms

Collision risk when merging

with trafficBroadcast V2X 10Hz 100ms

Electronic emergency

breaking lightsBroadcast V2X 10Hz 100ms

Incoming traffic on the op-

posite laneBroadcast V2X 10Hz 100ms

Immobilized vehicle Broadcast V2X 10Hz 100ms

Danger on the

road signsTraffic state

Broadcast

GeocastV2X 10Hz —

Traffic lights transgressions Broadcast V2X 10Hz 100ms

10

Road Safety

Category Name Mode TypeMin.

Freq.

Max.

Lat.

Road workBroadcast

GeocastI2V 2Hz 100ms

Dangerous obstacle on the

roads

Broadcast

Geocast

I2V

V2X10Hz —

Cooperative

Knowledge

Presence of Emergency

VehiclesBroadcast V2X 10Hz 100ms

Presence of a slow vehicle Broadcast V2X 2Hz 100ms

Presence of a small bike Broadcast V2X 2Hz 100ms

Overtaking Broadcast V2X 10Hz 100ms

Changing lanes assistance Broadcast V2X 10Hz 100ms

Reducing light intensity Broadcast V2X 2Hz 100ms

Possibility of collision on In-

tersectionsBroadcast V2X 10Hz 100ms

Traffic Management

Traffic Management applications were created to give information on circulating conditions that could

improve traffic flow. Table 2.3 provides an overview of these applications, being divided in logical groups,

according to the types of generated warnings.

Table 2.3: Traffic Management Applications Summary

Traffic Management

Type of Alert Name Description

State of

the

infrastructure

Speed limits

An RSU transmits information on the

speed limit allowed on a certain road.

Improves road security and traffic flow.

Current traffic lights stateTraffic lights warn the vehicles on the

remaining time to swap states.

Information on traffic and rec-

ommended routes

Informs approaching vehicles on ab-

normal events, recommending alter-

nate routes in case of congestion.

Intersection Management

All V2X and V2I operations with an in-

tention of improving vehicle circulation

in an intersection, such as the traffic

lights’ synchronization.

11

Traffic Management

Type of Alert Name Description

Vehicle Signaling

The traffic lights’ infrastructure trans-

mits a message with its signal to the

vehicle.

Type of roadLimited access, deviation notifi-

cation

Warns vehicles on events that limit ac-

cess, although it could suggest new

itineraries, in order to avoid the re-

stricted area.

Dynamic Vehi-

cle Behaviour

Automation System on cooper-

ative vehicles on the highway

Through V2X and Unicast messages,

vehicles more efficiently, due to having

the information of all parties involved.

Table 2.4 presents the basic requirements that need to be followed to assure proper functioning of

the Traffic Efficiency applications described in table 2.3.

Table 2.4: Main Traffic Management Applications Requisites

Traffic Management

Type of Alert Name Mode Type Min. Freq.Max.

Lat.

State of

the

infrastructure

Speed limits Broadcast I2V1Hz up to

10Hz—

Current traffic lights

stateBroadcast I2V 2Hz 100ms

Information on traffic

and recommended

routes

Broadcast I2V1Hz up to

10Hz500ms

Intersection Man-

agementBroadcast

V2X

I2V1Hz 500ms

Vehicle Signaling Broadcast I2V 1Hz 500ms

Type of roadLimited access, de-

viation notificationBroadcast I2V

1Hz up to 10

Hz500ms

Dynamic Vehi-

cle Behaviour

Automation System

on cooperative vehi-

cles on the highway

Broadcast I2V 2Hz 100ms

12

Synthesis and Discussion

As shown in previous sections cooperative applications work in a very similar way, regardless of their

category. Therefore:

• to provide cooperative awareness, specific messages are transmitted with no restrictions, without

a limited duration;

• to support notification of events, event messages are transmitted as long as the event is valid;

• it is mandatory that the messages are sent periodically, with a frequency between 1 and 10 Hz;

• messages are sent to every node of the neighbourhood, through broadcast, or sent to a specific

Region-Of-Interest (ROI);

• the maximum reasonable latency varies between 50 and 500 ms.

2.2.2 Facilities layer

Facilities layer described in standard TS 102 637-1 [23] is responsible for generating support services to

applications, in order to allow several nodes to share a common service. It is on this layer that standard

messages are defined, so that every node has access to data described in the same structure. Thus,

the definition of the cooperative environment depends on sending/receiving the following messages: Co-

operative Awareness Message (CAM) [24] and Distributed Environmental Notification Message (DENM)

[25].

This section describes the services that manage the messages CAM and DENM: Cooperative Aware-

ness Service (CA service) and Distributed Environmental Notification Service (DEN service), respec-

tively.

CA service

The CA service disseminates CAM messages that are used by other nodes to improve the awareness

of the environment. These messages contain the node’s static and dynamic information, such as the

station type, time, position, speed, among others. CAM is periodically sent, with a frequency that varies

between 1 and 10 Hz. When a CAM is received by a node, it will store its information on a database

called Local Dynamic MAP (LDM) [26]. In [27] the transmission rate of CAM was studied and was

concluded that a single node can easily receive 500 CAM every second. The authors suggested that, to

restrict the amount of received data, application should select the most relevant CAM, possibly occurring

omission or not having the most recent information possible.

DEN service

The DEN service is used to disseminate events that allow other nodes to be informed on abnormal

conditions that either impact road safety or traffic efficiency. A DENM contains information that describes

13

the event and its evolution. These messages can be transmitted until the event that generated them has

ended, which can lead to a long period of time. The contents of this information is also stored in LDM,

in order to have a real-time knowledge of the environment.

2.2.3 Network & Transport layer

As in the application layer, the network & transport layer is also split in two parts: a group for normal

applications, that use protocols such as IP, TCP and UDP, and another group for new applications, that

require different protocols to make possible messages dissemination.

Below, it is presented the concept associated to the way these new applications communicate -

geocast- to introduce the new networking and transport protocols used in the European case.

Geocast communication concept

As present in ETSI standards and in a document produced by EU-US ITS Task Force with consider-

ations about GeoNetworking [28], Geocast is the communication mode used when sending a message

to a specific geographic area is necessary. This communication mode is very specific, since it sends

its messages to a location, without knowing if that location has nodes inside of it. This and many other

questions are presented when Geocast is studied. Maybe the most important question about this issue

is the ability of a node to transmit a message to a geographic area, giving the different forwarding tech-

niques used in different cases. In this subsection, these forwarding techniques are explained, from the

beginning of the process, until the end.

When a node intends to send a message to a Region of Interest (ROI), it is mandatory to have

awareness of its surroundings and, on the other hand, to make itself ”alive” for other nodes, so that

these can also know of its existence. To do so, a node will send the CAM message detailed in section

2.4.2. to its neighbours. This message will be sent in Single-Hop Broadcast mode (SHB), which consists

of broadcasting the message in only one step, as showed in figure 2.4. Thereby, the node will warn its

direct neighbors of its presence. However, this routing mode is not bidirectional, which means that the

sender node will not receive any confirmation of the reception of its message by other nodes, making the

reception of a CAM message sent by other nodes the only way possible to know about its surroundings.

Figure 2.4: Single-Hop Broadcast.

In [29] a model is presented where a CAM message is only sent once, so that the networks’ band-

width is less occupied. This is not a good method in dense VANET networks, since its nodes are

14

constantly on the move and, as a consequence, neighbors of a certain node can change in a fraction of

second, leading to a lack of updated awareness of nodes’ surroundings.

After the node is able to have awareness of its surroundings, it has to find where the ROI is located.

If the transmitter node is located inside of the geographic area, the DENM message will be GeoBroad-

casted, that is to say the message will be broadcasted, based on the transmitter’s geographic location

and size/format of ROI (figure 2.5).

In standard 636-4-1 [30] are defined three pseudo-algorithms to achieve GeoBroadcast and, in [31],

a study was performed on their performance in terms of reliability, latency and overhead, in a VANET

placed on a highway.

Figure 2.5: GeoBroadcast.

On the other hand, if a transmitter node is not located inside of ROI, firstly, it is necessary to find if

ROI places before or after the transmitter node. To do so, a message is sent in Topologically-Scoped

Broadcast (TSB), which means that this message will also be broadcast but the number of given steps is

counted (figure 5.3). The number of steps is limited, so that the overhead does not increase significantly.

If the node could not find ROI, it is necessary to increase the number of steps.

Figure 2.6: Topologically-Scoped Broadcast.

When ROI is found, the transmitter node needs to send its DENM message to ROI. DENM message

can be transmitted by GeoUnicast, where a transmitter node sends its message to a specific node inside

of ROI - figure 2.7(a); or by GeoAnycast, where a transmitter node sends its message to any node inside

ROI-figure 2.7(b). In both cases, the message is sent hop-by-hop, passing by relays. Relays are helping

nodes that forward the message, without processing it. There are some protocols that use the features

of relays, like IVG, Cached Geocast and DRG.

GeoUnicast and GeoAnycast are used when ROI is located behind or ahead of the transmitting

node. In the specific case where ROI is behind the transmitting node, GeoUnicast and GeoAnycast use

15

(a) Same direction GeoUnicast.

(b) Same direction Anycast.

Figure 2.7: Comparision of forwarding techniques GeoUnicast e GeoAnycast.

as relays the nodes that move in an opposite direction as the transmitting node. This technique is called

Reverse Direction and is usually used in environments like the highway (figure 2.8). The DTSG protocol

[32] uses this technique, specially because vehicles circulating in the opposite direction are dislocating

towards ROI and, given the high speeds they can reach, the message will reach its destination much

faster.

Figure 2.8: Reverse Direction GeoUnicast.

Finally, the message is propagated by GeoBroadcast in the specific geographical region.

These forwarding techniques are explained in standards EN 302 636-1 and EN 302 636-2. It was

only because of these concepts that Networking and Transport layer was standardized.

Transport Protocol - BTP

In standard EN 636-4-1 [30] the transport protocol that cooperative applications use is described: Basic

Transport Protocol (BTP). This protocol has as main objective to multiplex messages coming from the

facilities layer (CAM and DENM) in order to send them through the network protocol and, on the other

hand, dis-multiplex incoming messages if the node behaves as a destination node. To identify the ITS

nodes, the concept of port from IP protocol is used, as long as the source and destination ports are well

16

defined. Similarly to what happens with IP protocols concerning with UDP, the network protocol will be

responsible to deliver packages to ITS nodes and BTP protocol delivers these packages to the facilities

layer that will process the information received and perhaps send it to a C-ITS application. Therefore,

the BTP protocol can be compared to the UDP protocol since it is considered a light protocol (its header

only has 4 bytes) and it is not trustworthy, since packages can arrive out-of-order, duplicated or might

not even arrive to its destination.

Network Protocol - GeoNetworking

In ETSI EN 302.636 group of standards is described the network protocol that cooperative applica-

tions use: GeoNetworking. This is the protocol that implements geocast concept presented previously

that, shortly, uses the geographic location to decide where to disseminate messages. It is extremely

important to learn how this protocol generates the nodes’ address and how it makes possible the for-

warding of messages.

• Geographic Addressing - Unlike typical network protocols, where nodes of a network need to

have an identification, like an IP address, to be able to disseminate messages, GeoNetworking

Protocol does not need to know nodes’ identification to be able to send messages. It only needs to

know the geographic area to cover and messages are sent to the nodes that belong to that region.

• Geographic Forwarding - To forward packets, it is assumed that networks’ nodes have knowledge

of their surroundings and that theses packages have a specific geographic location or area as a

destination. Therefore, when a node receives a package, it compares the geographic region with

its own geographic location, as well as with its neighbours geographic locations and takes actions

accordingly: obtains the package information to process and transmits it, transmits the package

without processing its information or simply ignores the package. Thus, forwarding tables are not

necessary, since it would be completely unbearable for these networks with such distinct features.

Although the GeoNetworking protocol does not specifically need to use the IP protocol, ITS nodes

also have to behave has internet routers or hosts, which means that they have to use this protocol. The

specifications that need to be fulfilled so that ITS nodes can support IPv6 are described in standard 302

636-6-1 [33].

In the specific case of using GeoNetworking in VANETs, this protocol meets the specifications of

these types of networks: it is very efficient for networks with high mobility of the nodes and with variable

geometry. With particular focus on C-ITS applications, since its messages need to be transmitted quickly

and with guaranteed spread, GeoNetworking is the most suitable protocol.

2.2.4 Access layer

The standard that describes access technologies is EN 302 663 [34]. In this document, it is said that

the technology in this layer is called ITS-G5 and refers to the lowest layer of the protocol stack in figure

2.3. This layer can be sub-divided into other two layers: Data Link Layer (consisting of Logical Link

17

Control Layer - LLC - and Medium Access Control - MAC) and Physical Layer, as presented in figure

2.9. The current version of the standard, proposes the use of 802.11p technology [35].

Figure 2.9: Interface IN-SAP specification. [34]

As a brief explanation of this layer, figure 2.10 presents its architecture in standard TS 102 724

[36]. Channel Configuration Entity is responsible to allow transmission requests, to process requests

parameters, to choose the channel and to forward the request to the LLC of the selected channel. LLC

controls data flows and possible errors before passing the request to the selected channel.

Figure 2.10: Access layer architecture [36]

Next, the frequencies’ allocation in Europe, data and physical layers are explained.

Logical Link Control - LLC

This sub layer is described in standard IEEE 1609.4 [37] and is responsible for channels access co-

ordination. When several ITS nodes need to access many channels in a short period of time, some

interference may occur. To prevent this situation it was created a Rendezvous channel and a common

period of time to all devices, Universal Coordinated Time (UCT). UCT is divided in 10 synchronization

periods, with 100 ms each. Each synchronization period is segmented in a control channel and ser-

vice channel, both with 50 ms (where only 46 ms are effectively used, since 4 ms are the guard band).

Therefore, nodes can broadcast a message to a control channel randomly chosen but, if the message

arrives during the service channel period of time, the channel is considered busy and the message is

saved in a vector so that in the next period of the control channel, the message can be transmitted. The

allocation of these messages in a vector is also based in their priority level. Thus, in spite of the short

18

period of time that exists to transmit messages (46 ms), it is possible to avoid media congestion and loss

of crucial information.

Media Access Control - MAC

Mac layer in 802.11p is based on MAC layer of technology 802.11a, where a group of stations

that want to communicate between themselves need to be registered in a Basic Service Set (BSS). A

BSS is formed when an Access Point (AP) is connected to mobile devices and to a wired network, and

also need to share control information so that communication can be correctly established. However,

given time to establish connection between elements of a BSS is not supported by VANETs, since data

sharing needs to be done very quickly and latency caused by authentication/association and security

cannot occur. To answer to this question, in amendment 802.11p, a mode that deactivates all control

procedures in a BSS was created and is called Outside the Context of a BSS (OCB). In this mode, it is

only necessary to choose the channel to establish communication.

To access the media, it is used Enhanced Distributed Channel Access (EDCA) method. In this, there

are 4 queues to put specific messages. In [38], it is stated that this division is not enough to establish

priorities regarding messages transmission and is suggested some changes to address this situation.

In [39], applications are distributed to a specific channel, according to its category: AC[3] for emergency

information coming from RSUs or vehicles; AC[2] for information about the existence of vehicles and their

speed; AC[1] for information that is non-related to other vehicles’ safety; AC[0] for information related

with entertainment and comfort.

This method works along with Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA),

which means that, the one that intends to transmit, will ”listen” the channel before making the transmis-

sion [40]. If the media is free during a period of time AIFS (Arbitration Inter-Frame Space), the node

can transmit its message, assigning a random backoff time. This random time is selected between

[0, CW+1], where CW stands for the Contention Window. CW will begin in a minimum value and will

duplicate if the next transmission was not successful, until it reaches a maximum value. Backoff will

only reduce when the channel is empty and, when it reaches zero, the transmission can happen. CW’s

maximum and minimum values for each queue are presented in table 2.5.

AC[i] CW min CW max AIFS0 15 1023 58 us1 15 1023 110 us2 7 15 71 us3 3 7 58 us

Table 2.5: CW and AIFS timing for each AC[i] queue.

Physical Layer - PHY

The physical layer, also described in IEEE 802.11p [35], is divided into two sub layers: PMD (Physical

Medium Dependent), responsible to convert symbols and to transmit them to the media, and PLCP

19

(Physical Layer Convergence Prodedure), responsible to connect data layer to PMD.

PMD uses OFDM (Orthogonal Frequency Division Multiplexing), a data coding method used in car-

rier frequencies and highly efficient against interferences. In order to make this technique efficient in

vehicular environments, OFDM is implemented with half of the clock time that is used for other commu-

nications, like Wi-Fi communication, which enables the reduction of channels’ size from 20 MHz to 10

MHz (as stated in the subsection of frequency allocation) and, consequently, makes other parameters

change, as illustrated in table 2.6.

In sub layer PLCP, the signal is coded to be transferred to the MAC layer.

Parameters 802.11p Wi-FiChannel Bandwith 10 20Data transmission Rate(Mbps) 3, 4.5, 6, 9, 12, 18, 24, 27 6, 9, 12, 18, 24, 36, 48, 54

Modulation BPSK, QPSK, 16QAM,64QAM

BPSK, QPSK, 16QAM,64QAM

Coding 1/2, 2/3, 3/4 1/2, 2/3, 3/4Interval between OFDMsymbols (us) 8 4

Table 2.6: Comparision of 802.11p and Wi-Fi communication parameters.

The next chapter describes the architecture that was used in the platform that was developed.

20

Chapter 3

Architecture

The main goal of this thesis is to provide a Geonetwork platform that might be used to test and validate

C-ITS applications for research and educational purposes.

This chapter describes the architectural approach that was followed.

It comprises a requirements section and a global architecture sections, that has all the details re-

garding GeoNetworking and its services.

3.1 Requirements

The implemented system was designed in order to implement the following requirements:

• Flexibility, in order to develop applications that can be performed on this software and that can

run in emulated environments, to test their performance in congested VANETs;

• Modularity, in order to promote modules’ replacement to test new approaches and functionalities;

• Reduced complexity, so that the software can be tested in systems with limited performance.

• Standard-compliance, to create a software to test the performance of systems with the architec-

ture standardized by ETSI.

3.2 Global Architecture

The main purpose of the solution implemented in this thesis is the possibility to send messages to a

geographic location, without knowing if there are any nodes in that region to receive them. In addition,

the messages flow has to have low latency and with guaranteed throughput. The layer of ETSI’s archi-

tecture that implements these features is GeoNetworking and, as a consequence, the main focus of this

software’s architecture is GeoNetworking. The next section presents the architecture of the components

developed for the implemented solution.

21

3.3 GeoNetworking Architecture

The implementation of the geocast concept presented in 2.2.3 has to fulfill all application performance

requirements (both traditional and cooperative applications, as explained in 2.1.4). Considering that

these nodes are a part of dynamic VANETs, the state of the node’s surrounding can change rapidly,

given the fact that these nodes are mainly vehicles that are moving very fast and usually with an unknown

trajectory, making sudden changes to their course. When a node is inserted in such dynamic networks,

it must save self-state information, as well as neighbour-state information, in order to have knowledge

of itself and of its surroundings, as updated as possible. When a network has such specific features

related with its dynamic, the identification of the nodes cannot be handled with IP addresses, as used

in traditional applications. Therefore, the key factor to identify nodes in this architecture is their location.

GeoNetworking layer is the one responsible to store and update the information of the nodes - LocalInfo

Service, to send its information to other nodes, so that they know it exists - Beaconing Service, to

generate the message that the application wants to send to a specific geographic region, - GeoMessage

Handling Service, and to identify the location of a specific node - Location Service.

Thus, in order to meet the requirements that were just explained, GeoNetworking layer has four main

services:

• LocalInfo Service - service responsible for maintaining the information about the node updated,

such as its identification and location.

• Beaconing Service - service responsible for having up-to-date information about the node’s neigh-

bourhood either by sending its own keep-alive (beacons) messages to its 1-hop neighbours or by

receiving and managing beacons received from its neighbours.

• GeoMessage Handling Service - service responsible for managing the transmission and recep-

tion of messages regarding the forwarding techniques explained in 2.2.3.

• Location Service - service responsible for finding the location of a specific node, when the node

needs to send a GeoUnicast message to an unknown destination.

Figure 3.1 shows the global architecture of GeoNetworking Layer and the interaction this layer has

with adjacent layers (Facilities and Access).

In the following subsections, the architecture of each one of these four services is explained.

3.3.1 LocalInfo Service component

The Local Info Service is necessary to maintain the node’s information up-to-date so that the node can

share it with their neighbours in order to participate in the cooperative environment. For this, the node

uses two complementary types of information: static information, such as its identification, and dynamic

information, such as its position and speed.

ETSI standard defines two structures to convey such information:

22

Figure 3.1: Global Architecture with focus on GeoNetworking Layer [19]

• GeoNetwork Address (GN ADDR) - describes the node’s static information and comprises the

type of node, the node identifier, legal domain information and the address of the network interface

card.

• Local Position Vector (LPV) - comprises all the fields that represents the node’s dynamics,

namely, the position, speed, heading and altitude values that are measured in a given time in-

stant.

In the standard, the GN ADDR information is retrieved from the Management Information Base (MIB)

or through the interface with the upper layer.

Regarding the LPV, it is retrieved from the GPS reader of the in-veichle network. Note that, LPV

needs to be periodically updated, since a VANET is a network with variable geometry and the node’s

location and movement dynamics can change drastically within seconds.

3.3.2 Beaconing Service component

The Beaconing Service is responsible for keeping up-to-date information of the node’s neighbours. For

that, the node maintains a table with all known and active nodes. ETSI standard refers this table as

Location Table (LocTable). The LocTable has one entry per known node, that basically contains the

node information and status information (flags), used to support GeoNetwork protocol operation.

To keep the neighbourhood information updated, each node has to make itself alive to other nodes.

In order to accomplish this, it sends to its 1-hop neighbours periodic messages - Beacons - with its

own information (LPV). Every time a node receives a Beacon, it updates its view of the network in the

LocTable with the information received from the neighbour that sent the Beacon. A new entry is created

if the sending node is unknown, or updated otherwise. After a given period of time without receiving any

information from a node, the LocTable entry of the corresponding node is removed.

23

Figure 3.2: Node Info Service detailed architecture [19].

Figure 4.28 outlines the interactions of this service.

Figure 3.3: Node Info Service detailed architecture [19].

3.3.3 Location Service component

As stated before, the entire communication process of GeoNetwork architecture is based on the node’s

position. So, whenever a node needs to send data to a specific destination node, such as in GeoUnicast

mode, the position of that destination node must be previously known to allow the node to select the

neighbour that must be used to forward the messages.

The Location Service is triggered when the node needs to send a GeoUnicast message to a node

with unknown position.

To initiate the location process, the source node creates an LS request message that is spread

through the network. In order to avoid flooding the entire network with requests (for instance, to inactive

24

or very distant nodes), the number of hops over which the message is forwarded is limited by an upper

bound, previously configured. Whenever a node receives an LS request message it may either reply,

if the destination node is itself or, in other cases, forward the message until the maximum number of

hops is reached. The destination node replies with an LS reply message, containing the information of

the destination node’s location. This answer is sent hop-by-hop back to the source node. Due to the

network dynamics, the source node may repeat the LS request, if, after a given time interval, no reply is

received. This process is limited to a maximum number of attempts. Figure 3.4 outlines the message’s

diagram of this service.

Figure 3.4: Location Service message diagram [19].

During this process, all incoming GeoUnicast messages for that destination cannot be sent to the

network. In order to avoid losing relevant information, these messages are placed in a buffer, until the

location process is over.

If the node receives the confirmation of the destination location, it flushes the buffer with the GeoUni-

cast message. In case the messages are compliant with the application latency requirements they will

be sent, otherwise they will be dropped. If the node does not receive any information of the destination

position within a given period of time, it will abort the location service and discard all the messages that

have been stored in the buffer.

Figure 4.34 outlines the interactions of this service.

3.3.4 GeoMessage Handling Service component

The GeoMessage Handling Service is responsible for sending GeoMessages to its surroundings. The

service must be able to support applications with different requirements and provide support to different

modes of communication.

For instance, CA messages are transmitted within 1-hop neighbours, while DEN messages may be

spread within a ROI, broadcast through n-hops or, eventually, targeted to a specific node. This is the

25

Figure 3.5: Location Service detailed architecture [19].

service that creates these messages, to be spread in the network, according to their specifications.

There are 5 different messages that can be generated in this service.

• Single-Hop Broadcast (SHB) - message created to be transmitted to the node’s 1-hop neigh-

bours.

• Topologically-Scoped Broadcast (TSB) - message created to be transmitted to the node’s n-hop

neighbours.

• GeoBroadcast (GeoB) - message created to be transmitted to all the nodes included in a ROI.

• GeoAnycast (GeoA) - message created to be transmitted to one of the nodes that are included in

a ROI.

• GeoUnicast (GeoU) - message created to be transmitted to a node that is located in a specific

destination.

These messages have common fields, such as the location of the sender node or the lifetime of the

message and, on the other hand, each message has specific fields: in SHB and TSB, the number of hops

must be mentioned; in GeoB and GeoA, the ROI must be well defined and, in GeoU, the identification of

the destination must be included on the message. Common and specific fields are mandatory, in order

for the receiver nodes to process received information.

Equivalent to Location Service, when a Geo-message needs to be sent but there are no known

neighbours, these messages cannot be sent to the network. Instead, these messages are placed in a

buffer. When the node has neighbours, this buffer is flushed. If these messages have reach their lifetime,

in similarity to the events in Location Service, the messages are dropped.

It is on this service that received geo-messages are processed. According to its category, the Ge-

oMessage Handling Service will act properly and send the original message to the upper layer.

Figure 3.6 outlines the interactions of this service.

26

Figure 3.6: GeoMessage Handling Service detailed architecture [19].

3.4 Synthesis

With all the components of the GeoNetworking layer described, there is the need to explain how and

when these will work. On one hand, there are services that need to be working throughout the lifetime

of the node, such as the NodeInfo Service (in order to have the must updated location of the node

itself) and Beaconing Service (in order to make the node alive for all its neighbours, the old and new

ones, and to maintain the LocTable updated with the information received in Beacons from other nodes).

On the other hand, there are services that are only triggered when an event occurs. For instance,

the GeoMessage Handling Service will be activated when it receives a message from the Facilities

Layer and the Location Service is only activated when the node wants to send a GeoU message and

the location of the destination is unknown. More specifically, the GeoMessage Handling Service will

generate an SHB message when a CAM is received from the upper layer (since CAM requires to be sent

within 1-hop neighbours and SHB is the specification that fulfills this requirement) and other messages

will be generated when a DENM is received. Since a DENM is an alert message and its spreading

conditions can be different depending on the situation, TSB will be generated when the node wants to

send information to the closest neighbours (1-hop to n-hop neighbours) GeoB will be generated to warn

all nodes of a geographic region, GeoA to alert only one node of a geographic region and GeoU to alert

only one specific node.

As far as interactions with adjacent layers is concerned, the components have interactions with the

Access Layer every time it is necessary to send a message to the network or to process messages that

were sent by other nodes (Beaconing Service when it wants to send/receive a Beacon, Location Service

when it wants to send/receive an LS Request or LS Reply and GeoMessage Handling Service when it

wants to send/receive an SHB, TSB, GeoB, GeoA or GeoB). The only component that has interactions

with the Facilities Layer is GeoMessage Handling Service. Every time it receives a message from the

27

upper layer, it creates the corresponding message and sends it to the lower layer; every time it receives

a message from the outside world, it process its information and sends the original message to the

Facilities Layer, so that the applications can act based on the received information. The only component

that does not interact with the other layers is the Node Info Service, since its purpose is to update node’s

structures, that are not necessary for other layers.

Figure 3.7 shows the services described in subsections 3.3.1, 3.3.2, 3.3.3 and 3.3.4, with all the

interactions between each other, with other layers and with the node’s structures.

Figure 3.7: GeoNetworking detailed architecture [19].

In the next chapter, the implementation requirements and options are explained.

28

Chapter 4

Implementation

This chapter explains the implementation of the architecture described in chapter 3 in a software de-

veloped for this thesis called GeoNetworking. This name was chosen because the main focus of this

study is the GeoNetworking layer, even though some very simple implementations of other layers were

implemented in order to simulate this software functioning correctly. In the following sections, general

implementation options are explained, as well as the components of the software and their interactions

with each other.

4.1 System overview

As stated before, the system aims to create a platform that enables students to create their own appli-

cations and evaluate the performance in an environment similar to reality, as much as possible.

In order to perform tests with this platform, a toy city was created with infrastructures and vehicles

that are equipped with a low-cost sensing and computing platform to execute this software. Raspberry

Pi single-board computing platform was selected to deploy the geocast platform due, to the good ratio

in terms of performance, flexibility and cost it offers. Performance studies may also be realized by

emulating a set of nodes (non-physical devices) that are part of the network and represent situations of

different traffic intensity. Therefore, the software used for the nodes will be the same used for emulation

purposes. Figure 4.1 depicts an example of the city model currently used by the students.

The Geocast platform represents the ETSI standard perspective of a VANET, although some simpli-

fications were needed to allow the deployment in the computing platforms selected.

4.2 Implementation options

In terms of implementation, there were a few important options that were taken in order to satisfy the

goal of our system.

Firstly, and since it will be mainly used for education and research purposes, the Python 3 language

was chosen because it focuses on code readability and it is one of the programming languages that

29

Figure 4.1: SmartMob system

students learn to use. The fact that Python can be used in embedded systems was also an important

feature. In [41], it is stated that Python is the fastest-growing language for embedded computing, given

its simplicity to write and its well-defined data structures, that manage memory without extra coding.

This is an important feature since students will test its performance in machines with lots of nodes, to

get closer to reality. These machines can be their personal computers or Raspberry Pi provided in class.

The Geonetwork platform offers a set of functionalities that spawn over different layers of the protocol

stack and must be performed concurrently.

The main services of the GeoNetworking layer described in chapter 3 were created with threads

[42]. Other possible structures to use instead of threads would be processes [43]. Threads were chosen

because they have lighter weight operations, share memory with the process they belong to, making

inter-thread communication faster (a critical point in this work) [44]. Communication between threads is

done with event objects [45]. This data class was used whenever a thread needed to activate another

and to make a thread do something with a pre-defined periodicity. To send/receive messages between

threads, queues [46] were used. It was decided to use this method, since queues reduce the memory

cost for storing thread stacks in the application’s memory space, reduce the code to create, configure,

manage and schedule work with threads. In overall, queues make possible to simplify the code and is

highly efficient in terms of managing threads, as explained in [47]. Messages passed between threads

need to have a well-defined structure and in compliance with ETSI’s standards. To accomplish this

30

attribute, the messages are stored in dictionaries [48] that, although are not the usual way of storing

information, they are more flexible to maintain. To place these dictionaries in the queues, they are firstly

converted in text using JSON [49] and, when they are retrieved from another thread, they are converted

back to its original structure.

To make possible the communication between different nodes, IPv6 UDP sockets were used to com-

municate with every node of the neighbourhood. Since this is a software that has to run in Raspberry

Pi and the network interface is not well-defined, a solution that is already well documented and uses

802.11a was the simplest way to put the nodes communicating with each other, although this is not the

protocol used in cooperative applications. IPv6 was used instead of IPV4 and UDP multicast instead of

TCP to make the solution closer to the standards.

This software also registers its states in a log file [50] to extract its results and draw conclusions

about its performance. The disadvantage of using log files is that it requires more storage, since the

information placed in these files can increase exponentially with the time that the software is running.

The next section gives a straightforward view of the main structures implemented, to give an overall

vision of the solution implemented.

4.3 Software organization

In figure 4.2 is presented a simple view of the implemented solution. As stated before, the main focus of

this work is the GeoNetworking layer described in ETSI’s standards but, in order to test its performance,

a simple implementation of the adjacent layers were required. Thus, this software implements Facilities,

GeoNetworking and Access layers.

Firstly, the software has services implemented with threads, so it can be receiving and transmitting in-

formation at the same time, independently of other services. Additional threads were created to simulate

the Access and Facilities layer. As far as GeoNetworking is concerned, threads represent the services

described in 3.3. Some of the services had to be divided into 2 sub-services, since it is requires the

transmission and reception of information simultaneously (same colours represent the same service).

As far as communication between threads is concerned, this is made with queues. There are queues

to transmit data (for example, the queues to send/receive data) and queues to put data that cannot be

transmitted immediately (for example, when the location service is pending or there are no neighbours).

As far as data structure is concerned, GN ADDR, LPV and LocTable are structures that are shared

between all threads and, when one of these structures is being updated, a lock is used to prevent

unsyncronization writings to these structures. Lastly, there are events to establish execution timings or

to terminate the execution.

4.3.1 Code organization in files

In terms of code organization, the software is divided in 13 files that have functions regarding its

services: LocalInfoService.py, BeaconingService.py, BufferMngt.py, Exit.py, FacilitiesServices.py, Ge-

31

Figure 4.2: Components and interactions of the main program GeoNetworking.py.

oMsgReceiverHandler.py, GeoMsgTransmissionHandler.py, getmac.py, Header.py, LocationService.py,

LocTable.py, Multicast.py, being the main file GeoNetworking.py. The next subsections describe the

content of these files, starting from the lower layer to the upper layer, in opposite of what happens in

previous sections, given the complexity of the solution implemented.

4.3.2 Main Code - GeoNetworking.py

The command GeoNetworking.py [nodeID] is used to start the platform. The argument nodeID must

be an integer and, if no argument is given, it is assumed that the nodeID is 1. This is extremely necessary

for this platform, in order to emulate the system with several nodes in the same machine. When this

command is used, all threads are initialized, as well as the data structures and communication queues.

Figure 4.3 presents the pseudo-code of this file.

Figure 4.3: pseudo-code of GeoNetworking.py.

32

4.3.3 Multicast Layer - Multicast.py

Multicast.py is the file that simulates the Multicast layer of a C-ITS. The GeoNetworking layer communi-

cates with this layer through SendMulticastQueue, putting in this queue the packets it wants to send to

the media; On the other hand, this layer communicates with GeoNetworking layer through ReceiveMul-

ticastQueue, putting in this queue received packets from the media.

This layer has two main functions:

• SendMulticast - function that sends the packets inserted in SendMulticastQueue to the media,

according to the pseudo-code described in 4.4.

Figure 4.4: pseudo-code of sendMulticast.

• ReceiveMulticast - function that waits for the reception of a frame in the multicast group and,

when it does, puts it in the ReceiveMulticastQueue, according to the pseudo-code described in

4.5.

Figure 4.5: pseudo-code of receiveMulticast.

Figure 4.6 shows the components and interactions of this file.

4.3.4 GeoNetworking Layer

The GeoNetworking layer is the one where this thesis focus more thoroughly. This layer is composed

by functions related with the update of the nodes’ structures, functions to create packets with common

structure to be handled properly during all the states of this software and, finally, functions to provide the

services described in 3.2 that use the node’s structures and packets structured commonly.

33

Figure 4.6: Components and interactions of Multicast.py.

Creation and Maintenance of Node’s Structures

As stated before, a C-ITS node has three structures: GN-ADDR, LPV and LocTable. In addition, it has

all the queues described in 4.3. These structures need to be updated frequently and automatically, which

results in the construction of three files to manage this structures: LocalInfoService.py, LocTable.py and

BufferMngt.py.

• LocalInfoService.py - has the functions that update GN-ADDR and LPV structures:

– getGN ADDR - function that gets the GN ADDR of a nodes file and finds its MAC address,

according to the pseudo-code described in 4.7.

Figure 4.7: pseudo-code of getGN ADDR.

– updateLPV - function that acts as a GPS reader. It periodically reads the LPV file of a given

node and gets its coordinates (latitude and longitude) and the time acquired, according to the

pseudo-code described in 4.8.

Figure 4.8: pseudo-code of updateLPV.

LocTable.py - has the functions that update LocTable structure and that extract some of its infor-

mation:

34

– checkEntriesLocTable - function that checks periodically if a node that is inserted on LocTable

is still alive, according to the pseudo-code described in 4.9.

Figure 4.9: pseudo-code of checkEntriesLocTable.

– checkIsNeighbour - function that checks if the LocTable is empty (no neighbours) or if it has

any records, according to the pseudo-code described in 4.10. It also flushes the buffer that is

storing the messages that cannot be sent of there are no neighbours.

Figure 4.10: pseudo-code of checkIsNeighbour.

– updateLocTable - function that updates the LPV of a given node, according to the pseudo-

code described in 4.11.

Figure 4.11: pseudo-code of updateLocTable.

– removeEntry - function that removes a node of the LocTable, according to the pseudo-code

described in 4.12.

– readLocTable - function that returns a node’s LPV, accordingly to its location, according to

the pseudo-code described in 4.13.

35

Figure 4.12: pseudo-code of removeEntry.

Figure 4.13: pseudo-code of readLocTable.

– checkLocation - function that checks if LocTable has a node with a certain location, accord-

ing to the pseudo-code described in 4.14.

Figure 4.14: pseudo-code of checkLocation.

• BufferMngt.py - has the functions that manage this software’s queues:

– writeBuffer - before putting a packet in a queue, it firstly checks if the packet is still valid,

according to the pseudo-code described in 4.15.

Figure 4.15: pseudo-code of writeBuffer.

– getPacketFromBuffer - gets a packet form a queue but, instead of returning it automatically,

checks if the packet is valid, according to the pseudo-code described in 4.16.

36

Figure 4.16: pseudo-code of getPacketFromBuffer.

– removeBufferHead - as the name implies, it removes the first package of the queue (the

oldest one).

– flushBuffer - deletes from memory a given queue.

– flushPkt - flushes all the packages of a given queue, putting them in SendMulticastQueue.

– validPkt - checks if a packet is valid, which means that it didn’t exceed its lifetime, and updates

several fields of LocTable, according to the pseudo-code described in 4.17.

Figure 4.17: pseudo-code of validPkt.

Figure 4.18 shows the components and interactions of some of this functions.

Figure 4.18: Components and interactions of the functions that updates the node’s structures.

Creation and Maintenance of packets’ common structure

As shown in figure 3.1, the messages that need to be transmitted to the media need to have a specific

structure, called CommonHeader. It is because of this structure that the software can check the same

fields independently of the type of packet transmitted. Thus, Header.py is the file that has the functions

related with the management of the CommonHeader. This file has the following functions:

37

• createCommonHeader - function that creates the CommonHeader giving the inputs described in

table 4.1, according to [ETSI EN 302 636-4-1].

Table 4.1: CommonHeader format.

• addTSBHeader - function that adds to a previously CommonHeader created the inputs described

in table 4.2.

Table 4.2: TSBHeader format.

• addGeoHeader - function that adds to a previously CommonHeader created the inputs described

in table 4.3.

Table 4.3: GeoHeader format.

38

• addGeoUHeader - function that adds to a previously CommonHeader created the inputs de-

scribed in table 4.4.

Table 4.4: GeoUHeader format.

• getSenderFromCommonHeader - function that returns the LPV of the sender in a packet.

• getDestinationFromLSHeader - function that returns the LPV of the destination in a LS packet.

• getDestinationFromGeoUHeader - function that returns the LPV of the destination in a GeoU

packet.

• getSourceFromTSBHeader - function that returns the LPV of the source in a TSB packet.

• processCommonHeader - function that updates the LocTable with the LPV received in a given

packet and flushes the sender’s LS-Buffer, according to the pseudo-code described in 4.19.

Figure 4.19: pseudo-code of processCommonHeader.

• removeCommonHeader - function that removes the CommonHeader of a packet, keeping the

original format of the message received by Facilities Layer.

Services

In order to send/receive messages according to a geo-location, the services described in section 3.2

need to be implemented. The Beaconing Service was implemented in BeaconingService.py, Location

Service in LocationService.py and GeoMessage Handling Service was divided into two files: GeoMsg-

TransmissionHandler.py and GeoMsgReceiverHandler.py.

• GeoMsgReceiverHandler.py - This file has the thread that handles received messages from the

media and routes them to the correct handler. It has the following functions:

39

– GeoMsgReceiverHandler - this thread is responsible to handle the received messages from

the Multicast Layer, that are stored in ReceiveMulticastQueue. It was designed to be the

manager and the forwarder of other messages, such as a Beacon or a LS-related, so that

this software could be handling three types of messages at the same time. Thus, it acts

accordingly to the type of the received message:

∗ if the packet is a Beacon, this function puts the Beacon in the BeaconQueue to be han-

dled separately;

∗ if the packet is a LS-related, this function puts the LS-related packet in the LS-Queue to

be handled separately;

∗ if the packet is Geo-related, it calls one of the following functions, depending on the type

of the received Geo-related packet:

· receiveSHB - function that processes the received packet, removes the Common-

Header and puts the packet in the ReceiveFacilitiesQueue, according to the pseudo-

code described in 4.20.

Figure 4.20: pseudo-code of receiveSHB.

· receiveTSB - function that processes the received packet, removes the Common-

Header, puts it in the ReceiveFacilitiesQueue and, if it hasn’t reached the maximum

number of hops, forwards it (putting the packet in SendMulticastQueue), according to

the pseudo-code described in 4.21.

Figure 4.21: pseudo-code of receiveTSB.

· receiveGeoB - function that processes the received packet, checks if the node is

inside of the ROI defined in the packet and, if it does, removes the CommonHeader,

puts it in the ReceiveFacilitiesQueue and, if it hasn’t reached the maximum number

40

of hops, forwards it (putting the packet in SendMulticastQueue); if the node is outside

the ROI and it hasn’t reached the maximum number of hops, it simply forwards the

packet, according to the pseudo-code described in 4.22.

Figure 4.22: pseudo-code of receiveGeoB.

· receiveGeoA - function that processes the received packet, checks if the node is

inside of the ROI defined in the packet and, if it does, removes the CommonHeader

and puts it it the ReceiveFacilitiesQueue; if the node is outside the ROI and it hasn’t

reached the maximum number of hops, forwards it (putting the packet in SendMulti-

castQueue), according to the pseudo-code described in 4.23.

Figure 4.23: pseudo-code of receiveGeoA.

· receiveGeoU - function that processes the received packet, updates LocTable source

information, checks if the node is the destination and, if it is, removes the Common-

Header and puts it in the ReceiveFacilitiesQueue; if the node is not the destination

and it hasn’t reached the maximum number of hops, forwards it (putting the packet in

SendMulticastQueue), according to the pseudo-code described in 4.24.

Figure 4.25 shows the components and interactions of this thread.

• BeaconingService.py - this file has the the threads that are responsible to create and to manage

the reception of beacons. It has the following functions:

41

Figure 4.24: pseudo-code of receiveGeoU.

Figure 4.25: Components and interactions of GeoMessageReceiverHandler.py.

– sendBeacon - function that generates a Beacon packet and puts it in the Queue to send it to

the media (SendMulticastQueue), according to the pseudo-code described in 4.26.

Figure 4.26: pseudo-code of sendBeacon.

– receiveBeacon - function that waits for its queue to have some packet and, when it does, it

processes it,, updating node’s LocTable, according to the pseudo-code described in 4.27.

Figure 4.28 shows the components and interactions of this service.

42

Figure 4.27: pseudo-code of receiveBeacon.

Figure 4.28: Components and interactions of BeaconingService.py.

• LocationService.py - this file has the functions that are activated when it is necessary to send a

GeoU message and the destination is unknown. It has the following functions:

– LS-EventHandler - function that waits for its queue to have some packet and, when it does,

it calls one of the following functions, depending on the type of the received packet:

– createLS Request - function that creates a packet called LS Request, used when it is needed

to send a GeoUnicast packet but the destination location is unknown. If there is already a

LS Request on demand, it puts the GeoUnicast packet on LS Buffer queue of that destina-

tion, so it can be buffered when the destination is located. If it hasn’t been started with the

search of that destination, it generates a LS Request, puts it in the queue to send the packet

to the media and repeats this process periodically calling the function repeatLS Request,

according to the pseudo-code described in 4.29.

– repeatLS Request - function called by createLS Request periodically to repeat the creation

of a LS Request. Before creating this packet once more, it checks if the retransmission

counter of the packet is equal to the maximum number of hops of the same packet and, if

it has reached the same number, it means that the timeout of retransmission is reached, it

doesn’t create a LS Request and flushes destination’s LS Buffer, according to the pseudo-

code described in 4.30.

– replyLS Request - if a LS Request is received, this function processes the packet and, if

this node is the destination described in the packet, it creates a LS Reply ; if it is not the

43

Figure 4.29: pseudo-code of createLS Request.

Figure 4.30: pseudo-code of repeatLS Request.

destination, it forwards the packet to the media, according to the pseudo-code described in

4.31.

Figure 4.31: pseudo-code of replyLS Request.

– createLS Reply - function that creates a LS Reply accordingly and puts it in the queue to

send the packet to the media, it forwards the packet to the media, according to the pseudo-

code described in 4.32.

Figure 4.32: pseudo-code of createLS Reply.

44

– receiveLS-Reply - if the node receives a LS-Reply packet, it means that the destination

was found and its records in the LocTable can be updated, ands its buffer with GeoUnicast

messages can also be flushed, according to the pseudo-code described in 4.33.

Figure 4.33: pseudo-code of receiveLS Reply.

Figure 4.34 shows the components and interactions of this service.

Figure 4.34: Components and interactions of LocationService.py.

• GeoMsgTransmissionHandler.py - this file has the thread that handles received messages from

the Facilities layer. It has the following functions:

– GeoMsgTransmissionHandler - thread that waits for SendFacilitiesQueue to have packets

and, when it does, it calls one of the following functions, depending on the type of the received

packet:

∗ sendSHB - function that creates the header of a SHB message and, if the node has

neighbours, sends it to SendMulticasQueue to be transmitted to the media; otherwise,

puts it in the queue that is flushed when a neighbour is found, according to the pseudo-

code described in 4.35.

∗ sendTSB - function that creates the header of a TSB message and, if the node has

neighbours, sends it to SendMulticasQueue to be transmitted to the media; otherwise,

45

Figure 4.35: pseudo-code of sendSHB.

puts it in the queue that is flushed when a neighbour is found, according to the pseudo-

code described in 4.36.

Figure 4.36: pseudo-code of sendTSB.

∗ sendGeoB - function that creates the header of a GeoB message and, if the node has

neighbours, sends it to SendMulticasQueue to be transmitted to the media; otherwise,

puts it in the queue that is flushed when a neighbour is found, according to the pseudo-

code described in 4.37.

Figure 4.37: pseudo-code of sendGeoB.

∗ sendGeoA - function that creates the header of a GeoA message and, if the node has

neighbours, sends it SendMulticasQueue to be transmitted to the media; otherwise, puts

it in the queue that is flushed when a neighbour is found, according to the pseudo-code

described in 4.38.

∗ sendGeoU - function that creates the header of a GeoU message and, if the node has

46

Figure 4.38: pseudo-code of sendGeoA.

the location of the destination, sends it SendMulticasQueue to be transmitted to the me-

dia; otherwise, calls the function creatLS-Request to start the process of the location of

a node that is in an exact location, according to the pseudo-code described in 4.39.

Figure 4.39: pseudo-code of sendGeoU.

Figure 4.40 shows the components and interactions of this thread.

Figure 4.40: Components and interactions of GeoMessageTransmissionHandler.py.

47

4.3.5 Facilities Layer

FacilitiesServices.py is the file that simulates the Facilities layer of a C-ITS. The GeoNetworking layer

communicates with this layer through ReceiveFacilitiesQueue, putting in this queue the packets it wants

to send to the upper layer; On the other hand, this layer communicates with GeoNetworking layer through

SendFacilitiesQueue, putting in this queue the messages it wants to send to other ndoes. This layer has

two main functions:

• FacilitiesMsgTransmission - function that generates the type of message the application wants

to send (CAM, DENM or a specific message created by the application) and puts it in the SendFa-

cilitiesQueue.

• FacilitiesMsgReceiver - function that waits for the reception of a message in the ReceiveFacili-

tiesQueue and, when it does, processes it.

Figure 4.41 shows the components and interactions of this file.

Figure 4.41: Components and interactions of Facilities.py.

The next chapter describes the implementation of all these services.

48

Chapter 5

Results

To make sure that the solution implemented would perform accordingly to the parameters stated in 3.1

, several tests were made to the developed services. The results taken for each one of the performed

tests are presented in this chapter and were based on the log files created in each one of these tests.

The section 5.1 describes the tests performed in each component of the software, isolated from other

happenings and as easily as this software can be placed, in a computer with Windows OS; the section

5.2 describes the performance of the software in a larger network, to verify if density networks affect

the performance of the software. The later happened in two machines: a computer with mac operating

system and in a raspberry pi zero.

5.1 Unit Tests

Before assembly the entire system, a set of unit tests have been made in order to verify if each one

of the components is complaint with the expected behaviour. These tests were performed in the same

machine, in order to retrieve the machine’s timing to take conclusions about its performance. Next

sections describes these tests, starting by the definition of the scenario used.

5.1.1 Unit Tests scenario

To test each one of the services independently, a simple network with 4 nodes was created, with fixed

coordinates.

These are the properties of the nodes that have been created:

• Node 1: this is the node that will be sending information. It is placed in coordinates (1;1).

• Node 2: this is one of the receiving nodes. It is placed in coordinates (2;1).

• Node 3: this is one of the receiving nodes. It is placed in coordinates (3;1).

• Node 4: this is one of the receiving nodes. It is placed in coordinates (4;1).

49

Since every node that registers in the multicast group is assumed to be neighbour of other nodes,

this service can’t be fully tested if all of the nodes of the VANET are neighbours of each other. To

overcome this issue, an if clause was added to the code that states that if the distance between 2 nodes

is superior than a reference value, then those 2 nodes aren’t neighbours. With this clause, the solution

can be completely tested. In the following tests, the reference value for the neighbourhood clause is 1,

meaning that Node 1 is neighbour of Node 2; Node 2 is neighbour of Node 1 and Node 3; Node 3 is

neighbour of Node 2 and Node 4; Node 4 is neighbour of Node 3. Figure 5.1 summarizes the scenario

implemented.Each vehicle is represented by a color and the circle of the same color represents the area

of their neighbours, which means that the vehicles inside the circle are the neighbours of that vehicle.

Figure 5.1: Unit tests scenario.

The next subsections describe the tests that took place for every service implemented.

5.1.2 GeoMessage Handling Service

To make this software closer to reality, the Geo-related messages are created in the Facilities Layer and

are processed in the GeoNetworking Layer, as shown in figure 4.2. In this section it is presented the

tests and messages diagrams of all the Geo-related modes implemented.

Single-Hop Broadcast

As stated before, Single-Hop Broadcast is the communication mode where a message is sent to 1-hop

neighbours. A real situation that could use SHB communication mode is when a node wants to send a

CA message to help other nodes improve their awareness of the environment.

With the scenario described in 5.1, node 1 will be sending 5 CA messages. Since the only direct

neighbour of node 1 is node 2, this is the node that can receive the CA message. The log files and the

message diagram in figure 5.2 shows that only node 2 receives the message after an average of 1363

ms, leading to the conclusion that SHB fulfills basic requirements.

Topologically-Scoped Broadcast

As stated before, Topologically-Scoped Broadcast is the communication mode where a message is sent

to n-hop neighbours. A real situation where a node could use TSB communication is when a vehicle

receives a message of an accident from another vehicle and wants to spread this information to its

closest neighbours.

50

Figure 5.2: Message diagram of SHB test.

With the scenario described in 5.1, node 1 will be sending 5 DEN messages to 2-hop neighbours,

meaning that node 2 and 3 have to receive this message, and node 4 cannot receive any message. The

log files and the message diagram in figure 5.3 shows that nodes 2 and 3 receive the messages after

an average of 1158 ms, leading to the conclusion that TSB fulfills basic requirements.

Figure 5.3: Message diagram of TSB test.

GeoBroadcast

As stated before, GeoBroadcast is the communication mode where a message is sent to all the nodes

that are in a ROI. A real situation that could use GeoB mode would be when a vehicle has an accident

and wants to alert a ROI, so that the vehicles in that geographic location can take other route.

With the scenario described in 5.1, node 1 will be sending a DEN message to a ROI where nodes 3

and 4 belong. The expected outcome is that node 2 is the relay, which means that it only forwards the

51

message, not processing it, and that node 3 and 4 receive it. The log files and the message diagram in

figure 5.4 shows that nodes 3 and 4 receive the messages after an average of 510 ms, leading to the

conclusion that GeoB fulfills basic requirements.

Figure 5.4: Message diagram of GeoB test.

GeoAnycast

As stated before, GeoAnycast is the communication mode where a message is sent to any node located

in ROI. A real situation that could use this mode of communication would be when a vehicle has a

mechanical malfunction and wants to alert only a single vehicle of the ROI, so it can alert its neighbours.

With this, node 1 will not fill the network of nodes that will not process these message.

With the scenario described in 5.1, node 1 will be sending a DEN message to a ROI where nodes 3

and 4 belong. The expected outcome is identical with the GeoB but instead of node 3 and 4 receive the

message, only the closest node will receive the message (in this case, it will be node 3).

The log files and the message diagram in figure 5.5 shows that node 3 receives the messages after

741 ms, leading to the conclusion that GeoA fulfills basic requirements.

Figure 5.5: Message diagram of GeoA test.

52

GeoUnicast

As stated before, GeoUnicast is the communication mode where a message is sent to a specific des-

tination. A real situation that could use this mode of communication would be when a vehicle has a

mechanical malfunction and wants to alert a police station that is located in its proximity. With the sce-

nario described in 5.1, node 1 will be sending a DEN message to the position (2;1). Since node 2 is at

this position and is node 1 neighbour, the communication has to be established.

The log files and the message diagram in figure 5.6 shows that node 2 receives the messages after

an average of 817 ms, leading to the conclusion that GeoA fulfills basic requirements.

Figure 5.6: Message diagram of GeoU test.

To test if node 1 can send GeoU messages to a destination that exists, but this node doesn’t have

that information yet, the component that is actually being tested is the Location Service.

5.1.3 Location Service

Once again, Location Service is the one responsible to find if there is a node in a specific location.

This service is triggered when a GeoU message needs to be sent, but the destination is unknown. The

Location Service will be considered well implemented if a GeoU message needs to be transmitted, the

sender node does not have knowledge of the existence of that destination node and, after a short period

of time, the destination receives the GeoU message. To simplify the results of the tests made to this

service, node 4 was removed from the scenario described in 5.1.

In the first test, node 1 wants to send a message to the location (5;1). None of the network nodes are

in this location, which means that node 1 has to be sending LS Requests to its neighbours and, when

a certain period of time passes without receiving a LS Reply, it stops trying to send LS Requests and

drops the buffer where GeoU message is stored. This test was successful and happened as showed in

the log files and in figure 5.7.

In the second test, node 1 wants to send a message to the destination (3;1), corresponding to node

53

Figure 5.7: Message diagram of the first LS test.

3 position. This node exists but node 1 does not know of its existence. In this case, the timeout is long

enough so that the location service does not stop until node 3 replies to node 1. When node 1 receives

the LS Reply, it flushes the buffer where GeoU is stored. Node 2 acts as the relay, which means that,

when it receives the GeoU message, it only forwards it, without processing it. This test was successful

and happened as showed in the log files and in figure 5.8.

Figure 5.8: Message diagram of the second LS test.

54

5.2 Performance Test

All the tests described in section 5.1 occurred in one machine with Windows operating system, making

the communication between nodes easier to happen and to make conclusions about running time of

each service. Since this software will be used by students that might run it in other OS, there was the

need to run it in other machines. In addition, the scenario in 5.1 is sparce and, as a consequence, the

vehicle network is not defined in a close way to the reality. Thus, the performance test took place to

check the behaviour of the software in machine-to-machine communication and in a denser network.

5.2.1 Performance Tests scenario

To test the performance of the software in terms of communication between machines and in a more

dense VANET, 8 nodes were initialized, both in a MAC OS machine and in a raspberry pi processor.

Each of these machines had 4 nodes, as described in figure 5.9 and all of them were neighbours. These

machines were connected through an independent Ad-Hoc network to simulate the real world in an

approximate way.

Figure 5.9: Performance test scenario.

To test if the efficiency of the software could be affected by these conditions, the 8 nodes were

running with the service that was not testes in section 5.1: the Beaconing Service. This was the service

chosen to be tested in this section, given the fact that every node will be sending beacons periodically,

every 100 ms, flooding the network with messages, as what happens in real systems.

5.2.2 Beaconing Service

As stated before, this is the service responsible to send periodic messages to the neighbours of a node,

to make itself visible in the network; on the other hand, this is the service responsible to process the

received beacons by other nodes, to allow the node to have a bigger knowledge of its surroundings. With

the scenario described in 5.9, nodes 1-8 will be sending beacons to the network with 100 ms periodicity.

55

NodeID Average (ms) Standard Deviation (ms)

Node 1 542 612Node 2 536 462Node 3 585 576Node 4 586 523Node 5 511 605Node 6 586 464Node 7 490 684

Table 5.1: Average and standard deviation for the reception of beacons in node 8, from each node.

Figure 5.10 shows the time-chart of the reception of beacons in the last node started in the raspberry pi

zero (node 8).

Figure 5.10: Evolution of beacons’ reception through time in node 8, running in raspberry pi zero, with100 ms of periodicity.

The table 5.1 shows the average and standard deviation of the reception of beacons sent by each of

the nodes.

Figure 5.11 shows the time-chart of the reception of beacons in the last node started in the macOS

(node 7), with 100 ms of periodicity.

Figure 5.11: Evolution of beacons’ reception through time in node 7, running in macOS, with 100 ms ofperiodicity.

56

NodeID Average (ms) Standard Deviation (ms)

Node 1 441 439Node 2 527 515Node 3 490 488Node 4 475 413Node 5 462 401Node 6 474 443Node 8 492 445

Table 5.2: Average and standard deviation for the reception of beacons in node 7, from each node.

The table 5.2 shows the average and standard deviation of the reception of beacons sent by each of

the nodes.

Given the results presented in 5.1 and 5.2, it is possible to conclude that both node 8 and node 7

receive beacons with an average periodicity of 548 ms and 480 ms, respectively, making a total average

of 514 ms. Given the fact that the requirements of C-ITS applications can have a maximum reasonable

latency of 500 ms as stated in 2.2.1, the performance of the software has very close results to the

requirements specified in this architecture, even when the software is running in systems less potencial

than the system implemented in real-life nodes, such as vehicles and RSU’s.

57

58

Chapter 6

Conclusions

In this chapter the achievements of this work are listed, as well as the future work that can be done.

6.1 Achievements

The major achievements of the present work are the implementation of GeoNetworking layer, fulfilling

the requirements described in ETSI standards: messages are sent in a periodic time, as long as a

certain event is taking place; the frequency of transmitted messages is reduced, as well as receiving

latency; messages are broadcasted depending on the location of the nodes. The implemented software

is also very versatile, whereas it can be placed together with other softwares, such as applications

layer simulator, and can be easily changed, accordingly to the evolution of the standards. The biggest

achievement of this work is the possibility to test the performance of the transmission and reception in

non traditional way of communication, such as geocast, where conclusions of real systems, used in real

nodes, can be taken.

6.2 Future Work

Since this software was developed not only for academic reasons, but also to be used by other students,

the future work goes through the development of different applications that test the performance of the

C-ITS system as a whole, with the implementation of BTP in the transport layer and possibly using a

real GPS-reader for the coordinates of nodes, making other complex tests involving the biggest number

of components and with the biggest network. Some tests can also be performed when change lifetime

of packets. In shortly, adjusting the software to simulate the real world as accurate as possible.

59

60

Bibliography

[1] Shanthi Ameratunga, Martha Hijar, and Robyn Norton. Road-traffic injuries: confronting disparities

to address a global-health problem. The Lancet, 367(9521):1533–1540, 2006.

[2] World Health Organization. Global status report on road safety 2015. World Health Organization,

2015.

[3] Queensland Government. About cooperative and automated vehicles,

https://www.qld.gov.au/transport/projects/cavi/cooperative-automated-vehicles.

[4] Yuh-Shyan Chen, Yun-Wei Lin, and Sing-Ling Lee. A mobicast routing protocol in vehicular ad-hoc

networks. Mobile Networks and Applications, 15(1):20–35, 2010.

[5] Abderrahmane Lakas and Moumena Shaqfa. Geocache: sharing and exchanging road traffic in-

formation using peer-to-peer vehicular communication. In Vehicular Technology Conference (VTC

Spring), 2011 IEEE 73rd, pages 1–7. IEEE, 2011.

[6] IEEE Institute of Electrical and Electronics Engineers. The world’s largest technical professional

organization for the advancement of technology, https://www.ieee.org/.

[7] ETSI European Telecommunications Standards Institute. Welcome to etsi the standards people,

http://www.etsi.org/.

[8] JISC Japanese Industrial Standards Committee. About jisc, http://www.jisc.go.jp/eng/.

[9] ETSI European Telecommunications Standards Institute. Intelligent transport systems (its); vehic-

ular communications; geonetworking; part 4: Geographical addressing and forwarding for point-to-

point and point-to-multipoint communications; sub-part 1: Media-independent functionality. ETSI

EN 302 636-4-1 V1.3.1, 08 2017.

[10] A. Benslimane A. Bachir. A multicast protocol in ad hoc networks inter-vehicle geocast. IEEE,

2003.

[11] R. Eberhardt. C. Maihofer. Geocast in vehicular environments: Caching and transmission range

control for improved efficiency. Proc. of 2004 IEEE Intelligent Vehicles Symposium (IV’04), Parma,

Italy, 2004.

61

[12] E. Schoch C. Maihofer, T. Leinmuller. Abiding geocast: time–stable geocast for ad hoc networks.

Proc. of the 2nd ACM international workshop on Vehicular ad hoc networks (VANET’05), Cologne,

Germany, 2005.

[13] M. Kihl H. P. Joshi, M. L. Sichitiu. Distributed robust geocast multicast routing for inter-vehicle

communication. Proc. of the 1st WEIRD Workshop on WiMAX, Wireless and Mobility, Wireless and

Mobility, Coimbra, Portugal, 2005.

[14] Maria Kihl, Mihail Sichitiu, Ted Ekeroth, and Michael Rozenberg. Reliable geographical multicast

routing in vehicular ad-hoc networks. In WWIC, pages 315–325. Springer, 2007.

[15] L. Brunie T. Atechian. Dg-castor: Direction-based geocast routing protocol for query dissemina-

tion in vanet. Proc. of the 4th International Workshop on Localized Communication and Topology

Protocols for Ad hoc Networks (LOCAN’08), 2008.

[16] Katrin Bilstrup, Elisabeth Uhlemann, Erik G Strom, and Urban Bilstrup. Evaluation of the ieee

802.11 p mac method for vehicle-to-vehicle communication. In Vehicular Technology Conference,

2008. VTC 2008-Fall. IEEE 68th, pages 1–5. IEEE, 2008.

[17] Stephan Eichler. Performance evaluation of the ieee 802.11 p wave communication standard. In

Vehicular Technology Conference, 2007. VTC-2007 Fall. 2007 IEEE 66th, pages 2199–2203. IEEE,

2007.

[18] EN ETSI. 302 665 v1. 1.1: Intelligent transport systems (its). Communications architecture, 2010.

[19] Teresa Vazao. Vehicular networks - network & transport layer. slides passed during class.

[20] Y. Toor, P. Muhlethaler, and A. Laouiti. Vehicle ad hoc networks: applications and related technical

issues. Communications Surveys Tutorials, IEEE, (vol. 10, no. 3, pp. 74 –88), 2008.

[21] T. Kosch, I. Kulp, M. Bechler, M. Strassberger, B. Weyl, and R. Lasowski. Communication archi-

tecture for cooperative systems in europe. Communications Magazine, IEEE, (vol. 47, no. 5, pp.

116–125), 2009.

[22] ETSI European Telecommunications Standards Institute. Intelligent transport systems (its); vehic-

ular communications; basic set of applications; definitions. ETSI TR 102 638 V1.1.1, 06 2009.

[23] ETSI European Telecommunications Standards Institute. Intelligent transport systems (its); vehicu-

lar communications; basic set of applications; part 1: Functional requirements. ETSI TS 102 637-1

V1.1.1, 09 2010.

[24] ETSI European Telecommunications Standards Institute. Intelligent transport systems (its); vehicu-

lar communications; basic set of applications; part 2: Specification of cooperative awareness basic

service. ETSI EN 302 637-2 V1.3.2, 11 2014.

62

[25] ETSI European Telecommunications Standards Institute. Intelligent transport systems (its); vehicu-

lar communications; basic set of applications; part 3: Specifications of decentralized environmental

notification basic service. ETSI EN 302 637-3 V1.2.2, 11 2014.

[26] ETSI European Telecommunications Standards Institute. Intelligent transport systems (its); vehicu-

lar communications; basic set of applications; local dynamic map (ldm); rationale for and guidance

on standardization. ETSI TR 102 863 V1.1.1, 06 2011.

[27] Jakob Breu, Achim Brakemeier, and Michael Menth. Analysis of cooperative awareness message

rates in vanets. In ITS Telecommunications (ITST), 2013 13th International Conference on, pages

8–13. IEEE, 2013.

[28] EU-US ITS Task Force. Observations on geonetworking, https://ec.europa.eu/digital-single-

market/en/news/progress-and-findings-harmonisation-eu-us-security-and-communications-

standards-field.

[29] Poonam Verma and Neeta Singh. Non-repetitive single-hop broadcast model for cam in ieee802.

11p vanets. In Contemporary Computing (IC3), 2016 Ninth International Conference on, pages

1–5. IEEE, 2016.

[30] ETSI European Telecommunications Standards Institute. Intelligent transport systems (its); vehic-

ular communications; geonetworking; part 4: Geographical addressing and forwarding for point-to-

point and point-to-multipoint communications; sub-part 1: Media-independent functionality. Final

draft ETSI EN 302 636-4-1 V1.2.1, 05 2014.

[31] Sebastian Kuhlmorgen, Ignacio Llatser, Andreas Festag, and Gerhard Fettweis. Performance eval-

uation of etsi geonetworking for vehicular ad hoc networks. In Vehicular Technology Conference

(VTC Spring), 2015 IEEE 81st, pages 1–6. IEEE - IEEE - Institute of Electrical and Electronics

Engineers, 2015.

[32] Hamidreza Rahbar, Kshirasagar Naik, and Amiya Nayak. Dtsg: Dynamic time-stable geocast rout-

ing in vehicular ad hoc networks. In Ad Hoc Networking Workshop (Med-Hoc-Net), 2010 The 9th

IFIP Annual Mediterranean, pages 1–7. IEEE, 2010.

[33] ETSI European Telecommunications Standards Institute. Intelligent transport systems (its); vehic-

ular communications; geonetworking; part 6: Internet integration; sub-part 1: Transmission of ipv6

packets over geonetworking protocols. Draft ETSI EN 302 636-6-1 V1.2.0, 10 2013.

[34] ETSI European Telecommunications Standards Institute. Intelligent transport systems (its); access

layer specification for intelligent transport systems operating in the 5 ghz frequency band. Draft

ETSI EN 302 663 V1.2.0, 11 2012.

[35] IEEE Standards Association et al. 802.11-2012-ieee standard for information technology–

telecommunications and information exchange between systems local and metropolitan area

63

networks–specific requirements part 11: Wireless lan medium access control (mac) and physi-

cal layer (phy) specifications. Retrieved from http://standards. ieee. org/about/get/802/802.11. html,

2012.

[36] ETSI European Telecommunications Standards Institute. Intelligent transport systems (its); harmo-

nized channel specifications for intelligent transport systems operating in the 5 ghz frequency band.

ETSI TS 102 724 V1.1.1, 10 2012.

[37] IEEE 1609 Working Group et al. Ieee standard for wireless access in vehicular environments

(wave)-multi-channel operation. IEEE Std, pages 1609–4, 2016.

[38] Mohssin Barradi, Abdelhakim S Hafid, and Jose R Gallardo. Establishing strict priorities in ieee

802.11 p wave vehicular networks. In Global Telecommunications Conference (GLOBECOM 2010),

2010 IEEE, pages 1–6. IEEE - Institute of Electrical and Electronics Engineers, 2010.

[39] Jose R Gallardo, Dimitrios Makrakis, and Hussein T Mouftah. Performance analysis of the edca

medium access mechanism over the control channel of an ieee 802.11 p wave vehicular network.

In Communications, 2009. ICC’09. IEEE International Conference on, pages 1–6. IEEE - IEEE -

Institute of Electrical and Electronics Engineers, 2009.

[40] Andreas Festag. Standards for vehicular communication—from ieee 802.11 p to 5g. e & i Elek-

trotechnik und Informationstechnik, 132(7):409–416, 2015.

[41] Luigi F. Cerfeda. The rise of python for embedded systems, https://www.zerynth.com/blog/the-rise-

of-python-for-embedded-systems/.

[42] Python Software Foundation. Threading — thread-based parallelism,

https://docs.python.org/3/library/threading.html.

[43] Python Software Foundation. multiprocessing — process-based “threading” interface,

https://docs.python.org/2/library/multiprocessing.html.

[44] Roderick Bauer. What’s the diff: Programs, processes, and threads,

https://www.backblaze.com/blog/whats-the-diff-programs-processes-and-threads/.

[45] Python Software Foundation. Event objects, https://docs.python.org/2.0/lib/event-objects.html.

[46] Python Software Foundation. Queue — a synchronized queue class,

https://docs.python.org/3/library/queue.html.

[47] Omar Elgabry. Threads vs queues, https://medium.com/omarelgabrys-blog/threads-vs-queues-

a71e8dc30156.

[48] Python Software Foundation. Data structures, https://docs.python.org/3/tutorial/datastructures.html.

[49] Douglas Crockford. Introducing json, https://www.json.org/.

[50] Python Software Foundation. logging — logging facility for python,

https://docs.python.org/3/library/logging.htmlmodule-logging.

64