ISO/TR 23255:2022

Intelligent transport systems - Architecture - Applicability of data distribution technologies within ITS

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.

Systèmes de transport intelligents — Architecture — Applicabilité des technologies de distribution des données dans les ITS

General Information

• Status: Published
• Publication Date: 28-Apr-2022
• ICS: 03.220.01 - Transport in general
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 1 - Architecture
• Current Stage: 6060 - International Standard published
• Start Date: 29-Apr-2022
• Due Date: 12-Jun-2021
• Completion Date: 29-Apr-2022

Overview

ISO/TR 23255:2022 - Intelligent transport systems - Architecture - Applicability of data distribution technologies within ITS evaluates how general-purpose data distribution technologies from the ICT industry can be applied to Intelligent Transport Systems (ITS). The report maps these technologies to the ITS station (ITS‑S) reference architecture - specifically the facilities layer (OSI layers 5–7) as defined in ISO 21217 - and provides an objective analysis of their applicability, performance characteristics and architectural fit.

Key topics and technical focus

• Data distribution functionality (DDF) and data distribution services (DDS): definitions and how services such as publish/subscribe and discovery fit ITS use‑cases.
• Publish‑subscribe paradigm: rationale for use in ITS and how it supports scalable vehicle‑to‑vehicle (V2V), vehicle‑to‑infrastructure (V2I) and centre‑to‑any (C2X) exchanges.
• Types of information flows: non‑emergency, emergency, control flows, interrogatives and local exchanges - and their differing requirements.
• Performance and scalability metrics: latency, completion percentage, and scenarios such as Many→One, One→Many, 10→Many, 50→Many and N↔N topologies.
• Solution characteristics and architecture: considerations for topology, deployment maturity, protocol interoperability and system engineering lifecycle (conceptualization, architecture and design).
• Protocol survey: discussion and testing of common protocols and stacks referenced in ITS contexts (examples in the report include DDS, MQTT, AMQP, HTTP/REST, XMPP and others).
• Test environment and objective analysis: methodology and annexed test environment description used to compare protocol behaviors and qualitative lessons learned.

Practical applications and intended users

Who benefits from ISO/TR 23255:2022:

• ITS architects and system designers selecting data distribution approaches for connected‑vehicle systems.
• Transport agencies and solution integrators evaluating publish‑subscribe and other middleware for real‑time messaging.
• Vendors and software developers implementing ITS‑facilities layer services (ITS‑S/ITS‑SU).
• Researchers and project managers running pilots or benchmarking protocols for scalability, latency and reliability in ITS deployments.

Practical uses:

• Informing procurement and technology selection for cooperative ITS projects.
• Guiding system architecture decisions for V2V, V2I and C2X messaging patterns.
• Supporting design trade‑offs around latency, topology and message distribution policies.

Related standards (if applicable)

• ISO 21217 - ITS station reference architecture (facilities layer mapping).
• ISO/TS 14812 - ITS vocabulary.
• ARC‑IT (Architecture Reference for Cooperative and Intelligent Transportation) - contextual material and use‑case guidance cited in the report.

Keywords: ISO/TR 23255:2022, Intelligent Transport Systems, data distribution, publish‑subscribe, ITS architecture, facilities layer, ITS‑S, DDS, MQTT, AMQP, latency, scalability.

Standards Content (Sample)

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 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: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
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
Bibliography .40
iv
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
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
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.
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
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
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;
— 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.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.
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 often result
in four major problems:
1) Competing protocol selection: Different silo efforts are likely to select different approaches to
exchanging data. There are many off-the-shelf protocols that can be extended to support most
ITS data exchange needs and some experts can wish to develop their own protocols to optimize
performance in certain cases. While each decision can be reasonable in isolation, each protocol
adopted by the ITS industry has costs associated with stakeholders learning the technology,
implementers programming with the technology, testers verifying conformance to the technology,
and maintenance issues with maintaining backwards compatibility, as well as memory and
processing issues within devices that need to support multiple technologies. Ideally, the ITS
community as a whole can attempt to identify a suite of preferred protocols that meet industry
needs so that the variability in systems is minimized.
2) Competing data definitions: Different silo efforts are likely to produce different data definitions to
describe the same real-world conditions. This greatly complicates data sharing, increases potential
translation errors, and increases integration costs. Ideally, all ITS data definitions can be developed
in a cooperative fashion.
3) Limited scope and lack of forwards compatibility: Engineers within the silo teams often attempt
to “optimize” their design; however, without a complete knowledge of how data can be used, it is
impossible to know if a design is truly optimal or not. This can partially be overcome by ensuring
that the reference architecture is developed with as broad a scope as practical, but since innovations
occur over time, no effort can be omniscient about how the data will be used; one can only attempt
to consider as much data as possible.
4) Competing efforts: A final challenge facing any development team is that there are often different
competing and/or overlapping efforts across the world. Once standards are developed, it is often
difficult and expensive to harmonize the results at a later point.
This document attempts to address the first issue by identifying different protocols that have been
suggested for use within the ITS industry, comparing their respective characteristics, and suggesting a
preferred set of protocols for future use.
6 Summary of needs and considerations
6.1 General
In order to evaluate specific technologies, the analysis described in this document began by identifying
the key stakeholder needs and considerations for data distribution. Recognizing that the needs of ITS
vary based on the specific information flow considered, an analysis of the Harmonized Architecture
Reference for Technical Standards (HARTS; see Reference [9]) and ARC-IT v8.3 (see Reference [6]) was
performed to identify the types of information flows throughout ITS and to determine the possible
characteristics driving the selection of data exchange technology.
6.2 Types of information flows
6.2.1 General
Information flows were characterized by general pattern of information exchange. Those types were
then assessed for whether they might be appropriate for satisfaction through a data distribution
system. Note that these categorizations attempt to cover 80 % or more of the information flows in ARC-
IT, but do not pretend to be an exhaustive and complete assessment.
6.2.2 Non-emergency information sharing
The first type of flow is information of a non-emergency nature, typically shared by central stations.
This information can be personalized and can be consumed by any other kind of station (personal,
vehicular etc.). Examples are traveller information (centre-field/personal/vehicle), centre-centre
traffic, environmental and maintenance information. These flows are probably well-suited for DDF.
6.2.3 Emergency information sharing
The second type of flow is information of an emergency nature, typically shared by central stations.
This is generally of two types:
— alerts to other stations, but particularly motorists to alert them of a widespread issue to which
they can react, for example, disaster information, severe weather, Amber or Silver alerts. These
exchanges are likely to be suitable for data distribution.
— alerts and exchanges with other central stations and supporting field stations to manage emergencies
and incidents. These exchanges generally require acknowledgement and can be dialogue-driven.
They are unlikely to be suitable for data distribution.
6.2.4 Control flows
A third type of flow is information provided from one station to another to direct a given action by the
receiver. Typically, this is a central-field flow with a central station controlling the field station. It can
or can not require acknowledgement, but it does require authorization and authentication. This type of
flow is generally not suitable for data distribution technologies, but it is possible if one is able to define
operations that would commonly be enacted identically for a group of field devices.
6.2.5 Interrogatives
Another type of flow is a dialogue where one party sends a request followed by the other party sending
a response. These flows are not suitable for data distribution.
6.2.6 Local exchanges
Local exchanges are information exchanges where the source and destination lie in close proximity.
These are typically local exchanges (usually using a short-range wireless medium) because there is
a performance requirement that dictates low latency. Data distribution functionality is only viable
for these scenarios if the DDF implementation technology meets that low latency and message size
requirements.
6.3 Characteristics
Information flows are characterized according to the following characteristics, many of which indicate
requirements on potentially suitable data distribution technologies:
— Confidentiality: Many information flows require encryption meeting the requirements of FIPS 140-
2, level 3. In some cases, it is necessary to maintain the confidentiality to the application entity
(i.e. meaning the data distribution technology is unable to decrypt the information). Additionally,
some cases require intrusion detection and mitigation functions that can inspect data distribution
messages.
— Integrity: Virtually all flows are likely to need integrity meeting the requirements of FIPS 140-
2, level 3, that ensures that received information is authenticated and authorized. In some cases,
intrusion detection and mitigation functions that can inspect data distribution messages are also
required.
— Availability: Some information flows require support for multiple communication technologies to
allow communications when the primary communication channels are unavailable.
— Latency: While most information flows within the architecture allow for up to 2 s of delay between
production of the data and its consumption; there are a relatively small number of flows where ultra-
low latency (100 ms) is required. Support for the ultra-low latency requirement can be handled by
other means if necessary.
— Throughput: For most flows, the data distribution technology often delivers at least 10 kb/s of
aggregate data subscriptions from a single ITS-SU source. In a few cases (5-10 % of information
exchanges), the data distribution technology needs to be able to deliver up to 500 kb/s of aggregate
data subscriptions from a single ITS-SU source.
— Pseudonymity: For most information flows, pseudonymity is not required (i.e. it is acceptable or
even desired for the receiver to be able to identify the source).
— Quality of service: The data distribution technology can provide at least a high level of assurance
that the data throughput expectations will be met under all conditions, and in some cases, it is
necessary to be able to guarantee this.
— Continuity: The data distribution technology can provide a level of assurance that the data exchange
capability can be maintained for the defined quality of service for a period of time.
— Non-repudiation: Most information flows require some form of non-repudiation; in many cases an
explicit acknowledgement is required. As noted above, flows requiring explicit acknowledgement
are probably not suitable for fulfilment by data distribution technology. For flows that do not require
such acknowledgement, the data distribution technology can support non-repudiation services such
that the sender of a message is not able to successfully claim that it did not send it.
6.4 Solution characteristics
6.4.1 General
Each solution is also characterized by several other factors as follows:
— Communication technology: The data distribution technology can be readily deployed using a range
of IP-based communication technologies.
— Misbehaviour reporting: The data distribution technology can report any misbehaving actors to the
appropriate systems to ensure that all systems can be properly prepared.
— Geofencing: In several environments it is useful to restrict publications to a specific geofenced area
and/or to restrict publication content to information related to a geofenced area.
— Flow filters: In many cases, it is desirable to allow a subscriber to request topic publications to be
filtered to better meet its needs based on frequency, accuracy and other parameters. For example,
while a source can provide once-per-second updates, a subscriber might only need and want once-
per-minute updates.
— Efficient repackaging: In some cases, it can be advantageous if the data distribution technology is
able to combine topics from multiple updates from one or more sources and package them into a
single publication to meet the needs of each user.
— Aggregation: In some cases, data is commonly used in aggregate; it would be useful if the data
distribution performed this aggregation rather than depending on the endpoint to do it.
6.4.2 Architectural topology
6.4.2.1 General
Part of the goal in sharing data among systems is to minimize the complexity associated with
maintaining connections between the various components. Each mechanism for information sharing is
based on an architectural topology that can generally be grouped into one of four styles as described in
the following subclauses.
6.4.2.2 Mesh topology
Within a mesh topology, every application entity is required to establish a connection with every other
application entity with which it wants to communicate. Once a connection is established, the two
applications can subscribe for information and provide publications as necessary. The mesh topology is
depicted in Figure 1.
NOTE 1 Connections are logical; all inter-station communications can exist on a single physical medium (e.g.
over the air). Each interface is designed for a specific need.
NOTE 2 The number of connections can be determined by the following formula:
c = c = a × (a – 1) / 2
a s
where
c application connections
a
c inter-station connections
s
a number of applications
Figure 1 — Mesh topology
The mesh topology has the advantage that an application providing data can ensure that the application
requesting the data is authorized to receive it. However, this also means that each application has to
spend resources managing connections and authorizing requests. This can be especially challenging
in a cooperative environment where requesters are not necessarily part of a pre-defined list and the
number of connections is not necessarily constrained.
While this type of network shares information, it does not meet the definition of a data distribution
technology because it does not include generalized layer 5-7 services to handle the data distribution. It
is mentioned in this document to contrast data distribution technologies against this more traditional
information exchange design.
6.4.2.3 Hub-and-spoke topology
In a hub-and-spoke topology every spoke application entity is required to establish a connection with
a hub application. The spoke can then subscribe for information or publish information to the hub. The
hub then has the responsibility of forwarding the publications to all applications that have subscribed
for the data. The hub-and-spoke topology is depicted in Figure 2.
NOTE 1 In theory, a Hub app can exist in any station.
NOTE 2 The Hub App can become a single point of failure.
NOTE 3 Each interface represents a superset of all needs.
NOTE 4 The number of connections can be determined by the following formula:
c = c = a
a s
where
c application connections
a
c inter-station connections
s
a number of applications
Figure 2 — Hub-and-spoke topology
The hub-and-spoke topology has the advantage that an application providing data can focus on
providing its core service while managing a single connection. However, it delegates the authorization
task to a remote hub application, which potentially raises issues in a C-ITS environment where the hub
application is a separate system (i.e. owned and/or operated by a different legal entity and therefore
increasing the number of legal entities with theoretical access to the data). The design also presents
challenges for a constantly changing network where devices are mobile and are constantly connecting
and disconnecting.
6.4.2.4 Databus service topology
Within a peer-to-peer data distribution topology, every device supports its own service that acts in a
manner like a hub. Each application within each device connects to its local hub service. The hub service
then connects to the hub services in other devices. Applications publish information to their local hub.
The hub service then takes care of distributing the information to other local entities and remote hub
services that are authorized. The peer-to-peer topology is depicted in Figure 3.
NOTE 1 Each interface represents a superset of some needs.
NOTE 2 The number of connections can be determined by the following formulae:
c = a
a
c = s × (s – 1) / 2
s
where
c application connections
a
c inter-station connections
s
s number of stations
a number of apps
Figure 3 — Peer-to-peer topology
The peer-to-peer topology has the advantage that an application providing data can focus on providing
its core service while managing a single connection; further, the authorization task is still largely
controlled by a local service within the same system. While a portion of the authorization task is the
responsibility of th
...