SIST EN 302 895 V1.1.1:2014

Final draft ETSI EN 302 895 V1.1.0 (2014-07)

EUROPEAN STANDARD
Intelligent Transport Systems (ITS);
Vehicular Communications;
Basic Set of Applications;
Local Dynamic Map (LDM)
2 Final draft ETSI EN 302 895 V1.1.0 (2014-07)

Reference
DEN/ITS-0010005
Keywords
application, ITS, management, user
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2014.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 Final draft ETSI EN 302 895 V1.1.0 (2014-07)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 8
4 General description of a LDM . 9
4.1 Functionality provided by the LDM . 9
5 LDM functional specification . 9
5.1 LDM requirements . 9
5.1.1 LDM functional requirements. 9
5.1.2 LDM other requirements . 10
5.2 The LDM within the ITS-S communication architecture . 10
5.3 LDM functional architecture . 11
5.3.1 Function FN.LDM.1 - LDM Service . 11
5.3.2 Function FN.LDM.2 - LDM Maintenance . 12
5.4 Interfaces of the LDM . 12
5.4.1 Interface IF.LDM.1 - management layer . 12
5.4.2 Interface IF.LDM.2 - security layer . 13
5.4.3 Interface IF.LDM.3 - LDM Data Providers . 13
5.4.4 Interface IF.LDM.4 - LDM Data Consumers . 13
6 LDM Interfaces . 14
6.1 Interface IF.LDM.2 to the security layer . 14
6.1.1 Authorization . 14
6.1.1.1 Authorize messages . 14
6.1.2 Revocation . 15
6.1.2.1 RevokeAuthorization messages . 15
6.2 Interface IF.LDM.3 to LDM Data Providers . 16
6.2.1 Registration . 16
6.2.1.1 RegisterDataProvider messages . 16
6.2.2 Deregistration . 17
6.2.2.1 DeregisterDataProvider messages . 17
6.2.2.2 RevokeDataProviderRegistration message . 17
6.2.3 Maintenance of Provider data . 18
6.2.3.1 AddProviderdata messages . 18
6.2.3.2 UpdateProviderdata messages . 19
6.2.3.3 DeleteProviderdata messages . 19
6.3 Interface IF.LDM.4 to LDM Data Consumers . 20
6.3.1 Registration . 20
6.3.1.1 RegisterDataConsumer messages . 20
6.3.2 Deregistration . 21
6.3.2.1 DeregisterDataConsumer messages . 21
6.3.2.2 RevokeDataConsumerRegistration message . 22
6.3.3 Data Request . 22
6.3.3.1 RequestDataobjects messages . 22
6.3.4 Subscription . 23
ETSI
4 Final draft ETSI EN 302 895 V1.1.0 (2014-07)
6.3.4.1 SubscribeDataConsumer messages . 23
6.3.5 Cancel subscription . 25
6.3.5.1 UnsubscribeDataConsumer messages . 25
Annex A (normative): Data request filtering . 26
A.1 Minimal syntax of data request filtering . 26
A.1.1 Filter . 26
A.1.2 Filter Statement . 26
A.1.2.1 Comparison Operator . 27
A.1.2.2 Reference Value . 27
A.1.3 Logical operators for combining Filter Statements . 27
A.2 Ordering Data Request Results . 28
Annex B (normative): ITS LDM Interface messages specified in ASN.1 . 29
Annex C (informative): Bibliography . 35
History . 36

ETSI
5 Final draft ETSI EN 302 895 V1.1.0 (2014-07)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This final draft European Standard (EN) has been produced by ETSI Technical Committee Intelligent Transport
Systems (ITS), and is now submitted for the Vote phase of the ETSI standards EN Approval Procedure.
The present document is a single part deliverable.

Proposed national transposition dates
Date of latest announcement of this EN (doa): 3 months after ETSI publication
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 6 months after doa
Date of withdrawal of any conflicting National Standard (dow): 18 months after doa

Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "may not", "need", "need not", "will",
"will not", "can" and "cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms
for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
In cooperative Intelligent Transport Systems (ITS), the Local Dynamic Map (LDM) is a key facility supporting various
ITS applications by maintaining the information on objects influencing or being part of ITS. The Local Dynamic Map
therefore is relevant to the development of technical standards and specifications in order to ensure deployment and
interoperability of cooperative systems and services described in the EC's ICT Standardization Work Programme [i.7].
The LDM is a facility within the ITS station facilities layer as defined in the ITS communication architecture given in
EN 302 665 [i.1]. Cooperative Awareness Messages (CAMs) as defined in EN 302 637-2 [4] and Decentralized
Environmental Notification Messages (DENMs) as defined in EN 302 637-3 [5] are important sources of data for the
LDM.
Moreover the LDM will support the Basic Set of Applications (BSA) outlined in TS 102 637-1 [i.2] by providing
plausible authorized, area related information in a time relevant manner. The BSA provides the application specific
requirements for the LDM.
ETSI
6 Final draft ETSI EN 302 895 V1.1.0 (2014-07)
The following applications from the BSA are considered:
• Driving assistance - Cooperative awareness.
• Driving assistance - Road Hazard Signalling (see TS 101 539-1 [i.3]).
• Speed management.
• Cooperative navigation Location based services.
• Community services.
• ITS station life cycle management.
ETSI
7 Final draft ETSI EN 302 895 V1.1.0 (2014-07)
1 Scope
The present document defines functional behaviour associated with a Local Dynamic Map (LDM) for usage in an ITS
station unit (ITS-SU). It specifies functions and interfaces supported by a LDM. These functions and interfaces provide
secure access to the LDM to manage LDM data objects stored in a LDM. It defines LDM data objects for safety-related
and Vehicle to Vehicle (V2V)-related applications.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 102 860 (V1.1.1) (2011-05): "Intelligent Transport Systems (ITS); Classification and
management of ITS application objects".
[2] ISO/IEC 8824-1:2008: "Information technology - Abstract Syntax Notation One (ASN.1):
Specification of basic notation".
[3] ETSI TS 102 894-2: "Intelligent Transport Systems (ITS); Users and applications requirements;
Part 2: Applications and facilities layer common data dictionary".
[4] ETSI EN 302 637-2 (V1.3.0) (2013-08): "Intelligent Transport Systems (ITS); Vehicular
Communications; Basic Set of Applications; Part 2: Specification of Cooperative Awareness Basic
Service".
[5] ETSI EN 302 637-3 (V1.2.0) (2013-08): "Intelligent Transport Systems (ITS); Vehicular
Communications; Basic Set of Applications; Part 3: Specifications of Decentralized
Environmental Notification Basic Service".
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI EN 302 665 (V1.1.1) (2010-09): "Intelligent Transport Systems (ITS); Communications
Architecture".
[i.2] ETSI TS 102 637-1 (V1.1.1) (2010-09): "Intelligent Transport Systems (ITS); Vehicular
Communications; Basic Set of Applications; Part 1: Functional Requirements".
[i.3] ETSI TS 101 539-1 (V1.1.1) (2013-08): "Intelligent Transport Systems (ITS); V2X Applications;
Part 1: Road Hazard Signalling (RHS) application requirements specification".
[i.4] ETSI TS 102 723-5 (V1.1.1) (2012-11): "Intelligent Transport Systems (ITS); OSI cross-layer
topics; Part 5: Interface between management entity and facilities layer".
ETSI
8 Final draft ETSI EN 302 895 V1.1.0 (2014-07)
[i.5] ETSI TR 102 863 (V1.1.1) (2011-06): "Intelligent Transport Systems (ITS); Vehicular
Communications; Basic Set of Applications; Local Dynamic Map (LDM); Rationale for and
guidance on standardization".
[i.6] ISO/IEC 19505-2:2012(E): "Information technology - Object Management Group Unified
Modeling Language (OMG UML), Superstructure".
[i.7] European Commission: "2010-2013 ICT Standardisation Work Programme for industrial
innovation", 2nd update - 2012.
NOTE: Available at: http://ec.europa.eu/enterprise/sectors/ict/files/ict-policies/2010-
2013_ict_standardisation_work_programme_2nd_update_en.pdf.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
area of interest: geographical area specified by data consumer limiting the LDM to satisfying the data consumers'
subsequent requests for information only from data originating within that area
LDM area of maintenance: geographical area specified by the LDM for LDM maintenance
LDM data consumer: facility or an application that is authorized to request data from the LDM
LDM data object: object with attributes that can be accessed by the LDM Interfaces
LDM data object identifier: unique identifier within the LDM for a LDM Data Object added by a LDM Data Provider
LDM data provider: facility or an application that is authorized to provide the data to the LDM
Local Dynamic Map (LDM): facilities layer data store for storing LDM Data Objects that are timestamped and
location referenced
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ASN Abstract Syntax Notation
BSA Basic Set of Applications
CA Co-operative Awareness
CAM Co-operative Awareness Message
DEN Decentralized Environmental Notification
DENM Decentralized Environmental Notification Message
FA-SAP Facilities/Applications Service Access Point
ICRW Intersection Collision Risk Warning
ICT Information and Communication Technology
ITS Intelligent Transport System
ITS-AID ITS Application IDentifier
ITS-S Intelligent Transport System Station
ITS-SU Intelligent Transport System Station Unit
LCRW Longitudinal Collision Risk Warning
LDM Local Dynamic Map
MF-SAP Management/Facilities Service Access Point
NF-SAP Networking & Transport/Facilities Service Access Point
RHS Road Hazard Signalling
SF-SAP Security Facilities - Service Access Point
UML Unified Modelling Language
V2V Vehicle to Vehicle
ETSI
9 Final draft ETSI EN 302 895 V1.1.0 (2014-07)
4 General description of a LDM
A Local Dynamic Map (LDM) is a facility in cooperative Intelligent Transport Systems (ITS). It supports ITS
applications by maintaining information on objects influencing or influenced by road traffic. ITS applications require
information on moving objects such as vehicles nearby or on stationary objects such as traffic road signs. Information
required by, or useful to active applications, can be maintained in a LDM.
The LDM is a conceptual data store located within an ITS-S as outlined in EN 302 665 [i.1] containing information
which is relevant to the operation of ITS applications and related road safety and traffic efficiency. Data can be received
from a range of different sources such as vehicles, infrastructure units, traffic centres, personal ITS stations, and on-
board sensors and applications. The LDM offers mechanisms to grant secure access to the data that it holds. For
example, the LDM can provide information on the surrounding vehicles and Road Side Units to any authorized
application that requests it.
The information stored in the LDM can be accessed in the form of objects called LDM Data Objects. LDM Data
Objects are provided from for example basic services for ITS Message Sets such as those defined in EN 302 637-2 [4]
and EN 302 637-3 [5]. LDM Data Objects can be composed of sub objects, similar to the hierarchical structure of data
frames in messages, and the objects contain attributes representing data elements from TS 102 894-2 [3]. Information
on a vehicle or road side ITS-S for example is provided by a cooperative awareness basic service as defined in
EN 302 637-2 [4] and is accessed from the LDM as a LDM Data Object with sub-objects representing the information
from the CAM Basic Container. Information on an event for example is provided by a distributed environmental
notification basic service as defined in EN 302 637-3 [5] and is accessed from the LDM as a LDM Data Object with
sub-objects for the situation, location and a la carte containers.
The LDM can also store LDM Data Objects from applications and other facilities. For example, the LDM may maintain
information on the ITS-S it is part of.
The LDM does not modify the data provided by LDM Data Providers. No permanent, static information is required to
be stored in the LDM.
4.1 Functionality provided by the LDM
The basic functionality of the LDM is to provide a repository of information for facilities and applications. Facilities
such as the CA and DEN basic services can store information into the LDM. Applications can retrieve information from
and store information into the LDM. Additional functionality of the LDM includes:
• Registration/Deregistration of facilities and applications as LDM Data Providers/sinks to the LDM via the
security layer (authorization) (see clause 6.1.1).
• Subscribe/Unsubscribe for notifications (see clause 6.3.4).
• Information retention by applying rules, e.g. based on time and/or location (see clause 5.3.2).
• Prioritization of requests (see clause 6.3.3).
5 LDM functional specification
5.1 LDM requirements
5.1.1 LDM functional requirements
A LDM may communicate with other entities within the ITS-S architecture outlined in EN 302 665 [i.1] in order to:
• receive incoming information such as decoded CAMs in accordance with EN 302 637-2 [4] and DENMs in
accordance with EN 302 637-3 [5];
• store and protect information according to constraints of time and LDM Area of Maintenance;
ETSI
10 Final draft ETSI EN 302 895 V1.1.0 (2014-07)
• provide information to authorized applications as requested:
- by means of a subscription/notification method; or
- by means of queries including spatial queries;
• prioritize data requests;
• store and protect LDM Data Objects so that it can be shared with applications;
• provide a mechanism for facilities and applications to register and deregister as LDM Data Providers;
• provide a mechanism for applications to register and deregister as LDM Data Consumers;
• ensure data access by LDM Data Providers and LDM Data Consumers is authorized.
5.1.2 LDM other requirements
In addition to the functional requirements listed in clause 5.1.1, a LDM may be constrained by a range of other
requirements such as reliability (system maturity, fault tolerance and restorability) and scalability. However, within
communications systems such requirements are normally considered to be related to procurement and, consequently,
are not specified in the present document.
5.2 The LDM within the ITS-S communication architecture
The LDM collects, qualifies (ensures that it is valid and from an authorized source) and stores data received from other
ITS-Ss. The LDM may also collect, qualify and store information from other sources such as traffic information
providers, or from its own sensors and applications.
As shown in Figure 1, the LDM receives data from other ITS-Ss through a common interface which is available to all
message services such as CA and DEN within the ITS-S Facilities layer. Information is exchanged with other services
or applications by invoking functions located at the FA-SAP as outlined in EN 302 665 [i.1]. Security and management
permissions are provided by functions which are located at the SF-SAP and the MF-SAP respectively.

Figure 1: LDM and logical interfaces
ETSI
11 Final draft ETSI EN 302 895 V1.1.0 (2014-07)
5.3 LDM functional architecture
The rationale for and guidance on standardization of the LDM outlined in TR 102 863 [i.5] specify two main
components of the LDM; the LDM Maintenance component and the LDM Service component (see clause 5.3.1).
Figure 2 shows these two components of the LDM and its main interfaces in a Unified Modelling Language (UML)
component diagram in accordance with ISO/IEC 19505-2 [i.6]. The interfaces are separated into those required by the
LDM (IF.LDM.1 and IF.LDM.2) and those exposed to other facilities and applications (IF.LDM.3 and IF.LDM.4).

Figure 2: LDM Functional architecture
The LDM shall provide the functions defined in Table 1 and illustrated in Figure 2.
Table 1: LDM Functions
Function Description
FN.LDM.1 The LDM Service component (see clause 5.3.1) is responsible for providing functionalities to
authorized LDM Data Providers for LDM data manipulation (such as adding new data, modifying
existing data, delete existing data), direct access to data (query data) and a publish/subscribe
mechanism for data access by LDM Data Consumers. It also provides registration and deregistration
functionalities to LDM Data Providers and LDM Data Consumers.
FN.LDM.2 The LDM Maintenance component (see clause 5.3.2) is responsible for storing and maintaining the
data and its integrity as well as for the garbage collection of persistent data held within the LDM.

5.3.1 Function FN.LDM.1 - LDM Service
The LDM is connected to authorized LDM Data Providers and LDM Data Consumers. LDM Data Providers provide
information to the LDM which makes these data available to LDM Data Consumers. The LDM offers three different
types of interfaces:
• a transaction interface for LDM Data Providers, where a transaction describes a sequence of LDM Data Object
exchanges between a LDM Data Provider and the LDM (see clause 6.2.3);
• a query interface for LDM Data Consumers (see clause 6.3.3); and
• a publish/subscribe interface for LDM Data Consumers (see clause 6.3.4).
ETSI
12 Final draft ETSI EN 302 895 V1.1.0 (2014-07)
The LDM shall:
• provide a mechanism for facilities to register and deregister as LDM Data Providers;
• provide a mechanism for applications to register and deregister as LDM Data Providers or LDM Data
Consumers;
• verify the authorization of LDM Data Providers and LDM Data Consumers prior to data access.
5.3.2 Function FN.LDM.2 - LDM Maintenance
The LDM shall maintain all LDM Data Objects received from registered and authorized LDM Data Providers during
their time validity and within the LDM Area of Maintenance of the LDM.
The LDM considers a LDM Data Object to be valid during the time period starting on the timestamp of the LDM Data
Object and for the duration of the time validity period. A LDM Data Provider specifies the timestamp and the time
validity of every LDM Data Object it provides to the LDM:
• The timestamp is specified upon adding or updating the LDM Data Object (see clause 6.2.3).
• The default time validity for all LDM Data Objects is specified upon registration (see clause 6.2.1). The
default time validity is replaced by the time validity specified for a specific LDM Data Object upon adding or
updating the LDM Data Object (see clause 6.2.3).
The LDM considers a LDM Data Object to be valid if the location of the LDM Data Object intersects with the LDM
Area of Maintenance. A LDM Data Provider specifies the location upon adding or updating a LDM Data Object (see
clause 6.2.3). The LDM Area of Maintenance is a geographical area defined by the LDM, which can be defined relative
to the momentary location of the host ITS-S.
5.4 Interfaces of the LDM
The LDM interfaces are identified in Figure 2 and specified in Table 2. Table 2 consists of the following 5 columns:
• Interface ID - providing the identifier of the interface described.
• Interface Type - describing the type of interface, with provided (P): interface is realized by the LDM and
offered to its clients, required (R): interface is needed by the LDM to perform an action but realized by another
component.
• Component connected - name of the component interacting with the LDM.
• Message type - type of message exchanged via the interface.
• Direction - describing the message flow, with IN: message received by the LDM, OUT: message provided by
the LDM.
Table 2: LDM Interfaces
Interface Interface Component connected Message Type Direction
ID Type
IF.LDM.1 R Management layer MF-SAP IN and OUT
IF.LDM.2 R Security layer SF-SAP IN and OUT
IF.LDM.3 P LDM Data Providers CAM, DENM and other IN
IF.LDM.4 P LDM Data Consumers CAM, DENM and other OUT

NOTE: This is a non-exclusive list which may be extended in the future.
5.4.1 Interface IF.LDM.1 - management layer
The interface IF.LDM.1 to the ITS Management layer is described in TS 102 723-5 [i.4].
ETSI
13 Final draft ETSI EN 302 895 V1.1.0 (2014-07)
5.4.2 Interface IF.LDM.2 - security layer
The LDM shall provide an interface IF.LDM.2 for the exchange of information with the ITS Security layer as described
in EN 302 665 [i.1] in order to verify the authorization of an ITS application or facility to access or modify specific
LDM Data Objects within the LDM.
The ITS security layer will exchange information with the LDM across interface IF.LDM.2 in order to revoke the
authorization of a previously authorized ITS LDM Data Provider and LDM Data Consumer.
5.4.3 Interface IF.LDM.3 - LDM Data Providers
The LDM shall provide an interface IF.LDM.3 to enable an application or facility to register as a LDM Data Provider
and, subsequently, to send LDM Data Objects to the LDM.
A LDM Data Provider shall register with the LDM before the LDM accepts LDM Data Objects from the LDM Data
Provider. The LDM shall request the security layer to check if the LDM Data Provider is authorized using the message
sequence specified in clause 6.1.1.1 across interface IF.LDM.2 (clause 5.4.2). The LDM shall confirm the success of the
authorization to the LDM Data Provider.
The LDM shall at least support the exchange of LDM Data Objects, sub-objects and attributes derived from frames,
sub-frames and elements such as defined in the Common Data Dictionary as specified in TS 102 894-2 [3]. Further
details on LDM Data Objects are out of scope of the present document.
While the LDM Data Provider is registered, the LDM shall provide access to LDM Data Objects for which the LDM
Data Provider is authorized.
When the authorization is revoked by the services of the security layer then the LDM shall deny further access to the
LDM Data Objects.
A LDM Data Provider may deregister itself from the LDM after which it shall no longer have access to LDM Data
Objects.
A LDM Data Provider shall provide a timestamp and location for LDM maintenance purposes with each LDM Data
Object sent to the LDM.
The LDM may store LDM Data Objects identified in Table 3 if offered by an authorized LDM Data Provider. The
LDM may update parts of the LDM Data Objects if offered by an authorized LDM Data Provider.
Table 3: LDM data objects
Message type Reference Data Object Description
CAM EN 302 637-2 [4] All data objects and attributes from a CAM
DENM EN 302 637-3 [5] All data objects and attributes from a DENM

NOTE: This is a non-exclusive list which may be extended in the future.
5.4.4 Interface IF.LDM.4 - LDM Data Consumers
The LDM shall provide an interface IF.LDM.4 to enable an ITS application or facility to register as a LDM Data
Consumer and to access data in the LDM.
A LDM Data Consumer shall register with the LDM before the LDM provides access to the LDM Data Objects. The
LDM requests the security layer to check if the LDM Data Consumer is authorized using the message sequence
specified in clause 6.1.1.1 across interface IF.LDM2 (see clause 5.4.2). The LDM checks the Area of Interest against its
LDM Area of Maintenance. The LDM shall confirm the success of the registration to the LDM Data Consumer.
While the LDM Data Consumer is registered, the LDM shall grant access to LDM Data Objects for which the LDM
Data Consumer is authorized.
When the authorization is revoked by the security services then the LDM shall inform the LDM Data Consumer that its
registration is revoked and shall deny further access to the LDM Data Objects.
ETSI
14 Final draft ETSI EN 302 895 V1.1.0 (2014-07)
A LDM Data Consumer may deregister itself from the LDM after which it shall no longer have access to LDM Data
Objects.
The LDM shall support the exchange of data as defined in the Common Data Dictionary as specified in
TS 102 894-2 [3].
The LDM shall provide mechanisms for filtering the LDM Data Objects to be returned upon request from the LDM
Data Consumer. These filtering mechanisms are:
1) A querying mechanism for an immediate single data request.
2) A publish/subscribe mechanism for the continuous return of data which shall support the following:
a) Event driven data request according to the given filter.
b) Periodic data request according to a given time interval and filter.
c) Composite event driven data request according to a given filter or time interval.
The filtering mechanisms contain a filter on one or more attributes of the requested LDM Data Objects. A filter on a
single attribute of a LDM Data Object compares the attribute value against a reference value (see clause A.1.2.2).
Only LDM Data Objects that meet the specified filtering criteria and are within the defined Area of Interest shall be
returned to the LDM Data Consumer by the LDM.
The response to a data request shall be a list of zero or more requested LDM Data Objects. In the case of the
publish/subscribe mechanism a LDM Data Consumer receives a response to the same request every time the
subscription criteria are matched.
The LDM shall support the prioritization of processing data requests.
6 LDM Interfaces
The interfaces to LDM Data Providers, LDM Data Consumers, and to the security and management layers are defined
here as messages in the information flow. These messages can also be considered as the data part of the service
primitives to the AF-SAP, MF-SAP and SF-SAP, and need to be extended with the source and destination addresses.
This clause specifies the minimal functionality of the LDM interfaces.
6.1 Interface IF.LDM.2 to the security layer
6.1.1 Authorization
6.1.1.1 Authorize messages
When the LDM receives a Registration request from a LDM Data Provider or a LDM Data Consumer (see clauses 6.2.1
and 6.3.1) it shall send an Authorize request message to the ITS Security layer across the interface IF.LDM.2 to verify
if the LDM Data Provider or LDM Data Consumer is authorized for access to LDM Data Objects. Figure 3 shows the
message sequence with the authorization request message (Authorize.Req) and the response message
(Authorize.Resp) to confirm the successful or unsuccessful authorization. The Registration Request and Response
messages are defined in clauses 6.2.1.1 and 6.3.1.1 for the LDM Data Provider and Consumers respectively.
ETSI
15 Final draft ETSI EN 302 895 V1.1.0 (2014-07)

Figure 3: LDM Data Provider or Consumer authorization message sequence
The content of the Authorize request and response messages in this information flow are specified at a functional level
as in Table 4. The request and response messages are specified at a syntactical level in annex B.
Table 4: Contents of Authorize Information Flow
Parameter Content Request Response
ITS Application Identifier ITS-AID as defined in TS 102 860 [1] Mandatory Mandatory
Permissions for which access Permissions are defined as one or more root LDM Mandatory Optional
is requested/granted Data Object types (or classes) that can be accessed (see note)
from the LDM. Typical permissions are the root classes
of LDM Data Objects decoded from ITS message sets
from Table 3 and TS 102 894-2 [3]
Result Indication of result of the request: Mandatory
• Successful
• Fail: Invalid ITS-AID
• Fail: Unable to authenticate application
• Fail: Application not authorized for requested
permissions
NOTE: Mandatory if the Result parameter is set to "Successful" and the list of permissions, for which
authorization is granted, is different from that requested.

6.1.2 Revocation
6.1.2.1 RevokeAuthorization messages
The RevokeAuthorization message shall be sent by the ITS Security Layer to the LDM across the interface IF.LDM.2
to inform the LDM that authorization to permit a particular LDM Data Provider or LDM Data Consumer to have access
to information in the LDM has been revoked. Figure 4 shows the message sequence with the revocation request
message (RevokeAuthorization.Req) and the response message (RevokeAuthorization.Resp) to
confirm the successful or unsuccessful revocation. The Revoke Registration message is defined in clauses 6.2.2.2 and
6.3.2.2 for the LDM Data Provider and Consumers respectively.
ETSI
16 Final draft ETSI EN 302 895 V1.1.0 (2014-07)

Figure 4: Authorization revocation message sequence
The content of the RevokeAuthorization request and response messages are specified at a functional level as in Table 5.
The request and response messages are specified at a syntactical level in annex B.
Table 5: Contents of RevokeAuthorization Information Flows
Parameter Content Request Response
ITS Application Identifier ITS-AID as defined in TS 102 860 [1] Mandatory Mandatory
Reason Indication of the reason why authorization is revoked Mandatory
for the application:
• Registration of the application or service has
been revoked by the Registration Authority
• Period of authorization has expired
Revocation Indication that the revocation has been received and Mandatory
acknowledgement processed
6.2 Interface IF.LDM.3 to LDM Data Providers
6.2.1 Registration
6.2.1.1 RegisterDataProvider messages
A LDM Data Provider shall send a RegisterDataProvider request message to the LDM across the interface IF.LDM.3 to
register for access to LDM Data Objects. Figure 5 shows the message sequence with the registration request message
(RegisterDataProvider.Req) and the response message (RegisterDataProvider.Resp) to confirm the
successful or unsuccessful registration. The LDM uses the Authorization message across interface IF.LDM.2 to request
the verification of the authorization from the security layer (see clause 6.1.1.1).
NOTE: If a LDM Data Provider is already registered with the LDM it is deregistered without notification before
the new registration request is processed.

Figure 5: LDM Data Provider registration message sequence
ETSI
17 Final draft ETSI EN 302 895 V1.1.0 (2014-07)
The content of the RegistrationDataProvider request and response messages are specified at a functional level as in
Table 6. The request and response messages are specified at a syntactical level in annex B.
Table 6: Contents of RegisterDataProvider Information Flow
Parameter Content Request Response
IT'S Application Identifier ITS-AID as defined in TS 102 860 [1] Mandatory Mandatory
Permissions for which access Permissions are defined as one or more root LDM
Mandatory Optional
is requested/granted Data Object types (or classes) that can be provided (see note)
as the root classes of LDM Data Objects decoded
from ITS message sets from Table 3 and
TS 102 894-2 [3]
Time validity Default time validity of provided data Mandatory
Result Indication of result of the registration request: Mandatory
• Accepted
• Rejected
NOTE: Mandatory if the Result parameter is set to the value "Accepted" and the list of permissions for which
authorization is granted is different from that requested.

6.2.2 Deregistration
6.2.2.1 DeregisterDataProvider messages
A LDM Data Provider shall send a DeregisterDataProvider request message to the LDM to deregister itself as a LDM
Data Provider from the LDM. Figure 6 shows the message sequence for deregistration with the request message
(DeregisterDataProvider.Req) and the response message (DeregisterDataProvider.Req) to confirm
the deregistration.
Figure 6: LDM Data Provider deregistration message sequence
The content of the DeregisterDataProvider request and response messages flow are specified at a functional level as in
Table 7. The request and response messages are specified at a syntactical level in annex B.
Table 7: Contents of DeregisterDataProvider Information flows
Parameter Content Request Response
ITS Application Identifier ITS-AID as defined in TS 102 860 [1] Mandatory Mandatory
Deregistration Indication that the deregistration message has been Mandatory
acknowledgement received and processed.

6.2.2.2 RevokeDataProviderRegistration message
When the authorization of a LDM Data Provider is revoked by the security layer (see clause 6.1.2.1) then the LDM
shall send a RevokeDataProviderRegistration response message to the LDM Data Provider to inform that its registration
is terminated and further access to the LDM Data Objects will be denied. Figure 7 shows the message sequence with the
response message (RevokeDataProviderRegistration.Resp) to inform the LDM Data Provider that its
registration has been revok
...

EUROPEAN STANDARD
Intelligent Transport Systems (ITS);
Vehicular Communications;
Basic Set of Applications;
Local Dynamic Map (LDM)
2 ETSI EN 302 895 V1.1.1 (2014-09)

Reference
DEN/ITS-0010005
Keywords
application, ITS, management, user
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2014.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI EN 302 895 V1.1.1 (2014-09)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 8
4 General description of a LDM . 9
4.1 Functionality provided by the LDM . 9
5 LDM functional specification . 9
5.1 LDM requirements . 9
5.1.1 LDM functional requirements. 9
5.1.2 LDM other requirements . 10
5.2 The LDM within the ITS-S communication architecture . 10
5.3 LDM functional architecture . 11
5.3.1 Function FN.LDM.1 - LDM Service . 11
5.3.2 Function FN.LDM.2 - LDM Maintenance . 12
5.4 Interfaces of the LDM . 12
5.4.1 Interface IF.LDM.1 - management layer . 12
5.4.2 Interface IF.LDM.2 - security layer . 13
5.4.3 Interface IF.LDM.3 - LDM Data Providers . 13
5.4.4 Interface IF.LDM.4 - LDM Data Consumers . 13
6 LDM Interfaces . 14
6.1 Interface IF.LDM.2 to the security layer . 14
6.1.1 Authorization . 14
6.1.1.1 Authorize messages . 14
6.1.2 Revocation . 15
6.1.2.1 RevokeAuthorization messages . 15
6.2 Interface IF.LDM.3 to LDM Data Providers . 16
6.2.1 Registration . 16
6.2.1.1 RegisterDataProvider messages . 16
6.2.2 Deregistration . 17
6.2.2.1 DeregisterDataProvider messages . 17
6.2.2.2 RevokeDataProviderRegistration message . 17
6.2.3 Maintenance of Provider data . 18
6.2.3.1 AddProviderdata messages . 18
6.2.3.2 UpdateProviderdata messages . 19
6.2.3.3 DeleteProviderdata messages . 19
6.3 Interface IF.LDM.4 to LDM Data Consumers . 20
6.3.1 Registration . 20
6.3.1.1 RegisterDataConsumer messages . 20
6.3.2 Deregistration . 21
6.3.2.1 DeregisterDataConsumer messages . 21
6.3.2.2 RevokeDataConsumerRegistration message . 22
6.3.3 Data Request . 22
6.3.3.1 RequestDataobjects messages . 22
6.3.4 Subscription . 23
ETSI
4 ETSI EN 302 895 V1.1.1 (2014-09)
6.3.4.1 SubscribeDataConsumer messages . 23
6.3.5 Cancel subscription . 25
6.3.5.1 UnsubscribeDataConsumer messages . 25
Annex A (normative): Data request filtering . 26
A.1 Minimal syntax of data request filtering . 26
A.1.1 Filter . 26
A.1.2 Filter Statement . 26
A.1.2.1 Comparison Operator . 27
A.1.2.2 Reference Value . 27
A.1.3 Logical operators for combining Filter Statements . 27
A.2 Ordering Data Request Results . 28
Annex B (normative): ITS LDM Interface messages specified in ASN.1 . 29
Annex C (informative): Bibliography . 35
History . 36

ETSI
5 ETSI EN 302 895 V1.1.1 (2014-09)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This European Standard (EN) has been produced by ETSI Technical Committee Intelligent Transport Systems (ITS).
The present document is a single part deliverable.

National transposition dates
Date of adoption of this EN: 22 September 2014
Date of latest announcement of this EN (doa): 31 December 2014
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 30 June 2015
Date of withdrawal of any conflicting National Standard (dow): 30 June 2016

Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "may not", "need", "need not", "will",
"will not", "can" and "cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms
for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
In cooperative Intelligent Transport Systems (ITS), the Local Dynamic Map (LDM) is a key facility supporting various
ITS applications by maintaining the information on objects influencing or being part of ITS. The Local Dynamic Map
therefore is relevant to the development of technical standards and specifications in order to ensure deployment and
interoperability of cooperative systems and services described in the EC's ICT Standardization Work Programme [i.7].
The LDM is a facility within the ITS station facilities layer as defined in the ITS communication architecture given in
EN 302 665 [i.1]. Cooperative Awareness Messages (CAMs) as defined in EN 302 637-2 [4] and Decentralized
Environmental Notification Messages (DENMs) as defined in EN 302 637-3 [5] are important sources of data for the
LDM.
Moreover the LDM will support the Basic Set of Applications (BSA) outlined in TS 102 637-1 [i.2] by providing
plausible authorized, area related information in a time relevant manner. The BSA provides the application specific
requirements for the LDM.
ETSI
6 ETSI EN 302 895 V1.1.1 (2014-09)
The following applications from the BSA are considered:
• Driving assistance - Cooperative awareness.
• Driving assistance - Road Hazard Signalling (see TS 101 539-1 [i.3]).
• Speed management.
• Cooperative navigation Location based services.
• Community services.
• ITS station life cycle management.
ETSI
7 ETSI EN 302 895 V1.1.1 (2014-09)
1 Scope
The present document defines functional behaviour associated with a Local Dynamic Map (LDM) for usage in an ITS
station unit (ITS-SU). It specifies functions and interfaces supported by a LDM. These functions and interfaces provide
secure access to the LDM to manage LDM data objects stored in a LDM. It defines LDM data objects for safety-related
and Vehicle to Vehicle (V2V)-related applications.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 102 860 (V1.1.1) (2011-05): "Intelligent Transport Systems (ITS); Classification and
management of ITS application objects".
[2] ISO/IEC 8824-1:2008: "Information technology - Abstract Syntax Notation One (ASN.1):
Specification of basic notation".
[3] ETSI TS 102 894-2: "Intelligent Transport Systems (ITS); Users and applications requirements;
Part 2: Applications and facilities layer common data dictionary".
[4] ETSI EN 302 637-2 (V1.3.1) (2014-09): "Intelligent Transport Systems (ITS); Vehicular
Communications; Basic Set of Applications; Part 2: Specification of Cooperative Awareness Basic
Service".
[5] ETSI EN 302 637-3 (V1.2.1) (2014-09): "Intelligent Transport Systems (ITS); Vehicular
Communications; Basic Set of Applications; Part 3: Specifications of Decentralized
Environmental Notification Basic Service".
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI EN 302 665 (V1.1.1) (2010-09): "Intelligent Transport Systems (ITS); Communications
Architecture".
[i.2] ETSI TS 102 637-1 (V1.1.1) (2010-09): "Intelligent Transport Systems (ITS); Vehicular
Communications; Basic Set of Applications; Part 1: Functional Requirements".
[i.3] ETSI TS 101 539-1 (V1.1.1) (2013-08): "Intelligent Transport Systems (ITS); V2X Applications;
Part 1: Road Hazard Signalling (RHS) application requirements specification".
[i.4] ETSI TS 102 723-5 (V1.1.1) (2012-11): "Intelligent Transport Systems (ITS); OSI cross-layer
topics; Part 5: Interface between management entity and facilities layer".
ETSI
8 ETSI EN 302 895 V1.1.1 (2014-09)
[i.5] ETSI TR 102 863 (V1.1.1) (2011-06): "Intelligent Transport Systems (ITS); Vehicular
Communications; Basic Set of Applications; Local Dynamic Map (LDM); Rationale for and
guidance on standardization".
[i.6] ISO/IEC 19505-2:2012(E): "Information technology - Object Management Group Unified
Modeling Language (OMG UML), Superstructure".
[i.7] European Commission: "2010-2013 ICT Standardisation Work Programme for industrial
innovation", 2nd update - 2012.
NOTE: Available at: http://ec.europa.eu/enterprise/sectors/ict/files/ict-policies/2010-
2013_ict_standardisation_work_programme_2nd_update_en.pdf.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
area of interest: geographical area specified by data consumer limiting the LDM to satisfying the data consumers'
subsequent requests for information only from data originating within that area
LDM area of maintenance: geographical area specified by the LDM for LDM maintenance
LDM data consumer: facility or an application that is authorized to request data from the LDM
LDM data object: object with attributes that can be accessed by the LDM Interfaces
LDM data object identifier: unique identifier within the LDM for a LDM Data Object added by a LDM Data Provider
LDM data provider: facility or an application that is authorized to provide the data to the LDM
Local Dynamic Map (LDM): facilities layer data store for storing LDM Data Objects that are timestamped and
location referenced
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ASN Abstract Syntax Notation
BSA Basic Set of Applications
CA Co-operative Awareness
CAM Co-operative Awareness Message
DEN Decentralized Environmental Notification
DENM Decentralized Environmental Notification Message
FA-SAP Facilities/Applications Service Access Point
ICRW Intersection Collision Risk Warning
ICT Information and Communication Technology
ITS Intelligent Transport System
ITS-AID ITS Application IDentifier
ITS-S Intelligent Transport System Station
ITS-SU Intelligent Transport System Station Unit
LCRW Longitudinal Collision Risk Warning
LDM Local Dynamic Map
MF-SAP Management/Facilities Service Access Point
NF-SAP Networking & Transport/Facilities Service Access Point
RHS Road Hazard Signalling
SF-SAP Security Facilities - Service Access Point
UML Unified Modelling Language
V2V Vehicle to Vehicle
ETSI
9 ETSI EN 302 895 V1.1.1 (2014-09)
4 General description of a LDM
A Local Dynamic Map (LDM) is a facility in cooperative Intelligent Transport Systems (ITS). It supports ITS
applications by maintaining information on objects influencing or influenced by road traffic. ITS applications require
information on moving objects such as vehicles nearby or on stationary objects such as traffic road signs. Information
required by, or useful to active applications, can be maintained in a LDM.
The LDM is a conceptual data store located within an ITS-S as outlined in EN 302 665 [i.1] containing information
which is relevant to the operation of ITS applications and related road safety and traffic efficiency. Data can be received
from a range of different sources such as vehicles, infrastructure units, traffic centres, personal ITS stations, and
on-board sensors and applications. The LDM offers mechanisms to grant secure access to the data that it holds. For
example, the LDM can provide information on the surrounding vehicles and Road Side Units to any authorized
application that requests it.
The information stored in the LDM can be accessed in the form of objects called LDM Data Objects. LDM Data
Objects are provided from for example basic services for ITS Message Sets such as those defined in EN 302 637-2 [4]
and EN 302 637-3 [5]. LDM Data Objects can be composed of sub objects, similar to the hierarchical structure of data
frames in messages, and the objects contain attributes representing data elements from TS 102 894-2 [3]. Information
on a vehicle or road side ITS-S for example is provided by a cooperative awareness basic service as defined in
EN 302 637-2 [4] and is accessed from the LDM as a LDM Data Object with sub-objects representing the information
from the CAM Basic Container. Information on an event for example is provided by a distributed environmental
notification basic service as defined in EN 302 637-3 [5] and is accessed from the LDM as a LDM Data Object with
sub-objects for the situation, location and a la carte containers.
The LDM can also store LDM Data Objects from applications and other facilities. For example, the LDM may maintain
information on the ITS-S it is part of.
The LDM does not modify the data provided by LDM Data Providers. No permanent, static information is required to
be stored in the LDM.
4.1 Functionality provided by the LDM
The basic functionality of the LDM is to provide a repository of information for facilities and applications. Facilities
such as the CA and DEN basic services can store information into the LDM. Applications can retrieve information from
and store information into the LDM. Additional functionality of the LDM includes:
• Registration/Deregistration of facilities and applications as LDM Data Providers/sinks to the LDM via the
security layer (authorization) (see clause 6.1.1).
• Subscribe/Unsubscribe for notifications (see clause 6.3.4).
• Information retention by applying rules, e.g. based on time and/or location (see clause 5.3.2).
• Prioritization of requests (see clause 6.3.3).
5 LDM functional specification
5.1 LDM requirements
5.1.1 LDM functional requirements
A LDM may communicate with other entities within the ITS-S architecture outlined in EN 302 665 [i.1] in order to:
• receive incoming information such as decoded CAMs in accordance with EN 302 637-2 [4] and DENMs in
accordance with EN 302 637-3 [5];
• store and protect information according to constraints of time and LDM Area of Maintenance;
ETSI
10 ETSI EN 302 895 V1.1.1 (2014-09)
• provide information to authorized applications as requested:
- by means of a subscription/notification method; or
- by means of queries including spatial queries;
• prioritize data requests;
• store and protect LDM Data Objects so that it can be shared with applications;
• provide a mechanism for facilities and applications to register and deregister as LDM Data Providers;
• provide a mechanism for applications to register and deregister as LDM Data Consumers;
• ensure data access by LDM Data Providers and LDM Data Consumers is authorized.
5.1.2 LDM other requirements
In addition to the functional requirements listed in clause 5.1.1, a LDM may be constrained by a range of other
requirements such as reliability (system maturity, fault tolerance and restorability) and scalability. However, within
communications systems such requirements are normally considered to be related to procurement and, consequently,
are not specified in the present document.
5.2 The LDM within the ITS-S communication architecture
The LDM collects, qualifies (ensures that it is valid and from an authorized source) and stores data received from other
ITS-Ss. The LDM may also collect, qualify and store information from other sources such as traffic information
providers, or from its own sensors and applications.
As shown in Figure 1, the LDM receives data from other ITS-Ss through a common interface which is available to all
message services such as CA and DEN within the ITS-S Facilities layer. Information is exchanged with other services
or applications by invoking functions located at the FA-SAP as outlined in EN 302 665 [i.1]. Security and management
permissions are provided by functions which are located at the SF-SAP and the MF-SAP respectively.

Figure 1: LDM and logical interfaces
ETSI
11 ETSI EN 302 895 V1.1.1 (2014-09)
5.3 LDM functional architecture
The rationale for and guidance on standardization of the LDM outlined in TR 102 863 [i.5] specify two main
components of the LDM; the LDM Maintenance component and the LDM Service component (see clause 5.3.1).
Figure 2 shows these two components of the LDM and its main interfaces in a Unified Modelling Language (UML)
component diagram in accordance with ISO/IEC 19505-2 [i.6]. The interfaces are separated into those required by the
LDM (IF.LDM.1 and IF.LDM.2) and those exposed to other facilities and applications (IF.LDM.3 and IF.LDM.4).

Figure 2: LDM Functional architecture
The LDM shall provide the functions defined in Table 1 and illustrated in Figure 2.
Table 1: LDM Functions
Function Description
FN.LDM.1 The LDM Service component (see clause 5.3.1) is responsible for providing functionalities to
authorized LDM Data Providers for LDM data manipulation (such as adding new data, modifying
existing data, delete existing data), direct access to data (query data) and a publish/subscribe
mechanism for data access by LDM Data Consumers. It also provides registration and deregistration
functionalities to LDM Data Providers and LDM Data Consumers.
FN.LDM.2 The LDM Maintenance component (see clause 5.3.2) is responsible for storing and maintaining the
data and its integrity as well as for the garbage collection of persistent data held within the LDM.

5.3.1 Function FN.LDM.1 - LDM Service
The LDM is connected to authorized LDM Data Providers and LDM Data Consumers. LDM Data Providers provide
information to the LDM which makes these data available to LDM Data Consumers. The LDM offers three different
types of interfaces:
• a transaction interface for LDM Data Providers, where a transaction describes a sequence of LDM Data Object
exchanges between a LDM Data Provider and the LDM (see clause 6.2.3);
• a query interface for LDM Data Consumers (see clause 6.3.3); and
• a publish/subscribe interface for LDM Data Consumers (see clause 6.3.4).
ETSI
12 ETSI EN 302 895 V1.1.1 (2014-09)
The LDM shall:
• provide a mechanism for facilities to register and deregister as LDM Data Providers;
• provide a mechanism for applications to register and deregister as LDM Data Providers or LDM Data
Consumers;
• verify the authorization of LDM Data Providers and LDM Data Consumers prior to data access.
5.3.2 Function FN.LDM.2 - LDM Maintenance
The LDM shall maintain all LDM Data Objects received from registered and authorized LDM Data Providers during
their time validity and within the LDM Area of Maintenance of the LDM.
The LDM considers a LDM Data Object to be valid during the time period starting on the timestamp of the LDM Data
Object and for the duration of the time validity period. A LDM Data Provider specifies the timestamp and the time
validity of every LDM Data Object it provides to the LDM:
• The timestamp is specified upon adding or updating the LDM Data Object (see clause 6.2.3).
• The default time validity for all LDM Data Objects is specified upon registration (see clause 6.2.1). The
default time validity is replaced by the time validity specified for a specific LDM Data Object upon adding or
updating the LDM Data Object (see clause 6.2.3).
The LDM considers a LDM Data Object to be valid if the location of the LDM Data Object intersects with the LDM
Area of Maintenance. A LDM Data Provider specifies the location upon adding or updating a LDM Data Object (see
clause 6.2.3). The LDM Area of Maintenance is a geographical area defined by the LDM, which can be defined relative
to the momentary location of the host ITS-S.
5.4 Interfaces of the LDM
The LDM interfaces are identified in Figure 2 and specified in Table 2. Table 2 consists of the following 5 columns:
• Interface ID - providing the identifier of the interface described.
• Interface Type - describing the type of interface, with provided (P): interface is realized by the LDM and
offered to its clients, required (R): interface is needed by the LDM to perform an action but realized by another
component.
• Component connected - name of the component interacting with the LDM.
• Message type - type of message exchanged via the interface.
• Direction - describing the message flow, with IN: message received by the LDM, OUT: message provided by
the LDM.
Table 2: LDM Interfaces
Interface Interface Component connected Message Type Direction
ID Type
IF.LDM.1 R Management layer MF-SAP IN and OUT
IF.LDM.2 R Security layer SF-SAP IN and OUT
IF.LDM.3 P LDM Data Providers CAM, DENM and other IN
IF.LDM.4 P LDM Data Consumers CAM, DENM and other OUT

NOTE: This is a non-exclusive list which may be extended in the future.
5.4.1 Interface IF.LDM.1 - management layer
The interface IF.LDM.1 to the ITS Management layer is described in TS 102 723-5 [i.4].
ETSI
13 ETSI EN 302 895 V1.1.1 (2014-09)
5.4.2 Interface IF.LDM.2 - security layer
The LDM shall provide an interface IF.LDM.2 for the exchange of information with the ITS Security layer as described
in EN 302 665 [i.1] in order to verify the authorization of an ITS application or facility to access or modify specific
LDM Data Objects within the LDM.
The ITS security layer will exchange information with the LDM across interface IF.LDM.2 in order to revoke the
authorization of a previously authorized ITS LDM Data Provider and LDM Data Consumer.
5.4.3 Interface IF.LDM.3 - LDM Data Providers
The LDM shall provide an interface IF.LDM.3 to enable an application or facility to register as a LDM Data Provider
and, subsequently, to send LDM Data Objects to the LDM.
A LDM Data Provider shall register with the LDM before the LDM accepts LDM Data Objects from the LDM Data
Provider. The LDM shall request the security layer to check if the LDM Data Provider is authorized using the message
sequence specified in clause 6.1.1.1 across interface IF.LDM.2 (clause 5.4.2). The LDM shall confirm the success of the
authorization to the LDM Data Provider.
The LDM shall at least support the exchange of LDM Data Objects, sub-objects and attributes derived from frames,
sub-frames and elements such as defined in the Common Data Dictionary as specified in TS 102 894-2 [3]. Further
details on LDM Data Objects are out of scope of the present document.
While the LDM Data Provider is registered, the LDM shall provide access to LDM Data Objects for which the LDM
Data Provider is authorized.
When the authorization is revoked by the services of the security layer then the LDM shall deny further access to the
LDM Data Objects.
A LDM Data Provider may deregister itself from the LDM after which it shall no longer have access to LDM Data
Objects.
A LDM Data Provider shall provide a timestamp and location for LDM maintenance purposes with each LDM Data
Object sent to the LDM.
The LDM may store LDM Data Objects identified in Table 3 if offered by an authorized LDM Data Provider. The
LDM may update parts of the LDM Data Objects if offered by an authorized LDM Data Provider.
Table 3: LDM data objects
Message type Reference Data Object Description
CAM EN 302 637-2 [4] All data objects and attributes from a CAM
DENM EN 302 637-3 [5] All data objects and attributes from a DENM

NOTE: This is a non-exclusive list which may be extended in the future.
5.4.4 Interface IF.LDM.4 - LDM Data Consumers
The LDM shall provide an interface IF.LDM.4 to enable an ITS application or facility to register as a LDM Data
Consumer and to access data in the LDM.
A LDM Data Consumer shall register with the LDM before the LDM provides access to the LDM Data Objects. The
LDM requests the security layer to check if the LDM Data Consumer is authorized using the message sequence
specified in clause 6.1.1.1 across interface IF.LDM2 (see clause 5.4.2). The LDM checks the Area of Interest against its
LDM Area of Maintenance. The LDM shall confirm the success of the registration to the LDM Data Consumer.
While the LDM Data Consumer is registered, the LDM shall grant access to LDM Data Objects for which the LDM
Data Consumer is authorized.
When the authorization is revoked by the security services then the LDM shall inform the LDM Data Consumer that its
registration is revoked and shall deny further access to the LDM Data Objects.
ETSI
14 ETSI EN 302 895 V1.1.1 (2014-09)
A LDM Data Consumer may deregister itself from the LDM after which it shall no longer have access to LDM Data
Objects.
The LDM shall support the exchange of data as defined in the Common Data Dictionary as specified in
TS 102 894-2 [3].
The LDM shall provide mechanisms for filtering the LDM Data Objects to be returned upon request from the LDM
Data Consumer. These filtering mechanisms are:
1) A querying mechanism for an immediate single data request.
2) A publish/subscribe mechanism for the continuous return of data which shall support the following:
a) Event driven data request according to the given filter.
b) Periodic data request according to a given time interval and filter.
c) Composite event driven data request according to a given filter or time interval.
The filtering mechanisms contain a filter on one or more attributes of the requested LDM Data Objects. A filter on a
single attribute of a LDM Data Object compares the attribute value against a reference value (see clause A.1.2.2).
Only LDM Data Objects that meet the specified filtering criteria and are within the defined Area of Interest shall be
returned to the LDM Data Consumer by the LDM.
The response to a data request shall be a list of zero or more requested LDM Data Objects. In the case of the
publish/subscribe mechanism a LDM Data Consumer receives a response to the same request every time the
subscription criteria are matched.
The LDM shall support the prioritization of processing data requests.
6 LDM Interfaces
The interfaces to LDM Data Providers, LDM Data Consumers, and to the security and management layers are defined
here as messages in the information flow. These messages can also be considered as the data part of the service
primitives to the AF-SAP, MF-SAP and SF-SAP, and need to be extended with the source and destination addresses.
This clause specifies the minimal functionality of the LDM interfaces.
6.1 Interface IF.LDM.2 to the security layer
6.1.1 Authorization
6.1.1.1 Authorize messages
When the LDM receives a Registration request from a LDM Data Provider or a LDM Data Consumer (see clauses 6.2.1
and 6.3.1) it shall send an Authorize request message to the ITS Security layer across the interface IF.LDM.2 to verify
if the LDM Data Provider or LDM Data Consumer is authorized for access to LDM Data Objects. Figure 3 shows the
message sequence with the authorization request message (Authorize.Req) and the response message
(Authorize.Resp) to confirm the successful or unsuccessful authorization. The Registration Request and Response
messages are defined in clauses 6.2.1.1 and 6.3.1.1 for the LDM Data Provider and Consumers respectively.
ETSI
15 ETSI EN 302 895 V1.1.1 (2014-09)

Figure 3: LDM Data Provider or Consumer authorization message sequence
The content of the Authorize request and response messages in this information flow are specified at a functional level
as in Table 4. The request and response messages are specified at a syntactical level in annex B.
Table 4: Contents of Authorize Information Flow
Parameter Content Request Response
ITS Application Identifier ITS-AID as defined in TS 102 860 [1] Mandatory Mandatory
Permissions for which access Permissions are defined as one or more root LDM Mandatory Optional
is requested/granted Data Object types (or classes) that can be accessed (see note)
from the LDM. Typical permissions are the root classes
of LDM Data Objects decoded from ITS message sets
from Table 3 and TS 102 894-2 [3]
Result Indication of result of the request: Mandatory
• Successful
• Fail: Invalid ITS-AID
• Fail: Unable to authenticate application
• Fail: Application not authorized for requested
permissions
NOTE: Mandatory if the Result parameter is set to "Successful" and the list of permissions, for which
authorization is granted, is different from that requested.

6.1.2 Revocation
6.1.2.1 RevokeAuthorization messages
The RevokeAuthorization message shall be sent by the ITS Security Layer to the LDM across the interface IF.LDM.2
to inform the LDM that authorization to permit a particular LDM Data Provider or LDM Data Consumer to have access
to information in the LDM has been revoked. Figure 4 shows the message sequence with the revocation request
message (RevokeAuthorization.Req) and the response message (RevokeAuthorization.Resp) to
confirm the successful or unsuccessful revocation. The Revoke Registration message is defined in clauses 6.2.2.2 and
6.3.2.2 for the LDM Data Provider and Consumers respectively.
ETSI
16 ETSI EN 302 895 V1.1.1 (2014-09)

Figure 4: Authorization revocation message sequence
The content of the RevokeAuthorization request and response messages are specified at a functional level as in Table 5.
The request and response messages are specified at a syntactical level in annex B.
Table 5: Contents of RevokeAuthorization Information Flows
Parameter Content Request Response
ITS Application Identifier ITS-AID as defined in TS 102 860 [1] Mandatory Mandatory
Reason Indication of the reason why authorization is revoked Mandatory
for the application:
• Registration of the application or service has
been revoked by the Registration Authority
• Period of authorization has expired
Revocation Indication that the revocation has been received and Mandatory
acknowledgement processed
6.2 Interface IF.LDM.3 to LDM Data Providers
6.2.1 Registration
6.2.1.1 RegisterDataProvider messages
A LDM Data Provider shall send a RegisterDataProvider request message to the LDM across the interface IF.LDM.3 to
register for access to LDM Data Objects. Figure 5 shows the message sequence with the registration request message
(RegisterDataProvider.Req) and the response message (RegisterDataProvider.Resp) to confirm the
successful or unsuccessful registration. The LDM uses the Authorization message across interface IF.LDM.2 to request
the verification of the authorization from the security layer (see clause 6.1.1.1).
NOTE: If a LDM Data Provider is already registered with the LDM it is deregistered without notification before
the new registration request is processed.

Figure 5: LDM Data Provider registration message sequence
ETSI
17 ETSI EN 302 895 V1.1.1 (2014-09)
The content of the RegistrationDataProvider request and response messages are specified at a functional level as in
Table 6. The request and response messages are specified at a syntactical level in annex B.
Table 6: Contents of RegisterDataProvider Information Flow
Parameter Content Request Response
IT'S Application Identifier ITS-AID as defined in TS 102 860 [1] Mandatory Mandatory
Permissions for which access Permissions are defined as one or more root LDM
Mandatory Optional
is requested/granted Data Object types (or classes) that can be provided (see note)
as the root classes of LDM Data Objects decoded
from ITS message sets from Table 3 and
TS 102 894-2 [3]
Time validity Default time validity of provided data Mandatory
Result Indication of result of the registration request: Mandatory
• Accepted
• Rejected
NOTE: Mandatory if the Result parameter is set to the value "Accepted" and the list of permissions for which
authorization is granted is different from that requested.

6.2.2 Deregistration
6.2.2.1 DeregisterDataProvider messages
A LDM Data Provider shall send a DeregisterDataProvider request message to the LDM to deregister itself as a LDM
Data Provider from the LDM. Figure 6 shows the message sequence for deregistration with the request message
(DeregisterDataProvider.Req) and the response message (DeregisterDataProvider.Req) to confirm
the deregistration.
Figure 6: LDM Data Provider deregistration message sequence
The content of the DeregisterDataProvider request and response messages flow are specified at a functional level as in
Table 7. The request and response messages are specified at a syntactical level in annex B.
Table 7: Contents of DeregisterDataProvider Information flows
Parameter Content Request Response
ITS Application Identifier ITS-AID as defined in TS 102 860 [1] Mandatory Mandatory
Deregistration Indication that the deregistration message has been Mandatory
acknowledgement received and processed.

6.2.2.2 RevokeDataProviderRegistration message
When the authorization of a LDM Data Provider is revoked by the security layer (see clause 6.1.2.1) then the LDM
shall send a RevokeDataProviderRegistration response message to the LDM Data Provider to inform that its registration
is terminated and further access to the LDM Data Objects will be denied. Figure 7 shows the message sequence with the
response message (RevokeDataProviderRegistration.Resp) to inform the LDM Data Provider that its
registration has been revoked.
ETSI
18 ETSI EN 302 895 V1.1.1 (2014-09)

Figure 7: LDM Data Provider revocation message sequence
The content of the RevokeDataProviderRegistration response message are specified at a functional level as in T
...

SLOVENSKI STANDARD
01-november-2014
,QWHOLJHQWQLWUDQVSRUWQLVLVWHPL.RPXQLNDFLMDPHGYR]LOL2VQRYQLQDERUDSOLNDFLM
.UDMHYQDGLQDPLþQDNDUWD
Intelligent Transport Systems (ITS) - Vehicular Communications - Basic Set of
Applications - Local Dynamic Map (LDM)
Ta slovenski standard je istoveten z: EN 302 895 Version 1.1.1
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
43.040.15 $YWRPRELOVNDLQIRUPDWLND Car informatics. On board
9JUDMHQLUDþXQDOQLãNLVLVWHPL computer systems
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
Intelligent Transport Systems (ITS);
Vehicular Communications;
Basic Set of Applications;
Local Dynamic Map (LDM)
2 ETSI EN 302 895 V1.1.1 (2014-09)

Reference
DEN/ITS-0010005
Keywords
application, ITS, management, user
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2014.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI EN 302 895 V1.1.1 (2014-09)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 8
4 General description of a LDM . 9
4.1 Functionality provided by the LDM . 9
5 LDM functional specification . 9
5.1 LDM requirements . 9
5.1.1 LDM functional requirements. 9
5.1.2 LDM other requirements . 10
5.2 The LDM within the ITS-S communication architecture . 10
5.3 LDM functional architecture . 11
5.3.1 Function FN.LDM.1 - LDM Service . 11
5.3.2 Function FN.LDM.2 - LDM Maintenance . 12
5.4 Interfaces of the LDM . 12
5.4.1 Interface IF.LDM.1 - management layer . 12
5.4.2 Interface IF.LDM.2 - security layer . 13
5.4.3 Interface IF.LDM.3 - LDM Data Providers . 13
5.4.4 Interface IF.LDM.4 - LDM Data Consumers . 13
6 LDM Interfaces . 14
6.1 Interface IF.LDM.2 to the security layer . 14
6.1.1 Authorization . 14
6.1.1.1 Authorize messages . 14
6.1.2 Revocation . 15
6.1.2.1 RevokeAuthorization messages . 15
6.2 Interface IF.LDM.3 to LDM Data Providers . 16
6.2.1 Registration . 16
6.2.1.1 RegisterDataProvider messages . 16
6.2.2 Deregistration . 17
6.2.2.1 DeregisterDataProvider messages . 17
6.2.2.2 RevokeDataProviderRegistration message . 17
6.2.3 Maintenance of Provider data . 18
6.2.3.1 AddProviderdata messages . 18
6.2.3.2 UpdateProviderdata messages . 19
6.2.3.3 DeleteProviderdata messages . 19
6.3 Interface IF.LDM.4 to LDM Data Consumers . 20
6.3.1 Registration . 20
6.3.1.1 RegisterDataConsumer messages . 20
6.3.2 Deregistration . 21
6.3.2.1 DeregisterDataConsumer messages . 21
6.3.2.2 RevokeDataConsumerRegistration message . 22
6.3.3 Data Request . 22
6.3.3.1 RequestDataobjects messages . 22
6.3.4 Subscription . 23
ETSI
4 ETSI EN 302 895 V1.1.1 (2014-09)
6.3.4.1 SubscribeDataConsumer messages . 23
6.3.5 Cancel subscription . 25
6.3.5.1 UnsubscribeDataConsumer messages . 25
Annex A (normative): Data request filtering . 26
A.1 Minimal syntax of data request filtering . 26
A.1.1 Filter . 26
A.1.2 Filter Statement . 26
A.1.2.1 Comparison Operator . 27
A.1.2.2 Reference Value . 27
A.1.3 Logical operators for combining Filter Statements . 27
A.2 Ordering Data Request Results . 28
Annex B (normative): ITS LDM Interface messages specified in ASN.1 . 29
Annex C (informative): Bibliography . 35
History . 36

ETSI
5 ETSI EN 302 895 V1.1.1 (2014-09)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This European Standard (EN) has been produced by ETSI Technical Committee Intelligent Transport Systems (ITS).
The present document is a single part deliverable.

National transposition dates
Date of adoption of this EN: 22 September 2014
Date of latest announcement of this EN (doa): 31 December 2014
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 30 June 2015
Date of withdrawal of any conflicting National Standard (dow): 30 June 2016

Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "may not", "need", "need not", "will",
"will not", "can" and "cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms
for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
In cooperative Intelligent Transport Systems (ITS), the Local Dynamic Map (LDM) is a key facility supporting various
ITS applications by maintaining the information on objects influencing or being part of ITS. The Local Dynamic Map
therefore is relevant to the development of technical standards and specifications in order to ensure deployment and
interoperability of cooperative systems and services described in the EC's ICT Standardization Work Programme [i.7].
The LDM is a facility within the ITS station facilities layer as defined in the ITS communication architecture given in
EN 302 665 [i.1]. Cooperative Awareness Messages (CAMs) as defined in EN 302 637-2 [4] and Decentralized
Environmental Notification Messages (DENMs) as defined in EN 302 637-3 [5] are important sources of data for the
LDM.
Moreover the LDM will support the Basic Set of Applications (BSA) outlined in TS 102 637-1 [i.2] by providing
plausible authorized, area related information in a time relevant manner. The BSA provides the application specific
requirements for the LDM.
ETSI
6 ETSI EN 302 895 V1.1.1 (2014-09)
The following applications from the BSA are considered:
• Driving assistance - Cooperative awareness.
• Driving assistance - Road Hazard Signalling (see TS 101 539-1 [i.3]).
• Speed management.
• Cooperative navigation Location based services.
• Community services.
• ITS station life cycle management.
ETSI
7 ETSI EN 302 895 V1.1.1 (2014-09)
1 Scope
The present document defines functional behaviour associated with a Local Dynamic Map (LDM) for usage in an ITS
station unit (ITS-SU). It specifies functions and interfaces supported by a LDM. These functions and interfaces provide
secure access to the LDM to manage LDM data objects stored in a LDM. It defines LDM data objects for safety-related
and Vehicle to Vehicle (V2V)-related applications.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 102 860 (V1.1.1) (2011-05): "Intelligent Transport Systems (ITS); Classification and
management of ITS application objects".
[2] ISO/IEC 8824-1:2008: "Information technology - Abstract Syntax Notation One (ASN.1):
Specification of basic notation".
[3] ETSI TS 102 894-2: "Intelligent Transport Systems (ITS); Users and applications requirements;
Part 2: Applications and facilities layer common data dictionary".
[4] ETSI EN 302 637-2 (V1.3.1) (2014-09): "Intelligent Transport Systems (ITS); Vehicular
Communications; Basic Set of Applications; Part 2: Specification of Cooperative Awareness Basic
Service".
[5] ETSI EN 302 637-3 (V1.2.1) (2014-09): "Intelligent Transport Systems (ITS); Vehicular
Communications; Basic Set of Applications; Part 3: Specifications of Decentralized
Environmental Notification Basic Service".
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI EN 302 665 (V1.1.1) (2010-09): "Intelligent Transport Systems (ITS); Communications
Architecture".
[i.2] ETSI TS 102 637-1 (V1.1.1) (2010-09): "Intelligent Transport Systems (ITS); Vehicular
Communications; Basic Set of Applications; Part 1: Functional Requirements".
[i.3] ETSI TS 101 539-1 (V1.1.1) (2013-08): "Intelligent Transport Systems (ITS); V2X Applications;
Part 1: Road Hazard Signalling (RHS) application requirements specification".
[i.4] ETSI TS 102 723-5 (V1.1.1) (2012-11): "Intelligent Transport Systems (ITS); OSI cross-layer
topics; Part 5: Interface between management entity and facilities layer".
ETSI
8 ETSI EN 302 895 V1.1.1 (2014-09)
[i.5] ETSI TR 102 863 (V1.1.1) (2011-06): "Intelligent Transport Systems (ITS); Vehicular
Communications; Basic Set of Applications; Local Dynamic Map (LDM); Rationale for and
guidance on standardization".
[i.6] ISO/IEC 19505-2:2012(E): "Information technology - Object Management Group Unified
Modeling Language (OMG UML), Superstructure".
[i.7] European Commission: "2010-2013 ICT Standardisation Work Programme for industrial
innovation", 2nd update - 2012.
NOTE: Available at: http://ec.europa.eu/enterprise/sectors/ict/files/ict-policies/2010-
2013_ict_standardisation_work_programme_2nd_update_en.pdf.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
area of interest: geographical area specified by data consumer limiting the LDM to satisfying the data consumers'
subsequent requests for information only from data originating within that area
LDM area of maintenance: geographical area specified by the LDM for LDM maintenance
LDM data consumer: facility or an application that is authorized to request data from the LDM
LDM data object: object with attributes that can be accessed by the LDM Interfaces
LDM data object identifier: unique identifier within the LDM for a LDM Data Object added by a LDM Data Provider
LDM data provider: facility or an application that is authorized to provide the data to the LDM
Local Dynamic Map (LDM): facilities layer data store for storing LDM Data Objects that are timestamped and
location referenced
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ASN Abstract Syntax Notation
BSA Basic Set of Applications
CA Co-operative Awareness
CAM Co-operative Awareness Message
DEN Decentralized Environmental Notification
DENM Decentralized Environmental Notification Message
FA-SAP Facilities/Applications Service Access Point
ICRW Intersection Collision Risk Warning
ICT Information and Communication Technology
ITS Intelligent Transport System
ITS-AID ITS Application IDentifier
ITS-S Intelligent Transport System Station
ITS-SU Intelligent Transport System Station Unit
LCRW Longitudinal Collision Risk Warning
LDM Local Dynamic Map
MF-SAP Management/Facilities Service Access Point
NF-SAP Networking & Transport/Facilities Service Access Point
RHS Road Hazard Signalling
SF-SAP Security Facilities - Service Access Point
UML Unified Modelling Language
V2V Vehicle to Vehicle
ETSI
9 ETSI EN 302 895 V1.1.1 (2014-09)
4 General description of a LDM
A Local Dynamic Map (LDM) is a facility in cooperative Intelligent Transport Systems (ITS). It supports ITS
applications by maintaining information on objects influencing or influenced by road traffic. ITS applications require
information on moving objects such as vehicles nearby or on stationary objects such as traffic road signs. Information
required by, or useful to active applications, can be maintained in a LDM.
The LDM is a conceptual data store located within an ITS-S as outlined in EN 302 665 [i.1] containing information
which is relevant to the operation of ITS applications and related road safety and traffic efficiency. Data can be received
from a range of different sources such as vehicles, infrastructure units, traffic centres, personal ITS stations, and
on-board sensors and applications. The LDM offers mechanisms to grant secure access to the data that it holds. For
example, the LDM can provide information on the surrounding vehicles and Road Side Units to any authorized
application that requests it.
The information stored in the LDM can be accessed in the form of objects called LDM Data Objects. LDM Data
Objects are provided from for example basic services for ITS Message Sets such as those defined in EN 302 637-2 [4]
and EN 302 637-3 [5]. LDM Data Objects can be composed of sub objects, similar to the hierarchical structure of data
frames in messages, and the objects contain attributes representing data elements from TS 102 894-2 [3]. Information
on a vehicle or road side ITS-S for example is provided by a cooperative awareness basic service as defined in
EN 302 637-2 [4] and is accessed from the LDM as a LDM Data Object with sub-objects representing the information
from the CAM Basic Container. Information on an event for example is provided by a distributed environmental
notification basic service as defined in EN 302 637-3 [5] and is accessed from the LDM as a LDM Data Object with
sub-objects for the situation, location and a la carte containers.
The LDM can also store LDM Data Objects from applications and other facilities. For example, the LDM may maintain
information on the ITS-S it is part of.
The LDM does not modify the data provided by LDM Data Providers. No permanent, static information is required to
be stored in the LDM.
4.1 Functionality provided by the LDM
The basic functionality of the LDM is to provide a repository of information for facilities and applications. Facilities
such as the CA and DEN basic services can store information into the LDM. Applications can retrieve information from
and store information into the LDM. Additional functionality of the LDM includes:
• Registration/Deregistration of facilities and applications as LDM Data Providers/sinks to the LDM via the
security layer (authorization) (see clause 6.1.1).
• Subscribe/Unsubscribe for notifications (see clause 6.3.4).
• Information retention by applying rules, e.g. based on time and/or location (see clause 5.3.2).
• Prioritization of requests (see clause 6.3.3).
5 LDM functional specification
5.1 LDM requirements
5.1.1 LDM functional requirements
A LDM may communicate with other entities within the ITS-S architecture outlined in EN 302 665 [i.1] in order to:
• receive incoming information such as decoded CAMs in accordance with EN 302 637-2 [4] and DENMs in
accordance with EN 302 637-3 [5];
• store and protect information according to constraints of time and LDM Area of Maintenance;
ETSI
10 ETSI EN 302 895 V1.1.1 (2014-09)
• provide information to authorized applications as requested:
- by means of a subscription/notification method; or
- by means of queries including spatial queries;
• prioritize data requests;
• store and protect LDM Data Objects so that it can be shared with applications;
• provide a mechanism for facilities and applications to register and deregister as LDM Data Providers;
• provide a mechanism for applications to register and deregister as LDM Data Consumers;
• ensure data access by LDM Data Providers and LDM Data Consumers is authorized.
5.1.2 LDM other requirements
In addition to the functional requirements listed in clause 5.1.1, a LDM may be constrained by a range of other
requirements such as reliability (system maturity, fault tolerance and restorability) and scalability. However, within
communications systems such requirements are normally considered to be related to procurement and, consequently,
are not specified in the present document.
5.2 The LDM within the ITS-S communication architecture
The LDM collects, qualifies (ensures that it is valid and from an authorized source) and stores data received from other
ITS-Ss. The LDM may also collect, qualify and store information from other sources such as traffic information
providers, or from its own sensors and applications.
As shown in Figure 1, the LDM receives data from other ITS-Ss through a common interface which is available to all
message services such as CA and DEN within the ITS-S Facilities layer. Information is exchanged with other services
or applications by invoking functions located at the FA-SAP as outlined in EN 302 665 [i.1]. Security and management
permissions are provided by functions which are located at the SF-SAP and the MF-SAP respectively.

Figure 1: LDM and logical interfaces
ETSI
11 ETSI EN 302 895 V1.1.1 (2014-09)
5.3 LDM functional architecture
The rationale for and guidance on standardization of the LDM outlined in TR 102 863 [i.5] specify two main
components of the LDM; the LDM Maintenance component and the LDM Service component (see clause 5.3.1).
Figure 2 shows these two components of the LDM and its main interfaces in a Unified Modelling Language (UML)
component diagram in accordance with ISO/IEC 19505-2 [i.6]. The interfaces are separated into those required by the
LDM (IF.LDM.1 and IF.LDM.2) and those exposed to other facilities and applications (IF.LDM.3 and IF.LDM.4).

Figure 2: LDM Functional architecture
The LDM shall provide the functions defined in Table 1 and illustrated in Figure 2.
Table 1: LDM Functions
Function Description
FN.LDM.1 The LDM Service component (see clause 5.3.1) is responsible for providing functionalities to
authorized LDM Data Providers for LDM data manipulation (such as adding new data, modifying
existing data, delete existing data), direct access to data (query data) and a publish/subscribe
mechanism for data access by LDM Data Consumers. It also provides registration and deregistration
functionalities to LDM Data Providers and LDM Data Consumers.
FN.LDM.2 The LDM Maintenance component (see clause 5.3.2) is responsible for storing and maintaining the
data and its integrity as well as for the garbage collection of persistent data held within the LDM.

5.3.1 Function FN.LDM.1 - LDM Service
The LDM is connected to authorized LDM Data Providers and LDM Data Consumers. LDM Data Providers provide
information to the LDM which makes these data available to LDM Data Consumers. The LDM offers three different
types of interfaces:
• a transaction interface for LDM Data Providers, where a transaction describes a sequence of LDM Data Object
exchanges between a LDM Data Provider and the LDM (see clause 6.2.3);
• a query interface for LDM Data Consumers (see clause 6.3.3); and
• a publish/subscribe interface for LDM Data Consumers (see clause 6.3.4).
ETSI
12 ETSI EN 302 895 V1.1.1 (2014-09)
The LDM shall:
• provide a mechanism for facilities to register and deregister as LDM Data Providers;
• provide a mechanism for applications to register and deregister as LDM Data Providers or LDM Data
Consumers;
• verify the authorization of LDM Data Providers and LDM Data Consumers prior to data access.
5.3.2 Function FN.LDM.2 - LDM Maintenance
The LDM shall maintain all LDM Data Objects received from registered and authorized LDM Data Providers during
their time validity and within the LDM Area of Maintenance of the LDM.
The LDM considers a LDM Data Object to be valid during the time period starting on the timestamp of the LDM Data
Object and for the duration of the time validity period. A LDM Data Provider specifies the timestamp and the time
validity of every LDM Data Object it provides to the LDM:
• The timestamp is specified upon adding or updating the LDM Data Object (see clause 6.2.3).
• The default time validity for all LDM Data Objects is specified upon registration (see clause 6.2.1). The
default time validity is replaced by the time validity specified for a specific LDM Data Object upon adding or
updating the LDM Data Object (see clause 6.2.3).
The LDM considers a LDM Data Object to be valid if the location of the LDM Data Object intersects with the LDM
Area of Maintenance. A LDM Data Provider specifies the location upon adding or updating a LDM Data Object (see
clause 6.2.3). The LDM Area of Maintenance is a geographical area defined by the LDM, which can be defined relative
to the momentary location of the host ITS-S.
5.4 Interfaces of the LDM
The LDM interfaces are identified in Figure 2 and specified in Table 2. Table 2 consists of the following 5 columns:
• Interface ID - providing the identifier of the interface described.
• Interface Type - describing the type of interface, with provided (P): interface is realized by the LDM and
offered to its clients, required (R): interface is needed by the LDM to perform an action but realized by another
component.
• Component connected - name of the component interacting with the LDM.
• Message type - type of message exchanged via the interface.
• Direction - describing the message flow, with IN: message received by the LDM, OUT: message provided by
the LDM.
Table 2: LDM Interfaces
Interface Interface Component connected Message Type Direction
ID Type
IF.LDM.1 R Management layer MF-SAP IN and OUT
IF.LDM.2 R Security layer SF-SAP IN and OUT
IF.LDM.3 P LDM Data Providers CAM, DENM and other IN
IF.LDM.4 P LDM Data Consumers CAM, DENM and other OUT

NOTE: This is a non-exclusive list which may be extended in the future.
5.4.1 Interface IF.LDM.1 - management layer
The interface IF.LDM.1 to the ITS Management layer is described in TS 102 723-5 [i.4].
ETSI
13 ETSI EN 302 895 V1.1.1 (2014-09)
5.4.2 Interface IF.LDM.2 - security layer
The LDM shall provide an interface IF.LDM.2 for the exchange of information with the ITS Security layer as described
in EN 302 665 [i.1] in order to verify the authorization of an ITS application or facility to access or modify specific
LDM Data Objects within the LDM.
The ITS security layer will exchange information with the LDM across interface IF.LDM.2 in order to revoke the
authorization of a previously authorized ITS LDM Data Provider and LDM Data Consumer.
5.4.3 Interface IF.LDM.3 - LDM Data Providers
The LDM shall provide an interface IF.LDM.3 to enable an application or facility to register as a LDM Data Provider
and, subsequently, to send LDM Data Objects to the LDM.
A LDM Data Provider shall register with the LDM before the LDM accepts LDM Data Objects from the LDM Data
Provider. The LDM shall request the security layer to check if the LDM Data Provider is authorized using the message
sequence specified in clause 6.1.1.1 across interface IF.LDM.2 (clause 5.4.2). The LDM shall confirm the success of the
authorization to the LDM Data Provider.
The LDM shall at least support the exchange of LDM Data Objects, sub-objects and attributes derived from frames,
sub-frames and elements such as defined in the Common Data Dictionary as specified in TS 102 894-2 [3]. Further
details on LDM Data Objects are out of scope of the present document.
While the LDM Data Provider is registered, the LDM shall provide access to LDM Data Objects for which the LDM
Data Provider is authorized.
When the authorization is revoked by the services of the security layer then the LDM shall deny further access to the
LDM Data Objects.
A LDM Data Provider may deregister itself from the LDM after which it shall no longer have access to LDM Data
Objects.
A LDM Data Provider shall provide a timestamp and location for LDM maintenance purposes with each LDM Data
Object sent to the LDM.
The LDM may store LDM Data Objects identified in Table 3 if offered by an authorized LDM Data Provider. The
LDM may update parts of the LDM Data Objects if offered by an authorized LDM Data Provider.
Table 3: LDM data objects
Message type Reference Data Object Description
CAM EN 302 637-2 [4] All data objects and attributes from a CAM
DENM EN 302 637-3 [5] All data objects and attributes from a DENM

NOTE: This is a non-exclusive list which may be extended in the future.
5.4.4 Interface IF.LDM.4 - LDM Data Consumers
The LDM shall provide an interface IF.LDM.4 to enable an ITS application or facility to register as a LDM Data
Consumer and to access data in the LDM.
A LDM Data Consumer shall register with the LDM before the LDM provides access to the LDM Data Objects. The
LDM requests the security layer to check if the LDM Data Consumer is authorized using the message sequence
specified in clause 6.1.1.1 across interface IF.LDM2 (see clause 5.4.2). The LDM checks the Area of Interest against its
LDM Area of Maintenance. The LDM shall confirm the success of the registration to the LDM Data Consumer.
While the LDM Data Consumer is registered, the LDM shall grant access to LDM Data Objects for which the LDM
Data Consumer is authorized.
When the authorization is revoked by the security services then the LDM shall inform the LDM Data Consumer that its
registration is revoked and shall deny further access to the LDM Data Objects.
ETSI
14 ETSI EN 302 895 V1.1.1 (2014-09)
A LDM Data Consumer may deregister itself from the LDM after which it shall no longer have access to LDM Data
Objects.
The LDM shall support the exchange of data as defined in the Common Data Dictionary as specified in
TS 102 894-2 [3].
The LDM shall provide mechanisms for filtering the LDM Data Objects to be returned upon request from the LDM
Data Consumer. These filtering mechanisms are:
1) A querying mechanism for an immediate single data request.
2) A publish/subscribe mechanism for the continuous return of data which shall support the following:
a) Event driven data request according to the given filter.
b) Periodic data request according to a given time interval and filter.
c) Composite event driven data request according to a given filter or time interval.
The filtering mechanisms contain a filter on one or more attributes of the requested LDM Data Objects. A filter on a
single attribute of a LDM Data Object compares the attribute value against a reference value (see clause A.1.2.2).
Only LDM Data Objects that meet the specified filtering criteria and are within the defined Area of Interest shall be
returned to the LDM Data Consumer by the LDM.
The response to a data request shall be a list of zero or more requested LDM Data Objects. In the case of the
publish/subscribe mechanism a LDM Data Consumer receives a response to the same request every time the
subscription criteria are matched.
The LDM shall support the prioritization of processing data requests.
6 LDM Interfaces
The interfaces to LDM Data Providers, LDM Data Consumers, and to the security and management layers are defined
here as messages in the information flow. These messages can also be considered as the data part of the service
primitives to the AF-SAP, MF-SAP and SF-SAP, and need to be extended with the source and destination addresses.
This clause specifies the minimal functionality of the LDM interfaces.
6.1 Interface IF.LDM.2 to the security layer
6.1.1 Authorization
6.1.1.1 Authorize messages
When the LDM receives a Registration request from a LDM Data Provider or a LDM Data Consumer (see clauses 6.2.1
and 6.3.1) it shall send an Authorize request message to the ITS Security layer across the interface IF.LDM.2 to verify
if the LDM Data Provider or LDM Data Consumer is authorized for access to LDM Data Objects. Figure 3 shows the
message sequence with the authorization request message (Authorize.Req) and the response message
(Authorize.Resp) to confirm the successful or unsuccessful authorization. The Registration Request and Response
messages are defined in clauses 6.2.1.1 and 6.3.1.1 for the LDM Data Provider and Consumers respectively.
ETSI
15 ETSI EN 302 895 V1.1.1 (2014-09)

Figure 3: LDM Data Provider or Consumer authorization message sequence
The content of the Authorize request and response messages in this information flow are specified at a functional level
as in Table 4. The request and response messages are specified at a syntactical level in annex B.
Table 4: Contents of Authorize Information Flow
Parameter Content Request Response
ITS Application Identifier ITS-AID as defined in TS 102 860 [1] Mandatory Mandatory
Permissions for which access Permissions are defined as one or more root LDM Mandatory Optional
is requested/granted Data Object types (or classes) that can be accessed (see note)
from the LDM. Typical permissions are the root classes
of LDM Data Objects decoded from ITS message sets
from Table 3 and TS 102 894-2 [3]
Result Indication of result of the request: Mandatory
• Successful
• Fail: Invalid ITS-AID
• Fail: Unable to authenticate application
• Fail: Application not authorized for requested
permissions
NOTE: Mandatory if the Result parameter is set to "Successful" and the list of permissions, for which
authorization is granted, is different from that requested.

6.1.2 Revocation
6.1.2.1 RevokeAuthorization messages
The RevokeAuthorization message shall be sent by the ITS Security Layer to the LDM across the interface IF.LDM.2
to inform the LDM that authorization to permit a particular LDM Data Provider or LDM Data Consumer to have access
to information in the LDM has been revoked. Figure 4 shows the message sequence with the revocation request
message (RevokeAuthorization.Req) and the response message (RevokeAuthorization.Resp) to
confirm the successful or unsuccessful revocation. The Revoke Registration message is defined in clauses 6.2.2.2 and
6.3.2.2 for the LDM Data Provider and Consumers respectively.
ETSI
16 ETSI EN 302 895 V1.1.1 (2014-09)

Figure 4: Authorization revocation message sequence
The content of the RevokeAuthorization request and response messages are specified at a functional level as in Table 5.
The request and response messages are specified at a syntactical level in annex B.
Table 5: Contents of RevokeAuthorization Information Flows
Parameter Content Request Response
ITS Application Identifier ITS-AID as defined in TS 102 860 [1] Mandatory Mandatory
Reason Indication of the reason why authorization is revoked Mandatory
for the application:
• Registration of the application or service has
been revoked by the Registration Authority
• Period of authorization has expired
Revocation Indication that the revocation has been received and Mandatory
acknowledgement processed
6.2 Interface IF.LDM.3 to LDM Data Providers
6.2.1 Registration
6.2.1.1 RegisterDataProvider messages
A LDM Data Provider shall send a RegisterDataProvider request message to the LDM across the interface IF.LDM.3 to
register for access to LDM Data Objects. Figure 5 shows the message sequence with the registration request message
(RegisterDataProvider.Req) and the response message (RegisterDataProvider.Resp) to confirm the
successful or unsuccessful registration. The LDM uses the Authorization message across interface IF.LDM.2 to request
the verification of the authorization from the security layer (see clause 6.1.1.1).
NOTE: If a LDM Data Provider is already registered with the LDM it is deregistered without notification before
the new registration request is processed.

Figure 5: LDM Data Provider registration message sequence
ETSI
17 ETSI EN 302 895 V1.1.1 (2014-09)
The content of the RegistrationDataProvider request and response messages are specified at a functional level as in
Table 6. The request and response messages are specified at a syntactical level in annex B.
Table 6: Contents of RegisterDataProvider Information Flow
Parameter Content Request Response
IT'S Application Identifier ITS-AID as defined in TS 102 860 [1] Mandatory Mandatory
Permissions for which access Permissions are defined as one or more root LDM
Mandatory Optional
is requested/granted Data Object types (or classes) that can be provided (see note)
as the root classes of LDM Data Objects decoded
from ITS message sets from Table 3 and
TS 102 894-2 [3]
Time validity Default time validity of provided data Mandatory
Result Indication of result of the registration request: Mandatory
• Accepted
• Rejected
NOTE: Mandatory if the Result parameter is set to the value "Accepted" and the list of permissions for which
authorization is granted is different from that requested.

6.2.2 Deregistration
6.2.2.1 DeregisterDataProvider messages
A LDM Data Provider shall send a DeregisterDataProvider request message to the LDM to deregister itself as a LDM
Data Provider from the LDM. Figure 6 shows the message sequence for deregistration with the request message
(DeregisterDataProvider.Req) and the response message (DeregisterDataProvider.Req) to confirm
the
...