Agnostic Middleware for VANETs: Speciﬁcation, Implementation and

Testing

abio Gonc¸alves, Bruno Ribeiro, Oscar Gama, Maria Jo

ao Nicolau, Bruno Dias, Ant

onio Costa,

Alexandre Santos and Joaquim Macedo

Centre Algoritmi, Univ. Minho, Portugal

Keywords:

VANETs, Middleware, Agnosticism, Protocol, API.

Abstract:

Vehicular Ad hoc Networks (VANETs) are the basic support for Intelligent Transportation Systems (ITS),

providing a framework for its multiple entities to communicate. The communications and services provided to

the road entities are generally implemented by means of an On-Board Unit (OBU) and Road Side Unit (RSU),

sharing a rather similar hardware and software architectures. These devices need to support multiple com-

munications types and provide access to the needed vehicle data to the applications. Most of the existing

solutions demand that the application developers have development control and knowledge about the OBU

internals. Thus, most applications are developed by OBU makers and implemented directly on it. However,

solutions based on middleware agnosticism separate the OBU internals and software development, facilitating

the application development by software makers or researchers. This paper proposes an Application Program-

ming Interface (API) and protocol that can easily be used to access the vehicle internals and services through

an agnostic architecture without any knowledge on how they are implemented.

1 INTRODUCTION

Intelligent Transportation Systems (ITS) is a set of

applications and services that aim to facilitate trans-

portation and make roads safer. It allows avoiding

road obstacles and trafﬁc redirection.

Vehicular Ad hoc Networks (VANETs) are the un-

derlying communication network that enables the sev-

eral ITS nodes to communicate. The nodes can be di-

vided into infrastructural and road entities. The ﬁrst

are usually entities with no movement located in the

infrastructure, and the latter the road vehicles. De-

pending on their physical location, the device that

enables vehicular communication to implement the

multiple services has different characteristics and des-

ignations; if it is located in the infrastructure Road

Side Unit (RSU), if on the road vehicles On-Board

Unit (OBU).

In the traditional approach, and following the ex-

isting architectures (ETSI ITS-G5, Communications

Access for Land Mobile (CALM), etc.), each man-

ufacturer develops its own applications and deploys

them directly in the OBU, transforming them into

a black box with a set of services and applications.

Thus, making it impossible for the development of

third-party applications and complicating the interop-

erability with OBUs from other manufacturers.

Authors in Dias et al. and Sousa et al. (Dias

et al., 2018; Sousa et al., 2017) propose a new ap-

proach on communications architectures for ITS by

adapting existing communications models deﬁned, by

the most important standardization institutions, into

a more speciﬁc and modular architecture. It models

the OBU like a black box where all the lower-level

services are implemented. These services share the

same interface technologies and implemented func-

tionalities, covering the same functionalities as re-

ferred by European Telecommunications Standards

Institute (ETSI) ITS. Its main goal is to make it easily

adopted by the manufacturers and research develop-

ment and integration of independent application-level

software.

This agnostic architecture provides a separation

between the OBU internals and high-level applica-

tion development through the ITS-Local Communi-

cation Interface (ITS-LCI) (Dias et al., 2018; Sousa

et al., 2017) to interact using standard communica-

tion protocols and access technologies implemented

on the three service modules: Communication Ser-

vices Module, Information Services Module, Func-

tion Services Module.

The ITS-LCI should use a large bandwidth, low-

Gonçalves, F., Ribeiro, B., Gama, O., Nicolau, M., Dias, B., Costa, A., Santos, A. and Macedo, J.

Agnostic Middleware for VANETs: Speciﬁcation, Implementation and Testing.

DOI: 10.5220/0011315100003286

In Proceedings of the 19th International Conference on Wireless Networks and Mobile Systems (WINSYS 2022), pages 84-92

ISBN: 978-989-758-592-0; ISSN: 2184-948X

cost medium wired technology like Gigabit Ethernet,

support a network stack like User Datagram Proto-

col (UDP) over Internet Protocol (IP), and an applica-

tion management protocol like Simple Network Man-

agement Protocol (SNMP) (Harrington et al., 2002).

This work presents a well-deﬁned protocol and

Application Programming Interface (API) for ac-

cess to the OBU’s lower layer services through the

ITS-LCI. Thus, allowing easy development of third-

party applications without the specialized knowledge

of the OBU’s internals. The proposed protocol uses

UDP and is encoded using the standard widely known

Abstract Syntax Notation One (ASN.1) format, facili-

tating an easy and quick development and deployment

in any system.

The remainder of the paper is organized as fol-

lows. Section 2 discusses the related work, presenting

other middleware architectures in the literature. Then,

in Section 3, the agnostic architecture that serves as

the basis for the development of this work is de-

scribed. Section 4 presents the API designed to access

the OBU internals through the agnostic architecture.

Section 5 evaluates the designed protocol, and, ﬁnally,

the conclusions are presented in Section 6.

2 RELATED WORK

VANETs are complex and heterogeneous networks,

and in the future, vehicles may use multiple types of

wireless communications. Thus, the implementation

of applications and technologies should be indepen-

dent of the underlying medium access communication

framework. Additionally, the same concept should be

applied to the transport and network level. This can be

achieved by applying a concept known as an agnostic

middleware communication layer. It can provide in-

dependent information management for multiple data

sources, allowing the communication over heteroge-

neous interfaces to be transparently supported over

different stacks.

CALM is a communication architecture deﬁned

by the ISO Technical Committee 205 - Working

Group 16 (TC204 WG16). It is designed to allow in-

teroperability between Cooperative Intelligent Trans-

portation Systems (C-ITS) stations, and it abstracts

applications and services from the underlying com-

munication layers (Willke et al., 2009). The CALM

architecture deﬁnes a set of standard speciﬁcations

(Dias et al., 2018; Sousa et al., 2017), including ITS

Station Management, Communications Security, Fa-

cilities, Station Networking, Transport layer proto-

cols, Communication Interfaces and Services, Inter-

facing Technologies and ITS Station, and Distributed

Implementations ITS Stations, Interfacing ITS Sta-

tion to existing communication networks. . However,

it does not present detailed solutions for simultane-

ous usage of the different Vehicle to Anything (V2X)

communication technologies by multiple applications

in the same ITS station.

ETSI ITS-G5 is deﬁned by the standard ISO

21217:2014 (WG16, 2014), which describes the ITS

station reference architecture. It consists of six parts:

Applications, Management, Facilities, Networking

and Transport, Access and Security. However, the

standard does not specify whether a particular ele-

ment should be implemented. It depends on the spe-

ciﬁc communication requirements. The most relevant

middleware support solution for application agnosti-

cism architecture on CALM was introduced by the

facilities layer (Some more recent alternatives were

proposed (Nour et al., 2011) (Costa, 2013) (Silva

et al., 2013) (Jawhar et al., 2013), but they can be

seen as forms of instantiation of the generic ETSI pro-

posal). However, the implementation of such middle-

ware might be very complex, needing knowledge of

many details of the lower layers. Thus, causing soft-

ware makers to lose their ability to choose the devel-

opment paradigm for their applications.

3 AGNOSTIC ARCHITECTURE

The Agnostic and Modular Architecture for the De-

velopment or Cooperative ITS Applications is an ar-

chitecture adapted from the modern ETSI and ISO

to be deployed on ITS and overcome the current ar-

chitecture standards shortcomings. Its goal is to en-

able middleware agnosticism, facilitating the devel-

opment of cooperative ITS applications and services

that use different communication technologies and

network/transport stacks to use the communication

medium transparently. It separates the OBU inter-

nals and the application development, enabling an

easier integration of applications developed by third

parties. Furthermore, the separation between user ap-

plications and OBU internals more easily fulﬁlls the

strict safety and security requirements of the automo-

tive industry’s strongly regulated manufacturing and

deployment processes.

The agnostic ITS architecture supports all types

of vehicular applications using any programming

paradigm and taking full potential of a multi-medium

access capable OBU.

For this approach, the OBU should provide a

group of services, implementing all common fea-

tures needed for access to the vehicle’s internal data

sources, V2X communications, and lower-level auto-

Agnostic Middleware for VANETs: Speciﬁcation, Implementation and Testing

motive functions. The interface to these services is

identiﬁed as ITS-LCI. It should be available through

technologies that are widely used and easily sup-

ported by all automotive manufacturers. Software ap-

plications implemented in the ITS station outside the

OBU would use the technologies deﬁned for this in-

terface for access to the OBU internals.

As shown in (Dias et al., 2018; Sousa et al., 2017),

the OBU implements three modules, Communica-

tion Services Module, Information Services Module,

and Function Services Module, that are accessible

through the ITS-LCI.

Communication Services Module - Must permit

sharing of all the available OBU’s medium access

technologies, implement adequate multi-homing al-

gorithms, vertical hand-off, and related functions for

medium-access addressing, monitoring parameteriza-

tion, and security. Also, when available, implement

antenna conﬁguration as no direct access to commu-

nication functions is possible from external services.

This module requires a bidirectional adaptation

to allow forwarding Protocol Data Units (PDUs) ar-

riving in the communication block/channels through

the ITS-LCI to the adequate application stack at the

network level, depending on their type, while imple-

menting efﬁcient scheduling strategies.

Information Services Module - Must permit ac-

cess and manipulation of data generated by all sen-

sors, actuators, and other devices indirectly or di-

rectly connected to the OBU at rates and precision ad-

equate for the proper use of applications, some in al-

most real-time. Additionally, parameters such as sam-

pling rate and security access should be conﬁgurable,

preferably through conﬁguration functions, but direct

manipulation, as long as adequate security mecha-

nisms are supported.

Function Services Module - Must permit access

to lower-level functions. These are atomic opera-

tional procedures implemented by the manufacturers

due to security, safety, performance, and liability is-

sues. These procedures can then be used to implement

all types of external applications with a higher-level

functionality.

4 AGNOSTIC MIDDLEWARE API

The ITS-LCI represents a standard bidirectional com-

munication technology that all parties need to imple-

ment to be able to use the functions provided by the

three previously mentioned services.

This section describes the protocol and API de-

veloped to allow any third-party application to easily

access the OBU internals without any knowledge of

how they are implemented.

The architecture (Figure 1) assumes two entities:

the communication server (to be deployed as the OBU

board) and the client application (to be deployed as a

host system on the same local area network).

Each application can implement its own network

protocol, independently of the communication inter-

face. The developed API provides a standard way to

access the services previously described.

Communications between applications and the

OBU are made over the widely known UDP, a very

simple and light internet protocol. It has no hand-

shake or conﬁrmations, but the communications be-

tween all the parties happen inside the vehicle, in

close proximity, and over a high bandwidth physical

technology. Thus, the probability of errors or packet

loss is low. This protocol beneﬁts, however, from its

low overhead.

The OBU can be accessed in two different ports,

depending on the operation type, as shown in Figure

1. In port 9011 is implemented a data exchange ser-

vice to be used by the client application. The sent

or received data is either typed (Context Awareness

Message (CAM), Decentralized Environmental No-

tiﬁcation Message (DENM), Basic Safety Message

(BSM), Wave Service Advertisement (WSA), etc.) or

opaque.

Conﬁguration of the server is attained by setting

conﬁguration communication parameters through

primitives addressed to the conﬁguration server UDP

port 9012. This port can also be used to check the

server conﬁguration.

The port marked as XXXX and YYYY are ran-

domly attributed when opening the socket. The

XXXX port is used by the client application to receive

the response requests. The YYYY port is merely in-

dicative. It is a result of opening a socket for the client

application on the C PORT.

The API’s implementation uses different UDP

ports for the different operations, thus, isolating the

different operations and simplifying the API’s imple-

mentation.

The C PORT is used by the client application. It

is deﬁned by the application at the moment of cre-

ation. It allows a device to have multiple applications

running and using the OBU’s services.

In the proposed protocol, the OBU is a com-

munication server that implements a data exchange

communication service to be used by any client ap-

WINSYS 2022 - 19th International Conference on Wireless Networks and Mobile Systems

Figure 1: ITS-LCI communication architecture.

plication. The services are asynchronous and non-

conﬁrmed over UDP.

4.1 Message Format

This section presents the different types of messages

supported by the current protocol version, their pay-

loads, and functionalities. Table 1 presents the multi-

ple conﬁguration parameters that can be altered in the

OBU. It shows the identiﬁcation code to be used, the

value type, and the parameter’s name and description.

These can be used in the set request, status request,

and notiﬁcation request messages.

Table 2 shows the multiple error codes deﬁned and

their description. These errors are only used by re-

sponse request and notiﬁcation request messages.

The message format to be used for the communi-

cation between applications and the OBU is as follow:

• [Version] [Message ID] [Payload]

The ﬁeld Version is an Integer that indicates the

current version of the protocol 0x01 is the ﬁrst ver-

sion. Message ID represents the message identiﬁer,

which is a 32-bit random value that univocally identi-

ﬁes a particular request primitive through a reasonable

time period. The last ﬁeld, Payload, is the payload of

the message. One of the 6 different payloads is per-

mitted:

• send request: Used for requesting the server to

send the included data using the IEEE 802.11p

protocol; the request should be sent to the data

communication server UDP port; the server shall

respond with a response request to the origin IPv4

+ UDP port of the client application. This payload

type also has a Data ﬁeld.

– [Data]: Data can be untyped (Opaque) or one

of the following types: CAM, DENM, BSM,

WSA. When this ﬁeld includes a typed data, it

does not refer to an exact syntax of the message

PDU of that standard; instead, it only speci-

ﬁes data values that can be obtained from one

or more original standard message PDUs. It

should contain at least one byte of data and not

more than 1024.

• receive request: This primitive is for requesting

the client application to receive the included data;

the request should be sent to the pre-deﬁned client

application UDP port; the client application shall

not respond to this primitive. This payload type

also has a Data ﬁeld.

– [Data] Same as the one for send request.

• set request: Primitive for requesting a conﬁgura-

tion operation in the communication server; the

request should be sent to the conﬁguration server

UDP port; the server shall respond with a re-

sponse request to the origin IPv4 + UDP port of

the client application. Note: when making a pure

abstract message speciﬁcation, each tuple can be

replaced by an abstract parameter ﬁeld combin-

ing identiﬁcation and value. This payload also in-

cludes a list of parameters to be conﬁgured. The

list format is [Parameter ID][Parameter Value].

– [Parameter ID]: please refer to Table 1; please

note that some conﬁguration parameters are de-

pendent on other higher-level parameters; for

example, the values used for 802.11p channel

numbers are dependent on the 802.11p regula-

tion domain; also there would be one 802.11p

channel number to be conﬁgured for each avail-

able medium antenna/port.: please refer to Ta-

Agnostic Middleware for VANETs: Speciﬁcation, Implementation and Testing

ble 1; please note that some conﬁguration pa-

rameters are dependent on other higher-level

parameters; for example, the values used for

802.11p channel numbers are dependent on the

802.11p regulation domain; also there would be

one 802.11p channel number to be conﬁgured

for each available medium antenna/port.

– [Parameter Value]: the size and meaning of

the parameters depend on their ID; when the

parameter ID refers to a parameter type that

can have a variable size, the value encodings

should include information about the parame-

ter size and, optionally, other relevant encod-

ing/decoding information.

• status request: Primitive for requesting informa-

tion about the communication server’s conﬁgura-

tion parameters; the request should be sent to the

conﬁguration server UDP port; the server shall re-

spond with a response request to the origin IPv4

+ UDP port of the client application. This payload

also includes a list with the IDs of the parameters

to be consulted.

– [Parameter ID]: please refer to Table 1; when

there is the possibility of having multiple pa-

rameters with the same ID (like, for exam-

ple, all parameters related to each medium an-

tenna/port), the associated notiﬁcation request

should only include the values of the param-

eters related to the set value of the respective

higher-level parameter.

• notiﬁcation request: Primitive for requesting the

client application to receive the included notiﬁca-

tion information; this information is directly re-

lated to previous send, set or status requests issued

by the client application and that can be identiﬁed

by the Message ID; when the Message ID refers to

a previous send request, than it permits the com-

munication server to inform the client application

of the success or failure of the data send operation

(is this case, the Error Value indicates the code

of the results of the operation); when the Mes-

sage ID refers to a previous set request, than it

permits the communication server to inform the

client application of the success or failure of the

attempted conﬁguration operation (is this case,

the Error Value indicates the code of the results of

the operation and the included list of parameters

indicate the values after the attempted conﬁgura-

tion operation); when the Message ID refers to a

previous status request, than it permits the com-

munication server to inform the client application

of the success or failure of the attempted operation

(is this case, the Error value indicates the code

of the results of the operation and the included

list of parameters values indicate the current sta-

tus of the conﬁguration parameters); the request

should be sent to the pre-deﬁned client applica-

tion UDP port; the client application shall not re-

spond to this primitive. Note: when making a pure

abstract message speciﬁcation, each parameter tu-

ple can be replaced by an abstract parameter ﬁeld

combining identiﬁcation and value. The notiﬁca-

tion request primitive includes also an error value

and a list of parameters.

– [Error Value]: the error code associated with

the request primitive that the notiﬁcation relates

to; please refer to Table 2.

– [Parameter ID];

– [Parameter Value];

• response request: Primitive for requesting the

client application to receive the included response

information; this information is directly related to

the previous send, set, or status requests issued by

the client application and that can be identiﬁed by

the Message ID; the server shall address this prim-

itive to the origin IPv4 + UDP port of the client

application. This payload type also includes an

Error Value.

– [Error Value];

Data to be sent by the communication server

should be addressed to its data server UDP port 9011

using a send request primitive. All information to

be received by the client application should be ad-

dressed to a pre-conﬁgured client application UDP

port (except for the response request primitive). The

receive request primitive should be used by the server

to send data to the client application on port C PORT,

while the notiﬁcation request should be used to send

information about results on client requests to the

server.

The communication server also implements a con-

ﬁguration communication service to be used by the

application client. The service is asynchronous and

non-conﬁrmed. Conﬁguration of the server is attained

by setting conﬁguration communication parameters

through a set

request primitive addressed to the con-

ﬁguration server UDP port 9012. The client applica-

tion can check for the server’s conﬁguration by issu-

ing a status request to the conﬁguration server UDP

port 9012.

The communication server should always re-

spond with a response request to any send request,

set request, or status request. The communication

server should respond if the request was accepted or

not (it does not imply any conﬁrmation on the success

WINSYS 2022 - 19th International Conference on Wireless Networks and Mobile Systems

Table 1: Conﬁguration Parameters.

ID Value

Type

Name Obs

0x00 NA All parameters Indicates all parameters available

0x01 Unsigned

Integer

Number

of Anten-

nas/Ports

Number of medium anten-

nas/ports

0x02 Unsigned

Integer

Active An-

tenna/Port

Antennas/Ports, when available

should be numbered sequentially

(0x01, 0x02, etc.); if no antenna is

temporarily available then values

should be 0x00.

0x03 Unsigned

Integer

Active Chan-

nel Number

The active channel number (for

example, 0xAE for channel 174)

on the active antenna/port

0x04 Unsigned

Integer

Active Chan-

nel Bandwith

The active channel band-

with/spacing, in MHz (for

example, 0x0A for 10 MHz) on

the active anetnna/port

0x05 Unsigned

Integer

Active Chan-

nel Center

Frequency

Range

The active channel frequency

range in MHz (for example,

0x16EE for 5870 GHz) on the ac-

tive antenna/port

0x06 Unsigned

Integer

Active Chan-

nel TX power

the active channel TX power, in

-3

dBm (for example, 0x59D8

for 23 dBm) on the active an-

tenna/port

0x07 Unsigned

Integer

Active Chan-

nel Data

Rate

The active channel data rate, in

Kbits/s (for exampe, 0x1770 for

7Mbits/s)

0x08 Unsigned

Integer

CAM Genera-

tion Rate

CAM generation rate in Hz (for

example, 0x0A for 10Hz); if gen-

eration is 0x00 the CAM genera-

tion is off

0x09 Unsigned

Integer

CAM Echoing

Mode

If value is 0x00 CAM echoing to

client application is off, otherwise

it is on

0x0A Unsigned

Integer

DENM Gener-

ation Mode

If the value is 0x00 the generation

is off, on otherwise

0x0B Unsigned

Integer

DENM Echo-

ing mode

Same as CAM echoing mode

0x0C String, 4

charac-

ters

Pre-deﬁned

IPv4 Address

of the Client

application

”0.0.0.0” or ”255.255.255.255”

for broadcast on the IPv4 local

network.

0x0D Unsigned

Integer

Pre-deﬁned

UDP ad-

dress port

of the client

application

(C PORT)

If the value equals to 0x00 then

no client application is set (for ex-

ample 0,0x1F90 for port number

8080)

0x0E Unsigned

Integer

Server Re-

quest Time

Out

The amount of milliseconds that

the client should wait for the re-

spective server’s response request

before it considers it was not re-

ceived, ignored or unattended (for

example, 0x64 for 0,1 seconds)

or failure of the sending of the data through the con-

ﬁgured communication technology or the success or

failure of the setting request). The response request

should always be sent to the client IPv4 address and

UDP port of the client application’s original request,

and it could be sent from any ephemeral UDP port on

the server (implementing a concurrent UDP server),

or from 9011 or 9012 UDP ports. After a period of

time deﬁned by REQUEST TIME OUT (please re-

fer to 1), the client application can assume the request

was not received by the communication server.

The client application never responds to any prim-

itive received from the communication server, and all

Table 2: Error Codes.

ID Semantics

0x00 No error

0x01 Undeﬁned Error

0x02 Service not available at that port

0x03 Unrecognizable message type

0x04 Maximum Payload Length surpassed

0x05 Unrecognizable message type

0x06 Unrecognizable data type

0x07 Unrecognizable Parameter ID

0x08 Mismatch on Parameter value

0x08 Unacceptable parameter value

0x0A Unsupported parameter value

0x0B Invalid number of parameters

0x0C Unable to send data

0x0D Not enough memory

Table 3: Protobuf and ASN.1 notation comparison.

Protobuf

ASN.1

communications are insecure.

4.2 Data Structure

The goal of this API is to provide a methodology

for easy access to the OBU internals. Thus, the data

should be structured using a widely known format that

simpliﬁes its adoption and interoperability.

Two different methods of describing the structured

data were considered, Google’s protobuf (Google,

2022) and ASN.1 (ITU-T, 2022). In Table 3 is shown

a simple example of both methods.

Protobuf (Google, 2022) is a language-neutral,

platform-neutral mechanism for serializing structured

data. The data structure can be deﬁned and then use a

specially generated code to easily read and write this

data to and from a variety of data streams. It is, com-

paratively, more recent, but it has gained some mo-

mentum in the last years.

ASN.1 (ITU-T, 2022) is a format for describing

data transmitted by telecommunication protocols. It

is independent of the language implementation and

the physical representation of the data.

Agnostic Middleware for VANETs: Speciﬁcation, Implementation and Testing

Ideally, the chosen description language should

have tools that enable its translation directly to code,

thus, simplifying the implementation in any system or

language.

Google’s protobuf is more recent, and there are

far fewer tools, especially aimed at ARM processors.

The one tool found presented some bugs, crashing the

application each time the workload was increased.

ASN.1 has had more time to grow and evolve and

has many more tools available that allow its conver-

sion to multiple programming languages. So, it was

the description format chosen for the development of

the description of the messages. The data deﬁnitions

are shown next.

LTS-LCI DEFINITIONS AUTOMATIC TAGS::=

BEGIN

MessageHeader ::= SEQUENCE {

version INTEGER,

messageID INTEGER

}

CAMp2aMessage ::= SEQUENCE {

stationid INTEGER,

timestamp INTEGER,

latitude INTEGER,

longitude INTEGER,

heading INTEGER,

speed INTEGER,

acceleration INTEGER,

yawrate INTEGER

}

Parameter ::= SEQUENCE {

numberofantennas INTEGER OPTIONAL,

activeantennaorport INTEGER OPTIONAL,

activechannelnumber INTEGER OPTIONAL,

activechannelbandwith INTEGER OPTIONAL,

activechannelcenterfrequency INTEGER OPTIONAL,

activechanneltxpower INTEGER OPTIONAL,

activechanneldatarate INTEGER OPTIONAL,

camgenerationrate INTEGER OPTIONAL,

demngenerationmode INTEGER OPTIONAL,

demnechoingmode INTEGER OPTIONAL,

clientappip OCTET STRING OPTIONAL,

clientappcport INTEGER OPTIONAL,

serverrequesttimeout INTEGER OPTIONAL

}

DataType ::= ENUMERATED {

opaque (0)

}

Error ::= ENUMERATED {

noerror (0),

undefinederror (1),

servicenotavailableatthatport (2),

unrecognizableversion (3),

unrecognizablemessagetype (4),

maximumpayloadlengthsurpassed (5),

unrecognizabledatatype (6),

unrecognizableparatervalue (7),

mismatchonparametervalue (8),

unaceptlableparametervalue (9),

unsportedparametervalue (10),

invalidnumberofparameters (11),

unabletosenddata (12),

notenoughmemory (13)

}

ParameterID ::= ENUMERATED {

allparameters (0),

numberofantennas (1),

activechannelnumber (2),

activechannelbandwith (3),

activechannelcenterfrequency (4),

activechanneltxpower (5),

activechanneldatarate (6),

camgenerationrate (7),

camechoingmode (8),

demngenerationmode (9),

demnechoingmode (10),

clientappip (11),

clientappcport (12),

serverrequesttimeout (13)

}

Opaque ::= SEQUENCE {

datatype DataType,

data BIT STRING

}

Data ::= CHOICE {

opaque Opaque,

cam CAMp2aMessage

}

SendRequestMessage ::= SEQUENCE {

data Data

}

SetRequestMessage ::= SEQUENCE {

parameters Parameter

}

StatusRequestMessage ::= SEQUENCE {

parameterid INTEGER

}

ResponseRequestMessage ::= SEQUENCE {

error Error

}

ReceiveRequestMessage ::= SEQUENCE {

data Data

}

NotificationRequestMessage ::= SEQUENCE {

error Error,

parameters Parameter

}

WINSYS 2022 - 19th International Conference on Wireless Networks and Mobile Systems

Payload ::= CHOICE {

sendrequest SendRequestMessage,

receiverequest ReceiveRequestMessage,

setrequest SetRequestMessage,

statusrequest StatusRequestMessage,

resposerequest ResponseRequestMessage,

notificationrequest NotificationRequestMessage

}

MessageP2a ::= SEQUENCE {

messageheader MessageHeader,

payload Payload

}

5 PROTOCOL EVALUATION

The introduced overhead and overall message size

were measured through the implementation of a Java

application. One advantage of using ASN.1 is the

multitude of tools available that generate the code au-

tomatically, given the message deﬁnitions.

So, the application developed uses the ASN.1 for

the message deﬁnitions, which are then encoded us-

ing the Basic Encoding Rules (BER) (Mitra, 1994).

These deﬁne how information can be encoded using

binary. BER uses a Type Length Value (TLV) struc-

ture, as shown in Figure 2. The three components of

the structure can vary in size. The ﬁrst (type) has, typ-

ically, a ﬁxed size of 1 byte. The number of bytes oc-

cupied by the size information depends on the size of

the next component (value). A single byte is enough

if the information is smaller than 127 bytes. However,

if the value has 128 bytes or more, the length compo-

nent will need more than 1 byte. The last component

is the actual data of the element.

Figure 2: BER TLV structure.

The message types previously deﬁned can be di-

vided into two types, depending on their format.

SendRequest and ReceiveRequest, may have different

payloads with different sizes depending on the data

size or if they are Opaque or CAM. If the data type is

CAM, the data size is also ﬁxed.

The rest of the messages, NotiﬁcationRequests,

SetRequest, StatusRequest, NotiﬁcationRequest, and

ResponseRequest do not have payloads with different

sizes but ﬁxed parameters and error messages.

In the ﬁrst group of messages, their message size

and, more speciﬁcally, the overhead introduced was

evaluated and is shown in Table 4. In Table 5, the

message size for the other message types is shown. To

Table 4: Message size comparison (Bytes).

Payload Size Encoding Size Overhead

1 25 24

10 34 24

100 124 24

200 230 30

300 336 36

1000 1036 36

Table 5: Message size comparison (Bytes).

Message Type Encoding Size

SendRequest CAM 42

ReceiveRequest CAM 42

ResponseRequest 19

SetRequest 64

StatusRequest 17

NotiﬁcationRequest 67

be noticed that all the messages have an ID. So, the

total overhead of the messages can vary depending on

this value. This table also includes SendRequests and

ReceiveRequests when used with CAMs as the pay-

load because, in this case, they also have ﬁxed sizes.

Table 4 presents the overhead introduced in the

messages that may have different size payloads

(SendRequest, ReceiveRequest). As both message

types have the same format, their size and overhead

are equal. The columns indicate the original size of

the data payload, the size after the encoding process,

and the total overhead. All the mentioned message

types introduce the same overhead, so only one table

is presented for all of them. The overhead introduced

depends on the payload size being 24 bytes for pay-

loads smaller than 200 bytes, 30 bytes for messages

smaller than 200 bytes, and 36 bytes for messages

bigger than 300 bytes. Thus, the introduced overhead

is very small, and it is almost negligible for messages

bigger than 100 bytes. The overhead increases with

the size of the message due to the TLV structure of

the BER encoding. As previously stated, the length

component of the TLV is variable and increases with

the size of the data encoded.

The size of the other messages can be seen in Ta-

ble 5. This table shows the message size after encod-

ing for each message type that does not have a vari-

able payload size.

Any of the deﬁned messages with a ﬁxed size is

smaller than 70 bytes. The biggest one is the Notiﬁ-

cationRequest and the smallest StatusRequest. So, it

seems to have small enough sizes for in-vehicle com-

munications, either over wireless or wired mediums.

The evaluation of the protocol only considered the

overhead introduced by the multiple message types.

Encoding speed or delay introduced are metrics that

Agnostic Middleware for VANETs: Speciﬁcation, Implementation and Testing

heavily rely on external factors. The encoding speed

depends on the supporting device characteristics or

the coding of the application. The delay introduced

can be measured in two different places. The ﬁrst is

during the message encoding. This metric suffers the

same problem of the encoding speed. The other is

the delay introduced in the message exchange. As the

overhead introduced is very small and ideally trans-

mitted over high bandwidth mediums, the delay in-

troduced in the connection is negligible.

6 CONCLUSIONS

This paper presents an architecture for an agnostic

middleware and its corresponding API, as well as a

protocol speciﬁcation and implementation. The pre-

sented protocol allows third-party applications to eas-

ily take advantage of an agnostic architecture. It al-

lows applications to easily access the vehicle’s data

sources without any knowledge of the OBU internals.

The API’s messages are deﬁned using the ASN.1

notation over the UDP protocol. ASN.1 is a widely

used and accepted format for describing data trans-

mitted over communication protocols and is indepen-

dent of the data’s implementation language and phys-

ical representation, permitting its easy adoption.

The protocol was evaluated in terms of overhead

introduced. Evaluating the encoding speed and com-

munication time was not performed because it de-

pends on external factors. The overhead introduced

is minimal, with only 24 bytes in messages of 100

bytes and 36 for messages of more than 300 bytes.

The current implementation does not have any

security considerations. It is an in-vehicle proto-

col communication deployed in the same local area

network, which is considered a secure environment.

Nonetheless, it is to be investigated the impact and

need for security mechanisms.

The API and protocol are functional and allow ac-

cess to the conﬁguration parameters and services. It

was the basis for the implementation of a platoon-

ing application tested with success in the real world.

Currently, the OPENC2X (Laux et al., 2016; Klingler

et al., 2017) platform is being extended to support the

developed API. Nonetheless, it is still evolving, with

new functionalities being implemented.

ACKNOWLEDGEMENTS

This work has been supported by FCT – Fundac¸

para a Ci

encia e Tecnologia within the R&D Units

Project Scope: UIDB/00319/2020.

REFERENCES

Costa, R. (2013). VADM - A common API for agnostic ap-

plication development within VANETs. In Proceed-

ings Elmar - International Symposium Electronics in

Marine, pages 365–368.

Dias, B. et al. (2018). Agnostic and Modular Architec-

ture for the Development of Cooperative ITS Applica-

tions. Journal of Communications Software and Sys-

tems, 14(3):218–227.

Google (2022). Protocol Buffers. Online,

https://developers.google.com/protocol-buffers

(accessed on 2022-04-20).

Harrington, D. et al. (2002). An architecture for describing

simple network management protocol (snmp) man-

agement frameworks.

ITU-T (2022). ASN.1. Online, https://www.itu.int/en/ITU-

T/asn1/Pages/asn1 project.aspx (accessed on 2022-

04-20).

Jawhar, I. et al. (2013). An overview of inter-vehicular com-

munication systems, protocols and middleware. Jour-

nal of Networks, 8(12):2749–2761.

Klingler, F. et al. (2017). Poster: Field Testing Vehicu-

lar Networks Using OpenC2X. In Proceedings of the

15th Annual International Conference on Mobile Sys-

tems, Applications, and Services, MobiSys ’17, page

178, New York, NY, USA. Association for Computing

Machinery.

Laux, S. et al. (2016). Demo: OpenC2X — An open

source experimental and prototyping platform sup-

porting ETSI ITS-G5. In 2016 IEEE Vehicular Net-

working Conference (VNC), pages 1–2.

Mitra, N. (1994). Efﬁcient Encoding Rules for ASN.1-

Based Protocols. AT&T Technical Journal, 73(3):80–

93.

Nour, S. et al. (2011). Middleware for Data Sensing and

Processing in VANETs. In 2011 International Con-

ference on Emerging Intelligent Data and Web Tech-

nologies, pages 42–48. IEEE.

Silva, F. A. et al. (2013). ConProVA: A smart context provi-

sioning middleware for VANET applications. In IEEE

Vehicular Technology Conference.

Sousa, S., Santos, A., Costa, A., Dias, B., Ribeiro, B.,

Gonc¸alves, F., Macedo, J., Nicolau, M. J., and Gama,

O. (2017). A New Approach on Communications

Architectures for Intelligent Transportation Systems.

Procedia Computer Science, 110:320–327.

WG16, I. T. C. . (2014). ISO 21217: 2014: Intelligent trans-

port systems-Communications access for land mo-

biles (CALM)-Architecture.

Willke, T. et al. (2009). A survey of inter-vehicle commu-

nication protocols and their applications. IEEE Com-

munications Surveys and Tutorials, 11(2):3–20.

WINSYS 2022 - 19th International Conference on Wireless Networks and Mobile Systems