SIST EN 15509:2023

SLOVENSKI STANDARD
01-julij-2023
Nadomešča:
SIST EN 15509:2014
Elektronsko pobiranje pristojbin - Interoperabilnost profila aplikacije za DSRC
Electronic fee collection - Interoperability application profile for DSRC
Elektronische Gebührenerhebung - Anwendungsprofil für DSRC Interoperabilität
Perception de télépéage - Profil d'application d'interopérabilité pour DSRC
Ta slovenski standard je istoveten z: EN 15509:2023
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 15509
EUROPEAN STANDARD
NORME EUROPÉENNE
March 2023
EUROPÄISCHE NORM
ICS 35.240.60 Supersedes EN 15509:2014
English Version
Electronic fee collection - Interoperability application
profile for DSRC
Perception de télépéage - Profil d'application Elektronische Gebührenerhebung - Anwendungsprofil
d'interopérabilité pour DSRC für DSRC Interoperabilität
This European Standard was approved by CEN on 30 January 2023.

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, Türkiye 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
© 2023 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 15509:2023 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
Introduction . 4
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 7
4 Symbols and abbreviations . 10
5 Conformance . 12
5.1 General . 12
5.2 Base standards . 12
5.3 Main contents of an EFC-DSRC-IAP . 14
5.4 Conformance requirements . 15
5.5 Conformation notification . 15
5.6 Conformance evaluation and testing . 15
5.7 Multiple IAPs . 15
6 Requirements for EFC-DSRC-IAP-1 . 15
6.1 OBU requirements . 15
6.1.1 General . 15
6.1.2 DSRC requirements . 15
6.1.3 DSRC L7 and EFC functions . 16
6.1.4 Data requirements . 16
6.1.5 Security requirements . 18
6.1.6 Transaction requirements . 20
6.2 RSE requirements . 20
6.2.1 General . 20
6.2.2 DSRC requirements . 20
6.2.3 DSRC L7 and EFC functions . 20
6.2.4 Data requirements . 20
6.2.5 Security requirements . 20
6.2.6 Transaction requirements . 21
Annex A (normative) EFC data specification . 22
Annex B (normative) Implementation conformance statement proforma . 28
Annex C (informative) IAP taxonomy and numbering . 45
Annex D (informative) Security considerations . 47
Annex E (informative) Interlayer management . 48
Annex F (informative) Mounting guidelines for the OBU . 54
Annex G (informative) Use of this standard for the EETS . 58
Bibliography . 60
European foreword
This document (EN 15509:2023) has been prepared by 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 September 2023, and conflicting national standards
shall be withdrawn at the latest by September 2023.
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 15509:2014.
The main changes compared to the previous edition are as follows:
— updated data definitions to reflect changes made to the underlying base standards, notably in
EN ISO 14906, whilst seeking to ensure backward compatibility with previous editions of this
document;
— use of imported ASN.1 types with successors (i.e. including all future minor versions);
— updated terms, to take into account the harmonized terms across electronic fee collection
standards, as specified in ISO/TS 17573-2;
— deletion of the normative annex on “Security calculations”, which has been moved to EN ISO 14906;
— updated informative Annex G on the “Use of this document for the European electronic toll service”
[21]
(EETS), to reflect the recast of the EETS legislation (i.e. Directive (EU) 2019/520 and the
[22] [23]
corresponding Commission Delegated and Implementing Regulations ).
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organisations 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, Türkiye and the
United Kingdom.
Introduction
CEN/TC 278 has produced a set of standards that supports interoperable dedicated short-range
communication (DSRC)-based electronic fee collection (EFC) systems (e.g. EN ISO 14906, a “toolbox” for
definition of EFC-DSRC transactions). However, these standards provide necessary but not sufficient
support for technical interoperability between EFC-DSRC-systems.
This document specifies an Interoperable Application Profile (IAP) to support EFC-DSRC transactions,
with a coherent set of requirements. The main objective is to support technical interoperability
between EFC-systems within the scope of this document (as described in Clause 1). A basic description
of the EFC-service and an EFC System can be found in EN ISO 17573-1.
This document specifies a basic level of technical interoperability for EFC equipment, i.e. on-board unit
(OBU) and roadside equipment (RSE) using DSRC. It does not provide a full solution for interoperability,
nor does it specify other parts of the EFC-system, other services, other technologies and non-technical
elements of interoperability.
The elaboration of this document is based on the experiences from a considerable number of
implementations and projects throughout Europe. This document makes use of the results from
European projects such as CARDME, PISTA and CESARE, as they represent fruits of European EFC
harmonization and have been used as the basis for several national implementations.
The development of a common European electronic toll service (EETS) as a part of the European
[19]
Directive (2004/52/EC ) also calls for the definition of an interoperable EFC-service. The first edition
of this document was referenced as a mandatory element in the service definition of the EETS, in the EC
[20]
decision 2009/750/EC .
The revision of the EETS legislation (recast in EU legal parlance) resulted in the adoption of Directive
[21]
2019/520/EC on the interoperability of electronic road tolling systems and facilitating cross-border
exchange of information on the failure to pay road fees in the Union, which refers to the second edition of
this document (EN 15509:2014) as a mandatory element for the EETS. Further technical and
procedural characteristics of the EETS were laid down in the associated Commission Delegated
[22] [23]
Regulation (EU) 2020/203 and Commission Implementing Regulation (EU) 2020/204 .
Although there are standards and specifications, there are specific needs that motivate this document:
— Definition of the necessary and sufficient EFC-DSRC requirements to underpin technical
interoperability;
— Choice of data elements including vehicle data;
— Extended definition of the use of some data elements, including semantics and coding;
— Choice of security measures;
— It facilitates a complementing test specification with clear relations between the conformance
requirements and evaluation tests;
— The provisions laid down in Directive 2019/520/EC and the associated Commission Regulations;
— Support for procurements.
The Application Profile is described using the concept of “International Standardized Profiles (ISP)” as
[15]
specified 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 in
EFC, where a set of base standards allows for different choices that are not interoperable.
The principles of the ISP-concept can be summarized as follows:
— An ISP makes references only to base standards or other ISPs;
— The profile restricts 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 does not copy content of the base standards to ensure consistency with the base standards;
— The profile does 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 conformance to a set of base standards, whereas conformance to
that set of base standards does not necessarily imply conformance to the profile.
The use of the Application Profiling concept also provides for a flexible framework towards adoption,
migration and use of this document. Toll Chargers (TCs), Toll Service Providers (TSPs) and
Manufacturers may use this IAP as a basis for interoperable use of their equipment, without having to
interfere with or otherwise affect any EFC-system used locally.
The general requirements of this document are set out in Clause 5, whilst the specific conformance
requirements are given in Clause 6. For ease of referencing, testing and look-up, these specific
requirements are divided into two parts; on-board unit (OBU) requirements and roadside equipment
(RSE) requirements.
For future use, it is envisaged that other IAPs may be defined using the same structure as is defined in
Clause 6. Annex C contains IAP taxonomy and numbering.
In addition, this document includes various annexes that provide further detailed specifications as well
as background, motivation and examples for the conformance requirements. These are intended to
enhance the readability and understanding of the document.
This document is complemented by standard EN 15876 that specifies how to evaluate on-board and
roadside equipment for conformity to EN 15509 (this document).
1 Scope
The scope of this document is limited to:
— payment method: central account based on EFC-DSRC;
— physical systems: on-board unit (OBU), roadside equipment (RSE) and the DSRC interface between
them (all functions and information flows related to these parts);
— DSRC-link requirements;
— EFC transactions over the DSRC interface;
— data elements to be used by OBU and RSE used in EFC-DSRC transactions;
— security mechanisms for OBU and RSE used in EFC-DSRC transactions.
It is outside the scope of this document to specify:
— contractual and procedural interoperability requirements;
— conformance procedures and test specifications;
— setting-up of operating organizations e.g. toll charger (TC), toll service provider (TSP), trusted third
party, etc.;
— other payment methods in DSRC-based EFC (e.g. on-board accounts using integrated circuit cards);
— other basic technologies (e.g. GNSS/CN or video registration-based EFC);
— non-EFC transactions over the DSRC interface (e.g. compliance check communication and
localization augmentation communication, which are specified in other standards);
— other interfaces or functions in EFC-systems than those specified above (i.e. information flows and
data exchange between operators or personalization, initialization and customization of the OBU).
NOTE Some of the issues that are outside the scope of this document are subject of separate standards
prepared by CEN/TC 278, ISO/TC 204 and ETSI ERM.
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.
EN 12834, Road transport and traffic telematics - Dedicated Short Range Communication (DSRC) - DSRC
application layer
EN 13372:2004, Road Transport and Traffic Telematics (RTTT) - Dedicated short-range communication -
Profiles for RTTT applications
EN ISO 14906:2023, Electronic fee collection - Application interface definition for dedicated short-range
communication
ETSI/TS 102 486-1-1 V1.1.1 (2006-03), Electromagnetic compatibility and Radio spectrum Matters
(ERM); Road Transport and Traffic Telematics (RTTT); Test specifications for Dedicated Short Range
Communication (DSRC) transmission equipment; Part 1: DSRC data link layer: medium access and logical
link control; Sub-Part 1: Protocol Implementation Conformance Statement (PICS) proforma specification
ETSI/TS 102 486-2-1 V1.2.1 (2008-10), Intelligent Transport Systems (ITS); Road Transport and Traffic
Telematics (RTTT); Test specifications for Dedicated Short Range Communication (DSRC) transmission
equipment; Part 2: DSRC application layer; Sub-Part 1: Protocol Implementation Conformance
Statement (PICS) proforma specification
ISO/IEC 9646-7, Information technology — Open Systems Interconnection — Conformance testing
methodology and framework — Part 7: Implementation Conformance Statements
EN ISO 17573-3:—, Electronic fee collection — System architecture for vehicle-related tolling — Part 3:
Data dictionary
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:
• IEC Electropedia: available at https://www.electropedia.org/
• ISO Online browsing platform: available at https://www.iso.org/obp
3.1
access credentials
trusted attestation or secure module that establishes the claimed identity of an object or application
[SOURCE: ISO/TS 17573-2:2020, 3.4]
3.2
attribute
addressable package of data consisting of a single data element or structured sequences of data
elements
[SOURCE: ISO/TS 17573-2:2020, 3.13]
3.3
authenticator
data, possibly encrypted, that is used for authentication
[SOURCE: ISO/TS 17573-2:2020, 3.16]

Under preparation. Stage at time of publication: ISO/DIS 17573-3:2022
3.4
base standard
approved International Standard, Technical Specification or ITU-T Recommendation
Note 1 to entry: This includes but is not limited to approved standard deliverables from ISO, ITU, CEN, CENELEC,
ETSI and IEEE
[SOURCE: ISO/TS 17573-2:2020, 3.23]
3.5
data group
class of closely related attributes (3.2)
[SOURCE: ISO/TS 17573-2:2020, 3.55]
3.6
EFC service
service for electronic payment offered by a payment service provider
[SOURCE: ISO/TS 17573-2:2020, 3.54]
3.7
Element
DSRC directory containing application information in the form of attributes (3.2)
[SOURCE: EN ISO 14906:2023, 3.8]
3.8
integrity
property that data have not been altered or destroyed in an unauthorized manner
[SOURCE: ISO/TS 17574:2009, 3.9]
3.9
international standardized profile
internationally agreed-to, harmonized document which describes one or more profiles (3.14)
[SOURCE: ISO/TS 17573-2:2020, 3.102]
3.10
interoperability
ability of systems to exchange information and to make mutual use of the information that has been
exchanged
[SOURCE: ISO/TS 17573-2:2020, 3.103]
3.11
mobile roadside equipment
equipment mounted on a mobile unit or handheld equipment to be used along the road
[SOURCE ISO/TS 17573-2:2020, 3.119]
3.12
on-board equipment
all required equipment on-board a vehicle for performing required electronic fee collection (EFC)
functions and communication services
[SOURCE: ISO/TS 17573-2:2020, 3.127, modified – Note 1 to entry has been added]
3.13
on-board unit
electronic unit on-board a vehicle for performing specific electronic fee collection (EFC) functions and
for communication with external systems
Note 1 to entry: An OBU always includes, in this context, at least the support of the DSRC interface.
[SOURCE: ISO/TS 17573-2:2020, 3.127]
3.14
profile
set of requirements and selected options from base standards (3.3) or international standardized
profiles used to provide a specific functionality
[SOURCE: ISO/TS 17573-2:2020, 3.146]
3.15
roadside equipment
fixed or movable electronic fee collection (EFC) equipment located along or on the road
Note 1 to entry: Movable RSE can be mounted temporarily along the road or in a vehicle.
[SOURCE: ISO/TS 17573-2:2020, 3.161]
3.16
session
exchange of information and interaction occurring at a specific EFC station between the roadside
equipment (3.15) and the user/vehicle
3.17
toll charger
entity which levies toll for the use of vehicles in a toll domain
[SOURCE: ISO/TS 17573-2:2020, 3.194]
3.18
toll service provider
entity providing toll services in one or more toll domains
Note 1 to entry: In other documents, the terms issuer or contract issuer may be used.
Note 2 to entry: The toll service provider may provide the OBE or may provide only a magnetic card or a smart
card to be used with OBU provided by a third party (like a mobile telephone and a SIM card can be obtained from
different parties).
Note 3 to entry: The toll service provider is responsible for the operation (functioning) of the OBE with respect to
tolling.
[SOURCE ISO/TS 17573:2020, 3.206, modified – Notes to entry have been added]
3.19
transaction
whole of the exchange of information between two physically separated communication facilities
[SOURCE: ISO/TS 17573-2:2020, 3.211]
3.20
transaction counter
data value in the on-board unit that is incremented by the roadside equipment at each transaction
(3.19)
[SOURCE: ISO/TS 17573-2:2020, 3.212]
3.21
transaction model
functional model describing the general structure of electronic payment transactions (3.19)
[SOURCE: ISO/TS 17573-2:2020, 3.213]
4 Symbols and abbreviations
For the purposes of this document, the following symbols and abbreviations apply.
AC_CR Access Credentials
ADU Application Data Unit
AP Application Process
APDU Application Protocol Data Unit
ASN.1 Abstract Syntax Notation One
AuK AuKey
BST Beacon Service Table
CCC Compliance Check Communication
DEA Data Encryption Algorithm
DES Data Encryption Standard
DSRC Dedicated Short-Range Communication
EETS European Electronic Toll Service
e [key] (value) encryption of the value using the key
ede [key] (value) chained encryption, decryption and encryption of the value using the
key
EFC Electronic Fee Collection
EID Element Identifier
GNSS Global Navigation Satellite Systems
IAP Interoperable Application Profile
ICS Implementation Conformance Statement
ISP International Standardized Profile
IUT Implementation Under Test
L1 Layer 1 of DSRC (Physical Layer)
L2 Layer 2 of DSRC (Physical Layer)
L7 Layer 7 of DSRC (Application Layer Core of DSRC)
LAC Localisation augmentation communication
LID Logical Link Control identifier
LLC Logical Link Control
LSDU Link Service Data Unit
MAC Media Access Control
MMI Man-Machine Interface
OBE On-Board Equipment
OBU On-board Unit
PICS Protocol Implementation Conformance Statement
RL Requirements List
RSE Roadside Equipment
TC Toll Charger
TSP Toll Service Provider
T-APDU Transfer-Application Protocol Data Unit
VST Vehicle Service Table
5 Conformance
5.1 General
This clause describes in general terms what it means for an implementation to be in conformity with
the profile in this document applicable to the DSRC link between OBU and RSE, as illustrated in
Figure 1 as the area within the box delimited with a dotted line.

Figure 1 — Scope of this document
5.2 Base standards
This document specifies one Application Profile based on the ISP-concept. It is based on the following
base standards:
— EN ISO 14906 on EFC application interface definition for DSRC
NOTE 1 This implies an indirect reference to EN ISO 14816 on “Numbering and data structure”.
— EN 12834 on DSRC application layer (L7),
— EN 13372 on DSRC profiles
NOTE 2 This implies indirect references to EN 12253 (“DSRC L1”), EN 12795 (“DSRC L2”) and EN 12834
(“DSRC L7”).
The relationship and references between base standards and this document are illustrated in Figure 2.
Figure 2 — Relationship and references between base standards and this document
All requirements specified in this document are either choices made from these base standards or are
more specific requirements based on the general provisions of these standards.
The organization of the DSRC-stack and the link with the profile are illustrated in Figure 3.
NOTE The abbreviated terms used in Figure 3 are defined in Clause 4.
Figure 3 — DSRC-stack elements
5.3 Main contents of an EFC-DSRC-IAP
The conformance requirements of an interoperable application profile (IAP) are divided between
requirements for the OBU and the RSE. The requirements are listed separately for OBU and RSE. This
applies for all parts; requirements, protocol implementation conformance statement (PICS) and
conformance testing.
The conformance requirements of an IAP according to this document include the following parts
(divided into separate requirements for OBU and RSE):
— DSRC requirements;
— DSRC L7 and EFC functions;
— data requirements;
— security requirements;
— transaction requirements.
5.4 Conformance requirements
Conformance requirements are specified in Clause 6, supplemented by Annex A.
NOTE Conformance requirements are deliberately expressed concisely, to provide clear and verifiable
requirements. For motivations, explanations, etc., see the supporting parts of this document (Foreword,
Introduction, the informative Annexes C-G).
5.5 Conformation notification
A statement of conformance to a specific IAP shall be done according to the ICS proforma requirements
specified in Annex B.
5.6 Conformance evaluation and testing
Conformance evaluation and testing shall be done according to provisions laid down in EN 15876.
NOTE The use of EN 15876 implies the use of other underlying test standards for evaluation of conformance
to this document.
5.7 Multiple IAPs
This standard specifies one profile (EFC-DSRC-IAP-1) as laid down in the clause for conformance
requirements (Clause 6).
NOTE For future use, it is envisaged that other IAPs may be specified using the same structure as used in
Clause 6. A taxonomy for EFC-DSRC-IAPs is contained in Annex C.
6 Requirements for EFC-DSRC-IAP-1
6.1 OBU requirements
6.1.1 General
6.1 contains the conformance requirements on the OBU for profile number 1; EFC-DSRC-IAP-1.
6.1.2 DSRC requirements
The OBU shall comply with:
— DSRC Profiles P0 / P1 L1-B according to EN 13372, or
— DSRC Profiles P0 / P1 L1-A according to EN 13372 with a Conversion Gain which is limited to a
maximum value of 10 dB (Parameter U12b = 10 dB) and a Cut-off power level of minimum -
60 dBm (Parameter D12 = - 60 dBm).
NOTE 1 This implies indirect references to and OBU’s compliance with the underlying DSRC-standards for L1,
L2 and L7 [EN 12253, EN 12795 and EN 12834].
The following DSRC-L7 features according to EN 12834 shall be supported by the OBU:
— the length of a single Transfer-Application Protocol Data Unit (T-APDU) or multiple concatenated
T-APDUs, with or without chaining, shall not exceed the maximum logical link control (LLC) frame
length (i.e. fit into one DSRC L2 frame);
— The maximum LLC frame lengths are defined in EN 12795:2003, Annex A “Data link layer
parameters”; 128 octets in a downlink window frame or in a private uplink window frame.
NOTE 2 The requirement above implies that the fragmentation header is limited to 1 octet only.
— any “fill bit” (as specified 6.3.4 in EN L7), used for octet alignment, shall be assigned the value zero.
Annex E provides a set of guidelines on how Interlayer Management should be performed.
Annex F provides a set of guidelines on how OBU mounting should be performed.
6.1.3 DSRC L7 and EFC functions
The OBU shall support the DSRC Layer 7 services and EFC functions, defined in EN 12834 and
EN ISO 14906:2023, 7.1.2, in Table 1.
Table 1 — Overview of DSRC L7 and EFC functions
DSRC-L7 EFC function Action/Event Remarks
services type
INITIALISATION N/A N/A Establishes communication, selects the application
and contract
ACTION GET_STAMPED 0 Retrieves data with an authenticator from the OBU,
with or without AC-CR
GET N/A N/A Retrieves data from the OBU, with or without AC-
CR
SET N/A N/A Writes data to the OBU, with or without AC-CR
ACTION SET_MMI 10 Invokes an MMI function (e.g. signal “OK” via
buzzer). All SetMMIRq values (i.e. 0, 1, 2 and 255)
specified in EN ISO, 14906:2023, Annex A shall be
supported
ACTION ECHO 15 OBU echoes received data
EVENT-REPORT RELEASE 0 Terminates communication
6.1.4 Data requirements
The addressing of the EFC system and application data shall conform to the rules specified in
EN ISO 14906:2023, Clause 5.3.
The EFC attributes in Table 2, specified in EN ISO 14906:2023 and in EN 12834, shall be implemented in
the OBU.
Table 2 — Overview of the OBU EFC application data
a b b
AttrId Type Length Read Write Remarks
DATA GROUP /
(octets)
Attribute (EID > 0)
APPLICATION CONTEXT      This attribute is specified in EN 12834.
ApplicationContextMark N/A N/A 6 or 16 Yes No An octet string that is sent from the OBU in
the Initialization phase (vehicle service
table, VST) that contains the identification
of a specific DSRC application context. For
EFC, the first 6 octets of the
ApplicationContextMark contain the
EfcContextMark. Length varies between
security levels (see Table A.1 for details).
CONTRACT      Information associated with the service
rights of the TSP.
EfcContextMark 0 32 6 Yes No According to EN ISO 14906:2023, it
contains the ContractProvider and is
transmitted as part of the VST.
PAYMENT      Data associated with the Payment
transaction.
PaymentMeans (including 32 64 14 Yes No According to EN ISO 14906:2023, it
PAN) includes:
- the PersonalAccountNumber (PAN),
including the Payment Means Issuer.
- the PAN Expiry Date
- the PaymentMeansUsageControl
VEHICLE      Information pertaining to the
identification and characteristics of the
vehicle.
VehicleLicencePlateNumber 16 47 13 to 17 Yes No More specific and limited in scope than in
EN ISO 14906 (see Table A.2 for details).
VehicleClass 17 49 1 Yes No More specific and limited in scope than in
EN ISO 14906 (see Table A.2 for details).
VehicleDimensions 18 50 3 Yes No According to EN ISOS 14906:2023.
VehicleAxles 19 51 2 Yes No According to EN ISO 14906:2023.
VehicleWeightLimits 20 52 6 Yes No According to EN ISO 14906:2023.
VehicleSpecificCharacteristics 22 54 4 Yes No According to EN ISO 14906:2023.
a b b
AttrId Type Length Read Write Remarks
DATA GROUP /
(octets)
Attribute (EID > 0)
EQUIPMENT      Information pertaining to the OBU.
EquipmentOBUId 24 56 5 (=1+4) Yes No According to EN ISO 14906:2023: Coded as
an octet string with a length
determinant = 4.
EquipmentStatus (transaction 26 58 2 Yes Yes More specific and limited in scope than in
counter) EN ISO 14906:2023 (see Annex A,
Table A.3 for details).
RECEIPT      Information associated with a specific
session, including both financial and
operational data.
ReceiptData1 (last) 33 65 28 Yes Yes According to EN ISO 14906:2023.
ReceiptData2 (penultimate) 34 66 28 Yes Yes According to EN ISO 14906:2023.
a
Including the length determinant as specified in ISO/IEC 8825-2 (packed encoding rules for ASN.1 is used in EN ISO 14906).
In case of discrepancies between the Type and the Length and the ASN.1 module, the ASN.1 module specified in A.2 shall take
precedence.
b
The read and write columns denotes read and write operations in an EFC DSRC transaction (no other possible situations
like e.g. personalization of an OBE).
EFC attribute requirements that restrict choices or are more specific and limited in scope than those of
EN ISO 14906 can be found in Annex A.
Only Latin alphabet (LatinAlphabetNo1) is applicable in context of this document for the encoding of
licence plate numbers (see Table A.2 for details) in the OBU. Non-Latin characters from
LatinAlphabetNo2, LatinCyrillicAlphabet, LatinGreekAlphabet and LatinAlphabetNo10 shall be mapped
to LatinAlphabetNo1 lower case characters by applying the mapping table as specified in
EN ISO 14906:2023, Table D.1 when the corresponding characters of the licence plate number are
entered into the OBU.
EN ISO 14906:2023, Annex E shall apply compulsory in the context of this document, i.e. the
correspondence between elements available inside the European registration certificate and the
vehicle-related data elements as specified in this document.
[18]
NOTE 1 The European registration certificate is specified by Commission Directive 2003/127/EC .
NOTE 2 The TSP personalizes the OBU with the corresponding vehicle-related data.
6.1.5 Security requirements
6.1.5.1 General
This document specifies security features and mechanisms based on the security framework specified
in EN ISO 19299.
EFC-DSRC-IAP-1 in this document allows for implementation of two different levels of security (0,1).
Security level 0 shall be supported whereas level 1 can be implemented on an optional basis.
NOTE See Annex D for further details and explanations.
An OBU may have several EFC elements with different security levels.
6.1.5.2 Security level 0 requirements
The security-related data elements listed in Table 3 shall be implemented in the OBU:
Table 3 — Overview of the OBU security related data
Name Length (octets) Remarks
AuthenticationKey1 8 Private
AuthenticationKey2 8 Private
AuthenticationKey3 8 Private
AuthenticationKey4 8 Private
AuthenticationKey5 8 Private
AuthenticationKey6 8 Private
AuthenticationKey7 8 Private
AuthenticationKey8 8 Private
KeyRef 1 Reference to AuKey used for the computation of the Authenticators,
e.g. TSP and TC Authenticators. The TSP decides which keys are
shared with TCs (referenced through AuKey_Op), and which are
only known by himself (referenced through AuKey_Iss).
RndRSE 4 Random number, containing SessionTime, from RSE used for the
computation of Authenticator.
The OBU shall be able to calculate an Authenticator (i.e. support the GET_STAMPED function operating
on one attribute list considering that the response shall fit into one DSRC Layer 2 frame) to validate
data integrity and origin of the application data. These calculations shall be performed according to EN
ISO 14906:2023, Annex F.2.
NOTE The OBU also supports (through the data stored in the OBU) other security features such as the
TransactionCounter (see 6.2.5.2) and signed receipt that are performed at the RSE or in the central system.
6.1.5.3 Security level 1 requirements
The OBU shall support the security level 0 requirements as specified in 6.1.5.2.
The OBU shall support calculation of Access Credentials for protection of user related data on the OBU.
These calculations shall be performed according to EN ISO 14906:2023, Annex F.3.
This requires the additional security data elements, in Table 4, to be implemented in the OBU.
Table 4 — OBU security related data for handling of Access Credentials
Name Length (octets) Remarks
AccessKey 8 Private.
AC_CR 4 Access credentials calculated by the RSE and the OBU using
RndOBU and the Access Key AC_CRKey.
AC_CR-KeyReference 2 Reference to the key generation and the Diversifier for the
computation of AC_CRKey.
RndOBU 4 Random number (nonce) used together with AccessKey (referenced
through AC_CR-KeyReference) to calculate the Access credentials.
NOTE An RSE that has only implemented the security requirements associated with level 0 in this document
(as in 6.2.5.2) is not able to access OBU data protected by means of access credentials.
6.1.6 Transaction requirements
An OBU compliant with this document shall be able to perform an EFC transaction model as specified in
EN ISO 14906:2023, Clause 6.
NOTE EN ISO 14906:2023, Annex B provides an informative example of a transaction by detailing the
CARDME transaction.
6.2 RSE requirements
6.2.1 General
6.2 contains the conformance requirements on the RSE for profile number 1; EFC-DSRC-IAP-1.
6.2.2 DSRC requirements
The RSE shall support any OBU complying with 6.1.2.
NOTE 1 This implies indirect references to and RSE’s compliance with the DSRC-standards for Profiles, L1, L2
and L7 [EN 13372, EN 12253, EN 12795 and EN 12834].
NOTE 2 This implies indirect references to and mobile RSE’s compliance with the DSRC-standards for Profiles,
L1, L2 and L7 [EN 13372, EN 12253, EN 12795 and EN 12834], except for Downlink Parameter D4a (which is not
applicable to mobile RSE).
6.2.3 DSRC L7 and EFC functions
The RSE shall support the DSRC Layer 7 services and EFC functions as specified in 6.1.3.
6.2.4 Data requirements
The RSE shall support any OBU complying with 6.1.4.
There are no specific data requirements for the RSE, other than the possibility to retrieve and write
(including decoding and encoding, respectively) data as specified in 6.1.4.
6.2.5 Security requirements
6.2.5.1 General
This document specifies security features and mechanisms based on the security framework specified
in EN ISO 19299.
EFC-DSRC-IAP-1 in this document allows for implementation of two different levels of security (0,1).
Security level 0 shall be supported whereas level 1 can be implemented on an optional basis. The
associated security related data elements that are used for data exchanges over the EFC-DSRC interface
are specified in 6.1.5.
NOTE See Annex D for further details and explanations.
6.2.5.2 Security level 0 requirements
The RSE shall be able to calculate Authenticators to validate data integrity and origin of the application
data. These calculations shall be performed according to EN ISO 14906:2023, Annex F.2.
The RSE shall update the TransactionCounter according to the following procedure:
a) retrieve the EFC attribute EquipmentStatus by using the GET or ACTION GET_STAMPED service;
b) let the Transaction Counter be the value of the last 12 bits in EquipmentStatus (0.4095);
c) increase the Transaction Counter by 1;
d) insert the changed Transaction Counter into the last 12 bits of EquipmentStatus.
e) write the updated EquipmentStatus attribute to the OBU by using the SET service.
NOTE 1 See the CARDME-4 concept or EN ISO 14906:2023, Annex B.3.5 for further explanation of the context
and use of the Transaction Counter.
NOTE 2 An RSE that has only implemented the security requirements associated with level 0 in this document
is not able to access OBU data protected by means of access credentials according to security level 1 (see 6.1.5.3).
6.2.5.3 Security level 1 requirements
The RSE shall support the requirements associated with security level 0 as specified in 6.1.5.2.
The RSE shall be able to calculate Access Credentials for access to protected user related data on the
OBU. These calculations shall be performed according to EN ISO 14906:2023, Annex F.3.
6.2.6 Transaction requirements
The EFC transaction model shall comply with EN ISO 14906:2023, Clause 6.
There are no additional specific normative requirements on the transaction in this document. This
means that the RSE may perform the transaction in any way suitable as long as the other requirements
in this document are met.
An informative example of a transaction can be found in EN ISO 14906:2023, Annex B.

Annex A
(normative)
EFC data specification
A.1 Specification of data elements
The basic specification of EFC data elements is specified in EN ISO 14906 and in EN 12834. The specification in this clause of EFC data elements
(EFC attributes and security-related data) restricts choices or is more specific and limited in scope than those of the mentioned base standards.
The EFC data elements are specified in Tables A.1 to A.4.
The length column in Tables A.1 to A.4. includes the length determinant as specified in ISO/IEC 8825-2 (unaligned packed encoding rules for ASN.1
is used in EN ISO 14906). In case of discrepancies between the Length and the ASN.1 module, the ASN.1 module specified in A.2 shall take
precedence.
Table A.1 — Application related data (specified in EN 12834)
Name Definition and remarks Usage Length
(octets)
Data element
An octet string that is s
...