1       Introduction

In the few last years, automobile manufacturers gave more interest into Collaborative Intelligent Transportation Systems (C-ITS). Indeed, they provided numerous prototypes of vehicles equipped with sensors, dedicated computing hardware and dedicated shortrange radio (DSRC) for communication with other nearby ITS Station Vehicles (ITSS-V) or with road side infrastructure (ITS Station Road side unit (ITSSR)). Furthermore, numerous deployment project were achieved like SCMS [1], SEVECOM [2], PRESERVE [3] [4], CORRIDOR [5], Eco-AT [6] and SCOOP@F [7].

Within an ITS environment, numerous services such as improvement of road safety, driver assistance, entertainment and commercial services are provided. In order to achieve these services, their advertisement and dissemination are mandatory. In a classical scenario, a service provider which can be an application provider or even a commercial advertisement provider sends out the service advertisement message through an ITSS-R, and nearby receiving, ITSSVs start to disseminate those advertisement messages by forwarding them to other vehicles in their neigh-

borhood [8].

Numerous works and studies were proposed and conducted in the goal of providing efficient and secure service advertisement protocols. However, beyond the different organisms’ architectures and requirements, only ISO and IEEE proposed standards: Fast service advertisement protocol (FSAP) described by ISO 24102-5 standard [9]; and Wave Service Advertisement (WSA) defined in IEEE 1609.3 standard [10]. Nonetheless, the latter are compatible only with architectures proposed by their respective organisms. ETSI proposes Service Announcement Message (SAM) and Extended SAM (ESAM), which is -while writing this paper- not yet standardized [11] [12]. In addition, SAM is suitable only for systems using Geonetworking protocol on G5. We recall that using Geonetworking protocol for information carrying have the shortcoming of huge time delays, since the packets go by each hop.

Our work is part of SCOOP@F project. The latter is a french Cooperative ITS pilot deployment project (extended to Europe) that aims at deploying C-ITS in a nationwide scale. 2000 kms of road are to be equipped with Road Side Units (ITSS-R) and 3,000

Figure 1: WSA message format [13]

ITSS-V with On-Board Units to enable communication between the infrastructure (the road operator) and the user (the driver). Ile de France, Bordeaux and its ring, Bretagne and Isere counties, in addition to Paris-Strasbourg highway represent the fields of the first deployments . SCOOP@F architecture relies on ETSI published standards. Thus, WSA is not compatible with our needs. Furthermore, SAM does not cover all our needs and requirements. Indeed, in multiple scenarios, we use one hop (face-to-face) advertisement, which is not compatible with SAM.

In order to remedy SAM limits, we implemented a new advertisement solution called Cooperative Awareness Message Infrastructure (CAM-I). Its main advantage is that CAM-I is compliant with the Cooperative Awareness Message (CAM) existing standard [14]. We describe the details of CAM-I structure and functioning in this work which represent an extension of [15].

The rest of the paper is organized as follows: Section 2 gives an overview of the existing advertisement standards and explain our motivation for this work. Section 3 details our CAM-I solution. Section 4 describes a comparison of the proposed solution CAM-I with existing solutions. Finally, Section 5 concludes this paper and introduce our future works.

2          Related Works and motivation

Numerous research proposals and studies on services advertisement were conducted. However, since our project concerns a real nationwide deployment project, we will discuss only standardization working groups and consortia works.

Figure 2: IEEE communication stack [16]

2.1         IEEE WAVE Service Announcement (WSA)

WSA is only compatible with architectures that deploy IEEE WAVE communication stack described by Figure 2. Thus, this solution does not fit needs of SCOOP@F project and more generally european projects which rely on ETSI-based architecture.IEEE proposes WAVE Service Announcement (WSA), described in IEEE 1609.3 [10]. In a system implementing it, all stations are required to monitor the multi-channel radio Control Channel (CCH). In 1609.3 provider mode, the station transmits a WSA message on the CCH during the CCH interval. Consequently, since all ITSS are monitoring this channel at that time, they all receive the WSA. The WSA contains a list of the services that the provider will provide during the Service Channel (SCH) interval. It also provides the SCH channel number that they will be using. The services are identified by a code number known as a Provider Service Identifier (PSID). If an ITSS in user mode receives a WSA that contains a PSID of interest, it will switch to the appropriate SCH during the SCH interval and will make use of that service [17]. Figure 1 describes the structure of a WSA message.

2.2         ISO Fast Service Announcement Protocol (FSAP)

ISO proposes Fast Service Announcement Protocol (FSAP) [9] [18] in order to inform peer stations about available services by means of Fast Service Announcement Messages (FSAM). FSAM structure is very similar to WSA messages. This service advertisement distinguishes at least the following roles: (1) Service Advertisement Manager which contains a Server manager that transmits FSAMs and a Client manager, responsible for FSAMs’ reception; (2) Service Provider which ensure provision of ITS services; and (3) Service User which consumes ITS services. FSAM messages are encoded according to UPER encoding rules

[19].

FSAP relies on two types of unique identifiers in its functioning:

• ITS Application IDentifier (ITS-AID): specified in ISO 17419 [20] as an unsigned integer which have the same function as the IEEE PSID. It also shares a common number space with PSID. According to [20] the ITS-AID of FSAP is equal to 2.113.664.
• ITS Port Number (ITS-PN): also specified in ISO 17419 [20]. It is used at the OSI transport layer in order to identify source and destination port numbers of advertised application and services.

[18] introduces Harmonized Service Advertisement Message (HSAM), a hypothetical service advertisement message, having almost the same structure as FSAM and that can be extended to different forms. Figure 3 describes its structure details.

2.3         ETSI Service Announcement Message

ETSI proposes Services Announcement Message (SAM), which represents an ITS message that advertises available services. SAM is broadcasted from an ITSS-R on G5 on channel CCH using the Geonetworking protocol. Within a SAM, an ITSS-R must provide some specific information such as the list of the available services, the type of target for each services and the communication profile. More specifically, the available services are a list of Service-IDs. The target of the service has the value (All) or a Community-ID (CID) which associates a specific group of ITSS to an ID. The communication profile is identified by a Communication Profile Identifier (CPID).

SAMs can be sent simultaneously until a maximum threshold of sent messages which depends on the risk of congestion of CCH. At reception, SAMs are received in transport level packets. The Network & Transport layer will send the SAMs to the Facilities

Layer. At this level, a first function called “Messages Management” decodes the SAMs and sends the list of services and other data to a second function called “Services Announcement” which will provide several checks. For each service, the Service Announcement function will check if the ITSS is part of “All” or a “community” thanks to its CID. If yes, it will need to verify if the service has been subscribed or not. If the community or ITSS did not subscribed for the announced service then it should not be considered. The ITSS will create a list with all the relevant services checked from the list of the advertised services proposed in the SAM. The service announcement function will select one or several relevant services from the list depending on the channel capability so the service can be executed.

2.4         ETSI        Extended         Service Announcement Message

Recently, ETSI proposed an extended version of SAM called Extended SAM (ESAM) [12]. It defines three roles: (1) a Service Provider whose role is to register, update or deregister the provided services. (2) Service Announcer which announces the services provided by the Service Provider. The service provider and the service announcer can be the same ITSS or two distinct ITSSs. (3) Service User which represent ITSS-Vs that use the service.

The communication between each role is defined following the communication stack in Figure 4. At the application layer, the type of service, the requested actions regarding this service and other fields depending on the previously mentioned roles are defined to the management entity through the MA-SAP interface. At facility layer, ESAM needs to be encoded or decoded then managed by the management entity for each message transmission where UPER encoding rules are applied. One principal function of the management entity is to define the ITSS Communication Profile (ITS-SCP) used for the message transmission through the MA-SAP interface. Security processes between the Facility Layer and the Security Entity are achieved through the interface SF-SAP. At Networking and Transport (NT) Layer, the ESAM is delivered as a payload to the facility layer through the NF-SAP interface.

One novelty of the ESAM is the inclusion of ExtendedChannelInfos field and other needed extensions in its definition. For instance, the ExtendedChannelInfos is used in order to define new communication technologies which can be used to announce the ESAM such as IPv6. This feature was missing from the previous SAM definition which supported only G5 communication as discussed in [15]. However, no

Figure 3: HSAM structure [18]

Figure 4: SA in the context of the ETSI ITSS reference architecture [21]

clear definition on the use of new protocol type different than GN is defined yet.

SAM and ESAM solutions are suitable only for systems using Geonetworking protocol on G5 (plus IPv6 for ESAM), which relies on broadcast of messages. The latter does not suits to SCOOP@F needs, in which it does exist multiple scenarios where ITSSs communicate in face-to-face way (one hop) using IP protocol. In addition SAM and ESAM still being drafts from years and are not considered as standards yet.

Figure 5: CAM-I structure

To remedy these limits and to achieve SCOOP@F needs, we propose a new solution for service advertisement called CAM-I, a solution compliant with ETSI CAM standard [14].

3          New solution for services advertisement: CAM-I

In this section we describe the details of the advertisement solution that we propose.

3.1         Global structure

In ETSI architecture, periodic messages called CAM are diffused continuously. In our solution, the available services are advertised via the periodic broadcasting of a specific CAM message by the ITSS-R, called CAM-Infrastructure (CAM-I) message. The latter has almost the same structure as a CAM message sent by an ITSS-V.

As described in [14], a CAM is composed of one common ITS PDU header and multiple containers. The ITS PDU header is a common header that includes the information of the protocol version, the message type and the ITSS ID of the originating ITSS.

Figure 6: Service Advertisement Container structure

For an ITSS-V 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:

• Basic container: includes basic information related to the originating ITSS.
• High frequency container: contains highly dynamic information of the originating ITSS.
• Low frequency container: contains static and not highly dynamic information of the originating ITSS.
• Special vehicle container: contains information specific to the vehicle role of the originating vehicle ITSS.

As indicated in the CAM standard [14], all CAMs generated by an ITSS-R shall include a basic container and optionally more containers. Consequently, the proposed CAM-I is composed of an ITS PDU Header, a basic container and a High Frequency container, which in turn, is composed of 4 containers. Described by Figure 5, CAM-I structure is similar to the one of CAM. Its header (ITS PDU Header) and Basic Container are compliant with the standard ETSI EN 302 637-2 [14]. The ITS PDU header includes the protocol version, the message type, the ITSS-R identifier of the originating ITSS-R. In addition, a generation delta time of the message is included. The Basic Container includes the following fields: (1) The type of the emitting station (ITSS-R): 15; (2) The geographic position of the ITSS-R. While the PDU header and the low frequency are the same as in CAM, we modified the High Frequency (HF) container. More specifically, we defined a HF Container composed of the following containers:

• Service Advertisement Container;
• Position Enhancement Container;
• Environment & Context Container; (4) Protected Communication Zone RSU Container.

Table 1 describes the structure of the three last containers. Service Advertisement container is detailed in next section.

3.2         Service Advertisement Container

Figure 7: CAM-I Service Advertisement scenario

As described by Figure 6, Service Advertisement Container includes the following fields: (1) Advertisement Service ID: this byte provides the ID of the advertised service.

(2) Service Access Capabilities (SAC): The second byte details access capabilities to (1) a private network such as a network of the road operator that offers an access reserved to its staff, or (2) to a global network like Internet. The choice of access policy for SCOOP@F vehicles depends on the global access policy selected by each road operator. In SAC:

• The first bit indicates if a private access or a global access is available. If it is equal to 1, then the ITSS-R provides access to a private network and if it is equal to 0 ITSS-R provides access to a global one.
• The second bit, when having the value 1, it indicates the capacity of the ITSS-R to establish a continuous exchange with a remote server via the private/ global network. If this it has the value 0, then the ITSS-R does not possess this capacity.

Container

Data Elements

Type

Size in Bytes

Description

ITS PDU Header	Protocol version	same as in [14]		Version 1
	Message ID	same as in [14]		CAM
	Station ID	same as in [14]		ITSS-R identifier
Generation Delta Time	Generation Delta Time	same as in [14]
Basic Container	Station Type	same as in [14]		ITSS-R
	Reference Position	same as in [14]		Accurate position of the ITSS-R established at installation time
Protected Communication Zone RSU Container	Data elements for Toll collect protection	same as in [14]		for tolling collection
Position Enhancement Container	GPS Position Delta Latitude	same as in [14]		Optional, enable to correct positioning error by comparing the RSU accurate position with the given RSU GPS position
	GPS Position Delta Longitude	same as in [14]		Same as for GPS Latitude
	GPS Position Delta altitude	same as in [14]		Same as for GPS Latitude
	Satellite constellation locally available	Integer	1 byte	Enable the use of correction if the vehicle detects the same satellite constellation
	Trace leading to the ITSS-R	same as in [14]		Enable the improvement of the vehicle position and the computation of the time window for RSU exchange
Environment and context container	local meteorological data	Binary	1 byte	Provide local meteorological data for environmental characterization
	Road environment	Integer	byte	Provide the road environment type in which the RSU is positioned
	Traffic condition	Integer	1 byte	Provide the current traffic condition

• The third bit, when it is equal to 1, it indicates Table 1: Global Structure of the proposed CAM-I

Figure 8: Secured Message transporting CAM-I structure

Octet	Description
0	SSP version control
1 to 2	Service-specific parameter
3 to 30	Reserved for future usage

Table 2: Octet Scheme for CAM-I SSPs

the capacity of the ITSS-R to store locally a message and to transmit it as soon as possible towards a remote server (store and forward) via the private/ global network, as soon as this one is available. If this bit has the value 0, the ITSS-R does not possess this capacity.

• The bits N^o 4, 5, 6, 7 and 8 are reserved for a future usage.
• Channel: This field contains the channel used for communication
• Communication Profile (CP): The fourth byte indicates the communication profile. (5) RSU MAC Address (RM): This field indicates the MAC address of the ITSS-R.

(6) RSU IP Address (RIP): This field indicates the IP address of the ITSS-R. If IPv4 is supported the field contains the IPv4 address of the RSU. If IPv6 is supported the field contains the IPv6 address of the RSU. If both IPv4 and Ipv6 are supported, the field contains both addresses.

Figure 7 describes a typical scenario where an ITSS-R broadcasts a CAM-I, an ITSS-V receives the message and requests a needed service.

CAM-I messages are encoded in ASN.1 UPER encoding and integrated as the payload of a secured message compliant with the structure described in the standard ETSI TS 103097 [22] as described by Figure 8. For security purposes, the secured message is signed using the private key of the sender through Elliptic Curve Digital Signature Algorithm (ECDSA).

The secured message contains also a field named ITS Application ID (AID). The latter describes the type of message transported by the secured message and its value should belongs to a standardized list defined by ISO organism. For example the ITS AID value of CAM is 36, of DENM is 37. A request to ISO was sent to provide an ITS AID for CAM-I. Consequently, pending a response, we use 16490 value, which belongs to test range values. CAM-I is broadcasted via CCH channel with a frequency f as follows: 1 hertz ≤ f ≤ 10 hertz. this frequency is chosen according to the environment and context needs. As for CAM messages and in compliance with ETSI 103097 standard, for each second, the first sent message contains the sender’s certificate. For the rest, just the digest of the certificate, computed using SHA 256 algorithm is sent. Detailed ASN.1 structure of the advertisement container is described by Listing 1.

Listing 1: ASN1 definition of the Service Advertisement Container

ServiceAdvertismentContainer ::= SEQUENCE { advertisedServiceItsAid

AdvertisedServiceItsAid, serviceAccessCapabilities

ServiceAccessCapabilities, channelUsedByTheAdvertisedService

ChannelUsedByTheAdvertisedService, communicationProfileUsedForTheService

CommunicationProfileUsedForTheService, rsuMacAddress RsuMacAddress, rsuIpAddress RsuIpAddress

}

AdvertisedServiceItsAid ::= INTEGER(0..

4294967295)

ServiceAccessCapabilities ::= BIT STRING { globalNetwork (0), continuousExchangeCapability (1), storeForwardCapability (2)

} (SIZE(8))

ChannelUsedByTheAdvertisedService ::= ENUMERATED

{ cch(0), sch1(1), sch2(2), sch3(3), sch4(4), sch5(5), sch6(6)

}

Octet Position Bit Position Permission Items Bit Value 1 0 MSBit CenDsrcTollingZon ProtectionCommunicationZoneRSU 0: certificate not e/allowed to sign 1: certificate allowed to sign 1 1 PKI/ ServiceAdvertisementContainer 0: certificate not allowed to sign 1: certificate allowed to sign 1 2 Log/ ServiceAdvertisementContainer 0: certificate not allowed to sign 1: certificate allowed to sign 1 3 UseCaseToDefine1/ PositionEnhancementContainer 0: certificate not allowed to sign 1: certificate allowed to sign 1 4 UseCaseToDefine2/ ServiceEnvironmentAndContextContainer 0: certificate not allowed to sign 1: certificate allowed to sign 1 5 Reserved for future usage Not used, set to 0 1 6 Reserved for future usage Not used, set to 0 1 7 LSB Reserved for future usage Not used, set to 0 Table 3: CAM-I SSPs details

CommunicationProfileUsedForTheService ::=

ENUMERATED { btpgeonet(0), tcpipv4(1), tcpipv6(2) }

RsuMacAddress ::= OCTET STRING (SIZE(6))

RsuIpAddress ::= CHOICE { rsuipv4Andv6Address Ipv4Andv6, rsuiPv4Address IPv4Address, rsuiPv6Address IPv6Address

}

Ipv4Andv6 ::= SEQUENCE { rsuiPv4Address IPv4Address, rsuiPv6Address IPv6Address

}

3.3         Security material for CAM-I users

in order to use CAM-I service, the ITSS-R should have the authorization for. The latter is provided within its certificate. Indeed, ETSI certificates contains (1) a field called ITS AID, which includes the list of the services that the station is authorized to access and use; and (2) a field called ITS AID Service Specific Permissions (SSP), which indicates specific sets of per-

missions within the overall permissions indicated by the ITS-AID. In other words the SSP is a field that includes the different authorized options for each ITS AID. For example, if an ITSS-R can have authorization to use CAM-I service but not authorized to use PKI requests sub-service.

SSPs for CAM message are defined using 3 byte as described in ETSI EN 302 637-2 v1.3.2 [14]. SSPs for DENM message are defined using 4 bytes as presented in ETSI EN 302 637-3 v1.2.2 [23]. For CAM-I, we choose to use the octet scheme for CAM-I SSPs described by Table 2.

In Table 3 we give the SSPs adopted in SCOOP@F project for CAM-I usage.

4          Comparison of CAM-I with existing standards

In this section we produce, through Table 4, a comparison of the proposed CAM-I with WSA and SAM . One can note that CAM-I represents the advantage of using face-to-face communication instead of Geonetworking, which can performs enormous time savings. Furthermore, it is compliant with all standards, thus,

Criterion WSA SAM ESAM FSAM CAM-I Compatible architectures IEEE ETSI ETSI ISO ETSI Advertising channel CCH CCH/SCH CCH/SCH CCH/SCH CCH Advertised service   channel Any SCH (except           CH 172) SCH2-SCH4 SCH2-SCH4 SCH2-SCH4 Any SCH Message emission Frequency 1 Hz ≤f 1 Hz ≤ f ≤ 10 Hz 1 Hz ≤ f ≤ 10 Hz 1 Hz≤f 1 Hz ≤ f ≤ 10 Hz Security mechanism Digital               Signature: ECDSA Digital                Signature: ECDSA Digital                Signature: ECDSA Digital                Signature: ECDSA Digital Signature: ECDSA Access control MAC layer MAC layer MAC layer MAC layer MAC layer NACS1 Communication profile (Access/ Network/ Transport; ) WAVE/ LLC/ IPV6/ TCP; WAVE/ LLC/ IPV6/ UDP; WAVE/ LLC/ WMSP; G5/ Geonet/ BTP; G5/ Geonet/ BTP; G5/ IPv6; G5/ Geonet/ BTP; G5/ IPv6; G5/              IPv6/ TCP; G5/              IPv6/ UDP; G5/              IPv4/ TCP; G5/              IPv4/ UDP; Table 4: Comparison of advertisement services

CAM-I can be used in other deployment projects, even if they are not based on ETSI standards.

5          Conclusion and future work

In this paper we have proposed a new solution for service advertisement in Intelligent Transportation Systems’ environments called CAM-I. The latter is compliant with existing ETSI standards. Furthermore, it remedies SAM and ESAM limits for interoperability with communication protocols. CAM-I is deployed in SCOOP@F project, which represents a french deployment project that intends to implement a full ITS environment in a nationwide scale. Till the day we are writing this paper, three advertised services are deployed: (1) ITSSs’ provisioning with certificates from PKI; (2) upload of logs generated by ITSSs; and (3) Data Exchange with specific applications.

For our future works, at short term we plan to study the impact of this solution on the network’s overhead and the study of its evolution regarding the infrastructure scalability. For long term perspectives, we plan to submit CAM-I proposal to ETSI organism in the goal to standardize it.

Conflict of Interest The authors declare no conflict of interest.

1. CAMP. Security Credential Management System Proof-of-Concept Implementation. EE Requirements and Specifications Supporting SCMS Software Release 1.1. Standard, Vehicle Safety Communications 5 Consortium, May 2016.
2. B. Wiedersheim, M. Sall, and G. Reinhard. Sevecom x2014; se-curity and privacy in car2car ad hoc networks. In 2009 9th International Conference on Intelligent Transport Systems Telecom-munications, (ITST), pages 658–661, 2009.
3. PRESERVE. PRESERVE deliverable 1.3. v2x security architecture v2. PREparing SEcuRe VEhicle-to-X Communication Systems IST-269994, page 106, 2014.
4. PRESERVE. PRESERVE deliverable 1.1. security requirements of vehicle security architecture. PREparing SEcuRe VEhicle-to-X Communication Systems IST-269994, page 69, 2011.
5. van Sambeek Marcel, Ophelders Frank, Bijlsma Tjerk, van der Kluit Borgert, Turetken Oktay, Eshuis Rik, Traganos Kostas, and Grefen Paul. Architecture for Cooperative ITS Applications in the Netherlands. Technical report, DITCM Inno-vations, April 2015.
6. ECO-AT. Eco-AT European Corridor – Austrian Testbed for Cooperative Systems. Technical report, Eco-AT, 2015.
7. Hasnaâ Aniss. Overview of an ITS Project: SCOOP@F, pages 131–135. Springer International Publishing, 2016.
8. Suk-Bok Lee, Gabriel Pan, Joon-Sang Park, Mario Gerla, and Songwu Lu. Secure incentives for commercial ad dissemination in vehicular networks. In Proceedings of the 8th ACM International Symposium on Mobile Ad Hoc Networking and Computing, MobiHoc ’07, pages 150–159. ACM, 2007.
9. ISO. ISO 24102-5:2013 Intelligent transport systems – Communications access for land mobiles (CALM) – ITS station management – Part 5: Fast service advertisement protocol (FSAP). ISO, page 25, July 2013.
10. IEEE. IEEE Standard for Wireless Access in Vehicular Environments (WAVE) – Networking Services. IEEE Std 1609.3-2016 (Revision of IEEE Std 1609.3-2010), pages 1–160, April 2016.
11. ETSI. Draft ETSI DTS 102890-2: Intelligent Transport Systems (ITS), Facilities Layer Function, Part 2: Services Announcement . ETSI DTS 102890-2, February 2010.
12. ETSI. Draft ETSI TS 102 890-1 V0.0.12: Intelligent Transport Systems (ITS); Facilities layer function; Part 1 : Services Announcement (SA) specification. ETSI TS 102 890-1, January 2017.
13. IEEE. Ieee standard for wireless access in vehicular environments security services for applications and management messages. IEEE Std 1609.2-2013 (Revision of IEEE Std 1609.2-2006), pages 1–289, 2013.
14. ETSI. 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 EN 302 637-2 V1.3.2, November 2014.
15. Houda Labiod, Alain Servel, Gerard Seggara, Badis Hammi, and Jean Philippe Monteuuis. A new service advertisement message for etsi its environments: Cam-infrastructure. In New Technologies, Mobility and Security (NTMS), 2016 8th IFIP International Conference on, pages 1–4. IEEE, 2016.
16. TraicCom Kapsch, Hjelmare Anders, and Moring John. Service announcement using ieee wave service advertisement as a model. In 6th ETSI ITS Workshop 2014, 2014.
17. T. Weil. Service management for its using wave (1609.3) networking. In 2009 IEEE Globecom Workshops, pages 1–6, Nov 2009.
18. ISO. ISO/TS 16460:2016 Intelligent transport systems – Communications access for land mobiles (CALM) – Communication protocol messages for global usage. Technical report, International Organization for Standardization, September 2016.
19. ITU-T. ITU-T X.691 – Information technology – ASN.1 encoding rules: Specification of Packed Encoding Rules (PER). Standard, International Telecommunication Union, 2015.
20. ISO. Intelligent transport systems – Cooperative systems – Classification and management of ITS applications in a global context. Technical report, International Organization for Standardization, April 2014.
21. ETSI. ETSI EN 302 665 V1.1.1: Intelligent Transport Systems (ITS), Communication Architecture. ETSI EN 302 665 V1.1.1, September 2010.
22. ETSI. ETSI TS 103 097 V1.2.1: Intelligent Transport Systems (ITS), Security header and certificate formats. ETSI TS 103 097 V1.2.1, June 2015.
23. ETSI. 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. ETSI EN 302 637-3 V1.2.2, Novem-ber 2014.

(Click to view)

(Click to view)