ISO/TS 18750:2015

TECHNICAL ISO/TS
SPECIFICATION 18750
First edition
2015-05-15
Intelligent transport systems —
Cooperative systems — Definition of a
global concept for Local Dynamic Maps
Systèmes intelligents de transport — Systèmes coopératifs —
Définition d’un concept global pour cartes dynamiques locales
Reference number
©
ISO 2015
© ISO 2015, 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. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Symbols and abbreviated terms . 3
5 Architectural environment . 4
5.1 General . 4
5.2 Local Dynamic Map . 4
5.3 LDM in an ITS-S . 4
5.4 LDM in an ITS-SU . 5
5.5 LDM-related processes . 7
5.5.1 Synchronization of LDMs . 7
5.5.2 Archiving of LDM Data Objects . 7
5.6 LDM for road safety and vehicle-to-vehicle applications . 7
5.7 Security perspective . 7
5.7.1 Authorized access to LDM. 7
5.7.2 Initialisation and installation of applications to the BSMD . 7
5.7.3 Privacy . 8
5.8 LDM versus other similar functionalities in an ITS-SU . 8
6 Functionality . 9
6.1 General definitions and conventions . 9
6.2 Structure of an LDM .10
6.3 LDM Data Storage .12
6.4 LDM services .14
6.4.1 Registration, deregistration, and revocation of ITS-S application processes .14
6.4.2 Security checking in access requests .14
6.4.3 Access request management .14
6.5 LDM maintenance . .17
6.5.1 LDM Area of Maintenance .17
6.5.2 Outdated data management .17
6.6 LDM knowledge base .17
6.6.1 Metadata .17
6.6.2 Utility functions .17
6.7 Interfaces .18
6.7.1 Types of interfaces .18
6.7.2 Parameters of interface functions .18
6.7.3 LDM application management interface .20
6.7.4 LDM data interface .22
6.7.5 Security interface .25
6.7.6 LDM management interface .26
6.7.7 Service access points .27
7 Procedures .29
7.1 LDM services .30
7.1.1 Registration, deregistration, and revocation of ITS-S application processes .30
7.1.2 Security checking in access requests .30
7.1.3 Access request management .30
7.1.4 Second-level filtering .32
7.2 LDM maintenance . .32
7.2.1 Area management .32
7.2.2 Outdated data removal .33
7.3 LDM knowledge database .33
7.4 Interfaces .33
7.5 LDM management .33
7.5.1 Registration of LDM at ITS-S management entity .33
7.5.2 Multiple ITS-SCUs .33
Annex A (normative) ASN.1 modules .34
Annex B (normative) LDM Data Dictionary .45
Annex C (informative) Examples of LDM-DOs .47
Annex D (informative) Location referencing .53
Annex E (informative) Time referencing .57
Bibliography .58
iv © ISO 2015 – 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.
ISO/TS 18750 was prepared by the European Committee for Standardization (CEN) in collaboration with
ISO/TC 204, Intelligent transport systems, in accordance with the Agreement on technical cooperation
between ISO and CEN (Vienna Agreement).
Introduction
[16]
An essential property of cooperative intelligent transport systems (C-ITS) is the sharing of data
between different ITS applications providing different ITS services to the users. This approach replaces
the traditional approach where each application is operated in an isolated environment, i.e. referred
to as “silo approach”. The C-ITS approach enables synergies in components of an ITS station unit, e.g.
sharing of communication tools, improves overall performance and reliability, and reduces overall cost.
In order to protect the interests of the various ITS applications, C-ITS implements the concept of an
ITS station (ITS-S) operated as bounded secured managed domain.
The sharing of data between applications is achieved by subscribe/publish mechanisms, where at
least two mechanisms are distinguished, i.e. one allowing ITS-S application processes to subscribe to
standardized messages from ITS message sets (direct forwarding upon reception of such messages
in an ITS station unit) and one using a Local Dynamic Map (LDM) as repository of standardized data
objects. Such data objects stored in an LDM are named LDM Data Objects (LDM-DOs). LDM-DOs provide
self-consistent information on real objects existing at a given geo-location during a given lifetime-
interval. Authorized ITS-S application processes may add LDM-DOs to an LDM and may retrieve LDM-
DOs from an LDM. Retrieval of LDM-DOs may be performed in queries and by means of subscription. A
subscription will result in automatic notifications of selected LDM-DOs either in defined time intervals
or event driven.
This Technical Specification introduces the usage of LDMs and specifies the LDM for global usage in C-ITS.
[32] [34]
Initial implementations of LDMs were in the EU research projects CVIS and Safespot .
vi © ISO 2015 – All rights reserved

TECHNICAL SPECIFICATION ISO/TS 18750:2015(E)
Intelligent transport systems — Cooperative systems —
Definition of a global concept for Local Dynamic Maps
1 Scope
This Technical Specification
— describes the functionality of a “Local Dynamic Map” (LDM) in the context of the “Bounded Secured
Managed Domain” (BSMD), and
— specifies
— general characteristics of LDM Data Objects (LDM-DOs) that may be stored in an LDM, i.e.
information on real objects such as vehicles, road works sections, slow traffic sections, special
weather condition sections, etc. which are as a minimum requirement location-referenced and
time-referenced,
— service access point functions providing interfaces in an ITS station (ITS-S) to access an LDM for
— secure add, update, and delete access for ITS-S application processes,
— secure read access (query) for ITS-S application processes,
— secure notifications (upon subscription) to ITS-S application processes, and
— management access,
— secure registration, de-registration, and revocation of ITS-S application processes at
LDM, and
— secure subscription and cancellation of subscriptions of ITS-S application processes,
— procedures in an LDM considering
— means to maintain the content and integrity of the data store, and
— mechanisms supporting several LDMs in a single ITS station unit.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO 21217, Intelligent transport systems — Communications access for land mobiles (CALM) — Architecture
ISO/IEC 8824-1:2008, Information technology — Abstract Syntax Notation One (ASN.1): Specification of
basic notation — Part 1
ISO/IEC 8825-2:2008, Information technology — ASN.1 encoding rules: Specification of Packed Encoding
Rules (PER) — Part 2
ISO 24102-3, Intelligent transport systems — Communications access for land mobiles (CALM) — ITS station
management — Part 3: Service access points
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
data integrity
property that data has not been altered or destroyed in an unauthorized manner
[SOURCE: ISO 24534-5]
3.2
International Atomic Time
time since 00:00:00 UTC, 1 January, 2004, identical with UTC except that no leap seconds need to be added
3.3
LDM area of interest
location requirement used in the filter process of queries and automatic notifications
3.4
LDM area of maintenance
information on the operational location area of an LDM used by LDM maintenance
Note 1 to entry: Reference [22] restricts the LDM Area of Maintenance to “geographical area specified by the LDM
for LDM maintenance”
3.5
LDM permissions
information on how a specific ITS-S application process may use an LDM
3.6
LDM data object
location-referenced and time-referenced representation of a real object that is self-explanatory without
any further context information
3.7
LDM data object ID
identifier of an LDM data object which is unique in an LDM
3.8
LDM data dictionary
dictionary of LDM data object types
3.9
LDM data object type
identifier of the type of information contained in an LDM data record
3.10
location validity
information indicating a location at which an LDM data object is valid
3.11
time validity
information indicating a time interval during which an LDM data object is valid
3.12
LDM time of interest
time requirement used in the filter process of queries and automatic notifications
3.13
Local Dynamic Map
entity consisting of LDM data objects, services, and interfaces for manipulating these LDM data objects
2 © ISO 2015 – All rights reserved

3.14
location reference
uniquely identifiable description of position or area in the real world
3.15
metadata
data about data
Note 1 to entry: The term “metadata” is ambiguous as it is used for fundamentally different concepts. Structural
metadata are information related to the design and specification of data structures; it is also referred to as “data
about the containers of data”. Descriptive metadata are information on instances of data, i.e. the data content; it is
also referred to as “data about data content”.
[SOURCE: ISO 19115]
3.16
time of creation
time when an LDM data record was created and updated
3.17
time of deletion
time when an LDM data record may be deleted and will no more be considered by the LDM search
functionality
3.18
time of generation
time when the content of the LDM data object information field was created
Note 1 to entry: This is different to the time when the LDM data object was written into an LDM.
4 Symbols and abbreviated terms
BSMD Bounded Secured Managed Domain
BSME Bounded Secured Managed Entity
IAT International Atomic Time
ICS Implementation Conformance Statement
ITS Intelligent Transport Systems
ITS-SU ITS Station Unit
IUT Implementation Under Test
LDM Local Dynamic Map
LDM-DD LDM Data Dictionary
LDM-DT LDM Data Type
LDM-DAT LDM Data Attribute Type
LDM-DATID LDM-DAT Identifier
LDM-DTID LDM-DT Identifier
NoO Notification of Obligations
OoT Obligation of Trust
PMI Privilege Management Infrastructure
SAO Signed Acceptance of Obligations
SUT System Under Test
TPEG Transport Protocol Experts Group
UTC Universal Time Coordinated
5 Architectural environment
5.1 General
This Clause contains informative descriptions of the architectural environment of an LDM.
5.2 Local Dynamic Map
A Local Dynamic Map (LDM) is an entity consisting of LDM Data Objects (LDM-DO), services, and
interfaces for manipulating these LDM Data Objects. LDM-DOs are distinguished by means of their LDM
Data object Type (LDM-DT). LDM-DTs are specified by registration in an LDM Data Dictionary (LDM-
DD). The concept of the LDM-DD is specified in Annex B.
NOTE In Reference [17], LDM-DOs are classified into Type 1 (static permanent data objects, e.g. cartographic
[5] [5]
data ), Type 2 (static transitory data objects, e.g. temporary parking lot on the road ), Type 3 (dynamic
transitory data objects, e.g. works location), and Type 4 (highly dynamic data objects, e.g. location, orientation,
and speed of surrounding vehicles). This classification is not used in this Technical Specification.
An LDM-DO provides information on real objects (cars, road events, etc.) that are existent at a defined
location, e.g. in a defined geo-area and within a defined time interval. In the uppermost simple case, the
information provided by an LDM-DO is just its type, its geo-location, and its time interval of validity.
Such information may be received in an ITS station unit via different channels such as
[30][26]
— DATEX II, TPEG, RDS-TMC (legacy systems), and
[22][21]
— CEN/ETSI/ISO/SAE ITS message sets,
composed of different sets of attributes, and presented in different formats (encodings). ITS-S application
processes capable to receive this information perform a mapping on LDM-DOs and a translation of
attribute formats into the common format given by the LDM-DTs.
5.3 LDM in an ITS-S
The Local Dynamic Map (LDM) specification provided in this Technical Specification is designed for the
architectural environment of an ITS station operated as a Bounded Secured Managed Domain (BSMD)
specified in ISO 21217 and illustrated in Figure 1.
4 © ISO 2015 – All rights reserved

Figure 1 — LDM in an ITS-S operated as a Bounded Secured Managed Domain (BSMD)
The LDM functionality specified in Clause 6 is located in the ITS-S facilities layer. An LDM interfaces with
ITS-S application processes specified in ISO 21217. The interface functionality is specified in 6.6.2 by means
of functions of services of the FA-SAP and the MF-SAP; both service access points (SAPs) offer identical
functions for this purpose. The generic services of FA-SAP and MF-SAP are specified in ISO 24102-3.
5.4 LDM in an ITS-SU
Various examples of supported implementation configurations are illustrated in Figure 2, Figure 3,
Figure 4, and Figure 5.
Figure 2 illustrates a “single-box” configuration of an ITS station unit (ITS-SU) with a single LDM.
Figure 2 — Implementation configuration example a)
Figure 3 illustrates a “single-box” configuration of an ITS-SU with two LDMs.
Figure 3 — Implementation configuration example b)
Figure 4 illustrates a configuration of an ITS-SU with two ITS station communication units (ITS-SCU).
One of these ITS-SCUs has a host-only role specified in ISO 21217 and contains a single LDM. The other
ITS-SCU has a router-only role specified in ISO 21217 and does not contain an LDM.
Figure 4 — Implementation configuration example c)
Figure 5 illustrates a configuration of an ITS-SU with two ITS station communication units (ITS-SCU).
One of these ITS-SCUs has a host-only role specified in ISO 21217 and contains a single LDM. The other
ITS-SCU has a host-and-router role specified in ISO 21217 and contains also an LDM.
Figure 5 — Implementation configuration example d)
Many other implementation configurations are feasible.
NOTE In ITS-SUs composed of several ITS-SCUs, the ITS station management can use the “ITS station-internal
[11]
management communications protocol” (IICP) to support overall station management
6 © ISO 2015 – All rights reserved

5.5 LDM-related processes
5.5.1 Synchronization of LDMs
The concept of synchronization of LDMs is introduced in Reference [17], distinguishing
— synchronization of LDMs operated in ITS station units of different vehicles, and
— synchronization of LDMs operated in ITS station units at the roadside, in central offices, and in vehicles.
Reference is made to means which are already in use for TPEG and DATEX.
Such synchronization means updating of an LDM by an authorized “master” LDM. As only ITS-S
application processes can access LDM-DOs, any synchronization is to be realized by ITS applications.
Details are outside the scope of this Technical Specification.
NOTE Updates of information in an ITS-SU can be performed using remote management standardized in
Reference [10].
5.5.2 Archiving of LDM Data Objects
Archiving of LDM Data Objects is a feature that produces a kind of log-file of an LDM. Such log-file
information might be of interest for different purposes, but might also be subject to privacy considerations.
This Technical Specification specifies neither an archiving functionality nor related interfaces. Archiving
can be implemented in a non-standardized way.
5.6 LDM for road safety and vehicle-to-vehicle applications
An LDM dedicated to usage for road safety and vehicle-to-vehicle applications (electronic horizon) is
specified by ETSI in Reference [22]. This ETSI LDM specification constitutes a functional sub-set of the
specification provided in this Technical Specification.
5.7 Security perspective
5.7.1 Authorized access to LDM
The architecture of an LDM in the context of BSMD from a security perspective is to ensure that access is
restricted to identified and authorized ITS-S application processes. Application processes not certified
for operation in a BSMD may access an LDM via a secure gateway described in ISO 21217, where the
firewall ITS-S application process of this gateway is authorized for read-access to the LDM.
All the core assets are to be considered as vulnerable and therefore subject to protection, where
protection takes the form of specific guards. The guard mechanism used in protecting the LDM is a
policy-based access control scheme where ITS-S application processes will pre-register their policy with
the ITS-S, and if that policy is agreed, all future access by the ITS-S application process will be verified
as being consistent with the policy.
5.7.2 Initialisation and installation of applications to the BSMD
The kernel of an ITS-SCU forms a trust centre of the BSME and is identifiable to third-party ITS-S
application processes as such. Any ITS-S application process to be added to an ITS-SCU within the
BSME verifies the identity and capability of the ITS-SCU prior to installation. If installation is allowed,
an ITS-SCU verifies the credentials offered by the ITS-S application process. Prior to distribution, each
ITS-S application process is functionally verified and tested and assertions of required functionality, of
[18]
developer identity, and of the tester are validated prior to installation.
[33]
The core model follows that developed in the i-Tour project as an extension of an “Obligation of Trust”
(OoT) protocol, extending the models used for Java midlet distribution used in many common application
[18]
stores. The protection framework is a form of a Privilege Management Infrastructure (PMI) based
on common cryptographic modules and processing where authorization is viewed as a set of mutually
agreed actions through the assignment of permissions to the parties, i.e. the LDM and the LDM user. In
the OoT protocol, the participating parties exchange difficult-to-repudiate digitally signed obligating
constraints, also referred to as “Notification of Obligations” (NoO), which detail their requirements for
sending their sensitive information to the other party, and proof of acceptances, also referred to as
“Signed Acceptance of Obligations” (SAO), which acknowledge the conditions they have accepted for
receiving the other party’s sensitive information. The required capabilities of the LDM user, i.e. an ITS-S
application process, to be installed will be declared and the application restricted to use only those
capabilities by means of a policy enforcement engine acting in the role of a Policy Enforcement Point in
the LDM itself.
For protection of data, the data objects identified below capture the primary policy elements:
— PrivacyPolicyDirective;
— SecurityPolicyDirective;
— SignedPrivacyPolicy;
— SignedSecurityPolicy;
— CounterSignedPrivacyPolicy;
— CounterSignedSecurityPolicy.
The privacy policy directive is a set of policy statements that identify the identity of the data controller.
The privacy enforcement point agrees to implement the policy and to indicate that in the Signed Privacy
Policy where the signature is of the data processor (acting as policy enforcement point).
Acceptance of the privacy policy is notified by the client in the Countersigned Privacy Policy where
the signature is given by the client using the pseudonymous identity agreed during registration. The
retention of the countersigned policy agreement provides the basis of non-repudiation of consent.
NOTE The data privacy legislation in Europe assumes the presence of a number of entities in a system dealing
with private data. These are the data controller, data processor and data subject, and a contract of consent. In an
all-informed C-ITS, there is no a priori consent establishment between the transmitting ITS-SU and any of the
receiving ITS-SUs, thus, the security model attempts to minimize the possibility of any personal data being made
known to a receiving ITS-SU. The model therefore virtualizes the functionality of data controller, data processor,
and consent by use of verifiable proofs of authority to act on data.
Permissions resulting from policy are of type “Permit” and “Deny” based on authorization, i.e. after
application of the policy, the request is either permitted or denied. Requests themselves may contain
specific access requests, e.g. read data from the LDM, write data to the LDM.
Every incoming command to the LDM is associated with a set of claims that are checked against the local
policy at the PEP in the LDM. If any data access attempt from an application is made post-registration
and post-acceptance of the policy that does not comply with the policy, it is denied.
5.7.3 Privacy
The C-ITS enforces pseudonymity capabilities through the security functions described in ETSI/TS 102
[24] [25]
940 and ETSI/TS 102 941 which maintains privacy control of data entered into the LDM.
5.8 LDM versus other similar functionalities in an ITS-SU
The sharing of data between ITS-S application processes in an ITS-SU can be achieved by subscribe/publish
mechanisms, where at least two mechanisms are distinguished, i.e.
a) one allowing ITS-S application processes to subscribe at the ITS-S facilities layer to standardized
[19]
messages from ITS message sets as specified in without using an LDM, and
8 © ISO 2015 – All rights reserved

b) one using a Local Dynamic Map (LDM) as repository of standardized data objects.
[19]
The approach a) standardizes an ITS-S facility layer message handler which can
— directly forward complete received messages to subscribed ITS-S application processes without
storing these messages, and
— present LDM Data Objects to an LDM in case these LDM Data Objects are contained in messages that
follow the message format convention of this message handler.
There may be also other data storages, which are basically different to an LDM, i.e. which may store data
objects that are not following the definition of an LDM-DO.
6 Functionality
This Clause contains informative descriptions of the functionality of an LDM.
6.1 General definitions and conventions
As explained in 5.2, an LDM deals with information on real objects that are existent at a defined location
(geo-area) and within a defined time interval. Such information on a real object is identified in an LDM
Data Record (see Figure 7). Every LDM Data Record is identified with a unique LDM Data Record ID; the
value zero indicates an “unknown record”.
Different location and time definitions are used to define the functionality of an LDM.
— Definitions related to the information on the real object:
— Location Validity
Information at which geo-location or in which geo-area the LDM-DO applies.
— Time Validity
Information in which time interval(s) the LDM-DO applies.
— Time of Generation
Information on the time when the LDM-DO information was generated, e.g. time when a perception
system (e.g. a sensor) detected the event “slippery road”.
— Time of Mandatory Deletion
Information on time after which the LDM record will no longer be returned in a query.
— Definitions used in queries:
— LDM Area of Interest
Geo-location(s) or geo-area(s) that are of interest for the querying ITS-S application process.
— LDM Time of Interest
Time instant or time interval(s) that are of interest for the querying ITS-S application process.
— Age of Interest
Age of LDM record as required by the querying ITS-S application process. The age is calculated with
a numerical operator presented by the ITS-S application process against the time of generation of an
LDM-DO, if available, or alternatively against the time of last update of an LDM-DO.
— Definitions used for maintenance purposes:
— LDM Area of Maintenance
Geo-area(s) considered by the LDM search functionality and defined by the LDM in an implementation-
specific way. Without overlap of the LDM Area of Interest with the LDM Area of Maintenance, a query
will not result in a hit. Note that the area of maintenance can be defined relative to the momentary
location of the host ITS-S.
— LDM Inactive Area
Geo-area(s) considered by the LDM to store LDM records with are not considered by the search
functionality; there is no overlap between the LDM Area of Maintenance and the LDM Inactive Area.
Details on the usage of the LDM Inactive Area are not specified in this Technical Specification.
— Time of Creation
Time at which the LDM record was created in the LDM Data Storage.
— Time of Deletion
Time after which an LDM record may be deleted and will no more be considered by the LDM search
functionality.
Several location reference systems and time reference systems are known; examples are presented in
Annex D and Annex E. This Technical Specification supports any kind of reference system by defining time
reference and location reference with the ASN.1 type CLASS which allows defining specific instantiations
at a later time according to the needs of C-ITS services. The generic approach for location is given in the
ASN.1 type LDMarea. The generic approach for time is given in the ASN.1 type TimeInformation.
In order to manage time, an LDM needs to maintain or access a time reference system (clock). This
Technical Specification assumes that there is a trusted time service available in an ITS-SU which can be
used in an implementation-specific way. Time synchronization with an external clock to ensure unique
time information in all ITS-SUs will be a task of the ITS-S management.
Similarly, it is assumed that an LDM has access to a service providing continuously the kinematic state
of the ITS-SU in which it resides; thus, no explicit interface to such a service is specified in this Technical
Specification.
As this Technical Specification supports various implementation architectures illustrated in 5.4, ITS-S
application processes need to be enabled to select appropriate LDMs. For this purpose,
a) LDMs are identified by an LDM ID that is unique in an ITS-SU,
b) LDMs register at the ITS-S management entity reporting about their capabilities in terms of
supported LDM-DOs, and
c) ITS-S application processes register at the ITS-S management entity reporting their LDM
requirements in terms of required LDM-DOs, which is acknowledged by providing the address
information of the best-suited LDMs.
The LDM performs the following procedures to maintain integrity of the LDM Data Storage:
— removal of LDM Data Records that are out of date;
— removal of LDM Data Records which are out of the LDM Area of Maintenance.
Further integrity checking is supposed to be performed by ITS-S application processes.
6.2 Structure of an LDM
An LDM is composed of functional blocks presented in Figure 6.
10 © ISO 2015 – All rights reserved

Figure 6 — Structure of an LDM
— LDM Data Storage: This is the entity in an LDM that stores LDM-DOs as described in 6.3.
— LDM Service: This functional block provides means for
— managing registration, deregistration requests, and revocation of ITS-S application processes,
— security checking in access requests, and
— managing access requests (add, update, delete, subscribe, query, notify) from ITS-S
application processes
as described in 6.4.
— LDM Maintenance: This functional block provides means for
— updating the LDM Area of Maintenance, and
— removing LDM Data Records
as described in 6.5.
— LDM Knowledge Base: This provides the knowledge that is required in the LDM for internal
processing as described in 6.6. This functional block includes
— Metadata,
— the LDM Data Dictionary,
— information on ITS-S application processes’ registrations and subscriptions to the LDM, and
— LDM utility functions.
— Interfaces: The interfaces used and offered by an LDM are the following.
— Data interface towards ITS-S application processes for
— add, update, and delete access,
— query access,
— subscription access, and
— notifications upon subscription.
— Management and security interfaces for
— registration, deregistration, and revocation of ITS-S applications,
— validation of access rights claimed by ITS-S applications at time of registration, and
— LDM management (e.g. registration of LDM at the ITS-S management)
as described in 6.6.2.
— LDM Management: This functional block provides means for
— registration of an LDM at the ITS-S management.
6.3 LDM Data Storage
An LDM Data Storage logically contains LDM data records presented in Figure 7.
Figure 7 — Elements of LDM Data Record
An LDM data record is uniquely identified by its LDM record ID. An LDM data record consists of
— LDM-DO Parameters:
— the LDM-DO Type (LDM-DT);
— the Location Validity of the real object;
— the Time Validity of the real object;
— Time of Generation of information contained in the LDM-DO (set to the value zero in case the
time is unknown);
— Time of Mandatory Deletion of an LDM Data Record.
NOTE 1 Updates of an LDM Data Record can only be provided by the same ITS-S application process that
originally generated the LDM Data Record.
NOTE 2 The Location Validity and Time Validity fields basically consist each of two parts, one
containing the values of the original reference system and the other one containing the values of the
reference system used in the LDM.
— the LDM-DO Attributes as specified in the LDM Data Dictionary (LDM-DD).
12 © ISO 2015 – All rights reserved

— LDM Maintenance Parameters which cannot be set explicitly by an ITS-S application process and
which cannot be retrieved by an ITS-S application process:
— identifier of the ITS-S application process that presented this instantiation of an LDM-DO for
storing in the LDM;
— Time of Creation of the LDM Data Record which is different to the time of generation of the
information contained in the attributes of the LDM-DO;
— Time of Deletion of the LDM Data Record from the LDM;
— Privacy flag.
Table 1 explains and specifies the elements of an LDM Data Record in Figure 7; it refers to ASN.1 type
definition specified in Annex A.
Table 1 — LDM Data Record elements
Element Specification and explanation
LDM record ID This element uniquely identifies a specific record in the LDM. The format of this element
is given by the ASN.1 element LDMrecordID specified in Annex A. The value zero points
to the “non-existent” LDM Data Record.
LDM-DO type This element uniquely identifies the type of the LDM-DO. The format of this element is
given by the ASN.1 element LDMdataObjectTypeID specified in Annex A.
Location Validity This element uniquely identifies the position or area at which the information given by
the LDM-DO applies. Several location reference systems are allowed in the interface func-
tions. This field basically consist of two parts, one containing the values of the original
reference system and the other one containing the values of the reference system used
in the LDM. The format of location reference systems is given by the ASN.1 element
LDMarea specified in Annex A.
Time Validity This element uniquely identifies the time period when the information given by the
LDM-DO applies. Several time formats to present a time period are allowed in the inter-
face functions. Thus, this field basically consist of two parts, one containing the values
of the original reference system and the other one containing the values of the reference
system used in the LDM. The format of time reference systems is given by the ASN.1 ele-
ment TimeInformation specified in Annex A.
Time of Generation This element uniquely identifies the time when the data contained in the LDM-DO
was generated. Note that this is different to the time of creation when the LDM Data
Record was stored in the LDM. The format of this element is given by the ASN.1 element
TimeOfGeneration specified in Annex A.
Time of Mandatory This element is used to indicate up to which time the LDM Data Record ma
...