ISO/TR 23255:2022

TECHNICAL ISO/TR
REPORT 23255
First edition
2022-04
Intelligent transport systems —
Architecture — Applicability of data
distribution technologies within ITS
Systèmes de transport intelligents — Architecture — Applicabilité des
technologies de distribution des données dans les ITS
Reference number
ISO/TR 23255:2022(E)
© ISO 2022

---------------------- Page: 1 ----------------------
ISO/TR 23255:2022(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2022
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
  © ISO 2022 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/TR 23255:2022(E)
Contents Page
Foreword .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 Transitioning from traditional to cooperative thinking . 4
5.1 General . 4
5.1.1 Need for data exchanges . 4
5.1.2 Data distribution functionality . 5
5.2 Systems engineering process . 6
5.2.1 Conceptualization . 6
5.2.2 System architecture . 6
5.2.3 System design . 6
5.3 Traditional silos versus cooperative approaches . 7
6 Summary of needs and considerations . 7
6.1 General . 7
6.2 Types of information flows . 7
6.2.1 General . 7
6.2.2 Non-emergency information sharing . 8
6.2.3 Emergency information sharing . 8
6.2.4 Control flows . . 8
6.2.5 Interrogatives . 8
6.2.6 Local exchanges . 8
6.3 Characteristics. 8
6.4 Solution characteristics . 9
6.4.1 General . 9
6.4.2 Architectural topology. 9
6.4.3 Technology maturity and deployment characteristics .13
6.5 Objective analysis .15
6.5.1 General .15
6.5.2 Protocols tested .15
6.5.3 Protocols considered and not analysed . 16
6.5.4 Protocols considered and investigated but not tested . 17
6.5.5 Summary . 17
7 Summary of analysis results .18
7.1 General . 18
7.2 Quantitative results . 18
7.2.1 General . 18
7.2.2 Many2One . 18
7.2.3 One2Many . 20
7.2.4 10 to Many . 21
7.2.5 50 to Many .23
7.2.6 N to N . 24
7.2.7 Latency as a function of completion percentage .29
7.2.8 Other tests . 30
7.3 Qualitative lessons learned . 31
8 Summary of protocol characteristics and applicability to ITS .31
9 Conclusion .35
Annex A (informative) Test environment .37
iii
© ISO 2022 – All rights reserved

---------------------- Page: 3 ----------------------
ISO/TR 23255:2022(E)
Bibliography .40
iv
  © ISO 2022 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/TR 23255:2022(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
v
© ISO 2022 – All rights reserved

---------------------- Page: 5 ----------------------
ISO/TR 23255:2022(E)
Introduction
Since the early 2000s, various study, design and prototype efforts have been undertaken to explore the
potential use of communications in the vehicular environment. The first of these to demonstrate at real
scale was the Vehicle Infrastructure Initiative (VII), which demonstrated short range wireless-based
probe data generation and traveller advisory message delivery. This suggested the viability of initial
vehicle-to-vehicle and vehicle-to-infrastructure communications.
Subsequent projects worked to more formally define the “glue” components necessary to enable
widespread deployment. Several of these projects concluded that a publish-subscribe data distribution
paradigm was a necessary component of any connected vehicle implementation of significant scale.
These conclusions and much of the supporting work eventually found its way into ITS architectures.
Much of this material is currently included in the Architecture Reference for Cooperative and Intelligent
[6]
Transportation (ARC-IT) .
More recent pilot projects and deployments in both the United States and Europe have included publish-
subscribe technologies, but no independent, objective analyses of the advantages and disadvantages of
using specific protocols to facilitate data exchange within ITS are available. This document describes
such an analysis.
vi
  © ISO 2022 – All rights reserved

---------------------- Page: 6 ----------------------
TECHNICAL REPORT ISO/TR 23255:2022(E)
Intelligent transport systems — Architecture —
Applicability of data distribution technologies within ITS
1 Scope
A variety of general-purpose data distribution technologies have emerged within the Information and
Communications Technologies (ICT) industry. These technologies generally provide services at the
Open System Interconnect (OSI) session, presentation and application layers (i.e. layers 5-7). Within
Intelligent Transport Systems (ITS), these layers roughly correspond to the facilities layer of the ITS
station (ITS-S) reference architecture, as defined within ISO 21217.
This document investigates the applicability of these data distribution technologies within the ITS
environment.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/TS 14812, Intelligent Transport Systems — Vocabulary
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/TS 14812 and the following
apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
data distribution functionality
DDF
facilities layer (OSI layers 5, 6, and 7) functionality comprised of a set of data distribution services
that enables distribution of data throughout a communication network controlled by a set of policies,
regulations and rules
Note 1 to entry: Each distinct data distribution technology has its own unique data distribution functionality.
3.2
data distribution service
DDS
element of a set of services that implements a data distribution functionality in a communication
network
EXAMPLE 1 Publish: the provision of data from one entity to another, where the receiving entity has previously
registered to receive such data from the entity providing the data.
EXAMPLE 2 Subscribe: mechanism by which one entity registers for the reception of particular data from
another entity.
1
© ISO 2022 – All rights reserved

---------------------- Page: 7 ----------------------
ISO/TR 23255:2022(E)
EXAMPLE 3 Discovery: mechanism by which entities implementing DDF learn necessary particulars about
how to communicate with one another (e.g. lower layer network address, ports, etc.).
Note 1 to entry: This is a specific protocol standardized by the OMG.
4 Abbreviated terms
AES Advanced Encryption Standard
AMQP advanced message queuing protocol
API application programming interface
ARC-IT architecture reference for cooperative and intelligent transportation
ASN.1 abstract syntax notion one
AUTOSAR automotive open system architecture
C-ITS cooperative ITS
C2C centre-to-centre
C2F centre-to-field
C2P centre-to-personal station
C2V centre-to-vehicle
C2X centre-to-anything
CoAP constrained application protocol
ConOps concept of operations
CSSDDS commercial source software DDS
CSV comma separated value
DSRC dedicated short range communications
FEP-SDK functional engineering platform software development kit
FIPS Federal Information Processing Standard
HARTS harmonized architecture reference for technical standards
HTTP hypertext transfer protocol
IANA internet assigned numbers authority
ICD interface control document
ICT information and communications technology
IDL interface definition language
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronic Engineers
2
  © ISO 2022 – All rights reserved

---------------------- Page: 8 ----------------------
ISO/TR 23255:2022(E)
IoT internet of things
IP internet protocol
ISO Organization of International Standardization
ITS intelligent transport systems
ITS-S ITS station
ITS-SU ITS station unit
JMS Java Message Service
JSON Javascript Object Notation
MQTT message queuing telemetry transport
NTCIP National Transportation Communications for ITS Protocol
OMG object management group
OASIS Organization for the Advancement of Structured Information Standards
OS operating system
OSI open system interconnect
OSS DDS open source software DDS
PHP hypertext preprocessor
REST representational state transfer
RSS really simple syndication
SNMP simple network management protocol
SOAP simple object access protocol
STOMP simple text-oriented messaging protocol
TCP transport control protocol
TLS transport layer security
UDP user datagram protocol
UML Unified Modeling Language
V2I vehicle-to-infrastructure (communications)
VII vehicle infrastructure initiative
V2V vehicle-to-vehicle (communications)
XML Extensible Markup Language
XMPP Extensible Messaging and Presence Protocol
3
© ISO 2022 – All rights reserved

---------------------- Page: 9 ----------------------
ISO/TR 23255:2022(E)
5 Transitioning from traditional to cooperative thinking
5.1 General
5.1.1 Need for data exchanges
ITS is heavily dependent upon the exchange of various types of data between and among disparate types
of physical entities. As described within the Architecture Reference for Cooperative and Intelligent
Transportation (see Reference [6]), such entities include:
— centres (e.g. fixed-location facilities and cloud-based back-office services);
— field devices (e.g. devices along the roadside);
— vehicles;
— travellers (e.g. personal devices);
— support systems (typically fixed or back-office, that provide services enabling ITS, but do not
directly provide ITS services).
The data that these systems exchange include:
— live elemental data (e.g. vehicle speed, location, signal timing information, device status, etc.);
— live aggregated data (e.g. average speeds, rain rates, etc.);
— status information (e.g. status of reversible flow lanes);
— (relatively) static data (e.g. map information);
— quasi-static information (e.g. road conditions, weather);
— exception reports (e.g. information on traffic incidents, realignment of lanes due to incidents or
road work, etc.);
— control and configuration data (e.g. device control, software configuration);
— coordination data (e.g. exchanges to coordinate a response plan among centres);
— traffic regulations;
— software updates (e.g. for on-board applications);
— security material distribution including certificates and revocation lists.
Entities exchange data according to some well-characterized patterns. Certain kinds of entities typically
exchange certain kinds of data, and some characteristics of those exchanges tend to be relatively
consistent for similar kinds of data. For example:
— centres provide control and configuration data to field devices. These exchanges tend to be
synchronous request-response-based exchanges and occur irregularly;
— centres exchange coordination data with one another. These exchanges vary in size and format and
occur irregularly;
— field devices provide elemental and aggregated data to centres. These exchanges tend to be periodic
and are often redistributed centre-to-centre;
— centres provide exceptional information to field, vehicle, and personal devices. As exceptions, these
are irregular. The information is often geo-centric and needs to be disseminated to all entities
within a defined area that can benefit from such information, such as the dissemination of traffic
incidents to all vehicles upstream of the incident;
4
  © ISO 2022 – All rights reserved

---------------------- Page: 10 ----------------------
ISO/TR 23255:2022(E)
— centres provide information of wide utility (e.g. traffic regulations) to all vehicles in a geographic
area. These exchanges vary in size, can be initiated by either party depending on the communications
regime and are typically motivated by the geo-location of the vehicle or personal device;
— vehicles provide live and aggregated data to field devices and centres. These exchanges are typically
periodic and can be pseudonymized.
Additionally, some of the information exchanged can be useful for supporting ITS services other than
the ITS service for which the data was originally intended. Some of the information acquired and
exchanged between entities when implementing a specific ITS service also has potential value outside
ITS.
The challenges inherent in attempting to efficiently share information are two-fold. First, information
has value; often those involved in the acquisition will attempt to retain ownership of and control over
such information and to minimize privacy issues. Second, assuming the information can be made
available from the source, the technical challenge arises of getting the information to the right places
at the right times while implementing the established privacy policies. This document addresses the
later issue, The former issue is addressed by regulatory entities and other stakeholders in the ITS
community.
There are a variety of technical and institutional challenges related to successfully sharing data in a
timely and secure manner. These challenges include:
— acquiring the data (e.g. through sensors);
— defining ownership and access rights for the data;
— securing the data (e.g. authentication, authorization, confidentiality, integrity, availability, etc.);
— achieving adequate market penetration of lower-layer communication technologies;
— agreeing on the upper-layer protocols for exchanging the data over the communication technologies;
— standardizing the definition of data for use in various contexts;
— defining performance criteria for different uses of the data;
— maintaining the interface over the life cycle of the involved physical objects. Operational lifetimes
for ITS devices vary radically: field devices often have lifetimes of 15-20 years, vehicles closer to 10
(although often much longer) and smartphones can be as short as 18 months.
5.1.2 Data distribution functionality
A data distribution functionality (DDF) is implemented as a set of facilities layer (OSI layers 5, 6, and
7) services that enables distribution of data throughout a communication network controlled by a set
of policies, regulations and rules. Through a standardized application programming interface (API),
application processes can request information from (subscribe) and offer information to (publish)
the communication network to which they are attached without needing to know anything about the
details of how the information transfers take place. Using metadata and service configuration requests,
a variety of policies, rules and regulations can be implemented. When using DDF, application processes
no longer need to directly create and consume messages with other application processes to affect
information exchange. Instead, application processes publish data they agree to share (and receive data
they are interested in) through an API without having to know anything about the final destination(s)
(or source) or having to conform to a particular message format for each end entity.
NOTE The Object Management Group (OMG) has created a set of standards for data distribution functionality
(see 3.1) called the Data Distribution Service (DDS). This document uses the term “OMG DDS” to refer to OMG’s
understanding of data distribution functionality and the term “DDF” to refer to a generic data distribution
functionality.
5
© ISO 2022 – All rights reserved

---------------------- Page: 11 ----------------------
ISO/TR 23255:2022(E)
5.2 Systems engineering process
5.2.1 Conceptualization
The systems engineering approach to designing any complex system is to work with the relevant
stakeholders, including service providers and system integrators, to develop a “concept of operations”,
or ConOps. This involves describing in detail the service (the “why”), the actors participating in the
service (the “who”), and the requirements on information to be generated and exchanged by entities
engaged in the service (the “what”).
Once agreement is reached on the ConOps, the implementers work together to develop a high-level
design (i.e. an architecture) that defines the means by which the service will be implemented (the
“how”), which (directly or indirectly) defines the details of how the information is encoded and
transferred between physical objects. If the system is intended to support an open interface (i.e. so
that competing manufacturers can interoperate), these design details need to be defined within open
standards and developed with broad-based consensus.
5.2.2 System architecture
An architecture description of a specific system of interest can leverage existing work (e.g. reference
architectures such as ARC-IT) to simplify the organization of content, provide a common language
reference and assist in identifying implementation-relevant artifacts, in particular interfaces as well
as the standards used to implement endpoints and interfaces. The reference architecture can illustrate
where many information exchanges overlap or group together in patterns, which would suggest an
opportunity for consolidation that is relevant to a DDF.
For example, if several information flows all have the same source and destination, then perhaps those
information flows can share a DDF technology to provide some aspects of the information exchange.
These patterns will generally become clear if a system architecture is illustrated.
The system architecture development process can suggest design paradigms for interfaces, where some
interfaces are traditional ‘mesh’ interfaces (custom at each end), while others use a DDF to provide
transport, publication and subscription management, with or without a hub/broker. More complex
involvements can require hierarchies, which can be best noted if data dependencies are clearly shown.
5.2.3 System design
Open system design activities focus on developing interface control documents (ICDs), which specify
the:
— rules for application processes needing to share data;
— data elements to be exchanged;
— messages that contain those elements;
— dialogues and patterns of message exchange, which suggest or require behaviours at end points;
— lower layer details (i.e. details of the network and transport layer and access layer of the ITS-S
architecture).
Each DDF specification provides the messaging and dialogue components of the ICD. In many cases,
other standards will define the other aspects of the ICD and the ICD itself becomes primarily a reference
to a series of standards. Using DDF provides significant savings because it relies upon a single standard
interface for exchanging any data rather than requiring specialized messages for each interface.
6
  © ISO 2022 – All rights reserved

---------------------- Page: 12 ----------------------
ISO/TR 23255:2022(E)
5.3 Traditional silos versus cooperative approaches
Once the architecture is developed, each interface is designed by its own group of experts to meet the
defined needs. However, this division of effort tends to produce “silos” of thought that can o
...