ISO/TS 21219-23:2016

Intelligent transport systems - Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) - Part 23: Roads and multimodal routes (TPEG2-RMR)

ISO/TS 21219-23: 2016 describes new mobility services like car sharing, car rental or park and ride as well as the integration of different transport modes by multimodal or off-board navigation are gaining increasing importance. Furthermore, the cooperative management of the transport infrastructure requires the provision of precise information and guidance on dedicated routes from a central knowledge base to a traveller's mobile device. Such use cases are addressed by the TPEG application defined in this document. The Road and Multimodal Routes (RMR) application enables the service provision for road routes as well as multimodal routes including more than one transport mode and parking. For example, an optimal multimodal route may include a drive by car to a train station with parking facility, a train connection to a station nearby the destination and a local public transport ride from the train station to the traveller's destination. The standardized delivery, via TPEG technology, of routing information has some potential benefits for the users of an RMR TPEG service, for instance: - Enabling of specialized routing services like scenic routing or Eco routing; - The best use of the overall transport network, i.e. not only the road network; - Cost and time savings to traveller; - Harmonization of in-car navigation and traffic management, e.g. routing advices by variable message signs; - Personalized service provisioning, i.e. information services considering the specific characteristics of a user. Some of the use cases above, in particular personalized service, may require a Peer-to-Peer (P2P) communication while others may apply a broadcast communication approach, e.g. city routing.

Systèmes intelligents de transport — Informations sur le trafic et le tourisme via le groupe expert du protocole de transport, génération 2 (TPEG2) — Partie 23: Routes et routes multimodales (TPEG2-RMR)

General Information

• Status: Published
• Publication Date: 08-Dec-2016
• ICS: 03.220.01 - Transport in general
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 10 - Traveller information systems
• Current Stage: 9093 - International Standard confirmed
• Start Date: 31-Oct-2023
• Completion Date: 13-Dec-2025

Relations

• Consolidated By: ISO 11348-1:2007/Amd 1:2018 - Water quality - Determination of the inhibitory effect of water samples on the light emission of Vibrio fischeri (Luminescent bacteria test) - Part 1: Method using freshly prepared bacteria - Amendment 1
• Effective Date: 06-Jun-2022

Overview

ISO/TS 21219-23:2016 - TPEG2-RMR (Intelligent transport systems - Traffic and travel information via TPEG2 - Part 23: Roads and multimodal routes) defines the Roads and Multimodal Routes (RMR) application for TPEG Generation 2. It standardizes the representation and delivery of routing and multimodal trip information (including parking, car sharing, car rental and park-and-ride) from a central knowledge base to traveller devices. The specification supports both broadcast and Peer-to-Peer (P2P) communication models and provides machine-readable message structures to enable off-board navigation, cooperative infrastructure management and personalized routing services.

Key topics and requirements

• Message structure and components: standardized elements such as Route, RouteSegment, Parking, SegmentLocation, PointLocation and travel detail components (RoadTravelDetails, PTTravelDetails, PedestrianTravelDetails).
• Session and request messages: RMR request/response message models (e.g., RMRRequestMessage, RMRRouteReqParams, Activate/Terminate session parameters).
• Data types and tables: datatypes (WGS84Coordinate, EnergyConsumption, Operator) and lookup tables (RouteType, ModeType, ParkType, RouteObjectives, ErrorCode).
• Application constraints: application identification, version signalling, ordered components, extendibility and TPEG Service Component framing rules.
• Communication scenarios: support for broadcast (e.g., city routing) and P2P (for personalized routing) delivery.
• Physical representations: normative annexes defining TPEG-Binary and TPEG-ML (XML) representations for interoperability.
• Location referencing: integration with TPEG2 location referencing to support map-based and human-readable outputs.

Practical applications

• Multimodal trip planning that combines car, rail, transit and walking with parking recommendations (e.g., drive-to-station + park + train + local transit).
• Specialized routing services like eco routing and scenic routing.
• Real-time guidance for cooperative traffic management and harmonized in-vehicle navigation (including routing advice from variable message signs).
• Integration of shared mobility services (car sharing, rental) and parking availability into navigation apps.
• Personalized routing delivered via P2P to accommodate user preferences, vehicle type or energy consumption constraints.

Who uses this standard

• ITS service providers and content aggregators
• Navigation system manufacturers and in-car infotainment vendors
• Traffic Management Centers and municipal authorities
• Mobility-as-a-Service (MaaS) and multimodal trip planner developers
• Automotive OEMs and telematics platform providers

Related standards

• ISO/TS 21219 series (TPEG Generation 2 core rules and toolkit)
• ISO/TS 21219-6 (Message Management) and ISO/TS 21219-7 (Location Referencing)
• Earlier TPEG Generation 1 series (ISO/TS 18234)

Keywords: ISO/TS 21219-23:2016, TPEG2-RMR, intelligent transport systems, traffic and travel information, multimodal routing, route guidance, parking guidance, eco routing, P2P, broadcast.

Standards Content (Sample)

TECHNICAL ISO/TS
SPECIFICATION 21219-23
First edition
2016-12-15
Intelligent transport systems - Traffic
and travel information (TTI) via
transport protocol experts group,
generation 2 (TPEG2) —
Part 23:
Roads and multimodal routes
(TPEG2-RMR)
Systèmes intelligents de transport — Informations sur le trafic et le
tourisme via le groupe expert du protocole de transport, génération 2
(TPEG2) —
Partie 23: Routes et routes multimodales (TPEG2-RMR)
Reference number
©
ISO 2016
© ISO 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO 2016 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Abbreviated terms . 2
5 Application specific constraints . 3
5.1 Application identification . 3
5.2 Version number signalling . 3
5.3 Ordered components . 3
5.4 Extendibility . 4
5.5 TPEG Service Component Frame. 4
6 RMR structure . 4
6.1 Message structure . 4
6.2 Scenarios, features and requirements . 6
6.2.1 General. 6
6.2.2 Broadcast scenario . 6
6.2.3 P2P scenario . 6
7 RMR Message components . 8
7.1 RMRMessage . 8
7.2 Route . 9
7.3 RouteSegment .10
7.4 Parking .11
7.5 SegmentLocation .11
7.6 PointLocation .12
7.7 SegmentDetails .12
7.8 RoadTravelDetails .12
7.9 PTTravelDetails .12
7.10 PedestrianTravelDetails .13
7.11 RMRRequestMessage .13
7.12 RMRReqParams .13
7.13 RMRListReqParams .13
7.14 RMRRouteReqParams .14
7.15 RMRActivateRouteReqParams .14
7.16 TerminateRMRSession .15
7.17 RoutePreferences .15
7.18 MessageManagementContainerLink.15
7.19 RMRLocRef .15
7.20 LocationReferencingContainerLink .16
7.21 MMCLinkReq . .16
8 RMR datatypes .16
8.1 EnergyConsumption.16
8.2 Operator .16
8.3 PredefConnection .17
8.4 WGS84Coordinate .17
8.5 MessageLink .17
9 RMR Tables .18
9.1 rmr001:RouteType .18
9.2 rmr002:ModeType .18
9.3 rmr003:ParkType .19
9.4 rmr005:RouteObjectives .19
9.5 rmr006:RouteCause .20
9.6 rmr007:AccessType .20
9.7 rmr008:OccTendency .20
9.8 rmr009:EnergyType .21
9.9 rmr099:ErrorCode .21
Annex A (normative) TPEG application — TPEG-Binary Representation .22
Annex B (normative) TPEG application — TPEG-ML Representation .33
Bibliography .43
iv © ISO 2016 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
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. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/TC 204, Intelligent transport systems.
A list of all the parts in the ISO 21219 series, can be found on the ISO website.
Introduction
History
TPEG technology was originally proposed by the European Broadcasting Union (EBU) Broadcast
Management Committee, who established the B/TPEG project group in the autumn of 1997 with a brief
to develop, as soon as possible, a new protocol for broadcasting traffic and travel-related information
in the multimedia environment. TPEG technology, its applications and service features were designed
to enable travel-related messages to be coded, decoded, filtered and understood by humans (visually
and/or audibly in the user’s language) and by agent systems. Originally, a byte-oriented data stream
format, which may be carried on almost any digital bearer with an appropriate adaptation layer,
was developed. Hierarchically structured TPEG messages from service providers to end-users were
designed to transfer information from the service provider database to an end-user’s equipment.
One year later, in December 1998, the B/TPEG group produced its first EBU specifications. Two
documents were released. Part 2 (TPEG-SSF, which became ISO/TS 18234-2) described the Syntax,
Semantics and Framing structure, which was used for all TPEG applications. Meanwhile, Part 4 (TPEG-
RTM, which became ISO/TS 18234-4) described the first application for Road Traffic Messages.
Subsequently, in March 1999, CEN/TC 278, in conjunction with ISO/TC 204, established a group
comprising members of the former EBU B/TPEG and this working group continued development work.
Further parts were developed to make the initial set of four parts enabling the implementation of a
consistent service. Part 3 (TPEG-SNI, ISO/TS 18234-3) described the Service and Network Information
Application used by all service implementations to ensure appropriate referencing from one service
source to another.
Part 1 (TPEG-INV, ISO/TS 18234-1) completed the series by describing the other parts and their
relationship; it also contained the application IDs used within the other parts. Additionally, Part 5, the
Public Transport Information Application (TPEG-PTI, ISO/TS 18234-5), was developed. The so-called
TPEG-LOC Location Referencing method, which enabled both map-based TPEG-decoders and non-map-
based ones to deliver either map-based Location Referencing or human readable text information,
was issued as ISO/TS 18234-6 to be used in association with the other applications parts of the
ISO/TS 18234- series to provide Location Referencing.
The ISO/TS 18234- series has become known as TPEG Generation 1.
TPEG Generation 2
When the Traveller Information Services Association (TISA), derived from former forums, was
inaugurated in December 2007, TPEG development was taken over by TISA and continued in the TPEG
applications working group.
It was about this time that the (then) new Unified Modelling Language (UML) was seen as having major
advantages for the development of new TPEG Applications in communities who would not necessarily
have binary physical format skills required to extend the original TPEG TS work. It was also realized
that the XML format for TPEG described within the ISO/TS 24530- series (now superseded) had a
greater significance than previously foreseen, especially in the content-generation segment and that
keeping two physical formats in synchronism, in different standards series, would be rather difficult.
As a result, TISA set about the development of a new TPEG structure that would be UML based. This has
subsequently become known as TPEG Generation 2.
TPEG2 is embodied in the ISO/TS 21219- series and it comprises many parts that cover introduction,
rules, toolkit and application components. TPEG2 is built around UML modelling and has a core of rules
that contain the modelling strategy covered in ISO/TS 21219-2, ISO/TS 21219-3, ISO/TS 21219-4 and
the conversion to two current physical formats: binary and XML; others could be added in the future.
TISA uses an automated tool to convert from the agreed UML model XMI file directly into an MS Word
document file, to minimize drafting errors, that forms the Annex for each physical format.
vi © ISO 2016 – All rights reserved

TPEG2 has a three container conceptual structure: Message Management (ISO/TS 21219-6), Application
1)
(several Parts) and Location Referencing (ISO/TS 21219-7 ). This structure has flexible capability and
can accommodate many differing use cases that have been proposed within the TTI sector and wider
for hierarchical message content.
TPEG2 also has many Location Referencing options as required by the service provider community, any
of which may be delivered by vectoring data included in the Location Referencing container.
The following classification provides a helpful grouping of the different TPEG2 parts according to their
intended purpose.
— Toolkit parts: TPEG2-INV (ISO/TS 21219-1), TPEG2-UML (ISO/TS 21219-2), TPEG2-UBCR
(ISO/TS 21219-3), TPEG2-UXCR (ISO/TS 21219-4), TPEG2-SFW (ISO/TS 21219-5), TPEG2-MMC
2)
(ISO/TS 21219-6), TPEG2-LRC (ISO/TS 21219-7), TPEG2-LTE (ISO/TS 21219-24 );
— Special applications: TPEG2-SNI (ISO/TS 21219-9), TPEG2-CAI (ISO/TS 21219-10);
3) 4)
— Location Referencing: TPEG2-ULR (ISO/TS 21219-11 ), TPEG2-GLR (ISO/TS 21219-21 ), TPEG2-
5)
OLR (ISO/TS 21219-22 );
— Applications: TPEG2-PKI (ISO/TS 21219-14), TPEG2-TEC (ISO/TS 21219-15), TPEG2-FPI
(ISO/TS 21219-16), TPEG2-TFP (ISO/TS 21219-18), TPEG2-WEA (ISO/TS 21219-19), TPEG2-RMR
6) 7)
(ISO/TS 21219-23 ), TPEG2-EMI (ISO/TS 21219-25 ).
TPEG2 has been developed to be broadly (but not totally) backward compatible with TPEG1 to assist
in transitions from earlier implementations, while not hindering the TPEG2 innovative approach and
being able to support many new features, such as dealing with applications having both long-term,
unchanging content and highly dynamic content, such as Parking Information.
This document is based on the TISA specification technical/editorial version reference:
SP13010/1.0/001
1) Under development.
2) To be published.
3) Under development.
4) Under development.
5) Under development.
6) To be published.
7) To be published.
TECHNICAL SPECIFICATION ISO/TS 21219-23:2016(E)
Intelligent transport systems - Traffic and travel
information (TTI) via transport protocol experts group,
generation 2 (TPEG2) —
Part 23:
Roads and multimodal routes (TPEG2-RMR)
1 Scope
New mobility services like car sharing, car rental or park and ride as well as the integration of
different transport modes by multimodal or off-board navigation are gaining increasing importance.
Furthermore, the cooperative management of the transport infrastructure requires the provision of
precise information and guidance on dedicated routes from a central knowledge base to a traveller’s
mobile device.
Such use cases are addressed by the TPEG application defined in this document. The Road and Multimodal
Routes (RMR) application enables the service provision for road routes as well as multimodal routes
including more than one transport mode and parking. For example, an optimal multimodal route may
include a drive by car to a train station with parking facility, a train connection to a station nearby the
destination and a local public transport ride from the train station to the traveller’s destination.
The standardized delivery, via TPEG technology, of routing information has some potential benefits for
the users of an RMR TPEG service, for instance:
— Enabling of specialized routing services like scenic routing or Eco routing;
— The best use of the overall transport network, i.e. not only the road network;
— Cost and time savings to traveller;
— Harmonization of in-car navigation and traffic management, e.g. routing advices by variable
message signs;
— Personalized service provisioning, i.e. information services considering the specific characteristics
of a user.
Some of the use cases above, in particular personalized service, may require a Peer-to-Peer (P2P)
communication while others may apply a broadcast communication approach, e.g. city routing.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements 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/TS 18234-11:2013, Intelligent transport systems — Traffic and Travel Information (TTI) via transport
protocol experts group, generation 1 (TPEG1) binary data format — Part 11: Location Referencing
Container (TPEG1-LRC)
ISO/TS 21219-1, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 1: Introduction, numbering and versions (TPEG2-INV)
ISO/TS 21219-5, Intelligent transport systems - Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 5: Service framework (TPEG2-SFW)
ISO/TS 21219-7, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 7: Location Referencing Container (TPEG2-LRC)
ISO/TS 21219-9, Intelligent transport systems — Traffic and travel information (TTI) via transport
protocol experts group, generation 2 (TPEG2) — Part 9: Service and network information (TPEG2-SNI)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
—  IEC Electropedia: available at http://www.electropedia.org/
—  ISO Online browsing platform: available at http://www.iso.org/obp
3.1
message management container
MMC
concept applied to the grouping of all message elements including Message Management Information of
a TPEG-message together in one place
3.2
location referencing
means to provide information that allows a system to accurately identify a location
Note 1 to entry: The content of a location reference allows the location to be presented in a graphical or textual
manner to the end-user (e.g. coloured network graphs) as well as to be used for navigational systems purposes.
3.3
location referencing container
concept applied to the grouping of all the location referencing elements, of a TPEG-message, together in
one place
4 Abbreviated terms
ACID Application and Content Identifier
AID Application Identification
ADC Application Data Container
GLR TPEG LR method ‘Geo Location Referencing’
CEN Comité Européen de Normalisation
EBU European Broadcasting Union
LR Location Reference
LRC Location Reference Container
MMC Message Management Container
MMR Multimodal Route
P2P Peer-to-Peer (communication)
PKI Parking Information application
2 © ISO 2016 – All rights reserved

RMR Road and Multimodal Routes application
SFW TPEG Service Framework: Modelling and Conversion Rules
TISA Traveller Information Services Association
TPEG Transport Protocol Expert Group
TTI Traffic and Traveller Information
UML Unified Modelling Language
5 Application specific constraints
5.1 Application identification
The word ‘application’ is used in the TPEG specifications to describe specific subsets of the TPEG
structure. An application defines a limited vocabulary for a certain type of message, for example
parking information or road traffic information. Each TPEG application is assigned a unique number,
called the Application Identification (AID). An AID is defined whenever a new application is developed
and these are all listed in ISO/TS 21219-1.
The AID number is used within the TPEG-SNI application ISO/TS 21219-9 to indicate how to process
TPEG content and facilitates the routing of information to the appropriate application decoder.
5.2 Version number signalling
Version numbering is used to track the separate versions of an application through its development and
deployment. The differences between these versions may have an impact on client devices.
The version numbering principle is defined in ISO/TS 21219-1 (TPEG-INV).
Table 1 shows the current version numbers for signalling RMR within the SNI application ISO/TS 21219-9:
Table 1 — Current version numbers for signalling of RMR
major version number 1
minor version number 0
5.3 Ordered components
TPEG2-RMR requires a fixed order of TPEG components. The order for the RMR message component is
shown in Figure 1. The first component shall be the Message Management Container (MMC). This shall be
the only component if the message is a cancellation message. Otherwise, the MMC component shall be
followed by one or more Application Data Container (ADC) component(s) which includes the application-
specific information.
Figure 1 — Composition of TPEG messages
Note that the definition of the used Location Referencing methods is out-of-scope for the RMR
specification and has to be agreed between the service provider and the client supplier.
5.4 Extendibility
The requirement of a fixed component order does not affect the extension of RMR. Future application
extensions may insert new components or may replace existing components by new ones without
losing backward compatibility. That means a RMR decoder shall be able to detect and skip unknown
components.
5.5 TPEG Service Component Frame
RMR makes use of the “Service Component Frame with dataCRC and messageCount” according to
specification ISO/TS 21219-5 (TPEG2-SFW).
6 RMR structure
6.1 Message structure
Figure 2 below shows the message structure of RMR. In case of a P2P communication this structure
will also be used in the response of the TPEG server.
Figure 2 — RMR message structure
4 © ISO 2016 – All rights reserved

Figure 3 below shows the RMR request message structure. This message type will only be used for P2P
communication to request routing information from the TPEG server.
Figure 3 — RMR request message structure
NOTE Figure 4 below shows some examples for RMR.
— The first line describes a route consisting of just one route segment, in this example, travel on a road
network;
— The second line shows travel on a road network, ending at a car park and followed by a pedestrian
walk to the destination;
— The third line includes additionally a route segment using public transport.
Other combinations of route segments are possible. The RMR service has to take care that the sequence
of routes makes sense, e.g. travel by private car is in general only possible for the first part of the travel
segment (first route segment).
Figure 4 — Examples of RMR
6.2 Scenarios, features and requirements
6.2.1 General
An RMR message (see Figure 2) includes:
— One MMC only in case of a cancellation message;
— Otherwise:
— one MMC, with a message ID unique for the route transmitted in this message;
— one ADC with all required information of one route; and
— optionally one Location Reference Container (LRC) describing the overall location of the route.
As the particular route segments contain dedicated LRCs the general LRC on the message top
level is of descriptive nature and may be used to provide a graphical representation of the
overall route, e.g. by a GLR location reference.
6.2.2 Broadcast scenario
In a broadcast transmission, messages are sent from the TPEG server to a number of TPEG client
devices. Thus, only the message structure described in Figure 2 is applicable for this scenario while
requests are not possible. In this case, an RMR message shall include all service information required
by the client.
6.2.3 P2P scenario
6.2.3.1 P2P transmission without request messages
In this scenario, the client only uses the general request mechanisms as defined in TPEG over HTTP 0
and does not send dedicated request messages on TPEG level (Figure 3). Thus, the same requirements
as for the broadcast scenario apply.
6.2.3.2 P2P transmission with request messages
The request by dedicated TPEG RMR request messages enable a number of features, which are
particularly important for personalized services:
1. Request for a route list:
— The RMR client transmits with its request an RMR request message with an ‘RMRListReqParams’
component included. This component contains a number of parameters that define the user’s
characteristics and preferences concerning a road or multimodal route.
6 © ISO 2016 – All rights reserved

— The RMR server stores the request parameters of the client for this session and provides in its
response a list of routes that fulfil the user’s requirements delivered in the request message.
The list enables the user to select a suitable route.
— The route list consists of a number of RMR messages but should provide restricted details. As
a minimum requirement the components ‘Route’ and ‘RouteSegment’ shall be present in the
messages delivered by the RMR server. Each list has a RouteId unique for this service.
— The client may request further route list entries by using the attribute ‘maxListLen’ and
listCountOffset’ (see also 7.1.3).
2. Request for detailed route information
— The RMR client may request detailed route information by one or several requests. For that, it
transmits the ‘RMRRouteReqParams’ component with its RMR request message including the
RouteId of the route of interest.
— The RMR server responds with an RMR message with the detailed information about the
requested route. The RMR server shall use the same message ID as for the related route in the
route list.
3. Selection of a route
— The RMR client may select or activate a route of the route list. For that, it transmits an
‘RMRActivateRouteReqParams’ component with its RMR request message including the
RouteId of the selected route.
— The RMR server activates the route and is now able to keep the route up-to-date by sending
updates. The RMR client can request this information by additional requests for detailed
information (see list item 2 above).
4. Update of the route
— The RMR client may request updates of the information of the selected route information. For
that, it transmits the ‘RMRUpdateRouteReqParams’ component with its RMR request message
including its current position. The update may be requested iteratively.
— The RMR server responds with an RMR message with the detailed information about the
currently activated route. The RMR server shall use the same message ID as for the related
route in the route list.
5. Terminate a session
— The RMR client may actively terminate an RMR session by sending a ‘TerminateRMRSession’
component with its RMR request message.
— The RMR server may terminate the session and can release the user data transmitted by the
route list request (see list item 1 above).
NOTE This document defines only a basic mandatory set of request parameters. An implementation can add
vendor-specific attributes to the request components.
Figure 5 below shows a typical sequence of an RMR session.
Figure 5 — Typical sequence of an RMR session (RMC/RMS = RMR client/server)
7 RMR Message components
7.1 RMRMessage
The description of the RMR message (see Table 2) contains a road route or a multimodal route.
The RMR message may be sent by an RMR server on request of a client device (P2P communication) or
may be sent by broadcast if only a limited number of routes have to be transmitted.
8 © ISO 2016 – All rights reserved

Table 2 — RMRMessage
Name Type Multiplicity Description
Ordered components
mmt MessageManagementContainerLink 1 The MMC of the RMR message. The RMR server
shall use a service-wide unique message ID for
each route and shall keep this ID as long as the
route is valid to enable an easy update on the
client side.
route Route 0.1 A route delivered by the RMR server for a given
origin and destination pair.
loc LocationReferencingContainerLink 0.1 The overall location reference for the route. May
be optionally used for supplemental information.
As the specific routes are referenced by addi-
tional location references in its route-segments
this LRC shall contain only a simple descriptive
geographic outline of the route delivered by the
RMR server (e.g. a GLR line reference). The LR
shall be a linear location including the origin
and the destination of the route.
7.2 Route
A route object (see Table 3) contains the information of one RMR route consisting of one or several
route segments.
Table 3 — Route
Name Type Multiplic- Description
ity
routeID IntUnLoMB 1 A handle or ID for the route; shall be unique for the service.
routeListID IntUnLoMB 1 A handle or ID for the route list. Shall be used if the route
is grouped in a route list and the value of this parameter
shall be unique for the service in this case. If the route is
not part of a list the value shall be zero.
listCount IntUnLoMB 1 The value describes the position of the route in the route
list delivered by the RMR server for a given origin desti-
nation pair, according to the sorting order of the server
(broadcast scenario) or the client’s request-preferences
(P2P scenario). First position shall be 1. For instance, if
the server provides the 10 fastest routes for an origin
destination pair, value 2 means that this is the 2nd best
alternative. The value shall be zero if the route is not a
part of a route list.
routeType rmr001:RouteType 1 Type of the route
routeDescriptor LocalisedShortString 1 A description or name of the route (e.g. ‘P&R Garching’)
startTime DateTime 1 Start time of the route
travelTime IntUnLoMB 1 Overall travel time [seconds] of the route
distance IntUnLoMB 0.1 Overall length or distance [metres] of the route; may not be
present if not available or relevant (e.g. public transport)
lastReturn DateTime 0.1 Time of last possible return trip for a multimodal route.
Shall be present only in multimodal routes including PT
or other operated services.
shortListPT LocalisedShortString 0.1 A short list with the description of the public transport
lines used for a multimodal route (e.g. ‘U1 B244’)
Table 3 (continued)
Name Type Multiplic- Description
ity
routeCause rmr006:RouteCause 0.1 Descriptive information why this route has been proposed
by the server. Only a few popular reasons are listed in the
rmr:006 RouteCause table while others may be delivered
by the ‘causeDescription’ attribute.
accessType rmr007:AccessType 0.1 Type of access of overall route (e.g. ramp, stairs, elevator,
etc. along route); relevant in particular for persons with
restricted mobility.
causeDescription LocalisedShortString 0.1 Further description why this route has been proposed
by the server.
LinkedCause MessageLink 0.1 Link to a TPEG message with detailed information about
the route cause.
Ordered Components
routeSegments RouteSegment 1.* The list of segments of the route. A new segment shall be
added if the transport mode changes, e.g. one segment
for a journey by car on the road network, another one
for travel by bus.
7.3 RouteSegment
A route shall consist of one or several route segments (see Table 4) that may have different characteristics
(e.g. transport mode).
Table 4 — - RouteSegment
Name Type Multiplic- Description
ity
startTime DateTime 1 Scheduled time for start of this segment
travelTime IntUnLoMB 1 Duration or travel time of this segment [seconds]
mode rmr002:ModeType 1 Type of transport mode
distance IntUnLoMB 0.1 Distance of walk or drive on this segment [metres]
cost IntUnLoMB 0.1 Cost for this segment in local currency (using the lowest
value local currency units, such as cents); for example
public transport ticket or costs for gasoline; note that the
value may be a rough estimate, as the basis for a detailed
calculation may be unknown at the server side.
currencyType typ003:CurrencyType 0.1 Local Currency
energyConsumption EnergyConsumption 0.1 Energy consumption for the route segment; note that the
value may be a rough estimate, as the basis for a detailed
calculation may be unknown at the server side.
ptLine LocalisedShortString 0.1 Short string with description of public transport line (e.g.
head-sign ‘U5’); shall only be used if segment is of PT-type.
description LocalisedShortString 0.1 Further description of the segment.
operator Operator 0.1 Operator of the travel service, e.g. public transport,
car-sharing etc.
infoLink LongString 0.1 A URL with further information, if available.
Ordered components
segmentLoc SegmentLocation 0.1 Location description of the segment.
segmentDetails SegmentDetails 0.1 Detailed information for this route segment.
parking Parking 0.1 Parking or park and ride location at end of the segment.
10 © ISO 2016 – All rights reserved

7.4 Parking
Description of a car park, a parking garage or a park and ride station (see Table 5).
Table 5 — Parking
Name Type Multiplic- Description
ity
name LocalisedShortString 1 Name of the parking facility or park and ride facility
pType rmr003:ParkType 1 Type of parking facility
capacity IntUnLoMB 0.1 Capacity of parking facility, given as the number of
parking spaces
occupancy IntUnLoMB 0.1 Number of currently occupied parking spaces
costHour IntUnLoMB 0.1 Cost for parking per hour given in local currency; if there
is more than one currency unit (e.g. Euro and Cent) the
currency unit with lower value shall be used (e.g. Cent).
costDay IntUnLoMB 0.1 Cost for parking per day in local currency
currencyType typ003:CurrencyType 0.1 Description of local currency
description LocalisedShortString 0.1 Additional description of parking facility
tendency rmr008:OccTendency 0.1 Tendency of occupancy
prediction IntSiLoMB 0.1 Prediction of free capacity at arrival time at parking
facility [number of parking spaces]
timeForParking IntUnLoMB 0.1 Estimated time [sec] to get a parking place at parking
facility, e.g. queuing at car park or search
linkedPark MessageLink 0.1 Link to a TPEG message with detailed information about
the parking facility
Ordered Components
pLoc PointLocation 1 The location of the parking facility
7.5 SegmentLocation
Table 6 describes a SegmentLocation.
A SegmentLocation may be a GLR line-reference or a map-matchable dynamic location reference.
If GLR is used, the line reference shall include at least the coordinates of the start and end of the segment
where start/end means the beginning or end respectively (in driving direction) of the related segment.
A street name and heading may be added for further information.
Table 6 — SegmentLocation
Name Type Multiplic- Description
ity
streetName LocalisedShortString 0.1 Name of the street of road section. This shall be used
only if the section is on one named street (e.g. short
pedestrian segment).
heading IntUnTi 0.1 Heading of the client vehicle in 360/256 degrees resolu-
tion. Value range is 0 to 255, counted in counter-clockwise
direction.
Resulting Range:
000 = North 0°
064 = West 90°
128 = South 180°
196 = East 270°
Ordered components
locRef RMRLocRef 0.1 The location reference of the segment.
Shall be a map-matchable LR-method in case of a road
route segment (e.g. AGORA-C)
7.6 PointLocation
Table 7 describes a PointLocation, e.g.:
— a car park entry ramp location;
— an origin or destination location;
— a stopover location, e.g. for public transport.
The PointLocation can be defined by:
— a simple GLR point location coordinate and with optional street name, address or direction;
— a map-matchable dynamic location reference.
Table 7 — PointLocation
Name Type Multiplic- Description
ity
Ordered components
locRef RMRLocRef 0.1 The location reference of the location
7.7 SegmentDetails
SegmentDetails is an Abstract class construct for detailed segment information, switching to one of the
classes ‘RoadTravelDetails’, ‘PTTravelDetails’ or ‘PedestrianTravelDetails’.
7.8 RoadTravelDetails
RoadTravelDetails contains detailed information for a road route segment.
7.9 PTTravelDetails
Table 8 lists detailed information for a public transport route segment (see Table 8).
12 © ISO 2016 – All rights reserved

Table 8 — PTTravelDetails
Name Type Multiplic- Description
ity
originStation LocalisedShortString 0.1 Name of the start or origin station/stop of the PT con-
nection.
destinationStation LocalisedShortString 0.1 Name o
...