Protocol Interoperability for Intelligent Transportation Systems

Jonas Vogt

1, 2 a

and Hans D. Schotten

1 b

Division of Wireless Communications and Navigation (WiCoN), University of Kaiserslautern-Landau, Kaiserslautern,

Germany

ITS Research Group, University of Applied Sciences, htw saar, Saarbr

ucken, Germany

Keywords:

Intelligent Transportation Systems, Protocols, Interoperability, Cooperative Connected and Automated

Mobility.

Abstract:

Transportation is an essential part of daily life. To ensure optimal transportation of people and goods, all

stakeholders, including trafﬁc participants, infrastructure providers, and service providers, must be intercon-

nected. This interconnectivity enables efﬁcient trafﬁc management, energy and noise reduction, and safe

driving. However, integrating different systems via various communication technologies and protocols can

pose challenges to ensuring information quality, reliability, security, and privacy. As communication becomes

a more critical safety factor for connected and automated driving, and more systems are involved in commu-

nication, ensuring data quality becomes increasingly crucial. This includes data availability, range, precision,

privacy, and security. This paper presents an evaluation mechanism for assessing the quality of standardized

protocols in terms of interoperability. It can be concluded that, although many protocols exist in the ﬁeld of

intelligent transportation systems, they transport similar information but differ in details that may impact the

applications working with that information.

1 INTRODUCTION

In the ﬁeld of Intelligent Transportation Systems

(ITS), separate ecosystems have been established

in recent decades. These ecosystem includes in-

vehicle, trafﬁc infrastructure, service-oriented, and

direct communication systems. As current efforts to

shape future mobility include Cooperative, Connected

and Automated Mobility (CCAM), these once distinct

ecosystems must now interact. This interaction is es-

sential to the creation of a safe, eco-friendly, and efﬁ-

cient transportation system. Users are more likely to

adopt new multimodal mobility options if their mobil-

ity experience does not deteriorate. Therefore, the ac-

ceptance of these options is determined by these three

objectives. Each ecosystem has its own communica-

tion and application needs, which result in the cre-

ation of domain-speciﬁc speciﬁcations for data repre-

sentation, application and communication protocols,

and communication technologies. Interoperability is

crucial for the development of ITS and future mobil-

ity.

Protocols are used in various scenarios and ﬁelds

https://orcid.org/0000-0002-5856-0460

https://orcid.org/0000-0001-5005-3635

and can serve general or speciﬁc purposes. They can

be categorized based on their formal and informal

speciﬁcations. The protocol speciﬁcation combines

different components, starting with the speciﬁcation

of the protocol’s context. Then, the protocol descrip-

tion is speciﬁed, combining messaging and behavior.

Finally, data values are deﬁned. For example, the In-

ternet Protocol (IP) is a versatile protocol used in nu-

merous contexts, serving as a network protocol for the

Internet. In contrast, the Decentralized Environmen-

tal Notiﬁcation Message (DENM) is an application

layer protocol created for a speciﬁc purpose and en-

vironment, speciﬁcally for use in Cooperative Intelli-

gent Transportation Systems (C-ITS).

In this diverse environment, it is important to es-

tablish clear guidelines for transmitting data, includ-

ing when and what data should be transmitted. Ap-

plication developers can no longer rely on closed

ecosystems, such as those found in-vehicle or in traf-

ﬁc infrastructure. Instead, they must be able to adapt

to changing environments, unfamiliar data sources,

and ﬂuid communication environments. To do so,

they must establish mechanisms for distinguishing

between different protocols, data representations, and

communication behaviors. It is important to note that

228

Vogt, J. and Schotten, H.

Protocol Interoperability for Intelligent Transportation Systems.

DOI: 10.5220/0012554700003702

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 10th International Conference on Vehicle Technology and Intelligent Transport Systems (VEHITS 2024), pages 228-237

ISBN: 978-989-758-703-0; ISSN: 2184-495X

not all protocols may be adapted and common proto-

cols and data formats may not be used. We have de-

veloped an evaluation scheme to help application im-

plementers to identify possible interoperability issues.

This will enable developers to focus their attention on

those issues. This is just the ﬁrst step. A complete

evaluation involves assessing the connection between

speciﬁcations based on references, comparing formal

data speciﬁcations automatically, evaluating the data

itself, and assessing the ecosystems and architectures

for applications that use the speciﬁcations. These ad-

ditional steps are not included in this paper.

The paper is structured as follows: Section 2 de-

tails related work, Section 3 outlines the classiﬁca-

tion approach, Section 4 presents the ﬁndings and

Section 5 discusses these results. Finally, Section 6

presents the conclusion and provides an outlook for

future work.

2 RELATED WORK

The number of ITS standards is constantly chang-

ing. Publishers release new standards, remove out-

dated speciﬁcations, and revise current ones. Stan-

dards organizations monitor these changes through

their in-house and external mailing lists and websites.

There are publications, such as book chapters (e.g.,

(Williams, 2008), (Ernst, 2021)), and papers that sum-

marize the activities related to standards.

In their 2009 publication (Festag and Hess, 2009),

Festag and Hess provide an account of the early stan-

dardization processes and objectives in Europe. The

European ITS Station Reference Architecture is de-

tailed in (Festag, 2014), (Kosch et al., 2009), and

(Sousa et al., 2017) with speciﬁc attention to the co-

operative ITS (C-ITS) segment for direct communi-

cation. Various publications outline the current sta-

tus of ITS standardization and deployment in differ-

ent countries or regions. One example is Macioszek’s

study (Macioszek, 2014), which focuses on the situ-

ation in Poland. (Feng et al., 2017) discuss standard-

ization in China, while (Lim, 2012) and (Sugimoto,

1999) present plans for ITS in Korea and Japan, re-

spectively. (Padmadas et al., 2010) explain the de-

ployment of ITS in developing countries using the

example of license plate recognition and Djalalov

(Djalalov, 2013) discusses the role of standardization

in general. (Lonc and Cincilla, 2016) and (Hamida

et al., 2015) provide detailed information on secu-

rity aspects related to the architecture. Identity and

credential management requirements are detailed in

(Khodaei and Papadimitratos, 2015). The distribu-

tion of data and knowledge systems is examined in

ribyl et al., 2021), and ITS architecture require-

ments for information distribution based on applica-

tion viewpoints are available in (Ren et al., 2001).

Research projects like sim

T D

(St

ubing et al., 2010)

and C-MOBilE (Lu et al., 2018) also address these

topics. Standardization issues related to communica-

tion are covered in (Nsonga and Ustun, 2016) (EV

IEC 61850 and WAVE), as well as in (Zeadally et al.,

2020) (5G NR V2X and IEEE 802.11bd). Special at-

tention should be paid to functional safety in ITS in-

teroperability, as highlighted in (Mariani et al., 2021).

Standardization organizations provide overviews of

their speciﬁcations (CEN, 2024), (ETSI, 2024), (ISO,

2024). The International Telecommunication Union

(ITU) offers a synopsis of standardization documents

from different SDOs (ITU, 2024), allowing for easy

searching of documents from 16 organizations, with

a database of 1,265 ﬁles. Interoperability is discussed

in other ecosystems using two approaches: deﬁning a

common protocol/mapping or introducing a middle-

ware. The former approach has been explored in sev-

eral studies ((Park et al., 2009), (Cruz-S’nchez et al.,

2012), (Yacchirema et al., 2017), (Derhamy et al.,

2017), and (Bromberg et al., 2011)), while the lat-

ter has been investigated in other works ((Nakazawa

et al., 2006), (Cavalieri, 2021), and (Bouloukakis

et al., 2019)). Both approaches have their challenges.

The former requires a consensus among all stake-

holders, while the latter would require modiﬁcations

to various areas, which would not be feasible given

the current framework conditions in both vehicles and

trafﬁc infrastructure.

Although there is literature that offers a general

overview of the ﬁeld, none has provided insights into

interoperability speciﬁc to ITS. To the best of our

knowledge, speciﬁc research has been conducted on

standards interoperability in the various ITS ecosys-

tems.

3 APPROACH

The evaluation approach is based on classiﬁable cri-

teria. The following section outlines these criteria,

along with relevant calculations.

The criteria are divided into ﬁve groups: meta-

information, protocol category, communication par-

ticipants, protocol description, and protocol testing.

The meta-information describes the formal speciﬁca-

tions, while the protocol category speciﬁes the type

and purpose of the protocol. The criteria for com-

munication participants outline the systems and en-

tities involved in communication and categorize the

communication itself. The protocol description out-

Protocol Interoperability for Intelligent Transportation Systems

229

lines the protocol’s execution environment, intended

use, and context. Protocol testing incorporates mech-

anisms to assess the protocol’s implementation.

Figure 1 shows the ﬁve main categories of clas-

siﬁcation criteria: meta information, protocol cate-

gory, communication participants, protocol descrip-

tion, and protocol testing. These categories answer

the questions: what are the formal criteria, what is the

context/purpose of the protocol, who is communicat-

ing with whom, how is the protocol described, and

how can the protocol be tested and validated?

Figure 1 displays a total of 39 criteria. The criteria

are organized into separate vectors to ensure objectiv-

ity bias and provide a clear picture. Sub-vectors are

evaluated as a group. Values that are not comparable

or consist of text are divided into a more detailed set

of parameters to facilitate relative comparison. For

values that already consist of multiple values, a sub-

vector is created.

The following list provides guidelines for compar-

ing standards, focusing on the most important criteria.

• p

is+ik

. The protocol issuer is identiﬁed solely

by name, making it difﬁcult to compare. To fa-

cilitate comparison, a vector of determining fac-

tors is used. The vector includes the follow-

ing ﬁelds in the speciﬁed order: public/private,

proﬁt/non-proﬁt, international, African-based,

North American-based, South American-based,

Asia-Paciﬁc-based, European-based, national, na-

tional standardization body, ITS-domain-speciﬁc

topics, and communication-speciﬁc topics.

• p

. The protocol version is an important indica-

tor of whether the same version of the standard

is being used. It should not be assumed that the

latest version of the standard is always in use, as

legacy systems may still use older versions. Addi-

tionally, the speciﬁcation can be inﬂuenced by the

options and proﬁles of the standard. The version

may consist of a number, text, or a combination of

both.

• p

. Language can have an impact on the ability

of individuals to work with a speciﬁcation. While

many international speciﬁcations are written in

English, some national and regional speciﬁcations

are written in the native language of the country or

region. This can create challenges for implement-

ing an interoperable solution if the speciﬁcation

is not easily accessible due to language barriers.

This criterion is not directly related to interop-

erability in a strict sense but rather to the ability

of the implementer to understand and implement

the speciﬁcation. Misunderstandings could poten-

tially lead to interoperability issues.

• p

s f

. The comparability of a speciﬁcation may be

affected by whether it belongs to a standard family

or not. In some cases, this may result in an incom-

plete speciﬁcation that requires other parts of the

speciﬁcation family to be interpreted. Therefore,

it is important to thoroughly investigate the family

membership. However, a speciﬁcation may still

be complete even if it is of a family. It is im-

portant to consider different options and combi-

nations. The following example pertains to two

standards. If both standards belong to the same

family, they are expected to have the same val-

ues. If both standards are from different families

or not from any standard family, the values should

be different, but the properties may be the same.

However, if only one standard is from that family

and the other is not, different values are expected.

Therefore, it is necessary to extend this value with

the name of the standard being compared. In this

manner, different families would produce unique

results, and the lack of families would also pro-

duce distinct outcomes.

• p

. The validity of a speciﬁcation is directly re-

lated to the geographical area and the available in-

formation and how its interpretation. While other

intentions may remain the same, the interpretation

may vary.

• p

. The presence of necessary references is com-

parable to p

s f

. Including references implies that

the speciﬁcation is not self-contained and needs

additional information for a full assessment and

comparison. If neither speciﬁcation contains nor-

mative references, no further investigation is nec-

essary. If one or both documents cite normative

references, it indicates a need for a closer exami-

nation of the values presented.

• p

f s

. A formal speciﬁcation, such as Speciﬁcation

and Description Language (SDL), Message Se-

quence Charts (MSC), or Uniﬁed Modeling Lan-

guage (UML), must be used to describe a pro-

tocol precisely and without ambiguity. While a

written protocol can be open to interpretation, for-

mal languages leave no room for misunderstand-

ings. However, there may be some ﬂexibility in

the speciﬁcation of these languages for describing

the same protocol.

• cat. The protocol category indicates the protocol

type and its potential applications. The position

within the hierarchy demonstrates the relative re-

lationship between the protocols. The greater the

differences in values, the further apart the cate-

gory and intended protocols are.

• c

ps+pr

. Many protocols are designed for speciﬁc

VEHITS 2024 - 10th International Conference on Vehicle Technology and Intelligent Transport Systems

230

Figure 1: Overview about the classiﬁcation criteria.

use cases. They deﬁne information ﬂow as an

exchange between two designated systems. For

instance, communication between a Trafﬁc Man-

agement Center (TMC) and a Trafﬁc Light Con-

troller (TLC). On the other hand, some protocols

serve a general purpose. Internet Protocol (IP)

is a protocol for any scenario where information

is communicated between independent systems.

Communication can be affected by the abilities of

the source and destination when combined. In the

case of ITS, multiple layers can be identiﬁed (re-

fer to (ETSI, 2010a)). The sender and receiver

may be situated in the same or different layers.

The values indicate the layer or layers where com-

munication is intended to take place.

• c

en+di

. The endpoints deﬁne the relationship be-

tween the transmitter and receiver in a transmis-

sion, indicating the linkage and communication

direction. This is important because some pro-

tocols operate unidirectionally, while others re-

quire two-way communication. Understanding

both values provides insight into the protocol de-

signer’s intentions.

• d

co+pu

. Sometimes protocols are speciﬁed with-

out providing context. However, including the

necessary information can aid in interpretation.

Comparing context and purpose is interesting and

indicates that more information is available.

• d

. Interfaces can be included in a protocol spec-

iﬁcation to specify input and output information,

primarily input. This information can come from

data ﬂow, management, or security entities. The

presence of these interfaces provides insight into

the intended environment for the protocol.

• d

. External requirements can provide more in-

formation to assess the purpose and framework

conditions of the protocol.

• d

. When comparing two protocols, aside from

the actual data, the behavior of the protocols is

relevant, particularly when anticipating informa-

tion transfer between two distinct protocols.

• d

. If a protocol provides information through

push or pull, it can greatly affect interoperability.

If one protocol requires data to be pushed, but the

other only supplies data upon being pulled, then

interoperability is impossible.

• d

. Comparing data elements can be challenging

when unclear descriptions are used. Therefore,

a clear naming pattern is crucial for comparison.

For instance, if a value is referred to as ’speed’

rather than just ’s’, it becomes easier to under-

stand. It is essential to avoid ambiguous technical

terms that hinder comprehension.

• d

. The importance of clearly specifying the unit

of data elements cannot be overstated. When-

ever possible, the name of the unit should

be included in the element name, such as

’speed metersPerSecond’. If the unit is not al-

ready speciﬁed, the speciﬁcation should provide

clear clariﬁcation, including information about

the referencing system, such as elevation and alti-

tude.

• d

d p

. Plausibility value should be provided for val-

ues that cannot be precisely determined. For ex-

ample, a measurement error may be introduced

when obtaining a position from a Global Naviga-

tion Satellite System (GNSS) source. It is impor-

tant to communicate this information alongside

Protocol Interoperability for Intelligent Transportation Systems

231

the data so that the recipient can take it into ac-

count when interpreting the data.

• d

. The criteria for determining the suitability

of a data element for functional safety are crucial

for achieving interoperability. Different protocols

exhibit different methods in this regard.

• d

. To assess data, the type of data provided and

its processing are critical factors.

• d

. The reuse of data elements from another

speciﬁcation should be considered, as it is con-

nected to the incompleteness of the speciﬁcation.

• t

p+pd

. The Protocol Implementation Confor-

mance Statement (PICS) enumerates the compo-

nents of the speciﬁcation. It clariﬁes which parts

are required, optional, or conditional, and which

are included in the context of a particular imple-

mentation.

• t

s+sd

. The test speciﬁcations provide insight into

the relevant components and the minimum func-

tionality that can be expected from any implemen-

tation.

To assess the SDO, we have established twelve

criteria presented in Table 1. Each criterion has a bi-

nary value, with only two possible outcomes: zero or

one.

Table 1: Protocol issuer classiﬁcation.

Column Explanation

1 SDO is either private (0) or public (1) founded.

2 SDO is either a non-proﬁt (0) or a proﬁt (1) organization.

3 SDO is an international organization (1) or not (0).

4 SDO is responsible for Africa (1) or not (0).

5 SDO is responsible for North America (1) or not (0).

6 SDO is responsible for South America (1) or not (0).

7 SDO is responsible for Asia-Paciﬁc (1) or not (0).

8 SDO is responsible for Europa (1) or not (0).

9 SDO is responsible on a national level (1) or not (0).

10 SDO is a national standardization body (1) or not (0).

11 SDO speciﬁes ITS-domain-speciﬁc topics (1) or not (0).

12 SDO speciﬁes communication-speciﬁc topics (1) or not (0).

To explain table 1, we provide an example be-

low. The value for the European Telecommunica-

tions Standards Institute (ETSI) is 100 000 010 011.

ETSI is a non-proﬁt (second digit) European stan-

dardization organization authorized by the European

Commission for C-ITS (EU, 2009). It creates speci-

ﬁcations for the European Union (third digit) ans is

publicly-funded (ﬁrst digit). Therefore, digits four

to seven are zero and digit eight is marked as one.

ETSI is not a national SDO and is only indirectly re-

sponsible for national speciﬁcations. Certain ETSI

documents are transferred to the national SDO via

CENELEC. Therefore, digits nine and ten are set to

zero. ETSI is responsible for communication proto-

cols speciﬁc to intelligent transportation systems, as

well as general communication protocols and appli-

cation protocols speciﬁc to intelligent transportation

systems (digits 11 and 12 set to one).

4 RESULTS

Evaluations based on the given criteria and prepa-

ration have been conducted. Table 2 shows the re-

sults of selecting four different documents to visual-

ize the approach: ETSI DENM (ETSI, 2010b), Inter-

national Organization for Standardization (ISO) Sig-

nal Request Message (SRM) (CEN, 2019), SAE Inter-

national (SAE, formerly Society of Automotive En-

gineers) Radio Technical Commission for Maritime

Services Message (RTCM) (SAE, 2016), and German

Federal Highway Research Institute (BASt) Techni-

cal guidelines for outstations (TLS) (Bundesanstalt

ur Straßenwesen Bergisch Gladbach, 2013). This

excerpt discusses the challenges of using the classi-

ﬁcation. The speciﬁcations for DENM and TLS are

stand-alone. The remaining two cases are unique, as

they relate to a speciﬁc section of the speciﬁcation.

The speciﬁcation (SAE, 2016) is a collection of sev-

eral speciﬁcations, and the RTCM message is one of

those deﬁned within it. All of these messages share

the same data header and frame format. The purpose

of the SRM is twofold: to deﬁne the application pro-

tocols, including six of SAE’s 15 protocols (four of

which are extended), and to describe the requirements

and use cases for those six protocols. The geographic

region can generally be determined by the jurisdiction

of the issuing institution.

The formal speciﬁcation is provided in three of the

four speciﬁcations, with an expanded description of

the protocol’s behavior in three of the four instances.

The DENM protocol is the only protocol designed

for all communication endpoints. RTCM and DENM

are unidirectional. TLS, on the other hand, is bi-

directional (request-response). The directionality of

SRM is unclear. The message is transmitted with-

out an expected SRM message in return and instead

requires a Signal Status Message (SSM). The spec-

iﬁcations may not always consider external require-

ments (1/4) and context (2/4), but they always include

the purpose to varying degrees of detail. The clarity

of descriptions for data elements and units may not

always be consistent, with the TLS speciﬁcation us-

ing a distinct descriptive technique compared to the

other three. Finally, two of the speciﬁcations are self-

contained. One includes speciﬁc references, while the

other uses non-speciﬁc references.

Table 2 presents values that are primarily coded

for simpliﬁed automated comparison. These values

are binary-coded as a bitﬁeld to allow for combina-

VEHITS 2024 - 10th International Conference on Vehicle Technology and Intelligent Transport Systems

232

tions. The values in the table are deﬁned upon in-

troduction, with few exceptions. The category (cat)

includes 20 distinct values. This criterion uses four

different identiﬁers. These include 8 for application

environmental, 16 for application mobility, 36 for ap-

plication awareness (4) and application safety (32),

and 2088 for application awareness (4) and applica-

tion mobility (16) and ITS-related facility communi-

cation (2048). The values for the sender and receiver

ps+pr

) are categorized as back end (1), infrastructure

(2), pedestrian (4), vehicle (8), and other (16). Table 2

uses the following abbreviations: bac (backend), bidi

(bidirectional), ex (external), inf (infrastructure), ref

(references), spec (speciﬁc), uni (unidirectional), and

veh (vehicle).

Generative AI systems such as OpenAI ChatGPT,

Mircosoft Copilot, and Google Gemini can be utilized

to expedite the process. They can provide an overview

based on the given criteria for preliminary assess-

ment. Table 3 illustrates the combined feedback pro-

vided by the three AI systems for comparing the Co-

operative Awareness Message (CAM) (ETSI, 2019)

speciﬁcation of ETSI and the Basic Safety Message

(BSM) (SAE, 2016) speciﬁcation of SAE. The query

(’Compare the speciﬁcations of ETSI CAM and SAE

BSM based on the following criteria and show the re-

sult in a table. The criteria are protocol issuer, pro-

tocol version, protocol language, belongs to a stan-

dard family, geographical area the protocol is valid,

contains normative references, includes formal spec-

iﬁcation, deﬁnes speciﬁc sender and receiver, deﬁnes

communication endpoints, provides context and pur-

pose, includes interface description includes require-

ments, is a stateful or stateless protocol, push or pulls

information, conforms to data naming convention, in-

cludes plausibility values for data, includes informa-

tion for functional safety, resues data types, includes

PICS, includes test speciﬁcation.’) was asked three

times for every AI system.

5 DISCUSSION

Table 2 provides guidance for developers on trans-

ferring information between speciﬁcations. For in-

stance, consider DENM information and TLS tele-

grams. These speciﬁcations differ signiﬁcantly in

their approach and fall into separate categories (cat)

of ITS protocols, namely application safety (DENM)

and transport communication (TLS). Additionally,

they are written in different languages (p

). This is

not a technical interoperability issue, but rather a hu-

man one. To understand the details of a speciﬁcation

and implement data interoperability correctly, devel-

opers must grasp its meaning.

It is worth noting that DENM is a stateless pro-

tocol, while TLS is stateful (d

). The impact of this

difference depends on the speciﬁc situation in which

both protocols are used. If only data is being trans-

ferred from one protocol to another, the state may not

be relevant. However, if an application is waiting to

receive data via TLS and DENM is not providing this

data, it could cause the application to stall until the

data arrives. If an application includes both protocols,

it may face the challenge of information asymmetry,

where information is requestable via TLS but not via

DENM. This could lead to situations where applica-

tions do not possess all the information necessary to

evaluate a situation.

TLS does not have any formal speciﬁcations, but

it includes some behavioral aspects (p

f s

) related to

the protocol states. The data deﬁnitions differ be-

tween TLS and DENM’s speciﬁcations. TLS uses

only numbered ﬁelds with explanations for data el-

ement naming (d

), while DENM’s speciﬁcation de-

pends on other data deﬁnition speciﬁcations (ETSI

Common Data Dictionary (ETSI, 2023)). TLS’s data

deﬁnition is complete in this regard (d

). Only cer-

tain parts of the information can be transmitted due to

the signiﬁcant differences in the data elements. Fur-

thermore, while both TLS and DENM contain infor-

mation about data plausibility, they are not compat-

ible upon closer inspection. DENM has extensive

test speciﬁcations available, whereas TLS does not

p+pd

Table 3 presents the combined results of three AI

systems: OpenAI ChatGPT, Microsoft Copilot, and

Google Gemini of ETSI CAM and SAE BSM. None

of the systems produced a comprehensive result, and

they even contradicted each other on aspects such as

geographical area and testing capabilities. Often, the

correct speciﬁcation, EN 302 637-2 for CAM, was

not identiﬁed, and instead, DENM EN 302 637-3 was

mentioned. At times, even in versions such as 2.2.1,

which does not exist yet. The J2945-1A speciﬁca-

tion is mentioned regularly for SAE instead of J2735,

which is the test speciﬁcation for J2735. Prior knowl-

edge of the protocols is necessary to understand and

process the results at the current development state.

It is important to note that the results may vary when

two equal requests are made to the same AI system.

The criteria can be applied to a wide range of sit-

uations. If a simple comparison of communication

is required, only certain values should be used, such

as the data values d

, d

, and d

, the states d

and the communications paradigm d

. The commu-

nication and protocol categories criteria can be used

to establish primary compatibility. When conducting

Protocol Interoperability for Intelligent Transportation Systems

233

Table 2: Classiﬁcation example.

Criteria DENM SRM ISO RTCM SAE TLS

is+ik

100 000 010 011 010 000 000 111 011 010 000 011 100 000 001 011

Version 1.3.1 2019 Jul 2020 2012

English English English German

s f

4 (alone) 2 (part) 2 4

2 (Europe) 2 (America, Japan, Europe) 0 4 (National)

1 (8 ref) 1 (15 ref) 1 (15 ref) 1 (25 ref)

f s

1 + behavior 1 + behavior 1 0 + behavior

cat 36 16 8 2068

ps+pr

15 + 15 2 (inf) + 8 (veh) 2 + 12 (mainly) 1 (bac) + 2

63 (all) 8 (f-p) 2 (c-p) 1 (c-f)

1 (uni) 1 or 2 (bidi, with SSM) 1 2

2 (no) 1 (yes) 2 1

1 (yes) 1 1 (short) 1

1 (yes) 2 (no) 2 2

2 (no) 1 (yes) some extend 2 2

2 (stateless) 2 (1 with SSM) 2 1 (stateful)

1 (push) 1 1 4 (both)

1 (self) 4 (partly) 1 16 (not applicable)

1 (yes, ex) 8 (partly) 1 (yes) 8

d p

4 (some) 4 4 4

4 (some) 2 (no) 2 2

8 (undeﬁned) 8 8 8

1 (yes, spec) 2 (yes, non-spec) 0 (no) 0

p+pd

2 (yes, ex) + (ETSI, 2020a) 2 (yes, ex) + (ETSI, 2021a) 0 (not applicable) 2 (no)

s+sd

2 (yes, ex) + (ETSI, 2020b) and (ETSI, 2020c) 2 (yes, ex) + (ETSI, 2021b) and (ETSI, 2021c) 2 (no) 1 (yes, part)

Table 3: Comparison of ETSI CAM and SAE BSM.

Criteria ETSI CAM (EN 302 637-2) SAE BSM (J2735)

Protocol Issuer ETSI SAE International

Protocol Version EN 302 637-2 V1.4.1 (2019) J2735 (July 2020)

Protocol Language English English

Belongs to a Standard Family ETSI ITS V2X communications

Geographical Area Validity European Union Primarily North America

Contains Normative References Yes, lists multiple ISO, ETSI, and IEEE standards Yes, lists multiple SAE and IEEE standards

Includes Formal Speciﬁcation Yes, uses ASN.1 for data encoding and message structure Yes, uses ASN.1 for data encoding and message structure

Deﬁnes Speciﬁc Sender and Receiver Yes Yes, sender is an OBSE and receiver is any DSRC station

Deﬁnes Communication Endpoints Yes, uses DSRC ITS-G5 communication channels Yes, uses DSRC ITS-G5 communication channels

Provides Context and Purpose Cooperative awareness Safety communications

Includes Interface Description Yes, speciﬁes message structure and encoding rules Yes, speciﬁes message structure and encoding rules

Includes requirements Yes, speciﬁes requirements for message content and transmission Yes, speciﬁes requirements for message content and transmission

Stateful or Stateless protocol Stateless Stateless

Push or Pulls Information Push (broadcast-based) Push

Conforms to Data Naming Convention Yes, uses deﬁned ASN.1 data types and names Yes, uses deﬁned ASN.1 data types and names

Includes Plausibility Values for Data Not speciﬁed Not speciﬁed

Includes Information for Functional Safety Not speciﬁed Not speciﬁed

Reuses Data Types Yes Yes

Includes PICS Yes Yes

Includes Test Speciﬁcation Yes Yes

protocol testing, the criteria can be used to determine

the deﬁned test procedures and their compatibility.

The ﬁndings offer guidance to developers and sys-

tem architects, providing insight into critical ﬁelds for

the system, application, or use case.

6 CONCLUSION AND FUTURE

WORK

We proposed a mechanism for evaluating the infor-

mal part of ITS speciﬁcations. The proposed cate-

gories provide a comprehensive summary of the spec-

iﬁcations and allow for comparison between various

speciﬁcations. This knowledge enables the identiﬁca-

tion of potential interoperability issues before ﬁnaliz-

ing system or application design and implementation.

Although these measures do not replace integration

and interoperability testing, they provide a means to

make design choices, reducing problems early on in

the creation process. The deﬁned categories can be

customized to serve speciﬁc objectives, either inde-

pendently or as a subset.

Weights can be added to values to emphasize spe-

ciﬁc needs. This ﬂexible approach allows for adap-

tation to varied settings and requirements. However,

precise interpretation of speciﬁcations is vital, espe-

cially due to imprecise terminology that can lead to

identical concepts being described differently. Gener-

ative AI systems can provide an initial overview, but

they are currently unreliable in extracting the required

information from speciﬁcations. Additionally, they

cannot access speciﬁcations that are behind a paywall.

Even though the TLS (Bundesanstalt f

ur Straßenwe-

sen Bergisch Gladbach, 2013) speciﬁcation is freely

available, none of the three systems were able to ac-

cess it. Therefore, a specialized evaluation system

should be developed to meet the unique needs of the

evaluation process.

The next step is to fully automate the analysis

of formal speciﬁcation sections, including compar-

VEHITS 2024 - 10th International Conference on Vehicle Technology and Intelligent Transport Systems

234

ing data deﬁnitions in ASN.1 or UML. The purpose

of this analysis is to identify corresponding or seem-

ingly corresponding data ﬁelds and address the issue

of word ambiguity, such as the difference between

speed and velocity or elevation and altitude. Subse-

quently, we will evaluate the linkage between ecosys-

tems, architectures, and protocols.

ACKNOWLEDGEMENTS

This work was funded by the German projects

ConnRAD (grant number 16KISR032) and Gaia-

X4MoveID (grant number 19S22002L).

REFERENCES

Bouloukakis, G., Georgantas, N., Ntumba, P., and Is-

sarny, V. (2019). Automated synthesis of mediators

for middleware-layer protocol interoperability in the

IoT. Future Generation Computer Systems, 101(ISSN

0167-739X):1271–1294.

Bromberg, Y.-D., Grace, P., and R

eveill

ere, L. (2011).

Starlink: Runtime Interoperability between Heteroge-

neous Middleware Protocols. In 2011 31st Interna-

tional Conference on Distributed Computing Systems,

pages 446–455.

Bundesanstalt f

ur Straßenwesen Bergisch Gladbach (2013).

Technische Lieferbedingungen f

ur Streckenstationen.

Standard, Bundesministerium f

ur Verkehr, Bau und

Stadtentwicklung, Berlin.

Cavalieri, S. (2021). A Proposal to Improve Interoperability

in the Industry 4.0 Based on the Open Platform Com-

munications Uniﬁed Architecture Standard. Comput-

ers, 10(6).

CEN (2019). CEN/ISO TS 19091: Intelligent transport

systems - Cooperative ITS - Using V2I and I2V

communications for applications related to signal-

ized intersections. Technical speciﬁcation, European

Committee for Standardization; Technical committees

ISO/TC 204 - Intelligent Transport Systems, Brussels.

CEN (2024). Cen technical committee (tc) 278 its stan-

dardization website. https://www.itsstandards.eu/.

Accessed: 2024-02-18.

Cruz-S’nchez, H., Havet, L., Chehaider, M., and Song,

Y. (2012). MPIGate: A Solution to Use Heteroge-

neous Networks for Assisted Living Applications. In

2012 9th International Conference on Ubiquitous In-

telligence and Computing and 9th International Con-

ference on Autonomic and Trusted Computing, pages

104–111.

Derhamy, H., R

onnholm, J., Delsing, J., Eliasson, J., and

van Deventer, J. (2017). Protocol interoperability of

OPC UA in service oriented architectures. In 2017

IEEE 15th International Conference on Industrial In-

formatics (INDIN), pages 44–50.

Djalalov, M. (2013). The role of intelligent transportation

systems in developing countries and importance of

standardization. In 2013 Proceedings of ITU Kaleido-

scope: Building Sustainable Communities, pages 1–7,

Kyoto, Japan.

Ernst, T. (2021). Standards for cooperative intelligent trans-

port systems (c-its). In Bensrhair, A. and Bapin, T.,

editors, From AI to Autonomous and Connected Vehi-

cles. John Wiley & Sons, Ltd, London.

ETSI (2010a). EN 302 665: Intelligent Transport Systems

(ITS); Intelligent Transport Systems (ITS); Commu-

nications Architecture. European standard, European

Telecommunications Standards Institute; Intelligent

Transportation System, Technical Committee, Sophia

Antipolis Cedex.

ETSI (2010b). TS 102 636-3: Intelligent Transport Systems

(ITS); Vehicular Communications; GeoNetworking;

Part 3: Network architecture. Technical speciﬁ-

cation, European Telecommunications Standards In-

stitute; Intelligent Transportation System, Technical

Committee, Sophia Antipolis Cedex.

ETSI (2019). EN 302 637-2: Intelligent Transport Sys-

tems (ITS); Vehicular Communications; Basic Set of

Applications; Part 2: Speciﬁcation of Cooperative

Awareness Basic Service. European standard, Euro-

pean Telecommunications Standards Institute; Intel-

ligent Transportation System, Technical Committee,

Sophia Antipolis Cedex, France.

ETSI (2020a). TS 102 869-1: Intelligent Transport Systems

(ITS); Testing; Conformance test speciﬁcations for

Decentralized Environmental Notiﬁcation Basic Ser-

vice (DEN); Part 1: Test requirements and Protocol

Implementation Conformance Statement (PICS) pro

forma. Technical speciﬁcation, European Telecom-

munications Standards Institute; Intelligent Trans-

portation System, Technical Committee, Sophia An-

tipolis Cedex.

ETSI (2020b). TS 102 869-2: Intelligent Transport Sys-

tems (ITS); Testing; Conformance test speciﬁcations

for Decentralized Environmental Notiﬁcation Basic

Service (DEN)); Part 2: Test Suite Structure and Test

Purposes (TSS and TP). Technical speciﬁcation, Eu-

ropean Telecommunications Standards Institute; Intel-

ligent Transportation System, Technical Committee,

Sophia Antipolis Cedex.

ETSI (2020c). TS 102 869-3: Intelligent Transport Sys-

tems (ITS); Testing; Conformance test speciﬁcations

for Decentralized Environmental Notiﬁcation Basic

Service (DEN); Part 3: Abstract Test Suite (ATS)

and Protocol Implementation eXtra Information for

Testing (PIXIT). Technical speciﬁcation, European

Telecommunications Standards Institute; Intelligent

Transportation System, Technical Committee, Sophia

Antipolis Cedex.

ETSI (2021a). TS 103 191-1: Intelligent Transport Sys-

tems (ITS); Testing; Conformance test speciﬁcations

for Facilities layer protocols and communication re-

quirements for infrastructure services; Part 1: Test

requirements and Protocol Implementation Confor-

mance Statement (PICS) pro forma. Technical speci-

ﬁcation, European Telecommunications Standards In-

Protocol Interoperability for Intelligent Transportation Systems

235

stitute; Intelligent Transportation System, Technical

Committee, Sophia Antipolis Cedex.

ETSI (2021b). TS 103 191-2: Intelligent Transport

Systems (ITS); Testing; Conformance test speciﬁ-

cations for Facilities layer protocols and communi-

cation requirements for infrastructure services; Part

2: Test Suite Structure and Test Purposes (TSS and

TP). Technical speciﬁcation, European Telecommu-

nications Standards Institute; Intelligent Transporta-

tion System, Technical Committee, Sophia Antipolis

Cedex.

ETSI (2021c). TS 103 191-3: Intelligent Transport Systems

(ITS); Testing; Conformance test speciﬁcations for

Facilities layer protocols and communication require-

ments for infrastructure services; Part 3: Abstract

Test Suite (ATS) and Protocol Implementation eXtra

Information for Testing (PIXIT). Technical speciﬁ-

cation, European Telecommunications Standards In-

stitute; Intelligent Transportation System, Technical

Committee, Sophia Antipolis Cedex.

ETSI (2023). ETSI TS 102 894-2: Intelligent Transport

Systems (ITS); Users and applications requirements;

Part 2: Applications and facilities layer common data

dictionary; Release 2. Technical speciﬁcation, Euro-

pean Telecommunications Standards Institute; Intel-

ligent Transportation System, Technical Committee,

Sophia Antipolis Cedex.

ETSI (2024). Etsi standards overview. https://www.etsi.org

/standards. Accessed: 2024-02-18.

EU (2009). M/453 EN: Standardisation mandate addressed

to CEN, CENELEC and ETSI in the ﬁeld of infor-

mation and communication technologies to support

the interoperability of co-operative systems for intel-

ligent transport in the European community. Eu man-

date, European Commission: Enterprise and Industry

Directorate-General, Brussels.

Feng, Y., He, D., Niu, L., Yang, M., and Guan, Y. (2017).

The overview of chinese cooperative intelligent trans-

portation system vehicular communication applica-

tion layer speciﬁcation and data exchange standard.

In Information Technology and Intelligent Transporta-

tion Systems - Proceedings of the 2nd International

Conference on Information Technology and Intelligent

Transportation Systems (ITITS), volume 296 of Fron-

tiers in Artiﬁcial Intelligence and Applications, pages

516–526, Xi’an, China. IOS Press.

Festag, A. (2014). Cooperative intelligent transport systems

standards in europe. IEEE Communications Maga-

zine, 52(12):166–172.

Festag, A. and Hess, S. (2009). Etsi technical commit-

tee its: news from european standardization for in-

telligent transport systems (its)- [global communica-

tions newsletter]. IEEE Communications Magazine,

47(6):1–4.

Hamida, E. B., Noura, H., and Znaidi, W. (2015). Secu-

rity of cooperative intelligent transport systems: Stan-

dards, threats analysis and cryptographic countermea-

sures. Electronics, 4(3):380–423.

ISO (2024). Iso technical committee (tc) 204. https://www.

iso.org/committee/54706.html. Accessed: 2024-02-

18.

ITU (2024). Itu its speciﬁcation overview. https://www.itu.

int/itu-t/landscape/. Accessed: 2024-02-18.

Khodaei, M. and Papadimitratos, P. (2015). The key to in-

telligent transportation: Identity and credential man-

agement in vehicular communication systems. IEEE

Vehicular Technology Magazine, 10(4):63–69.

Kosch, T., Kulp, I., Bechler, M., Strassberger, M., Weyl, B.,

and Lasowski, R. (2009). Communication architec-

ture for cooperative systems in europe. IEEE Commu-

nications Magazine, 47(5):116–125.

Lim, S. (2012). Korean its standardization. In 2012 7th

International Conference on Computing and Conver-

gence Technology (ICCCT), pages 1235–1238, Seoul.

Lonc, B. and Cincilla, P. (2016). Cooperative ITS security

framework: Standards and implementations progress

in Europe. In 2016 IEEE 17th International Sympo-

sium on A World of Wireless, Mobile and Multimedia

Networks (WoWMoM), pages 1–6.

Lu, M., Blokpoel, R., F

unfrocken, M., and Castells, J.

(2018). Open architecture for internet-based c-its ser-

vices. In 2018 21st International Conference on In-

telligent Transportation Systems (ITSC), pages 7–13,

Maui.

Macioszek, E. (2014). Architecture of intelligent trans-

portation systems in the world and in poland. Archives

of Transport System Telematics, Vol. 7, iss. 3:22–26.

Mariani, R., Maor, N., Athavale, J., and Gay, K. (2021).

The importance of interoperability in functional safety

standards. Computer, 54(3):80–84.

Nakazawa, J., Tokuda, H., Edwards, W. K., and Ramachan-

dran, U. (2006). A Bridging Framework for Universal

Interoperability in Pervasive Systems. In 26th IEEE

International Conference on Distributed Computing

Systems (ICDCS’06), pages 3–3.

Nsonga, P. and Ustun, T. S. (2016). Integration of com-

munication standards in electrical vehicle ad-hoc net-

works for smartgrid support. In 2016 IEEE Interna-

tional Conference on Emerging Technologies and In-

novative Business Practices for the Transformation of

Societies (EmergiTech), pages 106–111, Balaclava.

Padmadas, M., Nallaperumal, K., Mualidharan, V., and

Ravikumar, P. (2010). A deployable architecture of in-

telligent transportation system — a developing coun-

try perspective. In 2010 IEEE International Confer-

ence on Computational Intelligence and Computing

Research, pages 1–6, Coimbatore.

Park, H., Lee, H., Park, S., and Lee, D. H. (2009). Devel-

oping a Multi-Protocol Mobility Manager for SIP/SS7

Networks. In 2009 International Conference on Com-

plex, Intelligent and Software Intensive Systems, pages

565–570.

ribyl, P., Janota, A., Spalek, J., and Faltus, V. (2021).

Knowledge System Supporting ITS Deployment. Sus-

tainability, 13(11).

Ren, J.-T., Zhang, Y., heng Li, Z., and cheng Hu, D. (2001).

An architecture for its information application sys-

tems. In ITSC 2001. 2001 IEEE Intelligent Trans-

portation Systems. Proceedings (Cat. No.01TH8585),

pages 994–999, Oakland.

VEHITS 2024 - 10th International Conference on Vehicle Technology and Intelligent Transport Systems

236

SAE (2016). SAE J2735: Dedicated Short Range Commu-

nications (DSRC) Message Set Dictionary. Standard,

Society of Automotive Engineers (SAE); DSRC com-

mittee, Warrendale.

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

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

Oscar

Gama (2017). A new approach on communications ar-

chitectures for intelligent transportation systems. Pro-

cedia Computer Science, 110(ISSN 1877-0509):320–

327. 14th International Conference on Mobile Sys-

tems and Pervasive Computing (MobiSPC 2017) /

12th International Conference on Future Networks

and Communications (FNC 2017) / Afﬁliated Work-

shops.

ubing, H., Bechler, M., Heussner, D., May, T., Radusch,

I., Rechner, H., and Vogel, P. (2010). simtd: a car-to-

x system architecture for ﬁeld operational tests [top-

ics in automotive networking]. IEEE Communications

Magazine, 48(5):148–154.

Sugimoto, T. (1999). Current status of its and

its international cooperation. In Proceedings of

the IEEE International Vehicle Electronics Confer-

ence (IVEC’99) (Cat. No.99EX257), pages 503–507

Suppl., Changchun.

Williams, B. (2008). Intelligent Transport Systems Stan-

dards. Artech House, London, 2nd edition.

Yacchirema, D. C., Palau, C. E., and Esteve, M. (2017).

Enable IoT interoperability in ambient assisted liv-

ing: Active and healthy aging scenarios. In 2017 14th

IEEE Annual Consumer Communications Networking

Conference (CCNC), pages 53–58.

Zeadally, S., Javed, M. A., and Hamida, E. B. (2020). Ve-

hicular communications for its: Standardization and

challenges. IEEE Communications Standards Maga-

zine, 4(1):11–17.

Protocol Interoperability for Intelligent Transportation Systems

237