CEN/TS 16986:2016

SLOVENSKI STANDARD
01-april-2017
Elektronsko pobiranje pristojbin - Interoperabilni profili aplikacije za informativno
izmenjavo med ponudnikom storitve in operaterjem cestninjenja
Electronic Fee Collection - Interoperable application profiles for information exchange
between Service Provision and Toll Charging
Elektronische Gebührenerhebung - Interoperables Anwendungsprofil für den
Datenaustausch zwischen Dienstanbietern und Mauterhebern
Perception de télépéage - Profil d'application interopérabilité pour échange
d'informations entre la prestation de service et la perception du péage
Ta slovenski standard je istoveten z: CEN/TS 16986:2016
ICS:
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.

CEN/TS 16986
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
October 2016
TECHNISCHE SPEZIFIKATION
ICS 35.240.60
English Version
Electronic Fee Collection - Interoperable application
profiles for information exchange between Service
Provision and Toll Charging
Perception de télépéage - Profil d'application Elektronische Gebührenerhebung - Interoperable
interopérabilité pour échange d'informations entre la Anwendungsprofile für den Informationsaustausch
prestation de service et la perception du péage zwischen den Dienste-Versorgern und Mauterhebern
This Technical Specification (CEN/TS) was approved by CEN on 13 July 2016 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to
submit their comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS
available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in
parallel to the CEN/TS) until the final decision about the possible conversion of the CEN/TS into an EN is reached.

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
© 2016 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 16986:2016 E
worldwide for CEN national Members.

Contents Page
European foreword . 6
Introduction . 7
1 Scope . 8
2 Normative references . 8
3 Terms and definitions . 9
4 Abbreviations . 13
5 Conformance . 14
5.1 General . 14
5.2 Base standard . 14
5.3 Main contents of an 12855-IAP . 14
5.4 Conformance requirements . 15
5.4.1 General requirements . 15
5.4.2 Transaction requirements . 15
5.4.3 Data requirements . 16
5.4.4 Transaction requirements . 17
5.5 Conformation notification . 20
5.6 Interoperability . 21
6 Requirements on common transactions . 21
6.1 General . 21
6.2 InfoExchange. 21
6.2.1 InfoExchangeContent . 21
6.2.2 InfoExchangeAuthenticator . 23
6.3 AckADU . 23
6.3.1 General . 23
6.3.2 Syntax and semantics. 23
6.4 USERDETAILS - Exchange Enforcement Data - Retrieve and Provide User Details . 26
6.4.1 Transaction sequence, triggers and timings . 26
6.4.2 Syntax and semantics. 28
6.5 LISTOFUSERS - List of Users . 30
6.5.1 Transaction sequence, triggers and timings . 30
6.5.2 Syntax and semantics. 31
6.6 EXCEPTIONLIST - Managing Exception Lists . 32
6.6.1 Transaction sequence, triggers and timings . 32
6.6.2 Syntax and semantics. 33
6.7 TRUSTOBJECTS - Exchange trust objects . 37
6.7.1 APDU transfer mechanisms . 37
6.7.2 Transaction sequence, triggers and timings . 37
6.7.3 Syntax and semantics. 38
6.8 PAYMENTCLAIM - Payment Claim . 40
6.8.1 Transaction sequence, triggers and timings . 40
6.8.2 Syntax and semantics. 42
7 DSRC profile specific transactions . 44
7.1 DSRC.CONTRACTISSUERLIST – ContractIssuerList . 44
7.1.1 Transaction sequence, triggers and timings . 44
7.1.2 Syntax and semantics - ContractIssuerListADU . 45
7.2 DSRC.EFCCONTEXTDATA - Provide and Request EFC Context Data . 45
7.2.1 Transaction sequence, triggers and timings . 45
7.2.2 Syntax and semantics - EfcContextDataADU . 47
7.3 DSRC.BILLINGDETAILS - Report billing details . 48
7.3.1 Transaction sequence, triggers and timings . 48
7.3.2 Syntax and semantics . 50
7.4 DSRC.REPORTABNORMALOBE . 62
7.4.1 Transaction sequence, triggers and timings . 62
7.4.2 Syntax and semantics - ReportAbnormalOBEADU . 64
8 GNSS profile specific transactions . 64
8.1 GNSS.TOLLDECLARATIONS - Report toll declarations. 64
8.1.1 Transaction sequence, triggers and timings . 64
8.1.2 Syntax and semantics - TollDeclarationADU . 66
8.2 Report billing details . 73
8.2.1 General . 73
8.2.2 GNSS.BILLINGDETAILS.TSP - Transaction sequence, triggers and timings . 73
8.2.3 GNSS.BILLINGDETAILS.TC - Transaction sequence, triggers and timing . 75
8.2.4 Syntax and semantics of GNSS.BILLINGDETAILS.TSP and GNSS.BILLINGDETAILS.TC -
BillingDetailsADU . 76
8.3 GNSS.PAYMENTANNOUNCEMENT . 80
8.3.1 Transaction sequence, triggers and timings . 80
8.3.2 Syntax and semantics - PaymentAnnouncementADU . 81
9 APDU Transfer mechanisms . 83
9.1 ASN.1 encoding . 83
9.2 Generic transfer mechanisms . 83
9.3 Alternative transfer mechanisms for transaction type TRUSTOBJECTS . 83
Annex A (normative) ICS Proforma . 84
A.1 Guidance for completing the PICS proforma . 84
A.1.1 Purposes and structure . 84
A.1.2 Abbreviations and conventions . 84
A.1.3 Instructions for completing the PICS proforma . 86
A.2 Identification of the implementation . 86
A.2.1 General . 86
A.2.2 Date of the statement . 86
A.2.3 Implementation Under Test (IUT) identification. 86
A.2.4 System Under Test (SUT) identification . 86
A.2.5 Product supplier . 87
A.2.6 Applicant (if different from product supplier) . 87
A.2.7 PICS contact person . 87
A.3 Identification of the protocol . 88
A.4 Global statement of conformance . 88
A.5 Roles . 88
A.6 Profiles. 88
A.7 InfoExchange . 89
A.7.1 InfoExchange protocol procedures. 89
A.7.2 InfoExchange parameters . 89
A.8 Common AckADU support. 90
A.8.1 AckADU fields . 90
A.9 Common Transactions support . 90
A.9.1 General . 90
A.9.2 USERDETAILS support . 91
A.9.3 LISTOFUSERS support . 92
A.9.4 EXCEPTIONLIST support . 94
A.9.5 TRUSTOBJECTS support . 96
A.9.6 PAYMENTCLAIM support . 97
A.10 DSRC Specific Transactions Support . 99
A.10.1 Prerequisites . 99
A.10.2 DSRC transactions support . 99
A.10.3 DSRC.CONTRACTISSUERLIST support . 99
A.10.4 DSRC.EFCCONTEXTDATA support . 100
A.10.5 DSRC.BILLINGDETAILS support . 102
A.10.6 DSRC.REPORTABNORMALOBE support . 108
A.11 GNSS Specific Transactions Support . 109
A.11.1 General . 109
A.11.2 Common GNSS.BILLINGDETAILS support . 110
A.11.3 GNSS.BILLINGDETAILS.TSP support . 113
A.11.4 GNSS.BILLINGDETAILS.TC support . 114
A.11.5 GNSS.TOLLDECLARATION support . 115
A.11.6 GNSS.PAYMENTANNOUNCEMENT support . 118
A.12 Transfer mechanisms . 119
Annex B (normative) Interoperability Statement Proforma . 120
B.1 Guidance for completing the Interoperability Statement proforma . 120
B.2 Interoperablilty Statement for transaction support . 120
B.3 Interoperability Statement for the USERDETAILS transaction type . 121
B.4 Interoperability Statement for the LISTOFUSERS transaction type . 121
B.5 Interoperability Statement for the EXCEPTIONLIST transaction type . 122
B.6 Interoperability Statement for the TRUSTOBJECTS transaction type . 123
B.7 Interoperability Statement for the PAYMENTCLAIM transaction type . 124
B.8 Interoperability Statement for the DSRC.CONTRACTISSUERLIST transaction type . 124
B.9 Interoperability Statement for the DSRC.EFCCONTEXTDATA transaction type. 124
B.10 Interoperability Statement for the DSRC.BILLINGDETAILS transaction type . 125
B.11 Interoperability Statement for the DSRC.REPORTABNORMALOBE transaction type . 125
B.12 Interoperability Statement for the GNSS.TOLLDECLARATIONS transaction type. 125
B.13 Interoperability Statement for the GNSS.BILLINGDETAILS.TSP transaction type . 126
B.14 Interoperability Statement for the GNSS.BILLINGDETAILS.TC transaction type . 126
B.15 Interoperability Statement for the GNSS.PAYMENTANNOUNCEMENT transaction type . 127
Annex C (normative) Web service definition (WSDL) . 128
Annex D (informative) Use of this Technical Specification for the EETS . 129
D.1 General . 129
D.2 Overall relationship between European standardization and the EETS . 129
D.3 European standardization work supporting the EETS . 129
D.4 Correspondence between this Technical Specification and the EETS . 130
Annex E (informative) How to read UML class diagrams in this Technical Specification . 131
E.1 General . 131
E.2 Relation of ASN.1 code and UML class diagrams . 131
E.3 Relation of UML class diagrams for the base standard and the profile . 133
Bibliography . 135

European foreword
This document (CEN/TS 16986:2016) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, the secretariat of which is held by NEN.
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 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 organisations of the
following countries are bound to announce this Technical Specification: 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.
Introduction
The Standard on information exchange between service provision and toll charging (i.e.
EN ISO 12855:2015) is a so-called toolbox standard. That means that it provides a large number of
options that can be used to support various needs of toll chargers and toll service providers. As such, it
provides useful but not sufficient support to ensure technical interoperability.
The aim of this Technical Specification is to produce a profile specification that provides technical
interoperability to support the EFC information exchange between toll service providers (TSPs) and toll
chargers (TCs):
— based on DSRC;
— based on GNSS/CN – autonomous systems.
This Technical Specification covers the definition of interoperable application profiles (IAP) applicable
for the use of EN ISO 12855:2015. These profiles define a specific coherent set of transactions, triggers,
conditions, data elements, transfer mechanisms and supporting functions for an interoperable exchange
of data between the central equipment of TCs and TSPs (in Europe).
This IAP defines profiles using the concept of “International Standardised Profiles (ISP)”, as defined in
ISO/IEC TR 10000-1. The ISP-concept is specifically suited for defining interoperability specifications
where a set of base standards can be used in different ways. This is exactly the case for
EN ISO 12855:2015, where the base standard allows for different choices that are not interoperable.
The principles of the ISP-concept can be summarized as follows:
— an ISP will make references only to base standards or other ISPs;
— the profile will restrict the choice of base standard options to the extent necessary to maximize the
probability of interoperability (e.g. chosen classes, conforming subsets, options and parameter
values of base standards);
— the ISP will not copy content of the base standards (in order to avoid consistency problems with the
base standards);
— the profile will not specify any requirements that would contradict or cause non-conformance to
the base standards;
— the profile may contain conformance requirements that are more specific and limited in scope than
those of the base standards;
— conformance to a profile implies by definition conformance to a set of base standards, whereas
conformance to that set of base standards does not necessarily imply conformance to the profile.
This Technical Specification is consistent with and is intended to provide support for the technical
specification of the EETS laid down in the European Directive 2004/52/EC and in the subsequent
European Commission Decision 2009/750/EC.
A suite of test specifications is currently being developed to support assessment of an implementation
for compliance with this Technical Specification.
1 Scope
This Technical Specification defines an application interface definition by selecting suitable options
from the base standard EN ISO 12855:2015. Furthermore, it defines transfer mechanisms and
supporting functions to ensure the interoperability between TCs and TSPs.
This Technical Specification covers:
— exchange of information between the central equipment associated with the two roles service
provision and toll charging, e.g.:
— charging related data (exception lists, toll declarations, billing details, payment claims);
— administrative data (trust objects, EFC context data, contact details for enforcement, etc.);
— confirmation data.
— transfer mechanisms and supporting functions;
— semantics of data elements;
— implementation conformance statement proforma (Annex A), as a basis for assessment of
conformity to this Technical Specification;
— an Interoperability statement proforma (Annex B), as a basis for assessment of transactional
intereoperability of two technical implementations;
— a web service definition (Annex C) for the use of web services as communication technology.
The implementation of the underlying back office systems and their business processes is not covered.
Therefore, outside of the scope is in particular:
— details on how to achieve security using the authenticator data elements of the base standards;
— how to operate compliance checking and the enforcement process;
— commercial aspects;
— definition of non-functional features such as performance indicators like accuracy, availability and
reporting requirements.
This Technical Specification further provides an assessment of support of the EETS (Annex D) and an
explanation how to read the unified modelling language (UML) diagrams (Annex E) that are used in this
document.
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.
EN ISO 12855:2015, Electronic fee collection — Information exchange between service provision and toll
charging
IETF RC 959, File Transfer Protocol [Oct 1985]
IETF RFC 4217, Securing FTP with TLS [Oct 2015]
1)
WSDL 1.1, Web Services Description Language (WSDL) 1.1

1) http://www.w3.org/TR/2001/NOTE-wsdl-20010315 [15.03.2001]
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
attribute
addressable package of data consisting of a single data element or structured sequences of data
elements
[SOURCE: EN ISO 17575-1:2016, 3.2]
3.2
authentication
security mechanism allowing verification of the provided identity
[SOURCE: ETSI EN 301 175]
3.3
authenticator
data, possibly encrypted, that is used for authentication
[SOURCE: EN 15509:2014, 3.3]
3.4
availability
property of being accessible and useable upon demand by an authorized entity
[SOURCE: CEN ISO/TS 19299:2015, 3.6]
3.5
base standard
approved international standard, technical specification or ITU-T Recommendation
[SOURCE: ISO/IEC TR 10000-1:1998, 3.1.1, modified]
3.6
billing detail
information needed to determine or verify the amount due for the usage of a given service
[SOURCE: EN ISO 12855:2015, 3.1]
3.7
channel
information transfer path
[SOURCE: ISO 7498-2:1989, 3.3.13]
3.8
charge object
geographic or road related object for the use of which a charge is applied
[SOURCE: EN ISO 17575-1:2016, 3.5]
3.9
charge report
information containing road usage and related information originated at the Front End
[SOURCE: EN ISO 17575-1:2016, 3.6]
3.10
charging data
relevant data on the usage of a certain service
[SOURCE: EN ISO 12855:2015, 3.4]
3.11
conformance testing
assessment to determine whether an implementation complies with the requirements
3.12
context data
information defined by the responsible toll charger necessary to establish the toll due for using a
vehicle on a particular toll context and to conclude the toll transaction
3.13
data element
coded information, which might itself consist of lower level information structures
[SOURCE: EN ISO 17575-1:2016, 3.9]
3.14
electronic fee collection
fee collection by electronic means
[SOURCE: EN ISO 12855:2015, 3.6]
3.15
enforcement
measures or actions performed to achieve compliance with laws, regulations or rules
[SOURCE: CEN ISO/TS 19299:2015, 3.15]
3.16
evaluation
systematic process of determining how individuals, procedures, systems or programs have met
formally agreed objectives and requirements
[SOURCE: ISO 10795:2011, 1.90]
3.17
Front End
part of a tolling system consisting of OBE and possibly a proxy where tolling information and usage data
are collected and processed for delivery to the Back End
[SOURCE: CEN ISO/TS 19299:2015, 3.20]
3.18
implementation conformance statement
statement of capabilities and options that have been implemented defining to what extent the
implementation is compliant with a given specification
[SOURCE: CEN ISO/TS 14907-2:2016, 3.6]
3.19
implementation under test
implementation of one or more open systems interconnection (OSI) protocols in an adjacent
user/provider relationship, being part of a real system which is to be studied by testing
3.20
international standardised profile
internationally agreed-to, harmonised document which describes one or more profiles
[SOURCE: ISO/IEC TR 10000-1:1998, 3.1.2]
3.21
interoperability
ability of systems to exchange information and to make mutual use of the information that has been
exchanged
[SOURCE: ISO/IEC TR 10000-1:1998, 3.2.1 modified]
3.22
issuer
entity responsible for issuing the payment means to the user
[SOURCE: ISO/TS 16785:2014, 3.9]
3.23
on-board equipment
all required equipment on-board a vehicle for performing required EFC functions and communication
services
3.24
payment claim
recurring statement referring to concluded billing details made available to the payer by the payee
indicating and justifying the amount due
[SOURCE: EN ISO 12855:2015, 3.10]
3.25
profile
set of requirements and selected options from base standards or international standardized profiles
used to provide a specific functionality
[SOURCE: ISO/IEC TR 10000-1:1998, 3.1.4 modified]
3.26
role
set of responsibilities
[SOURCE: ISO 17573:2010, 3.13]
3.27
system under test
real system in which the implementation under test resides
[SOURCE: ISO/IEC 9646-1:1996, 3.3.103 modified]
3.28
test
procedure designed to measure characteristics of a component or system in specified conditions
[SOURCE: CEN ISO/TS 14907-1:2015; 3.20]
3.29
toll
charge, tax or duty levied in connection to using a vehicle in a toll domain
[SOURCE: CEN ISO/TS 19299:2015, 3.42 modified]
3.30
toll charger
entity which levies toll for the use of vehicles in a toll domain
[SOURCE: ISO 17573:2010, 3.16 modified]
3.31
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
[SOURCE: EN ISO 17575-1:2016, 3.17]
3.32
toll declaration
statement to declare the usage of a given toll service to a toll charger
[SOURCE: ISO 17573:2010, 3.17 modified]
3.33
toll domain
area or a part of a road network where a certain toll regime is applied
[SOURCE: ISO 17573:2010, 3.18 modified]
3.34
toll regime
set of rules, including enforcement rules, governing the collection of toll in a toll domain
[SOURCE: ISO 17573:2010, 3.20]
3.35
toll scheme
organizational view of a toll regime, including the actors and their relationships
[SOURCE: EN ISO 17575-3:2016, 3.22]
3.36
toll service provider
entity providing toll services in one or more toll domains
[SOURCE: ISO 17573:2010, 3.23 modified]
3.37
transaction
whole of the exchange of information between two physically separated communication facilities
[SOURCE: EN ISO 17575-1:2016, 3.21]
3.38
transaction type
identifier of a set of transactions that adhere to the same rules for the exchanged application protocol
data units in terms of triggers, timings, content and sequence
3.39
trust object
information object that is exchanged between entities to ensure mutual trust
[SOURCE: ISO 17573:2010, 3.28]
4 Abbreviations
For the purposes of this document, the following abbreviations apply throughout the document unless
otherwise specified.
ADU Application Data Unit (EN ISO 14906)
APCI Application Protocol Control Information (EN ISO 12855)
APDU Application Protocol Data Unit (EN ISO 14906)
CCC Compliance Check Communication (EN ISO 12813)
CN Cellular Network(s)
CRL Certificate Revocation List
DSRC Dedicated Short-Range Communication (EN ISO 14906)
EETS European Electronic Toll Service
EFC Electronic Fee Collection (ISO 17573)
FE Front End
FTP File Transfer Protocol
GNSS Global Navigation Satellite System
IAP Interopability Application Profile (EN 15509)
IP Internet Protocol
IUT Implementation Under Test (CEN ISO/TS 14907-1)
MAC Message Authentication Code (EN ISO 14906)
LAC Localization Augmentation Communication (EN ISO 13141)
LPN License Plate Number (EN ISO 12855)
OBE On-Board Equipment (EN ISO 14906)
OSI Open Systems Interconnection
PAN Personal Account Number (EN ISO 14906)
PICS Protocol Implementation Conformance Statement (EN 15876–1)
RSE Roadside Equipment (EN ISO 14906)
SOAP Simple Object Access Protocol
SU Service User
SUT System Under Test (CEN ISO/TS 14907-1)
TC toll charger (EN ISO 12855)
TCP Transmission Control Protocol
TSP toll service provider (EN ISO 12855)
UML Unified Modelling Language (ISO 17573)
VPN Virtual Private Network
XER XML Encoding Rules
5 Conformance
5.1 General
This clause describes the two profiles that are defined by this Technical Specification and the respective
conformance requirements for toll chargers and toll service providers.
5.2 Base standard
This Technical Specification relies on EN ISO 12855:2015 as its base standard. It limits or restricts
options and ranges of data types defined in the base standard. It may even limit ranges of data types
imported into the base standard from other standards. These limitations are defined in the clauses for
the common transactions and the contained profiles.
The syntax of an InfoExchange application protocol data unit (APDU) shall be according to the ASN.1
definitions of the ASN.1 code in EN ISO 12855:2015 with the limitations and semantics relevant for the
profile(s) to which conformance is claimed, as defined in 5.4.
5.3 Main contents of an 12855-IAP
The rules for exchanging individual application data units (ADUs) are defined by the corresponding
transaction types.
A profile of this Technical Specification consists of:
— the list of transaction types that shall be supported (see Table 1);
— the transaction type definitions, including triggers and timings (see 5.4.4);
— restrictions to data elements from the base standard;
— requirements on transfer mechanisms (see Clause 9).
Two profiles are defined:
1. Profile for information exchange for DRSC-based EFC (DSRC) – intended for all DSRC-based
systems (closed or open).
2. Profile for information exchange for GNSS-based systems – intended for GNSS-based systems.
Allows for both TC and TSP to be responsible for the generation and sending of toll declarations,
billing details and payment announcements or payment claims.
Toll chargers shall select one of the profiles which supports their EFC system. toll service providers
shall support all profiles that are selected by the toll chargers with whom the toll service provider has a
contract with.
5.4 Conformance requirements
5.4.1 General requirements
To be compliant to the DSRC profile, the implementation shall fulfil the requirements of the following
clauses:
— Clause 6 “Requirements on common transactions”;
— Clause 7 “DSRC profile specific transactions”;
— Clause 9 “APDU Transfer mechanisms”.
To be compliant to the GNSS profile, the implementation shall fulfil the requirements of the following
clauses:
— Clause 6 “Requirements on common transactions”;
— Clause 8 “GNSS profile specific transactions”;
— Clause 9 “APDU Transfer mechanisms”.
5.4.2 Transaction requirements
The back office data exchange between toll chargers and toll service providers is complex and many
local requirements need to be respected. These are often driven by legal requirements and cannot be
changed easily. The defined profiles in this Technical Specifications restrict options provided by the
base standard in order to reach interoperability, whilst recognizing the need for bilateral agreements
between toll chargers and toll service providers.
Supported transactions are defined in Table 1 with the shorthand “M”, “O” and “-” having the following
meaning:
M “Mandatory”: Shall be supported according to the provisions of the respective profile in order to
claim conformance unless the implementer is the initiator of that transaction type (or part of
transaction type in case of multiple transaction type triggers) and never intends to initiate a
transaction of this type, in which case the implementers support of the transaction type (or part
of transaction type) may be omitted.
O “Optional”: Support is not required in order to claim conformance. May be required by the toll
charger (after selection of the applicable profile) in order for other TSPs to claim
interoperability (see Clause 5.5 and Clause 5.6), in that case to be implemented according to the
provisions of the profile.
- Out of scope of the IAP. May be used upon bilateral agreements
After selection of the applicable profile (see 5.3), toll chargers need to decide which optional transaction
types (O) shall be supported and inform toll service providers about this selection. This is supported by
the interoperability statement in Annex B. Each TC and TSP who claim conformance to one or more
profiles of this Technical Specification shall state all their supported ADUs in the interoperability
statement in Annex B, together with their timing requirements.
The AckADU shall be supported for every transaction. The RequestADU shall be supported as indicated
for each transaction in the clauses “Transaction flow, triggers and timings”.
NOTE The StatusADU is not in scope of the profiles but can be used if specified in bilateral agreements.
Table 1 — EN ISO 12855 ADU support and corresponding transaction types
ADU (EN ISO 12855) Transaction type DSRC GNSS
(support, (support,
defining defining
clause) clause)
ProvideUserDetailsADU USERDETAILS M (6.4) M (6.4)
ProvideUserIdListADU LISTOFUSERS O (6.5) O (6.5)
a
ExceptionListADU EXCEPTIONLIST M (6.6) M (6.6)
b,c
TrustObjectADU TRUSTOBJECTS M (6.7) M (6.7)
PaymentClaimADU PAYMENTCLAIM O (6.8) O (6.8)
ContractIssuerListADU CONTRACTISSUERLIST O (7.1) -
EfcContextDataADU EFCCONTEXTDATA M (7.2) -
BillingDetailsADU BILLINGDETAILS M (7.3) O (8.2)
ReportAbnormalOBEADU REPORTABNORMALOBE O (7.4) -
TollDeclarationADU TOLLDECLARATION - M (8.1)
PaymentAnnouncementADU PAYMENTANNOUNCEMENT - O (8.3)
ReportCCCEventADU  - -
ReportQAADU  - -
a
In the ExceptionListADU, only black, white, and discounted user lists are allowed according to
definitions in 6.6.2.1.
b
In the TrustObjectADU, for DSRC, the exchange of Masterkeys is mandatory. For GNSS, the exchange of
LAC and CCC keys is mandatory. The exchange of certificates, CRLs and public keys is optional according to
...