prEN ISO 17575-4

SLOVENSKI STANDARD
01-februar-2014
Elektronsko pobiranje pristojbin - Definicija aplikacijskega vmesnika za
avtonomne sisteme - 4. del: Gostovanje (ISO/DIS 17575-4:2013)
Electronic fee collection - Application interface definition for autonomous systems - Part
4: Roaming (ISO/DIS 17575-4:2013)
Elektronische Gebührenerhebung - Definition der Anwendungsschnittstelle für autonome
Systeme - Teil 4: Roaming (ISO/DIS 17575-4:2013)
Perception du télépéage - Définition de l'interface d'application pour les systèmes
autonomes - Partie 4: Itinérance (ISO/DIS 17575-4:2013)
Ta slovenski standard je istoveten z: prEN ISO 17575-4
ICS:
03.220.20 Cestni transport Road transport
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

DRAFT INTERNATIONAL STANDARD
ISO/DIS 17575-4
ISO/TC 204 Secretariat: ANSI
Voting begins on: Voting terminates on:
2013-12-12 2014-05-12
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
[Revision of first edition (ISO/TS 17575-4:2011)]
ICS: 35.240.60;03.220.20
ISO/CEN PARALLEL PROCESSING
This draft has been developed within the International Organization for
Standardization (ISO), and processed under the ISO lead mode of collaboration
as defined in the Vienna Agreement.
This draft is hereby submitted to the ISO member bodies and to the CEN member
bodies for a parallel five month enquiry.
Should this draft be accepted, a final draft, established on the basis of comments
received, will be submitted to a parallel two-month approval vote in ISO and
THIS DOCUMENT IS A DRAFT CIRCULATED
formal vote in CEN.
FOR COMMENT AND APPROVAL. IT IS
THEREFORE SUBJECT TO CHANGE AND MAY
NOT BE REFERRED TO AS AN INTERNATIONAL
STANDARD UNTIL PUBLISHED AS SUCH.
To expedite distribution, this document is circulated as received from the
IN ADDITION TO THEIR EVALUATION AS
committee secretariat. ISO Central Secretariat work of editing and text
BEING ACCEPTABLE FOR INDUSTRIAL,
composition will be undertaken at publication stage.
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
Reference number
NATIONAL REGULATIONS.
ISO/DIS 17575-4:2013(E)
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
©
PROVIDE SUPPORTING DOCUMENTATION. ISO 2013

ISO/DIS 17575-4:2013(E)
Copyright notice
This ISO document is a Draft International Standard and is copyright-protected by ISO. Except as
permitted under the applicable laws of the user’s country, neither this ISO draft nor any extract
from it may be reproduced, stored in a retrieval system or transmitted in any form or by any means,
electronic, photocopying, recording or otherwise, without prior written permission being secured.
Requests for permission to reproduce should be addressed to 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
Reproduction may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.
ii © ISO 2013 – All rights reserved

ISO/DIS 17575-4
Contents Page
Foreword . v
Introduction . vi
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) Protocol implementation conformance statement (PICS) proforma . 14
B.1 General . 14
B.2 General . 14
B.3 Purpose and structure . 14
B.4 Instruction for completing the PICS Proforma . 14
B.4.1 Definition of support . 14
B.4.2 Status column . 15
B.4.3 Support column . 15
B.4.4 Item reference numbers . 15
B.5 PICS proforma for the Front End . 16
B.5.1 Identification of the implementation . 16
B.5.2 Identification of the standard . 17
B.5.3 Global statement of conformance . 17
B.5.4 PICS proforma tables . 17
B.6 PICS proforma for the Back End . 20
B.6.1 Identification of the implementation . 20
B.6.2 Identification of the standard . 21
B.6.3 Global statement of conformance . 21
B.6.4 PICS proforma tables . 22
Annex C (informative) How to assemble and use roaming data . 24
C.1 General . 24
C.2 First to decide on the required different sets of roaming data . 24
C.3 Next to assemble specific context data sets . 25
C.4 Next to combine EFC contexts to EFC rwegimes . 25
C.5 Finally to assign groups of Users to single sets of roaming rules . 25
iii
ISO/DIS 17575-4
Annex D (informative) Use of this standard for the EETS .27
D.1 General .27
D.2 Overall relationship between European standardisation and the EETS .27
D.3 European standardisation work supporting the EETS .27
D.4 Correspondence between this standard and the EETS .28
Bibliography .29

iv
ISO/DIS 17575-4
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 17575-4 was prepared by Technical Committee ISO/TC 204, Intelligent Transport Systems,
Subcommittee SC , and by Technical Committee CEN/TC 278, Intelligent Transport Systems in collaboration.
This second/third/. edition cancels and replaces the first/second/. edition (), [clause(s) / subclause(s) /
table(s) / figure(s) / annex(es)] of which [has / have] been technically revised.
This second edition cancels and replaces the first edition (ISO/TS 17575 Part 4:2011) which has been
technically revised. The main changes comprise
¾ upgrade of the first edition from a Technical Specification to an International Standard
¾ editorial and formal corrections as well as changes to improve readability
ISO 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
v
ISO/DIS 17575-4
Introduction
Autonomous systems
This part of ISO 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.
NOTE 1 The Front End comprises the on-board equipment and an optional proxy.
NOTE 2 The OBE does not need to include payment means.
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
17575.
Business architecture
This part of ISO 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.
vi
ISO/DIS 17575-4
Interoperability
Management
Service
Provision
Toll
Charging
Service Usage
Figure 1 — The rolebased model underlying this International Standard
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
vii
ISO/DIS 17575-4
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 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.
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 17575 may be useful on several interfaces.
ISO 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 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.
viii
ISO/DIS 17575-4
¾ 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 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 17575
To communicate these ADUs between the Front End and the Back End, the same methodology as for ISO
17575-1 and ISO 17575-3 is applied as illustrated in Figure 3. The use of the communication stack is defined
in ISO 17575-2.
Application needs covered by ISO 17575
¾ The parts of ISO 17575 are compliant with the architecture defined in ISO 17573.
¾ The parts of ISO 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 17575 support fee collection based on units of distance or duration, and based on
occurrence of events.
¾ The parts of ISO 17575 support modulation of fees by vehicle category, road category, time of usage, and
contract type (e.g. exempt vehicles, special tariff vehicles, etc.)
ix
ISO/DIS 17575-4
¾ The parts of ISO 17575 support limiting of fees by a defined maximum per period of usage.
¾ The parts of ISO 17575 support fees with different legal status (e.g. public tax, private toll).
¾ The parts of ISO 17575 support differing requirements of different Toll Chargers, especially in terms of
¾ geographic domain and context descriptions,
¾ 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 17575 support overlapping geographic toll domains.
¾ The parts of ISO 17575 support adaptations to changes in
¾ tolled infrastructure,
¾ tariffs, and
¾ participating regimes.
¾ The parts of ISO 17575 support the provision of trust guarantees by the Service Provider to the Toll
Charger for the data originated from the Front End.

x
DRAFT INTERNATIONAL STANDARD ISO/DIS 17575-4

Electronic fee collection — Application interface definition for
autonomous systems — Part 4: Roaming
1 Scope
Roaming in the context of this part of ISO 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 17575-3. The additional data elements required
providing interoperability in overlapping and/or interdependent EFC contexts are defined in this part of ISO
17575.
A set protocol implementation conformance statement (PICS) proforma is specified in Annex B.
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 17573, Electronic fee collection — Systems architecture for vehicle-related tolling
ISO 14906:20011, Electronic fee collection — Application interface definition for dedicated short-range
communication
ISO 17575-1, Electronic fee collection — Application interface definition for autonomous systems — Part 1:
Charging
ISO 17575-2, Electronic fee collection — Application interface definition for autonomous systems — Part 2:
Communication and connection to the lower layers
ISO 17575-3, Electronic fee collection — Application interface definition for autonomous systems — Part 3:
Context data
EN 15509:2013, 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
attribute
addressable package of data consisting of a single data element or structured sequences of data elements
ISO/DIS 17575-4
[ISO 14906:2011]
3.2
authentication
provision of assurance that a claimed characteristic of an entity is correct
[ISO 2700]
3.3
authenticator
data, possibly encrypted, that is used for authentication
[ISO 14906:2011]
3.4
Back End
computing and communication facilities of an actor (e.g. a Toll Charger or a Toll Service Provider) exchanging
data with a Front or Back End
[ISO/TS 16410:2011]
3.5
Contracted EFC context
EFC context for which an individual user has the contractual consent that his or her Front End is interoperable
3.6
Front End
parts of the toll system where usage data for an individual user are collected, processed and delivered to the
Back End
[ISO 16403-2:2012]
3.7
interoperability
ability of systems to exchange information and to make mutual use of the information that has been
exchanged
[CEN/TR 16092:2011]
3.8
on-board equipment
OBE
equipment located on-board a vehicle including nomadic devices with the function of exchanging information
with external systems
[ISO 14906:2011]
3.9
proxy
optional part of a Front End that communicates with external equipment and processes the data received into
an agreed format to be delivered to the Back End
[ISO/TS 17575-1:2010]
3.10
2 © ISO 2013 – All rights reserved

ISO/DIS 17575-4
roadside equipment
equipment located along the road, ether fixed or mobile
[ISO 17574:2009]
3.11
service provider
toll service provider
entity providing toll services in one or more toll domains
[CEN/TR 16092:2011]
3.12
toll
any charge, tax or duty levied in relation with using a vehicle in a toll domain
[CEN/TR 16092:20011]
3.13
toll charger
entity which levies toll for the use of vehicles in a toll domain
[CEN/TR 16092:20011]
3.14
toll cluster
a group of toll schemes operating under a common agreement providing interoperability for road users having
a contract with a service provider being part of the cluster
[ISO/TS 17575-120110]
3.15
toll context
logical view as defined by attributes and functions of the basic elements of a toll scheme consisting of a single
basic tolling principle, a spatial distribution of the charge objects and a single behavior of the related front end
[ISO/TS 12813:2009]
3.16
toll domain
area or a part of a road network where a certain toll regime is applied
[CEN/TR 16092:20011]
3.17
toll regime
set of rules, including enforcement rules, governing the collection of toll in a toll domain
[ISO 17573:2011]
3.18
toll scheme
organizational view of a toll regime, including the actors and their relationships
ISO/DIS 17575-4
[ISO/TS 17575-3:2011]
3.19
transaction
whole of the exchange of information between two physically separated communication facilities
[ISO 14906:2011]
3.20
transaction model
functional model describing the structure of electronic payment transactions
[ISO 14906:2011]
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 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 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.
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 17575-3.
4 © ISO 2013 – All rights reserved

ISO/DIS 17575-4
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 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 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
ISO/DIS 17575-4
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 contracted 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.
The information required to do so are the information provided by the RoamingRules attribute.
Annex C provides an informative instruction on how to assemble and use roaming rules in general.
6 © ISO 2013 – All rights reserved

ISO/DIS 17575-4
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 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 outside the scope of this part of ISO 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 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 17575-3.
ISO/DIS 17575-4
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 shall be completed when the vehicle reaches the actual EFC
domain border as defined in ISO 17575-3.
6.2.2.7 The liableVehicleClasses sub element
...