ISO/TS 21192:2019

TECHNICAL ISO/TS
SPECIFICATION 21192
First edition
2019-10
Electronic fee collection — Support for
traffic management
Perception du télépéage — Aide pour la gestion du trafic
Reference number
©
ISO 2019
© ISO 2019
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
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2019 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Abbreviated terms . 3
5 Architectural concepts and information exchanges . 3
5.1 General . 3
5.2 Role model . 3
5.3 Data flow model . 4
5.4 Information exchanges between TC and RTM . 5
6 General requirements for data exchange . 6
6.1 General . 6
6.2 Transaction: Set tariff scheme based on LOS . 7
6.2.1 Overview . 7
6.2.2 Message: LevelOfServiceAdu . 7
6.2.3 Message: TariffSchemeAdu . 8
6.3 Transaction: Levy toll . 9
6.3.1 Overview . 9
6.3.2 Message: RealTimeTollInformationAdu .10
6.3.3 Message: RoadUsageDataAdu .11
6.4 Transaction: Set tariff scheme based on travel demand model .12
6.4.1 Overview .12
6.4.2 Message: TariffSchemeRequestAdu.12
6.4.3 Message: TariffSchemeAdu .14
6.5 Privacy and quality of data .14
Annex A (normative) Data type specification .15
Annex B (normative) Implementation conformance statement proforma .16
Annex C (normative) Reference standards for data exchange .20
Annex D (informative) Smart route selection in Japan .23
Annex E (informative) Electronic Road Pricing (ERP) in Singapore .25
Annex F (informative) Managed lanes in the USA .27
Annex G (informative) Emission control using transit data in Japan .29
Annex H (informative) Data flow model of EFC support for traffic management .30
Annex I (informative) Example of data flows .31
Annex J (informative) Privacy and quality of data.32
Bibliography .35
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.
iv © ISO 2019 – All rights reserved

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.
Examples of EFC used for traffic management in other countries include:
— a new movement 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 Tokyo (see Annex D);
— Electronic Road Pricing in Singapore (see Annex E);
— Managed lanes [including services known as high occupancy vehicle (HOV) lanes and high occupancy
tolls (HOT)] on interstate freeways in the USA (see Annex F).
Traffic management is becoming more important in urban areas for reduction of congestion and also
for emissions control, and EFC schemes such as the smart route selection and managed lanes are some
of the key EFC applications used to support traffic management.
Figure 1 shows the scope of this document in the data flow model.
Figure 1 — Scope of this document in data flow model
TECHNICAL SPECIFICATION ISO/TS 21192:2019(E)
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.
The scope of this document defines:
— the architecture related to the scope;
— 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).
This document is a toolbox standard of application protocol data units (APDUs), which can be
used for the assigned purpose. 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.
Data types and associated coding related to the data elements described in Clause 6 are defined in
Annex A, using the abstract syntax notation one (ASN.1) according to ISO/IEC 8824-1. This document
allows the implementer to define suitable protocol procedures such as basic interaction, protocol
mechanism, and choice of transfer protocol.
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 12855:2015, Electronic fee collection — Information exchange between service provision and toll
charging
ISO 14827-1, Transport information and control systems — Data interfaces between centres for transport
information and control systems — Part 1: Message definition requirements
ISO 14827-2, Transport information and control systems — Data interfaces between centres for transport
information and control systems — Part 2: DATEX-ASN
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 14906, Electronic fee collection — Application interface definition for dedicated short-range
communication
ISO 17575-3, Electronic fee collection — Application interface definition for autonomous systems — Part 3:
Context data
ISO 22837:2009, Vehicle probe data for wide area communications
3 Terms and definitions
For the purposes of this document, the following terms and definitions 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
— IEC Electropedia: available at http: //www .electropedia .org/
3.1
electronic fee collection
EFC
fee collection by electronic means
[SOURCE: ISO 17573-1:2019, 3.5, modified — Note 1 to entry has been deleted.]
3.2
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
3.3
transport performance requirement
needed level of service (3.2) related to a set of operational goals and performance measures, e.g. speed,
travel time, freedom to manoeuvre, traffic interruptions, comfort or convenience
3.4
probe data
vehicle sensor information, formatted as probe data elements and/or probe messages, that is processed,
formatted, and transmitted to a land-based centre for processing to create a good understanding of the
driving environment
[SOURCE: ISO 22837:2009, 4.3]
3.5
road and traffic manager
RTM
manager responsible for a road transport network operation including monitoring of the level of
transport service
3.6
road usage data
travel data accumulated per road user, which is used to calculate the toll due
3.7
tariff scheme
set of rules to determine the fee due for a vehicle within a toll domain
[SOURCE: ISO 12855:2015, 3.12]
3.8
traffic flow information
traffic related data
EXAMPLE Average speed, traffic volume, level of congestion.
3.9
transit data
road usage data (3.6) necessary to calculate fees based on used road sections or passage of certain points
2 © ISO 2019 – All rights reserved

3.10
travel demand model
model for estimating travel demand and behaviour
3.11
dynamic toll
toll adjusted in real time in response to the actual traffic situation or other actual external conditions
3.12
fixed toll
toll applied according to a predefined tariff scheme
4 Abbreviated terms
EFC Electronic Fee Collection (ISO 17573-1)
OBE On-Board Equipment (ISO 14906)
LOS Level of Service
RSE Roadside Equipment (ISO 14906)
RTM Road and Traffic Manager
TC Toll Charger (ISO 17573-1)
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 the four main roles in the toll charging environment. Figure 2 shows the role model
expanded with one role to support for traffic management. Interactions between the management
role of road and traffic operation environment and the charging role of the toll are both management
and operational information flows, e.g. information flows regarding setting a tariff scheme, or daily
operation of the tolling.
The role related to the management of road and traffic operation environment is identified to manage a
road and traffic operation environment, i.e. defining and maintaining a set of rules that, taken together,
defines the policy of traffic management. It should be noted that the role related to traffic management
is not part of the EFC domain, but it belongs to the traffic management domain. Hence, this document
describes the interface between the two domains, see Figure 2.
The responsibilities of the role allocated to the traffic management domain include:
— definition of the LOS, including required transport performance which is appropriate for a regional
transportation network;
— provision of road usage data, including transit data to find the individual vehicle trace of the routes
and to calculate the tolls;
— operation of a travel demand model, including requesting a new tariff scheme to improve traffic
management.
Figure 2 — Role model in the toll charging environment to support traffic management
5.3 Data flow model
The TC needs to establish and maintain close contact with the relevant RTM in order to use a tariff
scheme for traffic management. In Figure 3, 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, in the centre of
the EFC architecture standard. The corresponding data flow of this document is shown in the double
line arrows between TC and RTM.
The roles and tasks of TC and RTM to support traffic management are as follows:
— RTM is a manager responsible for a 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 sets a tariff scheme, based on the transport performance requirements to optimize the toll
revenue and the LOS, and sends it to RTM. TC levies tolls and sends real time toll information to RTM.
— RTM monitors the LOS by taking vehicle probe data and traffic flow data. RTM provides real time
toll information for the users through the roadside information equipment, on-board equipment
(OBE), in-car navigation devices, or web pages. RTM sends 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 running 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.
Upon considering the roles, the data flow model is depicted as Figure 3 with RTM in the centre of the
basic EFC system architecture.
4 © ISO 2019 – All rights reserved

Figure 3 — Data flow model
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 be the flows with the time order of the exchanges, which are described as in Figure 4.
The first step is to define the LOS by RTM, then RTM shall send a performance request in terms of
definition of LOS to TC. TC shall set a tariff scheme to satisfy the LOS and send it to RTM.
The second step is to levy the toll. The real time toll information shall be sent to RTM upon levying the
toll to disseminate necessary tolling information to the road users, and RTM shall provide road usage
data which are collected from OBE as vehicle probe data. The probe data is the vehicle data that is used
to determine traffic conditions, time stamped unique identifiers, and to measure a vehicle’s progress
through the network, e.g. current position, speed, and heading and snapshots of recent events. This
includes route information, starts and stops, speed changes, and other information that can be used to
estimate traffic conditions. TC then calculates the tolls of individual vehicles. The vehicle probe data can
also be transmitted to TC, where TC may calculate the tolls without the road usage data sent from RTM.
The third step is to run the travel demand model and evaluate the tariff scheme. When the tariff scheme
is found to be not satisfactory with the LOS and a new tariff scheme is expected to meet LOS better by
running the model, RTM shall request TC to evaluate and set a new tariff scheme. (See Annex I in detail
including RSE and OBE.)
Figure 4 — Information exchanges between TC and RTM
6 General requirements for data exchange
6.1 General
Data to be exchanged for traffic management are 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 classified as the categories of congestion management, tolling, safety, monitoring environmental
impact, monitoring goods movement, and total management.
Table 1 — Exchanging data and purposes for evaluating the performance of traffic management
Traffic management purpose
Congestion Tolling Safety Monitoring Monitor- Total man-
Exchanging data
management environmental ing goods agement
impact movement
Traffic speed      
Traffic volume   
Traffic density   
Vehicle type/fleet compo-
    
sition
 
Traffic incident data
Toll data (revenues and
 
transactions)
The interface specifications of traffic centres and EFC centres are defined in ISO 14827 for traffic
management and ISO 12855 for EFC, respectively. The interface between RTM and TC shall be defined
in reference to the data exchange procedure in ISO 12855 and/or message exchange procedure in
ISO 14827. 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 description of data message in Clause 6 is ADU based on ISO 12855. Basic transaction flow including
AckADU is described in ISO 12855:2015, Clause 6 also.
The following basic data attributes are described in 6.2 to 6.4:
— LOS;
6 © ISO 2019 – All rights reserved

— tariff scheme;
— real time toll information;
— road usage data;
— new tariff scheme request.
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 5.
For each correct LevelOfServiceAdu the RTM sends, the TollCharger shall respond with one
corresponding TariffSchemeAdu. For each correct TariffSchemeAdu the TollCharger sends, the RTM
shall respond with one corresponding and positive AckAdu. Any incorrect ADU shall respond with a
negative AckAdu.
Figure 5 — 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, shall
be a factor to evaluate the transportation system (see Annex A, LevelOfService for syntax definition).
In the case of basic motorway sections, the LOSs should be based on density. Speed and flow are also
related to densities and the LOS.
The semantic definitions are in Table 2:
Table 2 — Semantic definitions for data type LevelOfServiceAdu
Data element Semantic definition Type Informative remarks
userInformation A human readable message UTF8String(SIZE(0.255))
from RTM about target traf-
ficStatus, TravelSpeed and
TravelTime.
trafficStatus A classification agreed bilat- TrafficStatus ::= NOTE 1  Data source is roadside
erally between implementors. UTF8String(SIZE(1)) vehicle detector, closed-circuit
television
EXAMPLE  Highway Capacity
Manual by TRB. TRB defines
six levels of service, designated
by the letters A through F, with
A being the highest LOS and F
the lowest.
minimumTra f f ic Minimum target vehicle speed MinimumTrafficSpeed ::= NOTE 2  Data source is road-
Speed on average on a certain road VehicleSpeed side vehicle detector
measured in km/h. VehicleSpeed ::= REAL
NOTE 3  velocity(m/sec.) is
used in ISO 22837
ma x i mu mTr avel a time interval in seconds. MaximumTravelTime::=REAL NOTE 4  Data source is probe
Time Maximum travel time on av- data, Automatic license Plate
erage on a certain route Recognition
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 (see Annex A, TariffScheme for syntax definition). The
tariff scheme shall be classified into three schemes: fixed toll, dynamic toll, and combination of both
fixed and dynamic. 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 semantic definitions are in Tables 3 to 6.
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 NOTE 1  Fixed toll is a toll
based on route, time of day, day
of week, vehicle class, user class
(e.g. number of passengers)
NOTE 2  Data source is TC
(Travel demand model), traffic
statistics
dynamicToll DynamicToll See Table 5 NOTE 3  Dynamic toll is a toll
based on status of traffic flow
NOTE 4  Data source is TC
(Travel demand model, toll
computation model), traffic
statistics
8 © ISO 2019 – All rights reserved

Table 3 (continued)
Data element Data type Semantic Definition Informative remarks
combinationOfToll CombinationOfToll See Table 6 NOTE 5  Combination of tolls
is a toll combined by both fixed
and dynamic
NOTE 6  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 INTEGER Indicator of tariff table with trip route of the vehicle. 1 is
active, 0 is disable.
timeOfDay Time See ISO 17575-3
dayOfWeek INTEGER See Table 6
vehicleClass VehicleClass See Table 6
userClass DriverCharacteristics See ISO 14906
Table 5 — Semantic definitions for data type DynamicToll
Data element Data type Semantic definition
statusOfTrafficFlow INTEGER Average vehicle speed [km/h] on certain roads
Table 6 — Semantic definitions for data type CombinationOfToll
Data element Data type Semantic definition
tollBasedOnRoute INTEGER Indicator of tariff table with trip route of the vehicle. 1 is
active, 0 is disable.
timeOfDay Time See ISO 17575-3
dayOfWeek INTEGER Day of the week
0=Sunday, 1=Monday, 2=Tuesday, 3=Wednesday, 4=Thurs-
day, 5=Friday, 6=Saturday
vehicleClass VehicleClass See ISO 14906
userClass Int1 See ISO 14906
statusOfTrafficFlow INTEGER Average vehicle speed [km/h] on certain roads
6.3 Transaction: Levy toll
6.3.1 Overview
RealTimeTollInformation is informed from TC to RTM for displaying real-time toll information text
on VMS, in-vehicle device, or OBE. RoadUsageData is informed from RTM to TC for analysing traffic
conditions and updating tariff schemes. The data exchanges are shown in Figure 6 and performed in
parallel.
For each correct RealTimeTollInformationAdu the TollCharger 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 6 — 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. But in 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 semantic definitions are in Tables 7 to 9.
Table 7 — Semantic definitions for data type RealTimeTollInformationAdu
Data element Data type Semantic definition Informative remarks
userInformation UTF8String(SIZE(0.255)) A human readable message from RTM
about Real-time Toll Information.
tollTable TollTable See Table 8 NOTE 1  Data source is TC
realTimeToll RealTimeToll See Table 9 NOTE 2  Data source is
RTM (status of traffic
flow), TC (toll by vehicle
class)
Table 8 — Semantic definitions for data type TollTable
Data element Data type Semantic Definition
tollByVehicleClass VehicleClass Vehicle class information in tariff
See ISO 14906
Route RoadNetwork Road route information in tariff
See ISO 17575-3
timeOfDay Time Time information of the day in tariff to identify the
time-zone (startTime and endTime) in tariff scheme.
startTimeOfDay GeneralizedTime (OPTIONAL) Start time of time-zone information of the day.
10 © ISO 2019 – All rights reserved

Table 8 (continued)
Data element Data type Semantic Definition
endTimeOfDay GeneralizedTime (OPTIONAL) End time of time-zone information of the day.
dayOfWeek INTEGER Day information of week in tariff to identify the day of
calendar in tariff scheme.
See Table 6.
startDayOfWeek GeneralizedTime (OPTIONAL) Start day of period in the week.
endDayOfWeek GeneralizedTime (OPTIONAL) End day of period in the week.
Table 9 — Semantic definitions for data type RealTimeToll
Data element Data type Semantic definition
statusOfTrafficFlow INTEGER Average vehicle speed [km/h] on certain roads
CertainRoutesOfRoadnetwork Roadnetwork Road link ID as route spot to distinguish certain
vehicle trip routes
tollByVehicleClass VehicleClass Vehicle class information in tariff
See ISO 14906
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 semantic definitions are in Tables 10 to 12.
Table 10 — 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 11 NOTE 1  Data source is
roadside vehicle detector,
closed-circuit television,
probe data
transitDataOfVehicles TransitDataOfVehicles See Table 12 NOTE 2  Data source is
probe data
Table 11 — Semantic definitions for data type TrafficFlowData
Data element Data type Semantic definition
vehicleClass VehicleClass See ISO 14906
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 12 — Semantic definitions for data type TransitDataOfVehicles
Data element Data type Semantic definition
TransitDataOfVehicles roadNetwork ::= See ISO 17575-3
RoadNetwork Road link ID as Route spot to distinguish certain vehi-
cle 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 7.
For each correct TariffSchemeRequestADU the RTM sends, the TollCharger shall respond with one
corresponding TariffSchemeAdu. For each correct TariffSchemeAdu the TollCharger sends, the RTM
shall respond with one corresponding and positive AckADU. Any incorrect ADU shall respond with a
negative AckAdu.
Figure 7 — 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 semantic definitions are in Tables 13 to 17.
12 © ISO 2019 – All rights reserved

Table 13 — Semantic definitions for data type TariffSchemeRequestAdu
Data element Data type Semantic Informative
definition remarks
userInformation UTF8String(SIZE(0.255)) A H u m a n
r e ad a b l e
m ess a g e
f rom RTM
about Traf-
fic Scheme
Request
unbalancedDensityOfTransportationNetwork UnbalancedDensityOfTransportationNetwork See NOTE 1  Data
Table 14 source is
roadside ve-
hicle detector,
probe data
unfavourableCongestion UnfavourableCongestion See NOTE 2  Data
Table 15 source is
roadside ve-
hicle detector,
probe data
unexpectedIncreaseOfIncidents UnexpectedIncreaseOfIncidents See NOTE 3  Data
Table 16 source is TC,
RTM, Police
agency,
unfavourableEnvironmentalImpact UnfavourableEnvironmentalImpact See NOTE 4  Data
Table 17 source is road-
side vehicle
detector, probe
data, Pollution
level sensor
Table 14 — 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 15 — Semantic definitions for data type UnfavourableCongestion
Data element Data type Semantic definition
trafficVolumes INTEGER Average traffic volume [vehicle/h] on cer-
tain roads
averageSpeed VehicleSpeed Average vehicle speed [km/h] on certain roads
trafficDensity INTEGER Traffic density [vehicle/km] on certain roads
speedChangeBetweenCertainSection VehicleSpeed Vehicle speed difference between start point
and end point of certain road sections
Table 16 — Semantic definitions for data type UnexpectedIncreaseOfIncidents
Data element Data type Semantic definition
numberOfIncidents INTEGER Number of incidents on certain roads per year
Table 17 — 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
Table 17 (continued)
Data element Data type Semantic definition
noise INTEGER Average dB on certain roads
Indicator of noise level
atmosphericEnvironment INTEGER ppm/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 mat-
ter (PM), ozone (O3), nitrogen dioxide (NOx) and
sulphur dioxide (SOx).
6.4.3 Message: TariffSchemeAdu
This message shall have the same requirements and definitions as the one defined in 6.2.3.
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 a vehicle’s progress through the network, e.g. current position, speed,
heading and snapshots of recent events, including route information, starts, and stops, speed changes,
and other information that can be used to estimate traffic conditions. The data could 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 could 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 license plate number, may be used
for identifying an individual. Privacy shall be taken into account 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 described in Annex J.
14 © ISO 2019 – All rights reserved

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.
Some data elements in this document are imported as ASN.1 format from ISO 22837 although they are
defined in ISO 22837 using the XML format. The semantics of these data elements shall comply with
ISO 22837.
The actual ASN.1 module is contained in the attached files “ISO21192(2019)
EfcSupportTrafficManagementV1.asn”, which can be directly imported in a compiler.
The syntax and semantics of the ASN.1 types in the attached file “ISO21192(2019)
EfcSupportTrafficManagementV2.asn” that are imported shall comply with ISO 14906 and ISO 17575-3.
NOTE 1 The above referenced files files (i.e. “ISO21192(2019)EfcSupportTrafficManagementv2.asn“) are
available for download via a hyperlink at www .itsstandards .eu/index .php/efc #EFCstandards and at http:
//standards .iso .org/iso/ts/21192/ed -1/en.
Table A.1 provides the SHA-256 cryptographic hash digests for the referenced files, offering a means to
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 EfcSupportTrafficManagementV1.asn d8807e714420b40fd788bdec8d345446f38b7acdb48
5745df1f843b7e7d92e56
NOTE 2 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
In order 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 also, 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 may be:
16 © ISO 2019 – All rights reserved

m mandatory support is required;
o optional support is permitted for conformance to the standard. If implemented it shall conform
to the specifications and restrictions contained in the standard. These restrictions may affect the
optionality of other items;
c the item is conditional (support of the capability is subject to a predicate);
- the item is not applicable;
i the item is outside the scope of this ICS.
In the ICS tables, every leading item marked “m” shall be supported by the IUT. Sub-items marked “m”
shall be supported if the corresponding leading item is supported by the IUT.
B.3.3 Support column
This column shall be completed by the supplier or implementer to indicate the level of implementation
of each item. The proforma has been designe
...