GB2616456A - Enhanced authorization tickets for test mode in intelligent transport systems - Google Patents

Abstract

The invention relates to Intelligent Transport Systems, ITS, providing ITS services where an ITS station, ITS-S, is tested. ITS messages broadcast by the Station Under Test, SUT, is signed with an authorization ticket, AT. The same dedicated Test ITS-application identifier, ITS AID, is used in the AT for multiple operational ITS services under test, while the specific authorizations at ITS service level are signalled in the Service Specific Permissions, SSP, section of the ATs. The SSP can signal a unique authorized service or list several of them. The testing system deduces the type, hence the format, of the broadcast ITS message (carrying the dedicated Test ITS AID) from the SSP section of the AT or from the message ITS itself. It also checks, using the SSP section, that the ITS station is allowed to use the ITS service (under test) corresponding to the deduced message type. The disclosure proposes an alternative way to identify the test response ITS messages, that does not require mirroring the regular ITS-AIDs, hence saving AID values that are rare resources. Also disclosed is an Authorization Authority, AA, configured to provide, to an ITS station under test, one or more Test authorisation tickets.

Description

ENHANCED AUTHORIZATION TICKETS FOR TEST MODE IN INTELLIGENT TRANSPORT SYSTEMS

FIELD OF THE INVENTION

The present invention relates generally to Intelligent Transport Systems (ITS) and more specifically to Cooperative Intelligent Transport Systems (C-ITS)

BACKGROUND OF THE INVENTION

Cooperative Intelligent Transport Systems (C-ITS) is an emerging technology for future transportation management that aims at improving road safety, traffic efficiency and drivers experience.

Intelligent Transport Systems (ITS), as defined by the European Telecommunications Standards Institute (ETSI), include various types of communication between vehicles (e.g. car-to-car) and between vehicles and fixed locations (e.g. car-to-infrastructure).

ITSs are not restricted to road transport as such, as they also include the use of information and communication technologies (ICT) for rail, water and air transport, including navigation systems. In general, the various types of ITS rely on radio services for communication and use dedicated technologies.

Cooperation within the ITS is achieved by exchange of messages between ITS stations, various types of ITS messages (e.g. so-called CAM, CPM, DENM) being issued when corresponding services or functions, known as "ITS services", are involved.

ITS messages are often broadcast. For security reason, they can be emitted only by an authorized ITS station. The authorization is implemented though a certificate, known as authorization ticket or AT generated through an operational certificate chain, which AT defines authorization for one or more operational ITS services.

Hence, the AT includes a list of one or more authorized ITS services, which is a list of corresponding ITS Application Identifiers (ITS AlDs). An ITS AID is coded over 1 byte (for a critical service) to 4 bytes. The ITS services are allocated respective ITS AID values or numbers according to a predefined allocation scheme defined in ISO/TS 17419.

The AT may further include Service Specific Permissions or "SSP" in association with each ITS AID to define permissions provided to the ITS station for the specific ITS service.

The ITS message and the corresponding authorization ticket are electronically signed, before being broadcast. The AT may be provided together with the broadcast ITS message, or may be provided before or after the broadcasting. The ITS message refers to the AT, for the receiving ITS station to be able to check the whole package.

ETSI TR 103 573 V1.1.1 introduces a test mode service, TMS, to verify RF and functional requirements of the ITS protocol communications. A separation of traffic, provided by usage of a dedicated certificate chain, is required to avoid affecting operational ITS stations when implementing the tests.

Although the TMS should have the ability to send proprietary message types (test mode messages), it should also be able to trigger CAMs, DENMs or other messages at their respective facility layer operational ITS services for testing purposes when in test mode state and only then. To protect operational ITS station traffic from interference as well as the test mode service from abuse, a dedicated certificate chain is used once test mode is activated. This results in the introduction of dedicated test ITS AIDs which are derived from regular ITS-AlDs. This means that every operational ITS AID (e.g. CP, CA, DEN basic services as defined in TS 17419) should have a mirror Test ITS AID.

However, this situation has serious drawbacks.

First, the ITS AID values are rare resources, in particular those 1-byte values dedicated to critical services. The duplication thus would waste rare resources, possibly preventing new critical ITS services to be added because of a lack of ITS AID 1-byte values.

Second, it is inevitable that some ITS AID be duplicated with a different number of bytes, due to the rare resources of ITS AID values. This would have a critical impact on the respective facility layer operational ITS services: the format of the ITS messages would be different (to signal either the operational ITS AID value over a first number of bytes or the Test ITS AID value over a different number of bytes) between operational ones and test ones.

However, this would not meet the following TR 103 573 requirement: the test mode should be usable in non-shielded environments without affecting operational ITS stations.

In this context, there is a need to provide an enhanced communication method for the test mode service in C-ITS.

SUMMARY OF THE INVENTION

A method of communication in an Intelligent Transport System, ITS, providing ITS services, comprises at an ITS station, ITS-S, under test, SUT: broadcasting an ITS message generated by a tested ITS service, which ITS message is signed with an authorization ticket, AT, granted to the SUT.

Correlatively, a method of communication in an Intelligent Transport System, ITS, providing ITS services, comprises at a dedicated test system, DTS: receiving, from an ITS station, ITS-S, under test, SUT, a broadcast ITS message generated by a tested ITS service, which ITS message is signed with an authorization ticket, AT, granted to the SUT.

From another perspective, an authorization authority in an Intelligent Transport System, ITS, providing ITS services, provides, to an ITS station, ITS-S, under test, SUT, one or more Test authorization tickets, ATs.

An idea of the invention is to use the same dedicated AID for multiple operational ITS services (e.g. to send CPM, DENM, CAM) under test and to signal, within the ATs, the ITS service or services authorized for test in the Service Specific Permissions section. One single Test Service AID can be used for all the ITS services under test. However, variants may contemplate using multiple AIDs for the test mode, each of the multiple AlDs be dedicated for multiple operational ITS services as defined in the SSP section.

The format (CPM, DENM or CAM format for example) of the test ITS messages carrying the dedicated Test Service AID can be deduced from the SSP section of the AT, from the message ITS itself or from a dedicated signaling in other test mode messages exchanged with the dedicated test system (DTS). In other words, as it can be deduced by the Test Mode Service in the facility layer of the ITS station under test (SUT), the other ITS services do not need to be modified.

In this respect, the present invention therefore proposes the AT includes: an ITS-application identifier, AID, field set to a value signaling a test mode service, and an associated Service Specific Permissions, SSP, field set to a value authorizing the tested ITS service.

Optional features of these embodiments of the invention are defined in the appended claims. Some of these features are explained here below with reference to a method, while they can be transposed into device features.

In some embodiments, the SUT broadcasts a second ITS message generated by a second tested ITS service (different from the first one), which ITS message is signed with a second (may be the same AT or a different one) authorization ticket, AT, granted to the SUT, wherein the second AT includes: an ITS-application identifier, AID, field set to the value signaling the test mode service, and an associated SSP field set to a value authorizing the second tested ITS service.

Correlatively, the DTS receives, from the SUT, a second broadcast ITS message generated by a second tested ITS service, which ITS message is signed with a second authorization ticket, AT, granted to the SUT, wherein the second AT includes: an ITS-application identifier, AID, field set to the value signaling the test mode service, and an associated SSP field set to a value authorizing the second tested ITS service.

With the present invention, two test ITS messages for different tested ITS services therefore carry the same ITS AID, the authorized ITS services being specified in the SSP field. The SSP field value in the second AT may be different from the SSP field value in the AT. Alternatively, the same AT may be used with the two broadcast ITS messages.

In some embodiments, the SUT is configured, when not being under test, to broadcast an operational ITS message generated by the tested ITS service, which ITS message is signed with an operational (may be the same AT or a different one) authorization ticket, AT, granted to the SUT, wherein the operational AT includes an ITS-application identifier, AID, field set to a value authorizing the tested ITS service.

In other words, the authorization for an ITS station to broadcast the same type of ITS message (CAM, DENM, CPM) is different when the message is for test purpose (ITS AID is set to the test mode and the SSP defines the ITS service tested) or when it is for operational purpose (ITS AID is directly set to the ITS service concerned).

In some embodiments, the broadcast ITS message includes an ITS AID set to the value signalling the test mode service. This makes the link with the authorization as set in the AT. In some embodiments, the ITS message is broadcast responsive to a test request having an ITS AID field set to a Test Mode ITS AID, and the value signaling a test mode service is set to the Test Mode ITS AID. In that case, no other ITS AID is needed for test purposes, except Test Mode ITS AID already defined in TR 103 573.

In some embodiments, the SSP field is configured to authorize at the most one ITS service. To validate the authorization, the one ITS service must be the tested ITS service.

In variants, the SSP field is configured to authorize a plurality of ITS services.

For example, the SSP field may include a bitmap, each bit of which signals whether a corresponding ITS service is authorized or not.

In another example, the SSP field may include a list of one or more identifiers, each identifier identifying one of the authorized ITS services.

In some embodiments, the SSP field includes a first subfield identifying the tested ITS service and a second subfield defining service specific permissions for the tested ITS service.

This allows defining various permissions within a tested ITS service, in particular when corresponding to a regular ITS service. For example, the second subfield defines a format of the broadcast ITS message between a plurality of message formats available for the tested ITS service. Depending on the value of the second subfield within the SSP field, an ITS message may be according to a first or second message format.

In some embodiments, the AT includes a single pair of ITS AID field and SSP field.

Indeed, a dedicated test AT can be generated that is limited to authorizations for the test mode. In variant where multiple ITS AID values can be used to group ITS services into multiple groups under the test mode, the AT may include a plurality of such pairs, wherein the ITS AID field of each pair is set to a value signaling a test mode service (i.e. different from the operation ITS services).

In some embodiments, the method at the DTS further comprises: determining a message format for the received broadcast ITS message, and decoding the broadcast ITS message using the determined message format.

For example, the message format may be determined from the broadcast ITS message itself, e.g. from a header thereof In variants, the method at the DTS further comprises retrieving an authorized ITS service from the SSP field value associated, in the AT, with an ITS AID field provided in the received broadcast ITS message, wherein determining the message format is based on the retrieved authorized ITS service.

Here, the SSP field allows the message format to be determined. Through the determination, the authorization is indirectly validated because the subsequent decoding is only possible for the authorized ITS service or services.

This implementation is particularly efficient when a single authorized ITS service is signaled through the SSP field. However, should various authorized ITS services be signaled, the DTS may test each of the corresponding message formats.

In other embodiments, the method at the DTS further comprises: determining an ITS service corresponding to the determined message format, and verifying that the determined ITS service is authorized by the SSP field.

Correlatively, the invention also provides an Intelligent Transport System, ITS, station, either SUT or DTS, in an ITS comprising at least one microprocessor configured for carrying out the steps of any of the above methods.

An authorization authority, AA, is also provided in an Intelligent Transport System, ITS, providing ITS services, which AA is configured to provide, to an ITS station, ITS-S, under test, SUT, one or more Test authorization tickets, ATs, wherein each Test AT includes: an ITS-application identifier, AID, field set to a value signaling a test mode service, and an associated Service Specific Permissions, SSP, field set to a value authorizing a tested ITS service.

Another aspect of the invention relates to a non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in an Intelligent Transport System, ITS, station of an ITS, causes the ITS station to perform any method as defined above.

The non-transitory computer-readable medium may have features and advantages that are analogous to those set out above and below in relation to the communication methods and ITS stations.

At least parts of the methods according to the invention may be computer implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system". Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium.

Since the present invention can be implemented in software, the present invention can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible carrier medium may comprise a storage medium such as a hard disk drive, a magnetic tape device or a solid state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g. a microwave or RF signal.

BRIEF DESCRIPTION OF THE DRAWINGS

Further advantages of the present invention will become apparent to those skilled in the art upon examination of the drawings and detailed description. Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings.

Figure 1 illustrates an exemplary ITS in which embodiments of the invention may be implemented.

Figure 2 illustrates security mechanisms implemented in an ITS.

Figure 3 illustrates the verification of a received ITS message based on a digital signature and an authorization ticket.

Figure 4 illustrates schematically the test mode service in a V2X architecture. Figure 5 illustrates the flow of messages during a test mode activation.

Figure 6 illustrates the flow of messages during a test item execution.

Figure 7 illustrates, using a flowchart, operations at an ITS station to process an ITS message received from another ITS station.

Figure 8a illustrates a first embodiment of signalling tested regular ITS service or services using a SSP field in an authorization ticket.

Figure 8b illustrates a variant of the first embodiment of signalling tested regular ITS service or services using a SSP field in an authorization ticket.

Figure 9 illustrates, using a flowchart, operations at an ITS station to process an ITS message received from another ITS station when implementing the signaling of Figure 8a or 8b. Figure 10 illustrates another embodiment of signalling tested regular ITS service or services using a SSP field in an authorization ticket.

Figure 11 illustrates yet another embodiment of signalling tested regular ITS service or services using a SSP field in an authorization ticket.

Figure 12 illustrates, using a flowchart, operations at an ITS station to process an ITS message received from another ITS station when implementing the signaling of Figure 10 or 11.

Figure 13 illustrates an example of a communication device, configured to implement at least one embodiment of the present invention.

The same references are used across different figures when designating same elements.

DETAILED DESCRIPTION

The invention will now be described by means of specific non-limiting exemplary embodiments and by reference to the figures.

Intelligent Transport Systems (ITS) standards are developed by different organizations: the European Telecommunication Standards Institute (ETSI), the European Committee for Standardization (CEN), the International Organization for Standardization (ISO), the Society of Automotive Engineers (SAE).

ITS standards define a general architecture, specified in ETSI EN 302 665 and ISO 21217, including ITS stations (denoted ITS-S) which can be vehicles, Road Side Units (RSU), Vulnerable Road Users (VRU) carrying an ITS equipment (for instance included in a smartphone, a GPS, a smart watch or in a cyclist equipment), or any other entities or infrastructures equipped with an ITS equipment, as well as central subsystems (back-end systems and traffic management centers). ITSs may support various types of communications, for instance between vehicles (vehicle-to-vehicle (V2V), that refers in general to all kinds of road users, e.g. car-to-car) or between vehicles and fixed locations (vehicle-to-infrastructure (V2I) and infrastructure-to-vehicle (I2V), e.g., car-to-infrastructure) and are not restricted to road transport. For instance, an ITS may also deal with information related to rail, water and air transport, including navigation systems.

Cooperation within the ITS is achieved using exchange of messages (ITS message) between the ITS stations. These exchanges of messages are performed through wireless networks, referred to as V2X networks, examples of which may include 3GPP LTE-Advanced Pro, 3GPP 5G and IEEE 802.11p technology.

Different types of ITS messages are exchanged when different services or functions, here below "ITS services" or "operational ITS services", are involved, for example Cooperative Awareness (CA) basic service, Decentralized Environmental Notification (DEN) basic service, Collective Perception (CP) basic service, and so on. For instance, a Cooperative Awareness Message (CAM -as defined in the ETSI EN 302 637-2 v1.4.1) can be sent by a vehicle ITS-S to share its current state (e.g. position, speed, length, width, angle) through the CA basic service. In another example, a Collective Perception Message (CPM -ETSI TR 103 562 v2.1.1) can be sent by an ITS station equipped with sensors, in order to share its perceived environment, notably the characteristics of its sensors, and a list of perceived objects, through the CP basic service. Similarly, a Decentralized Environmental Notification Message (DENM -ETSI EN 302 637-3 v1.3.1) can be sent by an ITS station to alert receiving ITS stations of a detected event.

In general, ITS messages are not encrypted when exchanged on V2X communications. However, the integrity of ITS messages can be verified as a digital signature is provided by the sending ITS station. This ITS station sending the ITS message is called the "originating" ITS station. This signature is based on digital certificates owned by the originating station. For this purpose, each station receives one or more certificates through a Public Key Infrastructure (PKI). These certificates aim at ensuring that the originating ITS station has the privilege/authorization to transmit specific ITS messages.

Privacy is ensured within the PKI mechanism thanks to the two following principles: -Pseudonymity ensuring that an ITS station may use a resource or service without disclosing its identity but can still be accountable for that use; -Unlinkability ensuring that the greater the distance in time and space between two transmissions from a same device, the harder it is to determine that those two transmissions did in fact come from the same device.

To this end, the ITS stations are provisioned with a set of Pseudonym Certificates referred to as authorization tickets (AT) delivered by a certification authority. Thus, when exchanging ITS messages within the ITS network, each ITS message, made of an unencrypted message, is accompanied with a given AT and the above digital signature that validate the authenticity of the transmitting ITS station and the integrity of the message. The anonymity of the transmitting ITS station is ensured because each AT is associated with a pseudonym, also called ITS identifier, used by the ITS station to communicate within the ITS.

Besides, ATs are regularly changed according to a temporal AT change strategy performed by each ITS station. Therefore, as the change of AT causes the change of the pseudonym and the digital signature used by the station, a regular change of AT over time makes the tracking by the receiving stations very difficult or impossible, in a classic operating mode of the ITS. Indeed, typically, the stations of the ITS (the vehicles or the vulnerable road users VRU) may share their current state (such as their position, speed, acceleration...) using a Cooperative Awareness Message (CAM), as defined in the ETSI EN 302 637-2, (or VRU Awareness Messages (VAM) as ETSI TR 103 300). Such messages are received by the receiving ITS stations and help them to determine their local environment.

This functioning of an ITS is now described with more details with reference to Figures Ito 3.

Figure 1 illustrates an exemplary typical ITS in which embodiments of the invention may be implemented.

ITS 100 comprises a plurality of fixed and mobile ITS stations 110, 120, 130, 140. In the example shown for illustrative purposes, moving vehicles 120, 130 and mobile phone 140 contain each an on-board unit (OBU) or ITS station. An ITS station inside a vehicle is called Vehicle ITS station', and an ITS station carried by a pedestrian or a cyclist is called VRU (Vulnerable Road User) ITS station'. Fixed road side entity 110 contains a road side unit (RSU) 111 also having a roadside ITS station. Central subsystems (not shown), such as back-end systems and traffic management centers, may also form part of ITS 100.

The reference architecture of an ITS station is defined in the version V1.1.1 of the ETSI EN 302 665 specification.

An ITS station may embed or be linked to one or more local sensors that may provide information about the ITS station position and/or motion or analyze or scan an area in the vicinity of the ITS station to detect objects.

For instance, vehicles 120, 130 and mobile device 140 embed perception sensors 125, 135, 145 referred to as embedded perception sensors, which may be based on different technologies such as camera, radar, radio and lidar. The output of the embedded perception sensors is usually a list of perceived objects including each corresponding description information.

Similarly, Fixed road side entity 110 embeds a Roadside Surveillance Monitoring System (RSMS) 112. RSMS 112 includes in particular a set of perception sensors, here video cameras 115 scanning the area 118, and a Video Content Analytics (VCA) module (not shown). VCA module analyzes the stream captured by the sensors/video cameras 115 in order to detect objects, referred to as perceived objects, and output a list thereof with corresponding description information. As RSMS 112 and RSU 111 are wire connected, RSMS 112 is considered as an embedded perception sensor for RSU 111.

The description information of a perceived object includes its dynamic state and properties (for instance position, speed, acceleration, class, dimension, age, and so on).

Cooperation within ITS 100 is achieved by exchange of ITS messages 150 between the ITS stations: V2V (vehicle-to-vehicle) messages, V2I (vehicle-to-infrastructure) messages and/or I2V (infrastructure-to-vehicle) messages. Various types of ITS messages exist to share information, alert, inform and/or warn users and/or vehicles of ITS 100. An ITS message 150 is made of a header 151 (including multiple fields) and payload 152.

An ITS station that sends an ITS message is referred to below as an originating ITS station while an ITS station that receives an ITS message is referred to below as a receiving ITS station.

A so-called Cooperative Awareness Message (CAM as defined in the version 1.3.1 of the ETSI EN 302 637-2 specification) is sent by any originating vehicle ITS station to share information about itself with the other ITS stations, for instance its current state (e.g. positron, speed, length, width, angle). A CAM is sent by a corresponding operational service (or application) in the facility layer of the ITS protocol stack of the ITS station, namely the Cooperative Awareness basic service.

More specifically, a so-called Vulnerable Road User Awareness Message (VAM as defined in version 2.1.1 of ETSI TS 103 300-3 specification) may be sent by any originating VRU ITS station to share information about itself with the other ITS stations, for instance its current state (e.g. position, speed, length, width, angle).

A so-called Decentralized Environmental Notification Message (DENM) is sent by an originating ITS station to alert receiving ITS stations of an event. A DENM is sent by a corresponding operational service in the facility layer of the ITS protocol stack of the ITS station, namely the Decentralized Environmental Notification basic service.

A so-called Collective Perception Message (CPM as defined in the version 2.1.1 of the ETSI TR 103 562 specification and/or in the version 0.0.22 of the ETSI TS 103 324 specification) is sent by any originating ITS station to share its perceived environment retrieved from its embedded perception sensors with receiving ITS stations. A CPM is sent by a corresponding operational service in the facility layer of the ITS protocol stack of the ITS station, namely the Collective Perception basic service.

All exchanged messages may be encoded using for example the ASN.1 Unaligned Packed Encoding Rules as defined in Recommendation ITU-T X691/150/1EV 8825-2.

To secure V2X communications within ITS 100, a Public-Key-Infrastructure (PKI) (as defined in the version 1.1.1 of the EIS! TS 102 731 specification) may be used that provides security and verification required to trust the originating ITS station. The PKI-based security may be implemented through the use of certificates delivered by a certification authority to the ITS stations. Each ITS message exchanged is made of a non-encrypted message 150 accompanied with a digital signature 170 and a Pseudonym Certificate 160 that validate the authenticity of the originating ITS station and the integrity of the message, while keeping anonymity of the originating ITS station. The digital signature 170 is computed (e.g. as a hash) on the message 150 and the Pseudonym Certificate 160 (e.g. on a concatenation thereof). The Pseudonym Certificate 160 is delivered by a certification authority. Such a certificate is referred to as an authorization ticket and ensures that the originating ITS station has the privileges and authorizations to transmit specific ITS messages. The authorization ticket is verified by the receiving ITS station.

Basically, an ITS station is required to obtain specific credentials from dedicated certification authorities in order to access the ITS network 100 and make full use of the available ITS application, services and capabilities, such as sending ITS messages. The certificate may depend on the capabilities of the ITS station (for instance its sensors or the Video Content Analytics (VCA) it can run) but also the role and the security level of the owner of the station. For example, only an ITS station with sensors with a sufficient quality of detection of a pedestrian and/or a cyclist may be authorized to send CPM messages containing VRU information. Another example is the case when the owner can demonstrate that its equipment is regularly controlled against hacking, then it may obtain a certificate characterizing a higher level of trust.

An example of a PKI-based mechanism 200 is illustrated in Figure 2. The PKI-based security is implemented through the use of certificates delivered by a certification authority to the ITS stations.

As part of the ITS station manufacturing process, a set of information elements 240 associated with the identity of the ITS station is established within the ITS station itself and within a so-called Enrolment Authority (EA) 235 as defined in the version 1.2.1 of the EIS! TS 102 941 specification. The set of information elements 240 is then registered within the ITS station and the EA 235.

As an example, the set of information elements 240 may comprise: -a canonical identifier: it is an identifier that uniquely identifies the ITS station. In other words, the canonical identifier is equivalent to the ITS station identity.

-a public/private key pair for cryptographic purpose based on PKI mechanism. Based on this set of information elements, the EA 235 generates an Enrolment Certificate 245 which contains a pseudonym provided to the ITS station during the enrolment process. The pseudonym is used for anonymity and is referred to as Enrolment Identity (Enrolment ID).

Next, after having enrolled with the EA 235, the ITS station requests an Authorization Authority 205 (AA) for specific services and permission within the EA's domain and AA's Authorization context. In particular, the AA 205 checks the Enrolment Certificate 245 included in the request (more specifically, the AA checks the Enrolment ID included in the Enrolment Certificate 245). Then, if the Enrolment Certificate 245 is suitable, the AA 205 provides multiple Pseudonym Certificates referred to as Authorization Tickets (AT) 215. Each AT 215 includes a pseudonym of the ITS station to be used in V2X communication, to ensure its privacy when interacting within the ITS network.

From this security procedure, an ITS station 210 selects an AT among its available multiple ATs 215 for a given period before switching to another AT in order to prevent the linkability. The change of AT may be performed according to an AT change strategy.

The message 225 sent by the ITS station 210 together with the AT 230 corresponds to message 150 with AT 160 (the digital signature 170 is not shown in Figure 2).

Rather than accompanying the ITS message 225 with the AT 230, the ITS message 225 may contain a link to the AT 230 used, which is transmitted by other means, e.g. in a different message or using another transmission mean (prior to the ITS message or after the ITS message is sent, e.g. upon request from the receiving ITS station).

The pseudonym ITS identifier from the selected AT 230 may also be indicated in the header of the ITS message 225. In variants, an ID value linked to the ITS pseudonym may be indicated in the ITS message header, selected by the transmitting ITS station 210. Thus the change of the value of the ID reflects the change of the selected AT 230 and the associated pseudonym.

An ITS station may thus have several valid certificates in the same time, all having different pseudonyms. The station can then select different certificates for different messages. Due to multiple pseudonyms, this may allow avoiding station tracking and thus ensure privacy protection. In addition, as a certificate contains a list of several authorizations, different authorizations may be used by a station depending of the particular context.

When receiving a message 225, the receiving ITS station 220, verifies the AT 230 in order to ensure that the transmitting ITS station 210 has the privileges and authorizations to transmit specific ITS messages 225.

Figure 3 illustrates such verification of received message 150 accompanied with a digital signature 170 thereof The structure of the signed message 150 and its certificate AT 160 is described in Annex A.2 of the version 2.0.1 of the ETSI TS 103 097 specification. The structure of the certificate is a particular usage of the general signature defined in the specification IEEE 1609.2 and it is similar to the signature system defined in SAE J2945.

As illustrated, the signed message comprises the data 150 to be signed and a signature 170. The data to be signed comprise the payload 152 of the message, and as header 151, an ITS Application IDentifier ITS-AID 300 of the ITS application or service generating the message, and optionally other information such as the generation time and the generation location, which can be omitted if they can be deduced/inferred from the payload content. The signature 170 contains an identifier of the signer, i.e. the ITS-S ID (IDentifier) which is the pseudonym used by the originating ITS station, and an encrypted hashed value of the data being signed.

The pseudonym ITS-S ID allows the corresponding AT 160 to be retrieved by the receiving ITS-S. In other words, the pseudonym can be used as a reference to the AT 160. The AT 160 can be for example requested by the receiving ITS station to an Authorization Authority or obtained from a secure memory if it was previously received. As previously mentioned, the emitter (originating) station may have several such identifiers/pseudonyms attributed by the Authorization Authority and thus it may obtain as many certificates as identifiers/pseudonyms.

The certificate may specify an authorized period of time, an authorized location and a list of authorized applications with specific permissions.

For instance, the certificate 160 contains a validity period 305, a validity region 310 and a verification key 315. The verification key allows verification of the correctness of the encrypted hashed value included in the digital signature 170. The AT 160 also contains a list 320 of one or more application or service permissions (321, 322), each comprising an ITS Application IDentifier (ITS-AID 1, ITS-AID2) defining the authorized ITS service and a Service Specific Permission (SSP1, SSP2) definition permissions for the corresponding authorized ITS service. The ITS AID identifies an ITS service or application which uses some types of messages and that is authorized by the AT 160. Currently in ETSI TS 102 965 V1.4.1, one ITS AID is defined per message type (for example CAM, DENM, CPM, VAM), i.e. per operational ITS service. The allocation of ITS AID values to the ITS services is defined by a predefined allocation scheme provided in ISO/TS 17419. The ITS AID are encoded over 1 to 4 bytes. The shorter the ITS AID, the more critical the corresponding ITS service. For example, ITS AID equal to 36 (or 0x24) is assigned to the CA basic service, while ITS AID equal to 37 (or 0x25) is assigned to the DEN basic service The AT 160 thus provides the list of ITS messages that the ITS station is authorized to send.

The SSP associated with an ITS AID identifies some restrictions (or authorizations / permissions) with respect to the ability of the concerned ITS station in emitting an ITS message by the associated ITS service. This may restrict the type of data that can be provided within the ITS message. For example, an ITS station emitting a CAM may be entitled to send CAMs for a specific vehicle role only (emergency vehicle, public transport, ...). No generic encoding of the SSP field is defined for the time being; each facility layer service may use its own SSP format.

The encoding of each pair {ITS-AID, SSP} 321, 322 is defined in TS 103 097, section 6.9.

As illustrated by Figure 3, the digital signature 170 is checked using the key 315, usually by computing again the hash on the ITS message 150 accompanied with the AT 160, and then comparing the result with the hash value provided in the digital signature.

The time and location of the ITS message 150 can also be checked against the validity period 305 and validity region 310 respectively.

The authorization is also checked using ITS-AID 300 of the ITS message: the message can be processed only if ITS-AID 300 is present in the list 320 of permissions. In the affirmative, an additional check of the content of the message payload 152 with the SSP associated with the ITS-AID can be made to ensure e.g. the emitting ITS station has authorization to provide the payload data.

ETSI TR 103 573 V1.1.1 describes a test mode for the ITS protocol stack. The test mode provides the ability, through tests conducted by a Dedicated Test System (DTS), of verifying RF and functional requirements of the ITS protocol communications of an ITS station referred to as System Under Test (SUT). A DTS 190 is schematically illustrated in Figure 1 which conducts tests on ITS-S SUT 120. The DTS 190 and SUT 120 may be data connected through a dedicated wired link or through over-the-air messages.

Use cases for test mode include repair/maintenance of ITS vehicles in authorized workshops, periodic technical inspection, end-of-line or initial test, in-the-field inspection.

Verification of RF and functional requirements may include verifying one, all or part of Reception ability, Transmission ability, Reception quality Transmission quality, Transmission power, Protocol conformance after software-update, Functionality of accepting certificates, Functionality of rejecting certificates, Protocol conformance after software-update, Functionality of certificate revocation list (CRL) and certificate trusted list (CTL), Maximum performance test/stress test, Functionality of message content verification (non exhaustive list).

The test mode requires access to functionality located in the facility layer of the ITS protocol stack as well as new functionality to conduct these tests. A Test Mode Service (TMS) with specific permissions to access this functionality is defined, having its own Test Mode AID.

The test mode is usable in non-shielded environments without affecting operational ITS stations.

Hence, a separation of traffic, provided by usage of a dedicated certificate chain, is implemented. The Test Mode service is thus additional to the operational ITS services already existing in the ITS stations As explained below, the operational ITS services may also be executed for test purposes.

As shown in Figure 4, the TMS is located within the facility layer of the SUT. It has the ability to send proprietary message types (test mode messages) and have specific permissions to access ITS stations protocol functions. TMS receives messages from the DTS 190 over a dedicated BTP port. It is also able to trigger CAMs, DENMs or other messages generated by the conventional operational ITS services at their respective facility layer services, for testing purposes when the SUT is in test mode state and only then. To protect operational ITS station traffic from interference as well as the test mode service from abuse, a dedicated certificate chain is used once the test mode is activated. These certificates have stronger restrictions than operational certificates and apply separate SSPs to the service. Only the DTS has permission to trigger events at the SUT through test mode messages, while the SUT only receives certificates with permissions to send test mode message response messages.

As shown in Figure 5, test mode of the SUT 120 is activated by an authorized ITS-S DTS 190. A test mode triggering message 500 from the DTS is signed with an AT carrying a test mode dedicated ITS-AID, and transmitted to the SUT. The AT is provided by a dedicated test mode AA which optionally may also issue regular ATs. Optional messages 505 and 510 show the optional request from the SUT to obtain the test mode AT of the DTS, in order to validate, decode and then execute the received test mode triggering message 500.

Once the initial triggering request 500 has been verified, the SUT retrieves (messages 515, 520) its own test mode AT or ATs with its enrolment credentials from the test mode AA. If the retrieval has been successful, the SUT awaits a test mode trigger message 525 for test mode activation addressed only at the SUT. Once the SUT has retrieved the test mode AT, it changes its currently used AT to the time and area limited test mode AT and acknowledge successful test mode activation 530 to the DTS.

All further messages, while the SUT is under test, will be signed with the test mode AT until it expires.

Figure 6 illustrates the test procedure where a test item (to verify any RF and functional requirement defined above) is triggered (message 600) by the DTS 190 based on its legitimated SSPs. The test triggered in the SUT 120 results in a response 605 being either an ITS message generated by an operational ITS service (i.e. message of a certain type such as CAM, DENM, CPM, ...) or a (proprietary) test mode message carrying test results or both. We call (proprietary) test mode message, a message which is specific to the test mode service and thus may be standardized in the test mode service.

Identification of the type of message is important as it allows the SUT to direct the received ITS messages (after validation of the AT) to appropriate ITS services, for correct decoding (given their respective formats).

As mentioned above, the (proprietary) test mode message can be identified On the message and the corresponding AT) using the Test Mode ITS-AID corresponding to the test mode.

The other ITS messages generated by the operational ITS services cannot use the corresponding (regular) ITS-AlDs to avoid interference. TR 103 573 hence require the introduction of dedicated test ITS-AlDs which are derived from regular ITS-AlDs, meaning that every ITS-AID has a mirror Test ITS-AID.

Figure 7 illustrates, using a flowchart, operations at an ITS station to process an ITS message 150 received from another ITS station, according to conventional processing. It applies for any ITS message, be it an operational ITS message or a test response ITS message. Focus is however made below on the DTS when processing a test response ITS message 605 received from the SUT (i.e. a message for test purposes) in response to a test item request 600.

A new ITS message is received from the SUT at step 700. Step 705 consists for the security layer of the DTS to verify the validity of the ITS message 150 based on the accompanying digital signature 170 and on the corresponding AT 160. Details on the verifications are provided above.

Step 710 is executed by the facility layer only when the verification is positive. The layer checks whether the ITS AID 300 specified in the ITS message (which is thus listed in the AT 160) is the Test Mode AID, in which case the ITS message is a (proprietary) test mode message.

In the affirmative, the TMS of the DTS processes (i.e. decodes) the response message according to the proprietary format. This is step 715.

Otherwise, the TMS activates the ITS service corresponding to ITS AID 300. In the scenario of tests, the (regular) ITS service corresponding to the Test ITS-AID mirroring the regular ITS-AID is activated. The activated ITS service then processes the received ITS message in a conventional way. This is step 720.

The present invention proposes an alternative way to identify the test response ITS messages, that does not require mirroring the regular ITS-AlDs, hence saving AID values that are rare resources.

Instead of using a new ITS AID per operation (regular) ITS service, it is proposed to use one and the same new ITS AID (let say a test ITS AID) for a plurality of operation (regular) ITS services and to distinguish between the ITS services of this plurality using the associated SSP field provided in the AT 160 (within each pair 321, 322).

In this respect, the AT that is used by the SUT in association with a test response 605 regarding a tested ITS service includes: an ITS-application identifier, AID, field set to a value signaling a test mode service, and an associated Service Specific Permissions, SSP, field set to a value authorizing the tested ITS service.

The value signaling the test mode service may be the Test Mode ITS AID, i.e. the same value is used by the DTS and the SUT when requesting the test (message 600) and responding thereto (message 605). In other words, when the ITS message is broadcast responsive to a test request having an ITS AID field set to a Test Mode ITS AID, the value signaling a test mode service is set to the Test Mode ITS AID. In that case, no other ITS AID is needed for test purposes, except such Test Mode ITS AID already defined in TR 103 573. Of course, other test ITS AID values (over 1 to 4 bytes, available in the allocation scheme of TS 17419) may be used to distinguish from Test Mode ITS AID as used by the DTS for its test requests, as defined in TR 103 573.

In some embodiments, two or more test mode services may handle two or more respective groups of regular ITS services. Therefore, two or more test ITS AlDs for test mode associated with the two or more respective groups may coexist and be available. For example, a first test ITS AID may correspond to a group comprising the CA and DEN basic services (and thus correspond to CAMs and DENMs), while a second and different test ITS AID may correspond to a group comprising the CP and VA (VRU Awareness) basic services (and thus correspond to CPMs and VAMs).

Whatever the embodiment, the test ITS AID signalled in the test response ITS message 605 does not allow to discriminate between the various regular ITS services that are available (possibly a subgroup thereof) for test purposes. This raises two issues the present invention solves in one or more embodiments.

First, the DTS 190 receiving the test response ITS message 605 must be able to know which message type (e.g. CAM, CPM, DENM) it is, in order to decode (e.g. parse) it properly. Indeed, each message type has its own message format (set of fields).

Second, the authorizations provided by the AT 160 are at ITS AID level, meaning their conventional use does not allow the permissions to be managed at ITS service level when a general test ITS AID is used for a plurality of tested regular ITS services.

That is why the signalling of the tested regular ITS service or services is provided in the SSP field of the AT 190 according to the present invention. Indeed, this allows the authorizations to be specified at ITS service level, while indicating which possible message type or types the test response ITS message 605 complies with.

Figure 8a illustrates a first embodiment of signalling the tested regular ITS service or services using a SSP field 800 in the AT 160. It is recalled that the SSP field considered is the one associated with the relevant test ITS AID, within the list 320.

The SSP field is made of a plurality of bytes, here 3 bytes. Any number up to 31 bytes may be used. A first part 805 of the SSP field 800, here the first byte, is used to signal a version number of the SSP field and a length of the SSP field. A second part 810 of the SSP field 800, here the remaining bytes, is used to store an identifier of the tested ITS service. This configuration authorizes at the most one ITS service. The first part 805 may be omitted when the

format of the SSP field 800 is predefined.

For example, the SSP subfield 810 may be set to 37 (0x25 in the two last bytes) to signal the tested ITS service is the regular DEN basic service. In this example, the value set in the SSP subfield 810 is the regular ITS AID allocated to the tested ITS service as defined in the allocation scheme of TS 17419.

The SSP field 810 may have a length of four bytes to be able to reproduce any AID value as defined in the allocation scheme of TS 17419. In another embodiment the length may be restricted to two bytes in case the test mode is limited to test services with one or two-byte AlDs which are the most important services useful for safety of the ITS system.

As represented in Figure 8b, the SSP of the test mode may also contain one or more other fields, e.g. field 820, indicating other types of authorizations for the test mode. These additional fields may be of various lengths, preferably an integer number of bytes, for example, a 1-byte field or a 2-byte field.

Tested service permission field 820 may include the service specific permissions corresponding to the regular ITS service specified in Tested AID field 810. Such field 820 is thus interpreted in function of the content of Tested AID field 810.

For example, the regular CA basic service uses a 2-byte SSP which indicates for example if the vehicle is a public transport or an emergency vehicle. Therefore, when field 810 identifies the CA basic service (e.g. field 810 = 36), field 820 is coded onto 2 bytes and indicates the service specific permission of the CA basic service (public transport or emergency vehicle for example). With this implementation, the SUT is entitled to send two test mode messages 605 having the same Test ITS AID but with two different ATs defining two different structures of message payload. For example, the two ATs have the same value in field 810 (identifying e.g. the CA basic service with value 36) but two different values for the tested service permission field 820 indicating the different structures of the test CAM message payload. Hence, field 820 defines a format of the test response ITS message 605 between a plurality of message formats available for the tested ITS service.

When the same Test Mode AID is used for all the tested ITS services On that case field 810 may be void or set to 0 or the Test Mode AID or any predefined value), tested service permission field 820 may also be used to indicate specific permission related to the (proprietary) test mode response. In addition, it is to be noted that, in that case, the test item request 600 and its associated AT sent by the DTS 190 include the Test Mode AID. Tested service permission field 820 of the AT for the DTS 190 may then defines some permissions related to the request (field 810 of the SSP in the AT of the request is void or set to 0 or the Test Mode AID or the predefined value mentioned above). As an example, a status of the DTS 190 (e.g. police vehicle or not) may be defined using one bit of field 820. Such status read from the request 600 may be used by the SUT to determine whether a user authorization is required to execute the test item request 600: if the test item request 600 is sent by a vehicle having an AT indicating "police", no user authorization is required, otherwise an authorization is required.

Tested service permission field 820 may be a bitmap, each bit of which codes a specific permission. The order of the bits (permissions) within the bitmap and the length of the bitmap depend on the value of field 810. Of course, other permission coding within field 820 can be contemplated.

In these embodiments, different SSP subfields 810 are therefore used for different tested ITS services. This means that when the SUT 120 broadcasts a second test response ITS message 605 generated by a second tested ITS service (different from the first tested ITS service) in response to another test request 600, the second AT includes: an ITS-application identifier, AID, field set to a value signaling a test mode service.

This may be the same test ITS AID as for the first broadcast message, and an associated SSP field set to a different value authorizing the second tested ITS service. In the example above, the SSP subfield 810 may be set to 37 for the first AT (signaling the DEN basic service) while the SSP subfield 810 of the second AT may be set to 36 (signaling the CA basic service).

Note that the same SSP subfield values may signal other ITS services if the test ITS AID is a different one (e.g. in the above embodiments where groups of tested ITS services are associated with respective test ITS AlDs).

Advantageously, the embodiment of Figure 8a directly indicates to the DTS 190 the message type, hence the message format of the test response ITS message 605. Indeed, the SSP field indicates a unique tested ITS service, hence a unique message format. The process at the DTS is thus made simpler.

In specific embodiments where the Test Mode AID is used for all the tested ITS services, the SSP field may be void or set to 0 (or the Test Mode AID or any predefined value) to signal the test response ITS message 605 is a (proprietary) test mode response, and not a message according to a regular ITS service.

Figure 9 illustrates, using a flowchart, operations at an ITS station to process an ITS message 150 received from another ITS station, according to embodiments of the invention. As for Figure 7 above, focus is preferably made on the DTS when processing a test response ITS message 605 received from the SUT (i.e. a message for test purposes) in response to a test item request 600. However, the same process applies to any ITS station receiving an ITS message As in Figure 7, a new ITS message is received at step 700 by the network layer.

Step 705 consists for the security layer of the DTS to verify the validity of the ITS message 150 based on the accompanying digital signature 170 and on the corresponding AT 160. This step 705 allows the DTS to retrieve the pair {ITS AID, SSP} 321, 322 from the AT 160, corresponding to the ITS AID 300 specified in the received ITS message.

Step 910 is executed by the facility layer only when the verification is positive. It checks whether the ITS AID 300 signals a test mode service.

Depending on the embodiments above, this may consist in checking whether the ITS AID 300 equals the Test Mode AID or a predefined Test ITS AID associated with one of the groups of ITS services for test purposes.

In the negative meaning a regular ITS AID is used, the TMS activates the corresponding operational ITS service. The activated ITS service then processes the received ITS message in a conventional way. This is step 720.

In the affirmative of test 910, the SSP 800 corresponding to ITS AID 300 in the AT 160 is retrieved at step 915. Its validity is checked at optional step 917. This may for example mean checking tested service permission field 820 has the correct length given the value of the tested ITS service read from the SSP field 810 (hence step 917 is optional for the case where field 820 is provided). As mentioned above, the value is the SSP field (except the first byte) may be the regular ITS AID of the tested ITS service, or any other predefined identifier. If the SSP 800 is not valid, the message can be rejected (935).

An identification of the tested ITS service makes it possible to know the message format of the received ITS message. For example, if SSP field = 37, the tested ITS service is the DEN basic service, hence the received ITS message has a DENM format. Consequently, step 925 allows the DTS to get the message type or format from the SSP field associated, in the AT 160, with the ITS AID 300 of the received ITS message 150. In some embodiments, the value of tested service permission field 820 may define a format of the test response ITS message 605 between a plurality of message formats available for the tested ITS service.

In other words, during step 925 following step 915 or in the affirmative of test 917, the DTS retrieves an authorized ITS service from the SSP field value associated, in the AT, with an ITS AID field 300 provided in the received ITS message, and the message format is determined based on the retrieved authorized ITS service.

Note that if a single Test Mode AID is used to signal any test response ITS message (including the proprietary test mode response), a void SSP field (or equal to 0 or equal to the Test mode AID value or any other predefined value) may signal the received ITS message is a proprietary test mode response, and not an ITS message generated by an operational ITS service for test purposes.

Once the message type or format is known, the DTS decodes the received ITS message at step 930.

Of course, if a wrong ITS service is signaled in the SSP field, the message type/format determined at step 925 is incorrect, hence the decoding 930 fails, implicitly rejecting the received ITS message.

In these embodiments of Figures 8 and 9, the AT 160 for test purposes can signal only one tested ITS service per Test ITS AID, because each AID must be unique in the list 320. For a group of ITS services associated with the same Test ITS AID, the SUT needs to obtain a corresponding plurality of ATs 160 from the Test AA, each AT having a permission 321/322 associating the Test ITS AID with a different one of the ITS service identifiers in the SSP field. For example, a first AT authorizes a test for CAMs by signaling the pair {Test AID; 36} while a second AT authorizes a test for DENMs by signaling the pair {Test AID: 37}, and so on.

In this respect, the SUT is configured to select the appropriate AT corresponding to the tested ITS service (which is identified by the DTS in its test request 600 for example).

Figures 10 and 11 illustrates alternative embodiments for signalling the tested regular ITS service or services using a SSP field in the AT 160. It is recalled that the SSP field considered is the one associated with the relevant test ITS AID, within the list 320.

The SSP field is made of a plurality of bytes, here 3 bytes. Any number up to 31 bytes may be used. In both Figures, A first part 805 of the SSP field, here the first byte, is used to signal a version number of the SSP field and a length of the SSP field.

A second part of the SSP field, here the remaining bytes, is used to signal a plurality of ITS services that are authorized for test purposes. This configuration therefore authorizes one or more ITS services.

In Figure 10, the SSP subfield 1010 includes a bitmap, each bit of which signals whether a corresponding ITS service is authorized or not. In the example shown, bit 0 of byte 1 is used to signal whether the CA basic service is authorized (bit = 1) or not (bit = 0), while bit 1 of byte 1 is used to signal whether the DEN basic service is authorized (bit = 1) or not (bit = 0), and bit 2 of byte 1 is used to signal whether the CF basic service is authorized (bit = 1) or not (bit = 0), and so on.

The bitmap may occupy the entire subfield 1010 or a part thereof, depending on the number of ITS services that can be signaled through the SSP. They may be the plurality of ITS services composing a group associated with a given Test ITS AID, as mentioned above.

In Figure 11, the SSP subfield 1110 includes a list of one or more identifiers, each identifier identifying one of the authorized ITS services. Hence, a plurality of identifiers can be stored in the SSP subfield 1110 to signal the ITS services that are authorized for test purposes. In the example shown, each byte in the SSP subfield 1110 stores an identifier of an authorized ITS service. For illustrative purposes only, the first byte of SSP subfield 1110 stores the value 36 identifying the operational CA basic service, while the second byte of SSP subfield 1110 stores the value 37 identifying the operational DEN basic service. Of course, more than two bytes can be used to list more than two authorized ITS services.

Figure 12 illustrates, using a flowchart, operations at an ITS station to process an ITS message 150 received from another ITS station, according to embodiments of the invention in relation to the embodiments of Figures 10 and 11. As above, focus is preferably made on the DTS when processing a test response ITS message 605 received from the SUT (i.e. a message for test purposes) in response to a test item request 600. However, the same process applies to any ITS station receiving an ITS message.

As in Figures 7 and 9, a new ITS message is received at step 700 by the network layer. Step 705 consists for the security layer of the DTS to verify the validity of the ITS message based on the accompanying digital signature 170 and on the corresponding AT 160. This step 705 allows the DTS to retrieve the pair {ITS AID, SSP} 321, 322 from the AT 160, corresponding to the ITS AID 300 specified in the received ITS message.

Step 910 is executed by the facility layer only when the verification is positive. It checks whether the ITS AID 300 signals a test mode service Depending on the embodiments above, this may consist in checking whether the ITS AID 300 equals the Test Mode AID or a predefined Test ITS AID associated with one of the groups of ITS services for test purposes.

In the negative meaning a regular ITS AID is used, the TMS activates the corresponding operational ITS service. The activated ITS service then processes the received ITS message in a conventional way. This is step 720.

In the affirmative of test 910, a message type is determined at step 1215 for the received ITS message.

Various options are available.

In embodiments, the message type is known by the DTS because it reflects the test request 600 previously sent (the received test response ITS message is responsive to such request).

In other embodiments, the SUT may send a separate message (e.g. proprietary test mode message) indicating the message type (e.g. CAM, DENM, etc.) of the test response ITS message that follows. It is for instance recall that TR 103 573 allows two such messages 605 to be sent in response to the test request 600 (see above Figure 6). The DTS thus retrieves the message type from the separate message.

In yet other embodiments, a message type may be included in the header 151 of the test response ITS message 605, for example in the messagelD field defined in the ItsPduHeader described in TS 102 894-2, Annex B. The DTS thus retrieves the message type from the header of the received message.

In yet other embodiments, a message type may be included in a header of a mobile communication protocol, e.g. in a 5G or LTE header encapsulating the test response ITS message. The DTS thus retrieves the message type from the 5G or LTE header.

In yet other embodiments, the DTS may test a plurality of possible message formats (size and organization of fields) to validate the one or ones that are suitable. All the possible message formats the DTS knows can be checked against the received ITS message. However, in a preferred embodiment, the DTS retrieves the SSP 1000 or 1100 corresponding to ITS AID 300 in the AT 160, obtains the ITS services that are authorized for test purposes (those ITS services with an enabled bit in SSP subfield 1010 or explicitly identified in SSP subfield 1110), and only checks those ITS services against the received ITS message to determine the correct message format (hence message type).

Next, step 1225 is executed for all the above embodiments, optionally except the last ones based on the SSP subfield. At step 1225, the DTS checks whether the obtained message type corresponds to an ITS service that is authorized for test purposes, i.e. the corresponding bit in bitmap 1010 is enabled or the corresponding ITS service identifier is listed in SSP subfield 1110. To that end, the DTS determines an ITS service corresponding to the determined message format, and then verifies that the determined ITS service is authorized by

the SSP field.

In the negative, the received ITS message is rejected at step 1135.

Otherwise, the DTS decodes the received ITS message at step 930 based on the message type (hence message format) obtained at step 1215.

The above description shows the various roles played respectively by the Test AA 205 (there may be several of them), the SUT 120 and the DTS 190, with various options depending on the embodiments.

The Test AA is configured to provide, to a requesting SUT, one or more Test ATs, wherein each Test AT includes: an ITS-application identifier, AID, field set to a value signaling a test mode service, and an associated Service Specific Permissions, SSP, field set to a value authorizing the tested ITS service.

The request from the SUT may specify that the requested ATs are for test purposes. This indication triggers, at the Test AA, the generation of ATs having the above limitation of the present invention, and furthermore having usually restricted validity period 305 and region 310.

The SUT is configured to react to test requests 600 from the DTS to activate the appropriate tested ITS service in order to generate a corresponding test response ITS message, and to select the appropriate Test AT (from the Test ATs provided by the Test AA) corresponding to the tested ITS service. In other words, the Test AT having a permission made of an ITS-AID set to Test ITS AID and of a SSP authorizing the tested ITS service is selected. The test response ITS message is then signed with the selected Test AT before being emitted.

The DTS checks the received test response ITS message and decodes it using the process of Figure 9 or 12.

Figure 13 schematically illustrates a communication device 1300, typically any of the ITS stations of Figure 1, of an ITS, configured to implement at least one embodiment of the present invention. The communication device 1300 may preferably be a device such as a microcomputer, a workstation or a light portable device. The communication device 1300 may comprise a communication bus 1305 to which may be connected: -a central processing unit 1301, such as a processor, denoted CPU; -a memory 1303, denoted MEM, for storing an executable code of methods or steps of the methods according to embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing the methods; and -at least two communication interfaces 1302 and 1302' connected to the V2X network, for example a communication network according to 3GPP LTE-Advanced Pro, 3GPP 5G or IEEE 802.11p technology, via transmitting and receiving antennas 1304 and 1304', respectively.

Preferably the communication bus 1305 may provide communication and interoperability between the various elements included in the communication device 1300 or connected to it. The representation of the bus is not limiting and in particular the central processing unit is operable to communicate instructions to any element of the communication device 1300 directly or by means of another element of the communication device 1300.

The executable code may be stored in a memory that may either be read only, a hard disk or on a removable digital medium such as for example a disk. According to an optional variant, the executable code of the programs can be received by means of the communication network, via the interface 1302 or 1302', in order to be stored in the memory 1303 of the communication device 1300 before being executed.

In an embodiment, the device 1300 may be a programmable apparatus which uses software to implement embodiments of the invention. However, alternatively, embodiments of the present invention may be implemented, totally or in partially, in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC).

Although the present invention has been described herein above with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modifications will be apparent to a skilled person in the art which lie within the scope of the present invention.

Many further modifications and variations will suggest themselves to those versed in the art upon referring to the foregoing illustrative embodiments, which are given by way of example only and which are not intended to limit the scope of the invention, that being determined solely by the appended claims. In particular, the different features from different embodiments may be interchanged, where appropriate.

In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

Claims (23)

1. CLAIMS1. A method of communication in an Intelligent Transport System, ITS, providing ITS services, comprising at an ITS station, ITS-S, under test, SUT: broadcasting an ITS message generated by a tested ITS service, which ITS message is signed with an authorization ticket, AT, granted to the SUT, wherein the AT includes: an ITS-application identifier, AID, field set to a value signaling a test mode service, and an associated Service Specific Permissions, SSP, field set to a value authorizing the tested ITS service.
2. 2. The method of Claim 1, wherein the SUT broadcasts a second ITS message generated by a second tested ITS service, which ITS message is signed with a second authorization ticket, AT, granted to the SUT, wherein the second AT includes: an ITS-application identifier, AID, field set to the value signaling the test mode service, and an associated SSP field set to a value authorizing the second tested ITS service.
3. 3. The method of Claim 1, wherein the SUT is configured, when not being under test, to broadcast an operational ITS message generated by the tested ITS service, which ITS message is signed with an operational authorization ticket, AT, granted to the SUT, wherein the operational AT includes an ITS-application identifier, AID, field set to a value authorizing the tested ITS service.
4. 4. A method of communication in an Intelligent Transport System, ITS, providing ITS services, comprising at a dedicated test system, DTS: receiving, from an ITS station, ITS-S, under test, SUT, a broadcast ITS message generated by a tested ITS service, which ITS message is signed with an authorization ticket, AT, granted to the SUT, wherein the AT includes: an ITS-application identifier, AID, field set to a value signaling a test mode service, and an associated Service Specific Permissions, SSP, field set to a value authorizing the tested ITS service.
5. 5. The method of Claim 4, further comprising at the DTS: determining a message format for the received broadcast ITS message, and decoding the broadcast ITS message using the determined message format.
6. 6. The method of Claim 5, wherein the message format is determined from the broadcast ITS message itself.
7. 7. The method of Claim 5, further comprising, at the DTS, retrieving an authorized ITS service from the SSP field value associated, in the AT, with an ITS AID field provided in the received broadcast ITS message, wherein determining the message format is based on the retrieved authorized ITS service.
8. 8. The method of Claim 5, further comprising, at the DTS,: determining an ITS service corresponding to the determined message format, and verifying that the determined ITS service is authorized by the SSP field.
9. 9. The method of Claim 4, wherein the DTS receives, from the SUT, a second broadcast ITS message generated by a second tested ITS service, which ITS message is signed with a second authorization ticket, AT, granted to the SUT, wherein the second AT includes: an ITS-application identifier, AID, field set to the value signaling the test mode service, and an associated SSP field set to a value authorizing the second tested ITS service.
10. 10. The method of Claim 2 or 9, wherein the SSP field value in the second AT is different from the SSP field value in the AT.
11. 11. The method of Claim 1 or 4, wherein the broadcast ITS message includes an ITS AID set to the value signalling the test mode service.
12. 12. The method of Claim 1 or 4, wherein the ITS message is broadcast responsive to a test request having an ITS AID field set to a Test Mode ITS AID, and the value signaling a test mode service is set to the Test Mode ITS AID.
13. 13. A method of communication in an Intelligent Transport System, ITS, providing ITS services, comprising at an authorization authority: providing, to an ITS station, ITS-S, under test, SUT, one or more Test authorization tickets, ATs, wherein each Test AT includes: an ITS-application identifier, AID, field set to a value signaling a test mode service, and an associated Service Specific Permissions, SSP, field set to a value authorizing a tested ITS service.
14. 14. The method of Claim 1 or 4 or 13, wherein the SSP field is configured to authorize at the most one ITS service.
15. 15. The method of Claim 1 or 4 or 13, wherein the SSP field is configured to authorize a plurality of ITS services.
16. 16. The method of Claim 15, wherein the SSP field includes a bitmap, each bit of which signals whether a corresponding ITS service is authorized or not.
17. 17. The method of Claim 15, wherein the SSP field includes a list of one or more identifiers, each identifier identifying one of the authorized ITS services.
18. 18. The method of Claim 1 or 4 or 13, wherein the SSP field includes a first subfield identifying the tested ITS service and a second subfield defining service specific permissions for the tested ITS service.
19. 19. The method of Claim 18 when depending on Claim 1 or 4, wherein the second subfield defines a format of the broadcast ITS message between a plurality of message formats available for the tested ITS service.
20. 20. The method of Claim 1 or 4 or 13, wherein the AT includes a single pair of ITS AID field and SSP field.
21. 21. An Intelligent Transport System, ITS, station, in an ITS comprising at least one microprocessor configured for carrying out the steps of the method of Claim 1 or 4.
22. 22. An authorization authority in an Intelligent Transport System, ITS, providing ITS services, configured to provide, to an ITS station, ITS-S, under test, SUT, one or more Test authorization tickets, ATs, wherein each Test AT includes: an ITS-application identifier, AID, field set to a value signaling a test mode service, and an associated Service Specific Permissions, SSP, field set to a value authorizing a tested ITS service.
23. 23. A non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in an Intelligent Transport System, ITS, station of an ITS, causes the ITS station to perform the method of Claim 1 or 4.