ETSI TS 103 301 V1.1.1 (2016-11)

Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Facilities layer protocols and communication requirements for infrastructure services

DTS/ITS-00166

General Information

• Status: Published
• Publication Date: 09-Nov-2016
• Technical Committee: ITS WG1 - Application Requirements and Services
• Current Stage: 12 - Completion
• Due Date: 28-Oct-2016
• Completion Date: 10-Nov-2016

Standards Content (Sample)

TECHNICAL SPECIFICATION
Intelligent Transport Systems (ITS);
Vehicular Communications;
Basic Set of Applications;
Facilities layer protocols and communication requirements
for infrastructure services
2 ETSI TS 103 301 V1.1.1 (2016-11)

Reference
DTS/ITS-00166
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 - 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/standards-search
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
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
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 2016.
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 TS 103 301 V1.1.1 (2016-11)
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 . 7
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 8
4 Infrastructure services introduction and general requirements . 9
4.1 Naming convention . 9
4.2 Infrastructure services in the ITS communications architecture. 9
4.3 Infrastructure services in the ITS organizational architecture . 10
4.4 Interfaces of the infrastructure services . 11
4.4.1 Interface between Application layer and Facilities layer . 11
4.4.2 Interface between Facilities layer and Management entity . 11
4.4.3 Interface between Facilities layer and Security entity . 11
4.4.4 Interface between Facilities layer and the N&T layer. 12
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 . 12
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 Maneuver (TLM) service . 14
5.1 TLM service overview . 14
5.2 TLM service . 14
5.3 TLM service message and version . 14
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 . 15
5.4.3.1 TLM service communication overview . 15
5.4.3.2 TLM service communication requirements for short range access technologies . 15
5.4.3.3 TLM service communication requirements for long range 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 . 19
6.4.3.1 RLT service communication overview . 19
6.4.3.2 RLT service communication requirements for short range access technologies . 20
6.4.3.3 RLT service dissemination parameters for long range communication . 22
7 Infrastructure to Vehicle Information (IVI) service . 22
7.1 IVI service overview . 22
7.2 IVI service . 22
ETSI
4 ETSI TS 103 301 V1.1.1 (2016-11)
7.3 IVI service message and version . 22
7.4 IVI service dissemination . 23
7.4.1 IVI service identification . 23
7.4.2 IVI service trigger, update, repetition and termination . 23
7.4.3 IVI service communication requirements . 24
7.4.3.1 IVI service communication parameters for short-range communication . 24
7.4.3.2 IVI service dissemination parameters for long-range 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 . 28
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 parameters . 29
8.4.3.1 TLC service service communication overview . 29
8.4.3.2 TLC service communication parameters for short range access technologies . 30
8.4.3.3 TLC service communication parameters for long range communication. 33
9 Basic services running on ITS infrastructure devices . 33
9.1 Basic service overview . 33
9.2 DEN service on ITS infrastructure devices . 33
9.3 CA service on ITS infrastructure devices . 34
10 Communication Parameter Settings . 34
10.1 Overview . 34
10.2 CPS_001 . 34
10.3 CPS_002 . 35
10.4 CPS_003 . 35
10.5 CPS_004 . 36
10.6 CPS_005 . 36
11 Security Profile . 36
Annex A (informative): ASN.1 specification of SPATEM . 37
Annex B (informative): ASN.1 specification of MAPEM . 38
Annex C (informative): ASN.1 specification of IVIM . 39
Annex D (informative): ASN.1 specification of SREM . 40
Annex E (informative): ASN.1 specification of SSEM . 41
History . 42

ETSI
5 ETSI TS 103 301 V1.1.1 (2016-11)
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 (https://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 Technical Specification (TS) has been produced by ETSI Technical Committee Intelligent Transport Systems
(ITS).
The present document includes the integration of infrastructure based application protocols within the ITS message
environment.
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 V1.1.1 (2016-11)
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 to lower layer protocols and 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 at
https://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.
The following referenced documents are necessary for the application of the present document.
[1] ETSI EN 302 665 (V1.1.1): "Intelligent Transport Systems (ITS); Communications Architecture".
[2] ETSI TS 102 894-2 (V1.2.1): "Intelligent Transport Systems (ITS); Users and applications
requirements; Part 2: Applications and facilities layer common data dictionary".
[3] ETSI EN 302 636-4-1 (V1.2.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".
[4] ETSI EN 302 636-5-1 (V1.2.1): "Intelligent Transport Systems (ITS); Vehicular Communications;
GeoNetworking; Part 5: Transport Protocols; Sub-part 1: Basic Transport Protocol".
[5] ETSI EN 302 636-6-1 (V1.2.1): "Intelligent Transport Systems (ITS); Vehicular Communications;
GeoNetworking; Part 6: Internet Integration; Sub-part 1: Transmission of IPv6 Packets over
GeoNetworking Protocols ".
[6] ETSI TS 103 097 (V1.2.1): "Intelligent Transport Systems (ITS); Security; Security header and
certificate formats".
[7] CEN ISO/TS 19321-2015: "Intelligent transport systems - Cooperative ITS - Dictionary of
in-vehicle information (IVI) data structures".
[8] CEN ISO/TS 19091: "Intelligent transport systems - Cooperative ITS - Using V2I and I2V
communications for applications related to signalized intersections".
[9] ETSI EN 302 931 (V1.1.1): "Intelligent Transport Systems (ITS); Vehicular Communications;
Geographical Area Definition".
[10] ISO/TS 17427:2014: "Intelligent transport systems - Cooperative systems - Roles and
responsibilities in the context of cooperative ITS based on architecture(s) for cooperative
systems".
[11] Recommendation ITU-T X.691/ISO/IEC 8825-2 (1997-12): "Information technology - ASN.1
encoding rules: Specification of Packed Encoding Rules (PER)".
[12] ETSI EN 302 637-2 (V1.3.2): "Intelligent Transport Systems (ITS); Vehicular Communications;
Basic Set of Applications; Part 2: Specification of Cooperative Awareness Basic Service".
ETSI
7 ETSI TS 103 301 V1.1.1 (2016-11)
[13] ETSI EN 302 637-3 (V1.2.2): "Intelligent Transport Systems (ITS); Vehicular Communications;
Basic Set of Applications; Part 3: Specifications of Decentralized Environmental Notification
Basic Service".
[14] ISO/TS 17419 (2016-02-09): "ITS-AID-AssignedNumbers".
NOTE: Available at http://standards.iso.org/iso/ts/17419/TS17419%20Assigned%20Numbers/TS17419_ITS-
AID_AssignedNumbers.pdf.
[15] ETSI TS 103 248 (V1.1.1): "Intelligent Transport Systems (ITS); GeoNetworking; Port Numbers
for the Basic Transport Protocol (BTP)".
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 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 TS 102 965 (V1.2.1): "Intelligent Transport Systems (ITS); Application Object Identifier
(ITS-AID); Registration".
[i.2] ISO/TS 17423:2014: "Intelligent Transport Systems - Cooperative Systems - Application
requirements for selection of communication profiles".
[i.3] ISO/TS 14823: "Traffic and travel information - Messages via media independent stationary
dissemination systems - Graphic data dictionary for pre-trip and in-trip information dissemination
systems".
TM
[i.4] IEEE 802.11 -2012: "IEEE Standard for Information technology - Telecommunications and
information exchange between systems - Local and metropolitan area networks-Specific
requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications".
[i.5] IETF draft-lonc-tls-certieee1609-01.txt: "Transport Layer Security (TLS) Authentication using
ITS ETSI and IEEE certificates".
[i.6] ETSI TS 102 723-5 (V1.1.1): "Intelligent Transport Systems (ITS); OSI cross-layer topics; Part 5:
Interface between management entity and facilities layer".
[i.7] IANA Service Name and Transport Protocol Port Number Registry (2016-04-07).
NOTE: Available at https://www.iana.org/assignments/service-names-port-numbers/service-names-port-
numbers.txt.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
destination area: geographic area in which a message is disseminated
NOTE: The definition is compliant to ETSI EN 302 637-3 [13].
ETSI
8 ETSI TS 103 301 V1.1.1 (2016-11)
driver awareness zone: area in which the driver will be informed about upcoming situations
NOTE: The definition is compliant to CEN ISO/TS 19321 [7].
ITS-G5: access technology to be used in frequency bands dedicated for European intelligent transport System (ITS)
long range: communication with coverage of more than 500 m (e.g. cellular systems)
MAPEM: road/lane topology and traffic maneuver message
NOTE: As defined in Annex B including the corresponding extensions defined in CEN ISO/TS 19091 [8].
minimum dissemination area: minimum area where an information is disseminated by an ITS-S based on application
requirements
NOTE: The definition is compliant to CEN ISO/TS 19321 [7].
relevance zone: area where the information is applicable
NOTE: The definition is compliant to CEN ISO/TS 19321 [7].
short range: communication with coverage of approximately 500 m (e.g. WiFi)
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ADU Application Data Unit
AID Action IDentifier
ASN Anstract Syntax Notation
BTP Basic Transport Protocol
CA Certification Authority
C-ITS Cooperative ITS
C-ITS-S Cooperative ITS-S
DAZ Driver Awareness Zone
DE Data Element
DEN Decentralized Environmental Notification
DENM DEN Message
GBC GeoBroadCast
GN GeoNetworking
GPCH General Purpose CHannel
IANA Internet Assigned Numbers Authority
IP Internet Protocol
ITIS International Traveler Information Systems
ITS Intelligent Transport System
ITS-AID ITS-Application IDentifier
ITS-S ITS Station
ITU-T International Telecommunication Union - Telecommunication
IVI Infrastructure to Vehicle Information
IVIM Infrastructure to Vehicle Information Message
MAPEM MAP (topology) Extended Message
MDA Minimum Dissemination Area
MF-SAP Management Facilities layer SAP
MSB Most Significant Bit
MTU Maximum Transmit Unit
PDU Protocol Data Unit
PER Packet Encoding Rule
R-ITS-S Roadside ITS Station
RLT Road and Lane Topology
RZ Relevance Zone
SAP Service Access Primitive
SCH Service CHannel
SHB Single Hop Broadcast
ETSI
9 ETSI TS 103 301 V1.1.1 (2016-11)
SPATEM Signal Phase And Timing Extended Message
SREM Signal Request Extended Message
SSEM Signal request Status Extended Message
SSP Service Specific Permissions
TCC Traffic Control Center
TLC Traffic Light Control
TLM Traffic Light Maneuver
TSB Topological Scope Broadcast
UDP User Datagram Protocol
V-ITS-S Vehicular and personal ITS Station
WLAN Wireless Local Area Network
4 Infrastructure services introduction and general
requirements
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 (ETSI TS 102 894-2 [2]) with the
payload, in order to construct a message. The message is then delivered to the Networking & Transport layer with a set
of communication parameters.
NOTE: In other standards referred by the present document, the term message, payload, data structure may have
different meanings e.g. in CEN ISO/TS 19091 [8] and in CEN ISO/TS 19321 [7]. Therefore, the current
convention is defined for clarification purpose.
4.2 Infrastructure services in the ITS communications
architecture
The infrastructure services refer to Facilities layer entities that manage the generation, transmission and reception of
infrastructure-related messages from the infrastructure (C-ITS-S or R-ITS-S) to V-ITS-S or vice-versa. Figure 1
illustrates a high level functional architecture of the infrastructure services within the ITS communication architecture,
as specified in ETSI EN 302 665 [1]. The messages are Facilities layer PDUs that are exchanged among ITS-Ss. The
payload is generated by ITS applications in the transmitting ITS-S or other connected ITS-S (e.g. a C-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 an
R-ITS-S and disseminated to V-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 Maneuver" -
TLM service in the present document. TLM service is specified in clause 5 of the present document.
• MAPEM as defined in Annex B. 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.
• IVIM as defined in Annex C. 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.
ETSI
10 ETSI TS 103 301 V1.1.1 (2016-11)
• SREM as specified in Annex D. 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 E. 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 within the ITS-S architecture
The infrastructure service shall provide at least the following functions.
For the transmission service:
• Message encoding.
• Transmission management.
For the reception service:
• Message decoding.
• Reception management.
4.3 Infrastructure services in the ITS organizational architecture
Within the role "System Operation" as defined in ISO/TS 17427 [10], 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.
ETSI
11 ETSI TS 103 301 V1.1.1 (2016-11)

Figure 2: Identification of sub-roles of the role system (lifecycle)
operation in the ITS organizational architecture
4.4 Interfaces of the infrastructure services
4.4.1 Interface between Application layer and Facilities layer
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 Facilities control Information (SAP primitives) contained in an application request.
Table 1: Facilities control information (SAP primitives)
Category Data Definition
Infrastructure Identification of the message
message
identification
Data passed from
Request type Trigger, update or ending of transmission
application to
Dissemination For more details see the dissemination profile for each service in the
infrastructure
parameter clauses 5 to 8
services
Traffic class GN traffic class as defined in ETSI EN 302 636-4-1 [3], if
GeoNetworking/BTP is used
Payload Information contained in payload
actionID or The infrastructure service returns the message identification or other
Data returned from
other applicable applicable identifier created by the infrastructure service to the requesting
I2V service to the
identifier application
requesting
Failure notification The infrastructure service returns a failure notification to the requesting
application
application
4.4.2 Interface between Facilities layer and Management entity
The infrastructure services may exchange information with the Management entity. This includes the default service
communication parameters specified in clauses 5 to 8. The interface MF-SAP may be realized as the MF-SAP ETSI
TS 102 723-5 [i.6].
4.4.3 Interface between Facilities layer and Security entity
The infrastructure service may exchange information with the Security entity.
ETSI
12 ETSI TS 103 301 V1.1.1 (2016-11)
4.4.4 Interface between Facilities layer and the N&T layer
The infrastructure services deliver the message as payload to the Networking & Transport Layer for dissemination via
the NF-SAP.
The Networking & Transport Layer indicates the reception of an ITS message to the infrastructure services.
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].
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.1] indicates the overall type of permissions being
granted.
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: No version, length 1 octet; the value shall only be used for testing purposes.
1: First version, SSP contains information as defined in the present document.
2 to 255: Reserved for future usage.
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 the Annexes A to E.
ETSI
13 ETSI TS 103 301 V1.1.1 (2016-11)
4.5.3 Message encoding scheme
Unless specified otherwise, the Unaligned PER encoding scheme as specified in Recommendation ITU-T X.691 [11]
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 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
extnsions) 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 2.
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 2: 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
Support of V1 and
V1 with private extensions V1
no support of private extensions
Support of V1 and
V1 with same private extensions as
V1 with private extensions and support of private extensions from the
the sending ITS-S
sending ITS-S
Support of V1 and
V1 with other private extensions as the
V1 with private extensions no support of private extensions from the
sending ITS-S
sending ITS-S
No support of V1 and
V1 with private extensions V2
no support of private V1 extensions
V2 (V1 with published
extensions, included after V1 Support of V1
the extension mark)
V2 (V1 with published
extensions, included after V2 with published extensions Support of V2
extension mark)
V2 (changes in the data
elements, included before V2 No support of V2
the extension mark)
ETSI
14 ETSI TS 103 301 V1.1.1 (2016-11)
5 Traffic Light Maneuver (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 maneuvers 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 maneuvers 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.

Figure 3: Signaling status of the maneuvers in an intersection
Figure 3 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 maneuver, are highlighted based on the signaling status of
the traffic light controller. The status information (e.g. "stop", "go") transmitted by the traffic controller is depicted in
Figure 3 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 specified in CEN
ISO/TS 19091 [8].
The protocolVersion (defined in the header) of SPATEM message based on the present document is set to value "1".
ETSI
15 ETSI TS 103 301 V1.1.1 (2016-11)
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 identifier. The timestamp indicates the order of messages within
the given time system as defined in CEN ISO/TS 19091 [8]. There is no additional identifier needed to distinguish a
SPATEM from a previous one.
5.4.2 TLM service trigger, update, repetition and termination
The application triggers the TLM service for the transmission of SPATEM. The application provides all data content
included in a SPATEM payload. The TLM service constructs a SPATEM and delivers it to the Networking & Transport
Layer for dissemination. The SPATEM is not repeated.
The TLM service shall be terminated, if the ITS-S application requests the termination.
5.4.3 TLM service communication requirements
5.4.3.1 TLM service communication overview
The TLM service uses SPATEM to disseminate the status of the traffic light controller, traffic lights and intersection
traffic information. It transmits continuously in real-time the information relevant for all maneuvers in the of an
intersection. The goal is to address all traffic participants using the intersection for travel or cross walking. Due to
different equipment of end users, the SPATEM may be disseminated using different access technologies for short range
or for long range communication.
5.4.3.2 TLM service communication requirements for short range access
technologies
For short range broadcast communication different access technologies are applicable for dissemination of SPATEM as
follows:
• Short range communication data transmission using ITS-G5 broadcast transmission.
• WiFi communication.
In case the GN protocol and the GBC is used, the TLM service shall provide the destination area in the format
compliant to ETSI EN 302 931 [9] and to the ITS networking & transport layer.
Table 3 provides the requirements for the broadcast communication. The structure of the requirements is in accordance
with ISO/TS 17423 [i.2].
The ITS station management uses the communication requirements to select suitable ITS-S communication protocol
stacks. Some examples of communicati
...