ISO 14906:2004

Road transport and traffic telematics - Electronic fee collection - Application interface definition for dedicated short-range communication

ISO 14906:2004 specifies the application interface in the context of Electronic Fee Collection (EFC) systems using the Dedicated Short-Range communication (DSRC). The EFC application interface is the EFC application process interface to the DSRC Application Layer. ISO 14906:2004 is applicable to the EFC attributes (i.e. EFC application information); the addressing procedures of EFC attributes and (hardware) components (e.g. ICC and MMI); EFC application functions, i.e. further qualification of actions by definitions of the concerned services, assignment of associated ActionType values and content and meaning of action parameters; the EFC transaction model, which defines the common elements and steps of any EFC transaction; the behaviour of the interface so as to ensure interoperability on an EFC-DSRC application interface level. This is an interface standard, adhering to the open systems interconnection (OSI) philosophy (ISO/IEC 7498-1), and it is, as such, not concerned with the implementation choices to be realised at either side of the interface. ISO 14906:2004 provides security-specific functionality as place holders (data and functions) to enable the implementation of secure EFC transactions. Yet the specification of the security policy (including specific security algorithms and key management) remains at the discretion and under the control of the EFC operator, and hence is outside the scope of ISO 14906:2004.

Télématique de la circulation et du transport routier — Perception du télépéage — Définition de l'interface d'application relative aux communications dédiées à courte portée

General Information

• Status: Withdrawn
• Publication Date: 15-Sep-2004
• Withdrawal Date: 15-Sep-2004
• ICS: 03.220.20 - Road transport
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 5 - Fee and toll collection
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 06-Oct-2011
• Completion Date: 13-Dec-2025

Relations

• Consolidated By: ISO 18365:2013 - Hydrometry - Selection, establishment and operation of a gauging station
• Effective Date: 06-Jun-2022
• Revised: ISO 14906:2011 - Electronic fee collection - Application interface definition for dedicated short-range communication
• Effective Date: 31-Jul-2008
• Revises: ISO/TR 14906:1998 - Road Transport and Traffic Telematics (RTTT) - Electronic Fee Collection (EFC) - Application interface definition for dedicated short range communications
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 14906
First edition
2004-09-15
Road transport and traffic telematics —
Electronic fee collection — Application
interface definition for dedicated
short-range communication
Télématique de la circulation et du transport routier — Perception du
télépéage — Définition de l'interface d'application relative aux
communications dédiées à courte portée

Reference number
©
ISO 2004
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2004
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO 2004 – All rights reserved

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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
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.
ISO 14906 was prepared by the European Committee for Standardization (CEN) in collaboration with
Technical Committee ISO/TC 204, Intelligent transport systems, in accordance with the Agreement on
technical cooperation between ISO and CEN (Vienna Agreement).
Throughout the text of this document, read “.this European Standard.” to mean “.this International
Standard.”.
Contents
page
Foreword.v
Introduction .vi
1 Scope.1
2 Normative references.2
3 Terms and definitions .3
4 Abbreviations.5
5 EFC application interface architecture.8
5.1 Relation to the DSRC communication architecture.8
5.2 Usage of DSRC application layer by the EFC application interface .9
5.3 Addressing of EFC attributes .9
5.4 Addressing of components.11
6 EFC Transaction Model.12
6.1 General.12
6.2 Initialisation Phase.12
6.3 Transaction phase.15
7 EFC Functions .17
7.1 Overview and general concepts .17
7.2 EFC functions .21
8 EFC Attributes .38
8.1 General.38
8.2 Data group CONTRACT.40
8.3 Data group RECEIPT .42
8.4 Data group VEHICLE .46
8.5 Data group EQUIPMENT .47
8.6 Data group DRIVER .47
8.7 Data group PAYMENT .48
Annex A (normative)  EFC data type specifications .49
Annex B (informative)  CARDME transaction . 64
Annex C (informative)  Examples of EFC transaction types. 93
Annex D (informative)  Functional requirements . 104
Bibliography .111

iv © ISO 2004 – All rights reserved

Fore word
This document (EN ISO 14906:2004) has been prepared by Technical Committee CEN/TC 278 "Road Transport

and Traffic Telematics (RTTT)", the secretariat of which is held by NEN, in collaboration with Technical Committee
ISO/TC 204 “Intelligent Transport Systems (ITS)”.
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 March 2005, and conflicting national standards shall be withdrawn at the latest by
March 2005.
This document supersedes ENV ISO 14906:1998.
In order to facilitate migration from ENV ISO 14906, equipment procured and installed in accordance with ENV ISO
14906 has been considered when drafting this European Standard. Operation of such equipment and procurement
of additional equipment for systems based on such equipment can continue with reference to Directive 93/36/EEG
Article 8 item 3c.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to implement this European Standard: Austria, Belgium, Cyprus, Czech Republic, Denmark,
Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,
Netherlands, Norway, Poland, Portugal, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.

Introduction
This document specifies an application interface for Electronic Fee Collection (EFC) systems, which are based on
the Dedicated Short-Range Communication (DSRC). It supports interoperability between EFC systems on an EFC-
DSRC application interface level.
This document provides specifications for the EFC transaction model, EFC data elements (referred to as attributes)
and functions, from which an EFC transaction can be built. The EFC transaction model provides a mechanism that
allows handling of different versions of EFC transactions and associated contracts. A certain EFC transaction
supports a certain set of EFC attributes and EFC functions as defined in this European Standard. It is not
envisaged that the complete set of EFC attributes and functions is present in each piece of EFC equipment, be on-
board equipment (OBE) or roadside equipment (RSE).
This document provides the basis for agreements between operators, which are needed to achieve interoperability.
Based on the tools specified in this document, interoperability can be reached by operators recognising each
others EFC transactions (including the exchange of security algorithms and keys) and implementing the EFC
transactions in each others RSE, or they may reach an agreement to define a new transaction (and contract) that is
common to both. Considerations should also be made by each operator that the RSE has sufficient resources to
implement such additional EFC transactions.
In order to achieve interoperability, operators should agree on issues like:
— which optional features are actually being implemented and used;
— access rights and ownership of EFC application data in the OBE;
— security policy (including encryption algorithms and key management, if applicable);
— operational issues, such as how many receipts may be stored for privacy reasons, how many receipts are
necessary for operational reasons (e.g. as entry tickets or as proof of payment);
— the agreements needed between operators in order to regulate the handling of different EFC transactions.
This document has the following structure. In the first four clauses the scope, normative references, definitions of
terms and abbreviations are accounted for. Next, in Clause 5, the EFC Application interface architecture is
described in terms of its relation to the DSRC communication architecture, including the addressing of data
attributes and of components. In the following Clause 6, the EFC transaction model is introduced, defining the
common steps of each EFC transaction, in particular the initialisation phase. Clauses 7 and 8 are dedicated to the
detailed specification of the EFC application functions and of the EFC data attributes, respectively. Four annexes
provide:
1. Annex A: the normative ASN.1 specifications of the used data types (EFC action parameters and attributes);
2. Annex B: an informative example of a transaction based on the CARDME specification, including bit-level
specification;
3. Annex C: informative examples of EFC transaction types, using the specified EFC functions and attributes;
4. Annex D: an informative listing of functional requirements, which can be satisfied by using the tools provided by
this document.
vi © ISO 2004 – All rights reserved

1 Scope
This document specifies the application interface in the context of Electronic Fee Collection (EFC) systems using
the Dedicated Short-Range Communication (DSRC).
The EFC application interface is the EFC application process interface to the DSRC Application Layer, as can be
seen in Figure 1 below. The scope of this document comprises specifications of:
— EFC attributes (i.e. EFC application information);
— the addressing procedures of EFC attributes and (hardware) components (e.g. ICC and MMI);
— EFC application functions, i.e. further qualification of actions by definitions of the concerned services,
assignment of associated ActionType values and content and meaning of action parameters;
— the EFC transaction model, which defines the common elements and steps of any EFC transaction;
— the behaviour of the interface so as to ensure interoperability on an EFC-DSRC application interface level.

Figure 1 — The EFC application interface
This is an interface standard, adhering to the open systems interconnection (OSI) philosophy (ISO/IEC 7498-1),
and it is as such not concerned with the implementation choices to be realised at either side of the interface.
This document provides security-specific functionality as place holders (data and functions) to enable the
implementation of secure EFC transactions. Yet the specification of the security policy (including specific security
algorithms and key management) remains at the discretion and under the control of the EFC operator, and hence is
outside the scope of this document.
2 Normative references
The following referenced documents are indispensable for the application 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:2003, Road transport and traffic telematics - Dedicated Short Range Communication (DSRC) –
DCRC application layer.
EN ISO 3166-1, Codes for the representation of names of countries and their subdivisions - Part 1:
Country codes (ISO 3166-1:1997).
EN ISO/IEC 7812-1, Identification cards - Identification of issuers - Part 1: Numbering system (ISO/IEC
7812-1:1993).
ENV ISO 14816:2000, Road Traffic and Transport Telematics (RTTT) - Automatic Vehicle and
Equipment Identification – Numbering and Data Structures (ISO/TR 14816:2000).
ISO 612, Road vehicles - Dimensions of motor vehicles and towed vehicles - Terms and definitions.
ISO 1176, Road vehicles - Masses - Vocabulary and codes.
ISO 3779, Road vehicles - Vehicle identification number (VIN) - Content and structure.
ISO 4217, Codes for the representation of currencies and funds.
ISO/IEC 8824-1, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic
notation.
ISO/IEC 8825-2, Information technology - ASN.1 encoding rules: Specification of Packed Encoding Rules
(PER).
ISO/DIS 15628:2003, Transport Information and Control System (TICS) - Dedicated Short-Range
Communication (DSRC) – DSRC Application Layer.

Currently being revised.
2 © ISO 2004 – All rights reserved

3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
access credentials
data that is transferred to on-board equipment (OBE), in order to establish the claimed identity of a roadside
equipment (RSE) application process entity
NOTE The access credentials carries information needed to fulfil access conditions in order to perform the operation on the
addressed element in the OBE. The access credentials can carry passwords as well as cryptographic based information such
as authenticators.
3.2
action
function that an application process resident at the roadside equipment can invoke in order to make the on-board
equipment execute a specific operation during the transaction
3.3
attribute
application information formed by one or by a sequence of data elements, and is managed by different actions
used for implementation of a transaction
3.4
authenticator
data appended to, or a cryptographic transformation (see 3.8) of, a data unit that allows a recipient of the data unit
to prove the source and/or the integrity of the data unit and protect against forgery
3.5
channel
information transfer path
[ISO 7498-2]
3.6
component
logical and physical entity composing an on-board equipment, supporting a specific functionality
3.7
contract
expression of an agreement between two or more parties concerning the use of the road infrastructure
3.8
cryptography
discipline which embodies principles, means, and methods for the transformation of data in order to hide its
information content, prevent its undetected modification or/and prevent its unauthorised use
[ISO 7498-2]
3.9
data group
collection of closely related EFC data attributes which together describe a distinct part of an EFC transaction
3.10
data integrity
property that data has not been altered or destroyed in an unauthorised manner
[ISO 7498-2]
3.11
element
in the context of DSRC, a directory containing application information in form of attributes
3.12
on-board equipment
equipment located within the vehicle and supporting the information exchange with the roadside equipment. It is
composed of the on-board unit and other sub-units whose presence have to be considered optional for the
execution of a transaction
3.13
on-board unit
inimum component of an on-board equipment, whose functionality always includes at least the support of the
DSRC interface
3.14
roadside equipment
Equipment located at a fixed position along the road transport network, for the purpose of communication and data
exchanges with the on-board equipment of passing vehicles
3.15
service (EFC)
road transport related facility provided by a service provider. Normally a type of infrastructure, the use of which is
offered to the user for which the User may be requested to pay
3.16
service primitive (communication)
elementary communication service provided by the Application layer protocol to the application processes
NOTE The invocation of a service primitive by an application process implicitly calls upon and uses services offered by the
lower protocol layers.
3.17
service provider (EFC)
operator that accepts the user's payment means and in return provides a road-use service to the user
3.18
session
exchange of information and interaction occurring at a specific EFC station between the roadside equipment and
the user/vehicle
3.19
transaction
whole of the exchange of information between the roadside equipment and the on-board equipment necessary for
the completion of an EFC operation over the DSRC
3.20
transaction model
functional model describing the general structure of Electronic Payment Fee Collection transactions
3.21
user
entity that uses transport services provided by the Service Provider according to the terms of a contract
4 © ISO 2004 – All rights reserved

4 Abbreviations
For the purpose of this document, the following abbreviations apply throughout the document unless otherwise
specified.
4.1
ADU
Application Data Unit
4.2
APDU
Application Protocol Data Unit
4.3
AP
Application Process
4.4
ASN.1
Abstract Syntax Notation One (ISO/IEC 8824-1)
4.5
B-Kernel
Broadcast Kernel
4.6
BST
Beacon Service Table
4.7
cf
Confirm
4.8
DSRC
Dedicated Short-Range communication
4.9
EID
Element Identifier
4.10
EFC
Electronic Fee Collection
4.11
EVENT-RT
EVENT-REPORT
4.12
GPS
Global Positioning System
4.13
ICC
Integrated Circuit(s) Card
4.14
I-Kernel
Initialisation Kernel
4.15
IID
Invoker Identifier
4.16
ind
Indication
4.17
L1
Layer 1 of DSRC (Physical Layer)
4.18
L2
Layer 2 of DSRC (Data Link Layer)
4.19
L7
Application Layer Core of DSRC
4.20
LID
Logical Link Control Identifier
4.21
LLC
Logical Link Control
4.22
LPDU
LLC Protocol Data Unit
4.23
MAC
Medium Access Control
4.24
MMI
Man-Machine Interface
4.25
n.a.
Not applicable
4.26
OBE
On-Board Equipment
4.27
OBU
On-Board Unit
4.28
PDU
Protocol Data Unit
6 © ISO 2004 – All rights reserved

4.29
PER
Packed Encoding Rules (ISO/IEC 8825-2)
4.30
PPDU
Physical Layer Protocol Data Unit
4.31
req
Request
4.32
rs
Response
4.33
RSE
Roadside Equipment
4.34
RTTT
Road Transport and Traffic Telematics
4.35
SAM
Secure Application Module
4.36
T-APDU
Transfer-Application Protocol Data Unit
4.37
T-ASDU
Transfer-Application Service Data Unit
4.38
T Kernel
Transfer Kernel
4.39
VST
Vehicle Service Table
5 EFC application interface architecture
5.1 Relation to the DSRC communication architecture
The DSRC services are provided to an application process by means of the DSRC Application Layer service
primitives, which are abstract implementation interactions between a communication service user and a provider.
The services are offered by the DSRC communication entities by means of its DSRC Application Layer
(EN 12834 / ISO/DIS 15628).
Figure 2 — The EFC application process on top of the DSRC communication stack
NOTE The abbreviations used in Figure 2 are defined in clause 4.
The Transfer Kernel of DSRC Application Layer offers the following services to application processes (see also
Figure 2 above):
— GET: The invocation of a GET service request results in retrieval (i.e. reading) of application information (i.e.
Attributes) from the peer service user (i.e. the OBE application process), a reply is always expected.
— SET: The invocation of a SET service request results in modification (i.e. writing) of application information (i.e.
Attributes) of the peer service user (i.e. the OBE application process). This service may be requested in
confirmed or non-confirmed mode, a reply is only expected in the former case.
— ACTION: The invocation of an ACTION service request results in a performance of an action by the peer
service user (i.e. the OBE application process). An action is further qualified by the value of the ActionType.
This service may be requested in confirmed or non-confirmed mode, a reply is only expected in the former case.
8 © ISO 2004 – All rights reserved

— EVENT-REPORT: The invocation of an EVENT-REPORT service request forwards a notification of an event to
the peer service user.
— INITIALISATION: The invocation of an initialisation service request by RSE results in an attempt to initialise
communication between a RSE and each OBE that has not yet established communication with the concerned
RSE. The Initialisation service is only used by the Initialisation Kernel as defined in EN 12834 / ISO/DIS 15628.
5.2 Usage of DSRC application layer by the EFC application interface
EFC uses the following services offered by DSRC Application Layer (as defined in EN 12834 / ISO/DIS 15628):
— The INITIALISATION services:
— Notify Application RSU (at RSE);
— End Application (at RSE);
— Register Application RSU (at RSE);
— Deregister Application (at RSE and OBE);
— Notify Application OBU (at OBE);
— Register Application OBU (at OBE)
are used to realise the EFC-specific initialisation mechanism (see clause 6);
— The GET service is used to retrieve EFC attributes (For attribute specifications see clause 8);
— The SET service is used to set EFC attributes;
— The ACTION services are applied to realise additional EFC specific functionality needed to support EFC
application processes, such as TRANSFER_CHANNEL, SET_MMI and ECHO (see 7.2).
In the following, the EFC-specific usage of the DSRC Layer 7 services is specified in detail.
NOTE The EVENT-REPORT-service can be implicitly used by EFC application processes. It is e.g. used indirectly as part of
an already defined command to release an application process (see EN 12834 / ISO/DIS 15628, Ready Application). However
as the EVENT-REPORT-service is not explicitly used by EFC application processes, this service is not further referred to in this
document.
5.3 Addressing of EFC attributes
5.3.1 Basic mechanism
EFC Attributes are used to transfer the EFC application-specific information.
EFC Attributes are composed of one or more data elements of specified ASN.1 types. Each data element is
associated with, within the context of this document, an unambiguous name.
To each EFC Attribute, an AttributeID is associated. The AttributeId enables to unambiguously identify and address
an EFC Attribute.
EXAMPLE Figure 3 illustrates the basic addressing mechanism:

Figure 3 — Basic addressing mechanism
5.3.2 Role of the EID
The DSRC-EID (different from 0) is used to identify an EFC context, given by the EFC-ContextMark (see 6.2.3), in
which Attributes can be addressed unambiguously by AttributeIDs. In the VST, the OBE may specify several of
these EFC contexts, each corresponding to a set of EFC Attributes and EFC functions supported by it.
EXAMPLE
Figure 4 — Role of the EID
EID equals 0 shall be used to address application-independent functions and components, e.g. SET_MMI and
TRANSFER_CHANNEL (see 7.2).
5.3.3 Multiple Instances of Attributes
There may be n, where n is an integer, instances of an Attribute available in an OBE.
The maximum number of instances N of one Attribute may be limited according to the needs of operators and
max
users. The default maximum number of instances is N =1. The value of N is determined at the time of OBE
max max
configuration.
10 © ISO 2004 – All rights reserved

EXAMPLE:
Figure 5 — Multiple instances (0-2) of attribute 5
The handling of multiple instances and the corresponding addressing mechanism are described in detail as part of
the behaviour specification of the corresponding functions supporting multiple instances (see 7.2.6 for
GET_INSTANCE and 7.2.7 for SET_INSTANCE).
5.4 Addressing of components
Components of an OBE to be addressed via the EFC Application Interface include for example:
— OBU;
— SAM 1;
— SAM 2;
— ICC;
— Display;
— Buzzer;
— Printer;
— Serial interface;
— Parallel interface;
— GPS;
— Tachograph;
— Bluetooth.
Addressing of these components is enabled on two levels, device-specific and device-independent addressing.
The device-specific transparent addressing mechanism enables the transfer of information, which shall be
processed by the addressed device (such as an ICC-command). The addressed device is identified by a channel
Id. The EFC function TRANSFER_CHANNEL (see 7.2.10) supports this functionality.
EXAMPLE 1: Transfer of a bit string to an ICC.
The device-independent addressing mechanism uses a set of commands, which describe a certain functionality,
which can be performed by various OBU components. In this case, the operating system of the OBU will address
the corresponding components. The EFC function SET_MMI supports this functionality (see 7.2.12).
EXAMPLE 2: Invocation of a SET_MMI(EID=0, ContactOperator) function activates an OBE MMI-device, e.g. a buzzer or a
display.
NOTE In a specific implementation, specific attributes or data elements may activate some MMI function (e.g. a SET
command on the attribute ReceiptText might display the text on an LCD display. A SET command on the attribute
ReceiptServicePart with data element SessionResultOperational other than SessionOK might activate an alert beep).
Proprietary addressing mechanisms are not defined by this document.
6 EFC Transaction Model
6.1 General
The EFC Transaction Model related to the EFC Application Interface for the DSRC comprises two phases, the
initialisation phase and the transaction phase.
NOTE The purpose of the initialisation phase is to set up the communication between the RSE and OBEs that have entered
the DSRC zone but have not yet established communication with the RSE, and to notify the application processes. It provides
amongst others a multi-application switching mechanism, allowing for execution of several RTTT applications (in parallel) at one
RSE station.
The transaction phase can only be reached after completion of the initialisation phase. The EFC functions, as
defined in clause 7, can be performed in the transaction phase. The GET and SET services (DSRC application
layer functions) as defined in EN 12834 / ISO/DIS 15628:2003 (in 6.2) may also be used in an EFC transaction
phase.
6.2 Initialisation Phase
6.2.1 Overview
This Clause provides an overview of the functionality of, and the information exchanges in, the initialisation phase.
The Initialisation procedures, by means of beacon service table (BST) and vehicle service table (VST) exchanges,
are defined in EN 12834 / ISO/DIS 15628. 6.2.2 and 6.2.3 below account for the EFC application-specific
information that shall be included in the BST and VST, respectively.
NOTE The OBE evaluates the received BST, and selects the applications that it wishes to perform out of the lists of
applications supported by the RSE. If the OBE does not support any of application(s) supported by the RSE, then it is
recommended that the OBE does not exchange any information with the RSE. If the OBE supports at least one of the
application(s) supported by the RSE, then it is recommended that the OBE informs the RSE of which application it wishes to
execute in its corresponding VST.
12 © ISO 2004 – All rights reserved

Figure 6 — Initialisation phase: BST - VST exchanges
The Initialisation service associated with the initialisation phase is only used by the Initialisation Kernel
(of EN 12834 / ISO/DIS 15628), which in its turn is configured by the application(s) wishing to execute applications
over a DSRC link. The Initialisation Kernels of the RSE and of the concerned OBE shall have been configured,
according to EN 12834 / ISO/DIS 15628, prior to the invocation of the Initialisation service by the RSE.
6.2.2 EFC application-specific contents of the BST
An RSE supporting EFC shall have configured its Initialisation Kernel to carry the following information related
specifically to the EFC application(s):
— the application identifier (AID) shall be equal to 1 (i.e. the value assigned for EFC);
— the EFC application shall be qualified as a mandatory application;
— EID shall not be transmitted in the BST related to the EFC application;
— no Parameter shall be transmitted in the BST related to the EFC application.
NOTE 1 Aid equals to 14 identifies the Multi-purpose payment context. In Japan, EN ISO 14906 specifies the application
interface for DSRC used for multi-purpose payment (when the Aid=14 is used in Japan, the EID and parameter fields are
defined through the BST).
There shall be only one EFC application present in the BST (i.e. there shall be only one instance of AID=1 in the
BST) regardless of whether the RSE supports more than one EFC-ContextMark (see also 6.2.3).
NOTE 2 The above is the EFC application-specific contents of the BST. The complete BST is defined in EN 12834 / ISO/DIS
15628 and is given below for readability of this document:
BST ::= SEQUENCE {
beacon BeaconID,
time Time,
profile Profile,
mandApplications ApplicationList,
nonmandApplications ApplicationList OPTIONAL,
profileList SEQUENCE(0.127, .) OF Profile
}
where
ApplicationList ::= SEQUENCE (0.127,.) OF
SEQUENCE{
aid DSRCApplicationEntityID, -- AID=1
eid Dsrc-EID OPTIONAL, -- empty
parameter Container OPTIONAL -- empty
}
6.2.3 EFC application-specific contents of the VST
Each EFC application and corresponding contract shall be associated with an EFC-ContextMark, as defined below.
An OBE may support several EFC applications.
NOTE 1 It is outside the scope of this document to define in which order EFC-ContextMarks shall be presented in order to
indicate a user’s order of preference, in case his OBE supports several EFC applications. Such rules for indicating the user’s
order of preference may be subject to agreements between operators.
An OBE supporting EFC shall have configured its Initialisation Kernel to carry the following information related
specifically to the concerned EFC application:
— the AID shall be equal to 1;
— the EID value shall be logically associated with the corresponding EFC-ContextMark, contained in the
Parameter, and shall be unique within the OBE throughout the complete DSRC session;
— the Parameter shall be of Container CHOICE type OCTET STRING and shall comprise the EFC-ContextMark
as defined below, and may also be configured to carry additional EFC attributes (as defined in Clause 8 and
Annex A).
EFC-ContextMark::=SEQUENCE{
ContractProvider Provider,
TypeOfContract OCTET STRING (SIZE(2)),
ContextVersion INTEGER(0.127,.)
}
The EFC-ContextMark denotes a specific EFC context in the OBE, comprising the organisation that issued the
contract, the type of contract and the context version. ContractProvider, TypeOfContract and ContextVersion are
further defined in Clause 8 as data elements of the Attribute EFC-ContextMark.
NOTE 2 The above is the EFC application-specific contents of the VST. The complete VST is defined in EN 12834 / ISO/DIS
15628 and is given below for readability of this document:
VST ::=  SEQUENCE {
fill BIT STRING (SIZE(4))
profile Profile,
applications ApplicationList,
obeConfiguration ObeConfiguration
}
14 © ISO 2004 – All rights reserved

where:
ApplicationList ::= SEQUENCE (0.127,.) OF
SEQUENCE{
aid DSRCApplicationEntityID, -- AID =1
eid Dsrc-EID OPTIONAL, -- EID = e.g. 2
parameter Container OPTIONAL -- EFC-ContextMark
-- plus any EFC Attribute
}
NOTE 3 Aid equals to 14 identifies the Multi-purpose payment context. In Japan, EN ISO 14906 specifies the application
interface for DSRC used for multi-purpose payment (when the Aid=14 is used in Japan, the EID and parameter fields are
defined through the BST).
NOTE 4 An EFC application provider retains the ultimate control of his security domain, i.e. the security level and the associated
security mechanisms to be used within his system.
6.3 Transaction phase
After completion of the Initialisation phase, the appropriate RSE application is informed (by means of the Notify
Application RSU service) of the EFC-ContextMark and associated EID. The RSE shall use the functions defined in
clause 7 to complete the EFC transaction.
The RSE may invoke any sequence of EFC functions to complete the EFC transaction, provided that they are
supported by the EFC-ContextMark. The OBE shall respond to the EFC functions invoked by the RSE, and shall
not initiate any EFC functions (by usage of a request service primitive, see further clause 7) on its side.
EXAMPLE A transaction may consist of the following steps:
— GET(EID, ContractValidity, ContractVehicle, ReceiptServicePart, PaymentMeansBalance)
— DEBIT(EID, DebitPaymentFee)
— SET(EID, ReceiptServicePart)

Due to the construction of the EFC part of the VST, each EID identifies a certain EFC-ContextMark and shall be
used by the RSE as parameter of every function to unambiguously address data elements within the context given
by the EFC-ContextMark. More than one EID may be used in one session.
Both which attributes that are to be implemented and the maximum number of instances of an attribute is defined at
time of configuration of the OBE, and is outside the scope of this European Standard. These implementation
dependent aspects are referenced unambiguously by the ContextVersion data element in the EFC-ContextMark.
Figure 7 — Context of attributes given by EFC-ContextMark and identified by the EID
NOTE 1 This construction of contexts being identified by EIDs allows amongst others to implement the following transactions:
− booking from two contracts in one transaction. There is sometimes the need to book from two contracts in one
session, e.g. when a customer has a contract with a reduced price (e.g. a commuter contract) for part of the route
being tolled, plus a standard (not reduced) contract for the rest of the route. This may be implemented by having
all data groups identical between two EIDs, except for the data group contract.
− having either two instances of the data group Vehicle to accommodate a pulling vehicle plus a trailer, or having two
EIDs with separate data groups Vehicle for pulling vehicle and trailer (and probably also separate Contract).
NOTE 2 This EFC transaction model and associated procedures allow for different levels of co-existence and interoperability
between operators:
− No agreement between operators - each operator has a completely separate application domain, i.e. there are no
common data groups. Each operator books by using ”his“ EID.
− Agreement to share some data groups, but not others. E.g. the data groups Vehicle, Receipt and Payment are
shared, but not Contract. Different security measures (algorithms) are used by the two operators. Or, all data
groups are shared, except for Payment - each operator books from an account issued by himself.
16 © ISO 2004 – All rights reserved

7 EFC Functions
7.1 Overview and general concepts
7.1.1 EFC functions and service primitives
This clause describes the EFC functions invoked by T-ASDUs exchanged between peer applications
communicating via a DSRC link. The T-ASDUs are exchanged by means of service primitives of the DSRC
Application Layer (EN 12834 / ISO/DIS 15628). Exchanges of service primitives (and the corresponding T-ASDUs)
associated with EFC functions adhere to the following basic pattern:
— xxx.rq (request) service primitive invoked by the RSE application to DSRC Application Layer;
— xxx.ind (indication) service primitive issued by the DSRC Application Layer to the OBE application;
— xxx.rs (response) service primitive invoked by the OBE application to DSRC Application Layer;
— xxx.cf (confirmation) service primitive issued by the DSRC Application Layer to RSE application.
The last two steps are either mandatory or optional, depending on the nature of the service primitive and on the
setting of the Mode parameter (see 6.2.4 in EN 12834:2003 / ISO/DIS 15628:2003).
The logical sequence of a successful service primitives exchange (for Mode = TRUE) is illustrated in Figure 8
below. Service primitives that occur earlier in time, and are connected by dotted lines in the figure, are the logical
antecedents of subsequent service primitives.

Figure 8 — The logical sequencing of service primitive exchanges
For the purposes of this document, the DSRC link is seen as completely transparent, i.e. in the absence of
exceptions the XXX.ind is identical in content and meaning to the XXX.rq, and the XXX.cf is identical in content and
meaning to the XXX.rs. For the purpose of conciseness there will be:
— one description for request, i.e. XXX.rq, covering both request and indication service primitives;
— one description for response, i.e. XXX.rs, covering both response and confirmation service primitives.
The format and the parameters of the service primitives of the DSRC application layer are defined in EN
12834:2003 / ISO/DIS 15628:2003, 6.2.2 (T Kernel Services).
7.1.2 Overview of EFC functions
This sub-clause provides an overview of the EFC functions (based on the ACTION service primitive of EN 12834 /
ISO/DIS 15628) that are defined in 7.2 of this document. Each EFC function comprises a pair of service primitives,
a request and its associated response service primitive, which are accounted for in 7.2.
Table 1 — Overview of EFC functions
Function Name Action Action Parameter Response Parameter Remarks
Type
GET_STAMPED 0 GetStampedRq GetStampedRs retrieves data with an
authenticator from the OBE
SET_STAMPED
1 SetStampedRq OCTET STRING sets data in the OBE, which
generates an authenticator
GET_SECURE 2 OCTET STRING OCTET STRING gets data securely from the OBE
SET_SECURE
3 OCTET STRING OCTET STRING sets data securely in the OBE
GET_INSTANCE 4 GetInstanceRq GetInstanceRs retrieves a number of entries out
of an attribute’s multiple instances
SET_INSTANCE
5 SetInstanceRq n.a. sets one entry at a specified
position in an attribute’s multiple
instances
GET_NONCE 6 n.a. OCTET STRING retrieves a nonce - typically used
against replay attacks
SET_NONCE
7 OCTET STRING n.a. sets a nonce - typically used
against replay attacks
TRANSFER_CHANNEL 8 ChannelRq ChannelRs sets and/or retrieves data from the
addressed OBE component (e.g.
an ICC)
COPY
9 CopyRq n.a. copies data from a source EID to a
destination EID
SET_MMI 10 SetMMIRq n.a. invokes an MMI function (e.g.
signal Ok via buzzer)
SUBTRACT
11 SubRq n.a. subtracts the given value to the
addressed value
ADD 12 AddRq n.a adds the given value to the
addressed value
DEBIT
13 DebitRq DebitRs debits purse
CREDIT 14 CreditRq CreditRs credits purse
ECHO
15 OCTET STRING OCTET STRING OBE echoes received data
The GET and SET services (DSRC application layer functions) as defined in EN 12834 / ISO/DIS 15628:2003 (in
6.2) may also be used in an EFC transaction phase.
NOTE GET is used to retrieve (i.e. read) value(s) of the addressed attribute(s), a reply is always expected. SET is used to set
(i.e. write) value(s) of the addressed attribute(s).
7.1.3 Handling of multiple instances
For the purpose of description, the number of instances is denoted by n. In general the EFC functions operating on
multiple instances of OBE Attributes can be divided into the following groups:
18 © ISO 2004 – All ri
...