design and development of a green light optimized speed
TRANSCRIPT
Design and Development of a Green Light OptimizedSpeed Advisory System
A Degree Thesis
Submitted to the Faculty of the
Escola Tecnica Superior d’Enginyeria de Telecomunicacio de Barcelona
Universitat Politecnica de Catalunya
by
Jordi Marias Parella
In partial fulfilment
of the requirements for the degree in
Bachelor’s degree in Telecommunications Technologies and Services Engineering
Advisor: Jordi Casademont i Serra
Barcelona, June 2019
Abstract
The present project develops a Green Light Optimized Speed Advisory System (GLOSA) system;
implementing the standardizations marked by the European Telecommunications Standards
Institute (ETSI) and Society of Automotive Engineers (SAE) within the scope of Cooperative-
Intelligent Transport Systems also called Vehicle-to-Everything (V2X). A GLOSA system is a
system that operates at road intersections, which by communicating the ITS-Station (ITS-S)
working on the traffic lights and the ITS-S working on board; the vehicle is capable of providing
a recommended speed to the driver, to always find the traffic lights green.
The present project has mainly used for its development the open-source implementation of
the C-ITS stack, Vanetza; the Abstract Syntax Notation One (ASN.1) to C++ compiler, asn1c;
and basic web-oriented technologies to code the system.
The final results that the system has provided are that is capable of operate normally in
barely all sorts of intersections, except those ones with multiple lines and traffic lights signals per
direction. The big flaw of a system of a kind is the actual imprecision of the Global Positioning
System (GPS) system; because its high margin of error makes difficult to ensure which lane is
the vehicle using.
Resum
El present projecte desenvolupa un sistema ”Green Light Optimized Speed Advisory System
(GLOSA)”(Avıs de Velocitat Optima per Semafor Verd), implementant els estandards marcats
per el ”European Telecommunications Standards Institute (ETSI)”(Institut Europeu d’Estandards
de Telecomunicacions) i la ”Society of Automotive Engineers (SAE)”(Societat d’Enginyers d’Au-
tomocio) dins del marc del Cooperative-Intelligent Transport Systems”(Sistemes de Transport
Inteligents Cooperatius) tambe anomenat ”Vehicle-to-Everything (V2X)”(vehicle-cap a-tot). Un
sistema GLOSA es un sistema que opera a les interseccions de carrers, que amb comunicacio en-
tre la ”ITS-Station (ITS-S)”(Estacio-ITS) instal·lada al semafor i la ITS-S instal·lada al vehicle;
aquest ultim es capac de donar una velocitat recomanada al conductor, per sempre trobar-se el
semafor verd.
El present projecte principalment utilitza pel seu desenvolupament la implementacio de codi
lliure de tot el conjunt d’estandards C-ITS, Vanetza; el complinador d’Abstract Syntax Notation
One (ASN.1) (Notacio Sintactica Abstracta 1) a C++; asn1c; i tecnologies basiques orientades
a web per programar el sistema.
Els resultats finals que el sistema ha donat son que es capac d’operar amb tota normalitat en
quasi tots els tipus d’interseccions, amb l’excepcio de les que tenen multiples carrils per direccio
and senyalitzacions del semafor diferents. La gran debilitat del sistema es l’actual imprecisio del
sistema ”Global Positioning System (GPS)”(Sistema de Posicionament Global); perque presenta
uns alts marges d’error que fan difıcil saber per quin carril realment el vehicle circula.
Resumen
El presente proyecto desarrolla un sistema ”Green Light Optimized Speed Advisory System
(GLOSA)”(Aviso de Velocidad Optima para Semaforo Verde), implementando los estandares
marcados por el European Telecommunications Standards Institute (ETSI) (Instituto Europeo
de Estandares de Telecomunicaciones) y la ”Society of Automotive Engineers (SAE)”(Sociedad
de Ingenieros de Automocion) dentro del marco de los Cooperative-Intelligent Transport Systems
(C-ITS)”(Sistemas de Transporte Inteligente Cooperativos) tambien conocidos como ”Vehicle-
to-Everything (V2X)”(Vehiculo-hacia-Todo). Un sistema GLOSA es un sistema que opera en
las inteseciones de calles, y con la comunicacion entre la ”ITS-Station (ITS-S)”(Estacion ITS)
instalada en el semaforo y la ITS-S instalada en el vehıculo, este ultimo es capaz de dar una
elocidad recomendada al conductor, para siempre llegar com el semaforo en verde.
El presente proyecto principalmente utiliza para su desarrollo la implementacion en codigo
libre de todo el conjunto de estandares, Vanetza; el compilador de ”Abstract Syntax Notation
One (ASN.1)”(Notacion Sintactica Abstracta 1) a C++, asn1c; y tecnologıas basicas orientadas
a web para programar el sistema. Los resultados finales que el sistema ha dado son que es
capaz de operar con toda normalidad en cualquier tipo de interseccion, con la excepcion de los
que tienen multiples carriles por direccion y senalizaciones distintas dentro del semaforo. La
gran debilidad del sistema es la actual poca precision del sistema ”Global Positioning System
(GPS)”(Sistema de Posicionamiento Global); porque presenta unos elevados margenes de error.
Acknowledgements
The principal acknowledgements of this project are for its supervisor Jordi Casademont i Serra,
he was the one who proposed it and guided it and always have backed it even when the devia-
tions made it have relevant time plan changes.
This project would not have been possible without the co-financing of ”Secretaria d’Universitats
i Recerca del Departament d’Empresa i Coneixement de la Generalitat de Catalunya” via the
2017 SGR 00376 project.
IV
Revision history and approval record
Revision Date Purpose
0 27/05/2019 Document creation
1 28/05/2019 First Draft introduction
3 01/06/2019 State of the Art Introduction
4 05/06/2019 Project Development
5 06/06/2019 Budget
6 09/06/2019 First Appendix
7 12/06/2019 Revision of Introduction and State of The Art
8 13/06/2019 Revision of Project Development
9 18/06/2019 Results
10 19/06/2019 Second Appendix
11 20/06/2019 Conclusions
12 23/06/2019 Last Changes
25/06/2019 Last Changes
DOCUMENT DISTRIBUTION LIST
Name e-mail
Jordi Marias Parella [email protected]
Jordi Casademont i Serra [email protected]
Written by: Reviewed and approved by:
Date 25/06/2019 Date 25/06/2019
Name Jordi Marias Parella Name Jordi Casademont i Serra
Position Project Author Author Project Supervisor
V
Contents
Abstract I
Acknowledgements IV
Revision history and approval record V
1 Introduction 1
1.1 Statement of Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Requirements and Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Methods and procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Work Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Deviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 State of the art of the technology used or applied in this thesis 5
2.1 Introduction to Cooperative Intelligent Transport Systems (C-ITS) . . . . . . . . 5
2.2 Intelligent Transport Systems Communications (ITSC) . . . . . . . . . . . . . . . 6
2.2.1 Access Layer: ITS G5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Network and Transport Layer: GeoNetworking and BTP . . . . . . . . . 8
2.2.3 Facilities Layer and Application Layer . . . . . . . . . . . . . . . . . . . . 9
2.3 GLOSA under ETSI C-ITS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 Road Lane Topology Service (RLT) . . . . . . . . . . . . . . . . . . . . . 10
2.3.2 Traffic Light Maneuver Service (TLM) . . . . . . . . . . . . . . . . . . . . 13
2.4 Vanetza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.1 Socktap application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Abstract Syntax Notation One (ASN.1) . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.1 Encoding rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.2 asn1c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Project Development 18
3.1 System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1 OS, Dependencies and Libraries . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.2 Applications Developed . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.3 ASN.1 J2735 Module Implementation . . . . . . . . . . . . . . . . . . . . 20
3.1.4 TLM library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
VI
3.2 Development process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.1 Dockerization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5.1 Road Side Unit (RSU) settlement . . . . . . . . . . . . . . . . . . . . . . 24
3.5.2 On Board Unit (OBU) settlement . . . . . . . . . . . . . . . . . . . . . . 25
4 Results 26
4.1 Bidirectional road with one lane for direction . . . . . . . . . . . . . . . . . . . . 26
4.2 Multiple lanes on every direction with different phase per lane . . . . . . . . . . . 27
5 Budget 29
5.1 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3 Personal Salaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4 Total . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6 Conclusions and future development 31
Appendices 35
Appendix 1: TLM Library Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Appendix 2: Testing cases layouts and results . . . . . . . . . . . . . . . . . . . . . . . 40
VII
List of Figures
1.1 Work Breakdown Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Basic structure of the ITS-S architecture[6] . . . . . . . . . . . . . . . . . . . . . 6
2.2 The coexistance of GeoNetworking/BTP and IPv6 TCP/UDP [3] . . . . . . . . . 8
2.3 MAP depiction of an intersection . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 An example of XY offsets describing a rectangular polygon . . . . . . . . . . . . 13
2.5 Example of signaling status over an intersection . . . . . . . . . . . . . . . . . . . 13
2.6 An example of syntax triad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1 Software Prototyping iterative workflow . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 The gauge providing the recommended speed . . . . . . . . . . . . . . . . . . . . 25
4.1 Evolution of the recommended minimum speed on the first case . . . . . . . . . . 26
4.2 Recommended minimum speed during approach to the intersection . . . . . . . . 27
6.1 Lane Handler UML block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2 Map Handler UML block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3 Position Handler UML block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.4 Real Point UML block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.5 SPAT Handler UML block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.6 Speed Calculator UML block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.7 Assembled MAP for the intersection in front of the rectorate . . . . . . . . . . . 40
6.8 NMEA track used for the first case testing . . . . . . . . . . . . . . . . . . . . . . 40
6.9 Assembled MAP for the intersection between Avinguda Diagonal and Gonzalez
Tablas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.10 NMEA track used for the second case testing . . . . . . . . . . . . . . . . . . . . 42
VIII
List of Tables
5.1 Summary of paid documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 Equipment Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3 Summary of Personal Salaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4 Summary of total budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1 First scenario results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.2 Second scenario results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
IX
Chapter 1
Introduction
The idea of applying some automated intelligence to transport systems has been around even
much before the appearance of Information Technologies (IT). During the interwar period, the
authorities of the first large developed cities were starting to sort out how to change the old
nineteenth-century commuting systems to fit in the brand new private vehicle, the motorized
car; massive efforts were made to organize the traffic moving around the busiest avenues. This
lead to the development and deployment of automated traffic lights, which used the primitive
electronics of the late twenties to control the flow between intersections without having to have
a police officer handling manually which cars should go and which ones must stop. Despite
having taken major steps forward on electronics during the second half of the twentieth century,
none of these steps meant any significant improvement on the automated traffic control until the
appearance of widely used IT and with it, the concept of Intelligent Transport Systems (ITS).
The concept of ITS relies on the usage of IT on providing innovative services that rely on the
whole different modes of transport to improve safety and traffic conditions [13]. For example, the
reliance on multiple sensors to detect which street provides a higher traffic flow to an intersection
and adequate the traffic lights phase to give more time to the vehicles that come from the busiest
street.
1.1 Statement of Purpose
On the line of intersection traffic handling, this project aims to take a step forward on the
improvement of traffic lights using ITS services and develop what is called a Traffic Light Ma-
neuver Service (TLM). To be more specific, a Green Light Optimized Speed Advisory System
(GLOSA); which is a system that taking advantage of the capability of both the traffic lights and
the vehicles to send and receive messages through a wireless medium; allow the car to provide a
recommended speed to the driver for always arrive at the signalized intersection with the green
light opened.
Many studies have been carried out proving that a TLM service does not only makes an
urban ride with a private vehicle more comfortable and less stressful; it also means an essential
breakthrough in cutting car emissions by saving a significant percentage of fuel that, without a
system of a kind, is being burnt out [2]. This happens because one of the more energy demanding
1
states of a motorized vehicle is when it starts moving by placing the first gear.
Despite developing a GLOSA system seems as easy as being able to tell any vehicle near an
intersection with a semaphore which phase the lights controller is using, any full working TLM
does not only need to tell the phase; it also has to map the layout and calculate the distance
between the car and the lane approach to the intersection; as the standards issued by the ETSI
and SAE describe.
For that reason, the principal goals of this project are the following ones:
• Think and code a working prototype of a TLM service, which should perform perfectly
fine in the vast majority of probable cases a system of that kind has to be prepared to
deal with.
• Extend the open source “Vanetza” implementation of the ETSI C-ITS protocol stack to
be able to send and receive MAPEM and SPATEM frames.
• Design and implement a simplistic Road Lane Topology Service (RLT), in order to provide
the mapping service that any TLM relies on.
1.2 Requirements and Specifications
Project requirements:
• The project must provide, in the end, an extension of the Vanetza API capable of sending
and receiving SPATEMs and MAPEMs.
• The project must deliver at the end a reasonably simple RLT service implementation
capable of giving an answer to the needs of an implemented TLM service.
• The project must deliver at the end a working prototype of a TLM service that specifically
provides a recommended speed for those vehicles heading to a road intersection with traffic
lights.
• The project must deliver an accessible app with a friendly UI, bootable from a Raspberry
Pi.
The present project only commits to fit the specifications given by the ETSI C-ITS on the
document ETSI TS 103 301 V1.1.1 (2016-11); when defines a TLM service. In a nutshell, those
specifications are that the MAPEM and SPATEM message must follow the structure marked
by the ETSI and SAE standardizations; and must be encoded using the Packet Encoding Rules
(PER).
1.3 Methods and procedures
Although the present project starts from scratch and does not have any previous precedence
within the department on which is developed, must be said that, since the SAE developed the
2
concept of GLOSA and the ETSI also described the service of TLM, a few public institutions;
especially from the US; have tried to deploy such a system effectively and this has been an
enormous help when it comes to ensuring that all the standards that were being programmed
were interpreted the same way those institutions did.
The implementation of the ETSI C-ITS stack is an open source C++ project called Vanetza
currently developed by a research group at the Technische Hochschule Ingolstadt University
and licensed under GNU Lesser General Public License (LGPLv3). Vanetza, in general lines,
implements GeoNetworking and BTP over the network and transport layers and CAM and
DENM over the facilities layer along with security and management layers features. The fact
that Vanetza does not implement any TLM needed message over its facilities layer, makes the
present project the first that extends this open source C++ implementation to be capable of
sending and receiving the messages specified by SAE J2735.
Over the assembling of MAPs, the present project has used an app issued by the US De-
partment of Transportation (USDOT) in 2016. The application allows drawing lane layout of
any road intersection using aerial images to then assemble an already serialized MAP message.
Over the serialization and handling of complex data structures such as SPATs, the project
has relied on the ASN.1 to C++ struct compiler asn1c. Which has compiled the whole SAE
J2735 standard into a fully manageable library, capable of serializing all the C++ structs to
PER serialized objects to later be sent through the Vanetza implementation.
1.4 Work Plan
Despite having to handle a software development project, over which the workflow tends to be
circular and not linear the designed working plan was thought to approach the tasks in an ”as
linear as possible” manner. At the third chapter, the methodology and time handling devel-
opment strategies used are explained more deeply, but it’s important to say that the approach
taken is software prototyping; which straightforwardly, it’s developing a piece of software by
starting from a simple prototype and then adding more sophisticated features on every new
prototype compiled.
The work breakdown structure on figure 1.1 also reveals all the deliverables for accomplish-
ing the project: An SPATEM and MAPEM implementation over Vanetza, a basic Road Lane
Topology Service (RLT) service, an Traffic Light Maneuver Service (TLM) service and a basic
UI.
3
Figure 1.1: Work Breakdown Structure
1.5 Deviations
During the development of the present project, several deviations have been happening due to
external factors or problematics with the technology used. In a nutshell, here are listed all the
important deviations:
• The asn1c open source compiler didn’t have enough compatibilities to compile the SAE
J2735 standard. Which were a serious breakdown at the early stages of this project.
• The Packet Encoding Rules (PER) serialization wasn’t also well implemented (the un-
aligned version) and the emitted SPATEM and MAPEM in the early stages were not
compliant with the standard. Until a correct implementation of those serializations were
found, there was no way to go through.
• The compiler used to test (Ubuntu Docker Container) than the applied with the Raspberry
Pi, and this last one didn’t really compile the iterators of the <algorithms> standard
library.
4
Chapter 2
State of the art of the technology
used or applied in this thesis
2.1 Introduction to Cooperative Intelligent Transport Systems
(C-ITS)
Before starting, it’s imperative to point out the confusion or even misunderstandings that may
arise when reading the naming system to anyone already familiarized with any other Vehicle-
to-Everything (V2X) technology project or document. The fact is that, despite being in such a
globalized world, the technical standardizations promoted between different world political enti-
ties hardly never are homogeneous. And that’s precisely the case. The first institution to openly
talk about ITS were the United States Federal Communications Commission (FCC) when, in
October 1999, allocated 75 MHz of spectrum in the 5.9GHz for this purpose and encouraged
both national and international institutions to start assembling standards for this recently born
concept. This was translated into the IEEE constituting a working group that finally came up
with what was called Wireless Wireless Access in Vehicular Environments (WAVE), nowadays
referring to the IEEE 802.11p standard, and the Society of Automotive Engineers (SAE) pub-
lishing the Dedicated Short-Range Communications (DSRC) standard, which provided a stack
of standardized services and messages aimed to develop what is known of the facilities layer
of this communications standards. After nearly one decade, the European Telecommunications
Standards Institute (ETSI) started the same process by reserving 30 MHz of the 5.9GHz spec-
trum destined for the same purpose and started to assemble working groups that later issued
the papers which standardized the C-ITS [7]. That in essence, is the exact same technology that
the Americans designed first with some added features like the Cooperative Awareness Mes-
sage (CAM) or the Decentralized Environmental Notification Messages (DENM). This struggle
between institutions has translated, somehow, a bit of a mess of names where sometimes the
names of the European standards overlap the names of the American ones, but in some others
overwrites or even redefines them. One example of overlapping would be that the European
standard has no problem in calling the V2X applications in general as the same way the SAE
or WAVE does. But when it comes to other applications, such as a GLOSA, the more recent
5
European standard does not only overwrites its name calling it (TLM), it also kind of redefines
them: A TLM is defined in a broader sense of the concept than a GLOSA.
The legal definition within the European Union (EU) of ITS is that ”Intelligent Transport
Systems (ITS) are advanced applications which without embodying intelligence as such aim to
provide innovative services relating to different modes of transport and traffic management and
enable various users to be better informed and make safer, more coordinated and ‘smarter’ use
of transport networks” [1]. Which in a straightforward manner would be equal to say that ITS
is the appliance of IT to enhance or provide utilities for transport systems. On top of that, the
Cooperative Intelligent Transport Systems (C-ITS) are those ITS on which the vehicle takes
an active part of the system, whether by communicating from Vehicle-to-Everything (V2X),
vehicle-to-infrastructure (V2I) or even vehicle-to-pedestrian (V2P), along with some more types
of communications [7]. And that’s the reason why C-ITS provide a white canvas to develop any
kind of interaction between all the entities involved in a transport system that could improve the
overall performance. The present project develops a C-ITS because, despite the communications
are unidirectional under a GLOSA system, all the entities involved have to cooperate actively
to make it work.
2.2 Intelligent Transport Systems Communications (ITSC)
The ETSI provides a basic global working framework for the communications that regard to
ITS. On the logic of this framework, any entity involved in the ITSC is an ITS-Station (ITS-S),
without any regard on if the entity is a Road Side Unit (RSU) or an On Board Unit (OBU) [6].
Moreover, any ITS-S must implement the ITSC following a new communications model(called
ITS-S architecture) which is inspired by the well-known OSI architecture and simplifies and
adapts this famous model to serve the communication demands of any ITS safely and within a
changing, non-stable environment.
Figure 2.1: Basic structure of the ITS-S architecture[6]
6
If the basic structure of the ITS-S architecture is compared with the OSI model there can be
seen that the Access Layer regards to the two OSI’s Physical and Access layers, the Network &
Transport Layer regard to the two OSI’s Network and Transport Layers and the Facilities and
Applications Layers combined would be the three OSI’s Session, Presentation and Application
Layers. This structure enables to adapt any programmed facilities & application layer utilities
to work without having to take into account which physical medium is being used or which
network protocol is running at the lower layers. As a parenthesis, it’s important to design any
communications system in an OSI model like architecture because there are always different
possible standards for any layer, and, if any standard gets deprecated using this structure all
the pieces of software programmed above doesn’t necessarily get outdated. One perfect example
is the own C-ITS technology where at the time this document it’s been written there has been
a contest between which access layer medium is better: the WLAN-based that relies on the ITS
G5 over which there can be implemented IEEE 802.11p or LTE-V2X or the cellular-based now
called C-V2X standard which relies on cellular communications.
Considering that any ITS related technology is still on a really early phase, this project
bases its application on the standards that the ETSI have specified. Not only because these
standards are far more accessible than any other one, but also because at 2017 the European
Automobile Manufacturers Association made a commitment to start deploying vehicles with
V2X technologies related to the European standards on late 2019.
2.2.1 Access Layer: ITS G5
The ITS-G5 [5], nowadays associated with IEEE 802.11p, in the EU, and Wireless Access in
Vehicular Environments (WAVE), in the US, is a standard that regulates the short-range com-
munications over the 5GHz spectrum range. The available protocol that those standards rec-
ommend at the moment this project is being written is the IEEE 802.11p. The 802.11p is an
amendment to the widely-known IEEE 802.11 standard; which is a stack of LAN protocols, both
on the physical layer where standardizes any other general short-range wireless communication
that popularly is known as Wi-Fi. And, on the access layer, uses the Media Access Control
(MAC) protocol of the OSI architecture. 802.11p adds improvements to the original protocol to
work specifically in transport environments such as an urban street or even a fast-speed highway.
The main physical technical differentiation between this standard and others of the same family
is that works on the 5.9 GHz band and typically uses channels of 10MHz of bandwidth. On the
access side, the IEEE 802.11p dispenses the concept of Basic Service Set (BSS) considering that
the communication link between the roadside infrastructure and the vehicle might just only be
possible for a short time interval. In practice, this means that in some cases the communications
use a wildcard BSSID, which means that the stations send and receive as soon as one station is
at the same range as another.
The present project does not implement anything on the physical/access level; which means
that the GLOSA system will also work on conventional ethernet. But it has to be acknowledged
that, at the moment this document is being written, when the ETSI refers to C-ITS services use
to imply that the physical layer is the ETSI ITS-G5 (IEEE 802.11p) despite a few companies
7
are starting to push hard to replace the 802.11p with the LTE-V2X over the G5 range.
2.2.2 Network and Transport Layer: GeoNetworking and BTP
The networking and transportation layer is, probably the most interesting and challenging part
of the whole available ITS protocol stacks. The fact of having to design a networking system
capable of routing data among a fast-changing network topology to bring in a robust end-to-end
connection, obligate the proposed standards to be really flexible, versatile and tenacious.
The first approach when designing the network and transport layer, proposed by the IEEE
for the WAVE protocol stack, was just to use the same widely-known protocols that internet
uses nowadays: Implement IPv6 over the network layer and TCP/UDP over the transportation
layer. Thanks to the 6th version of the IP protocol any issue regarding the addressing problem
would be resolved and the ITS-S would be capable to communicate between themselves barely
doing the same(obviously the standard applies a few changes to provide safe and more flexible
connections) that is done on domestic WLANs.
The second approach, where the ETSI and the IEEE proposed different protocols, is to design
a whole new networking protocol, which has to cover all the issues that such a medium requires;
e.g. having a volatile and dynamic environment. The ETSI proposal is called GeoNetworking on
the network layer and Basic Transport Protocol (BTP) over the transport layer; while the IEEE
and SAE have a proposal for both layers called Wave Short Message Protocol (WSMP) [11].
The present project relies on the European solution for the network and transport layer. For
the record, it has to be said that at the moment this project is being developed both proposals
coexist and there is still no clear winner. Despite GeoNetworking seems to solve pretty well all
the challenges it has to face, the working groups of both proposals are struggling to impose their
standard on a worldwide level. This probably will mean that the first V2X vehicles will have
compatibilities with both standards.
Figure 2.2: The coexistance of GeoNetworking/BTP and IPv6 TCP/UDP [3]
Most of the physical prototypes of ITS-S already implement WSMP and GeoNetworking
with BTP.
8
GeoNetworking Working Principles
GeoNetworking is an extensive standard and its really difficult to summarize its working princi-
ples in a few lines. But, in general lines, GeoNetworking uses an address format that combines
the ITS-S type (pedestrian, motorist, special vehicle...), the ITS-S country and the link layer
address. On top of that, the protocol is really flexible and relies on multiple headers, that,
depending on the needs get extended and reveal one information or another. Here a basic
explanation of all the different GeoNetworking headers:
• Basic Header
The Basic Header includes the ”Lifetime” field which is the maximum time that a packet
can be alive, and the ”Remaining Hop Limit” which limits the hops that a packet can
make.
• Common Header
The common header is more extense and includes the length of the payload, the flag that
tells if the ITS-S is mobile or not along with additional fields describing GeoNetworking
parameters.
• Extended Header
Depending on the type of packet that will be sent this header will carry one type of
information or another. Generally in this header is revealed a position vector along with
an extensive set of possible data types.
Those headers are combined depending on the type of message that is sent. The present project
doesn’t make any change on this layer.
Basic Transport Protocol (BTP)
As it’s explained above, the BTP pretends to be the most simplistic possible transport protocol,
which implies that has huge similarities with UDP. In a few words, there could be two types
of BTP packets: the BTP-A and the BTP-B. The BTP-A simply provides the destination port
and the source port, while the BTP-B only provides the destination port with information about
itself; making clear that the BTP-B is designed for broadcast communications.
2.2.3 Facilities Layer and Application Layer
The facilities layer is the layer on which the present project develops the GLOSA System.
Although this layer is the one that, by far, has more standards to regulate the way almost
any possible service must be implemented, is the one whose standards have been standardized
barely equally for the whole world [8]. On this layer, there can be found the so-known CAM and
DENM [4] which were proposed under the European Standardization and at the same time there
can be found all the Dedicated Short-Range Communications (DSRC) Message Set Dictionary
standardized by SAE and also approved by the European institutions calling them ”Extended
Messages” with the added ITS-PDU-Header [12]. Since the application layer is the one on which
9
all the developers run their programs, there isn’t any relevant standardization. This layer when
working with the ”facilities services” is clearly influenced by the capabilities of the layer below
[9].
2.3 GLOSA under ETSI C-ITS
The Green Light Optimized Speed Advisory System (GLOSA) are those ITS on which the ITS-
S on board is synchronized with an ITS-S on traffic lights in order to provide a recommended
speed to the driver of the vehicle for always arriving at the signalized intersection with the green
light on the semaphore. The point of a GLOSA system is that improves the comfortability
when driving through urban areas and, more importantly, in most cases means reducing the
consumption of fuel significantly and with it a great breakdown on the CO2 emissions. There
can be found in that line a few papers proving that GLOSA systems might lower the CO2
emissions over urban intersections up to 11,5% in most cases [2].
GLOSA systems were first designed by the SAE at the DSRC standard. On which is required
that any GLOSA system need first a way to map the intersection topology, and then a way to
tell and upgrade the traffic light signalling phase to the vehicle. Once the vehicle receives all
that information must be capable of computing ITS position on the map layout, and calculate
the distance, timing and recommended speed to approach the intersection without having to
stop the vehicle completely. To accomplish the two needs that a GLOSA system requires SAE
issued the J2735 standard which characterized on the facilities layer the Map Message (MAP)
and the Signal Phase And Timing Message (SPAT). Where, as the name says, the first ones
are designed to provide the layout of any type of geographic road information, and the other
ones are thought to provide the status and timing of one or more signalized intersections. A
chandelier after, the ETSI issued the TS 103 301 standard on which facility layer protocols
and requirements are specified by depicting many possible services. Over them, there must be
acknowledged the Road Lane Topology Service (RLT) and the Traffic Light Maneuver Service
(TLM).
2.3.1 Road Lane Topology Service (RLT)
As the ETSI TS 103 301 standard specifies “The RLT service is one instantiation of the in-
frastructure services to manage the generation, transmission and reception of a digital topo-
logical map, which defines the topology of an infrastructure area” [10]. Which for the present
project means that the function of an RLT service is to provide the topology layout of the in-
tersection area. The RLT service marks as its indispensable tool the so-called Map Extended
Message(MAPEM) which is the same MAP message described by SAE J2735 with an extra
European standardized header known as ITS-PDU-header. The service instantiation is depicted
by the ETSI as the continuous transmission for the infinity of the MAPEM that describes the
topology of a certain area by ITS-S on the roadside(otherwise called RSU). The assembling pro-
cess of the map stored in a MAPEM should be done manually because the road layout doesn’t
change dynamically, which means that the is enough with having a stable version of the map
10
stored within the RSU that is continuously broadcasted through a MAPEM.
Map Extended Message (MAPEM)
As explained above, the Map Extended Message (MAPEM) is the core asset on which the RLT
service relies to work. Despite, at the present project, this message will only be used to describe
intersection geographies, as a data element, MapData is meant to also be able to depict road
segment descriptions, high-speed curve outlines (for curve safety services) and segments of a
roadway (also for safety services). The whole MAPEM structure is quite complex, and for this
reason, this document only talks about its general structure and the main working principles on
which this message relies.
Firstly, the only difference between a MAPEM described by ETSI and the MAP described
by SAE is that the first one includes an extra header. That, as it’s said in the previous section, is
called ITS-PDU-Header; and only specifies the “protocol version”, the type of extended message;
whether there is a SPATEM, MAPEM or any other; and adds an identification for the ITS-S;
which adds an extra field to avoid possible confusion in highly dense transport systems. Below
this header, the Map Data have exactly the same structure than the SAE specification. In fact,
the ETSI description of a MAPEM appends the SAE description of a MAP.
In general lines, inside a J2735 MapData there can be found infrastructure layout describing
objects as long as infrastructure parameter describing objects. The structures that the present
work uses to implement the GLOSA system are reported in the following sections.
Transport Infrastructure Description Principles
Both the “RoadSegment” and the “IntersectionGeometry” data elements rely on the same ap-
proach when it comes to describing the transport infrastructure items: the roadway lanes. The
data element named “GenericLane” is the core object for depicting any roadway layout. In
general terms, any ”RoadSegment” or ”IntersectionGeometry” describe the road lanes of their
topology by carrying a set of ”GenericLanes” as an abstract concept that can also describe
objects other than motorized vehicle lanes. Each lane carries an Identifier, specifies its direc-
tion using ”approaches” (another type of identifiers that allow any GenericLane to specify on
which points you can enter the lane, and if this approach is inbound or outbound), its attributes
(meaning the direction,ingress to the intersection or egress to the intersection; the type, if it’s
motorized vehicle lane, a pedestrian lane, or a cycling lane among much others), its allowed
maneuvers (if a U-turn is allowed, a lane change is allowed or even if the lane is on a no stopping
zone) and obviously with which lanes connect once entering the intersection. Over Figure 2.3
can bee seen an example of a topological drawing of an intersection among an aerial picture.
Every line in this picture is a lane; with the orange and blue lanes being motorized vehicle lanes
and the yellow lanes being pedestrian lanes. Each lane is drawn with the union of a set of points
and has to come with an approach(red rectangles) that specify the ingress or egress point of the
lane. On the lane points can be observed with a number which is the identification of the lane.
The ID number is really important because have to be coordinated with other types of messages
11
Figure 2.3: MAP depiction of an intersection
that reveal information over the states of the intersection. E.g. The SPATEM references to the
different lane IDs to reveal the signalling phase of its connections. And finally, the blue arrows
mean on which lanes the lane 1 connects; and with it the manoeuvres. In that case, can turn
right and continue straight forward.
Geometrical Description of any Map
The geometrical description of any Map starts by taking a reference point, which is described
with the GPS coordinates latitude, longitude and altitude. The reference point must be, by
convention, at the centre of the layout. Later, the lanes are described geometrically by the
union of a set of points (called offsets) that describe their position giving an offset in reference
from the last described point, starting by the Anchor point which on real points is the reference
point described by GPS coordinates.
Figure 2.4 shows a perfect example of how the points must be computed to describe a
rectangular polygon. The reason why this system is used; is to avoid having to deal with great
numbers that could increase the message payload.
The other way available to draw geometric objects within the MAP message is to compute
them in offset with another object. An example would what is called a ”ComputedLane” which
is a lane that defines its position in reference to another lane. Over the Figure 2.3 the lane 2
defines its position in reference to lane 1. Using this method multiple lane road is more easy to
define and, at the same time, huge amounts of bytes are earned increasing the efficiency of the
message.
12
Figure 2.4: An example of XY offsets describing a rectangular polygon
2.3.2 Traffic Light Maneuver Service (TLM)
The ETSI defines the TLM service as an instantiation of the infrastructure services to manage the
generation, transmission and reception of SPATEM messages[10]. Which, in more general words,
means that a TLM service is anyone that puts into practice what a SPATEM is designed for:
the signalling of phase states and any kind of information regarding any traffic light controller.
For example, showing the current phase state, the residual time until lights change or even the
allowed manoeuvres at any present moment. As is explained before at this same document a
SPATEM is virtually the same as a SPAT which allows us to do the same analogy saying that,
despite having a broader definition, a TLM service is virtually the same than a GLOSA system.
The difficulties that present the development of a TLM service is that have the dependency
Figure 2.5: Example of signaling status over an intersection
13
towards an RLT service. And, on top of that, the SPATEMs emitted are not static like MAPEMs;
they have to adapt to the current traffic light state; and have to be pretty accurate when showing
timings and likelihood ratios; because huge troubled could be caused if any SPATEM is not
correctly aligned with the running traffic light controller. This means that any implementation
of a TLM service means the capability to synchronize a service with a real traffic light controller,
to then assemble a MAPEM message from scratch and emit it.
Signal Phase And Timing Extended Message (SPATEM)
Similarly to the MAPEM case, SPATEM is the core asset that allows the TLM service to
convey the current status of one or more signalized intersections. And also, similarly to the
MAPEM, the only difference between a SPATEM described by ETSI and a SPAT described
by SAE is that the first one includes an extra header, called ITS-PDU-Header. On the other
hand, fortunately, a SPATEM, is not as complex as a MAPEM but, instead, always need to go
associated with one of it, and only by himself lacks meaning. In general lines, a SPATEM carries
a list ”IntersectionState”, a data object described by SAE, that is linked through an identifier
to an intersection previously described by a MAPEM and depicts the current and further states
of the identified intersection. First and foremost, the ”IntersectionState” describes what kind
of traffic controller is configured for that specific intersection(works on fixed time operation,
a traffic dependent operation, a standby operation(when the amber is partially flashing)...).
Secondly, it has a list identifying the enabled lanes, which are the lanes whose mobility is not
”revoked” by the current status of the traffic light controller. And finally, stores a list of another
data element object called ”MovementState” which relates to the MAPEM revealed topology
using an identifier called ”SignalGroupID” that the ”Connections” of the ”ConnectingLanes”
also bring with them; and explains the timing and recommended speeds for all the vehicles that
has to adequate their behaviour to the signaling of the specific traffic light controller.
2.4 Vanetza
Vanetza is an open-source C++ implementation of the ETSI C-ITS protocol stack. In other
words, generally speaking, this means that comprises the network and transport layer(implementing
the GeoNetworking protocol and the Basic Transport Protocol (BTP), with an added feature
that implements the security and a top of this also brings the support for Cooperative Awareness
Message (CAM) and Decentralized Environmental Notification Messages (DENM) messages.
Vanetza can be launched over any hardware capable of compiling it and with network interfaces
among which receive or send any message.
2.4.1 Socktap application
Vanetza brings with itself a set of example applications; that implement the basic functionalities
related to CAM. Those apps serve as the perfect blueprint of how any C++ program should use
Vanetza as a library to implement over the application layer, applications meant to be run over
an ETSI C-ITS.
14
2.5 Abstract Syntax Notation One (ASN.1)
The Abstract Syntax Notation One (ASN.1) is a data type declaration notation, specifically
designed to allow communications between heterogeneous counterparts. By heterogeneous is
meant computing systems with different hardware or even different software, e. g. different
programming languages or different Operating System (OS). The need of developing such a
notation appeared at the early eighties, a decade before Tim Berners-Lee proposed the so-known
Hypertext Transfer Protocol (HTTP), when international scientific computer research groups
started to design universal communications protocols that had to work between completely
different systems, e.g. the FTP protocol was issued at the mid eighties to allow file sharing
between two different computers. At that time, even nowadays, there were structural divergences
between different computers. One classic example is the endianness, the order of packing bytes
when stored in memory, which some architectures are big-endian, the most significant bytes
comes first, and some other are little-endian which means the most significant byte goes last.
These divergences that can be found on any possible level, e.g. the hardware architecture level,
Figure 2.6: An example of syntax triad
the OS level even the programming language level. Needed to be overthrown by designing a
high-level notation that later allowed the implementation of a specific data type to the different
heterogeneous machines.
2.5.1 Encoding rules
The ASN.1 does not only come with a way to describe data elements; it also comes with a
few ways to serialize them in order to be able to transfer them. Barely all of the following
serialization standards are not originally from the 1984’s ASN.1, they have been a posterior
amendment:
15
• Basic Encoding Rules (BER)
The encoding format of BER specifies a self-describing and self-delimiting format for encod-
ing ASN.1 data strictures. This type of encoding is commonly called Type-Length-Value
(TLV); because comes first with a type identifier octet followed by a length octet and
finally ends with the value itself.
• Distinguished Encoding Rules (DER)
DER is a restricted variant of BER. To say it scientifically DER encodings are a subset of
all possible BER encodings. One example of the different restrictions it has, among others,
is that in BER any bit of a byte can represent a boolean while in DER this is entirely
restricted.
• Canonical Encoding Rules (CER)
CER is another variant of BER, or in other words, is another subset of BER encodings.
In general terms, BER gives a set of options on how data values may be encoded, but on
the other side, CER like DER restricts those options to one.
• Packet Encoding Rules (PER)
PER is the encoding required by the SAE and the ETSI to encode the basic facilities layer
messages (CAM, DENM, MAPEM, SPATEM). The reason why they decided to use this
encoding rules is that is the most efficient of them all. PER try to waste as fewer bits
as possible by only telling the length of a value when it’s strictly necessary, and in most
cases also doesn’t waste bits telling the value type taking into account that the reciever
must also know the structure of the data element it’s receiving. Like BER it has subsets of
encodings: Unaligned Packet Encoding Rules (UPER), Canonical Packet Encoding Rules
(CPER) or even Canonical Unaligned Packet Encoding Rules (CUPER)
• XML Encoding Rules (XER)
The XER encodes the data into the popular format Extensible Markup Language (XML).
This format is really recent(the first 1.0 version was issued at 2008, after a long time
working over previous versions and despite Hypertext Markup Language (HTML) were
using the concept of markup language barely twenty years before) and it’s really easy
to understand and to handle, because it was designed to be both human and machine-
readable. In general terms, everything described in an XML file relates to a tag, used
to describe barely everything. The main problem with this encoding is that is highly
inefficient.
• JSON Encoding Rules (JER)
The most recent encoding rules, and when this document is being written the most popular,
are the JavaScript Object Notation (JSON) encoding rules. In some sense, both XML and
JSON share the same principles: Both are easy to understand and to handle, and both are
designed thinking in being human and machine readable. A JSON file describes it’s data
the same way Python and JavaScript would describe a list or a dictionary. Both XML and
16
JSON are being standardized in a time were wasting bytes is not a problem and both are
really inefficient.
2.5.2 asn1c
As said in the previous sections, the point of ASN.1 is that describes data elements in a higher
level than a programming language. Which means that compilers which implement the data
structures on a target programming language exists. And, at the present project to program the
SAE J2735 facilities messages, data elements and data types dictionaries we’ve used an open
source C compiler and library that allows translating the ASN.1 files to C structs that are easily
manageable.
asn1c does not only provide the ”compiler” capability but also provide a library with
BER/PER/XER serializers and deserializers; which means that once you’ve the ASN.1 data
structure you’ll not have to worry about the encoding and decoding process.
17
Chapter 3
Project Development
During the early days of this project, the main issue to determine its viability was to decide which
was the right framework used to structure, plan and control the process of developing this IT
system. After considering a few approaches, and considering that this is an unipersonal project;
which means that any matter regarding how a team should be constituted is unimportant, the
software prototyping methodology was considered the right one.
Figure 3.1: Software Prototyping iterative workflow
As shown in Figure 3.1, the development of the present project has consisted into quickly
developing prototypes with a few simplistic extra features; and, with each iteration, the code
becomes close to the project’s final goal requirements. The fact that this is an end year project
means that the maintenance stage will not be carried out, but that does not mean that if the
present project was executed on an industrial environment wouldn’t be done.
The present chapter, explains all the stages of the development process without taking into
account the ”Initial Investigation” stage, because all the matters regarding to this part are
explained at the ”State of the Art” chapter, and the ”Requirements and Definition” stage cause
it’s already explained at the ”Introduction” chapter.
18
3.1 System Design
Once the specifications and requirements are fine, and the initial research has shown a clear
path; the next step is to start the designing stage. On that stage, the most crucial decision that
has to be taken when developing a piece of software is which designing pattern will be used. On
that matter, there is never a clear answer and, in reality, any pattern well applied will actually
work. The fact here, is to choose the pattern that better fits to the development methodology
and the development time plan. For the present project, the main pattern applied is the so-
called ”chain-of-responsibly”, which is a design that consists of creating preprocessing objects
that handle command objects. In a more simplistic statement, consists of creating handlers that
simplify the main structure of the program. For that reason, all the complexity of the code is
passed to the handler libraries, generating a cleaner code and easily debuggable.
3.1.1 OS, Dependencies and Libraries
On the other side, over the designing stage, it’s important to know which compatibilities the code
will have in order to pick the right programming languages, development OS, dependencies and
libraries. Despite C++ has become, the universal low-level language, and it could be accurate
to say that any current OS used nowadays has a compiler capable of dealing with that language.
The preferred OS for the development and implementation of the GLOSA system is Linux.
Although the principal reason is that is freeware, there are other critical reasons to pick this
OS, for example, that all the libraries and dependencies listed below are easy to find for that
specific system.
The present project relies on vanetza as its main library and background project which means
that any decision on that matter must adapt with what Vanetza brings with itself. Vanetza is
programmed in C++ and relies on the following tools and libraries:
• C++11 Compatible compiler
In order to run the code on specific hardware, first, it has to be compiled to the ”machine
language” for that specific hardware. In that line, Vanetza uses utilities only available over
the 11th or superior version of C++. For that reason, Vanetza will only be compatible
with any piece of Software capable of compiling the version of C++.
• CMake 3.1 or higher
CMake is a utility design to ”pre-compile” any project considering the parameters that
any given OS brings with itself. Vanetza uses CMake to get pre-compiled and adapted to
a given software to then using the ”make” compile the project into a launchable program.
• Boost 1.58 or higher
Boost is one of the widest, free and well-documented libraries available in C++. It does
not only implement by himself utilities to handle more efficiently any piece of data it
also implements utilities over the runtime, the socket connections and the parallelized
programming.
19
• GeographicLib 1.37
Geographiclib is used by Vanetza to deal with the GPS data that is given to it.
• Crypto++ 5.6.1
Vanetza uses the utilities of that library to implement the security layer of the ETSI C-ITS
protocol stack. The development of a TLM service does not have big issues when it comes
to security so probable this library will not be used.
3.1.2 Applications Developed
As widely explained at the ”State of the art” Chapter, the entities involved in a GLOSA sys-
tem are, on the infrastructure side, the RSU who emits MAPEMs revealing the intersection
topology and SPATEMs which reveal the present and future states of the traffic light controller.
This needed cooperation to make possible such a system means that to implement its different
applications corresponding to the different roles have to be programmed. At the early days of
this project the approach taken to design this basic structural issues was to develop an ”RSU
application” and an ”OBU application” trying to imitate the classical approach of developing
a client application and a server daemon. Finally, after multiple tests, was decided to split the
RSU into the ”RLT application” and the finally called ”SPAT application” on which the first
is the MAPEM emitter and the second is the SPATEM assembler and emitter. The principal
reason to split up the ”Road Side” part of the system was that both programs end up being
simpler and easier to handle. And, on the other hand, is that MAPEMs are not only used in
TLMs, the RLT service is also used by another amount of possible services. Which means that,
by developing the two separately, there was being developed a RLT and an TLM.
3.1.3 ASN.1 J2735 Module Implementation
The most critical feature to implement before starting to code the applications which shape a
GLOSA system is to code over the Vanetza implementation of C-ITS the capability of handling
with MAPEMs and SPATEMs at the facilities layer of the protocol stack. The standardizations
of these two types of messages were issued by a compound of extense standards written in ASN.1.
The complexity of those standardizations made nearly impossible to implement by hand all the
data structures and serializations demanded to emit and receive any MAPEM or SPATEM. For
this reason, the ASN.1 to C++ asn1c compiler was used despite this open-source compiler lacked
compatibilities with some practices used by SAE J2735 standardization (The standardization of
SPAT and MAP); which meant that extra measures needed to be taken.
The problem asn1c had with the SAE J2735 was that this document describes an extra
variable for nearly every data element and message type that is ”empty” in a sense that does
not really have a type or a specific name.
The first approach taken to solve this problem was to eliminate this variable form every
data element or message which contains it. the results of this approach were fine until the PER
serialization was tried and the message failed to pass the test against the USDOT utility that
allows checking if a MAP is serialized according to the standard.
20
After a few research, the right approach was taken and it was by mixing a couple of third
party pending pull requests over the open source project which, in some sort of unprofessional
way implemented the compiler compatibility with this type.
Once the structs and serializers were resolved, other issues arose when trying to integrate
this new code within the vanetza code structure.
3.1.4 TLM library
The main application structure and implementation was taken from the blueprints given by the
vanetza developers by the example ”Socktap-application”. For that reason, the difficulties of the
present project were the adaptation of the Vanetza code to be able to emit and receive SPATEMs
and MAPEMs. This lead to the improvement and usage of the asn1c library to implement this
new standard, whose development process is explained above and the creation of a library that
had to make more easier to handle with complicated structs and serializations given by the
compiler. This variable is the regional variable and is designed because the document that the
SAE issued has international aspirations and pretend the peculiarities that every world region
might standardize would be placed within the scope of this variable.
MAP Handler
The MAP Handler class is designed to easily manipulate all the data that regards to any received
MAPEM and is at the interest of the functionality of a GLOSA system. It initializes a lane
handler for every lane it contains. Combining these two handlers the complete layout is computed
and can be depicted.
Lane Handler
The Lane Handler class is designed to easily manipulate the data that a lane brings with itself.
The main functionality of that class is that regardless of the type of lane (Computed or not) when
the constructor receives the GenericLane object, automatically computes all their real points
and stores them in a list. It also makes easier to obtain important information like checking if
the lane is for vehicles or the lane direction. The reason why these types of handlers are needed
is that the data structures treat with a lot of pointers and complex structures.
Real Point
The Real Point class is not a handler, it responds the need to create an object to store the points
of the bidimensional cartesian layout computed from a MAP. As said on the ”state of the art”
chapter, the points revealed by a message have the previous point as it’s offset. In that line,
when a new MAP is received the application computes the ”real points” considering the offset
the center of the Cartesian map (0,0). And, doing it that way it’s easier to compute lengths or
any other feature over them.
21
Position Handler
The position Handler is the class that implements all the RLT service at the client side. From
one perspective collects all the new positions that are given to it and using a Map Handler
computes on which lane of the layout the vehicle is running; with all of that means, computes
the direction and the path length to the centre of the intersection. All this information later is
used by the Speed Calculator to with simple maths calculate the recommended speed.
SPAT Handler
The SPAT handler, unlike the other handlers, is not that oriented on the client side of the system
is rather oriented on the Road Side of the application. The SPAT handler is capable to create
a SPAT from scratch depending on the variables you give to it.
This handler, when first instantiated, receives a MAP the so-called ”greentime” which is the
time that one ”SignalGroup” is at the state of ”protected movement allowed” and the so called
”yellowtime” which is the time the traffic light controller is at the orange state.
Speed Calculator
The Speed Calculator class it would be certain to say that is really the class that ultimately
implements the functionalities of a GLOSA system. From knowing the distance left to the
intersection (going through the lane), the traffic light controller signal phase and the speed limit
allowed computes the recommended speed that later will be shown to the driver.
3.2 Development process
The development process of the present project, as said before, was carried out with the soft-
ware prototyping methodology. For that reason, in every work package, a few prototypes were
implemented before coming up with the final version of the software. The second work package
implements the MAPEM and SPATEM compatibility with Vanetza. And, as explained above,
the first prototype of that implementation disregarded the so-called ”regional” variable, the
second prototype disregarded a viable PER compatibility and it wasn’t until the third imple-
mentation that the deliverable was considered to work fine. The third work package implements
the so-called Road Lane Topology Service (RLT) service. For this specific service, a static MAP
was crafted at the US Department of Transportation (USDOT) utility and then imported to the
application to be sent with the headers of a MAPEM. In this methodology, the first prototype
of the RLT only imported and printed by the screen in XML format the MAP. The second pro-
totype added the MAPEM headers and the emitting process. And finally the last version was a
MAPEM receiver with a position point computer that ensured that this message was well-sent,
and the topology received was according to the one demanded. The fourth work package, at the
real-time, was split in two, the development of the SPAT emitting app. Which took advantege
of the blueprint of the RLT application and the only implementation that had to be done was
the SPAT assembler(SPAT handler at the TLM library). And the ”Client application” which
22
also used the already programmed MAPEM receiver to also append the SPATEM receiver to
later program the ”Speed Calculator” which is in essence what a GLOSA system does. The fifth
work package, which regards to the UI was quickly developed thanks to the usage of HTML
CSS combined with Javascript. It’s important to notice, that communicates with the back-end
of the application using a JSON file.
3.3 Testing
Despite normally being ignored by open source or young developers like the student writing
this document, in software testing is almost as important as developing. The present project
implemented a rudimentary testing system which consisted in creating a ghost application that
instanced object by object and called every member function printing by screen the returned
value to asses if the member function was working as expected or not.
3.3.1 Dockerization
Despite the present GLOSA system is thought to be launched over Raspberry Pi,a small comput-
ing machine that runs on ARM architecture and Linux OS. The low speed and performance of
a Raspberry made necessary to look for alternative ways to compile the project much faster and
with a similar environment. Docker is a recently popularized virtualization utility that allows
creating containers, small virtual machines, with only the needed libraries and dependencies to
run a specific piece of software.In that line two container images were created: A Vanetza com-
piler container, designed to compile vanetza, and a vanetza container designed to run vanetza.
Any container image is described in a file called Docker file; on which in essence there are all
the instructions to install all the needed dependencies to run a specific piece of software.
FROM ubuntu : 1 8 . 0 4
RUN apt update && \apt i n s t a l l −y python3−pip python3−dev && \cd / usr / l o c a l / bin && \ln −s / usr / bin /python3 python && \pip3 i n s t a l l −−upgrade pip && \apt i n s t a l l g++ \l i b c r y p t o++−dev \l i bgeog raph i c−dev \l i bboo s t−date−time−dev \l i bboo s t−program−opt ions−dev \l i bboo s t−s e r i a l i z a t i o n −dev \l i bboo s t−system−dev \g i t −y \l i bgps−dev \gpsd−c l i e n t s \
23
python−gps −y \cmake \g i t
#ENTRYPOINT [”/ bin /bash ” ]
All the basic testing processes, all those that didn’t need to entities to get done, were made
using this Docker Container.
3.4 Hardware
The main hardware used in this project is the tiny, cheap, low consumption computer called
Raspberry Pi. Despite the main reason why this tiny computer is used it would be the
price(around 36 e) it also makes sense to consider as the perfect size to be carried out (It’s
size is smaller than a credit card) and it has enough capacity to support all the needed periph-
erals: GPS antenna, tiny screen, external LAN interface... On the OS level, uses the Raspbian
OS which is some kind of a mixture between Ubuntu and Debian adapted to the Raspberry
processor architecture ARM. This OS goes perfectly fine because has already compiled versions
of the dependencies and libraries on which Vanetza relies the most, and also C++ programs
can be compiled with the GCC compiler and will work perfectly fine. The problem comes when
is realized that the raspberry pi network interfaces have no compatibility whatsoever with the
ITS G5 standardization. But it also has to be acknowledged that there is no ITS G5 network
interface on the market for the great public. For that reason on the access layer will be used a
normal 5GHz 802.11ac network in ad hoc mode.
3.5 Usage
As explained before, any GLOSA system relies upon, at least, two entities cooperating. For
that reason, this section explains how to set up separately the OBU and RSU. It’s important
to point out that this section considers that the applications have been already compiled. To
compile those packages for a Linux system should be as easy as installing all the dependencies
and libraries required for vanetza (The Dockerfile shown above presents them) and then running
the following commands on a build folder within the main vanetza folder will do the case:
$cmake −D BUILD SOCKTAP=ON . .
$make
The compiled binaries will be inside the bin folder then.
3.5.1 Road Side Unit (RSU) settlement
The two services running at the RSU are the RLT which collects a static, previously designed,
MAP and broadcasts it periodically. And the called ”spat-application” which creates a SPATEM
with a fixed signal phase depending on the map number of signal phases. Before running the
24
services it’s important to point out that on a deployment stage those two services should be run
as a daemon. And also important that at the same folder where the binaries are there should
be a map.uper file containing the bits of a pre-assembled MAP.Said that with two terminals on
the RSU:
$ . / socktap−r l t −−gpsd−host l o c a l h o s t − i <ne twork in t e r f a c e>
On the second terminal the same:
$ . / socktap−spat −−gpsd−host l o c a l h o s t − i <ne twork in t e r f a c e>
If the RSU has a GPS antenna plugged the services will run fine. If not there must be launched
a gpsfake instance with a National Marine Electronics Association (NMEA) file showing the
position of the RSU.
3.5.2 On Board Unit (OBU) settlement
For the present case, is considered that the OBU is running on any popular Linux distro and has
a modern browser equipped. The OBU is simpler to set up but also needs a couple of daemon
services. The first is the application binary itself. Before launching the application binary, the
UI folder at the root of the Vanetza project must be copied to the same directory. Because
there, is from where the UI will be launched.
$ . / socktap−c l i e n t −−gpsd−host l o c a l h o s t − i <ne twork in t e r f a c e>
And then with another terminal and within the recently pasted ui folder:
$python3 −m http . s e r v e r 8050
The port is arbitrary. Now with launching a browser and connecting to the direction http://localhost:8050/
the following gauge providing the recommended speed will appear.
Figure 3.2: The gauge providing the recommended speed
25
Chapter 4
Results
The results of the present project correspond to the performance of the GLOSA implementation.
Multiple tests have been taken to ensure a minimum level of quality and viability. This chapter
presents two of those multiple tests that represent the good performance of the system and, at
the same time, the big flaws.
4.1 Bidirectional road with one lane for direction
The most iconic case for an intersection is when 4 streets with one lane for every direction
meet at one signalized intersection. In that test the GLOSA system has been tested over the
intersection in front of the UPC rectorate. All the complementary information of every test can
be found at the appendix (The intersection layout, the GPS registered track and the table with
all the information taken. Before analyzing the results obtained on the first case; it was to be
Figure 4.1: Evolution of the recommended minimum speed on the first case
26
acknowledged that those results are a sample of 24 (24 seconds) on which the phase of the traffic
lights is red and the time to await for the next ”green” is 28 seconds at the beginning and 4
seconds at the end. The first thing that can be seen from the Figure 4.1 is that the results are
the expected. The average speed is above the Recommended Maximum Speed which means that
the vehicle will arrive before the phase change and will have to stop. On the other side, this
graph comes with peaks of speed due to the GPS imperfections that place the vehicle further
from where it really is.
4.2 Multiple lanes on every direction with different phase per
lane
If the first testing case was, somehow, the best possible scenario. At this second stage, there has
been designed to be the one of the worst of them all. The layout for this test scenario is where the
Avinguda Diagonal and the Gonzalez Tablas meet. The depiction of the assembled map can be
foud at the second appendix along with the real recoded track and the results table. To describe
the scenario, the testing vehicle is going along Diagonal to leave Barcelona and is running on
the 4 lane roadside direction on which the first lane is to turn right to the Gonzalez Tablas and
the second one is to continue straight. This scenario is challenging because the testing vehicle
is running on the second lane with the intention to leave Barcelona; but is running next to the
first lane that is meant to turn right. The fact that both lanes regard to different traffic light
signalizations and that are going at the same direction (the main factor that the implemented
GLOSA system uses to correct the GPS margin of error makes the nightmare case on which the
system might probably give wrong recommended speeds. During all the test the traffic lights
Figure 4.2: Recommended minimum speed during approach to the intersection
phase for the second lane is at green with the exception of the last 4 seconds that turns red.
The problem with this test is the fallback that can be seen on the 22nd second on Figure 4.2.
27
Despite during barely all the test the GLOSA system works fairly well (because the error margin
of the GPS turns to the third line and not the first); at the end appears the wrong error and
the system believes that the vehicle is on the first lane; telling the driver to fully stop because
at that moment is in front of the intersection and the phase for that lane is zero,
In short terms, the results of this project are that all the requirements and specifications have
been accomplished with an incredibly good accuracy. The main flaws of this GLOSA system
are not its fault, and in a dismissed prototype the approach of statistically compute which is the
current line were tried with worse results than the final version. The problem of deciding which
is the right lane considering the past positions adds a delay that might be pretty misleading for
any driver.
28
Chapter 5
Budget
Despite this project is based on software; to implement and run the full end-to-end project,
some specific pieces of hardware are required which means that are taken into account at the
present chapter. At the software level, all the dependencies, libraries and compilers that this
project has relied on were open-source; in other ways, freeware. Which means they didn’t cost
a thing.
5.1 Standards
At the ”Initial investigation” a couple of standardization paid documents issued by SAE where
bought. Those documents once bought can be used without any restriction and if they are not
upload to the general internet public can be share between members of the same organization.
Document Price
SAE J2735 (DSRC) Message Set Dictionary 73e
SAE J2735 (DSRC) Message Set Dictionary ASN File 100e
TOTAL 173e
Table 5.1: Summary of paid documents
5.2 Equipment
The present project did not only required the basic expected hardware for a software; it also
requires a couple of ”as cheap as” possible linux running computers(to make the function of
ITS-S, one to be the On Board Unit (OBU) and the other the Road Side Unit (RSU)), and a
GPS pheripheral capable of providing the real time position of the computer that accomplish the
function of an OBU. On the other side, for all the programming stuff a laptop with virtualization
capabilities(for running docker) does the job.
29
Equipment Commercial Price Quantity Subtotal
Raspberry Pi 3 Model B+ 36.40e 2 72.80e
Raspberry Pi Charger 6.99e 2 13.98e
Micro SD (16GB) 9.99e 2 19.98e
External GPS Antenna 19.99e 1 16.99e
Medium-range Laptop 700.00e 1 700.00e
TOTAL 823.75e
Table 5.2: Equipment Summary
5.3 Personal Salaries
The present project counts on two main workers to be carried out. The student is listed as a
Junior engineer paid 20.00 efor hour working a total of 504 hours. The student total hours
counts from considering the 18 ECTS on which the bachelor’s end year project stands for, and
for each ECTS a total of 28 hours. The project Manager & Supervisor is actually the present
project supervisor and his hours are computed by counting a total dedication of 2 hours per
week (20 weeks) plus 10 hours of assessment. The taxes are considered at the 18%.
Workers Salary/Hours Total Hours Cost Cost with taxes
Junior Engineer 20.00 e/hour 504 hours 10080.00 e 11894.40 e
Project Manager & Supervisor 35.00 e/hour 50 hours 1750.00 e 2065.00 e
TOTAL 13959.40 e
Table 5.3: Summary of Personal Salaries
5.4 Total
Concept Cost
Knowledge 173.00 e
Equipment 823.75 e
Personal 13959.40 e
TOTAL 14956.15 e
Table 5.4: Summary of total budget
30
Chapter 6
Conclusions and future development
Conclusions overall present project development The principal conclusions of the present project
are that an implementation of a Green Light Optimized Speed Advisory System (GLOSA)
system, compliant with all the standards issued by the ETSI and SAE, is perfectly viable using
open-source code with a relatively cheap hardware. On the other hand, as it can be seen with
the results, the big flaws that this service presents are related to the high margin of error that
the current affordable GPS antennas provide. Making harder to effectively calculate the right
lane on which the vehicle or pederestian regard and the direction any car takes. Along with,
depending on the place, high latency.
Another important conclusion is that the GLOSA system needs, somehow, a redefinition.
The system presented at this project gives, if the value is not above the speed limit, the maximum
recommended speed when the traffic lights are red, meaning that if the driver surpass that speed
will arrive at the intersection with the red light shining; and when the controller is green, gives
the minimum recommended speed, by understanding that speed as if is not surpassed the vehicle
will arrive late at the intersection finding the red light shinning. Possibly further versions or
redefinitions of a GLOSA system will provide speed boundaries instead of a fixed recommended
speed.
The present project sets a precedent and a base implementation of the SAE J2735 standard
that will be useful to anyone willing to go further developing not just a RLT and a TLM but also
all the systems are services which makes use of this message set dictionary. Another precedent
that sets its a core implementation of an RLT service. And by that a handler capable of, by
receiving a MAP, fully understand the layout it brings with itself and the position on that map
where the OBU rely.
Along with the precedents, this own project could be improved not only by applying the
redefinition explained before, but also by developing an algorithm capable of overcoming the
GPS flaws.
On the C-ITS side, despite the concept is already 20 years old; all the proposals or imple-
mentations of such a technology, specially C-ITS, are on its early stages. The fact that the
automobile industry is one of the largest in the world; and that automobiles use to last for a
long time; makes any relevant change or even a small step forward go really slow. If to this
background is added the problematic of multiple standards and technologies competing for the
31
hegemony of a still non-commercial technology; this might mean that the next decade there will
be multicompatibility between those standards and this will bring with itself huge struggles and
technical challenges.
32
Bibliography
[1] Directive 2010/40/eu of the european parliament and of the council of 7 july 2010 on the
framework for the deployment of intelligent transport systems in the field of road transport
and for interfaces with other modes of transport, Official Journal of the European Union,
(2010-07-7), pp. 1–3.
[2] D. Eckhoff, B. Halmos, and R. German, Potentials and limitations of green light
optimal speed advisory systems, IEEE Vehicular Networking Conference, (2013).
[3] ETSI EN 302 636-3 V1.2.1; Intelligent Transport Systems (ITS); Vehicular Communica-
tions; GeoNetworking; Part 3: Network Architecture , standard, European Telecommuni-
cations Standards Institute, Sophia Antipolis, FR, 2014.
[4] ETSI EN 302 637-2 V1.3.2; Intelligent Transport Systems (ITS); Vehicular Communi-
cations; Basic Set of Applications; Part 2: Specification of Cooperative Awareness Basic
Service, standard, European Telecommunications Standards Institute, Sophia Antipolis,
FR, 2014.
[5] ETSI EN 302 663 V1.2.1; Intelligent Transport Systems (ITS); Access layer specification for
Intelligent Transport Systems operating in the 5 GHz frequency band, standard, European
Telecommunications Standards Institute, Sophia Antipolis, FR, May 2013.
[6] ETSI EN 302 665 V1.1.1; Intelligent Transport Systems (ITS); Communications Architec-
ture, standard, European Telecommunications Standards Institute, Sophia Antipolis, FR,
May 2010.
[7] ETSI TR 101 607 V1.1.1; Intelligent Transport Systems (ITS); Cooperative ITS (C-ITS);
Release 1, standard, European Telecommunications Standards Institute, Sophia Antipolis,
FR, May 2013.
[8] ETSI TR 102 638 V1.1.1; Intelligent Transport Systems (ITS); Vehicular Communications;
Basic Set of Applications; Definitions, standard, European Telecommunications Standards
Institute, Sophia Antipolis, FR, 2009.
[9] ETSI TS 102 894-1 V1.1.1; Intelligent Transport Systems (ITS); Users and applications
requirements; Part 1: Facility layer structure, functional requirements and specifications ,
standard, European Telecommunications Standards Institute, Sophia Antipolis, FR, 2013.
33
[10] ETSI TS 103 301 V1.1.1; Intelligent Transport Systems (ITS); Vehicular Communications;
Basic Set of Applications; Facilities layer protocols and communication requirements for in-
frastructure services, standard, European Telecommunications Standards Institute, Sophia
Antipolis, FR, 2016.
[11] IEEE 1609.3 - IEEE Standard for Wireless Access in Vehicular Environments (WAVE) –
Networking Services, standard, Institute of Electrical and Electronics Engineers, New York,
US, 2016.
[12] ISO/TS 19091:2017; Intelligent transport systems – Cooperative ITS – Using V2I and I2V
communications for applications related to signalized intersections, standard, International
Organization for Standardization, Geneva, CH, 2016.
[13] K. S. Pradip and K. J. Amit, Intelligent Transport Systems, PHI learning, Patparganj,
Delhi, 1 ed., 2018.
34
Appendices
Appendix 1: TLM Library Tables
This appendix lists, describe and depicts all the libraries programmed for the TLM library. In
a general way, it could be said that this appendix represents the code documentation of the
present project. The present appendix only documents the critical functions of each class in
order to give anyone that might continue this project a clear sneak peak of how the library
works.
Lane Handler
Figure 6.1: Lane Handler UML block
The main remarks considering the Lane Handler class are the following ones:
35
• lane handler(GenericLane t & genericLane)
The constructor needs a ”Generic Lane” to handle. Once this class is constructed, if the
given lane is not computed, computes the ”real points” of the lane and stores them. This
way internally depicts a bidimensional plane whose points in reference from the central
point.
• compute points(std::list<lane handler>& lanes)
If the lane is computed, the present function computes all its points by looking the reference
lane, (This function can only be used on computed lanes)
• get real points()
This function is a simple getter, but the reason why is being commented is because returns
the real points of the lane so, is returning the lane layout.
Map Handler
Figure 6.2: Map Handler UML block
The most important functions regarding to the MAP handler class are the following ones:
• map handler(MapData t & map)
The MAP Handler constructor initializes a Lane Handler list with all the lanes given by
the passed MAP.
• std::list<lane handler> get lane list()
The list with all the Lane Handlers that regard to an specific MAP can be obtained using
that function.
• void print map points()
36
This function only works for debugging purpose. Prints the points that regard to an
specific MAP. This is really useful if a map has to be seen on screen.
• long get lane signalGroup(long laneID)
Returns the SignalGroup on which regard an specific lane identified by the ”LaneID”.
Position Handler
Figure 6.3: Position Handler UML block
The Position Handler class altogether with the Speed Calculator class is the main pillar on
which the RLT service on the client side works. There are those relevant functions among others:
• position handler(map handler& mapHandler)
The constructor stores the MAP handler that contains the MAP over which the position
will be given,
• set new position(long lat, long lon)
Everytime there is a new position available is given to this class using this function.
Projects this GPS coordinates over the 2D map and stores this new position into the
trace.
• long get path length()
Returns the distance left to arrive to the intersection. This function is called by the Speed
Calculator to calculate recommended speeds.
Real Point
The Real Point class is some sort of data element that stores a couple of longs. The functions
are simple getters and setters.
37
Figure 6.4: Real Point UML block
SPAT Handler
Figure 6.5: SPAT Handler UML block
The SPAT Handler is the class that builds SPAT data elements to then assemble SPATEMs.
It has a lot of member variables because an SPAT is a complex structure and it requires of a lot
of pointers and initialized objects to be handled easily:
• spat handler(MapData t &map, long greentime, long yellowtime)
The constructor only needs the MAP over which the SPAT handler will create SPATs
and the time the traffic controller will be ”green” and ”orange” (the red is computed
automatically). Once this function is called the Handler simulates internally a traffic light
38
controller and give the phase states of that one.
• refresh spat()
Before getting the ”handled” SPAT it has to be refreshed. By calling this function, the
handler rebuilds the SPAT to send the correct ”on time” traffic controller phase.
• SPAT t get spat()
Getter of the built SPAT.
Speed Calculator
Figure 6.6: Speed Calculator UML block
The Speed Calculator class calculates the recommended speeds(the final purpose of a GLOSA
system) just by collecting all the needed information using setters. And then give back the
answers using getters. In some way, works pretty similar to the SPAT Handler way. It has some
internal functions for code simplification. The rellevant functions are the following ones:
• speed calculator()
All the needed information to calculate the recommended speed is volatile and has to be
given every time; for that reason the constructor doesn’t need anything.
• refresh speed()
Everytime this function is called, the recommended speed is caluclated using the current
settled parameters. If the parameters hasn’t been updated will use the old ones.
• double get recommended speed()
Getter of the current recommended speed.
39
Appendix 2: Testing cases layouts and results
Bidirectional road with one lane for direction
Figure 6.7: Assembled MAP for the intersection in front of the rectorate
Figure 6.8: NMEA track used for the first case testing
40
Time
(seconds)
Distance
(meters)
Recommended Maximum Speed
(Km/h)
Time to green
(Seconds)
1 323.65 30 28
2 321.93 31 27
3 309.36 30 26
4 278.66 28 25
5 273.06 29 24
6 251.38 27 23
7 226.86 26 22
8 227.63 27 21
9 194.00 24 20
10 188.71 24 19
11 200.97 27 18
12 141.58 20 17
13 135.11 20 16
14 139.72 22 15
15 99.17 16 14
16 98.69 18 13
17 107.02 21 12
18 58.82 12 11
19 49.48 11 10
20 28.94 7 9
21 26.53 7 8
22 12.79 3 7
23 6.65 2 6
24 9.48 3 5
Table 6.1: First scenario results
Multiple lanes on every direction with different phase per lane
41
Figure 6.9: Assembled MAP for the intersection between Avinguda Diagonal and Gonzalez
Tablas
Figure 6.10: NMEA track used for the second case testing
42
Time
(seconds)
Distance
(meters)
Recommended
Minimum
Speed
(Km/h)
Time to Red
(Seconds)
Current
Lane
1 207.44 23 24 2
2 200.19 24 23 2
3 191.52 23 22 2
4 186.46 24 21 2
5 178.28 24 20 2
6 179.74 25 19 2
7 158.87 23 18 2
8 153.69 24 17 4
9 149.39 24 16 4
10 136.34 26 15 4
11 140.12 25 14 4
12 120.79 26 13 4
13 112.16 28 12 4
14 94.16 25 11 3
15 90.11 27 10 3
16 93.79 31 9 3
17 99.82 37 8 3
18 64.63 27 7 3
19 59.59 29 6 3
20 64.17 38 5 2
21 36.82 27 4 2
22 28.79 28 3 2
23 34.64 2 2 2
24 41.54 3 1 1
25 2.93 0 0 4
26 3.48 2 -1 2
27 11.27 11 -2 1
28 18.1 11 -3 1
29 4.72 0 -4 2
Table 6.2: Second scenario results
43
Acronyms
ARM Advanced RISC Machine. 23, 24
ASN.1 Abstract Syntax Notation One. I, VI, 3, 15, 17, 20
BER Basic Encoding Rules. 16, 17
BSS Basic Service Set. 7
BSSID Basic Service Set Identifier. 7
BTP Basic Transport Protocol. VI, VIII, 8, 9, 14
C-ITS Cooperative Intelligent Transport Systems. I, VI, 2, 3, 5–7, 10, 14, 20, 31
C-V2X Cellular-V2X. 7
CAM Cooperative Awareness Message. 3, 5, 9, 14, 16
CER Canonical Encoding Rules. 16
CPER Canonical Packet Encoding Rules. 16
CSS Cascading Style Sheets. 23
CUPER Canonical Unaligned Packet Encoding Rules. 16
DENM Decentralized Environmental Notification Messages. 3, 5, 9, 14, 16
DER Distinguished Encoding Rules. 16
DSRC Dedicated Short-Range Communications. 5, 9, 10
ECTS European Credit Transfer and Accumulation System. 30
ETSI European Telecommunications Standards Institute. I, VI, 2, 3, 5–8, 10, 13, 14, 16, 20,
31
EU European Union. 6, 7
FCC United States Federal Communications Commission. 5
44
GLOSA Green Light Optimized Speed Advisory System. I, VI, 1–3, 5–7, 9, 10, 13, 19–24,
26–28, 31, 39
GPS Global Positioning System. I, 20, 25–29, 31, 37
HTML Hypertext Markup Language. 16, 23
HTTP Hypertext Transfer Protocol. 15
IEEE Institute of Electrical and Electronics Engineers. 5, 7, 8
IT Information Technologies. 1, 6, 18
ITS Intelligent Transport Systems. VI, 1, 5–10, 24
ITS-S ITS-Station. I, VIII, 6–10, 29
ITSC Intelligent Transport Systems Communications. VI, 6
JER JSON Encoding Rules. 16
JSON JavaScript Object Notation. 16, 17, 23
LAN Local Area Network. 7, 24
LGPLv3 GNU Lesser General Public License. 3
LTE Long Term Evolution. 7, 8
MAC Media Access Control. 7
MAP Map Message. VIII, 3, 10, 12, 20–22, 24, 25, 31, 36–38, 40, 42
MAPEM Map Extended Message. 2–4, 11, 14, 16, 20–23
NMEA National Marine Electronics Association. VIII, 25, 40, 42
OBU On Board Unit. VII, 6, 20, 24, 25, 29, 31
OS Operating System. VI, 15, 19, 23, 24
OSI Open Systems Interconnection model. 6, 7
PER Packet Encoding Rules. 2–4, 16, 17, 20, 22
RLT Road Lane Topology Service. VI, 2, 3, 10, 14, 20, 22, 24, 31, 37
RSU Road Side Unit. VII, 6, 20, 24, 25, 29
SAE Society of Automotive Engineers. I, 2–5, 8–10, 14, 16, 17, 20, 21, 29, 31
45
SPAT Signal Phase And Timing Message. VIII, 3, 10, 13, 14, 20, 22, 38, 39
SPATEM Signal Phase And Timing Extended Message. 2–4, 12–14, 16, 20–24, 38
TLM Traffic Light Maneuver Service. VI, VII, 1–3, 6, 10, 13, 14, 20–22, 31, 35
TLV Type-Length-Value. 16
UI User Interface. 2, 23, 25
UML Unified Modeling Language. VIII, 35–39
UPC Universitat Politecnica de Catalunya. 26
UPER Unaligned Packet Encoding Rules. 16
US United States. 3, 7
USDOT US Department of Transportation. 3, 20, 22
V2I vehicle-to-infrastructure. 6
V2P vehicle-to-pedestrian. 6
V2X Vehicle-to-Everything. I, 5–8
WAVE Wireless Access in Vehicular Environments. 5, 7, 8
Wi-Fi Wireless Fidelity. 7
WLAN Wireless Local Area Network. 7, 8
WSMP Wave Short Message Protocol. 8
XER XML Encoding Rules. 16, 17
XML Extensible Markup Language. 16, 22
46