ISO/TR 14906:1998

Road Transport and Traffic Telematics (RTTT) - Electronic Fee Collection (EFC) - Application interface definition for dedicated short range communications

Télématique de la circulationet du transport routier — Perception du télépéage — L'interface applicative relative aux communications dédiées aux courtes portées

General Information

• Status: Withdrawn
• Publication Date: 19-Dec-1998
• Withdrawal Date: 19-Dec-1998
• 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: 16-Sep-2004
• Completion Date: 13-Dec-2025

Relations

• Consolidates: ISO 7301:1988 - Rice - Specification
• Effective Date: 06-Jun-2022
• Revised: ISO 14906:2004 - Road transport and traffic telematics - Electronic fee collection - Application interface definition for dedicated short-range communication
• Effective Date: 15-Apr-2008

Standards Content (Sample)

TECHNICAL ISO/TR
REPORT 14906
First edition
1998-12-15
Road Transport and Traffic Telematics
(RTTT) — Electronic Fee Collection (EFC) —
Application interface definition for
dedicated short range communications
Télématique de la circulation et du transport routier — Perception du
télépéage — L'interface applicative relative aux communications dédiées
aux courtes portées
A
Reference number
Foreword
ISO (the International Organization for Standardization) is a worldwide
federation of national standards bodies (ISO member bodies). The work of
preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which
a technical committee has been established has the right to be represented
on that committee. International organizations, governmental and non-
governmental, in liaison with ISO, also take part in the work. ISO
collaborates closely with the International Electrotechnical Commission
(IEC) on all matters of electrotechnical standardization.
The main task of technical committees is to prepare International
Standards, but in exceptional circumstances a technical committee may
propose the publication of a Technical Report of one of the following types:
— type 1, when the required support cannot be obtained for the
publication of an International Standard, despite repeated efforts;
— type 2, when the subject is still under technical development or where
for any other reason there is the future but not immediate possibility of
an agreement on an International Standard;
— type 3, when a technical committee has collected data of a different
kind from that which is normally published as an International Standard
(“state of the art”, for example).
Technical Reports of types 1 and 2 are subject to review within three years
of publication, to decide whether they can be transformed into International
Standards. Technical Reports of type 3 do not necessarily have to be
reviewed until the data they provide are considered to be no longer valid or
useful.
ISO/TR 14906, which is a Technical Report of type 2, was prepared by
European Committee for Standardization (CEN) in collaboration with ISO
Technical Committee ISO/TC 204, Transport information and control
systems, in accordance with the Agreement on technical cooperation
between ISO and CEN (Vienna Agreement).
©  ISO 1998
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 the publisher.
International Organization for Standardization
Case postale 56 • CH-1211 Genève 20 • Switzerland
Internet [e-mail]
Printed in Switzerland
ii
©
ISO ISO/TR 14906:1998(E)
This document is being issued in the Technical Report (type 2) series of
publications (according to subclause G.3.2.2 of part 1 of the ISO/IEC
Directives, 1995) as a “prospective standard for provisional application” in
the field of transport information and control systems because there is an
urgent need for guidance on how standards in this field should be used to
meet an identified need.
This document is not to be regarded as an “International Standard”. It is
proposed for provisional application so that information and experience of
its use in practice may be gathered. Comments on the content of this
document should be sent to the ISO/TC 204 Secretariat.
A review of this Technical Report (type 2) will be carried out not later than
three years after its publication with the options of: extension for another
three years; conversion into an International Standard; or withdrawal.
Annex A forms an integral part of this Technical Report. Annexes B to D
are for information only.
iii
©
CONTENTS
Foreword. vi
Introduction. vi
1 Scope . 1
2 Normative references . 1
3 Definitions . 3
4 Abbreviations . 5
5 EFC application interface architecture . 6
5.1 Relation to the DSRC communication architecture . 6
5.2 Usage of DSRC application layer by the EFC application interface. 7
5.3 Addressing of EFC attributes. 7
5.3.1 Basic mechanism . 7
5.3.2 Role of the EID . 8
5.3.3 Multiple Instances of Attributes . 8
5.4 Addressing of components . 9
6 EFC Transaction Model. 10
6.1 Initialisation Phase . 10
6.1.1 Overview . 10
6.1.2 EFC application-specific contents of the BST . 11
6.1.3 EFC application-specific contents of the VST . 11
6.2 Transaction phase . 12
7 EFC Functions. 14
7.1 Overview and general concepts. 14
7.1.1 EFC functions and service primitives . 14
7.1.2 Overview of EFC functions. 15
7.1.3 Handling of multiple instances. 16
7.1.4 Security . 17
7.2 EFC functions . 18
7.2.1 GET_STAMPED. 18
7.2.2 SET_STAMPED . 19
7.2.3 GET_SECURE. 20
7.2.4 SET_SECURE . 21
7.2.5 GET_INSTANCE. 22
7.2.6 SET_INSTANCE . 23
7.2.7 GET_NONCE. 24
7.2.8 SET_NONCE . 25
7.2.9 TRANSFER_CHANNEL. 26
7.2.10 COPY . 27
7.2.11 SET_MMI. 28
7.2.12 SUBTRACT. 29
7.2.13 ADD. 30
7.2.14 DEBIT. 31
7.2.15 CREDIT. 32
7.2.16 ECHO. 33
8 EFC Attributes. 34
8.1 Data group CONTRACT . 35
8.2 Data group RECEIPT. 36
8.3 Data group VEHICLE. 38
8.4 Data group EQUIPMENT. 39
8.5 Data group DRIVER. 39
8.6 Data group PAYMENT. 40
iv
©
ISO ISO/TR 14906:1998(E)
ANNEX A (normative) EFC data type specifications .41
Annex B (informative) An excerpt from DSRC application layer .48
B.1 Format of service primitives .48
B.2 Generic DSRC application layer functions .50
B.2.1 GET .50
B.2.2 SET.50
B.3 Container ASN.1 type definition .51
Annex C (informative) Examples of EFC transactions using the EFC application interface .52
C.1 Example of an EFC transaction - Example 1.52
C.2 Example of an EFC transaction - Example 2.53
C.3 Example of an EFC transaction - Example 3.54
C.4 Example of an EFC transaction - Example 4.55
C.5 Example of an EFC transaction - Example 5.58
ANNEX D (informative) Functional requirements.62
v
©
Foreword
This European Prestandard has been prepared by Technical Committee CEN/TC 278 "Road transport and traffic
,
telematics", the secretariat of which is held by NNI in collaboration with Technical Committee ISO/TC 204
"Transport information and control systems".
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this European Prestandard: Austria, Belgium, Czech Republic, Denmark, Finland,
France, Germany, Greece, Iceland, Ireland, Italy, Luxembourg, Netherlands, Norway, Portugal, Spain, Sweden,
Switzerland and the United Kingdom.
Introduction
This European Pre-Standard specifies an application interface for Electronic Fee Collection (EFC) systems, which
are based on the Dedicated Short-Range Communication (DSRC), enabling interoperability between open EFC
systems (i.e. between different EFC system operators) on an EFC-DSRC application interface level.
The European Pre-Standard 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 Pre-Standard. It
is not envisaged that the complete set of EFC attributes and functions is present in each piece of EFC equipment,
be OBE or RSE.
This European Pre-Standard provides the basis for agreements between operators, which are needed to achieve
interoperability. Based on the tools specified in this European Pre-Standard, 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 also have to be made by each operator that the
RSE has sufficient resources to implement such additional EFC transactions.
In order to achieve interoperability, operators have to agree on issues like:
• which optional features are actually being implemented and used;
• 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 European Pre-Standard 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
− the normative ASN.1 specifications of the used data types (EFC action parameters and
attributes);
−
an informative excerpt from DSRC application layer (ENV 12834), and its service primitives,
parameters and functions;
− informative examples of EFC transactions using the specified EFC attributes and functions;
− an informative listing of functional requirements, which can be satisfied by using the tools
provided by this European Pre-standard.

vi
©
ISO ISO/TR 14906:1998(E)
1 Scope
This European Pre-Standard specifies the application interface in the context of Electronic Fee Collection
(EFC) systems using the Dedicated Short-Range Communications (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 European Pre-Standard 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 European Pre-Standard 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 European Pre-Standard.

2 Normative references
This European Pre-Standard incorporates by dated or undated reference, provisions from other
publications.
©
These normative references are cited at the appropriate places in the text and the publications are
listed hereafter.
For dated references, subsequent amendments to or revisions of any of these publications apply to
this European Pre-Standard only when incorporated in it by amendment or revision. For undated
references the latest edition of the publication referred to applies.

Vehicle Measurement Definition
ISO 612:
ISO 1176: Vehicle Weight Definitions
Codes for the representation of names of countries
ISO 3166:
ISO 3779: 1983 Road Vehicles - Vehicle Identification Number (VIN)
Content and Structure
ISO 3780: 1983 Road Vehicles World manufacturer identification code (WMI)
Codes for the representation of currencies and funds
ISO 4217:
ISO 7498-1: 1994 Information Processing Systems - Open Systems
Interconnection - Basic Reference model
ISO/IEC 8824-1: 1995 Information processing systems - Open Systems
Interconnection - Specification of abstract syntax notation one
(ASN.1)
ISO/IEC 8825-2: 1996 Information processing systems - Open Systems
Interconnection - ASN.1 encoding rules: Specification of
Packed encoding rules
1998 Identification card systems - Surface transport applications -
ENV 1545-1
Part 1 : General data elements
1998 Identification card systems - Surface transport applications -
ENV 1545-2
Part 2 : Transport payment related data elements
1998 Road Traffic and Transport Telematics (RTTT), Automatic
prENV ISO 14816:
Vehicle and Equipment Identification - Numbering and Data
Structures (ISO/DTR 14816 : 1998)
1997 Road Traffic and Transport Telematics (RTTT), Dedicated
ENV 12834:
Short-Range Communication (DSRC) - Application Layer

©
ISO ISO/TR 14906:1998(E)
3 Definitions
For the purposes of this European Pre-Standard, the following definitions apply:

Data that is transferred to On-Board Equipment, in order to establish
3.1 access credentials
the claimed identity of an 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.

Function that an application process resident at the Roadside
3.2 action
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
transaction
implementation of a .
3.4 authenticator Data appended to, or a cryptographic transformation (see
cryptography) 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.
An information transfer path [ISO/IEC 7498-2].
3.5 channel
Logical and physical entity composing an On-Board Equipment,
3.6 component
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 The 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/IEC 7498-2].
A collection of closely related EFC data attributes which together
3.9 data group
describe a distinct part of an Electronic Fee Collection transaction.

The property that data has not been altered or destroyed in an
3.10 data integrity
unauthorised manner [ISO 7498-2].

3.11 element In the context of DSRC, a directory containing application information
Attributes
in form of .
3.12 on-board equipment Equipment located within the vehicle and supporting the information
Road Side Equipment On-
exchange with the . It is composed of the
Board Unit and other sub-units whose presence have to be considered
optional for the execution of a Transaction.

Minimum component of an On-Board Equipment, whose functionality
3.13 on-board unit
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,
On-
for the purpose of communication and data exchanges with the
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 Elementary communication service provided by the Application layer
protocol to the application processes.
(communication)
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 The operator that accepts the user's payment means and in return
(EFC) provides a road-use service to the user.

3.18 session The complete exchange of information and interaction occurring at a
Roadside
specific Electronic Fee Collection station between the
Equipment
and the user/vehicle.
3.19 transaction The whole of the exchange of information between the Roadside
Equipment and the On-Board Equipment necessary for the
completion of an Electronic Fee Collection operation over the DSRC.

NO TE: A transaction may require more than one session in order to
be achieved, e.g. an entry session and an exit session.

3.20 transaction model Functional model describing the general structure of Electronic Fee
Collection transactions.
3.21 user The entity that uses transport services provided by the Service
Provider according to the terms of a Contract.

©
ISO ISO/TR 14906:1998(E)
4 Abbreviations
For the purpose of this European Pre-Standard, the following abbreviations apply throughout the
document unless otherwise specified:

Application Data Unit
ADU
APDU Application Protocol Data Unit
Application Process
AP
ASN.1 Abstract Syntax Notation One
Beacon Service Table (DSRC Application Layer)
BST
DSRC Dedicated Short-Range Communications
Element ID
EID
Electronic Fee Collection
EFC
Global Positioning System
GPS
ICC Integrated Circuit(s) Card
Initialisation Kernel Element (DSRC Application Layer)
I-KE
IID Invoker ID
LID Link ID
MMI Man-Machine Interface
OBE On-Board Equipment
On-Board Unit
OBU
PDU Protocol Data Unit
Packed Encoding Rules
PER
Road-Side Equipment
RSE
Road Traffic and Transport Telematics
RTTT
SAM Secure Application Module
Transport-Application Protocol Data Unit (DSRC Application Layer)
T-APDU
T-ASDU Transport-Application Service Data Unit (DSRC Application Layer)
Transport Kernel Element (DSRC Application Layer)
T-KE
VST Vehicle Service Table (DSRC Application Layer)

©
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 provider. The services are offered by the DSRC communication entities by means of its DSRC
Application Layer (ENV 12834).

Additional abbreviations used only in this figure (for all other abbreviations see clause 4.)
B-KE Broadcast-Kernel Element
LLC Logical Link Control
LPDU Link Protocol Data Unit
MAC Medium Access Control
PHY-PDU Physical Link Protocol Data Unit
req/ind/rs/cf request/indication/response/confirm
EVENT-RT EVENT-REPORT
n.a. not applicable
Figure 2: The EFC application process on top of the DSRC communication stack

The Transfer Kernel Element (T-KE) 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. a 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.
©
ISO ISO/TR 14906:1998(E)
• 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 (see clause 7.4) 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.
• 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 I-KE as defined in ENV 12834,
which in its turn is configured by the application(s) wishing to execute applications over the DSRC link.

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 ENV 12834):

• The INITIALISATION services:
• (De-)Register Application RSE (at RSE)
•
Notify Application Beacon (at RSE)
• Ready Application (at RSE)
• (De-)Register Application OBE (at OBE)
• Notify Application Vehicle (at OBE)
are used to realise the EFC-specific initialisation mechanism (see clause 6)
•
The GET service is used to retrieve EFC attributes (see annex B.2.1. For attribute specifications
see clause 8)
• The SET-service is used to set EFC attributes (see annex B.2.2)
• 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 clause 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 Ready
Application of ENV 12834). 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. All data elements
of an ASN.1 type are mandatory. To each data element an unambiguously defined name is associated.

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:

Basic addressing mechanism
Figure 3:
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
clause 6.1.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.
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 clause 7.2).

5.3.3 Multiple Instances of Attributes
There may be n 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
max
operators and users. The default maximum number of instances is N =1. The value of N is
max max
determined at the time of OBE configuration.

Figure 5: Multiple instances (0-2) of attribute 5
©
ISO ISO/TR 14906:1998(E)
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
clause 7.2.5 for GET_INSTANCE and clause 7.2.6 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
• Beeper
• Printer
• Serial interface
•
Parallel interface
• GPS
• Tachograph
Addressing of these components is enabled on two levels, device-specific and device-independent
addressing.
device-specific transparent addressing mechanism
The enables the transfer of information, which
shall be processed by the addressed device (such as an ICC-command). The addressed device is
channel Id
identified by a . The EFC function TRANSFER_CHANNEL (see clause 7.2.9) supports this
functionality.
EXAMPLE: Transfer of a bit string to an ICC.

device-independent addressing mechanism
The 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 clause 7.2.11).

EXAMPLE: Invocation of a SET_MMI(EID=0, ContactOperator) function activates an OBE MMI-device,
e.g. a beeper or a display.
NOTE: In addition, the OBE may use a kind of implicit addressing. In an 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).
©
6 EFC Transaction Model
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.

6.1 Initialisation Phase
6.1.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 BST and VST exchanges, are defined in ENV 12834. Clauses
6.1.2 and 6.1.3 below account for the EFC application-specific information that shall be included in the
BST and VST, respectively.
NOTE 1: 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 the OBE shall not exchange any information with the
RSE. If the OBE supports at least one of the application(s) supported by the RSE, then the OBE
shall send its corresponding VST, informing the RSE of which application it wishes to execute.

NOTE 2: Figure 6 describes the initialisation phase.

Figure 6: Initialisation phase: BST - VST exchanges

©
ISO ISO/TR 14906:1998(E)
The Initialisation service associated with the initialisation phase is only used by the I-KE (of ENV 12834),
which in its turn is configured by the application(s) wishing to execute applications over the DSRC link.
The I-KEs of the RSE and of the concerned OBE shall have been configured, according to ENV 12834,
prior to the invocation of the Initialisation service by the RSE.

6.1.2 EFC application-specific contents of the BST
An RSE supporting EFC shall have configured its I-KE 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.

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 clause
6.1.3) or not.
NOTE 1: The above is the EFC application-specific contents of the BST. The complete
BST is defined in ENV 12834 and is given below for readability:

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
}
NOTE 2: There is likely to be assigned other aid values for identification of non-European EFC
contexts, where those contexts will define the usage of eid and parameter fields (e.g. non empty).

6.1.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. If several EFC applications are supported
by an OBE, then the order in which the EFC-ContextMark are presented in the VST shall correspond to
the user’s order of preference. The RSE should honour the first EFC-ContextMark that it supports as
presented in the VST.
An OBE supporting EFC shall have configured its I-KE to carry the following information related
specifically to the concerned EFC application:
•
the AID shall be equal to 1;
•
the EID value shall be unique within the OBE throughout the complete DSRC session, and shall be
logically associated with the corresponding EFC-ContextMark contained in the Parameter;
• 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 1: The above is the EFC application-specific contents of the VST. The complete VST is
defined in ENV 12834 and is given below for readability:

VST ::=  SEQUENCE {
fill Bit STRING (SIZE(4))
profile Profile,
applications ApplicationList,
obeConfiguration ObeConfiguration
}
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 2: There is likely to be assigned other aid values for identification of non-European EFC
contexts, where those contexts will define the usage of eid and parameter fields.

NOTE 3: 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.2 Transaction phase
After completion of the Initialisation phase, the appropriate RSE application is informed (by means of the
Notify Application Beacon service) of the EFC-ContextMark(s) and associated EID(s). 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, Fee)
• 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 are implemented and which are not, 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 Pre-
Standard. These implementation dependent aspects are referenced unambiguously by the
ContextVersion data element in the EFC-ContextMark.

©
ISO ISO/TR 14906:1998(E)
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.

©
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 (ENV 12834). 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 clause 6.2.2.4 in ENV 12834, or annex B.1 in this European
Pre-Standard).
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 European Pre-Standard, 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 f
...

TECHNICAL
REPORT
First edition
1998-l 2-15
Road Transport and Traffic Telematics
(RTTT) - Electronic Fee Collection (EFC) -
Application interface definition for
dedicated short range communications
T&matique de la circulation et du transpot? routier - Perception du
L ‘interlace applicative relative aux communications dbdikes
tkkpkage -
aux courtes port&es
Reference number
~~
ISO/TR 14906: 1998(E)
ISOPTR 14906: 1998(E)
Foreword
IS0 (the International Organization for Standardization) is a worldwide
federation of national standards bodies (IS0 member bodies). The work of
preparing International Standards is normally carried out through IS0
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. IS0
collaborates closely with the International Electrotechnical Commission
(IEC) on all matters of electrotechnical standardization.
The main task of technical committees is to prepare International
Standards, but in exceptional circumstances a technical committee may
propose the publication of a Technical Report of one of the following types:
when the required support cannot be obtained for the
- type 19
publication of an international Standard, despite repeated efforts;
- type 2, when the subject is still under technical development or where
for any other reason there is the future but not immediate possibility of
an agreement on an International Standard;
- type 3, when a technical committee has collected data of a different
kind from that which is normally published as an International Standard
(“state of the art”, for example).
Technical Reports of types 1 and 2 are subject to review within three years
of publication, to decide whether they can be transformed into International
Standards. Technical Reports of type 3 do not necessarily have to be
reviewed until the data they provide are considered to be no longer valid or
useful.
ISO/TR 14906, which is a Technical Report of type 2, was prepared by
European Committee for Standardization (CEN) in collaboration with IS0
Technical Committee lSO.FTC 204, Transport information and control
systems, in accordance with the Agreement on technical cooperation
between IS0 and @EN (Vienna Agreement).
0 IS0 1998
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 the publisher.
International Organization for Standardization
Case postale 56 l CH-1211 Geneve 20 l Switzerland
Internet iso @I iso.ch
Printed in Switzerland
ii
@ IS0
This document is being issued in the Technical Report (type 2) series of
publications (according to subclause G.3.2.2 of part 1 of the ISO/IEC
Directives, 1995) as a “prospective standard for provisional application” in
the field of transport information and control systems because there is an
urgent need for guidance on how standards in this field should be used to
meet an identified need.
This document is not to be regarded as an “International Standard”. It is
proposed for provisional application so that information and experience of
its use in practice may be gathered. Comments on the content of this
document should be sent to the ISO/TC 204 Secretariat.
A review of this Technical Report (type 2) will be carried out not later than
three years after its publication with the options of: extension for another
three years; conversion into an International Standard; or withdrawal.
Annex A forms an integral part of this Technical Report. Annexes B to D
are for information only.
-.
ttt
@ IS0
ISOTTR 14906: 1998(E)
CONTENTS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.==.=.=. vi
Foreword
vi
introduction ~.,,.,.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.=.===.*. 1
1 Scope
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Normative references
. . . . . . . . . . . . . . . . . . . . . . . . .~.~. 3
3 Definitions
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*. 5
4 Abbreviations
5 EFC application interface architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .“.*.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .“.
5.1 Relation to the DSRC communication architecture
interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Usage of DSRC application layer by the EFC application
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Addressing of EFC attributes
5.3. I Basic mechanism . . . . . . . .*.*.*.*.
5.3.2 Role of the EID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53.3 Multiple Instances of Attributes ,.,.,.,. 8
5.4 Addressing of components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .*.*.*. 10
6 EFC Transaction Model
6.1 lnitialisation Phase . 10
6.1. I Overview .
................................................................................ II
6.1.2 EFC application-specific contents of the BST
II
6.1.3 EFC application-specific contents of the VST .
................................................................................................................................ 12
6.2 Transaction phase
7 EFC Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~.
7.1 Overview and general concepts .
............................................................................................. 14
7.1. I EFC functions and service primitives
............................................................................................................. 15
7.1.2 Overview of EFC functions
........................................................................................................ 16
7.1.3 Handling of multiple instances
7.1.4 Security .
7.2 EFC functions . 18
7.2.1 GET STAMPED . 18
7.2.2 SET-STAMPED . 19
7.2.3 GET SECURE . 20
7.2.4 SET-SECURE . 21
............................................................................................................................ 22
7.2.5 GET- INSTANCE
............................................................................................................................ 23
7.2.6 SET-INSTANCE
7.2.7 GET NONCE .
7.2.8 SET-NONCE . 25
7.2.9 TRANSFER CHANNEL . 26
........................................................................................................................................... 27
7.2.10 COPY -
MM/ . 28
7.2. I I SET
7.2.12 SUBTRACT .
7.2.13 ADD . 30
7.2.14 DEBIT . 31
7.2.15 CREDIT . 32
........................................................................................................................................... 33
7.2.16 ECHO
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8 EFC Attributes
8.1 Data group CONTRACT . 35
8.2 Data group RECEIPT . 36
8.3 Data group VEHICLE . 38
8.4 Data group EQUIPMENT . 39
8.5 Data group DRIVER . 39
8.6 Data group PAYMENT . 40

ISOKR 14906:1998(E)
0 IS0
ANNEX A (normative) EFC data type specifications . 41
..........................................................
Annex B (informative) An excerpt from DSRC application layer 48
..................................................................................................................
B.l Format of service primitives 48
............................................................................................
B.2 Generic DSRC application layer functions 50
B-2. I GET .
.................................................................................................................................................
B-2.2 SET 50
B.3 Container ASN.l type definition . 51
Annex C (informative) Examples of EFC transactions using the EFC application interface . . . . . . . . . . . .!Z
........................................................................................
C.l Example of an EFC transaction - Example 1 52
........................................................................................
C.2 Example of an EFC transaction - Example 2 53
........................................................................................
C.3 Example of an EFC transaction - Example 3 54
C.4 Example of an EFC transaction - Example 4 . 55
C.5 Example of an EFC transaction - Example 5 . 58
. . . . . . . . . . . . . .“.
ANNEX D (informative) Functional requirements 62

ISO/TR 149063 998(E)
Foreword
This European Prestandard has been prepared by Technical Committee CEN/TC 278 “Road transport and traffic
telematics”, the secretariat of which is held by NNI, in collaboration with Technical Committee ISO/TC 204
“Transport information and control systems”.
According to the CEIWCENELEC Internal Regulations, the national standards organizations of the following
countries are bound tit announce this European Prestandard: Austria, Belgium, Czech Republic, Denmark, Finland,
France, Germany,: GHXZXZ+ l&&and, Ireland, Italy, Luxembourg, Netherlands, Norway, Portugal, Spain, Sweden,
Switzerland and. the Ufrited? Kibgdom.
.*
Introduction
This European Pre-Standard specifies an application interface for Electronic Fee Collection (EFC) systems, which
are based on the Dedicated Short-Range Communication (DSRC), enabling interoperability between open EFC
systems (i.e. between different EFC system operators) on an EFC-DSRC application interface level.
The European P’re-Standard provides specifications for the EFC transaction model, EFC data elements (referred to
as attributes) &functions, from which an EFC transa&m ~ZHI be Buick The EFC ~KXIZZK%~~~ modeE pt-s%rades a
mechanism t&&allows handling of diff erm v&as Q# EFC’ t@ansati~~ a~~3 as~ciate-d contrac& A certain EFC
transaction supports a certain set of ElXZ at%tib&es arid/ EFC functions as defined in this Ew;tq~a~ Pre-Standard, It
is not envisaged that the complete set! of EFC at&i&~&s an& fun&‘~ns is present in each1 piece. of EFC equipment,
be OBE or RSE.
This European Pre-Standard provides the basis for agreemems between apera#ors, W#I&~I ale needed &I achieve
.
.
interoperability. Based on the tools specified in this European Pre-Standard, interoperability can be
bY
operators recognising each others EFC transactions (including the exchange of security algorithms and keys) ati
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 also have to be made by each operator that the
RSE has sufficient resources to implement such additional EFC transactions.
Warder to achieve interoperability, operators have to agree on issues like:
l n,which optional features are actually being implemented and used;
security policy (including encryption algorithms and key management, if applicable);
l
0 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);
l the-agreements needed between operators in order to regulate the handling of different EFC transactions.
This E.uropean Pre-Standard has the following structure. In the first four clauses the scope, normative references,
definitions of terms and abbreviations a.re 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 spe.cification of the EFC application functions and of the EFC data attributes, respectively. Four
annexes proM&
- the normative ASN.l specifications of the used data types (EFC action parameters and
attributes);
-
an informative excerpt from DSRC application layer (ENV 12834), and its service primitives,
parameters and functions;
-
informative examples of EFC transactions using the specified EFC attributes and functions;
- an informative listing of functional requirements, which can be satisfied by using the tools
provided by this European Pre-standard.

@ IS0 ISO/TR 14906:1998(E)
1 Scope
This European Pre-Standard specifies the application interface in the context of Electronic Fee Collection
(EFC) systems using the Dedicated Short-Range Communications (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 European Pre-Standard comprises specifications of:
l EFC attributes (i.e. EFC application information);
l the addressing procedures of EFC attributes and (hardware) components (e.g. ICC and MMI);
l 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;
l the EFC transaction model, which defines the common elements and steps of any EFC transaction;
l the behaviour of the interface so as to ensure interoperability on an EFC-DSRC application interface
level.
OBE
Application Process
Application Process
m1~--1m1111mmD~mmm1~I mm111-1-
I -
Scope of this I
I
ADU
Atttibutes (e.g. Payment Means,
Attributes (e.g. Payment&leans,
I European ,
I
VehicleDimensions, .)
VehicleDimensions, .)
Pre-standard ,
I
ActionType (e.g. debit, setJ&lI, ActionType (e.g. debit, set-MM&
transfer-channel, etc.) transfer -channel, etc.)
D
Notify Application
I 1 Notify AppVehicle I
ACTlON.rs
ACTION.cf
I
Ready Application
SET.cf SET.rs
I
GET.cf GET.rs
I
-mm-1)mmmmm
- T-ASDU - - -t”-c” - T-ASDU v -
DSRC
I-KE I-KE
DSRC
Application
Application
Layer
Layer
* I
I
i* T
T-APDU
T-KE .*I
KE KE
Figure 1: The EFC application interface
This is an interface standard, adhering to the open systems interconnection (OSI) philosophy (lSO/lEC
7498-l), and it is as such not concerned with the implementation choices to be realised at either side of
the interface.
This European Pre-Standard 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 European Pre-Standard.
2 Normative references
This European Pre-Standard incorporates by dated or undated reference, provisions from other
publications.
IS0R-R 14906:1998(E)
These normative references are cited at the appropriate places in the text and the publications are
listed hereafter.
For dated references, subsequent amendments to or revisions of any of these publications apply to
this European Pre-Standard only when incorporated in it by amendment or revision. For undated
references the latest edition of the publication referred to applies.
Vehicle Measurement Definition
IS0 612:
Vehicle Weight Definitions
IS0 1176:
Codes for the representation of names of countries
IS0 3166:
Road Vehicles - Vehicle Identification Number (VIN)
IS0 3779: 1983
Content and Structure
Road Vehicles World manufacturer identification code (WMI)
IS0 3780: 1983
Codes for the representation of currencies and funds
IS0 4217:
Information Processing Systems - Open Systems
IS0 7498-l : 1994
Interconnection - Basic Reference model
1995 Information processing systems - Open Systems
ISOAEC 8824-l :
Interconnection - Specification of abstract syntax notation one
(ASN.l)
1996 Information processing systems - Open Systems
ISOAEC 8825-2:
Interconnection - ASN.1 encoding rules: Specification of
Packed encoding rules
ENV 1545-I 1998 Identification card systems - Surface transport applications -
Part 1 : General data elements
ENV 1545-2 1998 Identification card systems - Surface transport applications -
Part 2 : Transport payment related data elements
prENV IS0 14816: 1998 Road Traffic and Transport Telematics (RTTT), Automatic
Vehicle and Equipment Identification - Numbering and Data
Structures (ISO/DTR 14816 : 1998)
ENV 12834: 1997 Road Traffic and Transport Telematics (RTTT), Dedicated
Short-Range Communication (DSRC) - Application Layer

@ IS0 ISO/TR 14906:1998(E)
3 Definitions
For the purposes of this European Pre-Standard, the following definitions apply:
access credentials Data that is transferred to On-Board Equipment, in order to establish
31 .
the claimed identity of an 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
weli as cryptographic based information such as authenticators.
Function that an application process resident at the Roadside
3.2 action
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.
Data appended to, or a cryptographic transformation (see
3.4 authenticator
cryptography) 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.
An information transfer path [ISO/IEC 7498-21.
3.5 channel
Logical and physical entity composing an On-Board Equipment,
3.6 component
supporting a specific functionality.
3.7 contract Expression of an agreement between two or more parties concerning
the use of the road infrastructure.
The discipline which embodies principles, means, and methods for the
3.8 cryptography
transformation of data in order to hide its information content, prevent
its undetected modification or/and prevent its unauthorised use
[ISO/IEC 7498-21.
A collection of closely related EFC data attributes which together
3.9 data group
describe a distinct part of an Electronic Fee Collection transaction.
The property that data has not been altered or destroyed in an
3.10 data integrity
unauthorised manner [ISO 7498-21.
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 Road Side 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 Minimum component of an On-Board Equipment, whose functionality
always includes at least the support of the DSRC interface.
Equipment located at a fixed position along the road transport network,
3.14 roadside equipment
for the purpose of communication and data exchanges with the On-
Board Equipment of passing vehicles.

lSO/TR 14906: 1998(E) @ IS0
Road transport related facility provided by a Service Provider. Normally
3.15 service (EFC)
a type of infrastructure, the use of which is offered to the User for
which the User may be requested to pay.
Elementary communication service provided by the Application layer
3.16 service primitive
protocol to the application processes.
(communication)
NOTE: The invocation of a service primitive by an application process
implicit/y calls upon and uses services offered by the lower protocol
layers.
The operator that accepts the user’s payment means and in return
3.17 service p~~4kl&sl
provides a road-use service to the user.
(EFC)
The complete exchange of information and interaction occurring at a
3.18 session
specific ElecW~nic Fee Cokction station between the Roadside
LEip&mm& anid! the userhehicle.
J .
The w&&e o# the exchange of information between the Roadside
3.19 transaction
Equipmzmf & he C?FI~%M~ Equipment necessary for the
completion cd ain Ekct~~nie Fee Cdktion operation over the DSRC.
NOTE: A transaction may require more than one session in order to
session and an exit session.
be achieved, e.g. an enfry
Functional model describ ing the general structure of Electronic Fee
3.20 transaction model
Collection transactions.
The entity that uses transport services provided by the Service
3.21 user
Provider according to the terms of a Contract.

@ IS0 ISO/Tl? 14906: 1998(E)
4 Abbreviations
For the purpose of this European Pre-Standard, the following abbreviations apply throughout the
document unless otherwise specified:
Application Data Unit
ADU
Application Protocol Data Unit
APDU
Application Process
AP
Abstract Syntax Notation One
ASN.l
Beacon Service Table (DSRC Application Layer)
BST
DSRC Dedicated Short-Range Communications
Element ID
EID
Electronic Fee Collection
EFC
Global Positioning System
GPS
ICC Integrated Circuit(s) Card
lnitialisation Kernel Element (DSRC Application Layer)
I-KE
Invoker ID
IID
Link ID
LID
Man-Machine Interface
MMI
On-Board Equipment
OBE
On-Board Unit
OBU
PDU Protocol Data Unit
PER Packed Encoding Rules
Road-Side Equipment
RSE
RTTT Road Traffic and Transport Telematics
Secure Application Module
SAM
T-APDU Transport-Application Protocol Data Unit (DSRC Application Layer)
Transport-Application Service Data Unit (DSRC Application Layer)
T-ASDU
T-KE Transport Kernel Element (DSRC Application Layer)
Vehicle Service Table (DSRC Application Layer)
VST
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 provider. The services are offered by the DSRC communication entities by means of its DSRC
Application Layer (ENV 12834).
RSE OBE
ADU
AP
L I
L
A
Notify Application
Notify Application
GET.cf GE-h
Beacon
SET.cf SET.rs
T-ASDU
Ready Application
(De-) Reg AppVe hicle
ACTION .rs
ACTlONxf
(De-)register App Beacon
(EVENT-RT.rs)
(EVENT-RT.cfj
p.--.- . . . . . . .
.
i B-KE i
. s
•.~.~~.~~~~~~
+ :
n.a. for EF’C
I I
DSRC-L7 i-Ii,
T-APDU
LPDU
MAC sublayer
MAC sublayer
T
T
DS;;Physical- -jjc-Ll
Additional abbreviations used only in this figure (for all other abbreviations see clause 4.)
B-KE Broadcast-Kernel Element
LLC Logical Link Control
LPDU Link Protocol Data Unit
MAC Medium Access Control
PHY-PDU Physical Link Protocol Data Unit
req/ind/rs/cf
request/indication/response/confirm
EVENT-RT
EVENT-REPORT
n-a.
not applicable
Figure 2: The EFC application process on top of the DSRC communication stack
The Transfer Kernel Element (T-KE) of DSRC Application Layer offers the following services to application
processes (see also figure 2 above):
l GET: The invocation of a GET service request results in retrieval (i.e. a reading) of application
information (i.e. Attributes) from the peer service user (i.e. the OBE application process), a reply is
always expected.
l 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.

@ IS0
ISO/TR 14906: 1998(E)
e 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 (see clause 7.4) 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.
l EVENT-REPORT: The invocation of an EVENT-REPORT service request forwards a notification of an
event to the peer service user.
l 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 lnitialisation service is only used by the I-KE as defined in ENV 12834,
which in its turn is configured by the application(s) wishing to execute applications over the DSRC link.
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 ENV 12834):
The INITIALISATION services:
l (De-)Register Application RSE (at RSE)
l Notify Application Beacon (at RSE)
l Ready Application (at RSE)
(at OBE)
l (De-)Register Application OBE
0 Notify Application Vehicle (at OBE)
are used to realise the EFC-specific initialisation mechanism (see clause 6)
The GET service is used to retrieve EFC attributes (see annex B.2.1. For attribute specifications
see clause 8)
The SET-service is used to set EFC attributes (see annex B.2.2)
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 clause 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 Ready
Application of ENV 12834). 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. All data elements
of an ASN.l type are mandatory. To each data element an unambiguously defined name is associated.
To each EFC Attribute, an AttributeID is associated. The Attributeld enables to unambiguously identify and
address an EFC Attribute.
0 IS0
ISO/TR 14906: 1998(E)
EXAMPLE: Figure 3 illustrates the basic addressing mechanism:
..-.---.- . . . . .
Attribute ID $!!?ly. .T. . i
.
.
;-------------*~
.
.
Attribute .
,
a
.
. . . . .r.-.--.
+
---
. . . . . . . . . . . . .I.
.
. 1
ContractAuthenticator::= r - - - - - - - - ‘- - - - - - :
#
.
*
ASN. 1 -Tvpe i
.
ContractVehicle::= .
.
.
.
:
.
ContractValidity ::=SEQUENCE (
. .
*
--.*-.-I- . . . . . . 4 -.-.a-.-.-.---.
contractRestrictions OCTETSTRING(4);
i
ContractExpiryDate DateCompact
I
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
clause 6.1.3), in which Attributes can be addressed unambiguously by AttributeIDs. In the VST, the OBE
may specify severai of these EFC contexts, each corresponding to a set of EFC Attributes and EFC
functions supported by it.
. .s-.1.1.1.-.- ----------------
&t&ID = n i
iAttrlD=O i
L. . . . .a
. . . . . . . . .-.-.-e-w
.
.
. .
Contract t
I I .
IEID= I 1
IEID =2 I . . . . . . . . . .
.
.
.
.
Contract IContract 1 .
.
.
IEID=~ I .
Vehicle Authenticator
. . . . . . . . . . . . . . Y . .I.
.
.
c
C
.
I I I I .
I I
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 clause 7.2).
5.3.3 Multiple Instances of Attributes
There may be n instances of an Attribute available in an OBE.
The maximum number of instances N ma of one Attribute may be limited according to the needs of
operators and users. The default maximum number of instances is Nm,=l. The value of Nma is
determined at the time of 0 B E configuration.
Ex4IMPL~
AttrlD=O 1
1 I
eceiptServicePart2 I
IReceiptServicePartl
(O-2) of attribute 5
Figure 5: Multiple instances
@ IS0 ISO/TR 14906: 1998(E)
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
clause 7.2.5 for GET INSTANCE and clause 7.2.6 for SET-INSTANCE).
-
.
54 Addressing of components
Components of an OBE to be addressed via the EFC Application Interface include for example:
l OBU
0 SAM 1
l SAM2
l ICC
l Display
l Beeper
l Printer
l Serial interface
l Parallel interface
l GPS
l Tachograph
on two levels, device-specific and device-independent
Addressing of these components is enabled
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 clause 7.2.9) supports this
-
functionality.
EXAMPLE: 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 clause 7.2.11).
EXAMPLE: Invocation of a SET MMI(ElD=O, ContactOperator) function activates an OBE MM/-device,
-
e.g. a beeper or a display.
/VOTE: In addition, the OBE may use a kind of implicit addressing. In an implementation, specific
attributes or data elements may activate some MMI function (e.g. a SET command on the attribute
ReceiptText might disp/ay 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).
ISO/TR 14906: 1998(E)
@ IS0
6 EFC Transaction Model
The EFC Transaction Model related to the EFC Application Interface for the DSRC comprises ttio 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.
61 . lnitialisation Phase
6.1.1 Overview
This clause provides
an overview of the functionality of, and the information nges
in, the initialisation
phase.
The lnitialisation procedures, by means of BST and VST exchanges, are defined in ENV 12834. Clauses
6.1.2 and 6.1.3 below account for the EFC application-specific information that shall be included in the
BST and VST, respectively.
NOTE I: 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 the OBE shall not exchange any information with the
RSE. If the OBE supports at least one of the application(s) supported by the RSE, then the OBE
shall send its corresponding VST, informing the RSE of which application it wishes to execute.
NOTE 2: Figure 6 describes the initialisation phase.
RSE OBE
_----.-_--_-____________________________~~-.
AFC-
Layer 7
Application
T-KE I-KE
RegisterApplication
h INIT.rq(BST]
Beacon
RegAppVehicle
INIT.cf(llST)
Figure 6: lnitialisation phase: BST
I VST exchanges
@ IS0
The lnitialisation service associated with the initialisation phase is only used by the I-KE (of ENV 12834),
which in its turn is configured by the application(s) wishing to execute applications over the DSRC link.
The I-KEs of the RSE and of the concerned OBE shall have been configured, according to ENV 12834,
prior to the invocation of the lnitialisation service by the RSE.
6.12 EFC application-specific contents of the BST
An RSE supporting EFC shall have configured its I-KE to carry the following information related
specifically to the EFC application(s):
l the application identifier (AID) shall be equal to 1 (i.e. the value assigned for EFC);
a
the EFC application shall be qualified as a mandatory application;
l EID shall not be transmitted in the BST related to the EFC application;
l No Parameter shall be transmitted in the BST related to the EFC application.
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 clause
6.1.3) or not.
NOTE I: The above is the EFC application-specific contents of the BST. The complete
BST is defined in ENV 12834 and is given below for readability:
BST ::= SEQUENCE {
beacon Beacon/D,
time Time,
profile Profile,
mandApplications Application List,
nonmandApplications ApplicationList OPTIONAL,
profileList SEG?iJENCE(O. 127, . .) OF Profile
where:
Application Lis t ::= SEQUENCE (0. 127,. . .) OF
SEQUENCE{
aid DS RCApplica tion En titylD, --aid=1
eid Dsrc- E/D OPTIONAL,
--empty
parameter Container OPTlONAL --empty
J
NOTE 2: There is likely to be assigned other aid values for identification of non-European EFC
contexts, where those contexts will define the usage of eid and parameter fields (e.g. non empty).
6.1.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. If several EFC applications are supported
by an OBE, then the order in which the EFC-ContextMark are presented in the VST shall correspond to
the user’s order of preference. The RSE should honour the first EFC-ContextMark that it supports as
presented in the VST.
An OBE supporting EFC shall have configured its I-KE to carry the following information related
specifically to the concerned EFC application:
l the AID shall be equal to 1;
* the EID value shall be unique within the OBE throughout the complete DSRC session, and shall be
logically associated with the corresponding EFC-ContextMark contained in the Parameter;
l 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{
ISO/TR 14906: 1998(E)
ContractProvider Provider,
OCTET STRING (SIZE(2)),
TypeOfContract
INTEGER(O.127,.)
ContextVersion
)
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.
/WXE 1.: T.&z a&ave is the EFC application-specific contents of the VST. The complete VST is
&f&e&h. ENV’ T28i34 and is given below for readability:
VSY’ ::=
SEQUENCE {
fil Bit STRlNG (SIzE(4))
profile Profile,
applications Application Lis t,
0beConfiguration ObeConfigura tion
where:
Apprica tion Lis t ::= SEQUENCE (0. 127,.) OF
SEQUENCE{
aid DSRCApp&ationEntitylD, --aid 4
eid Dsrc-E/D OPTlONA L, --eid = e.g. 2
parameter Container OPTfONAL --EFC-ContextMark
--plus any EFC Attribute
I
NOTE 2: There is likely to be assigned other aid values for identification of non-European EFC
contexts, where those contexts will define the usage of eid and parameter fields.
NOTE 3: 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.2 Transaction phase
After completion of the lnitialisation phase, the appropriate RSE application is informed (by means of the
Notify Application Beacon service) of the EFC-ContextMark and associated EED(s). The WE 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:
0 GET(EID, Contract Validity, Contract Vehicle, ReceiptServicePart, PaymentMeansBalance)
l DEBIT(EID, Fee)
l 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 are implemented and which are not, 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 Pre-
Standard. These implementation dependent aspects are referenced unambiguously by the
ContextVersion data element in the EFC-ContextMark.
1998(
...