ISO/TS 17575-4:2011

TECHNICAL ISO/TS
SPECIFICATION 17575-4
First edition
2011-04-15
Electronic fee collection — Application
interface definition for autonomous
systems —
Part 4:
Roaming
Perception du télépéage — Définition de l'interface d'application pour
les systèmes autonomes —
Partie 4: Itinérance
Reference number
©
ISO 2011
©  ISO 2011
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 copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2011 – All rights reserved

Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Normative References.1
3 Terms and definitions .1
4 Abbreviated terms.4
5 Basic concept .4
5.1 General .4
5.2 Overview.5
6 Data elements .6
6.1 General .6
6.2 Elements of the roaming rules attribute .7
6.2.1 The roaming rule identifier .7
6.2.2 The list of relevant EFC contexts.7
6.2.3 The list of EFC contexts which are grouped using a single charge report.9
6.2.4 House keeping data elements.9
7 Communicating the roaming rules attribute.10
7.1 Requesting an update of the roaming rules attribute.10
7.2 Responding to a roaming rules download request .10
7.3 ASN1 coding rules.10
Annex A (normative) EFC data type specifications .11
Annex B (normative) PICS proforma .13
Annex C (informative) How to assemble and use roaming data.22
Bibliography.24

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.
In other circumstances, particularly when there is an urgent market requirement for such documents, a
technical committee may decide to publish other types of document:
⎯ an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in
an ISO working group and is accepted for publication if it is approved by more than 50 % of the members
of the parent committee casting a vote;
⎯ an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting
a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for a
further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or ISO/TS is
confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an
International Standard or be withdrawn.
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/TS 17575-4 was prepared by the European Committee for Standardization (CEN) Technical Committee
CEN/TC 278, Road transport and traffic telematics, 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).
ISO/TS 17575 consists of the following parts, under the general title Electronic fee collection — Application
interface definition for autonomous systems:
⎯ Part 1: Charging
⎯ Part 2: Communication and connection to the lower layers
⎯ Part 3: Context data
⎯ Part 4: Roaming
iv © ISO 2011 – All rights reserved

Introduction
Autonomous systems
This part of ISO/TS 17575 is part of a series of four specifications defining the information exchange between
the Front End and the Back End in Electronic Fee Collection (EFC) based on autonomous on-board
equipment (OBE). EFC systems automatically collect charging data for the use of road infrastructure including
motorway tolls, zone-based fees in urban areas, tolls for special infrastructure like bridges and tunnels,
distance-based charging, and parking fees.
Autonomous OBE operates without relying on dedicated road-side infrastructure by employing wide-area
technologies such as Global Navigation Satellite Systems (GNSS) and Cellular Communications Networks
(CN). These EFC systems are referred to by a variety of names. Besides the terms autonomous systems and
GNSS/CN systems, also the terms GPS/GSM systems, and wide-area charging systems are in use.
Autonomous systems use satellite positioning, often combined with additional sensor technologies such as
gyroscopes, odometers and accelerometers, to localize the vehicle and to find its position on a map containing
the charged geographic objects, such as charged roads or charged areas. From the charged objects, the
vehicle characteristics, the time of day and other data that are relevant for describing road use, the tariff and
ultimately the road usage fee are determined.
Some of the strengths of the autonomous approach to electronic fee collection are its flexibility, allowing the
implementation of almost all conceivable charging principles, and its independence from local infrastructure,
thereby predisposing this technology towards interoperability across charging systems and countries.
Interoperability can only be achieved with clearly defined interfaces, which is the aim and justification of
ISO/TS 17575.
Business architecture
This part of ISO/TS 17575 complies with the business architecture defined in ISO 17573. According to this
architecture, the Toll Charger is the provider of the road infrastructure and, hence, the recipient of the road
usage charges. The Toll Charger is the actor associated with the Toll Charging role. See Figure 1.
Interoperability
Management
Service
Provision
Toll
Charging
Service Usage
Figure 1 — The rolebased model underlying this Technical Specification
Service Providers issue OBE to the users of the road infrastructure. Service Providers are responsible for
operating the OBE that will record the amount of road usage in all toll charging systems the vehicle passes
through and for delivering the charging data to the individual Toll Chargers. In general, each Service Provider
delivers charging data to several Toll Chargers, as well as each Toll Charger in general receives charging
data from more than one Service Provider. Interoperability Management in Figure 1 comprises all
specifications and activities that in common define and maintain a set of rules that govern the overall toll
charging environment.
Technical architecture
The technical architecture of Figure 2 is independent of any particular practical realization. It reflects the fact
that some processing functionalities can either be allocated to the OBE or to an associated off-board
component (Proxy). An example of processing functionality that can be realized either on- or off-board is
map-matching, where the vehicle locations in terms of measured coordinates from GNSS are associated to
geographic objects on a map that either resides on- or off-board. Also tariffication can be done with OBE tariff
tables and processing, or with an off-board component.
Scope of
ISO 17575
Proxy
Processing Equipment
OBE
Front End Back End
Road Usage Data
Context Data
Figure 2 — Assumed technical architecture and interfaces
The combined functionality of OBE and Proxy is denoted as Front End. A Front End implementation where
processing is predominately on OBE-side is known as a smart client (or intelligent client, fat client) or
edge-heavy. A Front End where processing is mostly done off-board is denoted as thin-client or edge-light
architecture. Many implementations between the “thin” and “thick” extremes are possible, as depicted by the
gradual transition in the wedges in Figure 2. Both extremes of architectural choices have their merits and are
one means where manufacturers compete with individual allocations of functionality between on-board and
central resources.
Especially for thin client OBE, manufacturers might devise a wide variety of optimizations of the transfer of
localization data between OBE and off board components, where proprietary algorithms are used for data
reduction and data compression. Standardization of this transfer is neither fully possible nor beneficial.
Location of the specification interface
In order to abstract from, and become independent of, these architectural implementation choices, the primary
scope of ISO/TS 17575 is the data exchange between Front End and Back End (see the corresponding dotted
line in Figure 2). For every toll regime, the Back End will send context data, i.e. a description of the toll regime
in terms of charged objects, charging rules and, if required, the tariff scheme to the Front End, and will receive
usage data from the Front End.
vi © ISO 2011 – All rights reserved

It has to be noted also that the distribution of tasks and responsibilities between Service Provider and Toll
Charger will vary individually. Depending on local legal situation, Toll Chargers will require “thinner” or
“thicker” data, and might or might not leave certain data processing tasks to Service Providers. Hence, the
data definitions in ISO/TS 17575 may be useful on several interfaces.
ISO/TS 17575 also provides for basic media-independent communication services that may be used for
communication between Front End and Back End, which might be line-based or an air-link, and can also be
used for the air-link between OBE and central communication server.
The parts of ISO/TS 17575
Part 1: Charging, defines the attributes for the transfer of usage data from the Front End to the Back End. The
required attributes will differ from one Toll Charger to another, hence, attributes for all requirements are
offered, ranging from attributes for raw localization data, for map-matched geographic objects and for
completely priced toll transactions.
Part 2: Communication and connection to lower layers, defines basic communication services for data transfer
over the OBE air-link or between Front End and Back End.
Part 3: Context Data, defines the data to be used for a description of individual charging systems in terms of
charged geographical objects and charging and reporting rules. For every Toll Charger's system, attributes as
defined in Part 3 are used to transfer data to the Front End in order to instruct it which data to collect and
report.
Part 4: Roaming, defines the functional details and data elements required to operate more than one EFC
regime in parallel. The domains of these EFC regimes may or may not overlap. The charge rules of different
overlapping EFC regimes can be linked, i.e. they may include rules that an area pricing scheme will not be
charged if an overlapping toll road is used and already paid for.
Relations between single EFC schemes can be
⎯ EFC domains that can adjoin each other so that when moving from one EFC domain in the domain of the
adjacent EFC regime there may be a zone where the OBE starts to operate according to the rules of the
new regime before stopping the operation according to the old regime rules. Within this zone the
OBE/Front-End needs to operate according to the rules for both of these schemes at the same time.
⎯ Overlapping EFC contexts that can have dependencies in the charge object definition like overlapping
areas where the outer/bigger area will not be charged when in the inner area. Or an area will not be
charged when using a sectioned toll-road in the same area.
⎯ Required to combine several usage statements for different EFC schemes in the same charge report.
The data elements (ADUs) required to specify these related properties are defined in this part of
ISO/TS 17575.
Back End Front End
Back End Front End
Application Application
BE calls Front End calls
Scope of
ADU
communication communication
this suite of
Functions for EFC Functions for EFC
standards
communication communication
service primitives
service primitives
data communication service
Figure 3 — Scope of ISO/TS 17575
To communicate these ADUs between the Front End and the Back End, the same methodology as for
ISO/TS 17575-1 and ISO/TS 17575-3 is applied as illustrated in Figure 3. The use of the communication stack
is defined in ISO/TS 17575-2.
Applicatory needs covered by ISO/TS 17575
⎯ The parts of ISO/TS 17575 are compliant with the architecture defined in ISO 17573.
⎯ The parts of ISO/TS 17575 support charges for use of road sections (including bridges, tunnels, passes,
etc.), passage of cordons (entry/exit), and use of infrastructure within an area (distance, time).
⎯ The parts of ISO/TS 17575 support fee collection based on units of distance or duration, and based on
occurrence of events.
⎯ The parts of ISO/TS 17575 support modulation of fees by vehicle category, road category, time of usage,
and contract type (e.g. exempt vehicles, special tariff vehicles, etc.)
⎯ The parts of ISO/TS 17575 support limiting of fees by a defined maximum per period of usage.
⎯ The parts of ISO/TS 17575 support fees with different legal status (e.g. public tax, private toll).
⎯ The parts of ISO/TS 17575 support differing requirements of different Toll Chargers, especially in terms of
⎯ geographic domain and context descriptions,
viii © ISO 2011 – All rights reserved

⎯ contents and frequency of charge reports,
⎯ feedback to the driver (e.g. green or red light), and
⎯ provision of additional detailed data on request, e.g. for settling of disputes.
⎯ The parts of ISO/TS 17575 support overlapping geographic toll domains.
⎯ The parts of ISO/TS 17575 support adaptations to changes in
⎯ tolled infrastructure,
⎯ tariffs, and
⎯ participating regimes.
⎯ The parts of ISO/TS 17575 support the provision of trust guarantees by the Service Provider to the Toll
Charger for the data originated from the Front End.

TECHNICAL SPECIFICATION ISO/TS 17575-4:2011(E)

Electronic fee collection — Application interface definition for
autonomous systems —
Part 4:
Roaming
1 Scope
Roaming in the context of this part of ISO/TS 17575 is understood as the ability of a Front End to operate in
more than one EFC context either consecutively or at the same time. Data elements required defining
operational properties of a single EFC context are defined in ISO/TS 17575-3. The additional data elements
required providing interoperability in overlapping and/or interdependent EFC contexts are defined in this part
of ISO/TS 17575.
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.
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 14906, Road transport and traffic telematics — Electronic fee collection — Application interface definition
for dedicated short-range communication
ISO/TS 17575-2, Electronic fee collection — Application interface definition for autonomous systems — Part
2: Communication and connection to the lower layers
ISO/TS 17575-3:2011, Electronic fee collection — Application interface definition for autonomous systems —
Part 3: Context data
EN 15509:2007, Road transport and traffic telematics — Electronic fee collection — Interoperability
application profile for DSRC
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
associated EFC context
EFC context for which an individual user has the contractual consent that his or her Front End is interoperable
3.2
attribute
application information formed by one or by a sequence of data elements, used for implementation of a
transaction
NOTE Adapted from ISO 14906:2011.
3.3
authenticator
data appended to, or a cryptographic transformation 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
[ISO 14906:2011, definition 3.4]
3.4
Back End
generic name for the computing and communication facilities of the Service Provider and/or the Toll Charger
3.5
contract
expression of an agreement between two or more parties concerning the use of the road infrastructure
[ISO 14906:2011, definition 3.7]
3.6
Front End
part(s) of the toll system where road usage data for an individual road user are collected, processed and
delivered to the Back End
NOTE The Front End comprises the on-board equipment and an optional proxy.
3.7
interoperability
ability of systems to provide services to and accept services from other systems and to use the services so
exchanged to enable them to operate effectively together
3.8
on-board equipment
OBE
equipment fitted within or on the outside of a vehicle and used for toll purposes
NOTE The OBE does not need to include payment means.
[ISO 14906:2011, definition 3.13]
3.9
proxy
optional component of the Front End that communicates with on-board equipment and processes road usage
data into a format compliant with this part of ISO/TS 17575 and delivers the data to the Back End
3.10
roadside equipment
equipment located along the road transport network, for the purpose of communication and data exchanges
with on-board equipment
[ISO 14906:2011, definition 3.16]
3.11
service primitive (communication)
elementary communication service provided by the application layer protocol to the application processes
[ISO 14906:2011, definition 3.18]
NOTE The invocation of a service primitive by an application process implicitly calls upon and uses services offered
by the lower protocol layers.
2 © ISO 2011 – All rights reserved

3.12
service provider (toll)
legal entity providing its customers with toll services in one or more toll domains for one or more classes of
vehicle
3.13
system
something of interest as a whole or as comprised of parts
NOTE A system can be referred to as an entity. A component of a system can itself be a system, in which case it can
be called a subsystem.
3.14
toll
charge, tax, fee or duty in connection with using a vehicle within a toll domain
NOTE The definition is the generalization of the classic definition of a toll as a charge, a tax, or a duty for permission
to pass a barrier or to proceed along a road, over a bridge, etc. The definition above also includes fees regarded as an
(administrative) obligation, e.g. a tax or a duty.
3.15
toll charger
legal entity charging toll for vehicles in a toll domain
[ISO/TS 17574:2009, definition 3.27]
3.16
toll cluster
group of toll schemes operating under a common agreement providing interoperability for vehicles equipped
with an appropriate OBE and being contracted under a toll service provider being part of the cluster
3.17
toll context
logical view of a toll scheme as defined by attributes and functions
NOTE Adapted from ISO/TS 12813:2009.
3.18
toll domain
area or part of a road network where a toll regime is applied
[ISO 14906:2011, definition 3.21]
3.19
toll regime
set of rules, including enforcement rules, governing the collection of toll in a toll domain
3.20
toll scheme
organizational view of a toll regime, including the group of actors of one toll domain and their relationships
3.21
toll service
service enabling users having only one contract and one set of OBE to use a vehicle in one or more toll
domains
NOTE Adapted from ISO/TS 12813:2009.
3.22
toll system
overall view of a toll scheme or toll cluster
NOTE A component of a toll system can itself be a system, in which case it may be called a toll subsystem.
3.23
transaction
whole of the exchange of information between Front End and Back End necessary for the completion of a toll
operation
NOTE Adapted from ISO 14906:2011.
3.24
transaction model
functional model describing the general structure of Electronic Payment Fee Collection transactions
[ISO 14906:2011, definition 3.25]
3.25
user
generic term used for the customer of a toll service provider, one liable for toll, the owner of the vehicle, a fleet
operator, a driver, etc., depending on the context
[ISO 14906:2011, definition 3.26]
4 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply, unless otherwise specified.
ADU Application data unit
ASN.1 Abstract Syntax Notation One (ISO/IEC 8824-1)
EFC Electronic Fee Collection (ISO 14906); here used equivalently to the term toll in ISO 17573
NOTE The European Directive 2004/52/EC uses the term toll for the same purpose. However it refers to all kinds of
toll declaration means including manual ones. In contrast to this, this part of ISO/TS 17575 defines only electronic means
and includes also fees like parking fees.
GNSS Global Navigation Satellite Systems
VAT Value added tax
5 Basic concept
5.1 General
EFC Front Ends require a set of data elements describing the properties of the EFC regime they are operating
for. The basic structure of these data elements is defined in ISO/TS 17575-3. This allows configuring the Front
End according to the needs of the local Toll Charger. This includes finding or measuring toll relevant objects.
This includes also assembling elements to prepare and transmit appropriate charge reports to the Back End.
Single context EFC regimes may not require more than a single set of EFC context data and may not need
respecting any roaming rules.
NOTE 1 Single EFC context Front Ends may be used without any roaming rules. However, these Front Ends cannot be
upgraded handling more than one EFC context without adding the roaming functionality.
4 © ISO 2011 – All rights reserved

In more complex EFC clusters, the full scheme may consist of more than one EFC domain and/or each of
these domains may consist of more than one EFC regime and/or an EFC regime may use one or more of the
basic tolling principles each of them defined in an individual set of EFC context data.
This structure allows the implementation of an interoperable cluster of EFC regimes keeping the freedom for
each of the EFC regimes to define their own set of rules independent of those of others by defining the own
regime properties using one or more sets of context data as defined in ISO/TS 17575-3.
Such a composition of an EFC cluster may not be stable over time allowing new EFC regimes or contexts
joining this cluster and/or others may terminate their operation.
Front Ends need to adapt their behaviour according to these complex definitions. Front Ends shall apply this
concept of using multiple sets of context data complemented by a single set of roaming rules.
The roaming rules as defined in this part of ISO/TS 17575 provide a set of data elements which shall be used
by Front Ends when operating within the domain of an EFC cluster consisting of more than one set of EFC
context data. This mandatory use includes, if available, also optional data elements as defined in clause
6.2.2.8 and 6.2.3.
NOTE 2 It is most likely that the operation of Front Ends needs to be optimised concerning their computational load by
concentrating their operation on EFC domains where vehicles are in or close by. This allows setting the EFC application
software for individual known EFC domains to “dormant” and saves with this computing power, memory space and
external communication bandwidth. The roaming rules data elements include some optional data elements just for this
purpose.
The roaming rule data elements may be originated by each of the Toll Chargers defining therewith their
individual needs. Different Toll Chargers operating interdependent EFC schemes are responsible that both
their expectations of the overall Front End behaviour are consistent. In the context of this part of
ISO/TS 17575 this set of rules is understood as the roaming rules.
Roaming rules may also be part of the EFC context data the Toll Chargers are forwarding to the Toll Service
Providers. The Service Providers may eliminate duplications and may concentrate or reconfigure these rules
to one single set of roaming rules relevant for Front Ends in the entire interoperable EFC cluster. The structure
or format of these overall roaming rules is the same as for complex EFC regimes and is therefore also
applicable for the individual Toll Charger.
5.2 Overview
Roaming rules and the associated set of parameters are covering a number of different aspects of
interrelations between different EFC schemes. The following scenarios are supported:
a. EFC domains may adjoin each other. Roaming data may be used by a Front-End preparing to operate
according to the rules of the adjacent EFC domain. First the liability for paying toll for the current
vehicle class and time may be verified. In case the vehicle is liable for paying toll roaming data may
be used activating a process ensuring that all the relevant EFC context data are available and the
assembling of a new charge report is initialized. A resulting data download depends on the structure
and size of the Front End memory and may occur only if an EFC regime is new, is entered the first
time or after a long period of time where a previous version of roaming data was used.
The information required for this scenario are the geographic border of the adjacent EFC domain, its
identifier and the minimum vehicle class liable for paying toll.
b. If EFC domains partly or fully overlap then the aspect defined under scenario a. is still relevant. In
overlapping domains it may also be required to initialize a secure environment in the Front End to
assemble more than one charge report at a time.
Overlapping EFC regimes may have dependencies in the charge object definition. Examples may be
overlapping areas where the outer/bigger area will not be charged when being in the inner area. The
inner area may have an own tariff scheme. Or an area will not be charged when being on a sectioned
toll road in the same area which may or may not be charged.
It may also be specified if entering an inner area where the charging of the outer area is halted that
the assembled charge report shall be forwarded to the Back End or not. Small inner domains like
ferries operated by another Toll Charger may not interrupt the charge report assembling of the outer
area. On the other hand if the inner area is an urban region it may be quite likely that the vehicle will
stay longer insider so that it makes sense to close the assembling of a charge report for the outer
area and forward it to the Back End.
The information required to adapt an Front End to these regulations include a precedence level for
each of the participating EFC context indicating that only one or more EFC contexts set to the highest
precedence will apply the charge. Another parameter indicate that an EFC account shall be closed
and a charge report forwarded if an EFC domain is entered having a higher precedence level.
c. The overall tariff scheme of more complex EFC regimes may be defined using more than one
overlapping or non-overlapping basic EFC context. This may be an overall area like a country.
Another area may cover an urban region. A third area may be the downtown area of a city and over all
of that there may be a sectioned toll road network with a different tariff scheme. This all together may
be operated by a single Toll Charger.
This Toll Charger may require receiving a consolidated charge report including all his contexts. This
may also be used addressing the user with a single bill paying for the use of an entire region or
country.
Note: this may be used not to bother the User with details on how the regime is split into different contexts.
The information required to configure the charge report accordingly is a list of EFC contexts which
shall be consolidated and addressing a single Toll Charger.
d. A higher privacy regulation may require that in a more complex EFC regime consisting of several non-
or partly overlapping domains the presence of the vehicle shall not be disclosed in charge reports.
This may be done by aggregating and hiding all the charge objects but disclosing the regime identifier.
In such cases it may also be required hiding the fact that a vehicle was present in a certain domain. In
this case an aggregated fee may cover more than one EFC regime. However this needs to be
operated by the same Toll Charger so that the fee recipient is the same.
6 Data elements
6.1 General
The data set “roaming” consists of a single attribute named RoamingRules. For a Front End operating
according to the conditions of a specific User a single data set RoamingRules is required. This applies
independently of the complexity of the interoperable EFC cluster the Front End is operating for.
Without presumption of any implementation it is anticipated that the data elements of the roaming rules are
used in a Front End ensuring:
⎯ that each relevant EFC context is recognised as such and charging reports are assembled when the
vehicle is moving inside the domain
⎯ that for each of the relevant EFC contexts the associated EFC context data set is available in the Front
End. This shall be ensured at least when the vehicle is inside or in a fringe closely outside of the EFC
domain
⎯ that the information required handling interdependencies between EFC contexts regarding tariff
exclusivenesses are respected in the process evaluating the tariff due.
6 © ISO 2011 – All rights reserved

The information required to do so are the information provided by the RoamingRules attribute.
NOTE In contrast to the roaming rules all data elements required by Front End evaluating a single EFC context are
provided by the EFC context data attributes defined in ISO/TS 17575-3.
6.2 Elements of the roaming rules attribute
6.2.1 The roaming rule identifier
Within a Back End several roaming rules data sets will be originated and maintained. This is due to version
management and maybe caused if more than one option of combinations of interoperable EFC contexts for
different Users exists. In order to identify an individual set of roaming rules the identifier efcRoamingRulesId
shall be used. It is of the type Int2 and shall be unique within the domain of the Back End.
6.2.2 The list of relevant EFC contexts
6.2.2.1 General
An important information of the roaming attribute is the list of relevant EFC contexts defining the composition
of the EFC cluster where the Front End shall operate providing interoperability. This list may change over time
if the User has been registered for more or less of the existing EFC contexts, if new EFC regimes came up or
if other EFC regimes had or will terminate its operation. The information a Front End requires to do so is
provided with the relevantEfcContexts data element as a list of RelevantEfcContext. All existing EFC contexts
which are not listed in the relevantEfcContexts data element the Front End does not know and therefore will be
ignored.
NOTE It is seen to be outside the scope of this part of ISO/TS 17575 to provide means ensuring that proxies
operating for more than one OBE apply the correct version of roaming rules. This is especially important if Service
Providers offer the interoperability in different combinations of EFC contexts.
6.2.2.2 Sub elements of the RelevantEfcContext element
The data element RelevantEfcContext contains the sub data elements Front Ends need to manage the data
download of attributes of the context data from the Back End and to organize the internal operation.
6.2.2.3 The efcContextId sub element
The efcContextId shall be used to identify the EFC context. This identifier shall correspond with the identifier
used in the EFC context data as defined in ISO/TS 17575-3.
6.2.2.4 The reuseTariffInformationFrom sub element
As described above a Front End should optimise its external communication effort. Supporting this the
RelevantEfcContext data contains elements allowing to indicate that another EFC context applies identical
tariffs and that downloading a copy of the tariff information attribute is redundant.
In cases where different EFC contexts are using the same definition of tariff information it is more effective just
forwarding and storing this data attribute once. Then for another EFC context it may just be referenced to it
indicating that it shall be reused.
A Front End may use the list reuseTariffInformationFrom to organize this.
6.2.2.5 The reuseReportingRulesFrom sub element
As described in 6.2.2 also the reporting rules may be same in different EFC contexts. Then the
reuseReportingRulesFrom list may be used avoiding downloading and storing multiple instances of identical
reporting rules as defined in ISO/TS 17575-3.
6.2.2.6 The efcDomainFrame sub element
The efcDomainFrame element contains a BoundingPolygon which describes the outer fringe of an EFC
context. It depends on the requirements of the Front End what distance and resolution this bounding polygon
may have relative to the real EFC domain border. The distance assuming a certain vehicle speed shall allow
preparing for the adoption of the Front End behaviour according to this next EFC domain before its actual
border may be reached.
The BoundingPolygon itself is just a list of points consisting of a Latitude and a Longitude. It is implicit
assumed that the border is represented by a line connecting all these points in the order they are listed. The
last point shall be connected with the first one.
It is required that the Front End of a vehicle being inside the efcDomainFrame activate preparing to participate
according to the local EFC regime rules. This must be completed when the vehicle reaches the actual EFC
domain border as defined in ISO/TS 17575-3.
6.2.2.7 The liableVehicleClasses sub element
NOTE 1 The term “liable vehicle class” should be read as a vehicle class causing the driver being liable paying toll if
he's using a vehicle belonging to it.
This sub element indicates a list of vehicle groups as defined within the attribute VehicleClass in EN 15509. In
case the precise definition of the liable vehicle classes cannot be expressed with this vehicle groups one or
more comprehensive groups shall be used including all real liable classes. The EFC context data defined in
ISO/TS 17575-3 contain a more detailed vehicle class definition which will be applied by the Front End when
declaring a toll road usage.
NOTE 2 This may result in indicating a certain vehicle as “liable” for tolling in the roaming data set and “not liable” in
the EFC context data. The definition of the EFC context data finally will be applied.
6.2.2.8 The precedenceLevel sub element
In case two or more overlapping EFC domains are depending on each other regarding the declaration of toll
relevant events, the individual precedenceLevel of all of these domains may be used to manage that.
Independent of its implementation a declared toll object in an EFC domain of a higher precedence level shall
prevent the toll object declaration of the same kind or amount within an overlapping EFC domain with a lower
precedence level.
If both precedence levels are same, then both toll objects shall be declared or forwarded.
Note: An example for this may be an area tolling context which is crossed by an arterial road which is defined as being
“out of the area” and may have a different tariff scheme, including a zero price. This can be modelled defining first an EFC
context for the area (covering the sectioned toll road) and a second EFC context for the sectioned toll road separately. If
the sectioned toll road context has a higher precedence level then the process assembling the usage statement for the
area context must ignore the distance of the sectioned toll road or - if it is a time based scheme - ignore the presence in
the area for the time being at the sectioned toll road.
6.2.2.9 The sendChargeReportIfEntering sub element
Note: the term “close account” should be understood as terminating the assembling of usage data for a certain EFC
context. This will result in forwarding the assembled usage data in a charge report to the Back End.
This sub element may be applied in overlapping EFC domains where the probability of staying longer inside
the domain with a higher precedence level is quite high.
Here it can be defined that the charge report assembled for the former used EFC context shall be closed
when entering one of the domains listed in sendChargeReportIfEntering with a higher precedence level.
NOTE An example for that may be a country wide area toll which will be paid to the state authority and an
overlapping urban regional area toll which may be paid to the regional authority. When entering the regional area it may be
intended to close the country toll account and forward it to the state authority in the moment the regional area is entered.
8 © ISO 2011 – All rights reserved

6.2.3 The list of EFC contexts which are grouped using a single charge report
The data element combinedChargeReportContexts provides a list of one or more
CombinedChargeReportContext. When listed a single charge report shall be provided to a single tollRecipient
covering the usage statements of these EFC contexts. These are still listed in relevantEfcContexts and further
in the appropriate EFC context identified by the efcContextId element.
In order to identify different clusters the element reportingClusterId is provided. It shall be unique within the
entire EFC cluster the Back End is managing.
Because the Charge reports generated for different EFC contexts will be forwarded to a single recipient the
tollRecipient data element shall be used identifying it.
6.2.4 House keeping data elements
Each roaming rule data set contains a roamingRuleVersion in the format of VersionAndValidity and an
authenticator in the format of MessageAuthenticator both as defined in ISO/TS 17575-3.
Table 1 — Major Data Elements
Attribute/Element Scenario Remark
efcRoamingRulesId General Data type Int2
roamingRulesVersion date and time when validity period of
this set of roaming data starts
authenticator authenticator of the full set of roaming
data attribute signed by the originator
of the content
relevantEfcContexts EFC contexts List of adjoining EFC domains
relevant for the
RelevantEfcContext list
Front End
efcContextId   entity identifier according to
ISO 14906
reuseTariffInformationFrom
reuseReportingInformationFrom
efcDomainFrame bounding polygon
liableVehicleClasses list of toll liable vehicle class groups
according to EN 15509
precedenceLevel Identifier of priority if all, some or a
single context is charged
sendChargeReportIfEntering list of EFC contexts when entered
triggering a charge event of the
former context
combinedChargeReportContexts Limulti EFC context st of overlapping EFC contexts
schemes using a requiring a common charge report
common charge
CombinedChargeReportContext list
report
reportingClusterId entity identifier according to
...