ISO 12813:2024
(Main)Electronic fee collection — Compliance check communication for autonomous systems
Electronic fee collection — Compliance check communication for autonomous systems
This document specifies requirements for short-range communication for the purposes of compliance checking in autonomous electronic fee collecting systems. Compliance checking communication (CCC) takes place between a road vehicle's on-board equipment (OBE) and an interrogator [fixed and mobile roadside equipment (RSE) or hand-held unit] and serves to establish whether the data that are delivered by the OBE correctly reflect the road usage of the corresponding vehicle according to the rules of the pertinent toll regime. The operator of the compliance checking interrogator is assumed to be part of the toll charging role as defined in ISO 17573-1. The CCC permits identification of the OBE, vehicle and contract, and verification of whether the driver has fulfilled their obligations and the checking status and performance of the OBE. The CCC reads, but does not write, OBE data. This document is applicable to OBE in an autonomous mode of operation. It is not applicable to compliance checking in dedicated short-range communication (DSRC)-based charging systems. It specifies data syntax and semantics, but not a communication sequence. All the attributes specified herein are required in any OBE claimed to be compliant with this document, even if some values are set to “not specified” in cases where a certain functionality is not present in an OBE. The interrogator is free to choose which attributes are read in the data retrieval phase, as well as the sequence in which they are read. In order to achieve compatibility with existing systems, the communication makes use of the attributes specified in ISO 17573-3 wherever useful. The CCC is suitable for a range of short-range communication media. Specific definitions are given for the CEN-DSRC as specified in EN 15509, as well as for the use of ISO CALM IR, the Italian DSRC as specified in ETSI ES 200 674-1, ARIB DSRC, and WAVE DSRC as alternatives to the CEN-DSRC. The attributes and functions specified are for compliance checking by means of the DSRC communication services provided by DSRC application layer, with the CCC attributes and functions made available to the CCC applications at the RSE and OBE. The attributes and functions are specified on the level of application data units (ADUs). The definition of the CCC includes: — the application interface between OBE and RSE (as depicted in Figure 2); — use of the generic DSRC application layer as specified in ISO 15628 and EN 12834; — CCC data type specifications given in Annex A; — a protocol implementation conformance statement (PICS) proforma is given in Annex B; — use of the CEN-DSRC stack as specified in EN 15509, or other equivalent DSRC stacks as described in Annex C, Annex D, Annex E and Annex F; — security services for mutual authentication of the communication partners and for signing of data (see Annex H); In addition, an example CCC transaction is presented in Annex G and Annex I highlights how to use this document for the European Electronic Toll Service (EETS). Test specifications are not within the scope of this document.
Perception de télépéage — Communication de contrôle de conformité pour systèmes autonomes
Le présent document spécifie les exigences relatives aux communications à courte portée aux fins de contrôle de conformité dans les systèmes de perception électronique de télépéage autonomes. La communication de contrôle de conformité (CCC, Compliance Checking Communication) survient entre l'équipement embarqué d'un véhicule routier (OBE) et un interrogateur (équipement en bord de route (RSE) fixe et mobile ou dispositif portable) et permet de déterminer si les données fournies par l'équipement embarqué reflètent correctement l'usage du réseau routier par le véhicule correspondant selon les règles du régime de péage applicable. L’exploitant de l’interrogateur de contrôle de conformité est supposé participer au rôle Perception du péage défini dans l’ISO 17573-1. L’application CCC permet d’identifier l’équipement embarqué, le véhicule et le contrat, de vérifier que le conducteur a bien rempli ses obligations et de déterminer l’état de fonctionnement et la performance de l’équipement embarqué. L’application CCC lit, mais n’écrit pas les données de l’équipement embarqué. Le présent document s’applique aux équipements embarqués autonomes; il ne s’applique pas au contrôle de conformité dans les systèmes de taxation reposant sur des communications dédiées à courte portée (DSRC). Il spécifie la syntaxe et la sémantique des données, mais ne définit pas de séquence de communication. Tous les attributs qui y sont spécifiés sont exigés dans tout équipement embarqué revendiqué conforme au présent document, même si certaines valeurs sont spécifiées comme étant «non spécifié» dans les cas où une certaine fonctionnalité n'est pas présente dans un équipement embarqué donné. L’interrogateur est libre de choisir quels attributs sont lus, ainsi que l’ordre dans lequel ils sont lus. Afin de permettre la compatibilité avec les systèmes existants, la communication utilise les attributs spécifiés dans l’ISO 17573-3 chaque fois que cela est utile. L’application CCC est adaptée à toute une variété de supports de communication à courte portée. Des définitions spécifiques sont données pour la pile de communication CEN-DSRC spécifiée dans l’EN 15509, ainsi que pour l’utilisation des piles ISO CALM IR, UNI DSRC (ETSI ES 200 674-1), ARIB DSRC et WAVE DSRC comme alternatives à CEN-DSRC. Les attributs et fonctions spécifiés sont destinés au contrôle de conformité via les services de communication DSRC fournis par la couche d'application DSRC, à l’aide des attributs et fonctions CCC mis à la disposition des applications CCC sur l’équipement en bord de route (RSE, Road-Side Equipment) et l’équipement embarqué. Les attributs et fonctions sont spécifiés au niveau des unités de données d’application (ADU, Application Data Unit). La définition de la communication CCC inclut: — l’interface d'application entre l’OBE et le RSE (comme décrit en Figure 2); — l’utilisation de la couche d'application DSRC générique spécifiée dans l’ISO 15628 et l’EN 12834; — les spécifications de types de données CCC données à l’Annexe A; — un formulaire de déclaration de conformité d’une mise en œuvre de protocole (PICS, Protocol Implementation Conformance Statement) est fourni à l’Annexe B; — l’utilisation de la pile CEN-DSRC selon l’EN 15509 ou d'autres piles de communication DSRC équivalentes comme décrit à l’Annexe C, l’Annexe D, l’Annexe E et l’Annexe F; — des services de sécurité dans le cadre de l’authentification mutuelle des partenaires de communication et de la signature des données (voir l’Annexe H); De plus, un exemple de transaction CCC est présenté à l’Annexe G et l’Annexe I explique comment utiliser le présent document dans le cadre du Service de Télépéage Européen (SET). Les spécifications d’essai n’entrent pas dans le domaine d’application du présent document.
General Information
Relations
Standards Content (Sample)
International
Standard
ISO 12813
Third edition
Electronic fee collection —
2024-02
Compliance check communication
for autonomous systems
Perception de télépéage — Communication de contrôle de
conformité pour systèmes autonomes
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 .v
Introduction .vi
1 Scope . 1
2 Normative references . 2
3 Terms and definitions . 3
4 Abbreviated terms . 5
5 Application interface architecture . 6
5.1 General .6
5.2 Services provided.6
5.3 Attributes .7
5.4 Toll context .7
5.5 Use of lower layers .7
5.5.1 Supported DSRC communication stacks .7
5.5.2 Use of the CEN-DSRC stack .8
6 Conformance . 8
6.1 Conformance requirements .8
6.2 Conformance statement .8
6.3 Conformance evaluation and testing .8
7 Functions . 8
7.1 Functional requirements . .8
7.1.1 Minimum supported functions .8
7.1.2 Initialise communication .9
7.1.3 Data retrieval .9
7.1.4 Authenticated data retrieval .9
7.1.5 Driver notification .9
7.1.6 Terminate communication .9
7.1.7 Test communication .10
7.2 Security .10
7.2.1 General .10
7.2.2 Authentication/non-repudiation .10
7.2.3 Access credentials .11
8 Data requirements .11
9 Transaction model .12
9.1 General . 12
9.2 Initialisation phase . 13
9.2.1 Initialisation request . 13
9.2.2 CCC application-specific contents of BST . 13
9.2.3 CCC application-specific contents of VST . 13
9.3 Transaction phase. 13
Annex A (normative) CCC data type specifications . 14
Annex B (normative) Protocol implementation conformance statement proforma .32
Annex C (informative) ETSI ES 200 674-1 communication stack usage for CCC applications . 41
Annex D (informative) Using the IR DSRC communication stack (CALM IR) for CCC applications .44
Annex E (informative) Using the ARIB DSRC communication stack for CCC applications .45
Annex F (informative) Using the WAVE communication stack for CCC applications . 47
Annex G (informative) Example CCC transaction .50
Annex H (informative) Security considerations .53
iii
Annex I (informative) Use of this document for the European Electronic Toll Service (EETS) .58
Bibliography .60
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 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, in
collaboration with the European Committee for Standardization (CEN) Technical Committee CEN/TC 278
Intelligent transport systems, in accordance with the Agreement on technical cooperation between ISO and
CEN (Vienna Agreement).
This third edition cancels and replaces the second edition (ISO 12813:2019), which has been technically
revised.
The main changes are as follows:
— Clause 6 has been added, concerning conformance requirements;
— 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;
— Annex A has been restructured;
— temporary optional support of legacy encoding in some data types in OBE and RSE in CEN countries has
been added;
— a second level of version identifier (i.e. minor version) of the abstract syntax notation one (ASN.1) module
has been added in order to provide enhanced support to standards that import data types from this
document (imported ASN.1 types are used to be subsequent editions, including all future minor versions).
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
On-board equipment (OBE) that uses satellite-based positioning technology to collect data required for
charging for the use of roads operates in an autonomous way (i.e. without relying on dedicated roadside
infrastructure). The OBE will record the amount of road usage in all toll charging systems it passes through.
This document specifies requirements for dedicated short-range communication (DSRC) between OBE and
an interrogator for the purpose of checking compliance of road use with a local toll regime. It assumes an
electronic fee collection (EFC) services architecture according to ISO 17573-1 (see Figure 1).
Figure 1 — Compliance check communication in EFC architecture according to ISO 17573-1
Toll chargers (TCs) need to check whether or not the road is used in compliance with the rules in the local
toll regime. One way of checking compliance is to observe a passing vehicle and to interrogate the OBE. This
interrogation happens under control of an entity responsible for toll charging (see Figure 1), accomplished
via short-range communication between an interrogator at the roadside or in another vehicle (operated by
a competent enforcement agency) and the OBE. In an interoperable environment, it is essential that this
interrogation communication be standardized such that every operator of compliance checking equipment
can check all passing OBE. For that purpose, this document defines attributes required on all OBE for reading
by an interrogator.
This document has been prepared to fulfil the following statements:
a) Collected evidence can be used as court proof. Data is indisputable and secured such that the operator
of the compliance checking interrogator can prove the integrity and authenticity of the data in case of
dispute.
b) The data required for compliance checking is read only, since the operator of the interrogator does not
interfere with the working of the OBE.
c) All attributes, standardized at the time of personalization of the OBE, are present in the OBE such that
an operator of an interrogator can essentially read the same data from all OBE, independent of the type
and make. In case an attribute does not make sense in a certain OBE implementation, a value assignment
for “not applicable” or “not defined” is provided in each case. An OBE compliant to the first edition of this
document will not answer with such a response for new attributes introduced in the current edition of
this document.
d) The attributes, derived from the individual toll regime are of general importance for all toll system
types (motorway tolling, area tolling, tolls for ferries, bridges, tunnels, cordon pricing, etc.).
vi
e) The attributes apply to all OBE architectures, and especially to both thin (edge-light) and fat (edge
heavy) client architectures. The interrogator is intended to receive essentially the same information,
irrespective of the type of OBE.
It is assumed that the prime objective of the operator of the compliance checking interrogation is to check
whether the user has fulfilled its obligations, in particular:
— whether the OBE is mounted in the correct vehicle;
— whether the classification data transmitted by the OBE are correct; and
— whether the OBE is in operational condition, both in a technical and a contractual sense.
Regarding the last point of the above list, on the operational status of OBE, the following model is assumed.
As long as the OBE signals the correct operational status to the user (“go” / “green”), the toll service provider
(TSP) takes full responsibility for the correct operation of the OBE and for the payment by the user. Hence, as
long as the OBE signals “green” and the user fulfils its other obligations (e.g. entering correct classification
data and not tampering with the OBE), the user can expect the OBE to serve as a valid payment means. As
soon as the OBE signals an invalid operational status (“no go” / “red”) — either set by the central system of
the TSP (e.g. because the user account is negative), by internal mechanisms of the OBE itself (e.g. because of
a detected defect or an outdated data set) or a user manipulation with such result — the user knows that the
OBE is no longer a valid payment means. The user then uses alternative means of toll declaration or payment
until the problem is remedied and the OBE indicates “green” again.
NOTE In this case, “red” and “green” are used in the abstract, symbolic sense, and do not imply any physical
implementation. The design of the user interface of the OBE is implementation-dependent, and several methods for
signalling “red” or “green” are conceivable.
Ultimately, the policy of when to signal “green” or “red” is specified by the TSP in accordance with the
requirements specified by the TC(s).
In the case where the OBE status turns “red”, the user takes action, declares road usage subject to fees or
pays by some alternative means as soon as practicable. Until the user does this, they are in a potentially non-
compliant situation. To allow a judgment to be made as to whether or not a user has taken the appropriate
action within an acceptable period of time, information is provided by this document not only on the “green/
red” operational status but also on the length of time that the OBE has been in its current status.
Different toll contexts can overlap geographically. A user could be liable in several toll contexts at once, e.g.
for a nationwide distance-dependent road tax and a local city access pricing scheme — a fact of which the
user might not in all cases be aware. This document builds on the concept that regarding compliance, as far
as possible, there is no notion of toll context (see 5.4). It is within the responsibility of the TSP to resolve
issues with overlapping toll contexts and to distil all information into a binary “red/green” message to the
user.
A secondary objective of the operator of the compliance checking interrogator can be to collect data on the
performance of the OBE, e.g. in order to check for the correct technical functioning. Since different OBE can
work according to quite different principles, the possibilities for doing this in a standardized way are quite
limited. This document contains some provisions for this task (e.g. the attributes CommunicationStatus,
GnssStatus, DistanceRecordingStatus), but otherwise assumes that TCs monitor correct recording by
comparing observed traffic (e.g. with cameras) with usage data received from TSPs.
This document has been prepared with the intention to be “minimalist” in the sense that it covers what is
required by operational and planned systems.
This document is complemented by ISO 13143, which specifies how to evaluate on-board and roadside
equipment for conformity to ISO 12813 (this document).
vii
International Standard ISO 12813:2024(en)
Electronic fee collection — Compliance check communication
for autonomous systems
1 Scope
This document specifies requirements for short-range communication for the purposes of compliance
checking in autonomous electronic fee collecting systems. Compliance checking communication (CCC) takes
place between a road vehicle's on-board equipment (OBE) and an interrogator [fixed and mobile roadside
equipment (RSE) or hand-held unit] and serves to establish whether the data that are delivered by the OBE
correctly reflect the road usage of the corresponding vehicle according to the rules of the pertinent toll
regime.
The operator of the compliance checking interrogator is assumed to be part of the toll charging role as
defined in ISO 17573-1. The CCC permits identification of the OBE, vehicle and contract, and verification of
whether the driver has fulfilled their obligations and the checking status and performance of the OBE. The
CCC reads, but does not write, OBE data.
This document is applicable to OBE in an autonomous mode of operation. It is not applicable to compliance
checking in dedicated short-range communication (DSRC)-based charging systems.
It specifies data syntax and semantics, but not a communication sequence. All the attributes specified
herein are required in any OBE claimed to be compliant with this document, even if some values are set to
“not specified” in cases where a certain functionality is not present in an OBE. The interrogator is free to
choose which attributes are read in the data retrieval phase, as well as the sequence in which they are read.
In order to achieve compatibility with existing systems, the communication makes use of the attributes
specified in ISO 17573-3 wherever useful.
The CCC is suitable for a range of short-range communication media. Specific definitions are given for the
CEN-DSRC as specified in EN 15509, as well as for the use of ISO CALM IR, the Italian DSRC as specified
in ETSI ES 200 674-1, ARIB DSRC, and WAVE DSRC as alternatives to the CEN-DSRC. The attributes and
functions specified are for compliance checking by means of the DSRC communication services provided by
DSRC application layer, with the CCC attributes and functions made available to the CCC applications at the
RSE and OBE. The attributes and functions are specified on the level of application data units (ADUs).
The definition of the CCC includes:
— the application interface between OBE and RSE (as depicted in Figure 2);
— use of the generic DSRC application layer as specified in ISO 15628 and EN 12834;
— CCC data type specifications given in Annex A;
— a protocol implementation conformance statement (PICS) proforma is given in Annex B;
— use of the CEN-DSRC stack as specified in EN 15509, or other equivalent DSRC stacks as described in
Annex C, Annex D, Annex E and Annex F;
— security services for mutual authentication of the communication partners and for signing of data (see
Annex H);
In addition, an example CCC transaction is presented in Annex G and Annex I highlights how to use this
document for the European Electronic Toll Service (EETS).
Test specifications are not within the scope of this document.
Key
ADU application data unit
AP application process
CCC compliance check communication
DSRC dedicated short-range communication
OBE on-board equipment
RSE roadside equipment
Figure 2 — CCC application interface
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/IEC 8825-2, Information technology — ASN.1 encoding rules — Part 2: Specification of Packed Encoding
Rules (PER)
ISO/IEC 9646-7, Information technology — Open Systems Interconnection — Conformance testing methodology
and framework — Part 7: Implementation Conformance Statements
ISO 12855, Electronic fee collection — Information exchange between service provision and toll charging
ISO 14906:2022, Electronic fee collection — Application interface definition for dedicated short-range
communication
ISO 15628:2013, Intelligent transport systems — Dedicated short range communication (DSRC) — DSRC
application layer
ISO 17573-3:2023, Electronic fee collection — System architecture for vehicle-related tolling — Part 3: Data
dictionary
EN 12834, Road transport and traffic telematics — Dedicated Short Range Communication (DSRC) — DSRC
application layer
EN 15509:2023, Electronic fee collection — Interoperability application profile for DSRC
NIMA Technical Report TR8350.2 version 3 — Department of Defense World Geodetic System 1984, Its
Definition and Relationships With Local Geodetic Systems
3 Terms and definitions
For the purposes of this document, the following terms and definitions 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
access credentials
trusted attestation or secure module that establishes the claimed identity of an object or application
[SOURCE: ISO/TS 17573-2:2020, 3.4]
3.2
attribute
addressable package of data consisting of a single data element or structured sequences of data elements
[SOURCE: ISO/TS 17573-2:2020, 3.13]
3.3
authentication
security mechanism allowing verification of the provided identity
[SOURCE: EN 301 175 V1.1.1:1998, 3]
3.4
authenticator
data, possibly encrypted, that is used for authentication (3.3)
[SOURCE: ISO/TS 17573-2:2020, 3.16]
3.5
back end
part of a back-office system interfacing to one or more front ends (3.8)
[SOURCE: ISO/TS 17573-2:2020, 3.22]
3.6
data integrity
property that data has not been altered or destroyed in an unauthorized manner
[SOURCE: ISO 7498-2:1989, 3.3.21]
3.7
fixed roadside equipment
roadside equipment (3.11) located at a fixed position
[SOURCE: ISO/TS 17573-2:2020, 3.81]
3.8
front end
part of an electronic fee collection (EFC) system which consists of on-board equipment (OBE) (3.10) and
possibly of a proxy where road tolling information and usage data are collected and processed for delivery
to the back end (3.5)
[SOURCE: ISO/TS 17573-2:2020, 3.85]
3.9
mobile roadside equipment
equipment mounted on a mobile unit or handheld equipment to be used along the road
[SOURCE: ISO/TS 17573-2:2020, 3.119]
3.10
on-board equipment
all required equipment on-board a vehicle for performing required electronic fee collection (EFC) functions
and communication services
[SOURCE: ISO/TS 17573-2:2020, 3.126]
3.11
roadside equipment
fixed or movable electronic fee collection (EFC) equipment located along or on the road
[SOURCE: ISO/TS 17573-2:2020, 3.161]
3.12
service primitive
elementary communication service provided by the application layer protocol to the application processes
[SOURCE: ISO/TS 17573-2:2020, 3.173]
3.13
toll
charge, tax or duty levied in connection to using a vehicle in a toll domain (3.16)
[SOURCE: ISO/TS 17573-2:2020, 3.193]
3.14
toll charger
entity which levies toll (3.13) for the use of vehicles in a toll domain (3.16)
[SOURCE: ISO/TS 17573-2:2020, 3.194]
3.15
toll context
logical view as defined by attributes (3.2) and functions of the basic elements of a toll scheme consisting of a
single basic tolling principle, a spatial distribution of the charge objects and a single behaviour of the related
front end (3.8)
[SOURCE: ISO/TS 17573-2:2020, 3.196]
3.16
toll domain
area or a part of a road network where a certain toll regime (3.17) is applied
[SOURCE: ISO/TS 17573-2:2020, 3.201]
3.17
toll regime
set of rules, including enforcement rules, governing the collection of tolls (3.13) in a toll domain (3.16)
[SOURCE: ISO/TS 17573-2:2020, 3.203]
3.18
toll service provider
entity providing toll services in one or more toll domains (3.16)
[SOURCE: ISO/TS 17573-2:2020, 3.206]
3.19
transaction
whole of the exchange of information between two physically separated communication facilities
[SOURCE: ISO/TS 17573-2:2020, 3.211]
4 Abbreviated terms
For the purpose of this document, the following abbreviated terms apply.
AC_CR access credentials
ADU application data unit
AID application identifier
ASN.1 abstract syntax notation one
BST beacon service table
CCC compliance check communication
CN cellular network
DSRC dedicated short-range communication
EFC electronic fee collection
EID element identifier
GNSS global navigation satellite systems
HMI human-machine interface
IID invoker identifier
MAC message authentication code
OBE on-board equipment
PICS protocol implementation conformance statement
PSC provider service context
RSE roadside equipment
SAM secure application module
TC toll charger
TSP toll service provider
VST vehicle service table
WGS84 World Geodetic System 1984
WSA WAVE service advertisement
5 Application interface architecture
5.1 General
This clause gives an insight into the CCC architecture. It identifies the services provided to CCC applications
and the functions that implement these services. It also defines principles regarding attributes and the use
of DSRC communication service primitives. A detailed description of the functions is given in Clause 7, whilst
the detailed list of the attributes is given in Clause 8.
The CCC application interface has been designed to make use of the CEN-DSRC communication stack, via the
application layer specified in ISO 15628 and EN 12834. For other identified DSRC communication media,
detailed mappings to corresponding services are given in annexes.
From a general addressing viewpoint, it should be noted that only one CCC context is used, as compliance
checking attributes are independent of context.
5.2 Services provided
The CCC application interface offers the following services to CCC applications:
— retrieval of compliance significant attributes, in order for RSE to assess OBE compliance,
— mutual authentication of RSE and OBE by means of exchange of credentials and authenticators, and
— a command to the OBE to signal to the user the result of the compliance check.
NOTE 1 The policy on whether the result of the compliance check or the fact that a transaction has taken place is
signalled to the user is decided by the entity operating the CCC interrogator and is outside the scope of this document.
The above services are realized by means of protocol exchanges performed by means of communication
services and transactions as described in Clause 9.
The services are provided by the following functions:
— the “initialise communication” function, which shall be used to establish the CCC communication link
between RSE and OBE;
— the “data retrieval” function, which shall be used to retrieve CCC attributes;
— the “authenticated data retrieval” function, which shall be used to retrieve data with an authenticator
from the OBE;
— the “driver notification” function, which shall be used to invoke a human-machine interface (HMI)
function (e.g. signal “OK” via a buzzer sound);
— the “terminate communication” function, which shall be used to terminate the CCC communication;
— the “test communication” function, which shall be used for testing and localizing the OBE.
NOTE 2 A “write” service is not provided, since the writing of data into the OBE is not foreseen.
5.3 Attributes
The attributes available on the OBE for a CCC application at roadside for checking the compliance of a vehicle
are given in detail in Clause 8.
All attributes specified in this document shall be available on the OBE.
The RSE is free to decide to read any combination of attributes from the OBE. The attributes shall be identified
and retrieved using the mechanisms specified in ISO 14906. More specifically, the addressing of the CCC
application data implemented by the OBE and RSE shall conform to the rules specified in ISO 14906:2022,
5.3.
Multiple instances of attributes are not supported.
5.4 Toll context
An OBE may be located in more than one tolling contexts at once.
NOTE This can occur, e.g. in situations where a motorway toll geographically overlaps with an area-based
charging system.
In these different tolling contexts, the OBE can potentially run different charging applications or several
instances of one charging application in parallel.
This document builds on the concept that for compliance checking, there is basically no need to distinguish
between tolling contexts. In certain circumstances and in the cases specified in the semantic definition, the
toll service provider (TSP) shall ensure that the attribute content complies with the specifications of the toll
charger (TC) (e.g. for local vehicle classes).
The OBE should hold only one CCC context, represented by a single element as specified in ISO 14906.
However, for backwards compatibility reasons, one additional CCC context, represented by a second element
may be used to support ISO 12813:2015, the previous edition of this document (see also 9.2.3).
5.5 Use of lower layers
5.5.1 Supported DSRC communication stacks
The CCC application interface makes use of the CEN-DSRC communication stack as defined in Table 1. Other
communication media can be used as listed in Table 1 if an equivalent mapping to corresponding services is
provided. Detailed examples are provided in informative annexes.
Table 1 — Supported short-range communication stacks
Medium Application layer Lower layers Detailed specifications
ISO 15628 EN 12795
CEN-DSRC Specification in 5.5.2
EN 12834 EN 12253
ETSI ES 200 674–1 ETSI ES 200 674–1
Italian DSRC (Clause 11 and (Clauses 7 to 10 and Implementation example in Annex C
Annex D) Annex D)
ISO 15628
ISO CALM IR ISO 21214 Implementation example in Annex D
EN 12834
ARIB STD-T75 ARIB STD-T75
ARIB DSRC Implementation example in Annex E
ISO 15628 ITU-R.M1453–2
IEEE 1609.3-2010
IEEE 1609.11-2010
WAVE DSRC IEEE 1609.4-2016 Implementation example in Annex F
ISO 15628
IEEE 802.11
NOTE EN 12795 and EN 12253 have been adopted in ITU-R.M 1453–2.
If more than one communication medium is implemented in an OBE, then the OBE shall respond to RSE
interrogations on the same medium that the RSE has initiated the CCC interrogation.
5.5.2 Use of the CEN-DSRC stack
The following requirements apply to the CCC application when used with the CEN-DSRC communication
stack.
The OBE shall conform to EN 15509:2023, 6.1.2.
Fixed RSE shall conform to EN 15509:2023, 6.2.2.
Mobile RSE shall conform to EN 15509:2023, 6.2.2, except for Downlink Parameter D4a (not applicable to
mobile RSE).
NOTE EN 15509 specifies the CEN-DSRC communication stack for fixed RSE only.
6 Conformance
6.1 Conformance requirements
The following requirements apply to OBE and RSE:
— functions (including security functions), as specified in Clause 7;
— application data, as specified in Clause 8 and supplemented by Annex A; and
— transaction model, as specified in Clause 9.
6.2 Conformance statement
A supplier of OBE that claims conformity of its OBE to the requirements specified in this document shall
provide a statement of conformance by completing the PICS proforma as provided in B.4.
A supplier of RSE that claims conformity of its RSE to the requirements specified in this document shall
provide a statement of conformance to this document by completing the PICS proforma as provided in B.5.
6.3 Conformance evaluation and testing
Suppliers of OBE or RSE claiming conformity of their equipment to this document for the communication
medium CEN-DSRC can perform their conformity tests according to specifications laid down in ISO 13143.
NOTE The use of ISO 13143 implies the use of other referenced underlying test standards for evaluation of
conformance to this document.
7 Functions
7.1 Functional requirements
7.1.1 Minimum supported functions
All functions specified in Clause 7 shall be available on the OBE.
For CEN-DSRC, the OBE shall provide the following functions:
— INITIALISATION, GET and RELEASE application layer services according to ISO 15628 and EN 12834;
— GET_STAMPED, SET_MMI and ECHO EFC functions according to ISO 14906.
Subclauses 7.1.2 to 7.1.7 specify the functions for CEN-DSRC only. For other supported media, according
to 5.5.1, equivalent functionality should be provided (for ETSI ES 200 674-1 5,8 GHz microwave DSRC see
Annex C, for CALM Infrared DSRC see Annex D, for ARIB microwave DSRC see Annex E and for WAVE 5,9 GHz
microwave DSRC see Annex F).
7.1.2 Initialise communication
The communication between the RSE and the OBE shall be initiated by the RSE, by means of the invocation of
an initialisation request by the RSE. After successful initialisation, the function “Initialise communication”
shall notify the applications on the RSE and OBE.
The initialisation notification on the OBE shall carry at least the identity of the beacon (e.g. beacon serial
number) and absolute time.
The initialisation notification on the RSE shall carry the CCC application identity and shall also carry data
required for the security services (e.g. nonce value, key identifier).
The function “Initialise communication” shall be provided by the application layer INITIALISATION services
as specified in ISO 15628 and EN 12834. It is specified in Annex A: refer to CCC-InitialiseComm-Request and
CCC-InitialiseComm-Response.
7.1.3 Data retrieval
The function “Data retrieval” shall be provided by the application layer GET service as specified in ISO 15628
and EN 12834. It is specified in Annex A: refer to CCC-DataRetrieval-Request and CCC-DataRetrieval-
Response.
In the GET service primitives, invoker identifier (IID) shall not be used.
NOTE The invocation of a service primitive by an application process implicitly calls upon and uses services
offered by the lower protocol layers.
GET shall always carry access credentials.
7.1.4 Authenticated data retrieval
The function “Authenticated data retrieval” shall be implemented by the EFC function GET_STAMPED
as specified in ISO 14906. It is specified in Annex A: refer to CCC-AuthDataRetrieval-Request and CCC-
AuthDataRetrieval-Response.
GET_STAMPED shall always carry access credentials.
NOTE Access credentials carry information needed to fulfil access conditions in order to perform the operation on
the addressed element in the OBE. Access credentials can carry passwords as well as cryptography-based information
such as authenticators.
7.1.5 Driver notification
The function “Driver notification” shall be implemented by the EFC function SET_MMI as specified in
ISO 14906. It is specified in Annex A: refer to CCC-Notification-Request and CCC-Notification-Response.
NOTE According to ISO 14906, SET_MMI.request uses EID = 0 and does not carry access credentials.
7.1.6 Terminate communication
The RSE may terminate the communication on the application level with the OBE with the function
“Terminate communication”, by means of the invocation of a release request by the RSE.
The function “Terminate communication” shall be provided by the application layer service EVENT-REPORT
as specified in ISO 15628 and EN 12834. It is specified in Annex A: refer to CCC-TerminateComm.
NOTE According to ISO 15628 and EN 12834, EVENT-REPORT (Release) uses EID = 0 and does not carry access
credentials.
7.1.7 Test communication
The function “Test communication” shall be implemented by the EFC function ECHO of ISO 14906, and is
specified in Annex A: refer to CCC-TestComm-Request and CCC-TestComm-Response.
NOTE According to ISO 14906, ECHO uses EID = 0 and does not carry access credentials.
7.2 Security
7.2.1 General
Security is an essential part of CCC applications. This document provides for generic security services. The
detailed implementations are media-specific.
This document provides for an authentication service that may serve to prove the identity of the data source
and the integrity of the data or to provide for non-repudiation, or both. It contains a mechanism for control
of access to the OBE data by means of access credentials. Access protection is also used for protection of user
privacy.
It does not provide for an encryption service.
NOTE 1 It is assumed that privacy protection requirements are covered by the access credentials mechanism.
NOTE 2 Transaction counter according to EN 15509 is not supported by the CCC application.
NOTE 3 The security measures specified in the following subclauses fulfil the CCC interface security
countermeasures specified in ISO 19299:2020, 7.3.3.
7.2.2 Authentication/non-repudiation
Authenticated reading of data is provided by the function “Authenticated data retrieval”. Authenticators
are defined as ASN.1 OCTET STRING type. This only pertains to the ASN.1 syntax; the semantics are media
dependent.
When using the CEN-DSRC communication stack:
— the OBE shall be able to calculate authenticators according to security level 1 as specified in EN 15509:2023,
6.1.5.3;
— the RSE shall be able to calculate authenticators to security level 1 as specified in EN 15509:2023, 6.1.5.3;
— the RSE shall request a message authentication code (MAC) by addressing at least the attribute
PaymentMeans;
— the authentication keys (AuK(k)) stored in the OBE shall be derived from the master authentication keys
(MAuK(k)) as specified in ISO 14906:2022, F.4.2, with the following algorithm for computing the input
value (VAL):
VAL = ‘Compact_PersonalAccountNumber || ContractProvider || 00’, where
Compact_PersonalAccountNumber = [HighDWord32(PAN)] XOR [LowDWord32(PAN)]
NOTE 1 The derived authentication key for a given generation k is computed as follows AuK(k) = ede [MAuK(k)]
(VAL), where "ede" is the chained encryption, decryption and encryption of the input value (VAL) using the master
authentication key for the given generation k.
When using one of the other communication stacks described in Annexes C, D, E or F, algorithms and the use
of lower communication layer services shall be as specified in the corresponding annex.
Authenticators shall primarily pertain to values and prove the source and the integrity of the data unit.
Authenticators shall protect against forge
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...