ETSI TS 103 301 V2.3.1 (2026-04)

Intelligent Transport Systems (ITS); Facilities Layer; Infrastructure Services; Release 2

RTS/ITS-001995

General Information

• Status: Not Published
• Technical Committee: ITS WG1 - Application Requirements and Services
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Due Date: 19-Apr-2026
• Completion Date: 23-Apr-2026

Standards Content (Sample)

TECHNICAL SPECIFICATION
Intelligent Transport Systems (ITS);
Facilities Layer;
Infrastructure Services;
Release 2
2 ETSI TS 103 301 V2.3.1 (2026-04)

Reference
RTS/ITS-001995
Keywords
application, data, ITS, protocol, requirements

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
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 prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
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.

© ETSI 2026.
All rights reserved.
ETSI
3 ETSI TS 103 301 V2.3.1 (2026-04)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Infrastructure services introduction . 8
4.1 Naming convention . 8
4.2 Services provided by IS . 8
4.3 Infrastructure services in the ITS organizational architecture . 10
4.4 Interfaces of the infrastructure services . 11
4.4.1 Interface to the ITS-S applications . 11
4.4.2 Interface to management plan entities . 11
4.4.3 Interface to security plan entities . 11
4.4.4 Interfaces IS_DataIn and IS_DataOut. 11
4.5 Common protocol requirements for infrastructure services . 12
4.5.1 Security for messages used by infrastructure . 12
4.5.2 Message payload encapsulation . 13
4.5.3 Message encoding scheme . 13
4.6 Protocol version . 13
4.6.1 Protocol version definition . 13
4.6.2 Protocol version handling . 13
5 Traffic Light Manoeuvre (TLM) service . 14
5.1 TLM service overview . 14
5.2 TLM service . 15
5.3 TLM service message and version . 15
5.4 TLM service dissemination . 15
5.4.1 TLM service identification . 15
5.4.2 TLM service trigger, update, repetition and termination . 15
5.4.3 TLM service communication requirements . 16
5.4.3.1 TLM service communication overview . 16
5.4.3.2 TLM service communication requirements for direct communication technologies . 16
5.4.3.3 TLM service communication requirements for indirect communication . 17
6 Road and Lane Topology (RLT) service . 18
6.1 RLT service overview . 18
6.2 RLT service . 19
6.3 RLT service message and version . 19
6.4 RLT service dissemination . 19
6.4.1 RLT service identification . 19
6.4.2 RLT service trigger, update, repetition and termination . 19
6.4.3 RLT service communication requirements . 20
6.4.3.1 RLT service communication overview . 20
6.4.3.2 RLT service communication requirements for direct communication technologies . 20
6.4.3.3 RLT service dissemination parameters for indirect communication . 21
7 Infrastructure to Vehicle Information (IVI) service . 22
7.1 IVI service overview . 22
ETSI
4 ETSI TS 103 301 V2.3.1 (2026-04)
7.2 IVI service . 22
7.3 IVI service message and version . 22
7.4 IVI service dissemination . 22
7.4.1 IVI service identification . 22
7.4.2 IVI service trigger, update, repetition and termination . 23
7.4.3 IVI service communication requirements . 23
7.4.3.1 IVI service communication parameters for direct communication . 23
7.4.3.2 IVI service dissemination parameters for indirect communication . 26
8 Traffic Light Control (TLC) service . 27
8.1 TLC service overview . 27
8.2 TLC service . 28
8.3 TLC service message and version . 29
8.4 TLC service dissemination . 29
8.4.1 TLC service identification . 29
8.4.2 TLC service trigger, update, repetition and termination . 29
8.4.3 TLC service communication requirements . 30
8.4.3.1 TLC service communication overview . 30
8.4.3.2 TLC service communication parameters for direct communication technologies . 30
8.4.3.3 TLC service communication parameters for indirect communication . 32
9 GNSS Positioning Correction (GPC) service . 33
9.1 GPC service overview . 33
9.2 GPC service . 33
9.3 GPC service message and version . 33
9.4 GPC service dissemination . 34
9.4.1 GPC service identification . 34
9.4.2 GPC service trigger, update, repetition and termination . 34
9.4.3 GPC service communication requirements . 34
9.4.3.1 GPC service communication overview . 34
9.4.3.2 GPC service communication requirements for direct communication technologies . 34
9.4.3.3 GPC service dissemination parameters for indirect communication . 36
10 Basic services running on ITS infrastructure devices . 36
10.1 Basic service overview . 36
10.2 DEN service on ITS infrastructure devices . 36
10.3 CA service on ITS infrastructure devices . 37
11 Communication Profiles . 37
12 Security Profile . 37
Annex A (normative): ASN.1 specification of IS Messages . 38
Annex B (informative): SSP coding of ServiceProviderId (DF Provider) . 39
B.1 SSP coding examples of DF Provider . 39
History . 41

ETSI
5 ETSI TS 103 301 V2.3.1 (2026-04)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are 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 IPR online database.
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
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.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™, LTE™ and 5G™ logo are trademarks of ETSI registered for the benefit of its Members and of the
3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of ®
the oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Intelligent Transport Systems
(ITS).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "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
The infrastructure services are application support facilities provided by the Facilities layer that construct, manage and
process messages distributed from infrastructure to end-users or vice-versa based on payload received from the
application. The infrastructure services specified in the present document support infrastructure-based applications in
order to achieve communication interoperability, and may be implemented in parallel to other services in an ITS-S.

ETSI
6 ETSI TS 103 301 V2.3.1 (2026-04)
1 Scope
The present document provides specifications of infrastructure related ITS services to support communication between
infrastructure ITS equipment and traffic participants using ITS equipment (e.g. vehicles, pedestrians). It defines services
in the facilities layer for communication between the infrastructure and traffic participants. The specifications cover the
protocol handling for infrastructure-related messages as well as requirements related to the security entity.
2 References
2.1 Normative 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 in the
ETSI docbox.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are necessary for the application of the present document.
[1] Void.
[2] ETSI TS 102 894-2: "Intelligent Transport Systems (ITS);Facilities Layer; Part 2: Common data
dictionary (CDD); Release 2".
[3] Void.
[4] Void.
[5] Void.
[6] ETSI TS 103 097: "Intelligent Transport Systems (ITS); Security; Security header and certificate
formats; Release 2".
[7] CEN ISO/TS 19321: "Intelligent transport systems - Cooperative ITS - Dictionary of in-vehicle
information (IVI) data structures".
[8] ETSI TS 103 899: "Intelligent Transport Systems (ITS); Vehicular Communications; Geographical
Area Definition; Release 2".
[9] Recommendation ITU-T X.691 / ISO/IEC 8825-2: "Information technology - ASN.1 encoding
rules: Specification of Packed Encoding Rules (PER)".
2.2 Informative 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.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's
understanding, but are not required for conformance to the present document.
[i.1] Void.
ETSI
7 ETSI TS 103 301 V2.3.1 (2026-04)
[i.2] ISO/TS 17423: "Intelligent transport systems — Application requirements and objectives".
[i.3] ISO/TS 14823-1: "Intelligent transport systems — Graphic data dictionary — Part 1:
Specification".
[i.4] Void.
[i.5] Void.
[i.6] Void.
[i.7] Void.
[i.8] Void.
[i.9] Void.
[i.10] SAE J2945/5-202002: "Service Specific Permissions and Security Guidelines for Connected
Vehicle Applications".
[i.11] CEN ISO/TS 19091: "Intelligent transport systems - Cooperative ITS - Using V2I and I2V
communications for applications related to signalized intersections".
[i.12] Void.
[i.13] ISO/TS 17427-1: " Intelligent transport systems — Cooperative ITS — Part 1: Roles and
responsibilities in the context of co-operative ITS architecture(s)".
[i.14] ETSI TS 103 836-4-1: "Intelligent Transport Systems (ITS); Vehicular Communications;
GeoNetworking; Part 4: Geographical addressing and forwarding for point-to-point and
point-to-multipoint communications; Sub-part 1: Media-Independent Functionality; Release 2".
[i.15] Void.
[i.16] ETSI TS 103 900: "Intelligent Transport Systems (ITS); Facilities Layer; Cooperative Awareness
Service; Release 2".
[i.17] ETSI TS 103 831: "Intelligent Transport Systems (ITS); Facilities Layer; Decentralized
Environmental Notification Service; Release 2".
[i.18] ETSI TS 102 965: "Intelligent Transport Systems (ITS); Application Object Identifier (ITS-AID);
Registration; Release 2".
[i.19] ETSI TR 103 902: "Intelligent Transport Systems (ITS); ITS Framework; Terms, Symbols and
Abbreviations; Release 2".
[i.20] ISO 3166-1: "Codes for the representation of names of countries and their subdivisions — Part 1:
Country code".
[i.21] Recommendation ITU-T S.1: "International Telegraph Alphabet No. 2".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI TR 103 902 [i.19] apply.
ETSI
8 ETSI TS 103 301 V2.3.1 (2026-04)
3.2 Symbols
For the purposes of the present document, the following symbols apply:
IS_Control Interface required by the IS to management plane entity(ies)
IS_DataIn Interface required by the IS to gather IS PDUs and other data
IS_DataOut Interface required by the IS to pass IS PDUs to other entities
IS_DataProviding Interface provided by the IS for making collected IS PDUs available
IS_Security Interface required by the IS to security plane entity(ies)
IS_Triggering Interface provided by the IS for controlling IS PDU dissemination
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI TR 103 902 [i.19] and the following apply:
GPCH General Purpose Channel
SFCH SaFety Channel
4 Infrastructure services introduction
4.1 Naming convention
Within the scope of the present document, the term "message" refers to the Facilities layer PDU; the term "payload"
refers to the applications layer ADU. The payload is generated by the application and provided to the corresponding
service of the Facilities layer. The Facilities service merges the ItsPduHeader with the payload, in order to construct a
message. The message is then delivered to the ITS Networking & Transport Layer (NTL) with a set of communication
parameters.
NOTE: In other specifications referred by the present document, the term message, payload, data structure may
have different meanings e.g. in CEN ISO/TS 19091 [i.11] and in CEN ISO/TS 19321 [7]. Therefore, the
current convention is defined for clarification purposes.
4.2 Services provided by IS
The infrastructure services refer to Facilities layer entities that manage the generation, transmission and reception of
infrastructure-related messages from the infrastructure to Vehicle or Personal ITS-S or vice-versa. Figure 1 illustrates a
high level functional architecture of the infrastructure services within the ITS communication architecture. The
messages are Facilities layer PDUs that are exchanged among ITS-Ss. The payload is generated by ITS applications in
the transmitting ITS-S. At the transmitting ITS-S, the transmission of a message is triggered by applications or by
forwarding mechanisms. For this purpose, the applications may connect to other entities of the Facilities layer or to
external entities, in order to collect relevant information for the generation of the payload. Once the message is
generated, the services may repeat the transmission, until the applications requests the termination of the transmission,
or trigger another request to generate updated messages. At the receiving ITS-S, the messages are processed by the
services and the content of the message is delivered to applications or to other Facilities layer entity. In one typical
application, the message is transmitted by a Roadside ITS-S and disseminated to a Vehicle ITS-S within a target
destination area, in which the information included in the message is considered as relevant to traffic participants.
In the scope of the present document, the infrastructure services supports the management of the following message
types. As result, the infrastructure services include a set of service entities as listed below:
• SPATEM as defined in Annex A. The corresponding service entity is referred as "Traffic Light Manoeuvre" -
TLM service in the present document. TLM service is specified in clause 5 of the present document.
• MAPEM as defined in Annex A. The corresponding service entity is referred as "Road and Lane Topology" -
RLT service in the present document. RLT service is specified in clause 6 of the present document.
ETSI
9 ETSI TS 103 301 V2.3.1 (2026-04)
• IVIM as defined in Annex A. The corresponding service entity is referred as "Infrastructure to Vehicle
Information" - IVI service in the present document. IVI service is specified in clause 7 of the present
document.
• SREM as specified in Annex A. The corresponding service entity is referred as "Traffic Light Control" -
TLC service in the present document. TLC service is specified in clause 8 of the present document.
• SSEM as specified in Annex A. The corresponding service is referred as "Traffic Light Control" - TLC service
in the present document. TLC service is specified in clause 8 of the present document.
NOTE: Other messages may be supported by infrastructure services in the future.

Figure 1: Infrastructure services and logical interfaces
The infrastructure services shall provide at least the following functions.
For the transmission service:
• Message encoding.
• Dissemination management.
For the reception service:
• Message decoding.
• Collection management.
ETSI
10 ETSI TS 103 301 V2.3.1 (2026-04)

Figure 2: Infrastructure service component diagram
4.3 Infrastructure services in the ITS organizational architecture
Within the role "System Operation" as defined in ISO/TS 17427-1 [i.13], the following sub roles are relevant for the
infrastructure services:
• "Content Provision" is responsible for generating the information that is conveyed in the message. This task is
included in any application providing information to the application which generates the payload.
• "Service Provision" is responsible for the generation of the payload and the transmission of the message using
an ITS-S. This task is managed by the application making use of the infrastructure services.
• "Service Presentation" is responsible for the reception of the messages and its processing and presentation.
This task is managed by the infrastructure services and the application.

Figure 3: Identification of sub-roles of the role system (lifecycle)
operation in the ITS organizational architecture
ETSI
11 ETSI TS 103 301 V2.3.1 (2026-04)
4.4 Interfaces of the infrastructure services
4.4.1 Interface to the ITS-S applications
The infrastructure services within the Facilities layer provide APIs to applications for the processing of the payload at
the transmitting ITS-S and the receiving ITS-S. An application may execute requests to the infrastructure services in the
Facilities layer to trigger, update or terminate transmission of a message. In addition, a set of Facilities control
information is passed as specified in Table 1.
Table 1 presents the data contained in an application request.
Table 1: Interfaces to ITS-S applications
Category Data Definition
Infrastructure Identification of the message
message
identification
Data passed from
Request type Trigger, update or ending of transmission
application to
Dissemination Conditional PCI and SCI data for IS_DataOut (see Table 2) like e.g. GN
infrastructure
parameter traffic class as defined in ETSI TS 103 836-4-1[i.14], if
services
GeoNetworking/BTP is used
(IS_Triggering)
For more details, see the dissemination profile for each service in
clauses 5 to 8
Payload Information contained in payload
Infrastructure The Infrastructure service returns the message identification or other
Data returned from
message applicable identifier created by the infrastructure service to the requesting
infrastructure
identification or application
services to the
Another applicable
requesting
identifier
application
Failure notification The infrastructure service returns a failure notification to the requesting
(IS_Triggering)
application
Data provided from Infrastructure Identification of the message
infrastructure message
identification
services to
application Payload Information contained in message as payload
(IS_DataProviding) Collection parameter Conditional PCI and SCI data from IS_DataIn (see Table 2)

4.4.2 Interface to management plan entities
The infrastructure services may exchange information with the entity(ies) in the ITS management plane via the interface
IS_Control.
NOTE: The specifications of the interface between the infrastructure services and the management entity is out of
scope of the present document.
4.4.3 Interface to security plan entities
In case ETSI ITS security at the facilities layer is used, the infrastructure services exchange information directly with
the entity(ies) in the security plane via the interface IS_Security.
NOTE: The specifications of the interface between the infrastructure services and the security entity is out of
scope of the present document.
4.4.4 Interfaces IS_DataIn and IS_DataOut
The infrastructure services shall pass the message for dissemination via the IS_DataOut to either another facilities layer
entity such as Resource Management or a lower layer functionality such as the NTL.
The infrastructure service shall gather messages via the IS_DataIn from either another facility layer entity such as
Resource Management or a lower layer functionality such as the NTL.
ETSI
12 ETSI TS 103 301 V2.3.1 (2026-04)
Table 2: Messages exchanged over Interfaces IS_DataIn and IS_DataOut
Category Data Data requirement M/O/C Remark/Condition
(see note)
Data provided PDU {message} as specified in Annex A, M
by the
infrastructure
services via
SCI Additional control information related to C if a security scheme at the
IS_DataOut
security such as ITS-AID and SSP which NTL (e.g. ETSI Security [6])
shall be listed in the Authorization Ticket requiring SCI is used.
associated to the private key used to sign the
message at the NTL.
PCI Additional control Information depending on C If a NTL protocol requiring PCI
the protocol stack applied in the NTL. is used.
RMI Additional control information related to C If RM is available.
Resource management.
Data gathered Received {message} as specified in Annex A. M
by the PDU
infrastructure
services via
SCI Additional control information related to C if a security scheme at the
IS_DataIn
security such as ITS-AID and SSP that are NTL (e.g. ETSI Security [6])
listed in the Authorization Ticket attached to requiring SCI is used.
the message and the result of the security
check at the NTL.
PCI Additional control Information depending on C If a NTL protocol requiring PCI
the protocol stack applied in the NTL. is used.
NOTE: M/O/C are as follows:
"M" indicates that the Data element shall always be included.
"O" indicates that the Data element may or may not be included.
"C" indicates that the Data element shall be included only if the condition is satisfied.

The infrastructure services may request data from the PoTi service using IS_DataIn.
NOTE 1: The specifications of the interface between the infrastructure services and the PoTi service is out of scope
of the present document.
The infrastructure services may provide messages to the LDM service using IS_DataOut.
NOTE 2: The specifications of the interface between the infrastructure services and the LDM service is out of
scope of the present document.
4.5 Common protocol requirements for infrastructure services
4.5.1 Security for messages used by infrastructure
The security mechanisms for messages used by the infrastructure service as specified in the present document shall use
the message authentication with signatures to be verified at the receiving ITS-S with public keys contained in
certificates. A certificate indicates its holder's permissions, i.e. what statements the holder is allowed to make or
privileges it is allowed to assert in a message signed by that certificate. The format for the certificates shall be as
specified in ETSI TS 103 097 [6].
All defined messages in the present document shall be signed using private keys associated to Authorization Tickets
that contain the appPermissions item with the ITS-AID of the Service and corresponding SSPs of type BitmapSsp as
specified in ETSI TS 103 097 [6].
Service permissions are indicated by a pair of identifiers within a certificate, the ITS-AID and the SSP. The
ITS-Application Identifier (ITS-AID) as given in ETSI TS 102 965 [i.18] indicates the overall type of permissions
being granted.
ETSI
13 ETSI TS 103 301 V2.3.1 (2026-04)
The Service Specific Permissions (SSP) is a field that indicates specific sets of permissions within the overall
permissions indicated by the ITS-AID. The originating ITS-S shall provide SSP information in its certificate for all
generated, signed messages. The SSP permissions are defined for each message in the corresponding clause. The
common approach that is used for all messages is that the SSP information is constructed out of N octets with a
maximum length as specified in ETSI TS 103 097 [6]. For each octet, the Most Significant Bit (MSB) shall be the
leftmost bit. The transmission order shall always be the MSB first. The first octet shall control the SSP version and be
interpreted in the following way:
0: NULL version, length 1 octet; the value shall only be used for testing purposes.
1.n: SSP version as defined in the present document for each service (see "SSP version control").
At reception of a message, the ITS-S shall check whether the message content is consistent with the SSP contained in
the certificate in its signature. If the consistency check fails, the message shall be discarded.
4.5.2 Message payload encapsulation
The ItsPduHeader header as defined in ETSI TS 102 894-2 [2] shall be used to encapsulate the payload in order to
construct messages. The ITS PDU header includes the following elements:
• protocolVersion: Version of the ITS payload contained in the message as defined for the specific infrastructure
service.
• messageID: Type of the ITS payload contained in the message as defined for the specific infrastructure
service.
• stationID: Identifier of the ITS-S that generated the message.
The messageID data element allows the receiver to identify the ITS message and to make it available to the
corresponding Facilities layer service.
The protocolVersion data element allows the receiver to correctly deal with different versions of the protocol
specification for the message.
More detailed information is covered in Annex A.
4.5.3 Message encoding scheme
Unless specified otherwise, the unaligned PER encoding scheme as specified in Recommendation ITU-T X.691 [9]
shall be used for the encoding of the messages specified in the present document.
4.6 Protocol version
4.6.1 Protocol version definition
The value of the protocol version for the messages SPATEM, MAPEM, IVIM, SREM, SSEM, RTCMEM is individual
and independent of each other. It is defined in the ItsPduHeader for each message and identified by the protocolVersion
data element (see clauses 5 to 8).
4.6.2 Protocol version handling
If the ASN.1 definition of the protocol is extended without compromising the backwards compatibility, the data element
protocolVersion will not be increased. This allows the receiving ITS-S to process the message correctly (except the
extensions) without the need for immediate update. An update for protocol interoperability is not needed, unless the
receiving ITS-Station is intended to correctly interpret also the added extensions.
The protocolVersion data element is increased only in case of non-backwards compatible changes in the protocol
specification to allow the receiving ITS-S to handle the message appropriately.
An example of how a receiving ITS-Station deals with messages according to the protocolVersion data element is
shown in Table 3.
ETSI
14 ETSI TS 103 301 V2.3.1 (2026-04)
In the example the Version "V1" is the published version (protocolVersion = 1). Private extensions indicate extensions
that are either not standardized or only recognized in a specific application context, e.g. applications implementing
extensions for usage within local geographical regions. Version "V2" indicates a published, non-backwards compatible
extension (protocolVersion = 2).
It is recommended that all changes to the protocol specification are additions using the ASN.1 extensions mechanism.
These can be:
• Private (non-standardized) extensions: the support for this is limited and its use is discouraged.
• Standardized extensions as part as new version of published standards.
Table 3: Example for handling of messages with different protocol versions
Sending ITS-S Receiving ITS-S Receiving ITS-S
Implemented version of Implemented version of the Decoding result
the protocol protocol
V1 V1 Support of V1
V1 with private extensions V1 Support of V1 and
no support of private extensions
V1 with private extensions V1 with same private extensions as Support of V1 and
the sending ITS-S support of private extensions from the sending
ITS-S
V1 with private extensions V1 with other private extensions as the Support of V1 and
sending ITS-S no support of private extensions from the
sending ITS-S
V1 with private extensions V2 No support of V1 and
no support of private V1 extensions
V2 (V1 with published V1 Support of V1
extensions, included after
the extension mark)
V2 (V1 with published V2 with published extensions Support of V2
extensions, included after
extension mark)
V2 (changes in the data V2 No support of V2
elements, included before
the extension mark)
5 Traffic Light Manoeuvre (TLM) service
5.1 TLM service overview
The TLM service is one instantiation of the infrastructure services to manage the generation, transmission and reception
of SPATEM messages. The TLM service includes safety-related information for supporting traffic participants
(vehicles, pedestrians, etc.) to execute safe manoeuvres in an intersection area. The goal is to enter and exit an
intersection "conflict area" in a controlled way. The TLM service informs in real-time about the operational states of the
traffic light controller, the current signal state, the residual time of the state before changing to the next state, the
allowed manoeuvres and provides assistance for crossing. Additionally the TLM service foresees the inclusion of
detailed green way advisory information and the status for public transport prioritization.
ETSI
15 ETSI TS 103 301 V2.3.1 (2026-04)

Figure 4: Signalling status of the manoeuvres in an intersection
Figure 4 gives an example of the TLM service describing the driving permissions given to the traffic streams. The
connection lanes (see clause 6), which describe the allowed manoeuvre, are highlighted based on the signalling status of
the traffic light controller. The status information (e.g. "stop", "go") transmitted by the traffic controller is depicted in
Figure 4 with red and green connection lines, respectively.
5.2 TLM service
The TLM service instantiated in an ITS-Station shall provide the communication services defined in clause 4.2.
5.3 TLM service message and version
The TLM service uses the message SPATEM as defined in Annex A. The header of SPATEM shall be as specified in
the data dictionary ETSI TS 102 894-2 [2]. The data elements of SPATEM payload shall be as in Annex A.
The protocolVersion (defined in the header) of SPATEM message based on the present document is set to value "2".
5.4 TLM service dissemination
5.4.1 TLM service identification
The TLM service provides real-time information of the traffic light signal phase and timing of an intersection or parts of
an intersection identified by the intersection reference identifie
...