Standards List

This document is one of the documents of stage 3 in the C-Roads workflow, as described in section 1.4 of Introduction to the C-Roads WG2 Deployment Documentation and Requirements. This workflow reflects how information flows through the C-ITS station architecture. It starts with an ITS-S application (referred to as 'Service'), which is described in the stage 2 documents. In order to perform its function, the ITS-S application decides to send out messages and in order to do so, it invokes a Service Access Point (SAP) of a Facility Layer Service (FLS). The term SAP is taken from the OSI reference model for the interfaces between layers, many people today would probably rather call it an API. The Facility Layer Service performs its task according to its specification and uses SAPs of underlying layers (transport, network, access) for doing so. The according specifications are not developed in C-Roads, standards are used for this instead, e.g. ETSI TS 103 831 [10] and ISO 103 301 [11] for the Facility Layer services.
What the stage 3 documents specify are the profiles used for these standards, depending on how the FLS is invoked. Hence, the behaviour is ITS-S application and use case specific, since different ITS-S applications – as well as the same ITS-S application in different Use Cases – invoke the FLS differently. Stage 3 describes the profiles on FLS level in the document named 'Message Profiles and Parameters', and the underlying layer aspects – where needed – in the 'Roadside ITS-G5 System Profile' [4] and 'Mobile ITS-G5 System Profile' [24] documents.
The present document C-ITS Message Profiles and Parameters describes the Facility Layer Service (FLS) that are used in the current release of the C-Roads specification. In the current version this includes the following FLS:
• Decentralise Environmental Notification
• Infrastructure to Vehicle Information
• Traffic Light Manoeuvre
• Road and Lane Topology
• Traffic Light Control
• Cooperative Awareness Basic Service
This document provides the message profiles used by different ITS-S applications and in different use cases, and it also provides the parameters used to control the FLS behaviour when invoking the underlying layers for transport, network and access.
This document defines the common base for the C-ITS message specifications. The specification targets predominantly the communication between roadside units and vehicles. The communication directions derived from this are also known as I2V (Infrastructure-to-Vehicle) and V2I (Vehicle-to-Infrastructure) communication. It also covers communication from vehicles assuming special roles, such as road operator vehicles, emergency vehicles, public transport vehicles, to other conventional vehicles. The latter falls into the category of V2V (vehicle-to-vehicle) communication. This selection has been taken based on maturity consideration, i.e. only specifications that have been implemented and tested in the field can be considered for this document.
Thus, note that the interfaces between the following units are not included in the current release of this specification:
• Roadside and centres (R2C and C2R)
• Roadside and web services (R2W and W2R)
This document is structured into three sections:
• Section 1 defines verbal forms and provisions
• Section 2 lists the functional description of supported system FLS and ITS-S applications
• Section 3 provides the technical specifications of the supported FLSs.
Section 3 will include also the security and management entity related specifications. Nevertheless, these will not be handled fully in this document.

This document is one of the documents of stage 4 in the C-Roads workflow, as described in section 1.4 of Introduction to the C-Roads WG2 Deployment Documentation and Requirements. This workflow reflects how information flows through the C-ITS station architecture. It starts with an application (referred to as 'Service'), which is described in the stage 2 documents. In order to perform its function, the application decides to send out messages and in order to do so, it invokes a Service Access Point (SAP) of a Facility Layer Service (FLS). The term SAP is taken from the OSI reference model for the interfaces between layers, many people today would probably rather call it an API. The Facility Layer Service performs its task according to its specification and uses SAPs of underlying layers (transport, network, access) for doing so. The according specifications are not developed in C-Roads, standards are used for this instead, e. g. ETSI EN 302 637-3 [10] and ISO 103 301 [16] for the Facility Layer services.
The present document specifies the requirements and general settings for most layers of the C-ITS system architecture in the case of a Roadside ITS-G5 System, including:
• The Access Layer
• The Network Layer
• The Transport Layer
• The Management Component
The European ITS-Station architecture (Figure 3), outlined in ETSI EN 302 665 [12], defines four ITS sub-systems; vehicle, roadside, personal, and central. Standards are developed in a neutral and open way such that they include different options to allow diversion and future options to extend the standards later. To realize Interoperability among sub-systems many of these options need to be made specific. Profiles therefore describe the selected options and include additional specification when required to ensure the expected interoperability. Herein, the roadside sub-system profile is defined.
The Infrastructure Roadside ITS-G5 System Profile, referred as Roadside System Profile (RSP), defines a common base for the ITS-G5 communication between roadside and vehicle. The communication directions derived from this are also known as I2V (Infrastructure-to-Vehicle) and V2I (Vehicle-to-Infrastructure).
The profile provides descriptions, definitions and rules for all layers (Applications, Facilities, Networking & Transport and Access) of the ETSI ITS station reference architecture/ITS-S host. Management is included, but Security is out of scope.
This infrastructure system is a Roadside ITS sub-system enabling a set of 'Day-1 services' (listed in Table 2 in section 3.2).
Since the requirements of the ITS sub-systems are very similar, this Infrastructure Roadside ITS-G5 System Profile uses the C2C-CC BSP [2] as a basis from content- and structure point of view.
This system profile specifies a minimum set of standards and fills the missing gaps necessary for the realisation of an interoperable roadside ITS-Station as defined in the Communication Architecture ETSI EN 302 665 [12]. The profile only includes the interoperability requirements leaving open any additional requirements, it therefore does not describe the full functionality of the roadside ITS-Station.
The current version of this system profile enables the deployment of the “Day-1 services”, as selected by C-Roads for this release. It may also support other services but these other services may require extensions of this system profile in next releases.
An infrastructure roadside system shall at least realize the requirements as specified here to realize European interoperability with the aim to increase road traffic safety and at improving the overall traffic efficiency.
The current document considers requirements such as information quality, the efficient use of the spectrum in the 5.9 GHz range and the coexistence with the tolling frequency band 5.8 GHz.
It does not consider the communication between roadside and centre (R2C and C2R) or roadside and web service (R2W and W2R) as well as vehicle and vehicle (V2V) are out of scope.
Security related requirements are also out of scope for this document, as they are covered by a dedicated document.
Mobile R-ITS-S are also not covered in this document.
The infrastructure roadside system profile contributes to the realisation of the objective of the C-ROADS Platform to develop, share, and publish common communication profiles.
The current document covers the Intra-C-ITS information exchange between infrastructure and vehicles, and not for intra-sub-system interoperability.

This document provides an overall introduction to the common European trust model and builds on the European Certificate Policy for C-ITS, which is referring to the relevant ETSI standards for certificates and PKI management as the underlying technical basis. These provisions are valid for all services, use cases and scenarios harmonized within C-Roads. This document also describes common agreements that are important for C-Roads and other European C-ITS stakeholders, covering a level of developments and testing within and across different C-Roads pilots as well as the relation to the levels of regular and continuous operation.
This report mainly covers the security of ETSI ITS G5 communication. Within this, it references the common EU Trust Model, the related requirements for Public Key Infrastructure (PKI) and the technical and organisational elements linked to it. This version also considers IP-based network technologies in more detail, so that the general provisions for a future “hybrid” communication approach between road infrastructures and vehicles in C-ITS are included.
The C-ITS security aspects described within this document have initially been based on two documents that the EU C-ITS Platform had produced in 2017 and updated in 2019:
• CP – Certificate Policy [1]
• SP – Security Policy [2]
Further reference documents are ETSI and CEN/ISO standards that provide security requirements for the use of a PKI to secure V2X communications. Besides these agreed policy requirements and related standards, additional guidance and detailed protocol specifications have been elaborated [4].
This report concentrates on the C-ITS implementation in the C-Roads pilots according to the requirements derived from aforementioned policies. Following a general introduction in chapter 1, security aspects relevant for the European CCMS are presented in chapter 2. Chapter 3 and 4 complete this report with a set of governance recommendations for testing and pilots as well as the phase of regular operation of C-ITS systems and services in Europe.
Technical details and requirements as well as information related to security testing are specified in a separate TF1 document 'C-ITS Security Requirements' [5].
In addition to these two documents, the 'hardening' and respective security certification of C-ITS stations is a CP requirement to be considered by all C-ITS station operators Therefore TF1 is also creating a 'Protection Profile' according to Common Criteria, ISO/IEC 15408.
None of these reports/documents provide a comprehensive list containing all 'cybersecurity aspects' of C-ITS stations and technical elements and the necessary provisions for preventing general IT security attacks. Out of scope are topics which are not (yet) included in the EU policy considerations. This includes: misbehaviour detection of single ITS stations; misuse of certificates; intrusion detection; security for the integration of C-ITS stations into other systems and secure operational processes beyond the requirements of the CP (i.e. ISMS); misuse of the entities within the EU Trust Model.

This document provides the detailed specifications for the certificates that are required to sign C-ITS messages. This covers service specific permissions that are required for all C-Roads services, e.g. per service and use case. Moreover, the validation and verification of incoming messages is specified from a security perspective. That is to say, the document provides the basis for the creation of security-specific test cases in collaboration with TF5, in addition to the TF3 documents providing the basis for functional test cases.
Note: the TF1 Security and Governance document provides an overall introduction to the common European trust model and builds on the European Certificate Policy for C-ITS, and describes the common agreements that are important for C-Roads and other European C-ITS stakeholders, covering a level of developments and testing within and across different C-Roads pilots as well as the relation to the level of regular and continuous operation.
The European ITS-Station architecture, outlined in EN 302 665, defines four ITS sub-systems; vehicle, roadside, personal, and central Standards are developed in a neutral and open way such that they include different options to allow diversion and future options to extend the standards later. To realize Interoperability among sub-systems many of these options need to be made specific. Profiles therefore describe the selected options and include additional specification when required to ensure the expected interoperability. Herein, the roadside sub-system profile is defined.
The Infrastructure Roadside Wi-Fi ITS-G5 System Profile, short called Roadside System Profile (RSP), defines a common base for the Wi-Fi ITS-G5 communication between roadside and vehicle. The communication directions derived from this are also known as I2V.
The profile provides descriptions, definitions and rules for all layers (Applications, Facilities, Networking & Transport and Access) of the ETSI ITS station reference architecture/ITS-S host. Management is included, but Security is out of scope.

This document covers stage 2, where services and use cases are described in a functional way. It also provides for each use case the generic reference to the required specific documentation of the C-Roads WG 2 and the harmonised specific use case settings in order to achieve interoperability. These functional descriptions are the result of the harmonisation efforts that have taken place within TF2 (Service Harmonisation) and the alignment with the work of the other C-Roads WG2 task forces where the harmonisation of the interoperability requirements for the specific services and use cases takes place.
In the C-ITS service context the following terminology is used:
• Service: a clustering of use cases based on a common denominator, for example, an objective such as awareness or a context like road works. Services are also known as ‘applications’.
• Use case: function of the system, the desired behaviour (of the system and actors), specification of system boundaries and definition of one or more usage scenarios.
• Situation: relevant situation (everything required to describe a static snapshot) considering (driving) function-related goals and values.
• Scenario: temporal development of a sequence of situations (e.g. initial and after) based on events and actions. It is story telling.
• Actors: external (human) entities that interact with the system. The system affects and is affected by the behaviour of actors; these interactions are described in the use case descriptions.
Basic principle: 'information need + context (situation) = use case'. Meaning that:
• A different information need in the same context results in a new use case.
• The same information need in a different context results in a new use case.
However, note that the functional description of these use cases may seem to be largely identical as the main differences might become apparent only when reading the high-level technical descriptions. This document contains functional descriptions, not high-level technical descriptions, which are described in a technology agnostic way (where possible).
It is important not to confuse ‘service’ with ‘use case’. Therefore, it is important to clearly refer to the information need and the context of use within a specific use case. Similarly, services should be defined carefully and economically as the one-to-many relationship between services and use cases may lead to a nearly infinite number of services.
Next to the functional description of the specific use cases, the specific interoperability requirements are included in the last part of the template. It contains generic references to the other C-Roads requirements documentation as well the use case specific harmonised settings needed for interoperability.

This document is one of the deliverables of Taskforce 5 of Working Group 2 of the C-Roads Platform and contributes to stage 5 in the C-Roads workflow. The stage 5 deliverables provide the basis to validate the interoperability of a C-ITS implementation and guide through all aspects of interoperability testing for ITS-G5 systems, IP-Based communication and security elements, as specified by different other Task Forces of Working Group 2 of the C-Roads Platform, namely TF1, TF2, TF3 and TF4.
The test cases provided in this deliverable are the basis to validated interoperability aspects by functional on-road testing using ITS-G5 or IP-Based (cellular) communication and on lab testing of implementations of security systems. All test cases are listed in this deliverable, the test cases them self are single files compiled in a joint directory.

The present report represents the latest version of the first set of Use Case descriptions (Volume 1 – previously named WAVE1) developed in context of the 5GAA WG1 work item 'Use Case and KPI requirements'[3]. The report introduces and explains the WG1 approach to describe Use Cases and their Service Level Requirements (SLRs). It includes a framework for the Use Case descriptions and a framework for Use Case Service Level Requirements collection. The two frameworks are applied to the Use Cases provided in the 5GAA Board Internal Guidance Document [1].
The results and conclusions of this report serve as input for the work of other WGs in 5GAA, as well as sources for input and feedback to standardisation activities, e.g. in 3GPP.

The present report contains the second volume (Volume II) of 5GAA WG1 agreed use case (UC) descriptions for '5G Use Cases' developed within the 5GAA WG1 work item 'Use Case and KPI requirements' [1]. This second volume was previously named as Wave 2.
The results and conclusions of this report, and of the future use case descriptions and related communication requirements, are intended to serve as input for the work of other WGs in 5GAA, as well as sources for input and feedback to standardization activities, e.g., in 3GPP.

The present report contains the third volume (Volume III) of 5GAA WG1 agreed use case (UC) descriptions for Use Cases developed within the 5GAA, and consolidated in WG1.
The results and conclusions of this report, and of the future use case descriptions and related communication requirements, are intended to serve as input for the work of other WGs in 5GAA, as well as sources for input and feedback to standardization activities, e.g., in 3GPP.

This document is not a standard, it is a candidate for a standard being submitted to SAE for their consideration as a comment to SAE J2735. The term SAE J2735 SE candidate is used within this document to refer to this submission.
This document specifies dialogs, messages, and the data frames and data elements that make up the messages specifically for use by applications intended to utilize the 5.9 GHz Dedicated Short Range Communications for Wireless Access in Vehicular Environments (DSRC/WAVE, referenced in this document simply as “DSRC'), communications systems. Although the scope of this Standard is focused on DSRC, these dialogs, messages, data frames and data elements have been designed, to the extent possible, to be of use for applications that may be deployed in conjunction with other wireless communications technologies. This standard therefore specifies the definitive message structure and provides sufficient background information to allow readers to properly interpret the message definitions from the point of view of an application developer implementing the messages according to the DSRC Standards.