EN ISO 12813:2015

SLOVENSKI STANDARD
01-april-2016
1DGRPHãþD
SIST-TS CEN ISO/TS 12813:2010
Elektronsko pobiranje pristojbin - Komunikacija za potrditev skladnosti
avtonomnih sistemov (ISO 12813:2015)
Electronic fee collection - Compliance check communication for autonomous systems
(ISO 12813:2015)
Elektronische Gebührenerhebung - Kommunikation zur Übereinstimmungsprüfung für
autonome Systeme (ISO 12813:2015)
Perception du télépéage - Communication de contrôle de conformité pour systèmes
autonomes (ISO 12813:2015)
Ta slovenski standard je istoveten z: EN ISO 12813:2015
ICS:
03.220.20 Cestni transport Road transport
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
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 2015
EUROPÄISCHE NORM
ICS 03.220.20; 35.240.60 Supersedes CEN ISO/TS 12813:2009
English Version
Electronic fee collection - Compliance check
communication for autonomous systems (ISO
12813:2015)
Perception du 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:2015) (ISO 12813:2015)
This European Standard was approved by CEN on 24 October 2015.

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, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, 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: Avenue Marnix 17, B-1000 Brussels
© 2015 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN ISO 12813:2015 E
worldwide for CEN national Members.

Contents Page
European foreword . 3

European foreword
This document (EN ISO 12813:2015) has been prepared by Technical Committee ISO/TC 204
"Intelligent transport systems" in collaboration with Technical Committee CEN/TC 278 “Road transport
and traffic telematics” 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 2016, and conflicting national standards shall be
withdrawn at the latest by June 2016.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent
rights.
This document supersedes CEN ISO/TS 12813:2009.
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, Former Yugoslav Republic of Macedonia,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,
Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.
Endorsement notice
The text of ISO 12813:2015 has been approved by CEN as EN ISO 12813:2015 without any modification.
INTERNATIONAL ISO
STANDARD 12813
First edition
2015-12-01
Electronic fee collection —
Compliance check communication for
autonomous systems
Perception du télépéage — Communication de contrôle de conformité
pour systèmes autonomes
Reference number
ISO 12813:2015(E)
©
ISO 2015
ISO 12813:2015(E)
© ISO 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, 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
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – All rights reserved

ISO 12813:2015(E)
Contents Page
Foreword .v
Introduction .vi
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 . 5
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. 6
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 . 7
6.1.4 Authenticated data retrieval . 7
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 . 8
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 .13
8 Transaction model .15
8.1 General .15
8.2 Initialisation phase .15
8.2.1 Initialisation request .15
8.2.2 CCC application-specific contents of BST .15
8.2.3 CCC application-specific contents of VST.15
8.3 Transaction phase .15
Annex A (normative) CCC data type specifications .16
Annex B (normative) PICS proforma for the attributes .17
Annex C (informative) ETSI/ES 200 674-1 communication stack usage for CCC applications .26
Annex D (informative) Using the IR DSRC communication stack (CALM IR) for CCC applications .29
Annex E (informative) Using the ARIB DSRC communication stack for CCC applications .30
Annex F (informative) Example CCC transaction .32
Annex G (informative) Security considerations .34
Annex H (informative) Use of this International Standard for the EETS .39
ISO 12813:2015(E)
Bibliography .41
iv © ISO 2015 – All rights reserved

ISO 12813:2015(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 on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/TC 204, Intelligent transport systems.
This first edition replaces the Technical Specification ISO/TS 12813:2009, which has been technically
revised. This first edition incorporates the following main modifications compared to the Technical
Specification:
− conversion from a Technical Specification to an International Standard;
− new attributes added (TrailerCharacteristics, AttributeUpdateInterval,
VehicleCurrentMaxTrainWeight, VehicleWeightHistory, ExtendedOBEStatusHistory,
ExtendedVehicleAxlesHistory and LocalVehicleClassId);
− amendment of terms, in order to reflect harmonization of terms across electronic fee collection
(EFC) standards;
− amendments to reflect changes to the underlying base standards, in particular ISO 14906 and
EN 15509;
− addition of a new informative annex (i.e. Annex H) on how to use this International Standard for
the European electronic toll service;
− editorial and formal corrections as well as changes to improve readability.
ISO 12813:2015(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
road side infrastructure). The OBE will record the amount of road usage in all toll charging systems it
passes through.
This International Standard 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.
See Figure 1.
Interoperability
management
Service
provision
Toll
charging
Compliance check
communication
Service usage
Figure 1 — Compliance check communication in EFC architecture as per ISO 17573
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 road-side 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 International Standard defines
attributes required on all OBE for reading by an interrogator.
This International Standard has been prepared considering the prerequisites listed below in a) to e).
a) Collected evidence must be court proof. Data must be 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 must be read only, since the operator of the interrogator
must not interfere with the working of the OBE.
c) All attributes, standardised at the time of personalisation of the OBE, should be 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 International Standard.
vi © ISO 2015 – All rights reserved

ISO 12813:2015(E)
d) The attributes, derived from the individual toll regime, must be of general importance for all toll
system types (motorway tolling, area tolling, tolls for ferries, bridges, tunnels, cordon pricing, etc.).
e) The attributes must apply to all OBE architectures, and especially to both thin (edge-light) and fat
(edge heavy) client architectures. The interrogator must be able to receive essentially the same
information irrespective of OBE implementation decisions.
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 working 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 working of the OBE and for the payment by the user. Hence, as long as
the OBE signals “green” and the user fulfils his other obligations (such as 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 quickly as possible. 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 International
Standard 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 nation-wide 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 International Standard builds on the concept that
regarding compliance, there is no notion of toll context (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 International Standard 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 International Standard 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) Here, “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.
ISO 12813:2015(E)
A test suite for checking an OBE or RSE implementation for compliance with the first edition of this
International Standard is defined in the corresponding edition of ISO/TS 13143-1 and ISO/TS 13143-
2. This test suite is currently being updated to reflect the changes incorporated into this first edition
of ISO 12813.
viii © ISO 2015 – All rights reserved

INTERNATIONAL STANDARD ISO 12813:2015(E)
Electronic fee collection — Compliance check
communication for autonomous systems
1 Scope
This International Standard 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 outside
interrogator (road-side 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. 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 International Standard 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 does not define a communication sequence. All the attributes
defined herein are required in any OBE claimed to be compliant with this International Standard, 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, 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 and ARIB 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 layer 7, with the CCC attributes and functions made available to the CCC applications at the
road-side 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,
— use of the CEN-DSRC stack as specified in EN 15509, or other equivalent DSRC stacks as described in
Annexes C, D and E, and
— security services for mutual authentication of the communication partners and for signing of data
(see Annex G).
CCC data type specifications are given in Annex A, protocol implementation conformance statement
(PICS) proforma in Annex B. An example CCC transaction is presented in Annex F. The informative
Annex H highlights how to use this International Standard for the European electronic toll service (as
defined in Commission Decision 2009/750/EC).
Test specifications are not within the scope of this International Standard.
ISO 12813:2015(E)
OBE
RSE
Road-side CCC On-board CCC
application application
RSE CCC OBE CCC
function calls function calls
Scope of
DSRC functions ADU DSRC functions
this
International for CCC for CCC
Standard
Communication Communication
service primitives service primitives
DSRC communication services
Figure 2 — CCC application interface
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. 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:2008, Information technology — Abstract Syntax Notation One (ASN.1): Specification of
basic notation — Part 1
ISO/IEC 8825-2:2008, Information technology — ASN.1 encoding rules: Specification of Packed Encoding
Rules (PER) — Part 2
ISO 14906:2011/Amd1:2005, 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
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
2 © ISO 2015 – All rights reserved

ISO 12813:2015(E)
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.
3.1
access credentials
trusted attestation or secure module that establishes the claimed identity of an object or application
[SOURCE: EN 15509:2014, 3.1]
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]
3.4
authenticator
data, possibly encrypted, that is used for authentication
[SOURCE: ISO/TS 19299:2015, 3.5]
3.5
data integrity
property that data has not been altered or destroyed in an unauthorized manner
[SOURCE: ISO/TS 19299:2015, 3.28]
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
3.8
on-board equipment
OBE
all required equipment on-board a vehicle for performing required EFC functions and
communication services
3.9
roadside equipment
RSE
equipment located along the road, either fixed or mobile
3.10
toll service provider
TSP
entity providing toll services in one or more toll domains
[SOURCE: ISO 17573:2010]
ISO 12813:2015(E)
3.11
service primitive
elementary communication service provided by the application layer protocol to the application processes
[SOURCE: ISO 14906:2011, 3.18 modified]
3.12
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.13
toll regime
set of rules, including enforcement rules, governing the collection of a toll in a toll domain
[SOURCE: ISO 17573:2010, 3.20]
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 abbreviations 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 media access control (EN 12795) or message authentication code (ISO 14906)
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
4 © ISO 2015 – All rights reserved

ISO 12813:2015(E)
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 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 of 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 International Standard.
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.
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 road-side for checking the compliance
of a vehicle are given in detail in Clause 7.
All attributes defined in this International Standard 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
ISO 12813:2015(E)
of the CCC application data implemented by the OBE and RSE shall conform to the rules defined in
ISO 14906:2011, 5.3.
Multiple instances of attributes are not supported.
5.4 Toll context
An OBE may be in several tolling contexts at once. This can occur, e.g. in situations where a motorway
toll geographically overlaps with an area charging system. In these different tolling contexts, the OBE
might run different charging applications or several instances of one charging application in parallel.
This International Standard builds on the concept that for compliance checking, there is no need to
distinguish between tolling contexts. The data relevant for checking compliance, e.g. the identity of the
vehicle, classification parameters and operational status of the OBE (“red” or “green”), are independent
of the tolling context. Also, for legal reasons, a user must know whether or not he is acting in a compliant
way without understanding technical detail, such as how many overlapping tolling contexts there are at
a given moment.
Hence, there is only one CCC context, and context-related concepts known from DSRC charging — such
as identification of the toll context via the EFC context mark or addressing a specific context via a
corresponding EID — are not required. Therefore, the OBE shall hold only one CCC context, identified
by a single EID value.
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 1: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.
6 © ISO 2015 – All rights reserved

ISO 12813:2015(E)
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.
Subclauses 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, and Annex E for ARIB 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.
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.
ISO 12813:2015(E)
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 terminate the communication on application level with the OBE with the function
“Terminate communication”, by means of the invocation of a release request by the RSE.
NOTE 1 A termination of the communication on link level is outside of the scope of this International Standard.
The function “Terminate communication” shall be provided by the application layer service EVENT-
REPORT as specified in ISO 15628 and EN 12834. It is defined in Annex A: refer to CCC-TerminateComm.
NOTE 2 According to ISO 15628 and EN 12834, EVENT-REPORT (Release) uses EID = 0 and does not carry
access credentials.
6.1.7 Test communication
The function “Test communication” shall be implemented by the EFC function ECHO of ISO 14906, and is
defined 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.
6.2 Security
6.2.1 General
Security is an essential part of CCC applications. This International Standard provides for generic
security services. The detailed implementations are media-specific.
This International Standard provides for an authentication service that may serve to prove the
identity of the data source, the integrity of the data and/or to provide for non-repudiation. 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 en
...