ISO/TS 17575-2:2010

TECHNICAL ISO/TS
SPECIFICATION 17575-2
First edition
2010-06-15
Electronic fee collection — Application
interface definition for autonomous
systems —
Part 2:
Communication and connection to the
lower layers
Perception du télépéage — Définition de l'interface d'application pour
les systèmes autonomes —
Partie 2: Communications et connexions aux couches plus basses

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

©  ISO 2010
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 2010 – All rights reserved

Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Normative references.1
3 Terms and definitions .1
4 Abbreviations.3
5 EFC Front End communication architecture.3
5.1 General .3
5.2 Relations to the overall EFC architecture.4
6 Initialize transactions.4
6.1 General .4
6.2 Addressing requested parts of a hierarchical data element structure .5
6.3 Identifying payloads for transmission .5
7 EFC communication services (functions).5
7.1 General concept .5
7.2 Initialization phase .6
7.3 Point-to-point communication service primitives.7
7.4 Session ending .8
7.5 Session failure .8
7.6 Security considerations.8
7.7 Media selection options.8
8 The use of a communication stack.8
8.1 General .8
8.2 Requirements on a underlying communication technology.9
8.3 Mobile terminated calls.9
Annex A (normative) Abstract API definition.10
Annex B (normative) PICS proforma .15
Annex C (informative) API requirements .20
Annex D (informative) Examples of definitions for appropriate languages.21
Annex E (informative) Example of message flow .24
Bibliography.25

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-2 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 2010 – All rights reserved

Introduction
Autonomous systems
This part of ISO/TS 17575 is part of a series of 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 the draft of the future
International Standard 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 reside 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 2010 – 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 the 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.

Figure 3 — Scope of ISO/TS 17575
Applicatory needs covered by ISO/TS 17575
⎯ The parts of ISO/TS 17575 are compliant with the architecture defined in the future International Standard
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,
⎯ 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.

viii © ISO 2010 – All rights reserved

TECHNICAL SPECIFICATION ISO/TS 17575-2:2010(E)

Electronic fee collection — Application interface definition for
autonomous systems —
Part 2:
Communication and connection to the lower layers
1 Scope
This part of ISO/TS 17575 defines how to convey all or parts of the data element structure defined in
ISO/TS 17575-1 over any communication stack and media suitable for this application. It is focussed on
mobile communication links. However, wired links shall use the same methodology.
To establish a link to a sequence of service calls initializing the communication channel, addressing the
reception of the message and forwarding the payload are required. The required communication medium
independent services are part of the definition of this part of ISO/TS 17575, represented by an abstract API.
The communication interface shall be implemented as an API in the programming environment of choice for
the Front End (FE) system. The definition of this API in concrete terms is outside of the scope of this part of
ISO/TS 17575. This part of ISO/TS 17575 specifies an abstract API that defines the semantics of the concrete
API. An example concrete API is presented in Annex C. Where no distinction is made between the abstract
and concrete communications APIs, the term “communications API” or just “API”, can be used.
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 — Part 1
ISO 14906:2004, Road transport and traffic telematics — Electronic fee collection — Application interface
definition for dedicated short-range communication
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
attribute
application information formed by one or by a sequence of data elements, used for implementation of a
transaction
3.2
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:2004, definition 3.4]
3.3
Back End
generic name for the computing and communication facilities of the Service Provider and/or the Toll Charger
3.4
data element
datum which might itself consist of lower level data elements
3.5
data integrity
property that data has not been altered or destroyed in an unauthorized manner
[ISO 14906:2004, definition 3.10]
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
Front End application
part of the Front End above the API
3.8
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.9
on-board equipment
OBE
equipment located within or on the outside of the vehicle and supporting the information exchange across the
interfaces of its sub-units, composed of the On Board Unit (OBU)
NOTE Other sub-units should be considered optional.
3.10
proxy
optional component part of the Front End that communicates with on-board equipment and processes road-
usage data into a format compliant with this Technical Specification and delivers the data to the Back End
3.11
road
any stretch of land that can be navigated by a vehicle
3.12
service primitive (communication)
elementary communication service provided by the Application layer protocol to the application processes
[ISO 14906:2004, definition 3.16]
NOTE The invocation of a service primitive by an application process implicitly calls upon and uses services offered
by the lower protocol layers.
3.13
service provider (toll)
legal entity providing its customers with toll services in one or more toll domains for one or more classes of
vehicle
2 © ISO 2010 – All rights reserved

3.14
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.15
tarrification
calculation of the tariff
3.16
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.17
toll charger
legal entity charging toll for vehicles in a toll domain
3.18
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
4 Abbreviations
For the purpose of this document, the following abbreviations apply unless otherwise specified.
⎯ ADU Application Data Unit (ISO 14906)
⎯ APDU Application Protocol Data Unit (ISO 14906)
⎯ AP Application Process (ISO 14906)
⎯ API Application programming interface
⎯ ASN.1 Abstract Syntax Notation One (See ISO/IEC 8824-1.)
⎯ BE Back End
⎯ EFC Electronic Fee Collection (ISO 14906); here used equivalently to the term toll
⎯ EID Element Identifier (ISO 14906)
⎯ FE Front End
⎯ GNSS Global Navigation Satellite System
⎯ VAT Value added tax
5 EFC Front End communication architecture
5.1 General
The communications subsystem is required to establish the communication link between a Front End (FE)
Application and a Back End (BE). It provides data transport for the tolling FE Application via the
communications session that takes part across the line in Figure 4. For the case where a proxy is present in
the Front End system the communications subsystem defines the communications between the BE and the
Proxy. The link between the Proxy and the OBE is out of scope. For the case that no Proxy is present (the
“Fat Client”) the communications subsystem defines the communications between the OBE and the BE.
Front End Application
7. Application
Communications
API
6. Presentation
Communications
Subsystem
5. Session
4. Transport
Underlying
3. Network
Communications
2. Datalink
Technology
1. Physical
Figure 4 — Relationship between Application and Protocol Stack

The communications subsystem is further subdivided into two distinct components. The communications API
itself offers communications functionality to the FE Application. Below this is the underlying communications
technology which provides the functionality that the API abstracts. Although the API is independent of the
underlying technology, it does place a number of functional demands upon it. For this reason the functional
requirements on the underlying communications technology are listed in 8.2.
Some underlying technologies will be much more capable than others. For the case where a very capable
technology is in use, the code interfacing the API to the underlying technology will serve little more function
than a simple pass through. For more simplistic transport technologies the communications subsystem will
have to do considerably more.
It is expected that these APIs will be “reflected” in the BE such that FEs and BEs can communicate over
arbitrary bearer infrastructures. The specification of the BE API is outside the scope of this part of
ISO/TS 17575.
5.2 Relations to the overall EFC architecture
The communications API provides the lower layers of the interface shown in Figure 5. The API has no
semantic knowledge of the ADUs that it is carrying. It does differentiate between “standard specific” and
“arbitrary” ADUs but it has no semantic knowledge about what these mean and simply carries them as
transparent octet streams atop an arbitrary bearer that is selected at runtime.
6 Initialize transactions
6.1 General
The API carries two “types” of message (ADU). Structured elements relating directly to the definitions in
ISO/TS 17575-1, and unstructured elements which are outside of the scope of this part of ISO/TS 17575 and
receive no further consideration within it.
4 © ISO 2010 – All rights reserved

6.2 Addressing requested parts of a hierarchical data element structure
It is intended that the means and mechanisms of identifying data elements for transmission be defined in a
projected part 3 of this Technical Specification.
6.3 Identifying payloads for transmission
It is intended that the means and mechanisms of identifying payloads for transmission be defined in a
projected part 3 of this Technical Specification.
7 EFC communication services (functions)
7.1 General concept
The abstract API for the communications services can be implemented in any programming environment that
defines the concept of event delivery, allowing the API to report information or to deliver results of operations
to the Front End Application. The general sequence of events is:
⎯ initialize and parameterize the communications interface;
⎯ establish a communications session;
⎯ transfer data in the context of the session;
⎯ terminate the communications session;
⎯ de-initialize the communications interface.
In a normal case the FE Application will initialize (a number of) communications interfaces when it first starts.
An active session is then established either as a direct action by the FE Application or in response to an
incoming request for a session from the BE. The flow of events through the lifetime depicted above is covered
in the sections that follow and cross-referenced to the abstract API definition in Annex A.
Front End Application
7. Application
UP API
Indications
Communications
API
DOWN API
Requests
6. Presentation
Communications
Subsystem 5. Session
4. Transport
Underlying
3. Network
Communications
2. Datalink
Technology
1. Physical
Figure 5 — Up/down interfaces
API calls down the communications stack, fall into two classes: synchronous and asynchronous. Synchronous
calls giving results immediately are limited to those API calls which can quickly return a result
(InitialiseInstance and GetParameter). Other API calls are asynchronous and return their results via
the event mechanism which is initialized during InitialiseInstance.
NOTE This prevents threads from locking while waiting for information to be returned and so reduces the requirement
for multithreaded programming, which is often inappropriate for embedded applications such as those which are typically
seen in the field of application.
7.2 Initialization phase
7.2.1 General
The Front End Application shall initialize the communications interfaces that it wishes to make use of by
means of calls to InitialiseInstance. For each instance created, the FE Application defines which
underlying communications stack is to be used. More than one interface may be used at the same time and
the choice between interfaces is the decision of the FE Application. The FE Application also provides a set of
event reception capabilities which are used by the API to inform the FE Application of status changes.
Any additional parameterization of the instance that is required is performed by repeated calls to
SetParameter. A set of parameters are recognised by the Communications API itself and those which are
not are passed through transparently to the underlying stack. Queries for the existing state of parameters may
be made via calls to GetParameter.
Once this process has been completed, the FE Application now has access to a (set of) communication
instances. There will be delivered state changes for events that occur on any of these interfaces by means of
InstanceStateChange event notification.
The state chart showing the relationship and interactions between each of these states is shown in Figure 6.
NOTE This chart only shows the states that are visible across the API.
Session R:Ended/
StartSession/
Ending
Starting
Unknown
Instance
R:Started/ EndSession/
InitialiseInstance/
R:ADUsReceived/
DropInstance/
ADUSent
R:ADURequest/
ADURequest
R:ReceiveADUsReq/
No
Session Awaiting
SessionSession
ADU Confirm
Session RX
IdlIdlee
ADUs
R:SesstionRequest/
SessionRequest
R:UnformattedADU/
UnformattedADUReceived
EndSession/ R:ReceiveADUsEnd/ R:ADU/
ADUReceived
Error/ SendADUSetEnd/ R:Reject/
!ADUSendOK
Sending
SendADUSetStart/ SendUnformattedADU/
Errored
ADU
R:MessageSent/
ADUSent
SendiSendingng ADU ADU Sending
R:Accept/
ADUSendOK
RequeRequesstt Unformatted ADU

Figure 6 — Session State Chart (API visible states)
6 © ISO 2010 – All rights reserved

7.2.2 Incoming (BE to FE Application) Session Request
Optionally, the BE may wish to establish communications with the FE. In this case it performs whatever
actions are appropriate for the particular communications technology concerned which will result in the FE
Application being informed of the request at some point in time by means of a SessionRequested event
with a datum SessionHandle indicating the identifier that the FE Application should use for the session.
From this point onward the process is the same as for an outgoing session establishment in 7.2.3.
NOTE The FE Application might defer a session request for an arbitrary length of time, subject to operational
constraints.
7.2.3 Outgoing (FE Application to BE) session establishment
The FE Application, either asynchronously of via the process in 7.2.2, requests a session within the chosen
communication context by means of StartSession, parameterized with information about the session to be
established. This returns immediately while also starting the process of creating the session within the
communications technology layers below.
Once the session is established an InstanceStateChange event informs the FE Application of this fact.
The session is now active and communications between the FE Application and the BE can take place within
its context.
7.3 Point-to-point communication service primitives
7.3.1 General
Once the session is active then ADUs can be sent to the BE by the FE Application. Both structured (i.e.
context aware) and unstructured (context unaware) communications capabilities are provided. All ADUs
(structured and unstructured) are opaque to the communications layers and the distinction is only made to
avoid the overhead of higher layer demultiplexing.
Within the context of the communication session the FE Application is considered the master and has control
of the session.
7.3.2 Unstructured messages (ADUs)
The facility is provided to transit unformatted ADUs over the communications infrastructure. This facility is
typically used for the purpose of software upgrades and various other manufacturer-specific information
exchanges.
ADUs are sent via calls to SendUnformattedADU. The maximum size of ADU that can be sent via this
mechanism is available via a parameter from the API. Once the message has been transmitted, an indication
shall be provided (ADUSent) that it has been received successfully by the remote end and that further
transactions are possible.
7.3.3 Structured messages (ADUs)
Structured ADUs are sent in sets. A set is constructed for transmission via a call to SendADUSetStart. This
requests a permission to enter into structured ADU sending mode from the far end. ADUs are added to the set
to be sent via calls to SendADU which returns the amount of space remaining in the transmit buffer. The set is
closed with a call to SendADUSetEnd. Once transmission has been competed the FE Application is informed
via an ADUSent event.
NOTE It is an implementation optimization option as ADUs are transmitted while the set is still being assembled. This
means that the available buffer space indicated by the return from SendADU should be trusted more than local calculations
in the FE Application as more space can be made available when elements are transmitted.
7.4 Session ending
When it is time for a session to end, the FE Application shall make a call to EndSession providing a suitable
reason code. This will start the process of ending the session within the underlying communications
technology. Session termination may not be immediate and transactions that are in process will be completed
before closure occurs. FE Application implementers should expect to have to handle activities from the open
session until an InstanceStateChange to state STNoSession is received.
7.5 Session failure
A session may end through no fault of the BE or the FE Application by means of intervening communications
infrastructure failure. In this instance the FE Application shall be informed of the fact by means of an
InstanceStateChange to STErrored. In this circumstance any ADUs sent by the FE Application for which
it has not received an ADUSent confirmation should be assumed to have failed.
The communications technology shall not attempt to automatically re-establish the session. That is the
responsibility of the FE Application. If the communications session was as a result of the BE request then the
session should be re-established at the first convenient opportunity. If the session was as a result of an FE
Application event then the decision to re-establish is left to the FE Application.
Note that some communications technologies are, by their nature, intermittently available. To support these a
StackAvail call is provided to allow the FE Application to make intelligent choices between available
infrastructures. If a medium fails during a session this shall be indicated according to the processes noted
above.
7.6 Security considerations
All communications are encrypted. Certificate handling and encryption mechanisms are outside of the scope
of this part of ISO/TS 17575.
7.7 Media selection options
Media may be selected between means of having several instances instantiated with independent
communication technologies. The capabilities of each medium can be determined via GetParameter calls,
and the local availability of any specific medium in an active instance can be determined through calls to
StackAvail.
8 The use of a communication stack
8.1 General
This part of ISO/TS 17575 allows for multiple, concurrent, communications technologies to be used at the
same time, and for the FE Application to be able to select amongst them the one most appropriate for the
specific communication to take place. It is envisaged that this capability will be useful for “multi-mode” OBEs
which can use different technologies depending upon the urgency of the communication, their capability and
the extent of the infrastructures that are available.
There are, however, a number of underlying capabilities that any communication technology (or rather, stack
which sits on top of the technology) needs to provide.
8 © ISO 2010 – All rights reserved

8.2 Requirements on a underlying communication technology
This part of ISO/TS 17575 is open for a wide range of underlying communications technologies. However, the
following list of properties of these stacks shall be provided.
⎯ Must be capable of supporting or emulating a “session”.
⎯ Must be capable of reliably transferring ADUs, in sequence, bidirectionally across the link.
⎯ Must be capable of reporting the safe receipt of ADUs at the remote end of the link.
⎯ Must be capable of transporting data elements of arbitrary length between the FE and the BE.
⎯ Must be capable of establishing a session from the FE to the BE.
⎯ Must offer some means of signalling a demand from the BE to the FE Application that the BE wishes a
session to be established.
⎯ Must be capable of reliably detecting the loss of a session and of delivering that information to the
communications API.
⎯ Must deliver ADUs across the link in a timely fashion.
⎯ Must be capable of carrying an appropriate amount of data.
8.3 Mobile terminated calls
The approach taken within this part of ISO/TS 17575 never requires an incoming, in band, communication port
to be open. If a BE wishes to make a connection to an FE Application for any purpose, it can use out of band
signalling to achieve that and the mechanisms used are outside the scope of this part of ISO/TS 17575. The
range of out of band options is considerable (SMS messages, push button on the unit, broadcast signal, etc.)
and makes the FE Application more secure as a result.
NOTE A consequence of this approach is that there is never any requirement for an IP addressable endpoint for a
mobile terminated call. This avoids the security issues discussed above but also simplifies issues of Network Address
Translation and private subnets, since the FE Application will only ever need to make an outgoing connection.

Annex A
(normative)
Abstract API definition
A.1 General
The communications API consists of a “down” API, from the Front End Application to the communications
stack, and an “up” API, from the communications stack to the Front End Application. Each will be considered
in turn.
A.2 Down API (Front End Application to communications stack)
A.2.1 InitialiseInstance
Purpose: Initializes the communications API for use. The interface is initialized in STNoSession
condition.
Takes: StackID Underlying communications stack to be employed.
Callbacks Reference to the event handlers to be used for this instance, refer to A.2
for details of these.
Precondition: The interface must not have been previously initialized.
Returns: A handle to the instance of the API. This handle is used for all communications.
Errors: Returns an invalid instance if it was not possible to create the instance.
A.2.2 SetParameter
Purpose: Set a parameter for this instance of the API. All parameters and values are expressed as
strings.
Takes: Instance The instance to which this parameter relates.
Parameter The parameter to be set.
value The value to give to the parameter.
Precondition: A valid instance is required.
Returns: Error Code.
Errors: ERNoError, ERNotSet
A.2.3 GetParameter
Purpose: Get a parameter value for this instance of the API.
Takes: Instance The instance to which this parameter relates.
Parameter The parameter to be set.
Precondition: A valid instance is required.
Returns: The specified parameter value as a string.
Errors: Invalid string if the parameter is not known.
10 © ISO 2010 – All rights reserved

A.2.4 DeleteParameter
Purpose: Delete a parameter from this instance of the API.
Takes: Instance The instance to which this parameter relates.
Parameter The parameter to be deleted.
Precondition: A valid instance is required.
Precondition: Error Code.
Errors: ERNoError, ERNotSet
A.2.5 StackAvail
Purpose: Indicate if the communications stack is currently available.
Takes: Instance The instance to which this check relates.
Precondition: A valid instance is required.
Returns: Boolean indicating if the stack is currently available.
Errors: Will return FALSE in the case of an error.
A.2.6 DropInstance
Purpose: Delete an API interface
Takes: Instance The instance to which this drop request relates.
Severity Speed with which this interface should be removed.
(SENormal, SEUrgent, SEUnconditional)
Precondition: A valid instance in the STNoSession state (for SENormal and SEUrgent) is required.
Returns: Error code.
Errors: ERUnknownInstance, ERBadState, ERNoError
A.2.7 StartSession
Purpose: Start the process to establish a session in the context of this interface (i.e. using the
established communications channel and parameters). Session establishment is defined by
an event indicating a change to STSessionIdle when the session is in place.
Parameterization of the session is via the SetParameter/GetParameter methods.
Takes: Instance The instance within which this session request should be met.
Reason Reason for this session establishment.
SessionHandle Any session handle information that is required.
Precondition: Active instance and no active session already. Correct parameterization in place.
Returns: Error code.
Errors: ERInSession, ERNoInstance, ERUnknownEndpoint, ERInSession,
ERSessionFailed, ERNoError
A.2.8 EndSession
Purpose: To start the process to end an active session in the context of this instance. Session end is
confirmed via the state change even
...