CAM-Infrastructure: a novel solution for service advertisement in Cooperative Intelligent Transportation Systems

Cooperative Intelligent Transportation Systems (C-ITS) are gaining ground and currently are almost part of our everyday life. A C-ITS environment can provide numerous services that soon will become essential to roads’ users. The latter resides in improvement of road safety, entertainment, and commercial services. However, in order to provide such services, the C-ITS environment needs an advertisement and dissemination service for them. Indeed, users have to be aware of the available services in order to request them if needed. Current standards of service announcement show their limits, especially regarding the interoperability between communication profiles. For this reason, in this paper, we describes our new service advertisement solution called CAM-Infrastructure. The latter is compliant with ETSI standards and is deployed in SCOOP@F, a nationwide scale project.


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 (ITSS-R)). 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, ITSS-Vs 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.

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.  during the SCH interval and will make use of that service [17]. Figure 1 describes the structure of a WSA message. 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.  [19]. FSAP relies on two types of unique identifiers in its functioning:

ISO
• 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.

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.

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 Ex-tendedChannelInfos field and other needed extensions in its definition. For instance, the Extended-ChannelInfos 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 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. 3 New solution for services advertisement: CAM-I In this section we describe the details of the advertisement solution that we propose.

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. 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: (1) Service Advertisement Container; (2) Position Enhancement Container; (3) 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. 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.

Service Advertisement Container
(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.

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

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  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.  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.

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.

Comparison of CAM-I with existing standards
In this section we produce, through

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.