SIST EN ISO 12813:2020

SLOVENSKI STANDARD
01-marec-2020
Nadomešča:
SIST EN ISO 12813:2016
SIST EN ISO 12813:2016/A1:2017
Elektronsko pobiranje pristojbin - Komunikacija za potrditev skladnosti
avtonomnih sistemov (ISO 12813:2019)
Electronic fee collection - Compliance check communication for autonomous systems
(ISO 12813:2019)
Elektronische Gebührenerhebung - Kommunikation zur Übereinstimmungsprüfung für
autonome Systeme (ISO 12813:2019)
Perception du télépéage - Communication de contrôle de conformité pour systèmes
autonomes (ISO 12813:2019)
Ta slovenski standard je istoveten z: EN ISO 12813:2019
ICS:
03.220.20 Cestni transport Road transport
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN ISO 12813
EUROPEAN STANDARD
NORME EUROPÉENNE
December 2019
EUROPÄISCHE NORM
ICS 03.220.20; 35.240.60 Supersedes EN ISO 12813:2015
English Version
Electronic fee collection - Compliance check
communication for autonomous systems (ISO
12813:2019)
Perception de télépéage - Communication de contrôle Elektronische Gebührenerhebung - Kommunikation
de conformité pour systèmes autonomes (ISO zur Übereinstimmungsprüfung für autonome Systeme
12813:2019) (ISO 12813:2019)
This European Standard was approved by CEN on 5 October 2019.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2019 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN ISO 12813:2019 E
worldwide for CEN national Members.

Contents Page
European foreword . 3

European foreword
This document (EN ISO 12813:2019) has been prepared by Technical Committee ISO/TC 204
"Intelligent transport systems" in collaboration with Technical Committee CEN/TC 278 “Intelligent
transport systems” the secretariat of which is held by NEN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by June 2020, and conflicting national standards shall be
withdrawn at the latest by June 2020.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document supersedes EN ISO 12813:2015.
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association.
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the
United Kingdom.
Endorsement notice
The text of ISO 12813:2019 has been approved by CEN as EN ISO 12813:2019 without any modification.

INTERNATIONAL ISO
STANDARD 12813
Second edition
2019-11
Electronic fee collection —
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 12813:2019(E)
©
ISO 2019
ISO 12813:2019(E)
© 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

ISO 12813:2019(E)
Contents Page
Foreword .v
Introduction .vii
1 Scope . 1
2 Normative references . 2
3 Terms and definitions . 3
4 Abbreviated terms . 4
5 Application interface architecture . 5
5.1 General . 5
5.2 Services provided . 5
5.3 Attributes . 6
5.4 Toll context . 6
5.5 Use of lower layers . 6
5.5.1 Supported DSRC communication stacks . 6
5.5.2 Use of the CEN-DSRC stack. 7
6 Functions . 7
6.1 Functions in detail . 7
6.1.1 General. 7
6.1.2 Initialise communication . 7
6.1.3 Data retrieval . 8
6.1.4 Authenticated data retrieval . 8
6.1.5 Driver notification . 8
6.1.6 Terminate communication . 8
6.1.7 Test communication . 8
6.2 Security . 8
6.2.1 General. 8
6.2.2 Authentication/non-repudiation . 9
6.2.3 Access credentials . 9
7 Attributes . 9
7.1 General . 9
7.2 Data regarding identification . .11
7.3 Data regarding status .11
7.4 Data regarding vehicle .18
8 Transaction model .20
8.1 General .20
8.2 Initialisation phase .20
8.2.1 Initialisation request .20
8.2.2 CCC application-specific contents of BST .20
8.2.3 CCC application-specific contents of VST.21
8.3 Transaction phase .21
Annex A (normative) CCC data type specifications .22
Annex B (normative) PICS proforma .23
Annex C (informative) ETSI ES 200 674-1 communication stack usage for CCC applications .31
Annex D (informative) Using the IR DSRC communication stack (CALM IR) for CCC applications .34
Annex E (informative) Using the ARIB DSRC communication stack for CCC applications .35
Annex F (informative) Using the WAVE communication stack for CCC applications .37
Annex G (informative) Example CCC transaction .40
Annex H (informative) Security considerations .42
ISO 12813:2019(E)
Annex I (informative) Use of this document for the EETS .47
Bibliography .49
iv © ISO 2019 – All rights reserved

ISO 12813:2019(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/ patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso .org/
iso/ foreword .html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
This second edition cancels and replaces the first edition (ISO 12813:2015), which has been technically
revised. It also incorporates the Amendment ISO 12813:2015/Amd 1:2017.
The main changes compared to the previous edition are as follows:
— inclusion of the changes of ISO 12813:2015/Amd 1:2017(E), i.e. it defines the electronic fee collection
compliance check communication using the WAVE communication stack as defined in IEEE;
— reverting the length of attribute GnssStatus back to 23 octets and removing the data element of type
Altitude;
— allowing a maximum of two instances of AID = 20 in the ApplicationList in the VST;
— adding values goSuspicion (5) and noGoPaymentMeans (4) to the data element statusIndicator as
well as updating and clarifying the semantic definitions of all statuses and when they change;
— updating the OBEStatusHistory – timeWhenChanged and ExtendedOBEStatusHistory
-timeWhenChanged/timeWhenChangedToPrevious based on the updated sematic definition of
statusIndicator;
— clarifing the relationship between the LLLL element in VehicleClass and the LocalVehicleClassId
(imported from ISO 17575-3);
— clarifing that ExtendedOBEStatusHistory - timeWhenChangedToPrevious shall be set to zero in
case no previous value is available;
— clarifing that VehicleWeightHistory – timeWhenChangedToCurrentValue changes not only due to
changes in the attribute VehicleCurrentMaxTrainWeight but also changes in the assignment of the
LocalVehicleClassId or the LLL element within VehicleClass;
ISO 12813:2019(E)
— adding the EFC attributes ExtendedOBUStatusHistoryPart1, ExtendedOBUStatusHistoryPart2 and
UserConfirmation;
— updating Annex C by adding the attributes VehicleCurrentMaxTrainWeight and
AttributeUpdateInterval to the information in virtual memory according to ETSI ES 200 674-1
communication stack usage for CCC applications.
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.
vi © ISO 2019 – All rights reserved

ISO 12813:2019(E)
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 defines 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 have the need to check whether 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 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, standardised at the time of personalisation of the OBE, are present in the OBE such
that an operator of an interrogator essentially can read the same data from all OBE independent of
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 will not answer with such a response for new attributes introduced in the current
edition of this document.
ISO 12813:2019(E)
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.).
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 interrogator is to
check whether the user has fulfilled his obligations, especially:
— 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 to the user correct operational status (“green”), the service provider 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 (“red”) — either set by the central system of
the service provider (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 has to use alternative
1)
means of toll declaration or payment until the problem is remedied and the OBE is “green” again .
Ultimately, the policy of when to signal “green” or “red” is defined by the service provider in accordance
with the requirements defined by the toll charger(s).
In the case where the OBE status turns “red”, the user has to take action, declare road usage subject to
fees or pay by some alternative means as soon as practicable. Until he does, the user is in a potentially
non-compliant situation. In order 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, there is no notion of toll context as far as possible (see especially 5.4). It is within the
responsibility of the service provider 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 might 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
standardised way are quite limited. This document contains some provisions for this task (e.g. the
attributes CommunicationStatus, GnssStatus, DistanceRecordingStatus), but otherwise assumes that
toll chargers monitor correct recording by comparing observed traffic (e.g. with cameras) with usage
data received from service providers.
This document has been prepared with the intention to be “minimalist” in the sense that it covers what
is required by operational systems and systems planned in the foreseeable future.
1) 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.
viii © ISO 2019 – All rights reserved

ISO 12813:2019(E)
A test suite for checking an OBE or RSE implementation for compliance with this document is defined in
the corresponding edition of ISO 13143-1 and ISO 13143-2.
INTERNATIONAL STANDARD ISO 12813:2019(E)
Electronic fee collection — Compliance check
communication for autonomous systems
1 Scope
This document defines 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 (roadside mounted
equipment, mobile device 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 his 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 defines data syntax and semantics, but not a communication sequence. All the attributes defined
herein are required in any OBE claimed to be compliant with this document, even if some values are set
to “not defined” in cases where 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 defined in ISO 14906 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 defined 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 roadside equipment (RSE) and OBE. The attributes and functions are
defined on the level of application data units (ADU).
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);
— an example CCC transaction is presented in Annex G;
— the informative Annex I highlights how to use this document for the European electronic toll service
(as defined in Commission Decision 2009/750/EC).
ISO 12813:2019(E)
Test specifications are not within the scope of this document.
NOTE A test suite for checking an OBE or RSE implementation for compliance with this document is defined
in the corresponding edition of ISO 13143-1 and ISO 13143-2.
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 8824-1:2015, Information technology — Abstract Syntax Notation One (ASN.1): Specification of
basic notation — Part 1
ISO/IEC 8825-2:2015, Information technology — ASN.1 encoding rules: Specification of Packed Encoding
Rules (PER) — Part 2
ISO 14906:2018, Electronic fee collection — Application interface definition for dedicated short-range
communication
2)
ISO 14906:2018/Amd 1 , Electronic fee collection — Application interface definition for dedicated short-
range communication — Amendment 1
2) To be published. Current stage: 40.99.
2 © ISO 2019 – All rights reserved

ISO 12813:2019(E)
ISO 17575-3:2016, Electronic fee collection — Application interface definition for autonomous systems —
Part 3: Context data
ISO 15628:2013, Intelligent transport systems — Dedicated short range communication (DSRC) — DSRC
application layer
EN 12834:2003, Road transport and traffic telematics — Dedicated Short Range Communication (DSRC) —
DSRC application layer
EN 15509:2014, 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 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
access credentials
AC_CR
trusted attestation or secure module that establishes the claimed identity of an object or application
3.2
attribute
addressable package of data consisting of a single data element or structured sequences of data
elements
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.5
data integrity
property that data has not been altered or destroyed in an unauthorized manner
[SOURCE: ISO 7498-2:1989, 3.3.21]
3.6
fixed roadside equipment
roadside equipment located at a fixed position
3.7
mobile roadside equipment
equipment mounted on a mobile unit or handheld equipment to be used along the road
ISO 12813:2019(E)
3.8
on-board equipment
OBE
all required equipment on-board a vehicle for performing required electronic fee collection (EFC)
functions and communication services
3.9
roadside equipment
RSE
equipment located along the road, either fixed or mobile
3.10
service primitive
elementary communication service provided by the application layer protocol to the application
processes
3.11
toll context
logical view as defined by attributes 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.12
toll regime
set of rules, including enforcement rules, governing the collection of a toll in a toll domain
3.13
toll service provider
TSP
entity providing toll services in one or more toll domains
3.14
transaction
whole of the exchange of information between two physically separated communication facilities
4 Abbreviated terms
For the purpose of this document, the following abbreviated terms apply.
AC_CR access credentials
ADU application data unit (ISO 14906)
ASN.1 abstract syntax notation one (ISO/IEC 8824-2)
BST beacon service table (ISO 14906)
CCC compliance check communication
DSRC dedicated short-range communication (ISO 14906)
EID Element Identifier (ISO 15628 and EN 12834)
EFC electronic fee collection
GNSS/CN global navigation satellite systems/cellular network
MAC message authentication code (ISO 14906)
4 © ISO 2019 – All rights reserved

ISO 12813:2019(E)
OBE on-board equipment (ISO 14906)
PICS protocol implementation conformance statement
RSE roadside equipment (ISO 14906)
TSP toll service provider
VST vehicle service table (ISO 14906)
WGS84 World Geodetic System 1984
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 6, whilst the detailed list of the attributes is given in Clause 7.
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
— a command to the OBE to signal to the user the result of the compliance check.
NOTE 1 The policy on whether or not 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 8.
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.
ISO 12813:2019(E)
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 side for a CCC application at roadside for checking the compliance of
a vehicle are given in detail in Clause 7.
All attributes defined in this document shall be available on the OBE side.
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 defined in ISO 14906. More specifically, the addressing
of the CCC application data implemented by the OBE and RSE shall conform to the rules defined in
ISO 14906:2018, 5.3.
Multiple instances of attributes are not supported.
5.4 Toll context
An OBE may be in several 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 might 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 shall ensure that the attribute content complies with the
specifications of the toll charger (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 (see also 8.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 described 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
NOTE  EN 12795 and EN 12253 have been adopted in ITU-R.M 1453–2.
6 © ISO 2019 – All rights reserved

ISO 12813:2019(E)
Table 1 (continued)
Medium Application layer Lower layers Detailed specifications
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 comply with EN 15509:2014, 6.1.2.
Fixed RSE shall comply with EN 15509:2014, 6.2.2.
Mobile RSE shall comply with EN 15509:2014, 6.2.2, except for Downlink Parameter D4a (not applicable
to mobile RSE).
NOTE EN 15509 defines the CEN-DSRC communication stack for fixed RSE only.
6 Functions
6.1 Functions in detail
6.1.1 General
All functions defined in 6.1 shall be available on the OBE side.
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.
6.1.2 to 6.1.7 define the functions for CEN-DSRC only. For other supported media, according to 5.5.1
equivalent functionality should be provided; see Annex C for ETSI ES 200 674-1 5.8 GHz microwave
DSRC, Annex D for CALM Infrared DSRC, Annex E for ARIB microwave DSRC and Annex F for WAVE
5.9 GHz microwave DSRC.
6.1.2 Initialise communication
Initialisation of 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 sides.
The initialisation notification on the OBE side shall carry at least the identity of the beacon (e.g. beacon
serial number) and absolute time.
The initialisation notification on the RSE side 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 defined in Annex A: refer to CCC-InitialiseComm-
Request and CCC-InitialiseComm-Response.
ISO 12813:2019(E)
6.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 defined in Annex A: refer to CCC-DataRetrieval-Request and CCC-
DataRetrieval-Response.
In the GET service primitives, 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.
6.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 defined 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
6.1.5 Driver notification
The function “Driver notification” shall be implemented by the EFC function SET_MMI as specified in
ISO 14906. It is defined 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.
6.1.6 Terminate communication
The RSE may termina
...