ETSI TS 103 900 V2.1.

1 (2023-11)

TECHNICAL SPECIFICATION

Intelligent Transport Systems (ITS);

Vehicular Communications;
Basic Set of Applications;
Cooperative Awareness Service;
Release 2
 2 ETSI TS 103 900 V2.1.1 (2023-11)

Reference
RTS/ITS-001966

Keywords
application, ITS, safety, service, transport

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 - 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:
https://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 prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
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
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure

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 2023.
All rights reserved.

ETSI
 3 ETSI TS 103 900 V2.1.1 (2023-11)

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 Definition of terms, symbols and abbreviations .......................................................................................8
3.1 Terms.................................................................................................................................................................. 8
3.2 Symbols .............................................................................................................................................................. 9
3.3 Abbreviations ..................................................................................................................................................... 9
4 CA service introduction..........................................................................................................................10
4.1 Background ...................................................................................................................................................... 10
4.2 Services provided by CA service ..................................................................................................................... 10
4.3 Sending CAMs ................................................................................................................................................. 10
4.4 Receiving CAMs .............................................................................................................................................. 11
5 CA service functional specification .......................................................................................................11
5.1 CA service in the ITS architecture ................................................................................................................... 11
5.2 CA service functional architecture ................................................................................................................... 11
5.3 Interfaces of the CA service ............................................................................................................................. 12
5.3.1 Interface to ITS application layer ............................................................................................................... 12
5.3.2 Interface to data provisioning facilities ....................................................................................................... 13
5.3.3 Interface to the networking & transport layer ............................................................................................. 13
5.3.4 Interfaces protocol stacks of the networking & transport layer .................................................................. 13
5.3.4.1 Interface to the GeoNetworking/BTP stack .......................................................................................... 13
5.3.4.2 Interface to the IPv6 stack and the combined IPv6/GeoNetworking stack ........................................... 15
5.3.5 Interface to the Management entity ............................................................................................................ 15
5.3.6 Interface to the Security entity .................................................................................................................... 15
6 CAM dissemination................................................................................................................................15
6.1 CAM dissemination concept ............................................................................................................................ 15
6.1.1 CA service activation and termination ........................................................................................................ 15
6.1.2 CAM generation frequency management for vehicle ITS-Ss ..................................................................... 15
6.1.3 CAM generation frequency management for RSU ITS-Ss ......................................................................... 17
6.1.4 CAM time requirement ............................................................................................................................... 17
6.1.4.1 CAM generation time ............................................................................................................................ 17
6.1.4.2 CAM Time stamp .................................................................................................................................. 17
6.2 CAM dissemination constraints ....................................................................................................................... 17
6.2.1 General Confidence Constraints ................................................................................................................. 17
6.2.2 Security constraints ..................................................................................................................................... 17
6.2.2.1 Introduction ........................................................................................................................................... 17
6.2.2.2 Service Specific Permissions (SSP) ...................................................................................................... 18
6.2.3 General priority constraints......................................................................................................................... 19
7 CAM Format Specification ....................................................................................................................19
7.1 General structure of a CAM PDU .................................................................................................................... 19
7.2 ITS PDU header ............................................................................................................................................... 20
7.3 Basic container ................................................................................................................................................. 20
7.4 Vehicle ITS-S containers .................................................................................................................................. 20
7.5 RSU ITS-S containers ...................................................................................................................................... 21
7.6 CAM format and coding rules .......................................................................................................................... 21
7.6.1 Common data dictionary ............................................................................................................................. 21
7.6.2 CAM data presentation ............................................................................................................................... 21

ETSI
 4 ETSI TS 103 900 V2.1.1 (2023-11)

Annex A (normative): ASN.1 specification of CAM syntax .............................................................22

Annex B (informative): Specification of CAM PDU components ......................................................23
Annex C (informative): Protocol operation of the CA service ...........................................................24
C.1 Introduction ............................................................................................................................................24
C.2 Originating ITS-S operation ...................................................................................................................24
C.2.1 Protocol data setting rules ................................................................................................................................ 24
C.2.2 T_CheckCamGen ............................................................................................................................................. 24
C.2.3 Originating ITS-S message table ...................................................................................................................... 24
C.2.4 General protocol operation ............................................................................................................................... 25
C.2.5 CAM construction exception ............................................................................................................................ 25
C.3 Receiving ITS-S operation .....................................................................................................................25
C.3.1 Protocol data setting rules ................................................................................................................................ 25
C.3.2 General protocol operation ............................................................................................................................... 25
C.3.3 Exception handling ........................................................................................................................................... 26
C.3.3.1 CAM decoding exception ........................................................................................................................... 26

Annex D (informative): Flow chart for CAM generation frequency management ..........................27
Annex E (informative): Extended CAM generation ...........................................................................31
History ..............................................................................................................................................................32

ETSI
 5 ETSI TS 103 900 V2.1.1 (2023-11)

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 Web server (https://ipr.etsi.org/).

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™ and LTE™ 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
Cooperative awareness within road traffic means that road users and roadside infrastructure are informed about each
other's position, dynamics and attributes. Road users are all kind of road vehicles like cars, trucks, motorcycles, bicycles
or even pedestrians and roadside infrastructure equipment including road signs, traffic lights or barriers and gates. The
awareness of each other is the basis for several road safety and traffic efficiency applications with many use cases, for
example as described in ETSI TR 102 638 [i.1]. It is achieved by regular exchange of information among vehicles
(V2V, in general all kind of road users) and between vehicles and road side infrastructure (V2I and I2V) based on
wireless networks, called V2X network and as such is part of Intelligent Transport Systems (ITS).

The information to be exchanged for cooperative awareness is packed up in the periodically transmitted Cooperative
Awareness Message (CAM). The construction, management and processing of CAMs is done by the Cooperative
Awareness service (CA service), which is part of the facilities layer within the ITS communication architecture ETSI
TS 103 898 [i.2] supporting several ITS applications.

ETSI
 6 ETSI TS 103 900 V2.1.1 (2023-11)

The CA service is a mandatory facility for all kind of ITS-Stations (ITS-S), which take part in the road traffic (vehicle
ITS-S, personal ITS-S, etc.). The present document focuses on the specifications for CAMs transmitted by all vehicle
ITS-Ss participating in the V2X network. Nevertheless, the present document defines the CAM format with flexibility
in order to be easily extendable for the support of other types of ITS-Ss or future ITS applications.

The requirements on the performance of the CA service, the content of the CAM and the quality of its data elements are
derived from the Basic Set of Applications (BSA) as defined in ETSI TR 102 638 [i.1] and in particular from the road
safety applications as defined in the C2C-CC Basic System Profile [i.3] and the C-Roads Release [i.5]. Further use
cases are specified in the C2C-CC Roadmap [i.4].

The Release 1 edition of the CA service has been published as ETSI EN 302 637-2 [i.6]. The present document is the
first Release 2 version and provides the improved specification of the Release 1 version as a basis for future Release 2
versions of the CA service: future versions of the present document will specify extensions to the CAM Release 2
format to support use cases based on BSA in a way allowing the facilities layer standard to be used with different
security and lower layer technologies.

To ensure backward compatibility, all future CA service Release 2 versions will be based on this first CA service
Release 2 version. Further it will be ensured that the Release 1 implementations can receive and decode Release 2 CAM
and utilize the Release 1 content without the need to understand the Release 2 content.

ETSI
 7 ETSI TS 103 900 V2.1.1 (2023-11)

1 Scope
The present document provides the specification of the Release 2 Cooperative Awareness (CA) service.

This includes definition of the syntax and semantics of the Cooperative Awareness Message (CAM) and detailed
specifications on the message handling.

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 TS 102 894-2: "Intelligent Transport Systems (ITS); Users and applications requirements;
Part 2: Applications and facilities layer common data dictionary; Release 2".

[2] Recommendation ITU-T X.691/ISO/IEC 8825-2 (02/2021): "Information technology -- ASN.1

encoding rules: Specification of Packed Encoding Rules (PER)".

[3] ETSI TS 103 097: "Intelligent Transport Systems (ITS); Security; Security header and certificate
formats; Release 2".

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 TR 102 638: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of
Applications; Definitions".

[i.2] ETSI TS 103 898 (2.0.0): "Intelligent Transport Systems (ITS); Communications Architecture;
Release 2".

[i.3] Car2Car Communication Consortium: "Basic System Profile".

[i.4] Car2Car Communication Consortium: "Guidance for day 2 and beyond roadmap".

[i.5] C-Roads: "The C-Roads Platform publishes harmonised C-ITS specifications for Europe".

[i.6] ETSI EN 302 637-2 (V1.4.1): "Intelligent Transport Systems (ITS); Vehicular Communications;
Basic Set of Applications; Part 2: Specification of Cooperative Awareness Basic Service".

ETSI
 8 ETSI TS 103 900 V2.1.1 (2023-11)

[i.7] ETSI TS 103 938 (V2.0.0): "Intelligent Transport Systems (ITS); Vehicular Communications;
Basic Set of Applications; Local Dynamic Map (LDM); Release 2".

[i.8] ISO 1176: "Road vehicles - Masses - Vocabulary and codes".

[i.9] ETSI EN 302 663 (V1.3.1): "Intelligent Transport Systems (ITS); ITS-G5 Access layer
specification for Intelligent Transport Systems operating in the 5 GHz frequency band".

[i.10] ETSI TS 103 613 (V1.1.1): "Intelligent Transport Systems (ITS); Access layer specification for
Intelligent Transport Systems using LTE Vehicle to everything communication in the 5,9 GHz
frequency band".

[i.11] ETSI TS 102 894-1 (V2.0.0): "Intelligent Transport Systems (ITS); Users and applications
requirements; Part 1: Facility layer structure, functional requirements and specifications;
Release 2".

[i.12] ETSI TS 103 831 (V2.1.1): "Intelligent Transport Systems (ITS); Vehicular Communications;
Basic Set of Applications; Decentralized Environmental Notification Service; Release 2".

[i.13] ETSI TS 103 836-4-1 (V2.1.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.14] ETSI TS 103 301 (V2.1.1): "Intelligent Transport Systems (ITS); Vehicular Communications;
Basic Set of Applications; Facilities layer protocols and communication requirements for
infrastructure services; Release 2".

[i.15] ETSI TS 103 836-5-1 (V2.0.0): "Intelligent Transport Systems (ITS); Vehicular Communications;
GeoNetworking; Part 5: Transport Protocols; Sub-part 1: Basic Transport Protocol; Release 2".

[i.16] ISO 17419: "Intelligent Transport Systems - Cooperative Systems - Classification and
management of ITS applications in a global context".

[i.17] ETSI TS 103 836-3 (V2.0.0): "Intelligent Transport Systems (ITS); Vehicular Communications;
GeoNetworking; Part 3: Network Architecture; Release 2".

[i.18] ETSI TS 102 724 (V1.1.1): "Intelligent Transport Systems (ITS); Harmonized Channel
Specifications for Intelligent Transport Systems operating in the 5 GHz frequency band".

[i.19] ETSI TS 102 965 (V2.1.1): "Intelligent Transport Systems (ITS);Application Object Identifier
(ITS-AID); Registration; Release 2".

[i.20] ETSI TS 103 574 (V2.0.0): "Intelligent Transport Systems (ITS); Congestion Control Mechanisms
for C-V2X PC5 interface; Access layer part; Release 2".

[i.21] ETSI TS 102 940 (V2.1.1): "Intelligent Transport Systems (ITS); Security; ITS communications
security architecture and security management; Release 2".

[i.22] ETSI EN 302 636-5-1 (V2.2.1): "Intelligent Transport Systems (ITS); Vehicular Communications;
GeoNetworking; Part 5: Transport Protocols; Sub-part 1: Basic Transport Protocol".

3 Definition of terms, symbols and abbreviations

3.1 Terms
For the purposes of the present document, the terms given in ETSI TS 103 898 [i.2], LDM given in ETSI
TS 103 938 [i.7] and the following apply:

Basic Set of Applications: group of applications, supported by vehicular communication system

NOTE: The basic set of applications is defined in ETSI TR 102 638 [i.1].

Cooperative Awareness (CA) service: facility at the ITS-S facilities layer to generate, receive and process the CAM

ETSI
 9 ETSI TS 103 900 V2.1.1 (2023-11)

Cooperative Awareness Message (CAM): CA service PDU

Cooperative Awareness Message (CAM) data: partial or complete CAM payload

Cooperative Awareness Message (CAM) protocol: ITS facilities layer protocol that operates the CAM transmission
and reception

empty vehicle: complete vehicle kerb mass as defined in ISO 1176 [i.8], clause 4.6

ITS-G5: access technology to be used in frequency bands dedicated for European intelligent transport System (ITS) as
defined in ETSI EN 302 663 [i.9]

LTE-V2X: access technology to be used in frequency bands dedicated for European intelligent transport System (ITS)
as defined in ETSI TS 103 613 [i.10]

V2X: vehicle to everything, e.g. Vehicle to Vehicle (V2V), Vehicle to Infrastructure (V2I) and/or Infrastructure to
Vehicle (I2V), Vehicle to Pedestrian (V2P) and/or Pedestrian to Vehicle (P2V), and Vehicle to Network (V2N) and/or
Network to Vehicle (N2V)

3.2 Symbols
For the purposes of the present document, the following symbols apply:

IF.CAM Interface between CAM service and LDM or ITS application

IF.FAC Interface between CAM service and other facilities layer entities
IF.N&T Interface between CAM service and ITS networking & transport layer
IF.SEC Interface between CAM service and ITS security entity

3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:

API Application Programming Interface

ASN.1 Abstract Syntax Notation 1
BSA Basic Set of Applications
BTP Basic Transport Protocol
C2C-CC Car to Car Communication Consortium
CA Cooperative Awareness
CAM Cooperative Awareness Message
DCC Decentralized Congestion Control
DDP Device Data Provider
DE Data Element
DENM Decentralized Environmental Notification Message
DF Data Frame
DTLS Datagram Transport Layer Security
FL-SDU Facility Layer Service Data Unit
GN GeoNetworking
HF High Frequency
HMI Human Machine Interface
I2V Infrastructure-to-Vehicle
ID IDentifier
ISO International Organization for Standardization
ITS Intelligent Transport Systems
ITS-AID ITS-Application IDentifier
ITS-S ITS Station
ITU-T International Telecommunication Union - Telecommunications
LDM Local Dynamic Map
LF Low Frequency
LTE Long Term Evolution
MIB Management Information Base
MSB Most Significant Bit

ETSI
 10 ETSI TS 103 900 V2.1.1 (2023-11)

N&T Networking & Transport layer

OID Object Identifier
PCI Protocol Control Information
PDU Packet Data Unit
PER Packed Encoding Rules
POTI Position and Time management
RSU Road Side Unit
SHA Secure Hash Algorithm
SHB Single-Hop Broadcasting
SSP Service Specific Permissions
TLS Transport Layer Security
TR Technical Report
TS Technical Specification
V2I Vehicle-to-Infrastructure
V2N Vehicle-to-Network
V2V Vehicle-to-Vehicle
V2X Vehicle-to-Everything
VPN Virtual Private Network

4 CA service introduction

4.1 Background
Cooperative Awareness Messages (CAMs) are messages exchanged in the ITS network between ITS-Ss to create and
maintain awareness of each other and to support cooperative performance of vehicles using the road network. A CAM
contains status and attribute information of the originating ITS-S. The content varies depending on the type of the
ITS-S. For vehicle ITS-Ss the status information includes time, position, motion state, activated systems, etc. and the
attribute information includes data about the dimensions, vehicle type and role in the road traffic, etc. On reception of a
CAM the receiving ITS-S becomes aware of the presence, type, and status of the originating ITS-S. The received
information can be used by the receiving ITS-S to support several ITS applications. For example, by comparing the
status of the originating ITS-S with its own status, a receiving ITS-S is able to estimate the collision risk with the
originating ITS-S and if necessary may inform the driver of the vehicle via HMI or in-vehicle system. Multiple ITS
applications may rely on the CA service. It is assigned to domain application support facilities in ETSI
TS 102 894-1 [i.11].

Besides the support of applications the awareness of other ITS-S gained by the CA service may be used in the
networking & transport layer for the position dependent dissemination of messages, e.g. DENM [i.12] by
GeoBroadcasting as specified in ETSI TS 103 836-4-1 [i.13]. The generation and transmission of CAM is managed by
the CA service by implementing the CAM protocol.

4.2 Services provided by CA service

The CA service is a facilities layer entity that operates the CAM protocol. It provides two services: sending and
receiving of CAMs. The CA service uses the services provided by the protocol entities of the ITS networking &
transport layer to disseminate the CAM.

4.3 Sending CAMs

The sending of CAMs comprises the generation and transmission of CAMs. In the course of CAM generation the
originating ITS-S composes the CAM, which is then delivered to the ITS networking & transport layer for
dissemination. The dissemination of CAMs may vary depending on the applied communication system. CAMs may be
sent by the originating ITS-S to all ITS-Ss within the direct communication range. This communication range may, inter
alia, be influenced in the originating ITS-S by changing the transmit power.

CAMs are generated periodically with a frequency controlled by the CA service in the originating ITS-S. The
generation frequency is determined taking into account the change of own ITS-Ss status, e.g. change of position or
speed as well as the radio channel load.

ETSI
 11 ETSI TS 103 900 V2.1.1 (2023-11)

4.4 Receiving CAMs

Upon receiving a CAM, the CA service makes the content of the CAM available to the ITS applications and/or to other
facilities within the receiving ITS-S, such as a Local Dynamic Map (LDM) [i.7].

5 CA service functional specification

5.1 CA service in the ITS architecture

The CA service is a facilities layer entity of the ITS-S architecture as defined in ETSI TS 103 898 [i.2]. It may interface
with other entities of the facilities layer and with the ITS application layer in order to collect relevant information for
CAM generation and to forward the received CAM content for further processing. The CA service within the ITS-S
architecture and the logical interfaces to other layers and potentially to entities within the facility layer are presented in
Figure 1.

In ITS-S, entities for the collection of data may be the Device Data Provider (DDP) and the Position and Time
management (POTI) and for received data the Local Dynamic Map (LDM) and/or ITS application as receiving entities.
For vehicle ITS-S, the DDP is connected with the vehicle network and provides the vehicle status information. The
POTI , provides the position of the ITS-S and time information. The LDM as outlined in ETSI TS 103 938 [i.7] is a
database in the ITS-S, which may be updated with received CAM data. ITS applications may retrieve information from
the LDM for further processing.

The CA service interfaces through the IF-N&T with the Networking & Transport (N&T) layer for exchanging of
CAMs with other ITS-Ss, the IF-Sec with the security entity to access security services for CAM transmission and
CAM reception, the IF-Mng with the management entity and the IF-App with the application layer if received CAM
data are provided directly to the applications.

The operation of the CA service on ITS infrastructure devices is specified in ETSI TS 103 301 [i.14].

The functionalities of the CA service are defined in clause 5.2, the interfaces in Figure 2 are defined in clause 5.3.

Figure 1: CA service within the ITS-S architecture

5.2 CA service functional architecture

The CA service is part of the Application support domain of the facilities layer according to ETSI TS 102 894-1 [i.11].
Figure 2 shows the functional block diagram with the functional blocks of the CA service and interfaces to other
facilities and layers, which are detailed in the following. The interfaces to other entities and layers are defined in
clause 5.3.

ETSI
 12 ETSI TS 103 900 V2.1.1 (2023-11)

Figure 2: Functional block diagram of the CA service

For sending and receiving CAMs, the CA service shall provide the following sub-functions:

• Encode CAM:

- This sub-function constructs the CAM according to the format specified in annex A. The most recent
device data shall be included in CAM.

• Decode CAM:

- This sub-function decodes the received CAMs.

• CAM transmission management:

- This sub-function implements the protocol operation of the originating ITS-S, as specified in clause C.2,
including in particular:

 Activation and termination of CAM transmission operation.

 Determination of the CAM generation frequency.

 Trigger the generation of CAM.

• CAM reception management:

- This sub-function implements the protocol operation of the receiving ITS-S, as specified in clause C.3,
including in particular:

 Trigger the "decode CAM" function at the reception of CAM.

 Provision of the received CAM data to LDM and/or ITS applications of the receiving ITS-S.

 Optionally, checking the information of received CAMs.

5.3 Interfaces of the CA service

5.3.1 Interface to ITS application layer
An ITS application is an application layer entity that implements the logic for fulfilling one or more ITS use cases.
Example ITS applications are defined in the C2C-CC Basic System Profile [i.3], the C2C-CC Roadmap [i.4] and the
C-Roads Release [i.5].

For the provision of received data the CA service provides the interface IF.CAM to LDM or to ITS application layer, as
illustrated in Figure 2.

ETSI
 13 ETSI TS 103 900 V2.1.1 (2023-11)

NOTE: The interface to the ITS application layer may be implemented as API and data are exchanged between
the CA service and ITS applications via this API. In another possible implementation, the interface to the
application layer may be implemented as IF-App.

5.3.2 Interface to data provisioning facilities

For the generation of CAMs, the CA service interacts with other facilities layer entities in order to obtain the required
data. This set of facilities that provides data for CAM generation is referred to as data provisioning facilities. Data are
exchanged between the data provisioning facilities and the CA service via the interface IF.FAC.

NOTE: Specifications of the interface to the data provisioning facilities and the corresponding protocols are out
of scope of the present document.

5.3.3 Interface to the networking & transport layer

The CA service exchanges information with ITS networking & transport layer via the interface IF.N&T as depicted in
Figure 2.

At the originating ITS-S, the CA service shall provide the CAM embedded in a Facility-Layer Service Data Unit
(FL-SDU) together with Protocol Control Information (PCI) to the ITS networking & transport layer. At the receiving
ITS-S, the ITS networking & transport layer will pass the received CAM to the CA service, if available.

The minimum data set that shall be passed between CA service and ITS networking & transport layer for the originating
and receiving ITS-S is specified in Table 1.

Table 1: Data passed between CA service and the ITS networking & transport layer
Category Data Data requirement Mandatory/Optional
Data passed from CAM {cam} as specified in annex A Mandatory
the CA service to
the ITS networking
& transport layer
PCI Depending on the protocol stack applied in the Optional
networking and transport layer as specified in
clause 5.3.4
Data passed from Received CAM {cam} as specified in annex A Mandatory
the ITS networking
& transport layer to
the CA service

The interface between the CA service and the networking & transport layer relies on the services of the
GeoNetworking/BTP stack as specified in clause 5.3.4.1 or to the IPv6 stack and the combined IPv6/GeoNetworking
stack as specified in clause 5.3.4.2.

5.3.4 Interfaces protocol stacks of the networking & transport layer

5.3.4.1 Interface to the GeoNetworking/BTP stack

A CAM may rely on the services provided by the GeoNetworking/BTP stack. If this stack is used, the GN packet
transport type Single-Hop Broadcasting (SHB) shall be used. In this scenario only nodes in direct communication range
may receive the CAM.

PCI being passed from CA service to the GeoNetworking/BTP stack shall comply with Table 1 and Table 2.

ETSI
 14 ETSI TS 103 900 V2.1.1 (2023-11)

Table 2: PCI from CA service to GeoNetworking/BTP

at the originating ITS-S
Category Data Data requirement Mandatory/Conditional
Data passed from BTP type BTP header type B Conditional
the CA service to (ETSI EN 302 636-5-1 [i.22], The data shall be passed if the
GeoNetworking/BTP clause 7.2.2) value is not provided by the ITS-S
configuration, e.g. defined in a
Management Information Base
(MIB) or if the value is different
from the default value as set in
the MIB.
Destination port As specified in Conditional
ETSI TS 103 836-5-1 [i.15] The data shall be passed if the
(see note) value is not provided by the ITS-S
configuration, e.g. defined in a
Management Information Base
(MIB) or if the value is different
from the default value as set in
the MIB.
Destination port info As specified in Conditional
ETSI TS 103 836-5-1 [i.15] The data shall be passed if the
value is not provided by the ITS-S
configuration, e.g. defined in a
Management Information Base
(MIB) or if the value is different
from the default value as set in
the MIB.
GN Packet transport type GeoNetworking SHB Conditional
The data shall be passed if the
value is not provided by the ITS-S
configuration, e.g. defined in a
Management Information Base
(MIB) or if the value is different
from the default value as set in
the MIB.
GN Communication profile Unspecified, ITS-G5, or Conditional
LTE-V2X The data shall be passed if the
value is not provided by the ITS-S
configuration, e.g. defined in a
Management Information Base
(MIB) or if the value is different
from the default value as set in
the MIB.
GN Security profile SECURED or UNSECURED Conditional
The data shall be passed if the
value is not provided by the ITS-S
configuration, e.g. defined in a
Management Information Base
(MIB) or if the value is different
from the default value as set in
the MIB.
GN Traffic Class As defined in Mandatory.
ETSI TS 103 836-4-1 [i.13]
GN Maximum packet Shall not exceed 1 000 ms Mandatory.
lifetime
Length Length of the CAM Mandatory.
NOTE: When a global registration authority for ITS application as specified in ISO 17419 [i.16] is operational, the
BTP destination port registered with this authority shall be used.

ETSI
 15 ETSI TS 103 900 V2.1.1 (2023-11)

5.3.4.2 Interface to the IPv6 stack and the combined IPv6/GeoNetworking stack
A CAM may use the IPv6 stack or the combined IPv6/GeoNetworking stack for CAM dissemination as specified in
ETSI TS 103 836-3 [i.17].

NOTE 1: When the CAM dissemination makes use of the combined IPv6/GeoNetworking stack, the interface
between the CA service and the combined IPv6/GeoNetworking stack may be identical to the interface
between the CA service and IPv6 stack. The transmission of CAM over the IPv6 stack is out of scope of
the present document.

NOTE 2: If IP-based transport is used to transfer the facility layer CAM between interconnected actors, security
constraints as outlined in Clause 6.2.2 may not be applicable. In this case trust among the participating
actors, e.g. using mutual authentication, and authenticity of information can be based on other standard IT
security methods, such as IPSec, DTLS, TLS or other VPN solutions that provide an end-to-end secure
communication path between known actors.

NOTE 3: Security methods, sharing methods and other transport related information, such as messaging queuing
protocols, transport layer protocol, ports to use etc. can be agreed among interconnected actors.

5.3.5 Interface to the Management entity

The CA service may exchange primitives with management entity of the ITS-S via the IF.Mng interface as depicted in
Figure 1. In case of the ITS-G5 access layer, an originating ITS-S the CA service gets information for setting the
T_GenCam_DCC from the management entity defined in clause 6.1.2 via the IF.Mng interface, as depicted in Figure 2.

NOTE: Specifications of the IF.Mng and the corresponding protocol are out of scope of the present document.

5.3.6 Interface to the Security entity

The CA service may exchange primitives with the Security entity of the ITS-S via the IF-Sec interface as depicted in
Figure 1 using the IF.Sec interface provided by the Security entity as depicted in Figure 2.

NOTE: Specifications of the IF-Sec and the corresponding protocol are out of the scope of the present document.

6 CAM dissemination

6.1 CAM dissemination concept

6.1.1 CA service activation and termination
CA service activation may vary for different types of ITS-S, e.g. vehicle ITS-S, road side ITS-S, personal ITS-S. As
long as the CA service is active, the CAM generation shall be triggered and managed by the CA service.

6.1.2 CAM generation frequency management for vehicle ITS-Ss

The CAM generation frequency is managed by the CA service; it defines the time interval between two consecutive
CAM generations.

Considering the requirements as specified in the C2C-CC Basic System Profile [i.3], the C2C-CC Roadmap [i.4] and
the C-Roads Release [i.5]. The upper and lower limits of the transmission interval are set as follows:

• The CAM generation interval shall not be inferior to T_GenCamMin = 100 ms. This corresponds to the CAM
generation rate of 10 Hz.

• The CAM generation interval shall not be superior to T_GenCamMax = 1 000 ms. This corresponds to the
CAM generation rate of 1 Hz.

ETSI
 16 ETSI TS 103 900 V2.1.1 (2023-11)

Within these limits the CAM generation shall be triggered depending on the originating ITS-S dynamics and the
channel congestion status. In case the dynamics of the originating ITS-S lead to a reduced CAM generation interval,
this interval should be maintained for a number of consecutive CAMs. The conditions for triggering the CAM
generation shall be checked repeatedly every T_CheckCamGen. T_CheckCamGen shall be equal to or less than
T_GenCamMin.

In the case of ITS-G5,the parameter T_GenCam_Dcc shall provide the minimum time interval between two consecutive
CAM generations in order to reduce the CAM generation according to the channel usage requirements of Decentralized
Congestion Control (DCC) as specified in ETSI TS 102 724 [i.18]. This facilitates the adjustment of the CAM
generation rate to the remaining capacity of the radio channel in case of channel congestion. The parameter T_
GenCam_Dcc shall be provided by the management entity as specified in clause 5.3.5 in the unit of milliseconds. The
value range of T_GenCam_DCC shall be limited to T_GenCamMin ≤ T_GenCam_DCC ≤ T_GenCamMax. If the
management entity provides this parameter with a value above T_GenCamMax, T_GenCam_DCC shall be set to
T_GenCamMax and if the value is below T_GenCamMin or if this parameter is not provided, the T_GenCam_Dcc shall
be set to T_GenCamMin.

In the case of LTE-V2X, DCC and T_GenCam_Dcc are not applicable. Channel congestion control is managed by the
access layer defined in ETSI TS 103 574 [i.20].

The parameter T_GenCam represents the currently valid upper limit of the CAM generation interval. The default value
of T_GenCam shall be T_GenCamMax. T_GenCam shall be set to the time elapsed since the last CAM generation, if a
CAM is triggered due to condition 1). After triggering the number of N_GenCam consecutive CAMs due to
condition 2), T_GenCam shall be set to T_GenCamMax. The value of the parameter N_GenCam can be dynamically
adjusted according to some environmental conditions. The default and maximum value of N_GenCam shall be 3.

EXAMPLE: N_GenCam can be increased when approaching an intersection in order to increase the probability
of CAM reception.

In detail the CAM generation trigger conditions shall be as follows:

1) The time elapsed since the last CAM generation is equal to or greater than T_GenCam_Dcc, as applicable, and
one of the following ITS-S dynamics related conditions is given:

- the absolute difference between the current heading of the originating ITS-S and the heading included in
the CAM previously transmitted by the originating ITS-S exceeds 4°;

- the distance between the current position of the originating ITS-S and the position included in the CAM
previously transmitted by the originating ITS-S exceeds 4 m;

- the absolute difference between the current speed of the originating ITS-S and the speed included in the
CAM previously transmitted by the originating ITS-S exceeds 0,5 m/s.

2) The time elapsed since the last CAM generation is equal to or greater than T_GenCam and, in the case of
ITS-G5, is also equal to or greater than T_GenCam_Dcc.

If one of the above two conditions is satisfied, a CAM shall be generated immediately.

When a CAM needs to be generated, the CA service shall construct the mandatory containers as specified in clause 7.1.
The mandatory containers mainly include the high dynamic information of the originating ITS-S, as
{CAM.cam.basicContainer} and {CAM.cam.camParameters.highFrequencyContainer} as specified in annex A.
Optionally, a CAM may include optional data. The optional data mainly include the status of the originating ITS-S
which is less dynamic, as {CAM.cam.camParameters.lowFrequencyContainer} and specific information as included for
a specific type of originating ITS-S, as {CAM.cam.camParameters.specialVehicleContainer} as specified in annex A.

The low frequency container shall be included in the first CAM generation since the CA service activation. After that
the low frequency container of CAM shall be included if time elapsed since the generation of the last CAM with the low
frequency container generation is equal to or greater than 500 ms.

For special vehicles, the special-vehicle container shall be included in the first CAM generation since the CA service
activation. After that, a special vehicle container shall be included if the time elapsed since the generation of the last
CAM with a special vehicle container is equal to or greater than 500 ms.

ETSI
 17 ETSI TS 103 900 V2.1.1 (2023-11)

6.1.3 CAM generation frequency management for RSU ITS-Ss

The CAM generation frequency for RSU ITS-Ss defined by the time interval between two consecutive CAM
generations shall be set in such a way, that at least one CAM is transmitted while a vehicle is in the communication
zone of the RSU ITS-S and that an inlineP2pcdRequest for an unknown authorization authority certificate from that
same vehicle can be answered according to ETSI TS 103 097 [3] at least once thereafter. The time interval shall be
greater than or equal to 500 ms.

NOTE: The probability for the reception of a CAM from an RSU by a passing vehicle depends on the generation
rate of the CAM and the time the vehicle is within the communication zone, which depends on the vehicle
speed and the RSU transmission power.

6.1.4 CAM time requirement

6.1.4.1 CAM generation time

Besides the CAM generation frequency the time required for the CAM generation and the timeliness of the data taken
for the message construction are decisive for the applicability of data in the receiving ITS-Ss. In order to ensure proper
interpretation of received CAMs, each CAM shall be time-stamped.

NOTE: An acceptable time synchronization between the different ITS-Ss is expected.

Time required for a CAM generation shall be less than 50 ms. The time required for a CAM generation refers to the
time difference between time at which CAM generation is triggered and time at which the CAM is delivered to
networking transport layer.

6.1.4.2 CAM Time stamp

The following requirements shall apply:

• The time stamp given in the vehicle ITS-S CAM shall correspond to the time at which the reference position
of the originating ITS-S given in this CAM was determined. The format and range of the time stamp is defined
in annex B.

• The time stamp given in the RSU ITS-S CAM shall be the time of generation.

• The difference between CAM generation time and time stamp shall be less than 32 767 ms.

NOTE 1: This requirement is set to avoid time stamp wrap-around situation.

NOTE 2: The specification of the ITS-S Time precision and synchronization is out of scope of the present
document.

6.2 CAM dissemination constraints

6.2.1 General Confidence Constraints
Several data elements of the CAM may vary with regard to accuracy or confidence. For these data elements data frames
are specified providing data element together with confidence information as presented in annex B.

6.2.2 Security constraints

6.2.2.1 Introduction
Clause 6.2.2 is applicable to ITS stations that use the trust model according to ETSI TS 102 940 [i.21] and ITS
certificates according to ETSI TS 103 097 [3].

NOTE: For other scenarios, the trust model and the mechanisms for trust enforcement for inter-connected ITS
stations can agreed among participating actors.

ETSI
 18 ETSI TS 103 900 V2.1.1 (2023-11)

The security mechanisms for ITS consider the authentication of messages transferred between ITS-Ss with certificates.
A certificate indicates its holder's permissions to send a certain set of messages and optionally privileges for specific
data elements within these messages. The format for the certificates is specified in ETSI TS 103 097 [3].

Within the certificate the permissions and privileges are indicated by a pair of identifiers, the ITS-AID and the SSP.

The ITS-Application Identifier (ITS-AID) as given in ETSI TS 102 965 [i.19] indicates the overall type of permissions
being granted: for example, there is an ITS-AID that indicates that the sender is entitled to send CAMs.

The Service Specific Permissions (SSP) is a field that indicates specific sets of permissions within the overall
permissions indicated by the ITS-AID: for example, there may be an SSP value associated with the ITS-AID for CAM
that indicates that the sender is entitled to send CAMs for a specific vehicle role.

An incoming signed CAM is accepted by the receiver if the certificate is valid and the CAM is consistent with the
ITS-AID and SSP in its certificate.

6.2.2.2 Service Specific Permissions (SSP)

CAMs shall be signed using private keys associated to Authorization Tickets that contain SSPs of type BitmapSsp as
specified in ETSI TS 103 097 [3].

The CAM-SSP octet scheme allows the SSP format to accommodate current and future versions of the present
document. The octet scheme is constructed out of three octets as illustrated in Figure 3.
0 1 2
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
Octet 0 Octet 1 Octet 2

Figure 3: Format for the Octets

EXAMPLE of bit order: The decimal value 199 shall be represented as shown below:
0 1 2 3 4 5 6 7
1 1 0 0 0 1 1 1

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 one octet; the value shall only be used for testing purposes.

1: first version, length three octets, SSP contains information as defined in the present document.

2 to 255: reserved for future usage.

The SSP has a maximum length as specified in ETSI TS 103 097 [3]. The first octet shall reflect the version of the
present document. As future versions of the present document are published, the first octet shall be incremented only in
case of changes in the assignment of the already assigned SSP bits. The remaining octets shall be based on the
permissions described in the present document (see Table 3 and Table 4).

Length of SSP is the length of the Octet String.

Table 3: Octet Scheme for CAM SSPs

Octet # Description
0 SSP version control
1 to 2 service-specific parameter
3 to 30 reserved for future usage

A vehicle may be assigned one or more permissions.

When the ITS-AID is set for the CA service, the SSPs shall be defined as in Table 4.

ETSI
 19 ETSI TS 103 900 V2.1.1 (2023-11)

Table 4: SSP Definitions for Permissions in CAM

Octet Bit Permission Items Bit
Position Position Value
1 0 (80h) CenDsrcTollingZone/ 0: certificate not allowed to sign
(MSBit) ProtectedCommunicationZonesRSU 1: certificate allowed to sign
1 1 (40h) publicTransport / 0: certificate not allowed to sign
publicTransportContainer 1: certificate allowed to sign
1 2 (20h) specialTransport / 0: certificate not allowed to sign
specialTransportContainer 1: certificate allowed to sign
1 3 (10h) dangerousGoods / 0: certificate not allowed to sign
dangerousGoodsContainer 1: certificate allowed to sign
1 4 (08h) roadwork / 0: certificate not allowed to sign
roadWorksContainerBasic 1: certificate allowed to sign
1 5 (04h) rescue / 0: certificate not allowed to sign
rescueContainer 1: certificate allowed to sign
1 6 (02h) emergency / 0: certificate not allowed to sign
emergencyContainer 1: certificate allowed to sign
1 7 (01h) safetyCar / 0: certificate not allowed to sign
(LSBit) safetyCarContainer 1: certificate allowed to sign
2 0 (80h) closedLanes / 0: certificate not allowed to sign
(MSBit) RoadworksContainerBasic 1: certificate allowed to sign
2 1 (40h) requestForRightOfWay / 0: certificate not allowed to sign
EmergencyContainer: EmergencyPriority 1: certificate allowed to sign
2 2 (20h) requestForFreeCrossingAtATrafficLight / 0: certificate not allowed to sign
EmergencyContainer: EmergencyPriority 1: certificate allowed to sign
2 3 (10h) noPassing / 0: certificate not allowed to sign
SafetyCarContainer: TrafficRule 1: certificate allowed to sign
2 4 (08h) noPassingForTrucks / 0: certificate not allowed to sign
SafetyCarContainer: TrafficRule 1: certificate allowed to sign
2 5 (04h) speedLimit / 0: certificate not allowed to sign
SafetyCarContainer 1: certificate allowed to sign
2 6 (02h) reserved for future usage not used, set to 0
2 7 (01h) reserved for future usage not used, set to 0
(LSBit)

6.2.3 General priority constraints

If the GeoNetworking / BTP stack is used, the priority constraint is given by the Traffic Class as specified in ETSI
TS 103 836-4-1 [i.13].

7 CAM Format Specification

7.1 General structure of a CAM PDU

A CAM is composed of one common ITS PDU header and multiple containers, which together constitute a CAM.

The ITS PDU header is a common header that includes the information of the protocol version, the message type and
the ITS-S ID of the originating ITS-S.

For vehicle ITS-Ss a CAM shall comprise one basic container and one high frequency container, and may also include
one low frequency container and one or more other special containers:

• The basic container includes basic information related to the originating ITS-S.

• The high frequency container contains highly dynamic information of the originating ITS-S.

• The low frequency container contains static and not highly dynamic information of the originating ITS-S.

The special vehicle container contains information specific to the vehicle role of the originating vehicle ITS-S.

ETSI
 20 ETSI TS 103 900 V2.1.1 (2023-11)

All CAMs generated by a RSU ITS-S shall include a basic container and optionally more containers.

The general structure of a CAM is illustrated in Figure 4.

Each container is composed of a sequence of optional or mandatory Data Elements (DE) and/or Data Frames (DF). DEs
and DFs are mandatory unless specified otherwise. The present document provides CAM content specifications for
vehicle ITS-Ss. CAM format and content specifications for other types of ITS-Ss is expected to be added in the future.

CAM

ITS PDU header Basic HF Container LF Special vehicle Container (Conditional)

Container Container
(Conditional) Public Transport Container
or
Vehicle HF Vehicle LF
Container or Container or Special Transport Container
or
Other containers Other containers …
(not yet defined)

Figure 4: General structure of a CAM

7.2 ITS PDU header

The ITS PDU header shall be as specified in ETSI TS 102 894-2 [1]. Detailed data presentation rules of the ITS PDU
header in the context of CAM shall be as specified in annex B.

7.3 Basic container

The basic container provides basic information of the originating ITS-S:

• type of the originating ITS-S;

• the latest geographic position of the originating ITS-S as obtained by the CA service at the CAM generation.

The basic container shall be present for CAM generated by all ITS-Ss implementing the CA service.

Detailed data presentation rules shall be as specified in annex B.

7.4 Vehicle ITS-S containers

All CAMs generated by a vehicle ITS-S shall include at least a high frequency vehicle (Vehicle HF) container, and
optionally a low frequency vehicle (Vehicle LF) container. The Vehicle HF container contains all fast-changing
(dynamic) status information of the vehicle ITS-S such as heading or speed. The Vehicle LF container contains static or
slow-changing vehicle data like the status of the exterior lights.

Vehicle ITS-Ss which use a value of vehicleRole in the Vehicle LF container, i.e.
{CAM.cam.basicVehicleContainerLowFrequency.vehicleRole} other than the value default(0) shall provide further
status information in special vehicle containers according to Table 5.

ETSI
 21 ETSI TS 103 900 V2.1.1 (2023-11)

Table 5: Special vehicle container according to the vehicle role

CAM data requirement Special vehicle container
Value of represented as
{CAM.cam.basicVehicleContainerLowFre
quency.vehicleRole} shall be set to
publicTransport(1) public transport container,{CAM.cam. specialVehicleContainer.
publicTransportContainer}
specialTransport(2) special transport container, {CAM.cam. specialVehicleContainer.
specialTransportContainer}
dangerousGoods(3) dangerous goods container, {CAM.cam. specialVehicleContainer.
dangerousGoodsContainer}
roadWork(4) road work container,
{CAM.cam.specialVehicleContainer.roadWorksContainer }
rescue(5) rescue container, {CAM.cam. specialVehicleContainer. rescueContainer}
emergency(6) emergency container, represented as {CAM.cam.
specialVehicleContainer.emergencyContainer}
safetyCar(7) Safety car container, represented as {CAM.cam. specialVehicleContainer.
safetyCarContainer}
agriculture(8), No special vehicle container defined in the present document.
commercial(9),
military(10),
roadOperator(11),
taxi(12),
uvar(13)

7.5 RSU ITS-S containers

RSU ITS-S CAMs shall provide at least one HF container. Additional LF containers may be added.

7.6 CAM format and coding rules

7.6.1 Common data dictionary
The CAM format makes use of the common data dictionary as defined in ETSI TS 102 894-2 [1].

Where applicable, DEs and DFs that are not defined in the present document shall be imported from the common data
dictionary as specified in ETSI TS 102 894-2 [1].

NOTE: Detailed descriptions of all DEs and DFs in the context of CAM are presented in the annex B of the
present document.

7.6.2 CAM data presentation

The CAM format is presented in ASN.1. Unaligned packed encoding rules (PER) as defined in Recommendation
ITU-T X.691/ISO/IEC 8825-2 [2] shall be used for CAM encoding and decoding.

The ASN.1 representation of CAM shall be as specified in the annex A of the present document.

ETSI
 22 ETSI TS 103 900 V2.1.1 (2023-11)

Annex A (normative):
ASN.1 specification of CAM syntax
This clause provides the normative ASN.1 module containing the syntactical specification of the CAM PDU, its
containers, data frames and data elements defined in the present document.

The semantical specification of the CAM components, its containers, data frames, and data elements are contained in
the same module, in the form of ASN.1 comments. For readability, the same semantical specification is presented in a
different format in annex B.

The CAM-PDU-Descriptions module is identified by the Object Identifier {itu-t (0) identified-organization (4) etsi (0)
itsDomain (5) wg1 (1) camPduRelease2 (103900) major-version-2 (2) minor-version-1 (1) }. The module can be
downloaded as a file as indicated in Table A.1. The associated SHA-256 cryptographic hash digest of the referenced file
offers a means to verify the integrity of that file.

Table A.1: ETSI TS 103 900 ASN.1 module information

Module name CAM-PDU-Descriptions
OID {itu-t (0) identified-organization (4) etsi (0) itsDomain (5) wg1 (1) camPduRelease2 (103900)
major-version-2 (2) minor-version-1 (1) }
Link https://forge.etsi.org/rep/ITS/asn1/cam_ts103900/-/raw/V2.1.1/CAM-PDU-Descriptions.asn
SHA-256 hash e6b9eea2828cd82d1dbc666e803c4078063700242ea4d8d49d18beb0470bd870

ETSI
 23 ETSI TS 103 900 V2.1.1 (2023-11)

Annex B (informative):
Specification of CAM PDU components
The specification of CAM PDU components is available at the following URL:

• https://forge.etsi.org/rep/ITS/asn1/cam_ts103900/-/blob/V2.1.1/docs/CAM-PDU-Descriptions.md.

ETSI
 24 ETSI TS 103 900 V2.1.1 (2023-11)

Annex C (informative):
Protocol operation of the CA service

C.1 Introduction
This annex provides a timer controlled approach for the protocol operation as one potential variant compliant to the
present document. It is distinguished between the originating ITS-S operation and the receiving ITS-S operation
considered in the following clauses.

Following specification of the protocol operation is organized in three parts:

1) Protocol data setting rules specify the setting of the relevant data elements used by the protocol.

2) The general protocol operation specifies the sequence of protocol operations.

3) Exception handling specifies additional protocol operations that extend the general protocol operation. They
are applied when special conditions, referred to exceptions (for example inconsistent data) occur.

An ITS-S maintains a local data structure, referred to as "ITS-S message table". This data structure holds information
about sent or received CAM messages.

It is out of scope of the present document to describe how this data structure is implemented.

C.2 Originating ITS-S operation

C.2.1 Protocol data setting rules

The data settings for the originating ITS-S operation are specified in annex B.

C.2.2 T_CheckCamGen
The timer T_CheckCamGen schedules the time at which the CAM generation conditions are checked by the CA service,
its time out value is specified in clause 6.1.2.

C.2.3 Originating ITS-S message table

The CA service stores at least the following information for the CAM originating ITS-S operation:

• CAM generation time;

• ITS-S position as included in CAM;

• ITS-S speed as included in CAM;

• ITS-S heading as included in CAM.

ETSI
 25 ETSI TS 103 900 V2.1.1 (2023-11)

C.2.4 General protocol operation

The originating ITS-S protocol starts when the CA service is activated as specified in clause 6.1.1. An originating ITS-S
may execute the following operations:

1) set T_ CheckCamGen and start the timer;

2) when the timer T_CheckGenCam expires, check the CAM generation conditions:

a) if any of the condition is satisfied, continues the operation;

b) if none of the condition is satisfied, skip step 3) to step 7);

3) collect data for mandatory containers;

4) check if optional containers are to be added for CAM generation:

a) if yes, check the ITS-S type and ITS-S role and collect data for optional containers;

b) if no, continue the operation;

5) encode CAM;

6) pass CAM to the ITS networking & transport layer;

7) save data required as specified in clause C.2.3 for next CAM generation;

8) restart the timer T_ CheckCamGen.

C.2.5 CAM construction exception

If the CA service could not construct a CAM successfully in step 5) as defined in clause C.2.4, the CA service is
expected to omit step 6) to step 8) and is expected to restart the timer T_CheckCamGen.

NOTE 1: The failure of the CAM construction may happen, if the CA service was not able to collect all required
data for the CAM construction, or the collected data are not compliant to the CAM format as specified in
annex A (e.g. the value of a data is out of authorized range of the ASN.1 definition).

NOTE 2: If the CAM construction failure was due to a data provided by other entities via the interface IF.FAC, CA
service may provide a failure notification to the corresponding data provision facilities via the IF.FAC.

C.3 Receiving ITS-S operation

C.3.1 Protocol data setting rules

No protocol data need to be set for the receiving ITS-S.

C.3.2 General protocol operation

The ITS-S receiver protocol starts when the CA service receives a CAM and executes the following operations:

1) decode received CAM;

2) make CAM data available by e.g. passing to the ITS application layer or to the LDM;

3) end of operation, wait for the next CAM reception.

ETSI
 26 ETSI TS 103 900 V2.1.1 (2023-11)

C.3.3 Exception handling

C.3.3.1 CAM decoding exception
If the CA service could not decode a CAM successfully in step 1) as defined in clause C.3.2, the CA service omits
step 2) and step 3).

NOTE: The failure of the CAM decoding may happen, if the CA service checks that the data included in a
received CAM is not compliant to the CAM format as specified in annex A (e.g. the value of a data is out
of authorized range of the ASN.1 definition).

ETSI
 27 ETSI TS 103 900 V2.1.1 (2023-11)

Annex D (informative):
Flow chart for CAM generation frequency management
Figures D.1 to D.3 illustrate the CAM frequency management specified in clause 6.1.2.

ETSI
 28 ETSI TS 103 900 V2.1.1 (2023-11)

Figure D.1: Process CAM Generation

ETSI
 29 ETSI TS 103 900 V2.1.1 (2023-11)

Figure D.2: Process Check Dynamics

ETSI
 30 ETSI TS 103 900 V2.1.1 (2023-11)

Figure D.3: Procedure Check

ETSI
 31 ETSI TS 103 900 V2.1.1 (2023-11)

Annex E (informative):
Extended CAM generation
This annex describes an additional trigger condition for the CAM message generation, which enables ITS applications
to increase the CAM generation frequency.

Depending on the requirements of an ITS application it may provide the parameter T_GenCam_App representing the
needed CAM generation interval. T_GenCam_App should be provided in the unit of milliseconds and with a value
range of T_GenCamMin ≤ T_GenCam_App ≤ T_GenCamMax. In case an ITS application provides this parameter with
a value below T_GenCamMin, T_GenCam_App would be set to T_GenCamMin and if the value is above
T_GenCamMax or this parameter is not provided, the T_GenCam_App would be set to T_GenCamMax. In case several
ITS applications require different values the lowest generation interval would be applied.

In addition to the CAM trigger conditions defined in clause 6.1.2, the following condition would apply:

1) the time since last CAM generation is equal to or greater than T_GenCam_App and equal to or greater than
T_GenCam_Dcc.

In case the requested CAM generation frequency will not be achieved, the CA service should return a failure
notification to the requesting application.

ETSI
 32 ETSI TS 103 900 V2.1.1 (2023-11)

History
Document history
V2.0.0 July 2022 Publication
V2.1.1 November 2023 Publication

ETSI