ISO/TS 21192:2024

Technical
Specification
ISO/TS 21192
Second edition
Electronic fee collection — Support
2024-11
for traffic management
Perception de télépéage — Aide pour la gestion du trafic
Reference number
© ISO 2024
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
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 Architectural concepts and information exchanges . 2
5.1 General .2
5.2 Role model .2
5.3 Data flow model .3
5.4 Information exchanges between TC and RTM .4
6 General requirements for data exchange . . 5
6.1 General .5
6.2 Transaction: Set tariff scheme based on LOS .6
6.2.1 Overview .6
6.2.2 Message: LevelOfServiceAdu .7
6.2.3 Message: TariffSchemeAdu .7
6.3 Transaction: Levy toll .9
6.3.1 Overview .9
6.3.2 Message: RealTimeTollInformationAdu.9
6.3.3 Message: RoadUsageDataAdu .10
6.4 Transaction: Set tariff scheme based on travel demand model .11
6.4.1 Overview .11
6.4.2 Message: TariffSchemeRequestAdu .11
6.4.3 Message: TariffSchemeAdu . 13
6.5 Privacy and quality of data . 13
Annex A (normative) Data type specification. 14
Annex B (normative) Implementation conformance statement proforma .15
Annex C (normative) Reference standards for data exchange . 19
Annex D (informative) Smart route selection in Japan .21
Annex E (informative) Electronic Road Pricing (ERP) in Singapore .23
Annex F (informative) Managed lanes in the USA .26
Annex G (informative) Emission control using transit data in Japan .28
Annex H (informative) Data flow model of EFC support for traffic management .29
Annex I (informative) Example of data flows .30
Annex J (informative) Privacy and quality of data .31
Bibliography .34

iii
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 document 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).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
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.
This second edition cancels and replaces the first edition of ISO/TS 21192:2019, which has been technically
revised.
The main changes are as follows:
— Clause 3 has been updated and ISO/TS 17573-2 has been made the primary source for terms and
definitions;
— data definitions have been updated, including making reference to ISO 17573-3 as the primary source.
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.

iv
Introduction
Electronic fee collection (EFC) systems have been introduced in many countries where collected revenue is
mostly used for funding the construction or maintenance of roads. EFC is also used for traffic management
to reduce congestion in urban areas, such as London and Stockholm, since tolling is closely related to travel
demand elasticity.
Traffic management is becoming more important as a tool used for reduction of congestion and emissions
control in urban areas. EFC schemes such as the smart route selection and managed lanes are some of the
key EFC applications used to support traffic management.
This document contains the following annexes:
— Data type specifications are given in Annex A;
— The implementation conformance statement proforma, to be completed by suppliers that claim their
implementations are in conformity with this document, is provided in Annex B;
— Annex C specifies the procedures for data exchange, in accordance with the referenced standards;
— Examples of EFC used for traffic management in other countries:
— Annex D presents a new method for traffic management, called smart route selection, in which EFC
will be used for selecting a route in the Tokyo metropolitan area to divert traffic out of central parts
of the metropolitan area;
— Annex E presents the Electronic Road Pricing scheme in Singapore;
— Annex F presents managed lanes including services known as high occupancy vehicle (HOV) lanes
and high occupancy tolls (HOT) on interstate freeways in the USA;
— Annex G presents the dynamic pricing scheme to improve the environment in Japan;
— Annex H shows the data flow model of EFC support for traffic management;
— Annex I provides examples of data flows between components of EFC and road traffic management
systems;
— Annex J explains principles and considerations of privacy and quality of data.

v
Technical Specification ISO/TS 21192:2024(en)
Electronic fee collection — Support for traffic management
1 Scope
This document identifies the architecture of a toll system environment in which a toll charger (TC) can act
to support traffic management with the use of a tariff scheme.
This document defines:
— the architecture relevant to the scope of this document;
— a standard framework and data flow model;
— an exchange of information between a TC and a road and traffic manager (RTM), e.g.:
— level of service (LOS);
— tariff scheme;
— data which is needed to support traffic management (vehicle probe and traffic flow data).
The detailed definitions of mandatory and optional elements in real implementation are outside the scope of
this document. This document does not define communication stacks or timings.
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.
1)
ISO/FDIS 12855 , Electronic fee collection — Information exchange between service provision and toll charging
ISO 14827-2, Intelligent transport systems — Data interfaces between centres for transport information and
control systems — Part 2: AP-DATEX
ISO 14827-3, Transport information and control systems — Data interfaces between centres for transport
information and control systems — Part 3: Data interfaces between centres for intelligent transport sytems
(ITS) using XML (Profile A)
ISO 22837:2009, Vehicle probe data for wide area communications
ISO/TS 17573-2, Electronic fee collection — System architecture for vehicle related tolling — Part 2: Vocabulary
ISO 17573-3, Electronic fee collection — System architecture for vehicle-related tolling — Part 3: Data dictionary
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/TS 17573-2 and the following
term and definition apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
1) Under revision. Stage at the date of publication: ISO/FDIS 12855:2024.

— IEC Electropedia: available at https:// www .electropedia .org/
3.1
level of service
LOS
rating of the quality of transportation facilities and services from the user perspective, with reference to
speed, convenience and comfort, to evaluate problems and potential solutions
4 Abbreviated terms
EFC Electronic Fee Collection
OBE On-Board Equipment
LOS Level of Service
RSE Roadside Equipment
RTM Road and Traffic Manager
TC Toll Charger
5 Architectural concepts and information exchanges
5.1 General
This clause specifies the role model of EFC support for traffic management in terms of its roles and
relationship with EFC and traffic management related roles. The information exchanges needed by a toll
charger (TC) and an RTM to perform their roles are described in this clause.
5.2 Role model
ISO 17573-1 defines four main roles in the electronic fee collection domain. Figure 1 shows the role model
expanded with one role with support for traffic management. Interactions between the management
role of road and traffic operation environment and the charging role of the tolling environment are both
management and operational information flows, e.g. information flows regarding setting a tariff scheme, or
daily operation of the tolling.
The main purpose of the role Management of road and traffic operation environment is to manage road and
traffic operation environment, by defining and maintaining the set of rules. that define the policy of traffic
management. It should be noted that the role for traffic management is part of the traffic management
domain. Hence, this document describes the interface between the two domains, see Figure 1.
The responsibilities of the role allocated to the traffic management domain include:
— definition of the level of service (LOS), including required transport performance which is appropriate
for a regional transportation network;
— provision of road usage data, including transit data to identify vehicle movements and usage of the road
infrastructure and to calculate the relevant tolls;
— operation of travel demand model, including definition of a new tariff scheme to improve traffic
management.
Figure 1 — Role model in EFC domain to support traffic management domain
5.3 Data flow model
The TC needs to establish and maintain close contact with the relevant RTM to use a tariff scheme for traffic
management. In Figure 2, the data flow model for EFC support for traffic management is shown with RTM,
which plays an important role for traffic management in a region. The corresponding data flow of this
document is shown in the double line arrows between TC and RTM.
The tasks and responsibilities of TC and RTM to support traffic management are as follows.
— RTM is responsible for road transport network operation, including monitoring of the level of transport
service. RTM defines the LOS and sets transport performance requirements, based on the regional
transport policy and traffic status, and sends them to TC.
— TC operates a tariff scheme, based on the transport performance requirements to optimize the toll
revenue and the LOS, and provides it to RTM. TC calculates and charges the toll and provides real time
toll-relevant information to RTM.
— RTM monitors the LOS by using vehicle probe and traffic flow data. RTM provides real time toll-relevant
information to the users through the roadside information equipment, on-board equipment (OBE), in-car
navigation devices, or web pages. RTM provides the road usage data required for tolling upon request
from TC.
— RTM runs the travel demand model, to pursue better traffic management, and requests a new tariff
scheme with the current data from the TC.
— TC evaluates and sets a new tariff scheme and sends it back to RTM.
— RTM activates the new tariff scheme, runs the travel demand model, and requests a new tariff scheme if
necessary.
Key
scope of this document
Figure 2 — Data flow model
A detailed presentation of the data flow model for EFC support to traffic management is provided in Annex H.
5.4 Information exchanges between TC and RTM
The information exchanges between TC and RTM, to support the traffic management with the use of EFC
scheme, shall follow the order of the exchanges described in Figure 3.
The first step is to define the LOS by RTM. RTM shall send a performance request based on definition of the
LOS to TC. TC shall incorporate the LOS requirements in tariff scheme and provide it to RTM.
The second step is to levy the toll. The real time toll information shall be provided to RTM upon levying
the toll to disseminate necessary tolling information to the road users. RTM shall provide road usage data
collected from OBE as vehicle probe data to TC. The probe data is the vehicle data (with time-stamped in the
scheme unique identifiers) that is used to determine traffic conditions, and to measure the vehicle’s progress
through the network. This includes route information, starts and stops, current position and speed and other
information (e.g. heading, speed changes and snapshots of recent events) that can be used to estimate traffic
conditions. TC calculates the tolls of individual vehicles. The vehicle probe data can also be transmitted to
TC, where TC may calculate the tolls even when the road usage data cannot be collected.
The third step is to run the travel demand model and evaluate the tariff scheme. When the tariff scheme is
found to be unsatisfactory for the LOS, new tariff scheme is defined to meet LOS requirements by running
the demand model. RTM shall request TC to evaluate and set a new tariff scheme. (See informative Annex I
for more detailed information on data flows between RSE and OBE).

Figure 3 — Information exchanges between TC and RTM
6 General requirements for data exchange
6.1 General
Data to be exchanged for traffic management is categorized as traffic flow related, traffic incident-related
and tolling-related data. The purposes of the data are shown in Table 1, together with the terms which
are required to evaluate the performance of traffic management. The performance measures, which are
required to set and evaluate the tariff scheme for supporting traffic management, should be categorized into
congestion management, tolling, safety, monitoring environmental impact, monitoring goods movement,
and total management.
Table 1 — Exchanging data for traffic management purposes
Traffic management purpose
Congestion Tolling Safety Monitoring Monitoring Total
Exchanging data
management environmental goods management
impact movement
Traffic speed      
Traffic volume   
 
Traffic density
Vehicle type/
    
fleet composition
Traffic incident data  
Toll data (revenues
 
and transactions)
The interface specifications of traffic management domain and EFC domain shall refer to ISO 14827-2 and
ISO 14827-3 for traffic management and ISO 12855 for EFC, respectively. The interface between RTM and TC
is specified by referring to data exchange procedure in ISO 12855, ISO 14827-2 and ISO 14827-3.
The specifications of the ASN.1 data types, relating to the data elements described in Clause 6, shall be in
accordance with Annex A.
To facilitate reading, the following conventions are adopted in this document:
a) the ASN.1 data elements are written with a lower case first letter using Courier New font;
b) the corresponding ASN.1 data types are written with an upper case first letter using Courier New font.
This document allows the implementer to define suitable protocol procedures such as basic interaction,
protocol mechanism, and choice of transfer protocol. The implementation conformance statement proforma

provided in Annex B shall be used by a supplier claiming that its implementation is in conformity with this
document.
The reference interface specification based on these standards is shown in Annex C. This document defines
the data attributes as application data units (ADUs) for EFC supporting traffic management. The data
exchanges shall be in accordance with Annex C.
The description of data message in Clause 6 is ADU based on ISO 12855. Basic transaction flow including
AckADU is described in ISO 12855:—, Clause 6.
The following basic data attributes are described in 6.2 to 6.4:
— LOS;
— tariff scheme;
— real time toll information;
— road usage data;
— new tariff scheme request.
The following annexes provide examples of EFC supported traffic management.
— Annex D presents an example of a smart route selection scheme;
— Annex E presents an example of an electronic road pricing scheme;
— Annex F presents managed lanes in the USA;
— Annex G presents an example of an emission control scheme, based on the usage of transit data;
— Annex I provides examples of data flows between components of EFC and road traffic management
systems.
Typical data flows using messages described in 6.2 to 6.4 between RTM, RSE, OBE and TC are shown in
Annex H.
6.2 Transaction: Set tariff scheme based on LOS
6.2.1 Overview
LevelOfService and TariffScheme are exchanged between the RTM and TC for setting and revising tariff
scheme based on LOS as shown in Figure 4.
For each correct LevelOfServiceAdu the RTM sends, the TC shall respond with one corresponding
TariffSchemeAdu. For each correct TariffSchemeAdu the TC sends, the RTM shall respond with one
corresponding and positive AckAdu. Any incorrect ADU shall respond with a negative AckAdu.

Figure 4 — Sequence diagram of LevelOfService and TariffScheme
6.2.2 Message: LevelOfServiceAdu
LOS, the rating of the quality of transportation facilities and services from the user perspective, plays a
major role in evaluation of the transportation system (see Annex A, LevelOfService for syntax definition).
In case of basic motorway sections, the LOS should be based on traffic density. Speed and flow are also
related to traffic densities and the LOS.
The semantics are defined in Table 2.
Table 2 — Semantic definitions for data type LevelOfServiceAdu
Data element Type Semantic definition Informative remarks
userInformation UTF8String(SIZE(1.255))
A human readable message from
RTM about target trafficStatus,
TravelSpeed and TravelTime.
trafficStatus TrafficStatus ::=
A classification agreed bilaterally Data source is roadside vehicle de-
UTF8String(SIZE(1))
between implementors. tector, closed-circuit television.
EXAMPLE Highway Capacity Man-
[13]
ual defines six levels of service,
designated by the letters A through
F, with A being the highest LOS and
F the lowest.
minimumTrafficSpeed MinimumTrafficSpeed ::=
Minimum target vehicle speed on Data source is roadside vehicle
VehicleSpeed VehicleSpeed
average on a certain road meas- detector.
::= REAL
ured in km/h.
velocity(m/s) is used in ISO 22837.
maximumTravelTime MaximumTravelTime::=REAL
A time interval in seconds. Data source is probe data, Automat-
Maximum travel time on average ic licence Plate Recognition.
on a certain route
6.2.3 Message: TariffSchemeAdu
A tariff scheme, i.e. the set of rules to determine the toll, shall be determined to optimize the toll revenue and
the LOS for suitable traffic management (in accordance with Annex A, TariffScheme for syntax definition).
The tariff scheme shall be classified into three schemes:
— fixed toll;
— dynamic toll;
— combination type of both fixed toll and dynamic toll;

The fixed toll scheme, applied according to a predefined tariff scheme, is usually expressed as the form
of the tables with the data of the toll based on the route, time of day, day of week, vehicle class, and user
class. The dynamic toll scheme is expressed as the toll adjusted in real time in response to the actual traffic
situation or other external actual conditions. The dynamic toll is determined by considering both the basic
toll and the traffic management. In case of the combination type of both fixed and dynamic tolls, the toll is
determined with the statistics of the traffic flow of the week or seasonal changes.
The semantics are defined in Tables 3 to 7.
Table 3 — Semantic definitions for data type TariffSchemeAdu
Data element Data type Semantic Definition Informative remarks
userInformation UTF8String(SIZE(0.255))
A human readable message
from RTM about tariff scheme.
fixedToll FixedToll
See Table 4 Fixed toll is a toll based on route, time of day, day of week,
vehicle class, user class (e.g. number of passengers)
Data source is TC (Travel demand model), traffic statistics.
dynamicToll DynamicToll See Table 6 Dynamic toll is a toll based on status of traffic flow.
Data source is TC (Travel demand model, toll computation
model), traffic statistics.
combinationOfToll CombinationOfToll
See Table 7 Combination of tolls is a toll combined by both fixed and
dynamic.
Data source is TC (Travel demand model, toll computation
model), traffic statistics.
Table 4 — Semantic definitions for data type FixedToll
Data element Data type Semantic definition
tollBasedOnRoute TollBasedOnRoute
Indicator of tariff table with trip route of the vehicle.
See Table 5.
timeOfDay TimeCompact
Imported from ISO 17573-3
dayOfWeek Weekday
Imported from ISO 17573-3
vehicleClass VehicleClass
Imported from ISO 17573-3
userClass DriverCharacteristics
Imported from ISO 17573-3
Table 5 — Values and semantics for data type TollBasedOnRoute
Name Semantics Value
Disabled
The route-based tariff table is disabled. 0
Active
The route-based tariff table is active. 1

Values reserved for future CEN and ISO use 2.127

Values reserved for private use 128.255
Table 6 — Semantic definitions for data type DynamicToll
Data element Data type Semantic definition
statusOfTrafficFlow StatusOfTrafficFlow ::=
Average vehicle speed [km/h] on certain roads
INTEGER (0.511)
Table 7 — Semantic definitions for data type CombinationOfToll
Data element Data type Semantic definition
tollBasedOnRoute TollBasedOnRoute
Indicator of tariff table with trip route of the vehicle.
1 is active, 0 is disable.
timeOfDay TimeCompact
Imported from ISO 17573-3
dayOfWeek Weekday
Imported from ISO 17573-3
vehicleClass VehicleClass
userClass Int1Unsigned
Imported from ISO 17573-3
statusOfTrafficFlow StatusOfTrafficFlow ::=
Average vehicle speed [km/h] on certain roads
INTEGER (0.511)
6.3 Transaction: Levy toll
6.3.1 Overview
RealTimeTollInformation is provided by TC to RTM for displaying real-time toll information text on VMS,
in-vehicle device, or OBE. RoadUsageData is provided by RTM to TC for analysing traffic conditions and
updating tariff schemes. These data exchanges are shown in Figure 5 and performed in parallel.
For each correct RealTimeTollInformationAdu the TC sends, the RTM shall respond with one corresponding
AckAdu. For each correct RoadUsageDataAdu the RTM sends, the TC shall respond with one corresponding and
positive AckAdu. Any incorrect ADU shall be replied to with a negative AckAdu.
Figure 5 — Sequence diagram of RealTimeTollImformation and RoadUsageData
6.3.2 Message: RealTimeTollInformationAdu
In case of the fixed toll scheme, RTM and the users only need the toll table to find the toll at the present time.
However, in the case of the dynamic toll and the combination toll types, real time toll information, which is
displayed on variable message signs, in-car navigation devices, or web pages for the users, shall be sent to
RTM (see Annex A, RealTimeTollInformation for syntax definition).
The semantics is defined in Tables 8 to 10.

Table 8 — Semantic definitions for data type RealTimeTollInformationAdu
Data element Data type Semantic definition Informative remarks
userInformation UTF8String(SIZE(0.255))
A human readable mes-
sage from RTM about
Real-time Toll Infor-
mation.
tollTable TollTable
See Table 9 Data source is TC.
realTimeToll RealTimeToll
See Table 10 Data source is RTM (status
of traffic flow), TC (toll by
vehicle class).
Table 9 — Semantic definitions for data type TollTable
Data element Data type Semantic Definition
tollByVehicleClass VehicleClass
Vehicle class information
Route Layout
Road route information
Imported from ISO 12855
timeOfDay Time
Time information of the day to iden-
tify the time-zone (startTime and
endTime).
startTimeOfDay GeneralizedTime (OPTIONAL)
Start time of time-zone information of
the day.
endTimeOfDay GeneralizedTime (OPTIONAL)
End time of time-zone information of
the day.
dayOfWeek Weekday
Day information of week to identify
the day of calendar.
Imported from ISO 17573-3
startDayOfWeek GeneralizedTime (OPTIONAL)
Start day of period in the week.
endDayOfWeek GeneralizedTime (OPTIONAL)
End day of period in the week.
Table 10 — Semantic definitions for data type RealTimeToll
Data element Data type Semantic definition
statusOfTrafficFlow StatusOfTrafficFlow ::=
Average vehicle speed [km/h] on
INTEGER (0.511)
certain roads
CertainRoutesOfRoadnetwork Layout
Road link ID as route spot to distin-
guish certain vehicle trip routes
tollByVehicleClass VehicleClass
Vehicle class information
6.3.3 Message: RoadUsageDataAdu
Road usage data, necessary to calculate the toll, is required for TC with two different types of data. One shall
be traffic flow data which is used for accumulating a toll amount by hour, day, week, and year, and the other
one shall be transit data which is used to determine the toll of individual vehicles where the toll scheme is
based on the vehicle’s driven routes, sections, or areas (see Annex A, RoadUsageData for syntax definition).
The VehicleSpeed shall be in accordance with ISO 22837.
The semantics is defined in Tables 11 to 13.

Table 11 — Semantic definitions for data type RoadUsageDataAdu
Data element Data type Semantic definition Informative remarks
userInformation UTF8String(SIZE(0.255)) A human readable message from RTM
about road usage data.
trafficFlowData TrafficFlowData
See Table 12 Data source is roadside vehicle
detector, closed-circuit televi-
sion, probe data.
transitDataOfVehicles TransitDataOfVehicles See Table 13 Data source is probe data.
Table 12 — Semantic definitions for data type TrafficFlowData
Data element Data type Semantic definition
vehicleClass VehicleClass
Vehicle class of certain vehicle
trafficVolume INTEGER
Average traffic volume [vehicle/h] on certain roads
averageSpeed VehicleSpeed
Average vehicle speed [km/h] on certain roads
trafficDensity INTEGER
Traffic density [vehicle/km] on certain roads
Table 13 — Semantic definitions for data type TransitDataOfVehicles
Data element Data type Semantic definition
TransitDataOfVehicles tripRoute ::= Layout
Road link ID as route spot to distinguish certain
vehicle trip routes
6.4 Transaction: Set tariff scheme based on travel demand model
6.4.1 Overview
TariffSchemeRequest and TariffScheme are exchanged between the RTM and TC for revising tariff scheme
based on recent traffic conditions as shown in Figure 6.
For each correct TariffSchemeRequestADU the RTM sends, the TC shall respond with one corresponding
TariffSchemeAdu. For each correct TariffSchemeAdu the TC sends, the RTM shall respond with one
corresponding and positive AckADU. Any incorrect ADU shall respond with a negative AckAdu.
Figure 6 — Sequence diagram of TariffSchemeRequest and TariffScheme
6.4.2 Message: TariffSchemeRequestAdu
It is important for RTMs to pursue optimal traffic management based on various factors since it often
occurs that the traffic patterns and the types and environmental performances of vehicles change as

economic and social conditions vary (such as the ratio of the electric vehicles). RTM should use factors of
unbalanced density of transportation network, unfavourable congestion, unexpected increase of incidents,
and unfavourable environmental impact upon requesting a new tariff scheme (see Annex A, TariffScheme
for syntax definition).
The semantics is defined in Tables 14 to 18.
Table 14 — Semantic definitions for data type TariffSchemeRequestAdu
Data element Data type Semantic definition Informative remarks
userInformation UTF8String(SIZE(0.255)) A human readable message from RTM
about Traffic Scheme Request
unbalancedDensityOfTransporta UnbalancedDensityOfTransporta
See Table 15 Data source is roadside vehicle detec-
tionNetwork tionNetwork
tor, probe data.
unfavourableCongestion UnfavourableCongestion
See Table 16 Data source is roadside vehicle detec-
tor, probe data.
unexpectedIncreaseOfIncidents UnexpectedIncreaseOfIncidents
See Table 17 Data source is TC, RTM, Police agency.
unfavourableEnvironmentalImpact UnfavourableEnvironmentalImpact
See Table 18 Data source is roadside vehicle detec-
tor, probe data, Pollution level sensor.
Table 15 — Semantic definitions for data type UnbalanceddensityOfTransportationNetwork
Data element Data type Semantic definition
trafficVolumes INTEGER
Average traffic volume [vehicle/h] on certain roads
averageSpeed VehicleSpeed
Average vehicle speed [km/h] on certain roads
trafficDensity INTEGER
Traffic density [vehicle/km] on certain roads
Table 16 — Semantic definitions for data type UnfavourableCongestion
Data element Data type Semantic definition
trafficVolumes INTEGER
Average traffic volume [vehicle/h]
on certain roads
averageSpeed VehicleSpeed
Average vehicle speed [km/h] on
certain roads
trafficDensity INTEGER
Traffic density [vehicle/km] on cer-
tain roads
speedChangeBetweenCertainSection VehicleSpeed
Vehicle speed difference between
start point and end point of certain
road sections
Table 17 — Semantic definitions for data type UnexpectedIncreaseOfIncidents
Data element Data type Semantic definition
numberOfIncidents INTEGER
Number of incidents on certain roads per year

Table 18 — Semantic definitions for data type UnfavourableEnvironmentalImpact
Data element Data type Semantic definition
trafficVolumes INTEGER
Average traffic volume [vehicle/h]
on certain roads
averageSpeed VehicleSpeed
Average vehicle speed [km/h] on
certain roads
Noise INTEGER
Average dB on certain roads
Indicator of noise level
atmosphericEnvironment INTEGER
ppm (parts per million)/day on
certain roads
Indicator of PM, nOx, sOx in air
airPolluters UTF8String(SIZE(0.255))
A human readable message from
RTM about measured air pollutants
such as particulate matter (PM),
ozone (O ), nitrogen dioxide (nOx)
and sulphur dioxide (sOx).
6.4.3 Message: TariffSchemeAdu
The response to the request of new tariff scheme is replacement information for current tariff scheme.
Therefore, message of TariffSchemeAdu as new tariff scheme shall be the same message and semantic
definitions with TariffSchemeAdu, defined in 6.2.3, response to the request of LevelOfServiceAdu.
6.5 Privacy and quality of data
The information flow of vehicle probe data is a crucial flow of information in traffic management. The
collected data is used to measure vehicle’s progress through the network, e.g. current position, speed,
heading and snapshots of recent events, that can be used to estimate traffic conditions. This data can be
used to identify an individual and is then by definition personal information (PI) that has to be managed in a
way that protects the privacy of the individual that can be identified.
Another crucial flow of information is the traffic flow data collected and handled by the roadside ITS sub-
system. Data that is unique for each vehicle, e.g. OBE and vehicle licence plate number, may be used for
identifying an individual. Privacy should be considered in the design and operation of Traffic Management
supported by EFC.
The ITS service, Traffic Management supported by EFC, is based on information on traffic flow conditions.
The information is used for optimising the use of the road network. This implies monitoring the traffic
flow conditions and controlling the traffic flows by means of pricing the road use. The user acceptance of
the service is closely related to the quality and efficiency of the ITS service, and quality and efficiency is
related to the quality of the traffic flow information that is collected. This implies that the complete value
chain of information flow should ensure the data quality parameters availability, integrity, authenticity,
confidentiality and accountability.
The details of privacy and quality of data are discussed in Annex J.

Annex A
(normative)
Data type specification
The EFC data types and associated coding related to the EFC data elements, described in Clause 6, are defined
using the Abstract Syntax Notation One (ASN.1) technique according to ISO/IEC 8824-1. The unaligned
packed encoding rules according to ISO/IEC 8825-2 are applied.
The ASN.1 module is identified by the object identifier {iso(1) standard(0) 21192 version2(2)
minorVersion1(1)}.
The actual ASN.1 module is contained in the attached file “ISO21192 EfcSupportTrafficManagement V2.1”
which can be directly imported in an ASN.1 compiler. This file is available for download via https:// standards
.iso .org/ iso/ ts/ 21192.
The syntax and semantics of the data types in the ASN.1 types in the above-mentioned file that is imported
shall comply with ISO 17573-3, respectively.
Table A.1 provides the SHA-256 cryptographic hash digests for the referenced files, offering a means to
[7]
verify the integrity of the referenced files. The SHA-256 algorithm is specified in NIST 180-4.
Table A.1 — SHA-256 cryptographic hash digests
File Name SHA-256 cryptographic hash digest
ISO21192 EfcSupportTrafficManagement V2.1 d18071c1b700ef29988d7090d2b50d64d2b8ac-
4412413f0857ab7f27178b40fc
It is important to be aware that pasting the text of the file into one of the hash digest computation pages
available on the web can result in a non-matching hash digest due to changes in the underlying coding.

Annex B
(normative)
Implementation conformance statement proforma
B.1 General
To evaluate the conformance of a particular implementation, it is necessary to have a statement of those
capabilities and options that have been implemented. This is called an implementation conformance
statement (ICS).
This annex presents the pro forma to be used for the attributes defined in Annex A, with ICS templates that
are to be filled in by equipment suppliers.
B.2 Purpose and structure
The purpose of this ICS is to provide a mechanism whereby a supplier of an implementation of the attribute in
media defined in this document can provide information about the implementation in a standardised manner.
The ICS is subdivided as follows:
— identification of the implementation;
— identification of the protocol;
— global statement of conformance;
— ICS tables.
B.3 Instruction for completing ICS
B.3.1 Definition of support
A capability is said to be supported if the implementation under test (IUT) can:
— generate the corresponding operation parameters (either automatically or because the end user requires
that capability explicitly),
— interpret, handle and, when required, make available to the end user the corresponding error or result.
A protocol element is said to be supported for a sending implementation if it is able to generate it under
certain circumstances (either automatically or because the end user requires relevant services explicitly).
A protocol element is said to be supported for a receiving implementation if it is correctly interpreted and
handled and, when appropriate, made available to the end user.
B.3.2 Status column
This column indicates the level of support required for conformance. Values in this column are:
m mandatory support is required;

o optional support is permitted for conformance to this document. If implemented, it shall conform to the
specifications and restrictions contained in the standard. These restrictions may affect the optionality
o
...