ISO 24099:2011

INTERNATIONAL ISO
STANDARD 24099
First edition
2011-01-15
Navigation data delivery structures and
protocols
Structures et protocoles pour la diffusion de données dans les systèmes
de navigation
Reference number
©
ISO 2011
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 2011
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2011 – All rights reserved

Contents Page
Foreword .v
Introduction.vi
1 Scope.1
2 Conformance .2
3 Terms and definitions .2
4 UML Expressions for diagrams .4
5 Abbreviated terms.4
6 Requirements.5
6.1 User-related requirements.5
6.2 Data requirements.5
6.3 Protocol requirements .6
6.4 Communication requirements .6
6.5 Update strategies .6
6.6 Others .7
7 Reference architecture and framework concept.7
7.1 Reference architecture.7
7.2 Framework concept.9
7.2.1 Varieties of updates .9
7.2.2 Case of update by geographic area.9
7.2.3 Case of incremental update .11
7.2.4 Descriptions of the exchange process of updating data .12
7.2.5 Methods for specifying update data by users or centre .14
7.2.6 Rules for specifying the objects to be replaced or deleted (Rules for identifiers).14
7.2.7 Version control .15
8 Protocols .15
8.1 Introduction.15
8.2 Protocol for an In-vehicle-System-Triggered system delivering map data or POI data .16
8.3 Protocol for an In-vehicle-System-Triggered system delivering status data.17
8.4 Protocol for a Service-Centre-Triggered system delivering map data, POI data or status
data .18
8.5 Protocol for a Service-Centre-Triggered system delivering emergency data.19
8.6 Definitions of messages used in the protocols .20
9 Data structures .21
9.1 Introduction.21
9.2 Class: Update target_identifier .21
9.3 Class: Area_ID .22
9.4 Class: Content_ID.22
9.5 Class: Version.22
9.6 Class: Area_version.23
9.7 Class: Content_version .23
9.8 Class: Operation.23
9.9 Class: Request_to_send_data .24
9.10 Class: With_or_without_data .24
9.11 Class: Data_size .24
9.12 Class: Kind_of_content .25
9.13 Class: Emergency_data_identifier.25
9.14 Class: Main_data .25
Annex A (normative) Abstract test suite. 26
Annex B (informative) Description of UML expression elements . 27
Annex C (informative) Use cases. 29
Annex D (informative) Examples of protocols for each update . 35
Annex E (informative) Example of a data update operation . 50
Bibliography. 52

iv © ISO 2011 – 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.
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.
ISO 24099 was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
Introduction
This International Standard was developed in relation to growing market demand for dynamic update services
for map-related data in navigation systems. Map-related data includes not only feature geometry and
attributes but also point of interest (POI) data such as hotels, restaurants, and dynamic content such as traffic,
weather, movie schedules, parking availability, etc. Currently, most map data updates are provided on
physical media whose map data content begins aging rapidly once it is delivered to the user. In the future, it is
anticipated that the transmission of these data will most often, but not exclusively, be via wireless means. The
advantage of wireless data delivery is that it simplifies the distribution logistics thereby accelerating the ability
of a consumer to receive fresher data. This International Standard facilitates the potential for on-demand
updates of on-board map databases. Further, the updates do not necessarily require the replacement of an
entire map database. Rather, the updates can be limited to a portion of a dataset or a specific list of attributes
or POI changes can also be provided.
The services described above have begun to be deployed in a non-interoperable manner by various car
manufacturers and information system providers. This International Standard is intended to promote the
successful widespread adoption of such services through user access to an interoperable network of servers
offering more content choices than is available through a single provider.
This International Standard defines the data structures and protocol needed to enable interoperability between
multiple content providers and consumers of map-related data content in a wireless environment. As far as
possible the data structures are compatible with the ISO geographic data file (GDF) data model. Different
software profiles can be developed to support various system configurations: systems which store all data in
the vehicle (on-board), systems which store all data in a central server (off-board), and systems which use
both on-board and off-board data storage (hybrid).
Furthermore, this International Standard is designed to utilize the communications protocols such as those
under development in TC 204/WG 16. This International Standard recognizes the possible need for security
mechanisms in the provision of this data.
The International Organization for Standardization (ISO) draws attention to the fact that it is claimed that
compliance with this document may involve the use of a patent concerning procedures, methods and/or
formats given in this document.
ISO takes no position concerning the evidence, validity and scope of this patent right.
The holder of this patent right has assured ISO that he/she is willing to negotiate licences under reasonable
and non-discriminatory terms and conditions with applicants throughout the world. In this respect, the
statement of the holder of this patent right is registered with ISO. Information may be obtained from:
INCREMENT P CORPORATION (iPC) 1-7-1 Shimomeguro, Meguro-ku, Tokyo 153-8665, Japan
Hitachi, Ltd. 6-6, Marunouchi 1-chome, Chiyoda-ku, Tokyo 100-8280, Japan
NAVTEQ 425 W Randolph St, Chicago IL 60606, USA
Nissan Motor Co., Ltd. 17-1, Ginza 6-chome, Chuo-ku, Tokyo 104-8023, Japan
Toyota Motor Corporation 1 Toyota-Cho, Toyota City, Aichi Prefecture 471-8571, Japan
Xanavi Informatics Corporation 6-35, Hironodai 2-chome, Zama-shi, Kanagawa-ken 228-0012, Japan
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights other than those identified above. ISO shall not be held responsible for identifying any or all such patent
rights.
vi © ISO 2011 – All rights reserved

2 Conformance
Protocols and data structures shall be provided as specified in Clauses 8 and 9.
Any protocols and data structures claiming conformance with this International Standard shall pass the
requirements presented in the abstract test suite in Annex A.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
address location
application category that deals with the task of expressing a real world position in terms of the physical
storage format (PSF) data representation
NOTE One of the six application categories supported by the physical storage format (PSF) and the application
programming interface (API) and defined in ISO/TS 20452.
3.2
application category
basic sub-function within the set of functionality for vehicle navigation and traveller information system
applications
NOTE ISO/TS 20452 identifies six application categories: positioning, route planning, route guidance, map display,
address location, services and point of interest (POI) information access.
3.3
data broadcasting
one-way communication by a Service Centre
3.4
data providing
two-way communication of data initiated by the In-vehicle System in which the version is controlled by the
Service Centre
3.5
data pushing
two-way communication of data initiated by the Service Centre
3.6
data retrieving
two-way communication of data initiated by the In-vehicle System in which the version is controlled by the
In-vehicle System
3.7
emergency data
data that is safety and/or security related
NOTE This data can be unilaterally sent by a sender to a user (such as data of accidents or disasters).
3.8
incremental update
action allowing for the replacement, insertion or deletion of features and/or attributes only when they change
from a previous version of the data set
3.9
in-vehicle system
function that receives update data and provides navigation and traveller information system applications
2 © ISO 2011 – All rights reserved

3.10
map centre
supplier of map data
3.11
map data
shape data composed from road, background and topology data (such as features, geometry, and
attributions)
3.12
map display
application category that deals with graphical information presentation
NOTE One of the six application categories supported by the physical storage format (PSF) and the application
programming interface (API) and defined in ISO/TS 20452.
3.13
point of interest (POI) data
destination and/or site of interest to travellers (such as restaurants)
3.14
positioning
application category that deals with the determination of vehicle location and map matching
NOTE One of the six application categories supported by the physical storage format (PSF) and the application
programming interface (API) and defined in ISO/TS 20452.
3.15
protocol
computer language enabling computers that are connected to each other to communicate
NOTE Protocol here is as sequence.
3.16
route guidance
application category that deals with the generation of graphical, textual, and/or audio instructions for following
a planned route
NOTE One of the six application categories supported by the physical storage format (PSF) and the application
programming interface (API) and defined in ISO/TS 20452.
3.17
route planning
application category that deals with the determination of routes between specified points
NOTE One of the six application categories supported by the physical storage format (PSF) and the application
programming interface (API) and defined in ISO/TS 20452.
3.18
update target
the object of update, which is sometimes specified by area, and the other times by features and attributes
NOTE One of the six application categories supported by the physical storage format (PSF) and the application
programming interface (API) and defined in ISO/TS 20452.
3.19
services and point of interest (POI) information access
application category that deals with the provision of point of interest (POI) information to the navigation
application
3.20
Service Centre
function that provides update data to In-vehicle Systems
3.21
status data
data that represent a status of a road or traffic (such as real time geographic traffic data)
3.22
update
sequence of flow of data between a Service Centre and an In-vehicle System to change the data inside a map
database in an In-vehicle System
3.23
update by geographic area
action allowing for the complete replacement of data for a specific geographic area or for an entire data set
4 UML Expressions for diagrams
This International Standard uses UML to express specific circumstances; the graphical elements are used to
express specific constraints and structural relationships. A full definition can be found in ISO 19501. However,
a short introduction of elements is given in Annex B.
5 Abbreviated terms
ADAS Advanced Driver Assistance System
API Application Programming Interface
CU Close Update
CPU Central Processing Unit
DB Database
FTP File Transfer Protocol
GDF Geographic Data File
HTTP Hyper Text Transfer Protocol
IP Internet Protocol
ITS Intelligent Transport System
IVS In-vehicle System
LDO Logical Data Organization
LR Location Referencing
NetBEUI NetBIOS Extended User Interface
NetBIOS Network Basic Input/Output System
OSI Open Systems Interconnection
4 © ISO 2011 – All rights reserved

POI Point of Interest
PPP Point-to-Point Protocol
PSF Physical Storage Format
ROD Request of Data
RUC Request of Update Category
SC Service Centre
SMTP Simple Mail Transfer Protocol
TCP Transmission Control Protocol
TOD Transmission of Data
TUC Transmission of Update Category
UML Unified Modelling Language
6 Requirements
6.1 User-related requirements
User-related requirements are defined as follows.
⎯ R-1. The data delivery structures and protocols shall support the six application categories: map display,
positioning, route planning, route guidance, address location, service and POI information access.
⎯ R-2. The protocols and data structures shall be designed in such a way that they do not force degradation
of system performance before, during or after their use.
⎯ R-3. The data exchanges between the Service Centre and In-vehicle Systems shall use an open (non-
proprietary) data format (see example). The specification of the sender's address of data is described
under the open data form, but the description of the content may be done by binary representation.
EXAMPLE XML.
6.2 Data requirements
Data requirements are defined as follows.
⎯ R-4. The data shall include, at a minimum, map data (see Example 1), and it may also include some
status data, and POI data. Advanced driver assistance system (ADAS) related map data may be included
as an extension. Some of the data shall be distinguished as emergency data (see Example 2).
EXAMPLE 1 Features, geometry, and attributes.
EXAMPLE 2 Real time geographic traffic data.
⎯ R-5. Data structures shall be easy to handle by In-vehicle Systems.
⎯ R-6. The data structures shall minimize dataset size as much as possible for both transmission and
processing in In-vehicle Systems coming on the market.
6.3 Protocol requirements
Protocol requirements are defined as follows.
⎯ R-7. The update protocol(s) shall be compatible with both wireless and wired methods.
⎯ R-8. The protocol shall not require more storage or computing power than is expected to be available in
In-vehicle Systems coming on the market.
⎯ R-9. The protocol in this International Standard shall be written with sufficient flexibility both to support
existing communication technology and to improve the capability to address future communication
technologies.
⎯ R-10. The protocol defines how to deliver map-related data between Service Centre and In-vehicle
Systems.
⎯ R-11. The protocol is expected to be used in a mobile environment in which communications may be
interrupted (see Example). The protocol shall support complete and efficient recovery from interruptions
of communication. For example, it shall avoid retransmission of an entire update when only a small part is
not received.
EXAMPLE By driving through tunnels or driving in areas of poor or no reception.
⎯ R-12. The protocol shall minimize dataset size as much as possible for both transmission and processing
in In-vehicle Systems coming on the market.
6.4 Communication requirements
Communication requirements are defined as follows.
⎯ R-13. The general update process shall be independent from the (technical) communication link between
the Service Centre and the In-vehicle Systems.
⎯ R-14. Within reason, the update process shall support communication links with a limited bandwidth.
6.5 Update strategies
Update strategies are defined as follows.
⎯ R-15. The design of the update process shall be independent from the data supplier (see Example 1).
The design of the update process shall be independent from the in-vehicle application.
EXAMPLE 1 Map Centre.
⎯ R-16. This International Standard shall support updates of different categories of data (see Example 2) at
different frequencies.
EXAMPLE 2 Map features and attributes, status data and POI data.
⎯ R-17. In-vehicle System functionality is affected by real world changes to spatial features and their
attributes (see Example 3). Therefore, the data available in the In-vehicle System shall be kept up-to-date.
EXAMPLE 3 New roads are built, road names can change, and previously existing errors can be corrected.
⎯ R-18. This International Standard supports two methods for supplying updates:
⎯ Update by geographic area: this method allows the complete replacement of data for a specific
geographic area or for an entire data set.
⎯ Incremental update of Spatial Features and Attributes: this method allows the replacement, insertion
or deletion of features and/or attributes only when they change from a previous version of the data set.
6 © ISO 2011 – All rights reserved

⎯ R-19. This International Standard supports four strategies for supplying updates:
⎯ Data Providing: two-way communication of data initiated by the In-vehicle System in which the
version is controlled by the Service Centre.
⎯ Data Retrieving: two-way communication of data initiated by the In-vehicle System in which the
version is controlled by the In-vehicle System.
⎯ Data Pushing: two-way communication of data initiated by the Service Centre.
⎯ Data Broadcasting: one-way communication by the Service Centre.
6.6 Others
Other requirements are defined as follows.
⎯ R-20. The process of defining requirements in this International Standard shall not favour any particular
logical data organization (LDO) and/or physical storage format (PSF). Existing LDOs and/or PSFs may be
taken into account in defining requirements.
⎯ R-21. This International Standard shall be scalable and generic to support future communication
technologies and data structures.
⎯ R-22. The interfaces shall be designed in such a way that a newer interface shall still support older PSFs
on the market, and older interfaces shall support newer PSFs, potentially restricted to the content of the
older version.
7 Reference architecture and framework concept
7.1 Reference architecture
Figure 2 represents the general architecture that supports the navigation data delivery by a Service Centre to
an In-vehicle System according to this International Standard.
Delivery data
Header
Application and Body1
communication
(Map data, etc.)
protocol
Body 2
…
Figure 3 — Basic structure of delivery data
7.2 Framework concept
7.2.1 Varieties of updates
Varieties of updates are defined as triple of initiatives, types and data categories.
Classifications of data categories initiatives and types can be found in Clause 6 and Annex C.
Data Categories (4) Initiatives (4) Types (2)

- Map data - Data providing - By geographic area
Updates - POI data - Data retrieving - Incremental (Replace,
= xx
- Status data - Data pushing insert, delete)
- Emergency data - Data broadcasting

Figure 4 — Varieties of updates
7.2.2 Case of update by geographic area
7.2.2.1 Introduction
When an update is done by geographic area, all the data of the geographic area is sent, which means the
data set also includes unchanged information.
There are two methods of updates: Mode1, execute post-compilation at the In-vehicle System, Mode2,
execute some kind of pre-compilation at the Service Centre (i.e. generating necessary layers, etc.) in order to
reduce the process at the In-vehicle System.
Most of the actual systems are hybrids of Mode1 and Mode2.
A full update is a specific case of an update by geographic area. A full update is done to replace the whole In-
vehicle System dataset.
7.2.2.2 Case of Post-compilation (Mode1)
Service Centre
Map Centre
In-vehicle System
Data
Applicati on
Server
Appl ication
Map
Area of update Area of u pdate
Centre DB
Service
Temporary
Onboard DB
Conversion
Ce ntre DB
Onb oard DB
Distribution Update
Extraction
Temporary Onboard DB
Onboard DB
Generate
Service Centre
Area of update
Generate
Figure 5 — Case of Post-compilation (Mode1)
An In-vehicle System receives an area of update data from a Service Centre through the communication.
Compilation and layer generations are done in the In-vehicle System.
NOTE Generally, a Post-compilation Mode tends to have a lower volume of transmitted data.
10 © ISO 2011 – All rights reserved

7.2.2.3 Case of Pre-compilation (Mode2)

In-vehicle System
Map Centre Service Cen tre
Data
Applicati on
Server
Application
Driver
Area of update
Area of update
Map
Cent re DB
Service Onboard DB
Centre DB (No conversion)
Update
Distribution
Extraction
Service Centre DB
Onboard DB
Area of upd ate
Figure 6 — Case of Pre-compilation (Mode2)
An In-vehicle System receives an area of update data from a Service Centre through the communication.
Updating data of all layers is made at a Service Centre, including the relationships of each layer.
NOTE Generally, the compilation in the In-vehicle System is minimized. Integrating the data to the onboard database
(DB) is basically the only process needed in an In-vehicle System. The central processing unit (CPU) load is likely to be
lighter than in a Post-compilation system (Mode1), though the volume of update data is likely to increase.
7.2.3 Case of incremental update
When update is done incrementally, only the different parts are sent.
As seen in the update by geographic area, there are also two modes of incremental updates: Mode1, to
compile the data at an In-vehicle System (Post-compilation), and Mode2, to compile the data at a Service
Centre and provide required layers (Pre-compilation).
Most of the actual systems are hybrids of Mode1 and Mode2.
Mode1 Post-compilation
An In-vehicle System receives the minimum amount of update data (i.e. only changes) from a Service
Centre through the communication mean. Each In-vehicle System compiles and generates the subset of
data.
NOTE 1 Generally, a Post-compilation method (Mode1) tends to have a lower volume of data transmitted.
Mode2 Pre-compilation
An In-vehicle System receives update data from a Service Centre through the communication. The
compilation of data is executed in a service centre. Update data is sent out to an In-vehicle System and
incorporated without on-board compilation.
NOTE 2 Generally, the compilation in the In-vehicle System is minimized. Integrating the data to the onboard DB is
basically the only process needed in an In-vehicle System. The CPU load is likely to be lighter than in a Post-compilation
system (Mode1), though the volume of update data is likely to increase.
7.2.4 Descriptions of the exchange process of updating data
When updating a map, a Service Centre and an In-vehicle System shall check the status before and after the
update. For more details, see Annex E.
The process is divided into three steps:
1) Preprocessing: prepare the data to be updated and confirm the user's intention.
2) Delivering of update data: data sending and receiving.
3) Post-processing: verification of the termination and other related tasks.
An entire update process is shown in Figure 7. The data flows in the shaded area in Figure 8 are defined in
this International Standard.
12 © ISO 2011 – All rights reserved

Service Centre In-Vehicle System
Specify the
content to be
updated
1) Preprocessing
Request of Update Category (RUC)
Select the
Content
Update necessity
Transmission of Update Category (TUC)
judgement
Request of Data (ROD)
2) Update
Data
Transmission of Data (TOD)
Update
3) Post-
Processing
Afterward Close Update (CU)
Process
Figure 7 — Entire process of update
The process is conducted by the requests and answers between a Service Centre and an In-vehicle System.
The basic structure of data is described below.
Basic Structure (1) Request
Header
Request
(Request)
Application and
Parameter
communication
(common use)
protocol
Parameter
(proprietary)
Basic Structure (2) Answer
Answer
Header
Application and
Body1
communication
protocol
(Delivery data or
message, script)
Body2
…
Figure 8 — The basic structure of data
7.2.5 Methods for specifying update data by users or centre
The user can specify the update content using the following information:
⎯ data provider;
⎯ type of data;
⎯ area;
⎯ time (version);
⎯ priorities (emergency data, etc.).
The centre defines the possible update content available according to the information above.
7.2.6 Rules for specifying the objects to be replaced or deleted (Rules for identifiers)
It is necessary to identify exactly objects (such as features, attributes, areas) to be replaced or deleted.
However, the rules for specifying the objects are outside the scope of this International Standard.
14 © ISO 2011 – All rights reserved

7.2.7 Version control
The versions of the content in each In-vehicle System, as well as between the In-vehicle Systems, can be
different.
EXAMPLE Various area-data composes one map, and the version differs from each area-data. Also, each system
has different content.
The entire DB of a Service Centre does not necessarily match the entire onboard DB. However, the versions
of the target object/area in both DB shall match after the update.
To make appropriate updates under these circumstances, it is necessary to be able to exchange the version
identifiers between Service Centres and In-vehicle Systems to realize what data needs to be updated.
8 Protocols
8.1 Introduction
This clause defines the protocols for updating data in an In-vehicle System according to the concepts defined
in Clause 7. There are four protocols. Two of them are used when an In-vehicle System is the trigger. The
other two are used when a Service Centre is the trigger. These protocols can handle several data categories.
The relationship between these protocols and the update varieties defined in 7.2.1 is described in Table 1.
The protocols are defined as sequences between a Service Centre and an In-vehicle System. An actual
system may skip the optional sequences of those protocols. In the figures of this clause the optional
sequences are shown as dot-line arrows.
Processes in an In-vehicle System and in a Service Centre are outside the scope of this International
Standard. These processes are shown as chain-line arrows in the figures.
NOTE These protocols result from a study of different cases corresponding to the different varieties of update as
defined in 7.2.1. The studied cases are in Annex D.
Table 1 — Protocols and relationship with the update varieties
Update varieties
Protocols
Data Categories Initiatives Types
Protocol for an In-vehicle-System- Map data, POI data Data providing By geographic area
trigger system delivering map data or
Incremental
POI Data
Data retrieving By geographic area
Incremental
Protocol for an In-vehicle-System- Status data Data providing By geographic area
trigger system delivering status data
Incremental
Data retrieving By geographic area
Incremental
Protocol for a Service-Centre-trigger Map data, POI data, Data pushing By geographic area
system delivering map data, POI data status data
Incremental
or status data
Data broadcasting By geographic area
Incremental
Protocol for a Service-Centre-trigger Emergency data Data pushing By geographic area
system delivering emergency data
Incremental
Data broadcasting By geographic area
Incremental
8.2 Protocol for an In-vehicle-System-Triggered system delivering map data or POI data
First, an In-vehicle System specifies the content to be updated. Then the In-vehicle System sends the
information that specifies content to be updated to a Service Centre. The Service Centre selects the content. It
sends the requested content information. The In-vehicle System judges the update necessity. It requests the
content to be updated. The Service Centre sends the content. The In-vehicle System executes the update. It
sends the completion information. Finally, the Service Centre executes the Afterward Process.

Service Centre In-vehicle System
Specify the
content to be
updated
1. Request of update category (RUC)
Select the
(Update_target_identifier, Kind_of_content, Version)
content
2. Transmission of update category (TUC)
Update
(With_or_without_update_information, Area_ID, Area_version,
necessity
Contents_ID, Content_version, Data_size)
judgement
3. Request of data (ROD)
(Request_to_send_data, Area_ID, Content_ID)
4. Transmission of data (TOD)
(Area_ID, Content_ID, Kind_of_contents, Area_version,
Update
Content_version, Main_data, Operation)
5. Close Update (CU)
Aferward
Process
Figure 9 — Protocol for an In-vehicle-System-Triggered system delivering map data or POI data
16 © ISO 2011 – All rights reserved

8.3 Protocol for an In-vehicle-System-Triggered system delivering status data
First, an In-vehicle System specifies the content to be updated. Then the In-vehicle System sends the
information that specifies content to be updated to a service centre. The Service Centre sends the content.
The In-vehicle System executes the update.
Service Centre In-vehicle System
Specify the
content to be
updated
1. Request of update category (RUC)
Select the
(Update_target_identifier, Kind_of_content, Version)
content
2. Transmission of data (TOD)
(Area_ID, Content_ID, Kind_of_content, Area_version,
Content_version, Main_data, Operation)
Update
Figure 10 — Protocol for an In-vehicle-System-Triggered system delivering status data
8.4 Protocol for a Service-Centre-Triggered system delivering map data, POI data or status
data
First, a Service Centre selects the content to be updated. The Service Centre sends the content information of
update content to an In-vehicle System. The In-vehicle System selects the content to be updated. It requests
the content. The Service Centre sends the content. The In-vehicle System executes the update. It sends the
update completion information. Finally, the Service Centre executes the Afterward Process.

Service Centre In-vehicle System
Select the
content to
be updated
Select the
1. Transmission of update category (TUC)
content to
(Area_ID, Content_ID, Kind_of_content, Data_size)
be updated
2. Request of data (ROD)
(Area_ID, Content_ID, Kind_of_content)
3. Transmission of data (TOD)
(Area_ID,Content_ID, Kind_of_content,
Main_data, Operation)
Update
4. Close update (CU)
Afterward
Process
Figure 11 — Protocol for a Service-Centre-Triggered system delivering map data, POI data or status data
18 © ISO 2011 – All rights reserved

8.5 Protocol for a Service-Centre-Triggered system delivering emergency data
First, a Service Centre selects the content to be updated. The Service Centre sends the content to an In-
vehicle system. The In-vehicle System executes the update.

Service Centre In-vehicle System
Select the
content to
be updated
1. Transmission of data (TOD)
(Emergency_data_identifier, Area_ID, Content_ID,
Kind_of_content, Main_data)
Update
2. Close update (CU)
Afterward
Process
Figure 12 — Protocol for a Service-Centre-Triggered system delivering emergency data
8.6 Definitions of messages used in the protocols
This subclause specifies the messages used by the different protocols to exchange information between a
Service Centre and an In-vehicle System (see Table 2).
Table 2 — Definitions of messages used in the protocols
Name Description Origin Destination Parameters
RUC RUC is a message sent by an In-vehicle In-vehicle Service Update
System that triggers the update procedure System Centre target_identifier,
(Request of
in a Service Centre with a range of update. Kind_of_content,
update
Version
category)
TUC TUC is a message sent by Service Centre Service In-vehicle With_or_without_up
which describes the available update Centre System date_information,
(Transmission
categories. Area_ID,
of update
Area_version,
category)
Content_ID,
Content_version,
Data_size
Kind_of_content
ROD ROD is a message sent by an In-vehicle In-vehicle Service Request_to_send_d
System to request the update data. System Centre ata,
(Request of
data) Area_ID, Content_ID
Kind_of_content
TOD TOD is a message sent by a Service Service In-vehicle Area_ID,
Centre, which contains the update data. Centre System Content_ID,
(Transmission
of data) Area_version,
Content_version,
Kind_of_content,
Main_data,
Operation,
Emergency_data_id
entifier
CU CU is a message sent by an In-vehicle In-vehicle Service
System to inform of the update System Centre
(Close
completion. This message is optional in
update)
the protocols and has no parameter.

20 © ISO 2011 – All rights reserved

9 Data structures
9.1 Introduction
The data exchange between a Service Centre and an In-vehicle System is structured by the five messages
defined in Table 2. The relationship between the messages and the parameters exchanged is shown in
Figure 13. The multiplicity appearing at each end of a relationship explains whether a parameter is optional or
not, and whether it may appear several times.
RUC TUC TOD
ROD CU
(Request of (Transmission of (Transmission of
(Request of Data) (Close Update)
Update Category) Update Category) Data)
0.1
1 0.1 0.1 11 0.1 0.1
1 0.1 0.1
0.1 1
0.1 1
0.1 1
0.1 1
0.1
0.1
0.1
0.* 0.*
0.*
0.*
0.1
Update_target_
Kind_of_content
Emergency_data_
0.*
identifier
identifier
0.* 0.* 0.*
0.* 1 0.* 0.*
With_or_without_
Version Content_ID Content_version 0.*
update_information
Operation
0.1 0.* 0.*
0.* 0.* 0.*
1.*
Data_size Area_version Area_ID
Main_data
Request_to_send
_data
Figure 13 — Data structure
9.2 Class: Update target_identifier
Class Update target_Identifier is a class used in a message originated with an In-vehicle System to a Service
Centre to specify the update target where the update is required. This is used when the In-vehicle System
cannot identify the IDs of the content coming from the Service Centre when requested.
RUC
(Request of
Update Category)
0.*
Update_target_
identifier
Figure 14 — Class: Update target_identifier
9.3 Class: Area_ID
Class Area_ID is a class used by a data provider to inform a data receiver about the identifier of the update
target to be updated. It is then used to specify the update target identifier of the update data. This is used
when the type of the update is “By Geographic area”.
TUC TOD
ROD
(Transmission of (Transmission of
(Request of data)
update category) data)
0.1 0.1 0.1
0.* 0.* 0.*
Area_ID
Figure 15 — Class: Area_ID
9.4 Class: Content_ID
Class Content_ID is a class used by a data provider to inform a data receiver about the identifier of the
content to be updated. It is then used to specify the content identifier of the update data. This is used when
the update type is “Incremental”.
TUC TOD
ROD
(Transmission of (Transmission of
(Request of data)
update cat
...