Specifications for the enhancement to existing LDM and cooperative communication protocol standards

Transcription

1 7 th Framework Programme Project number Specifications for the enhancement to existing LDM and cooperative communication protocol standards Work package Editor(s) WP3 Laurens Hobert (HIT) System Design Status Distribution Draft - not yet approved by the EC Public (PU) Issue date Project co-funded by the European Commission DG-Information Society and Media in the 7th Framework Programme

2 Document information Authors Ali Marjovi EPFL Andras Kovacs BB Ignacio Llatser TUD Lan Lin - HIT Laurens Hobert HIT Luciano Altomare CRF Panagiotis Lytrivis ICCS Xiangjun Qian ARM Document editor Laurens Hobert HIT [email protected] Project funding 7 th Framework Programme FP7-ICT Collaborative Project Grant Agreement No

3 Revision and history chart Version Date Comment Initial document outline (HIT) Feedback on outline (BB) Contribution Andras (BB) on GCA, MNMS and CEMS Contribution Laurens (HIT) on CSBS First draft of EGN (TUD) Updated EGN (TUD) and GCS/MNMS/CEMS (BB) Contribution of Ali (EPFL) on Manoeuvre Negotiation Message Service (4.3). Also made some minor comments on Detailed forwarding algorithms of EGN (TUD) Contribution to CABS extensions (CRF) First draft Reliable Basic Transport Protocol (HIT) Updated convoy procedure in MNMS and Cooperative speed advising service (BB) Updated EGN section (TUD) Contribution to CICS (HIT), updated communication architecture diagram (HIT), updated acronyms (HIT), updated EGN section (TUD) Updated EGN section (TUD), comments TUD on CICS and RBTP sections. Incorporated comments of ARMINES in CICS section Contribution to Cooperative Lane Chang Service (HIT), Changed CAM structure (CRF), added reference to NTRIP (BB) Contribution to AutoNet2030 Communication Functions (TUD), update GCA Information Sharing section (BB), Moved all ASN.1 to Appendix (HIT), Protocol operations CSS (HIT) Final version before review 1.0.Final Final version after review III

4 Table of contents Executive Summary 1 Acronyms, abbreviations and definitions 2 Acronyms and abbreviations 2 Definitions 3 1 Introduction Purpose of this Document Context Cooperative Automated/Manually Driving Use-Cases 5 2 AutoNet2030 Communication Functions Cooperative Lane Change Service Service Introduction Functional Interface Specification Protocol Operations Message Format Specification Convoy Control Communication Service Service Introduction Functional Interface Specification Message Format Specification Cooperative Intersection Control Service Service Introduction Functional Interface Specification Protocol Operations Message Format Specification Extended Cooperative Awareness Basic Service Service Introduction Functional Interface Specification Protocol Operations Message Format Specification Cooperative EGNSS Message Service Service Introduction Functional Interface Specification Protocol Operations Message Format Specification 43

5 2.6 Cooperative Sensing Service Service Introduction Functional Interface Specification Protocol Operations Message Format Specification GCA Information Sharing Service Introduction Functional Interface Specification Protocol Operations Message Format Specification Cooperative Speed Advising Service Service Introduction Functional Interface Specification Protocol Operations Message Format Specification Local Dynamic Map Reliable Basic Transport Protocol Service Introduction Functional Interface Specification Protocol Operations Packet Format Specification Extended GeoNetworking Service Introduction Functional Interface Specification Protocol Operations Packet Format Specification 69 3 Conclusion 70 4 References 71 5 Appendix A: ASN.1 Specification ASN.1 Specification of a CLCM ASN.1 Specification of a CMM ASN.1 Specification of an IEM ASN.1 Specification of a CAM ASN.1 Specification of a CSM 83 V

6 5.6 ASN.1 Specification of a CSAM ASN.1 Specification of a Common Data Dictionary 85 6 Appendix B: SAP Specification SAP Specification of interface CLCS.CONTROL SAP Specification of interface CICS.IE SAP Specification of interface RBTP.DATA 96 7 Appendix C: of Data Elements and Data Frames Hiba! A könyvjelző nem létezik. 7.1 of Data Elements and Data Frames of a CLCM Hiba! A könyvjelző nem létezik. 7.2 of Data Elements and Data Frames of a CMM of Data Elements and Data Frames of a IEM of Data Elements and Data Frames of CAM of Data Elements and Data Frames of a CSM of Data Elements and Data Frames of a CSAM of Data Elements and Data Frames of the Common Data Dictionary Appendix D: Duplicate Packet Detection for the Reliable Basic Transport Protocol Appendix E: Traffic Classes for ITS-G5D 128

7

8 Tables of figures Figure 1 AutoNet2030 Communication Architecture... 9 Figure 2 Lane Change of Subject Vehicle in Target Area Figure 3 UML Component Diagram of the Cooperative Lane Change Service (CLCS) Figure 4 Sequence Diagram Convoy Negotiation Procedure Figure 5 UML Component Diagram of the Cooperative Intersection Control Service for a Road-Side ITS-S Figure 6 UML Component Diagram of the Cooperative Intersection Control Service for a Vehicle ITS-S Figure 7: UML Component Diagram of the Extended Cooperative Awareness Basic Service Figure 8: Structure of the Cooperative Awareness Message Figure 9 RTK - GeoNet broadcaster architecture Figure 10 UML Component Diagram of the Cooperative Sensing Service (CSS) Figure 11 Decentralized (v)rsu notification procedure Figure 12 UML Component Diagram of the Reliable Basic Transport Protocol Figure 13 Reliable Basic Transport Protocol Header Figure 14 Reliable Basic Transport Protocol Request Header Figure 15 RBTP Acknowledgement Header Figure 16 UML Component diagram of Extended GeoNetworking Figure 17 Message dissemination in a group composed of 7 white vehicles using Greedy Broadcast Forwarding. The red solid lines represent the greedy forwarding transmissions, whereas the red dashed lines show the overhead transmissions. The dashed black lines represent the communication range of the transmitting vehicle. The black vehicle is a non-cooperative vehicle

9 Executive Summary The aim of the European Union s co funded AutoNet2030 research project is to develop and test cooperative automated driving technology, based on a decentralized decision-making strategy which is enabled by mutual information sharing among nearby vehicles. The project is aiming for a deployment time horizon, taking into account the expected preceding introduction of cooperative communication systems and sensor based lane-keeping /cruise-control technologies. The AutoNet2030 project team is a consortium of nine research organizations, including ARMINES (France), BASELABS (Germany), BroadBit (Slovakia), Fiat Research Center (Italy), EPFL (Switzerland), Hitachi Europe (UK), ICCS (Greece), Technical University of Dresden (Germany) and Volvo Technology AB (Sweden). AutoNet2030 intends to demonstrate how the combination of cooperative wireless communications and onboard sensors will make cooperative automated driving and interaction between automated and manually driven vehicles more efficient and reliable. The prototyped cooperative automated driving system will be fully integrated into test vehicles and demonstrated on a test track. Using results from drive-testing measurements, the effect of scaling-up to dense traffic scenarios will be investigated through computer simulations. The project aims at actively contributing to the ongoing standardization of cooperative vehicular communications at the Technical Committee on Intelligent Transportation Systems (TC ITS)of the European Telecommunications Standards Institute s (ETSI). This public deliverable D3.2 Specifications for the enhancement to existing LDM and cooperative communication protocol standards is the final output of Work Package 3 System design. This deliverable specifies the enhancements of European C-ITS standards and specifies new protocols and technical features to support the advanced automated driving use-cases as defined in Deliverable 2.1 during an earlier phase of the project, such as cooperative lane change, cooperative sensing, driving in a convoy and coordinated intersection control. In the first chapter, a brief introduction is presented on the targeted cooperative automated/manually driving use-cases. Chapter 2continues with an overview of the communication architecture which is adopted by AutoNet2030 and further provides the detailed specifications for all components highlighted in the architecture. Thesedetailed specificationsinclude a functional description, interface specification, protocol operations and message format specification. The deliverable is finally concluded in Chapter 3. In the appendixes, additional peripheral information is presented for completeness. The ASN.1 of several messages is given and their data elements are described. Major interfaces are specified,an algorithm is described for detecting duplicate packets and new traffic classes are introduced for ITS-G5D. 1

10 Acronyms, abbreviations and definitions This section contains a list of used acronyms, abbreviations and definitions used in this deliverable. Acronyms and abbreviations ASN.1 BSA BTP C2I C2X C-ACC C-ITS CABS CAM CCH CICM CICS CLCM CLCS CSAM CSAS CSM CSS DCC DE DF DENM DENBS DNS edns EN EGN ETSI GCA GN GNSS GPS I2C IEC IEM IETF IP Abstract Syntax Notation One Basic Set of Applications Basic Transport Protocol Car-to-Infrastructure Car-to-Car or Car-to-Infrastructure Cooperative Adaptive Cruise Control Cooperative ITS Cooperative Awareness Basic Service Cooperative Awareness Message Control Channel Cooperative Intersection Control Message Cooperative Intersection Control Service Cooperative Lane Change Message Cooperative Lane Change Service Cooperative Speed Advising Message Cooperative Speed Advising Service Cooperative Sensing Message Cooperative Sensing Service Decentralized Congestion Control Data Element Data Frame Decentralized Environmental Notification Message Decentralized Environmental Notification Basic Service Domain Name System Extended-DNS European Norm Extended GeoNetworking European Telecommunications Standards Institute Global Cooperative Area GeoNetworking Global Navigation Satellite System Global Positioning System Infrastructure-to-Car International Electrotechnical Commission Intersection Entry Message Internet Engineering Task Force Internet Protocol

11 IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 ISO International Organization for Standardization ITS Intelligent Transport System ITS-S ITS Station LDM Local Dynamic Map LTE Long Term Evolution NTRIP Networked Transport of RTCM via Internet Protocol OSI Open System Interconnection PCI Protocol Control Information PDU Protocol Data Unit PER Packed Encoding Rules POTI Position and Time RBTP Reliable Basic Transport Protocol RFC Request for Comments RSU Road-side Unit RTCM Radio Technical Commission for Maritime Services RTK Real Time Kinematic SAP Service Access Point SCH Service Channel SDU Service Data Unit SSP Service Specific Permissions TC ID Traffic Class Identifier TCP Transmission Control Protocol TS Technical Specification UML Unified Modeling Language UMTS Universal Mobile Telecommunications System UPER Unaligned PER VDP Vehicle Data Provider Definitions AutoNet CSS CSM Cooperative Automated Mode The AutoNet is an advanced vehicular ad hoc network (VANET) utilizing wireless communication to facilitate cooperation between cooperative automated vehicles. The AutoNet is used to inform about legacy vehicles, perform incident detection, advice on appropriate speed to achieve a better road traffic flow, share manoeuvring information, support lane changes and platoon/convoy merging. Facility at the ITS facilities layer supporting the CSS protocol and functionalities ITS facilities layer PDU providing ITS-S detected external objects and attributes The cooperative automated mode extends the cooperative mode by adding automated control of the vehicle, i.e., the vehicle controls lateral and longitudinal movements automatically based on in-vehicle sensors and received information from other cooperative vehicles. 3

12 Cooperative Automated Vehicle Cooperative Manually- Driven Vehicle Cooperative Mode Cooperative Vehicle Convoy GCA Legacy Vehicle ITS-G5 PCI PDU Platoon SDU A cooperative vehicle in cooperative automated mode.a cooperative automated vehicle can become a cooperative manually-driven vehicle when the driver turns off the cooperative automated mode. A manually driven vehicle equipped with a cooperative device. A cooperative manually-driven vehicle can become a cooperative automated vehicle when the driver turns on the cooperative automated mode. An mode of an ITS Station in which it can communicate with other ITS Stations using ITS-G5 and its associated European ITS protocols such as GeoNetworking, CAM and DENM. An ITS Station with Cooperative Mode may support LTE. Moreover, it is able to sense its surroundings and share its perception with other ITS Stations with cooperative mode. A vehicle with cooperative mode. A group of three or more cooperative vehicles maintaining a formation, typically their distance and speed using cooperative adaptive cruise control (C- ACC), with a distance greater than 0.5 s A set of area in which information is shared on a wider range e.g., a 20 km stretch of highway. A vehicle with no cooperative mode. and it is not able to participate in the AutoNet. Access technology to be used in the 5GHz frequency bands dedicated for European intelligent transport systems (ITS)[1]. OSI term for information exchanged between entities of a particular layer OSI term for a unit of data that consists of the SDU and PCI of a particular OSI layer A group of two or more automated cooperative vehicles in line, maintaining a close distance, typically such a distance to reduce fuel consumption by air drag. A platoon has a platoon leader that ensures coordination within the platoon. OSI term for a unit of data that is passed from one OSI layer to a lower layer and has not yet been encapsulated in a PDU

13 1 Introduction 1.1 Purpose of this Document This document specifiesnew and enhanced cooperative ITS communication protocols which can support automated driving based on a decentralized decision making strategy. These specifications are used on the one hand for the implementation of a cooperative automated vehicle prototype in the AutoNet2030 project which will be fully integrated in test vehicles and will be demonstrated and validated on a test track. On the other hand, this document may serve as input to ongoing standardization activities of C-ITS communication protocols at the European Telecommunications Standards Institute (ETSI) or any other relevant standardization organization. 1.2 Context The focus of the AutoNet2030 is on cooperative automated/manually driven vehicle technology in combination with onboard sensors technologies, in order to allow vehicles to perform manoeuvring negotiations and interactions under urban or highway driving conditions. In the first phase of the project, a list of automated driving control use cases and the related requirements were listed. Based on these use-case and requirements, the AutoNet2030 functional architecture was developed which is decomposing the complex on-board unit of a cooperative (automated) vehicle, road-side unit and a central unit in well-defined building blocks and interfaces. The four main building blocks of a cooperative (automated) vehicle in the AutoNet2030 architecture are identified as Manoeuvring& Control, Human Machine Interface, Perception and Communication[2]. The focus of this document is on the detailed protocol specification of the components inside the communication building block. 1.3 Cooperative Automated/Manually Driving Use-Cases The AutoNet2030 project is targeting the following high-level Cooperative Automated and Manually Driving Use-Cases: Convoy Driving: a group of three or more highly automated vehicles (with automated lateral and longitudinal control) or vehicles with at least Cooperative-ACC functionality maintaining a multi-lane formation in a decentralized manner. Unlike the well-known platooning concept, a convoy has no leader. The details of one possible approach for Convoy driving are presented in Marjovi et al. [3] Cooperative Lane Change: a lane change in which 2 or more cooperative automated and manually driven vehicles are negotiating, agreeing, preparing and executing a lane change in order to improve traffic flow of cooperative vehicles during lane-change and merging situations. Priority based Intersection Management: cooperative automated and manually driven vehicles are requesting explicit permission to cross an intersection. An intersection controller is assigning priorities to cooperative vehicles and informing them accordingly. The details of one approach for Priority based Intersection Management which is used in AutoNet2030 are presented in Qian et al. [4]. 5

14 The protocols specified in this document are supporting directly or indirectly the above mentioned use-cases. The Cooperative Lane Change Service of Section 2.1is directly supporting the Cooperative Lane Change whereas the Cooperative Sensing Service in Section 2.6and Extended GeoNetworking of Section 2.11are enabling technologies for convoy driving and Priority based Autonomous Intersection Management. In the next chapter, the AutoNet2030 communication architecture is presented and the detailed protocol specifications of several components of this architecture are described.

15 2 AutoNet2030 Communication Functions The communication architecture considered for the AutoNet2030 project is based on the C-ITS communication architecture, as defined by ETSI in the European Standard ETSI EN [5]. Consistentl with the C-ITS communication architecture, the AutoNet2030 communication architecture is divided in four horizontal and 2 vertical layers: ITS Application layer: this layer contains the cooperative autonomous driving applications including the manoeuvre controller. The manoeuvre controller calculates a feasible trajectory, generates manoeuvre commands (for automated vehicles) or advices to the driver (for manually driven vehicles) according to the information provided by the communication and sensor components. The functionality of this layer is out of scope of the current document. Facilities layer: the facilities layer provides support to satisfythe applications needs. The facilities layer components allow applications to communicate and exchange information with other cooperative entities, such as vehicles and roadside units. The communication components belonging to the facilities layer in AutoNet2030 architecture are the following: GCA Information Sharing:a component providing a service to distribute information (e.g. traffic status) within a wide geographical area known as Global Cooperation Area (GCA), supervised by a dedicated application server. Cooperative Speed Advising Service: a component enabling a traffic server to advise an appropriate driving speed to all vehicles within a given road segment. Cooperative EGNSS Message Service: a component which manages the transmission and reception of real-time kinematic corrections to data for enhanced geo-positioning, through a scalable broadcast-based approach. Cooperative Sensing Service:component to disseminate and receive information about perceived external dynamic objects (e.g. other vehicles, pedestrians, motorcyclists, etc.) Cooperative Lane Change Service: a component that supports the planning and execution of a lane change in collaboration with surrounding cooperative vehicles. Platoon Control Communication Service: a component that enables the communication between platoon leader and platoon members for the management and information sharing in platoons. Convoy Control Communication Service: a component providing an advanced communication mechanism which enhances the functionality of cooperative automated cruise control (C-ACC), allowing the control and maintenance of multi-lane vehicle formations. Cooperative Intersection Control Service: acomponent that manages the information exchange between vehicle and intersection controller for priority-based coordination of autonomous and manually driven vehicles at intersections. Extended CABasic Service: extension of thestandard component CABS as standardized in ETSI EN [6], in order to support the automated driving use-cases in AutoNet2030. Decentralized Environmental Notification Basic Service: standard componentas standardized in ETSI EN [7]which enables ITS applications to disseminate Decentralized 7

16 Environmental Notification Messages (DENM) to other ITS stations and to receive DENMs from other ITS stations. SPAT/MAP:component managing the exchange of intersection topology information and traffic light signal phase and timing information. Local Dynamic Map: a database which combines lane-level map information with sensed objects using local sensors and communication. The Local Dynamic Map (LDM) is considered as a key component in the AutoNet2030 architecture. However, no additional needs for standardization of the LDM were identified and for that reason no interoperability requirements for the Local Dynamic Map are specified in the current document. Networking &Transport layer: the network & transport layer are responsible for end-to-end connectivity and packet forwarding from the source to the destination (or destinations in the case of broadcast communications). The communication components belonging to the networking & transport layer in AutoNet2030 architecture are the following: Basic Transport Protocol: standard component which provides an end-to-end, connection-less communication service for the exchange of datagrams in an ITS ad-hoc network. The BTP has been specified in ETSI EN [8] Reliable Basic Transport Protocol:a component which provides a reliable end-to-end communication service based on acknowledgements and retransmissions for unicast connections. It extends the Basic Transport Protocol as specified in ETSI EN [8]. Extended GeoNetworking:component which provides the functionality to route packets among the cooperative entities of the AutoNet. The standard GeoNetworking protocol is extended with the design of a new forwarding protocol optimized for the requirements of cooperative autonomous driving. TCP/UDP: standard components of the TCP/IP protocol stack which provides end-to-end or host-to-host communication services for applications. IP: standard component of the TCP/IP protocol stack which has the task of delivering packets from the source to the destination. Access layer: the access layer provides physical access to the communication medium and the ability to transfer data between adjacent network nodes. The communication components belonging to the access layer in AutoNet2030 architecture are the following: ITS-G5: standard component which provides the functionality to transmit and receive frames according to the p MAC-sub layer formats. UMTS/LTE: standard component which provides the functionality to transmit and receive frames over the cellular communication network. Cross- of the C-ITS communication architecture cannot be classified into a single layer, but they are multilayers components: finally, some components -layer components: Management: component responsible of cross-interface management and inter-unit management communications. Security: component which enables the secure transmission and reception of messages by means of authentication, cryptographic keys and certificate management.

17 Figure 1 provides a graphical representation of the communication components in the AutoNet2030 architecture and their distribution into layers. A colour coding has been used to differentiate between new and updated communication components within the scope of AutoNet2030 (red) and existing components in the C- ITS communication architecture which will be reused without substantial modifications (blue). In the next chapter, the new and updated communication components are described in detail and specified. Facilities Layer Management Network & Transport Layer ITS Applications Layer Local Dynamic Map MIB Cooperative Speed Advising Service Extended Cooperative Awareness Basic Service Decentralized Environmental Notification Basic Service Cooperative Sensing Service SPAT/MAP Convoy Control Communication Service GCA Information Sharing Cooperative Lane Change Service Cooperative Intersection Control Service Cooperative EGNSS Message Service Security TCP/UDP IP RBTP Extended GeoNetworking BTP Access Layer UMTS/LTE ITS-G5 In scope of current document Out of scope of current document Figure 1AutoNet2030 Communication Architecture 9

18 2.1 Cooperative Lane Change Service Service Introduction The Cooperative Lane Change Service (CLCS) handles the interactions between ITS stations in order to plan, prepare and execute a cooperativee lane change. The CLCS component supports the lane change of a single vehicle as well as a group of vehicle (i.e. a platoon or convoy). Vehicles with the intention to perform a cooperative lane change are called Subject Vehicles in the context of this service. Figure 2 illustrates a situation in which two subject vehicles have the intention to make a lane change. The interactions between ITS stations for a particular lane change are initiated and coordinated by one ITS station called the originating station. This station can either be a road-side unit in which infrastructure supports the interactions or a subject vehiclee as illustrated in Figure 2. The interactions between Originating Station and subject vehicles are out-of-scope of the CLCS. Nevertheless, the originating station should have means to inform group members who have been selected as subject vehiclefor a specific dialogue. Subject vehicles plan in advance a lane change by selecting a geographical area to which they intend to change to. Thisarea is called thetargetareaand may have been selected based onfor example the road topology (e.g. the merging area of an on-ramp) ora road works (e.g. a closed lane or a roadwork).figure 2illustrates the targetarea of twosubject vehicle entering the highway. The CLCS component does not aim to reserve a fixedtargetareaexclusively for certain subject vehicle(s). This approach might rule out other subject vehicles to perform a similar lane change during the reserved period. Instead, the CLCS component negotiates the relative area in front of another vehiclee which will be driving in the target area during the lane change. This vehicle is called a Target Vehicle. Figure 2 illustrates the targetvehicle for the illustrated subject vehicles. Figure 2 Lane Change of Subject Vehicle in Target Area The CLCS component splits a cooperative lane change in three phases: a search phase, a preparation phase and an execution phase. The communication during these phases for a particular cooperative lane change is called a dialogue. Search Phase:during the search phase, the CLCS component of the originating station tries to find potential target vehicles during the search phase. A target vehicle is a vehicle in the Target Area during the Target Lane Change Time and is capable to open the required distance for the subject vehicle(s) to

19 perform the lane change in front of the target vehicle. This phase is optional and only executed when the originating station cannot select a target vehicle. During the search phase, zero, one or multiple potential target vehicles may be found and the originating station should select one to start the preparation phase. Preparation Phase During the preparation phase, the CLCS component of the originating station requests a target vehicle to open the required spaceto facilitate the lane change. This phase ends when the target vehicle has confirmed the opened space or the preparation has been aborted by either the target or subject vehicle(s). During the preparation phase, the subject vehicles will physically align to the space opened by the target vehicle in order to execute lane change. Execution Phase The lane change is executing during thisphase. Subject vehicle(s) and target vehicle should use perception sensors and C2X communication toensure a safe execution. When safety cannot be guaranteed, both subject and target vehicles can abort the cooperative lane change. Methods to ensure safety and detect unsafe situations (e.g. another vehicle taking the freed space) are out of scope of this specification and are left to the implementation of the vehicle control algorithm Functional The CLCS component handles the message exchange between ITS stations in order to support the cooperative lane change. The UML Component Diagram of the CLCS component is illustrated in Figure 3. The functionality of the CLCS-component can be sub-divided in four sub-components: Protocol Operations: this sub-component implements the protocol operations upon the transmission and reception of Cooperative Lane Change Messages (CLCM) and is specified in Section Encoding: this sub-component encodes CLCMs according to the specifications in Section Decoding: this sub-component decodes CLCMs according to the specifications in Section Dialogue Table: this sub-component stores dialogue entries for each dialogue the ego-station is involved in. A dialogue entryfor which the ego-station is acting as an originating station are stored in the Originating Dialogue Table and each entry contains at least the data as listed in Table 1. Table 1Originating Dialogue Table Fields Field Dialogue Identifier Originating Station Identifier Sequence Number Request Identifier Dialogue Phase Target Vehicle Identifier Identifier of the dialogue local to an ITS-S Facilities-layer identifier of the originating station identifier Sequence number identifying a dialogue in combination with the originating station identifier Last used request identifier of the dialogue corresponding to the entry The dialogue phase i.e. Search Phase, Preparation Phase or Execution Phase Facilities-layer identifier of the target vehicle 11

20 Cooperative Lane Change Message Encoded CLCM used for retransmissionss Dialogue entriesfor which the ego-vehicle is acting as a target vehicle are stored in the Target Dialogue Table and each entry contain at least the data as listed in Table 2. Table 2 Target Dialogue Table Fields Field Dialogue Identifier Originating Station Identifier Sequence Number GeoNetworking Address Identifier of the dialogue local to an ITS-SS Facilities-layer identifier of the originating station identifier Sequence number identifying a dialogue in combination with the originating station identifier GeoNetworking Address of the originating station Figure 3UML Component Diagram of the Cooperative Lane ChangeServicee (CLCS) The interfaces of the CLCS component are described in Section Interface Specification Interface with ITS Applications The CLCS component interacts with ITS Applications through interface CLCS.CONTROL. This interface is described as a Service Access Point (SAP)with corresponding primitives in Appendix Interface with the Basic Transport Protocol The CLCS component requests the dissemination of CLCMs by the Basic Transport Protocol (BTP)component through interface BTP.DATA. The BTP and its interfacesare specified in ETSI EN [8].

21 Interface with the Reliable Basic Transport Protocol The CLCS component requests the reliable transmission of CLCMs by the Reliable Basic Transport Protocol (RBTP) component through interface RBTP.DATA. The RBTP is specified in Section Interface with Security The CLCS component interacts with the Security component through the interface SEC.PSEUDONYM in order to block pseudonym changes during periods in which the ITS station is involved in a cooperative lane change. The specification of this interface is out-of-scope of the current document Protocol Operations This section specifies the operations of the CLCS component. Most operations are executed upon the reception of primitives of the interfaces specified in the previous section or upon timer timeout. On the reception of primitiveclcs.control.request, the CLCS shall execute the following operations: 1. Check the Dialogue Identifier of the primitiveclcs.control.request. a. If the Dialogue Identifier is set, find theoriginating dialogue entry in the dialogue table with corresponding dialogue identifier. i. If no dialogue entry is found, respond with primitive CLCS.CONTROL.result; set itsresult to Failure and omit the Dialogue Identifier and Request Identifier. Refrain from executing` further steps. b. If the Dialogue Identifier is not set, create a new originating dialogue entry according to Table 3and add it to the originating dialoguetable. Table 3Originating dialogue entry initialization values Parameter Dialogue Identifier Value Any value uniquely identifying a originatingor target dialogue entry in the dialogue table Originating Station Identifier Facilities-layer station identifier of the ego-vehicle, same as used by the CABS and DENBS as specified in as specified in ETSI TS [9] Sequence Number Anyvaluewhich in combination with the Originating Station Identifier is uniquely identifying the originatingdialogue entry in the originatingdialogue table Request Identifier -1 Dialogue Phase Target Vehicle Identifier CLCM Search Phase Undefined Undefined 13

22 2. Check the Originating Dialogue Entry. a. If the Target Vehicle Identifier of primitive CLCS.CONTROL.requestis not set and the Dialogue Phase of the originating dialogue entry equals Preparation Phase, refrain from executing further steps. b. If the Target Vehicle Identifierof primitive CLCS.CONTROL.requestis set, set the Dialogue Phaseand Target VehicleIdentifierof the originating dialogue entry respectively topreparation Phase and the Target Vehicle Identifier of the primitive. 3. Increase the Request Identifier of the originating dialogue entry with Create a Cooperative Lane Change Message (CLCM) as specified in Section Set the fieldsof the CLCM according to Table 4. a. If the CLCM cannot be constructed according to Section (e.g. a certain value is out-ofrange), then respond with primitive CLCS.CONTROL.result. Set the Result of the primitive to Failure and omit the Dialogue Identifierand Request Identifier. Refrain from executing further steps. Table 4 CLCMLane Change Request values Field Value itsheader protocolversion currentversion (1) messageid 129 stationid Originating Station Identifier of theoriginatingdialogue entry messageheader actionid originatingstationid sequencenumber messagebody requestid subjectvehicles lanechangedirection targetarea targetlane Originating Station Identifier of the originatingdialogue entry Sequence Number of the originatingdialogue entry lanechangerequest Request Identifier of the originatingdialogue entry Subject Vehicles of primitive CLCS.CONTROL.request Lane Change Direction of primitive CLCS.CONTROL.request TargetArea of primitive CLCS.CONTROL.request Target Lane of primitive CLCS.CONTROL.request

23 targetlanechangetime targetlanechangespeed minimumlanechangedistance targetvehicleid CLCS.CONTROL.request.Target Lane Change Time CLCS.CONTROL.request.Target Lane Change Speed CLCS.CONTROL.request.Minimum Lane Change Distance CLCS.CONTROL.request.Target Vehicle Identifier 5. If a t_retransmission timer is scheduled for the originating dialogue entry, stop the timer. 6. Store the created CLCM in the originating dialogue entry. 7. Request the BTP/GeoNetworking-stack for GeoBroadcasting the CLCM using primitive BTP- DATA.request and parameters intable 5. Table 5 Minimum set of PCI passed from the CLCS to the BTP/GN-stack on a CLCM transmission request Parameter Data Requirement Optionality BTP Type BTP A Mandatory Source port 3002 Mandatory Destination port 3002 Mandatory GN Packet transport type GN Destination address GN Communication profile GeoBroadcast A geographical area overlapping the target area of the CLCM message. ITS-G5 Mandatory Mandatory Mandatory GN Traffic class TC ID 6 (see Section 9), SCF and channel offload disabled Mandatory ITS-G5 Channel Type G5 SCH6 Mandatory Length The length in bytes of the CLCM Mandatory Data The CLCM message encoded according the ASN.1 UPER encoding rules as specified in ISO/IEC [10]. Mandatory 8. If CLCS.CONTROL.request.Target Vehicle Identifier is set, schedule a timer t_retransmission with a timeout of 500 milliseconds for the Originating Dialogue Entry of step Respond with primitive CLCS.CONTROL.result. Set the Result to Success anddialogue Identifierand Request Identifierto respectively the corresponding values of the Originating Dialogue Entry. On the expiration of timer t_retransmission, the CLCS shall execute the following operations: 1. Lookup the Originating Dialogue Entry in the Originating Dialogue Table corresponding to the expired timer. 15

24 a. If no dialogue entry is found, refrain from executing further steps. 2. Request the BTP/GeoNetworking-stack for the GeoBroadcast transmission of the CLCM in the Originating Dialogue Entry using primitive BTP.DATA.requestaccording to Table Reschedule timer t_retransmissionof the originating dialogue entry with a timeout of 500 milliseconds. On the reception of a CLCS.CONTROL.responseprimitive, the CLCS shall execute the following operations: 1. Lookup the Target Dialogue Entry in the Target Dialogue Table with dialogue identifier equal to CLCS.CONTROL.response.Dialogue Identifier. a. If no dialogue entry is found, refrain from executing further steps. 2. Create a CLCM as specified in Section Set the fields of the CLCM according totable 6. a. If the CLCM cannot be constructed (e.g. a certain value is out-of-range), refrain from executing further steps. Table 6CLCM Lane Change Responsesettings Field Value itsheader protocolversion currentversion (1) messageid 129 stationid Facilities-layer station identifier of the ego-vehicle, same as used by the CABS and DEN BS as specified in as specified in ETSI TS [9] messageheader actionid originatingstationid sequencenumber messagebody requestid responsetype targetvehicle targetvehicleprecedingvehicleid predictedlanechangespeed groupid Originating Station Identifier of the Target Dialogue Entry Sequence Number of the Target Dialogue Entry LaneChangeResponse CLCS.CONTROL.response.Request Identifier CLCS.CONTROL.response.Response Type CLCS.CONTROL.response.Target Vehicle CLCS.CONTROL.response.Target Vehicle Preceding Vehicle Identifier CLCS.CONTROL.response.Predicted Lane Change Speed CLCS.CONTROL.response.Group Identifier

25 3. Request the RBTP/GeoNetworking-stack for GeoBroadcasting the created CLCM using primitive RBTP.DATA.requestand parameters intable 7. Table 7Minimum set of PCI passed from the CLCS to the RBTP/GN-stack on a CLCM transmission Parameter Data Requirement Optionality Source port 3002 Mandatory Destination port 3002 Mandatory Acknowledgement Timeout GN Destination address 500 Mandatory GeoNetworking Address of the Target Dialogue Entry Mandatory GN Communication profile ITS-G5 Mandatory GN Traffic class TC ID 6 (see Section 9), SCF and channel offload disabled Mandatory ITS-G5 Channel Type G5-SCH6 Mandatory Length The length in bytes of the CLCM Mandatory Data The CLCM message encoded according the ASN.1 UPER encoding rules as specified in ISO/IEC [10]. Mandatory On the reception of primitiveclcs.control.prepared, the CLCS shall execute the following operations: 1. Lookup the Target Dialogue Entry in the Target Dialogue Table with dialogue identifier equal to CLCS.CONTROL.prepared.Dialogue Identifier. a. If no target dialogue entry is found, refrain from executing further steps. 2. Create a CLCM as specified in Section Set the fields of the CLCM according totable 8. a. If the CLCM cannot be constructed (e.g. a certain value is out-of-range), refrain from executing further steps. 3. Request the RBTP/GeoNetworking-stack for GeoBroadcasting the CLCM using primitive RBTP.DATA.requestand parameters intable 7. Table 8CLCM Lane Change Prepared settings Field Value itsheader protocolversion currentversion (1) messageid 129 stationid Facilities-layer station identifier of the ego-vehicle, same as used by the CABS and DEN BS as specified in as specified in ETSI TS [9] 17

26 actionid messagebody originatingstationid sequencenumber Originating Station Identifier of the Target Dialogue Entry Sequence Number of the Target Dialogue Entry lanechangeprepared On the reception of a CLCS.CONTROL.abortprimitive, the CLCS shall execute the following operations: 1. Lookup the OriginatingDialogue Entry in the dialogue table with dialogue identifier equal to CLCS.CONTROL.abort.Dialogue Identifier. a. If a OriginatingDialogue Entry is found, continue with step Lookup the Target Dialogue Entry in the dialogue table with dialogue identifier equal to CLCS.CONTROL.abort.Dialogue Identifier. a. If a Target Dialogue Entry is found, continue with step 8. b. If no Target Dialogue Entry is found, refrain from executing further steps. 3. Create a CLCM as specified in Section Set the fields of the CLCM according totable 9. a. If the CLCM cannot be constructed (e.g. a certain value is out-of-range), refrain from executing further steps. 4. Store the created CLCM in the OriginatingDialogue Entry. 5. If a timer t_retransmission is scheduled for the OriginatingDialogue Entry, stop the timer. 6. Request the BTP/GeoNetworking-stack for GeoBroadcasting the using primitive BTP-DATA.requestand parameters intable Schedule a timer t_retransmission with a timeout of 500 milliseconds for the Originating Dialogue Entry of step 1. Refrain from executing further steps. 8. Create a CLCM as specified in Section Set the fields of the CLCM according to Table 9. a. If no CLCM can be constructed according to Section (e.g. a certain value is out-of-range), refrain from executing further steps. 9. Request the RBTP/GeoNetworking-stack for the transmission of the CLCM using primitive RBTP.DATA.request as specified intable 7. Table 9 CLCM Lane Change Abort settings Field Value itsheader protocolversion currentversion (1) messageid 129

27 stationid Facilities-layer station identifier of the ego-vehicle, same as used by the CABS and DEN BS as specified in as specified in ETSI TS [9] actionid messagebody originatingstationid sequencenumber Originating Station Identifier of the Dialogue Entry Sequence Number of the Dialogue Entry lanechangeabort On the reception of a CLCS.CONTROL.finalizeprimitive, the CLCS shall execute the following operations: 1. Lookup the dialogue entry in the dialogue table with dialogue identifier equal to CLCS.CONTROL.abort.Dialogue Identifier. a. If no dialogue entry is found, refrain from executing further steps. 2. Stop timer t_retransmission associated with the removed originating dialogue entry 3. Remove the originating dialogue entry from the originating dialogue table. On the reception of primitive RBTP.DATA.indication, the CLCS shall execute the following operations: 1. Decode the RBTP.DATA.indication.Data according to the specification of Section Lookup the Originating Dialogue Entry in the Originating Dialogue Table with originating station identifier and sequence number equal to respectively CLCM.messageHeader.actionID.originatingStationID and CLCM.messageHeader.actionID.sequenceNumber a. If no dialogue entry is found, refrain from executing any further steps. 3. Check the messagebody of the decoded CLCM. a. If the messagebody is a lanechangeresponse, continue with step 4. b. If the messagebody is a lanechangeabort, continue with step 7. c. If the messagebody is a lanechangeprepared, continue with step 9. d. Else, drop the CLCM and refrain from executing further steps. 4. Check the Dialogue Phase of the OriginatingDialogue Entry a. If the Dialogue Phase is set to Preparation Phase, check the Target Vehicle Identifier. i. If the Target Vehicle Identifier of the OriginatingDialogue Entry does not equal the CLCM.messageHeader.stationID, refrain from executing further steps. b. If the Dialogue Phase equals Execution Phase, refrain from executing further steps. 5. If CLCM.messageBody.requestIDequals the Request Identifier of the Originating Dialogue Entry, inform ITS Applications about the received response using primitive CLCS.CONTROL.response-indication and parameters set according totable Refrain from executing any further steps. 19

28 Table 10 CLCS.CONTROL.response-indication settings Field Dialogue Identifier Request Identifier Response Type Target Vehicle Target Vehicle Preceding Vehicle Identifier Predicted Lane Change Speed Group Identifier Value The Dialogue Identifier of the OriginatingDialogue Entry CLCM.messageBody.requestID CLCM.messageBody.responseType CLCM.messageBody.targetVehicle CLCM.messageBody.targetVehiclePrecedingVehicleID CLCM.messageBody.predictedLaneChangeSpeed CLCM.messageBody.groupID 7. Check the Dialogue Phase of the OriginatingDialogue Entry a. If the Dialogue Phase is set to Preparation Phase or Execution Phase, check the Target Vehicle Identifier. i. If the Target Vehicle Identifier of the OriginatingDialogue Entry does not equal the CLCM.messageHeader.stationID, refrain from executing further steps. b. If the Dialogue Phase equals Search Phase, refrain from executing further steps. 8. Inform ITS Applications about the abort request using primitive CLCS.CONTROL.abort-indication and parameters set according totable 11. Refrain from executing any further steps. Table 11CLCS.CONTROL.abort-indication settings Field Dialogue Identifier Value The Dialogue Identifier of the OriginatingDialogue Entry 9. Check the Dialogue Phase of the OriginatingDialogue Entry a. If the Dialogue Phase is set to Preparation Phase, check the Target Vehicle Identifier. i. If the Target Vehicle Identifier of the OriginatingDialogue Entry does not equal the CLCM.messageHeader.stationID, refrain from executing further steps. b. If the Dialogue Phase equals Search Phase or Execution Phase, refrain from executing further steps. 10. Inform ITS Applications about the prepared request using primitive CLCS.CONTROL.prepared-indication and parameters set according totable 12. Refrain from executing any further steps. Table 12 CLCS.CONTROL.prepared-indication settings Field Dialogue Identifier Value The Dialogue Identifier of the OriginatingDialogue Entry

29 On the reception of primitive BTP-DATA.indication, the CLCS shall execute the following operations: 1. Decode the BTP-DATA.indication.Data according to the specification of Section Check the messagebody value of the decoded CLCM. 1. If the messagebody is a lanechangerequest, continue with step If the messagebody is a lanechangeabort, continue with step Else, drop the CLCM and refrain from executing further steps. 3. Lookup the Target Dialogue Entry in the Target Dialogue Table with originating station identifier and sequence number equal to respectively CLCM.messageHeader.actionID.originatingStationID and CLCM.messageHeader.actionID.sequenceNumber 1. If no dialogue entry is found, create a new Target Dialogue Entry according to Table 13and add the entry to the Target Dialogue Table. Table 13 Target Dialogue Entry initialization values Field Dialogue Identifier Originating Station Identifier Sequence Number GeoNetworking Address Value A unique identifier not already assigned to another originatingdialogue entry CLCM.messageHeader.actionID.originatingStationID CLCM.messageHeader.actionID.sequenceNumber GeoNetworking Address of the entity that sent the CLCM 4. Check the Request Identifier 1. If CLCM.messageBody.requestID is smaller than the Request Identifier of the Target Dialogue Entry i. Drop the CLCM. Refrain from executing any further steps. 2. If CLCM.messageBody.requestID is larger than the Request Identifier of the Target Dialogue Entry i. Update the Request Identifier of the Target Dialogue Entry to CLCM.messageBody.requestID. ii. Update the GeoNetworking Address of the Target Dialogue Entry to the GeoNetworking Address of the entity that sent the CLCM. 5. Inform ITS Applications about the lane change request using primitive CLCS.CONTROL.requestindication and parameters set according totable 14. Refrain from executing any further steps. Table 14CLCS.CONTROL.request-indication settings Field Dialogue Identifier Request Identifier Value The Dialogue Identifier of the Target Dialogue Entry CLCM.messageBody.requestID 21

30 Target Vehicle Identifier Subject Vehicles Lane Change Direction Target Area Target Lane Target Lane Change Time Target Lane Change Speed Minimum Lane Change Distance CLCM.messageBody.targetVehicleID CLCM.messageBody.subjectVehicles CLCM.messageBody.laneChangeDirection CLCM.messageBody.targetArea CLCM.messageBody.targetLane CLCM.messageBody.targetLaneChangeTime CLCM.messageBody.targetLaneChangeSpeed CLCM.messageBody.minimumLaneChangeDistance 6. Lookup the Target Dialogue Entry in the Target Dialogue Table with originating station identifier and sequence number equal to respectively CLCM.messageHeader.actionID.originatingStationID and CLCM.messageHeader.actionID.sequenceNumber. 1. If no dialogue entry is found, drop the CLCM and refrain from executing any further steps. 7. Check the Request Identifier 1. If CLCM.messageBody.requestID is larger than the Request Identifier of the Target Dialogue Entry i. Update the Request Identifier of the Target Dialogue Entry to CLCM.messageBody.requestID. ii. Update the GeoNetworking Address of the Target Dialogue Entry to the GeoNetworking Address of the entity that sent the CLCM. iii. Inform ITS Applications about the lane change abort request using primitive CLCS.CONTROL.abort-indication and parameters set according totable 11. Refrain from executing any further steps Message Format Specification The Cooperative Lane Chang Message (CLCM) is composed of an ITS PDU header, a CLCM header and a CLCM body. The ITS PDU header is a common header used by multiple ETSI facility-layer messages like the Cooperative Awareness Message (CAM) and Decentralized Environmental Notification Message (DENM). The ITS PDU header contains a message identifier, protocol version and ITS-S temporal identifier of the ITS-S originating the CLCM.The CLCM message body consists of DFs and DEs describing the different cooperative lane change message types. A detailed description of the DEs and DFs of a CLCM can be found in AppendixHiba! A hivatkozási forrás nem található..

31 The CLCM format makes use of the common data dictionary as defined inetsi TS [9] and Appendix5.1.The messageformat is represented in ASN.1 according to Appendix5.1and shall beencoded using the Unaligned Packed Encoding Rules (PER) as defined iniso/iec [10]. 2.2 Convoy Control Communication Service Service Introduction The convoy control communicationn service allows cooperative vehicles to plan automated adjustments of their speed and heading according to a decentralized mechanism, or to plan ahead needed lane change manoeuvres. This service supports continuous control over the vehicles longitudinal dynamics and lane change manoeuvring, supporting inherently safe multi-lane driving on highways. As the following figure illustrates, the supported Convoy driving use caseinvolves a higherlevel of control over the vehicle dynamics than the Cooperative Lane Change Service specified in Section 2.1, but a lower level of control than Cooperative Platooning use case. The actual selection of the activated use case depends on the traffic scenario context and capabilities of the automated vehicle. When the automated vehicle is part of a Convoy, its lane change manoeuvres are supported by the Convoy Control Communication Service specified in this section, while when the automated vehicle is not part of a Convoy formation, its lane change manoeuvres are supported by the Cooperative Lane Change Service specified in Section2.1. In contrast, lane changes are not possible in the platooning mode, i.e. the automated vehicle must exit a platoon before performing a needed lane change. This section specifiesthe inter-vehicle communications forthe functionalities offered by Convoy driving service: Longitudinal manoeuvre negotiation for convoy driving Cooperative lane change transaction in convoys Joining and leaving of convoys Functional Convoy negotiations During Convoy driving mode, neighbouring automated vehicles periodically exchange manoeuver negotiation messages to adjust their speed and heading for mutually safe distance keeping and formation maintenance. The convoy control mechanism facilitates safe execution of merging-in lane changes. Convoy driving mode is applicable to highly automated vehicles (with automated lateral and longitudinal control) or vehicles with at 23

32 least Cooperative-ACC functionality. Lane changes are also safely executed, as needed,within the Convoy driving vehicles.the details of one possible approach for Convoy driving are presentedin Marjovi et al. [3]. For compatibility of cooperative Convoy driving, the same control algorithm must be adapted in all vehicles participating in the Convoy cluster. Considering the graph-based control method described in [3], the following control parameters of the Convoy must be considered in the standardizations:w x ((longitudinal edge weights), w y ((lateral edge weights), w d ((diagonal edge weights), α(coefficient of convoy/lane-keeping). To guarantee safety and convoy formation stability, these parameters should be set to identical values in all vehicles in the convoy Interface Specification Convoy negotiations Convoy negotiation transactions request BTP/ Single Hop Broadcast network layer service for the delivery of all convoy management messages. The Response messages are sent over BTP / GeoUnicast network layer service. The BTP port 3003 shall be used for these transactions. The CAM messages containing convoy-specific extensions are sent using BTP / Single Hop Broadcast service, as specified in ETSI EN [8] Convoy negotiations The following figure illustrates an example of transactions involved in the Convoy driving mode.all members of the convoy periodically update their position through broadcasting Update messages. These Update broadcasts can be implemented through CAM messages, since the needed information content is largely overlapping. With respect to the current CAM specifications in ETSI EN [6], the new parameters to be added through protocol extension are: the Convoy-ID and the Convoy s goal velocity (v g ). When being in convoy mode, the vehicle must maintain the minimum CAM frequency as required for the Update procedure; the recommended frequency for normal convoy control in highways is 10 Hz. A vehicle approaching the convoy learns about its existence through the reception of these Update broadcast messages. The following paragraphs describe convoy coordination messaging, which have the purpose of updating local neighbourhood graphs of convoy members, ahead of planned manoeuvers. Convoy creation: A vehicle capable of convoy driving detects whether there is any nearby convoy which it may join. In the absence of any existing convoy, it may initiate a 1-member convoy itself, assign a new Convoy ID, and broadcast its information through the Update messages. Joining to a convoy: When a vehicle decides to join a nearby convoy, it sends a Join Request message; this request message shall contain the application-layer identifier (ITS-Station ID) of convoy members, between which the joining vehicle intends to merge on the targeted lane. If the convoy is joined from front or back, then naturally only one of these neighbour identifiers shall be present.the vehicles indicated in the Join Request message must respond bya Join Accept message. With this information contained in the received Join Request / Accept Figure 4 Sequence Diagram Convoy Negotiation Procedure

33 messages, all nearby convoy members shall update their local neighbourhood graph. As a special case, if a vehicle joins a convoy while driving on a neighbouring lane to all other convoy members, there shall be no neighbour identifiers present in the Join Request message, and it does not need any response for joining. The joined vehicle shall begin also sending convoy Update information through extended CAMs. Lane change in a convoy:when aconvoy member plans a lane change, it broadcasts a Lane Changemessage; this message contains the application-layer identifier of those convoy members, between which the vehicle intends to merge in the targeted lane.there is no response message in this procedure. Leaving a convoy: When a convoy member plans to leave the convoy e.g. via a departure at an upcoming highway exit - it broadcasts a Leave message.there is no response message in this procedure. Modifying the Local Graph: Each time that a convoy member updates its local graph, e.g. in response to a merging-in new convoy member, it sends a Modify Graph broadcast to inform its neighbours about its new graph.in multi-lane convoys, the neighbours may need to modify their own local graphs correspondingly. This way the consistency of local graphs is maintained even in long convoys, achieved through propagating graph modifications. The Modify Graph message contains the new listing of direct neighboursdriving in front, behind, left and right of the reporting station. This information is sufficient for all other relevantneighbours to adjust their local graphs accordingly. Modifying the Group Speed: The group speed of the convoy may be altered during the travel, when new group speed update is received through the cooperative speed advising service as specified in Section2.8. In most situations, all convoy members receive simultaneously the same speed update through a cooperative speed advising broadcast. However in case of large convoys it may happen that only part of the convoy receives an updated speed, while the group speed parameter must be consistently maintained through the entire convoy. Upon receiving a new speed advice through the cooperative speed advising service, a convoy member updates its group speed parameter, and broadcasts this new value in the periodic CAM broadcasts. Any inconsistency is detected by receiving a CAM broadcast from a convoy member (identified by same Convoy ID), which contains a different group speed. In response to such a detected inconsistency, the vehicle checks whether it has recently made a group speed update, and in that case sends a Modify Group Speed broadcast containing the updated group speed parameter. Receiving a Modify Group Speed message, which contains a different group speed from the current one, is processed in the same way as a cooperative speed advising message; thereby a consistent group speed is maintained within the convoy. In order to avoid broadcast storms, a random timer is started before sending a Modify Group Speed message, and the broadcast is made upon the expiration of this timer. During the timer countdown, any received Modify Group Speed messages originating from the same convoy will cause the cancellation of the pending broadcast. Modifying the cooperative speed advise: When a vehicle at the front of the convoy is unable to maintain the group speed, e.g. because of the traffic conditions, it sends a Speed Report message, as specified in Section2.8. This message is sentto the server, which is locally responsible for the cooperative speed advising. Upon processing Speed Report messages, the server calculates new cooperative speed advises for the involved road segments. 25

34 Response messages: In order to ensure that all local neighbours have updated their graphs in response to the above transactions, the following Response procedure is triggered upon processing any of the above convoy coordination messages, with the exception of CAM and Join Request messages: Response by the vehicle receiving a convoy coordination message: 1. If the receiving vehicle is part of the sending vehicle s local neighbourhood graph, and if it has not processed yet the received message, it processes the received message and adjusts its neighbourhood graph as needed. Otherwise the message is discarded. Duplicate messages are discriminated by matching the application-layeridentifier of the sender and the message timestamp. 2. If the received message is being processed, aresponse message is sent back to the sender of convoy coordination message. Response processing by the vehicle sending a convoy coordination message: 1. Wait within a defined timeout for receiving Response message from all vehicles in its local neighbourhood graph. In case the convoy coordination message has been already retransmitted, the Response message is expected only from those neighbourswho have not yet acknowledged. 2. If response is missing from some vehicle in its neighbourhood graph, and the number of retransmissions has not exceeded a threshold value, the convoy coordination message is retransmitted using the same timestamp as the initial transmission. Processing is continued from step 1. The relative longitudinal position among vehicles in neighbouring lanes may change during multi-lane convoy driving, and the local neighbourhood graph shall be kept up to date through processing the periodically broadcast Update information, which contains vehicle positions at the needed accuracy. There is no specific messaging needed for this purpose Message Format Specification Convoy negotiations This section specifies the Convoy negotiation messages in tabular format. The corresponding ASN.1 syntax of the CMM is specified in Appendix5.2. The CMM is encoded according the Unaligned Packed Encoding Rules (UPER) as specified in iniso/iec [10]. 2.3 Cooperative Intersection Control Service Service Introduction The cooperative intersection control service (CICS) is a service that supports the communication between vehicle and intersection controller for priority based coordination of autonomous vehicles at intersections as described by Qian et al. in [4]. The CICS components as illustrated infigure 5 implements this service in the architecture of AutoNet2030.

35 Priority based coordination of autonomous vehicles at intersections is an approach in which a Roadside ITS station, also called a (cooperative) intersection controller, is deciding on the relative priorities between (autonomous) vehicles to pass the intersection. Such approach can be proven to be collision-free and deadlockfree [4]. Priority based coordination is heavily depending on C2I and I2C communication.autonomous vehiclesare using C2I communication to request the entry to an intersection and thereby specifying the ingress and egress lanes, the predicted time to enter the intersection and vehicle parameters like position, speed and heading of the approaching vehicle. The cooperative intersection controller is using this information to calculate the relative priorities between vehicles and uses I2C communication to inform these vehicles about these priorities. The following sections specify the CICS components, its protocol operations and message formats. These specifications are inspired by the work of Qian et al. in [4] but aim to support a multitude of priority-based cooperative intersection control algorithms Functional The CICS service can be split in two parts. One part of the service is running in a Road-Side ITS station and supporting the cooperative intersection controller whereas the other part is running in the Vehicle ITS station of a (autonomous) vehicle. The component diagram of the CICS component for the Road-Side ITS station is depicted in Figure 5. This component can be sub-divided in four sub-components: 1. Controller Protocol Operations: this sub-component is implementing and executing the protocol operationsof the Road-Side ITS station upon the reception or transmission of a CICM. The protocol operations of this sub-component are specified in Section Encoding: encoding of CICS messages in the format as specified in Section Decoding: decoding of CICS messages according to the format as specified in Section Service Announcement: regular announcement of the CICS service to surrounding autonomous vehicles. This service is specified in Section The CICS component running at a Road-Side ITS station is offering an interface called CICS-IS. This interface is the access point for the cooperative intersection controller application to the CICS service. This interface is described as a SAP in Appendix 6.2. This component is using the BTP-DATAinterface as specified in ETSI EN [11] for the dissemination of CICS messages. 27

36 Figure 5UML Component Diagram of the Cooperative Intersection Control Servicefora Road-Side ITS-S The component diagram of the CICS component for in the Vehicle ITS station of an (autonomous) vehicle is illustrated in Figure 6. The functionality of this component can be sub-divided in three sub-components: 1. Vehicle Protocol Operations: this sub-component is implementing and executing the protocol operations of the vehicle ITS-S station upon the reception or transmission of a CICS. The protocol operations of this sub-component are specified in Encoding:encoding of CICS messages in the format as specified in Section Decoding: decoding of CICS message according the format as specified in Section Figure 6UML Component Diagram of the Cooperative Intersection Control Service for a Vehicle ITS-S The interfaces of the CICS component are described in the next section Interface Specification Interface with ITS Applications The CICS component interacts with ITS Applications on a Road-side ITS-S and Vehicle ITS-Sthrough respectively interfacescics.is and CICS.IE. Thesee interfacesare described as a Service Access Point (SAP) and corresponding primitives in Appendix6.2.

37 Interface with the Basic Transport Protocol On a Road-Side ITS-S, the CICS component requests the BTP component to disseminate IEMs using the interface BTP.DATA. On a Vehicle ITS-S, this interface is used to receive IEMs from the BTP component. The BTP is specified in ETSI EN [8]. The specification of interface BTP.DATA is out-of-scope of the current document Interface with the Reliable Basic Transport Protocol On a Vehicle ITS-S, the CICS component requests the RBTP component to transmit IEMs using the interface RBP.DATA. On a Road-Side ITS-S, this interface is used to receive IEMs from the RBTP component. The RBTP is specified in Section The interface RBTP.DATA is specified as a Service Access Point (SAP) in Section Interface with Security The CICS component interacts with the Security component through the interface SEC.PSEUDONYM in order to block the pseudonym change during periods in which the ITS station is involved in an intersection entry dialogue. The specification of this interface is out of scope of the current document Protocol Operations Vehicle Protocol Operations The protocol operations described in this section apply to vehicle ITS stations which want to request permission to enter an intersection. On the reception of a CICS.IE.request primitive, the CICS shall execute the following operations: 1. Request security to block for pseudonym changes (e.g. facilities-layer station identifier). 2. Create an Intersection Entry Message (IEM)as specified in Section Set the fields of the created IEM according to Table Request the BTP/GeoNetworking-stack for the transmission of a GeoUnicast using primitive RBTP.DATA.request as specified in Table 16. a. Check the Confirm Code of the returned primitive RBTP.DATA.confirm. i. If the ConfirmCode is NotAccepted_InvalidParametersorNotAccepted_UnspecifiedReason, respond with primitive CICS.IE.responseandResponse Code set to NotAccepted_UnspecifiedReason. Unblock for pseudonym changes and omit all following steps. b. Check the Result Code of the returned primitive RBTP.DATA.response i. If the Response Codeis Acknowledged, respond with primitive CICS.IE.responseandset its Response Code and Request Identifierset to respectivelyconfirmed and the requestid of the transmitted IEM. Do NOTunblock for pseudonym changes. ii. If the Response Code is Unacknowledged, responds with primitive CICS.IE.response and Response Code set to Unconfirmed. Omit the Request Identifier. Unblock for pseudonym changes. 29

38 Table 15 IEM parameter settings on CICS.IE.request primitive Field IEM.header Value ItsPduHeader protocolversion currentversion (1) messageid 131 stationid IEM.messageBody generationtime intersectionid requestid intersectionentrytimestampdelta inlane outlane priorityclass Facility-layer station identifier, same as used by the CABS and DEN BS as specified in as specified in ETSI TS [9]. IntersectionEntryRequest ITS Time at the time of generation of the IEM message as specified in ETSI TS [9]. CICS.IE.request.Intersection Identifier CICS.IE.request.Request Identifier if set, or a new generated and unused Request Identifier CICS.IE.request.Intersection Entry Timestamp -generationtime CICS.IE.request.In-Lane CICS.IE.request.Out-Lane CICS.IE.request.Priority-Class stationrole Station role of the requesting ITS-S as specified in ETSI TS [9]. stationtype The station type of the requesting ITS-S as specified in ETSI TS [9] stationposition stationspeed stationheading stationlength stationlonaccel The reference position of the ITS-S at time of requesting intersection entry as specified in ETSI TS [9] The station speed of the ITS-S at time of requesting intersection entry as specified in ETSI TS [9]. The heading of the ITS-S at time of requesting intersection entry as specified in ETSI TS [9]. The length of the ITS-S at time of requesting intersection entry as specified in ETSI TS [9]. The longitudinal acceleration of the ITS-S at time of requesting intersection entry as specified in ETSI TS [9].

39 Table 16Minimum set of PCI passed from the CICS to the RBTP/GN-stack on aniem transmission request Parameter Data Requirement Optionality Destination port 3004 Mandatory Source port 3004 Mandatory Acknowledgement Timeout 1000 Mandatory GN Destination Address The GN Address of the targeted ITS-S running the intersection controller. This value is provided in the primitivescics.ie.request and CICS.IE.cancel. Mandatory GN Communication profile ITS-G5 Mandatory GN Maximum packet lifetime 1000 Mandatory GN Traffic class TC ID 6 (see Appendix 9), SCF and channel offload disabled Mandatory ITS-G5 Channel Type G5-SCH6 Mandatory Length The length in bytes of the IEM message Mandatory Data The IEM message encoded according the ASN.1 UPER encoding rules as specified in ISO/IEC [10]. Mandatory On the reception of a CICS.IE.cancelprimitive, the CICS shall execute the following operations: 1. Create an IEM as specified in Section Set the fields of the created IEM according to Table Request to the BTP/GeoNetworking-stack the transmission of a GeoUnicast using primitive RBTP.DATA.request as specified in Section The parameters of the RBTP.DATA.request shall be set according totable 16. a. Check the Confirm Code of the returned primitive RBTP.DATA.confirm i. If the Confirm Code is NotAccepted_InvalidParametersorNotAccepted_UnspecifiedReason, respond with primitive CICS.IE.response and Response Code set to NotAccepted_UnspecifiedReason. Goto step 3. b. Check the Result Code of the returned primitive RBTP.DATA.result i. If the Result Code is Acknowledged, respond with primitive CICS.IE.response and Response Code set to Confirmed. Goto step 3. ii. If the Result Code is Unacknowledged, responds with primitive CICS.IE.response and Response Code set to Unconfirmed. Goto step Unblock for pseudonym changes. 31

40 Table 17IEM parameter settings on CICS.IE.cancel primitive Field IEM.header Value ItsPduHeader protocolversion currentversion (1) messageid 131 stationid IEM.messageBody Facility-layer station identifier, same as used by the CABS and DEN BS as specified in as specified in ETSI TS [9]. IntersectionEntryCancellation generationtime ITS Time at the time of generation of the IEM message as specified in ETSI TS [9]. intersectionid requestid CICS.IE.cancel.Intersection Identifier CICS.IE.cancel.Request Identifier On the reception ofthe primitive BTP-DATA.indicate BTP destination port set to 3002, the CICS shall execute the following operations: 1. Check the IEM.messageBody a. If the messagebody contains an IntersectionEntryRequest or IntersectionEntryCancellation, drop the message and omit any further steps 2. Inform any interested upper-layer entity with a primitive CICS.IE.inform and parameters set according totable 18. Table 18 Parameter settings forcics.ie.inform primitive on IEM reception Field Generation Time GN Address Intersection Identifier Priority Graph Value IEM.messageBody.entryStatus.generationTime RBTP.DATA.indicate.GN Source position vector.gn Address IEM.messageBody.entryStatus.intersectionID IEM.messageBody.entryStatus.entryGraph CooperativeIntersection Controller Protocol Operations The following operation shall be executed on start-up of the CICS component:

41 1. Start a timer t_service_announcement for each intersection identifier for which the intersection controller is scheduling intersection entry. Set the timeout value of the timer to 1000 milliseconds. The following operations shall be executed when stopping the CICS component: 1. Stop all scheduled timerst_service_announcement. On the reception of primitive CICS-IS.announce, the CICS shall execute the following operations: 1. Create an IEM as specified in Section Set the fields of the created IEM according totable Request a single-hop broadcast of the IEM using the BTP/GeoNetworking-stack using the primitive BTP- Data.request as specified in ETSI EN [8]. The parameters of the BTP-Data.request shall be set according to Table Restart timer t_service_announcementto a timeout of 1000 milliseconds for the intersection identifier as given in the primitive CICS-IS.announce. Table 19IEM parameter settings on CICS.IS.announce primitive Field IEM.header Value ItsPduHeader protocolversion currentversion (1) messageid 131 stationid IEM.messageBody Facility-layer station identifier, same as used by the CABS and DEN BS as specified in as specified in ETSI TS [9]. IntersectionEntryStatus generationtime ITS Time at the time of generation of the IEM message as specified in ETSI TS [9]. intersectionid prioritygraph CICS.IS.announce.Intersection Identifier CICS-IS.announce.Priority Graph. Table 20Minimum set of PCI passed from the CICS to the BTP/GN-stack on an IEM transmission request Parameter Data Requirement Optionality BTP type BTP-B Mandatory Destination port 3004 Mandatory Destination port info - Optional; Applicable if additional information for the destination 33

42 GN Packet transport type SHB Mandatory GN Communication profile ITS-G5 Mandatory GN Traffic class TC ID 6 (see Appendix9), SCF and channel offload disabled port needs to be provided. Mandatory ITS-G5 Channel Type G5-SCH6 Mandatory Length The length in bytes of the IEM message Mandatory Data The IEM message encoded according the ASN.1 UPER encoding rules as specified in ISO/IEC [10]. Mandatory On the timeout of timer t_service_announcement for a particular intersection identifier, the CICS shall execute the following operations: 1. Create an IEM as specified in Section Set the fields of the created IEM according totable 21. The Priority Graph in the created IEM is omitted. 2. Request a single-hop broadcast of the IEM using the BTP/GeoNetworking-stack using the primitive BTP- Data.request as specified in ETSI EN [8]. The parameters of the BTP-Data.request shall be set according to Table Restart timer t_service_announcement to a timeout of 1000 milliseconds for the intersection identifier as given in the primitive CICS-IS.announce. Table 21IEM parameter settings on t_service_announcement timeout Field IEM.header Value ItsPduHeader protocolversion currentversion (1) messageid 131 stationid IEM.messageBody Facility-layer station identifier, same as used by the CABS and DEN BS as specified in as specified in ETSI TS [9]. IntersectionEntryStatus generationtime ITS Time at the time of generation of the IEM message as specified in ETSI TS [9]. intersectionid Intersection Identifier of timer t_service_announcement On the reception of primitive RBTP.DATA.indication with BTP destination port set to 3002, the CICS shall execute the following operations:

43 1. Check the IEM.messageBody a. If the messagebody contains an IntersectionEntryStatus, drop the message and omit any further steps. b. If the messagebody contains an IntersectionEntryRequest, inform any interested upper-layer entity of the request with a primitive CICS.IE.inform and parameters set according to Table 22. c. If the messagebody contains an IntersectionEntryCancellation, inform any interested upperlayer entity of the request with a primitive CICS.IE.inform and parameters set according to Table 23. Table 22Parameter settings for CICS.IS.indicate primitive on reception of a request IEM Field Generation Time Is Cancellation Intersection Identifier Request Identifier In-Lane Out-Lane Priority-Class Station Identifier Station Type Station Position Station Speed Station Heading Station Length Station Acceleration Value IEM.messageBody.entryRequest.generationTime false IEM.messageBody.entryRequest.intersectionID IEM.messageBody.entryRequest.requestID IEM.messageBody.entryRequest.inLane IEM.messageBody.entryRequest.outLane IEM.messageBody.entryRequest.priorityClass IEM.ItsPduHeader.stationID IEM.messageBody.entryRequest.stationType IEM.messageBody.entryRequest.stationPosition IEM.messageBody.entryRequest.stationSpeed IEM.messageBody.entryRequest.stationHeading [IEM.messageBody.entryRequest.stationLength] IEM.messageBody.entryRequest.stationLonAccel Table 23Parameter settings for CICS.IS.indicate primitive on reception of a cancellation IEM Field Generation Time Is Cancellation Intersection Identifier Value IEM.messageBody.entryRequest.generationTime true IEM.ItsPduHeader.stationID 35

44 2.3.5 Message Format Specification The Intersection Entry Message (IEM) is composed of an ITS PDU header and aniem body. The ITS PDU header is a common header used by multiple ETSI facility-layer messages like the Cooperative Awareness Message (CAM) and Decentralized Environmental Notification Message (DENM). The ITS PDU header contains a message identifier, protocol version and ITS-S temporal identifier of the ITS-S originating the IEM. The IEM message body consists ofanactive request, cancellation request or status update. The active request can be used by a vehicle to request entry or update a previous entry request. The status update is used by the cooperativeintersection controller to announce the assigned intersection entry priorities. The IEM format makes use of the common data dictionary as defined in ETSI TS [9].The message format is represented in ASN.1 and specified in Appendix5.3. The CICM is encoded using the Unaligned Packed Encoding Rules (UPER) as defined iniso/iec [10].

45 2.4 Extended Cooperativee Awareness Basic Service Service Introduction The Cooperative Awareness Basic Service (CABS) is a standardized facilities-layer component designed to exchange Cooperative Awareness Messages (CAM) between ITS Stations (ITS-S) in the ITS networkto support the BSA road safety application. The CABS is specified in ETSI EN [6]. The functionalities of the CABS can be summarized in two main basic services: sending and receiving of Cooperative Awareness Messages (CAMs). CAMs are messages which are periodically exchanged between ITS- them. The transmission Ss in communication range, with the aim to create and maintain awareness between frequency of CAMsis controlled by the CABSbased on the ITS-S type, its dynamics and the congestion on the communication channel. Moreoverr the CABS has the capability to verify CAM content against the Service Specific Permissions (SSP) of the sending ITS-S. The CAM content is mainly related with the status and dynamics of the sending ITS-S. For vehicle ITS-Ss, this content includesamong others a time, position, motion state, activated systems, vehicle dimensions, vehicle type and the vehicle role in the road traffic. In the AutoNet2030 project, we propose an extension of the standardized CAM towith new high and low frequency containers to support the cooperative automated driving application. This application handles traffic situations like driving in a convoy, a platoon andcooperative lane changes Functional The UML Component Diagram of the Extended CABS component is illustrated in Figure 7 and consists of the following sub-components: Transmission Management: implements the procedure to transmit CAMs as specified in Section This sub-component extends the base specification with new generation rules. Reception Management: implements the procedure to received CAMs as specified in Section Encoding CAM: encodes a CAM according to the format as specified in Section Transmission management lists which optional data elements (DE) and data frame (DF) shall be included. Decoding CAM: decodes a CAM according to the format as specified in Section Figure 7: UML Component Diagram of the Extended Cooperative Awareness Basic Service 37

46 2.4.3 InterfaceSpecification Interface with ITS applications The CABS is exposing interface CABS.STATE for ITS applications to set and update automateddriving-related parameters. This interface is typically used, but not limited to ITS applications which predict, plan and control the vehicle in automated mode. The data set by ITS Application may be included in the following transmitted CAMs according to the protocol operations described in Section 2.4.4, until the data is update or outdated. The data that can be set using thecabs.state interface are described in Table 24. Table 24: List of automated driving-related parameters which can be set using the CABS.STATE interface Parameter Data Requirement Optionality Operating Mode Driving Mode Automated Control The operating mode of the CABS. Shall be set to either Normal Mode or High Awareness Mode. The level of automation of the ego-vehicle: semiorfully automated The automated driving functions engaged by the ego-vehicle Mandatory Mandatory Mandatory Target Speed The target speed of the ego-vehicle. Mandatory Target Longitudinal Acceleration Braking Capacity The target acceleration in the longitudinal direction of the ego-vehicle The maximum brake capacity of the ego-vehicle. This value may be calculated on-line taking into account e.g. the vehicle s weight, weather conditions, tire conditions, etc. Mandatory Mandatory Target Distance to Preceding Vehicle The target distance between the ego-vehicle s front bumper and the rear bumper of the immediate preceding vehicle in the same lane. Optional; Provided when available Target Distance to Following Vehicle The target distance between the ego-vehicle s rear bumper and the front bumper of the immediate following vehicle in the same lane. Optional; Provided when available Path Prediction Trajectory prediction of the ego-vehicle Optional; Provided when available Group Identifier Identifier of the platoon or convoy in which the ego-vehicle is driving Optional; Provided when driving in a platoon or convoy Group Speed Target speed of the convoy or platoon Optional

47 Interface with the Vehicle Data Provider (VDP) The CABS relies on the Vehicle Data Provider (VDP) for the provision of up-to-date dynamic vehicle data like the yaw-rate, accelerations and measured distance to a preceding vehicle in the same lane. The specification of this interface is out-of-scope of the current document Interface with Position and Time (POTI) The CABS relies on the Position and Time (POTI) component for the provision of up-to-date position and time information. The specification of this interface is out-of-scope of the current document Interface with the Local Dynamic Map (LDM) The CABS delivers data from received CAMs to the Local Dynamic Map for further processing and eventual delivery to ITS applications. The specification of this interface is out-of-scope of the current document Interface with Management The CABS relies on the management information base (MIB) of management for the provision of static configurationand vehicle parameters like the vehicle width and length. The specification of this interface is outof-scope of the current document Interface with the Basic Transport Protocol (BTP) The CABS relies on the interface BTP.Data of the Basic Transport Protocol (BTP) for the dissemination of CAMs to other ITS-Ss in the communication range. The BTP and its interfaces arespecified in ETSI EN [6] Protocol Operations The CABS base standard in ETSI EN [6] has defined several generation rules for the generation and transmission of CAMs. These rules for a vehicle ITS-S take into account its dynamics, state of the communication channel and as such makes a trade-off between awareness of the ITS-S and channel congestion. In AutoNet2030, we consider traffic situations in which the awareness is paramount and we require that CAMs are transmitted with 10Hz in several situations e.g. when driving in a platoon or convoy. For this reason, we introduce additional generation rules that transmit CAMs a high frequency in such situationsalso exploiting more than one transmission channel to divide the load. In this section wespecify the generation rulesof the extended CABS per operation mode of the vehicle ITS-S: Normal Mode: the triggering conditions and generation rules in ETSI EN [6] apply. The generated CAMs shall not include the containers AutomatedVehicleContainerHighFrequency and AutomatedVehicleContainerLowFrequency as described in Section and the CAMs are transmitted over the Control Channel (CCH). High Awareness Mode: in high-awareness mode, the following triggering conditions apply: 1. Upon the expiration of the timer T_CheckCamGen, check if the triggering conditions in EN [6] are met (note: T_CheckCamGen shall be equal to or less than T_GenCamMin = 100 milliseconds). 39

48 i. If yes, the generation rules in ETSI EN [6] apply. The generated CAM shall not include the containers AutomatedVehicleContainerHighFrequency and Automated- VehicleContainerLowFrequencyand the CAM shall be transmitted over the CCH channel. ii. Otherwise, the CABS shall generate a CAM with the AutomatedVehicleContainerHigh- Frequencycontainer. No SpecialVehicleContainer shall be included and the CAM shall be transmitted using the parameters intable 25,in particular in this case the generated CAMs are transmitted over the Service Channel 6 (SCH6). a. If the time since the last CAM with aautomatedvehiclecontainerlow- Frequencycontainer is 500 milliseconds or more, the CAM shall contain the AutomatedVehicleContainerLowFrequencycontainer. Table 25Minimum set of PCI passed from the Extended CABS to the BTP/GN-stack on a High Awareness CAM transmission request Parameter Data Requirement Optionality BTP type BTP-B Mandatory Destination port 2001 Mandatory Destination port info - Optional; Applicable if additional information for the destination port needs to be provided. GN Packet transport type SHB Mandatory GN Maximum packet lifetime 100 Mandatory GN Communication profile ITS-G5 Mandatory GN Traffic class TC ID 5 (see Section 9), SCF and channel offload disabled Mandatory ITS-G5 Channel Type G5-SCH6 Mandatory Length The length in bytes of the CAM message Mandatory Data The CAM message encoded according the ASN.1 UPER encoding rules as specified in ISO/IEC [10]. Mandatory On the reception of a CAM by means of primitive BTP.DATA.indication, the CABS shall execute the following operations: 1. Check the protocolversion of the received CAM a. If the protocolversion equals 1, decode the received CAM according to ETSI EN [6]. b. If the protocolversion equals 2, decode the received CAM according to Section Process the received CAM according to ETSI EN [6].

49 2.4.5 Message Format Specification The CAM structure as specified in ETSI EN [6] and illustrated in Figure 8, consists of several containers: the ITS PDU header, the basic container, a high frequency container, a low frequency container and a special vehicle container. The low frequency container and special frequency container are optional whereas the ITS PDU header, basic container and high frequency container shall be present in each transmitted CAM. The base specification was designed to supportextensions at designated parts in the message while keeping backwards compatibility: the basic container can be extended with additional data element and new high frequency, low frequency and special vehicle containers may be introduced. The specification does however not support the extension of current BasicVehicleHighFrequencyContainer and BasicVehicleLowFrequency- Container. Figure 8: Structure of the Cooperative Awareness Message In AutoNet2030, we extend the CAM with an additional high frequency and low frequency container for the dissemination of addition informationto support automated driving situations (e.g. driving in a platoon or convoy, cooperative lane change, etc.). These containers are called respectively AutomatedVehicleContainerHighFrequency and AutomatedVehicleContainerLowFrequency. The AutomatedVehicleContainerHighFrequency container is a compact version of the BasicVehicleContainer- like its heading, speed, HighFrequency and contains only theminimaldynamic information of a vehiclee accelerations and distance to a preceding vehicle. Such compact container shortenss the length of the CAM and consumes less network resources while transmitted at high frequencies like 10Hz or higher. The AutomatedVehicleContainerLowFrequency introduces new Data Elements (DEs) and Data Frames (DFs) for automated driving which are sent at lower frequency (e.g. 2Hz). The AutomatedVehicleContainerLowFrequency may specify the driving mode (e.g. semi or fully autonomous), engaged automated control systems, target speed and acceleration, brake capacity, target distance to preceding and following vehicles, predicted trajectory and convoy/platoon identifier in which the ego-vehicle is driving. In addition, we added the DE distancetoprecedingvehicle to the BasicVehicleHighFrequencyContainer which breaks backwards compatibility with the base specification. This DE is included for the semi-automated and automated future vehicles to consider the information provided by vehicle s sensors about the measured distance to the preceding vehicle,,andbetter supportingcooperative functionalities like Cooperative-ACC and Cooperative Lane Change. For this reason, the protocolversion of the CAM shall be set to 2. The message format of the CAM used in AutoNet2030 is represented in ASN.1 and specified in Appendix5.4. The CAM shall be encoded using the Unaligned Packed Encoding Rules (UPER) as defined iniso/iec [10]. The DEs and DFs of the CAM in AutoNet2030 are described in Appendix

50 2.5 Cooperative EGNSS Message Service Service Introduction The aim of Cooperative EGNSS Messaging Service is to reliably deliver RTK correction data for enhanced GNSS positioning, through a scalable broadcast-based approach. The following figure illustrates the concept and functional components of the cooperative RTK correction system. Both the Broadcaster and Receiver entities may be implemented within the ITS-G5 communications unit. of components: Figure 9 RTK - GeoNet broadcaster architecture Remote NTRIP server: Server providing NTRIP protocol based RTK correction from a ground station, utilized with registered account. Local NTRIP server: A ground station implemented within a Road-Side Unit,serving NTRIP protocol based RTK correction Internet: Public Internet connection. Broadcaster: This entity continuously receives the RTK correction data from the NTRIP server and broadcasts it over the GeoNetworking layer. GeoNet layer: GeoNetworking implementation. Receiver(s): RTK correction receiver application. HW GPS: Hardware GPS with RAW data access support. RTKLIB corrections: Software application calculating theposition correction. Corrected GPS: Virtual GPS device with corrected position values Functional A Broadcaster module becomes activated when the cooperative vehicle is a GCA broadcaster (see Section2.7). The active Broadcaster modules are either: Road-Side Units with Local NTRIP Server implementation, or

51 Vehicles connected to the Remote NTRIP server via cellular (UMTS/LTE) connection, and periodically receiving packets from the NTRIP server. Packets containing NTRIP data are distributed via GCA distribution mechanism as specified in see Section2.7 without any payload modification. The Receiver module is active in every cooperative vehicle ITS-S. The Receiver module has two functions: 1. Listen and receive all incoming GeoBroadcast packages and parse into NTRIP messages. 2. Listen on a local port and simulate NTRIP anntripserver. Receiver main workflow may be implemented as follows: 1. Initialize and wait for GCA-distributed packets carrying NTRIP information. 2. Initialize as IPv4 socket-server on local NTRIP port and wait for local connections. 3. When a connection request is received on local NTRIP port, server forks a new child process. 4. New child process simulates NTRIP commands ( AUTH, START ). 5. New child process prints received NTRIP data (incoming messages) into local client. 6. New child process closes after socket has been terminated Interface Specification The transaction described in this section utilizes the GCA Broadcasting service, as specified in Section Protocol Operations TheBroadcaster and Receiver modules work in simple broadcast/receive mode. The GeoBroadcast distribution mechanism of the GeoNetworking layer provides the reliability of the periodic broadcast distributions, which are initiated by the Broadcaster module. In case a Receiver module does not receive some EGNSS data broadcast, it simply waits for the next broadcast; it is not critical to receive each broadcast. The following paragraph details the utilization of received NTRIP data for the implementation of the GPS/RTK correction.the correction processing module opens a connection to the virtual NTRIP server through a TCP connection on the localhost. The server uses a standard TCP/IP connection and the information exchanged is in plain text. The GPS/RTK correction module must carry out the following operations: Receive and Decode the raw GPS measurement data from the hardware device, Retrieve the NTRIP message, decompress it, and use RTK library tocalculate the corrections from the raw GPS data and correction parameters, Reformat the result in NMEA standard and transfer it to the /dev/gps software device and to the TCP socket serving this data for remote queries Message Format Specification NTRIP data packets are formatted as specified in [12]. 43

52 2.6 Cooperative Sensing Service Service Introduction The Cooperative Sensing Service (CSS) is a facilities-layer component for sharing sensed data with neighbouring cooperative ITS Stations. The scope of this specification is limited to the data sharing of moving objects like vehicles, pedestrians and cyclists. Sharing of (semi-) static data such as a road topology is left for future specification of the CSS component. However, the current specification facilitates the extension of future specifications while keeping backwards compatibility. The shared moving object data includes, among others, the position, speed, heading of the detect objects in addition to their respective confidence values. These data may be measured using on-board sensors (e.g. radar, Lidar, (stereo) camera, etc.) or indirectly, by means of car-2-any (C2X) communication Functional Hiba! A hivatkozási forrás nem található. shows a UML Component Diagram of the CSS component and its interfaces to other facilities layer components. The CSS component is composed of the following sub- components: Encoding:encoding of Cooperative Sensing Messages (CSM) according to the format described in Section Decoding:decoding of CSMs according to the format description in Section Protocol Operations: implements the sender and receiver protocol operations of an ITS-S. This includes: o Activation and termination of CSM sender protocol operations. o Request the encoding of detected objects retrieved from the LDM. o Verification the received CSM by comparing the message content with the permissions of the sending ITS-S. Note: this functionality is out-of-scope of the current document. Figure 10 UML Component Diagram of the Cooperative Sensing Service (CSS)

53 The interfaces of the CSS component are described in the next section Interface Specification Interface with the Local Dynamic Map The CSS component interacts with the Local Dynamic Map (LDM) through interface LDM to obtain sensed moving object data. In addition, the CSS component also provides object data as received in CSMs to the LDM through interface LDM. The specification of interface LDM is out of scope of the current document Interface with the Basic Transport Protocol The CSS component interacts with the Basic Transport Protocol (BTP) through interface BTP.DATA for the transmission and reception of CSMs. The specification of this interface is out-of-scope of the current document. The BTP and its interfaces are specified in ETSI EN [8] Protocol Operations This section describes the basic protocol operations of the CSS component. These protocol operations do not differentiate between detections, for example based on the relative speed of a detected object. Future extensions of these operations may differentiate between object detections by applying a transmission frequency proportional to the relative speed and distance of the detected object. The following operations shall be executed on start-up of the CSS component: 1. Schedule a timer t_timeout with timeout value of 1000ms. The following operations shall be executed on shut down of the CSS component: 1. Stop timer t_timeout The following operations shall be executed when time t_timeout times out: 1. Retrieve the parameters of detected objects which are detected since the last timeout of timer t_timeout from the LDM by using the interface LDM. 2. Encode the parameters of detected object as a CSM according the specification in Section a. If the encoding fails (e.g. because the mandatory data is not available), go to step Request the BTP/GeoNetworking-stack for the transmission of a SHB using primitive BTP.DATA.request as specified in Table 26 Minimum set of PCI passed from the CSS to the BTP/GN-stack for a CSM transmission requesttable 26Hiba! A hivatkozási forrás nem található.. 4. Restart timer t_timeout with a timeout of 1000ms. Table 26 Minimum set of PCI passed from the CSS to the BTP/GN-stack for a CSM transmission request Parameter Data Requirement Optionality BTP type BTP header type B Mandatory 45

54 Destination port 3001 Mandatory Destination port info Optional; Applicable if additional information for the destination port needs to be provided. GN Packet transport type GN transport type SHB Mandatory GN Communication profile ITS-G5 Mandatory GN Maximum packet lifetime 1 second Mandatory GN Traffic class TC ID 6 (see Section 9), SCF and channel offload disabled Mandatory ITS-G5 Channel Type G5-SCH6 Mandatory Length The length in bytes of the CSM message Mandatory Data The CSM message encoded according the ASN.1 UPER encoding rules as specified in ISO/IEC [10]. Mandatory Message Format Specification The CSM is composed of an ITS PDU header and a CSM body, including a series of data elements (DE) and Data Frames (DF) that contains the attributes of detected moving objects. The ITS PDU header is a common header used by multiple ETSI facility-layer messages like the Cooperative Awareness Message (CAM) and Decentralized Environmental Notification Message (DENM). The ITS PDU header contains a message identifier, protocol version and ITS-S pseudonym of the ITS-S originating the CSM. The CSM message body consists of a DEs and DFs describing the attributes of detected, external objects such as their type, position and speed. Such objects may be ITS stations or other moving objects without any C-ITS technologies. The CSM format makes use of the common data dictionary as defined inetsi TS [9].The message format is represented in ASN.1 and specified in Appendix5.5. The CSM shall be encoded using the Unaligned Packed Encoding Rules (UPER) as defined iniso/iec [10].

55 2.7 GCA Information Sharing Service Introduction This section describes the data distribution within a global cooperative area (GCA). GCA Communication Service is a wide-area broadcast service, which may be utilized by multiple applications requiring wide-area data distribution. The mechanism specified in this section is an improved and simplified revision of the Reliable Broadcast Distribution service specified in the D3.2 deliverable of Mobility2.0 project[13]. There are two aspects to GCA communication: Reporting data to the GCA Application Server. This functionality is performed by any entity which generates GCA-relevant information. Retrieving data from the GCA Server. This can be done either through direct download or through GCAbroadcasting: For some applications, a vehicle may directly connect to the geographically relevant GCA server (using UMTS/LTE connection), and retrieve application-specific data. Some applications may be based on broadcasting data from GCA Server to the cooperative vehicles within a GCA. This functionality is performed by cooperative vehicles or roadside units (RSUs) operating in GCA Broadcaster mode. The above services are application specific, i.e. a vehicle may be in GCA Broadcaster mode for a certain application, while not being in GCA Broadcaster mode for some other application Functional Reporting data to the GCA Server When a cooperative vehicle or infrastructure entity generates GCA-relevant information like a speed advice, first it must find the corresponding application server, which shall be serving this information for distribution within the GCA. This application server may be either a global or a local one corresponding to the region in which the vehicle is driving. The mechanism for handling such roaming issues is a geographically scoped extended-dns (edns) mechanism pointing to the local application server, to which the application content is reported. edns servers are extended with the capability to resolve geographic areas or geographiclocations into IPv6 addresses of the GCA server; an extended version of DNS as specified in IETF RFC 1035[14]is used for this purpose. The extensions make use of a type of resource record that has been specified in IETF RFC 1876[15]. This resource record, namely the LOC record, specifies the location associated with a certain name. The extended version of DNS extends the DNS server with capabilities to interpret a part of a domain name (i.e. a sub-domain) as an area within a domain. Upon receiving a query with such a specified area, the extended DNS server should return resource records for all names for which the area specified in a LOC record overlaps with the area specified in the query, and are also sub-domains of the domain specified in the query. The structure of DNS LOC recordis described in IETF RFC 1876[15]: <owner><ttl><class> LOC ( d1 [m1 [s1]] "N" "S" d2 [m2 [s2]] "E" "W" alt["m"] [siz["m"] [hp["m"] [vp["m"]]]] ) 47

56 where d1 is the latitude in degrees from 0 to 90; d2 is the longitude in degrees from 0 to 180; m1 and m2 are minutes from 0 to 59; s1 and s2 are seconds from 0 to ; alt is the altitude in meters from to and siz, hp, vp are respectively the GCA area radius, horizontal precision, and vertical precision expressed in meters from 0 to If omitted, minutes and seconds default to zero; size defaults to 1 m; horizontal precision defaults to m and vertical precision defaults to 10 m. The ednsqueries, as passed on via the local resolver and intermediate DNS servers to the edns server, will be formatted similarly to a name in a regular DNS query. The name field in the query will have the following format: ( dlat [mlat [slat [mslat]]] N S dlon [mlon[slon [ mslon]]] E W alt[ m ] size[ m ] ).domain Here, dlat, mlat, slat and mslat specify the latitude of the querying vehicle s position in degree, minute, second, and millisecond, North ( N ) or South ( S ) respectively. Similarly, dlon, mlon, slon and mslon specify the longitude of the centre of the destination area in degree, minute, second, and millisecond East ( E ) or West ( W ) respectively. Furthermore, alt is the altitude in meters. The domain specifies the domain to search in. If the query relates not only to the location of the vehicle but also to an extended area around it, the size parameter defines the radius of the destination area of interest in meters.example: a platoon leader may periodically report to the GCA server the information about the platoon in that case the size parameter may correspond with the GCA area size, and consequently the edns query returns multiple server addresses being in overlap within the area spanned by the indicated size parameter. In this way border transition issues are managed, as multiple neighbouring servers may contain the same locally relevant information. When a GCA broadcaster makes the query to distribute this information, the size parameter is not relevant, as it only needs to identify the application server corresponding to its current position. After obtaining the IPv6 address(es) of the local application server using edns, the reporting entity establishes a TCP connection with the GCA server and reports its data. The list application specific TCP port numbers for these GCA reports is maintained by the corresponding applications. The selection and operation of GCA broadcasters is described in the next subsections Direct data retrieval from the GCA Server For directly retrieving GCA information, the cooperative vehicle first needs to find pointers to the data, which it must periodically fetch. The relevant application server may be either a global or a local one corresponding to the region in which the vehicle is driving. The mechanism for handling such roaming issues is a geographically scoped edns mechanism pointing to the local application server, to which the relevant application content has been reported. The query of edns servers is performed according to the procedure described in the previous subsection.once the IP address ofthe GCA server has been resolved, the vehiclemay establish a TCP connection to this server GCA Broadcasting The GCA broadcaster selection mechanism described in this section is a generic mechanism, which can be applied to both real and virtual RSUs. The GCA broadcast data sources - which can be either a vehicle or a physical RSU - are therefore abbreviated as (v)rsu in this document.

57 Before switching to virtual RSU mode, a Vehicle ITS-Station must verify whether there are already enough other (v)rsus in its vicinity 1. Each ITS-G5 equipped Vehicle ITS-Station in (v)rsu mode periodically (e.g. every 20 seconds) geo-broadcasts within a pre-configured radius its (v)rsu status, in order to inform other ITS-G5 equipped ITS-Stations. If the number of received notifications from distinct (v)rsus within this advertising period is less than a threshold value (e.g., 2 or 3), then switching into a virtual RSU mode is activated and a notification of this new (v)rsu status is geo-broadcasted right away. Each ITS-G5 equipped Vehicle ITS-Station starts its counting period at a random time; this distribution ensures that only the actually needed virtual RSUs turn on. Each virtual RSU status automatically expires after a certain time (e.g., 10 minutes). This procedure of virtual RSU mode control is illustrated infigure 11Hiba! A hivatkozási forrás nem található., where the egostation is the station running the procedure. Figure 11 Decentralized (v)rsu notification procedure The summaries of control parameters for virtual RSU state control are listed below: 1. R vrsu :radius of the area served by a (v)rsu 2. N overlap :threshold number of overlapping distinct (v)rsus 3. T period :time duration between periodic (v)rsu status notifications 4. T lifetime :expiration time of (v)rsu status While the above procedure ensures that only the needed numbers of virtual RSUs are activated in the stationary status, moving virtual RSUs (connected e.g., via UMTS/LTE) can still have fluctuations from their distribution, though being evenly distributed, on average. The above-mentioned numbers of overlapping virtual RSU areas create redundancy with respect to such fluctuations. Once the ITS-G5 equipped ITS-Station becomes a virtual RSU for a certain application, it must establish a TCP connection to the corresponding application server. This broadcasting application needs to find pointers to the data, which it must periodically fetch and distribute. Generally, this data may be location-dependent (i.e. served by different servers in different regions). The mechanism for handling such roaming issues is a geographically scoped extended-dns (edns) mechanism pointing to the local data server, from which the 1 Permanent RSUs are of course in permanent RSU mode, applying the procedures described herein 49

58 required content is downloaded. The query of edns servers is performed according to the procedure described in the previous subsection. Note: Such edns query may not be applicable for the applications where the GCA data source is a global server. Upon receiving any data from the application server, the GCA Broadcaster distributes this data using the Basic Transport Protocol (BTP) / Geo-broadcasts within a defined R vrsu radius. Application-specific destination BTP port number is used for such broadcasting; the receiver side distributes received packets on the basis of thisdestination BTP port number Interface Specification Interface with the Basic Transport Protocol The GCA Broadcaster is interfacing with the BTP for the dissemination of data in a geographical area. The BTP and its interfaces are specified in EN [8]. The GN Packet transport type of the BTP interface shall be set to GeoBroadcast and the GN Destination address shall be a circular destination address with the radius set according to the R vrsu parameter. Each application reserves two application-specific BTP Destination port numbers: GCA Broadcaster port: the data packets are sent to this port number. vrsu notification port: the vrsu advertisement packets are sent over this port Interface with TCP/IP The GCA Broadcaster is interfacing with the TCP/IP stack to communicate with the GCA Application Server Protocol Operations GCA Broadcasting There are three relevant operations in GCA Broadcasting Service: (v)rsu selection, GCA Broadcaster operation, GCA receiver operation. (v)rsu selection procedure, which is always active: 1. Count the number of (v)rsu status notifications received over the (v)rsu notification portduringt period time. Compare received notifications (N) against the threshold(n overlap ) a. If N >= N overlap, repeat step 1. b. If N <N overlap, enable GCA Broadcaster mode, and set lifetime of this mode tot lifetime, and proceed to the following step. 2. Transmit the initial (v)rsu advertisement broadcast to the (v)rsu notification port. Establish the TCP connection to the application-specific port of the GCA server, using edns query if needed to identify the local GCA server. If the edns query returns multiple server addresses (overlap area), the destination server is randomly selected among the returned addresses. 3. SetT period timer, and upon the expiration of this timer transmit(v)rsu advertisement broadcast to the (v)rsu notification port. If T lifetime has not expired yet, repeat step Disable GCA Broadcaster mode, disconnect from the application server, and go back to step 1.

59 GCA Broadcast procedure, which is active when GCA Broadcaster mode is enabled: 1. Wait for packet reception from the TCP-port, which has been established to the GCA server. When a packet is received, proceed to step Transmit the received packet over the GCA Broadcaster port. Also, pass this received packet for the GCA receiver operation for processing. Repeat from step 1. GCA Receiver procedure, which is always active: 1. Wait for packet reception from the GCA Broadcaster port or from thegca Broadcast module, proceed to step 2 upon packetreception. 2. Compare the content of data packet received in step 1 against preceding data packets in the application-specific cache: a. If the same packet is already found in the cache, then discard it. b. If the received data packet is a new one, store it into the cache and pass it for the corresponding application processing. 3. Repeat from step Message Format Specification Packet format specification is not applicable for GCA Communication Service. Data packets are transparently forwarded for GCA Broadcasting. In case of vrsu notification messages, the only relevant information is the message counting, i.e. the message content may be empty. 51

60 2.8 Cooperative Speed Advising Service Service Introduction The aim of Cooperative Speed Advising Service (CSAS) is to reliably deliver the advised driving speed for a given road segment, through a scalable broadcast-based approach. The CSAS consists of two components: A Speed advising server: locally responsible server for providing driving speed recommendations. An ITS Station: a cooperative vehicle, which periodically polls speed advising from the server, and initiates the broadcasting of speed advises, as specified in Section2.7. In addition each ITS station reports events when it is unable to maintain the advised speed, e.g. due to traffic congestion Functional The server maintains a 'group speed map' database on the basis of semi-permanent data such as speed limits, roadwork restrictions, weather restrictions, etc. This data is modified by reported driving speed deviations; i.e. if a convoy member reports that it can only achieve 60 km/h group speed instead of the 100 km/h value in the speed map, and then the speed map is adjusted accordingly to 60 km/h. These dynamic adjustments have a lifetime and a geographic gradient (in the upstream direction). As the lifetime goes to zero, the speed value continuously changes back to the semi-permanent data through linear or exponential decay. The goal of the speed advising server application is to properly adjust the parameters for the lifetime and geographic gradient size Interface Specification The transaction described in this section utilizes the GCA Broadcasting service, as specified in Section2.7. Speed reports are sent directly from a cooperative vehicle to the speed advising server when needed, using UMTS/LTE communications; the ASN.1 encoded speed reports are sent directly over TCP transport Protocol Operations The Broadcaster and Receiver ITS Stations work in simple broadcast/receive mode. The GeoBroadcast distribution mechanism of the GeoNetworking layer provides the reliability of the periodic broadcast distributions, which are initiated by the Broadcaster vehicles. In case a Receiver module does not receive some speed advising broadcast, it simply waits for the next broadcast; it is not critical to receive each broadcast. The Broadcaster vehicles poll cooperative speed advises from the server in 10 second intervals, giving reasonable resolution for speed updates. The polls are periodically initiated via Speed Request Messages, and the received speed advises and broadcasted via Speed Advise Messages. When receiving a Speed Advise broadcast, the receiving vehicle verifies whether it is within the indicated relevant polygon. If this relevance filter is passed, the message is processed and the vehicle adjusts its individual or group speed as needed. The sending of speed reports is event triggered by deviations; such reports are sent via Speed Report messages.

61 2.8.5 Message Format Specification The Cooperative Speed Advising Message (CSAM) is formatted in ASN.1 as specified in Appendix 5.6 and shall be encoded using the Unaligned Packed Encoding Rules (UPER) as specified iniso/iec [10]. The CSAM is composed of an ITS PDU header and a CSAM payload. The ITS PDU header of the CSAM is a common header used by multiple ETSI facilities-layer message like the Cooperative Awareness Message (CAM) and the Decentralized Environmental Notification Message (DENM). The ITS PDU header consists of a message identifier, protocol version and an ITS-S temporal identifier of the ITS-S originating the CSAM. The CSAM payload consists of a speed request message, a speed advice message or a speed report message. A detailed description of the DEs and DFs of a CSAM can be found in Appendix

62 2.9 Local Dynamic Map The Local Dynamic Map (LDM) is a facilities-layer component of the ITS reference architecture as defined in ETSI EN [5]. The LDM is specified in ETSI EN [16]and defined there as a key facility supporting various ITS applications by maintaining the information on objects influencing or being part of ITS. The LDM in [5] supports the following Basic Set of Applications (BSA) as outline in TS ETSI TS [17]: Driving assistance - Cooperative awareness Driving assistance - Road Hazard Signalling Speed management Cooperative navigation Location based services Community services ITS station life cycle management In order to support the cooperative automated driving application, AutoNet2030 recognizes the importance of the LDM and foresees the need to extend the LDM as defined in [5] with additional functionalities. However, AutoNet2030 has not identified additional needs for standardization of the LDM as specified in [5] in order to support cooperative autonomous driving applications. For this reason, AutoNet2030 will not specify interoperability requirements for the LDM in this document.

63 2.10 Reliable Basic Transport Protocol Service Introduction This chapter specifies the Reliablee Basic Transport Protocol (RBTP) whichprovides a reliable end-to-end, connection-less transfer of data on top of GeoUnicasting. The reliability is achieved by a combination of packet retransmissions and acknowledgements. The RBTP is a lightweight protocol for the reliable transmission of datagrams. RBTP protocol adds between 3 and 9 bytes to the packet length andunlike the well-known transmission control protocol (TCP), RBTP does not provide advanced features like flow control, congestion control or re-ordering or packets Functional The UML component diagram of RBTP is illustrated in Figure 12. The RBTP component can be sub-divided into three sub-components: 1. Encoding: encodes the RBTP packets to be transmitted at the source node according to the protocol operations in Section and the packet format description in Section Decoding: decodes received RBTP packets at the destination node according to the protocol operations in Section and the packet format description in Section Retransmission:retransmits unacknowledged RBTP packets at the source according to the protocol operations in Section InterfaceSpecification Figure 12UML Component Diagram of thereliable Basic Transport Protocol Interface with Facilities The RBTP component exposes the interface RBTP.DATA to facilities for reliable end-to-end connection-less transfer of data. In addition, this interface provides the service to facilities to be informed of the data received by the RBTP component. This interface is described in detail in Appendix6.3 as a Service Access Point (SAP) and its corresponding primitives. 55

64 Interface with GeoNetworking The RBTP component interacts with GeoNetworkingfor the transmission and reception of packets by using the interface GN-DATA of GeoNetworking. The primitives and their parameter which shall be used by the RBTP component to interact with GeoNetworking are described in Section Protocol Operations Source operations On the reception of a RBTP.DATA.request primitive, the source shall execute the following operations: 1. If the timeout value is outside the range of [timeout_min (1), timeout_max (5000)], the RBTP shall respond with anrbtp.data.confirmandconfirmcode set to NotAccepted_InvalidParameters. The following steps shall be omitted. 2. Create an RBTP-PDU by addingin front of the RBTP-SDU the RBTP Header (clause ) and the RBTP Request Header (clause ). The values of the RBTP Header and RBTP Request Header shall be set according to Table 27. a. Increase the sequence number with one and wrap it around the maximum value i.e. last_sequence_number = (last_sequence_number + 1) mod 2^16 b. Set the sequence number of the RBTP Request Header to last_sequence_number. Table 27 RBTP Header and RBTP Request Header settings Field (Header) Next Header (RBTP Header) Sequence Number (RBTP Request Header) Destination Port (RBTP Request Header) Source Port (RBTP Request Header) Value 1 (RBTP Request Header) last_sequence_number RBTP.DATA.request.Destination port RBTP.DATA.request.Source port 3. Create an entry for the valuelast_sequence_number in the source retransmission table containing the RBTP-PDU and GN* parameters of the RBTP.DATA.request primitive. a. If an entry already exists for the valuelast_sequence_number, the RBTP shall respond with anrbtp.data.confirmandconfirmcode set to NotAccepted_UnspecifiedReason. The next steps shall be omitted. 4. Start atimeout timer for the created entry in step 3 with the timeout value of RBTP.DATA.request.Acknowledgment Timeout. 5. Start a retransmission timer for the created entry in step 3 with a timeout value which is smaller than RBTP.DATA.request.Acknowledgement Timeout. The timeout value of the retransmission timer is out of scope of the present specification. 6. Request to GeoNetworking the transmission of a GeoUnicast using primitive GN-DATA.request as specified in ETSI EN [11]. The parameters of the GN-DATA.request shall be set according totable 28.

65 a. If the ResultCode of the returned GN-DATA.confirm is accepted, a primitive RBTP.DATA.confirmshall be returned with ConfirmCode set to Accepted. b. If the ResultCode of the returned GN-DATA.confirm is rejected, a primitive RBTP.DATA.confirm shall be returned with ConfirmCode set to NotAccepted_UnspecifiedReason. Table 28GN-DATA.request parametersettings for a request Field Upper protocol entity Packet transport type Destination Communication profile Maximum packet lifetime Repetition interval Traffic class Length Data Value RBTP GeoUnicast RBTP.DATA.request.GN Destination Address RBTP.DATA.request.GN Communication Profile RBTP.DATA.request.GN Maximum Packet Lifetime RBTP.DATA.request.GN Repetition Interval RBTP.DATA.request.Traffic Class Length in bytes of RBTP-PDU RBTP-PDU On the expiration of a timeout timer, the source shall execute the following operations: 1. The entry in the source retransmission table corresponding to the expired timer is removed from the source retransmission table. 2. The retransmission timer corresponding to the removed entry in step 1 is stopped. 3. Send a primitive RBTP.DATA.response with ResponseCode set to Unacknowledged to the corresponding upper-layer entity. On the expiration of a retransmission timer, the source shall execute the following operations: 1. Lookup the source retransmission table entry corresponding to the retransmission timer. a. If no source retransmission table entry exists, omit further steps. 2. Request to GeoNetworking the transmission of a GeoUnicast using primitive GN-DATA.request as specified in ETSI EN [11]. The parameters of the GN-DATA.request shall be set according totable Restart the expired retransmission timer. The timeout value of the retransmission timer is out of scope of the present specification. 57

66 Table 29GN-Data.request parameter settings for a retransmission Field Upper protocol entity Packet transport type Destination Communication profile Maximum packet lifetime Repetition interval Traffic class Length Data Value RBTP GeoUnicast Source retransmission table entry. GN Destination Address Source retransmission table entry.gn Communication Profile Source retransmission table entry.gn Maximum Packet Lifetime Source retransmission table entry.gn Repetition Interval Source retransmission table entry.traffic Class Length in bytes of RBTP-PDU in source retransmission table entry RBTP-PDU in source retransmission table entry Destination Operations On the reception of a RBTP-PDU as part of the GN-DATA.indication data field, the destination shall execute the following operations: 1. If the field Upper protocol entity of the primitive GN-DATA.indication is not set to RBTP, drop the PDU and omit next steps. 2. If the field Packet transport type of the primitive GN-DATA.indication is not set to GeoUnicast, drop the PDU and omit next steps. 3. Check the Next Header-field in the RBTP header of the RBTP-PDU. a. If the Next Header value equals to 1 (RBTP Request Header), continue with step 4. b. If the Next Header value equals to 2 (RBTP Acknowledgement Header), continue with step 9. c. Else, drop the RBTP-PDU and omit next steps. 4. Lookup in the destination table the entry corresponding to the GN Address of the GN- DATA.indication.Source Position Vector. a. If no entry exists, create a destination table entry for the GN Address of the GN- DATA.indication.Source Position Vector. Set the update_timeof the entry to the current time. b. If an entry exists for which the difference between the current time and itsupdate_time is larger than 2*timeout_max, reset the entry. 5. Execute the duplicate packet detection (Chapter 8); if the packet is a duplicate or outdated, discard the PDU and omit next steps. 6. Create an RBTP-PDU consisting of the RBTP Header (clause ) followed by the RBTP Acknowledgement Header (clause ). The payload of this RBTP-PDU is empty. The values of the RBTP Header and RBTP Acknowledgement Header shall be set according totable 30.

67 Table 30 RBTP-PDU field settings Field Next Header (RBTP Header) Sequence Number (RBTP Acknowledgement Header) Values 2 (RBTP Acknowledgement Header) Received RBTP-PDU.SequenceNumber 7. Request to GeoNetworking the transmission using primitive GN-DATA.request as specified in ETSI EN [11]. The parameters of the GN-DATA.request shall be set according totable 31. Table 31 GN-DATA.request parameter settings for RBTP Acknowledgement Field Upper protocol entity Packet transport type Destination Traffic class Length Data Value RBTP GeoUnicast GN-DATA.indication.GN Destination Address GN-DATA.indication.Traffic Class Length in bytes of created RBTP-PDU Created RBTP-PDU 8. If the ResultCode of the returned GN-DATA.confirm is rejected, a primitive RBTP.DATA.confirm shall be returned with ConfirmCode set to NotAccepted_UnspecifiedReason.Send a primitive RBTP.DATA.indication to the ITS Facility layer entity that is registered for the Source Port of the received RBTP-PDU. The fields of the RBTP.DATA.indication shall be set as specified in Table 32. Omit further steps. Table 32RBTP.DATA.indication parameters Field Source port Destination port GN Packet transport type GN Destination GN Source position vector Value Received RBTP-PDU.Source Port Received RBTP-PDU.Destination Port GN-DATA.indication.GN Packet transport type GN-DATA.indication.GN Destination GN-DATA.indication.GN Source position vector 59

68 GN Security Report GN Certificate id GN Permissions GN Traffic class GN Remainingpacket lifetime Length Data GN-DATA.indication.GN Security report GN-DATA.indication.GN Certificate id GN-DATA.indication.GN Permissions GN-DATA.indication.GN Traffic class GN-DATA.indication.GN Remainingpacket lifetime Length in bytes of the received RBTP-SDU Received RBTP-SDU 9. Lookup in the source retransmission table the entry corresponding to thevalue SequenceNumber of the received RBTP-PDU. a. If no source retransmission table entry is found, drop therbtp-pdu and omit further steps b. Else, i. remove theentry from the source retransmission table and stop corresponding retransmission and timeout timers ii. Send a primitive RBTP.DATA.response with ResponseCode set to Acknowledged to the upper-layer entity corresponding to the source retransmission table entry Packet Format Specification Our extension of BTP defines a new BTP protocol header:rbtp for acknowledged packet transport. The protocol RBTPis distinguished by the Next Header field in the GeoNetworking header with the value RBTPHeader The RBTP header carries the Next Header field as is illustrated in Figure 13 and described in Table 33. The Next Headeridentifies the next header of the packet. This header can either be a RBTPRequest or RBTPAcknowledgement-header. Table 33 of the RBTP Header fields Figure 13Reliable Basic TransportProtocol Header Field Octet Position Type Next Header 0 8 bit unsigned integer The next header. The next header value 1 is used for a RBTP Request Header; value 2 is used for a RBTP Acknowledgement Header.

69 RBTP- Request Header The structure of the RBTP Request-header is illustrated in Figure 14 and described in Table 34. Table 34 of the RBTP Request Header fields Figure 14Reliable Basic Transport Protocol Request Header Field Octet Position Type Sequence Number 0 16 bit unsigned integer Sequence number identifying a content (re)transmission. This field is used to identify duplicate packets and is used to set the corresponding field in the RBTP Acknowledgement header. Destination Port 1 16 bit unsigned integer Source Port 2 16 bit unsigned integer Reserved 3 16 bit unsigned integer The field identifies the BTP destination port at the receiving ITS station. This value shall not be set to 0. This field identifies the BTP source port at the sending ITS station. This value shall bet set to 0 for non-interactive packet transport. This value shall be set to a value not equal to 0 for interactive packet transport. Reserved field used for padding. This value shall be set to RBTP Acknowledgement Header The structure of the RBTP Acknowledgement-header is illustrated in Figure 15 and described in Table 35. Figure 15RBTP Acknowledgement Header Table 35 of the RBTP Acknowledgement Header fields Field Octet Position Type Sequence Number 0 16 bit unsigned integer Sequence number identifying a RBTP request 61

70 2.11 Extended GeoNetworking Service Introduction The Extended GeoNetworking (EGN) module provides the functionality to route packets among cooperative entities within AutoNet. GeoNetworking is based on geographical routing, which makes use of the geographical positions of the cooperative entities to find forwarding paths from source to destination. Several forwarding algorithms (both unicast and broadcast) have been defined in the GeoNetworking standard ETSI EN [11]. However, these algorithms are designed for safety-oriented vehicular communications, generally considering the single-hop broadcasting of information and the multi-hop distribution of information within a geographical area. They do not consider the specific requirements of cooperative autonomous driving systems. For instance, cooperative autonomous vehicles driving in a platoon or convoy form a closed group of vehicles which have a very short distance among them, thereby requiring extremely low-delay and high-reliability communications to ensure their safe coordinated manoeuvring. The proposed extensions in EGN to the standardized GeoNetworking routing protocols aim to enhance their performance in order to satisfy the stringent communication requirements of cooperative autonomous driving in AutoNet2030. In particular, we introduce two new forwarding algorithms: Greedy Broadcast Forwarding and Greedy Multicast Forwarding, designed to allow fast and reliable information dissemination within vehicle groups, such as platoons and convoys. These algorithms are described in Sections and , respectively Functional The EGN module belongs to the networking & transport layer within the communication stack of the Autonet2030 system architecture. The purpose of this component is to provide routing functionality for packets to be transmitted among cooperative entities within the AutoNet. With this goal, it creates a link between the ITS-G5 module and the higher layer entity (e.g. the Basic Transport Protocol). Whenever the higher layer entity wants to send a packet, it passes it to EGN, which calculates an appropriate next hop and forwards it to the ITS-G5 module. The other way around, when ITS-G5 receives a packet, it passes it to EGN, which decides if the packet must be locally delivered and/or forwarded to other entities. In the first case, EGN passes the packet to the higher layer entity; in the second case, EGN executes the forwarding algorithm and passes the packet back to the ITS-G5 module. Figure 16 shows the UML Component Diagram of EGN and interfaces to other modules (detailed in Section2.11.3).

71 Figure 16UML Component diagram of Extended GeoNetworking The EGN module is composed of the following sub-functions: Packet encoding: encodes packets according to the packet format specified in Section Packet decoding: decodes received packets according to the format specified in Section Transmit Packet: implements the procedure to handle a packet to be transmitted, including: o Obtain an appropriate next hop for the packet using the Forwarding decision module; o Set or update relevant parameters in the packet (e.g. remaining number of hops, lifetime, etc.). Receive Packet: implements the procedure to handle a received packet, including: o Checking whether the packet needs to be locally delivered and/or forwarded to other entities; o Pass the packet to the higher layer entity and/or to the Transmit Packet sub-function for further processing. Forwarding decision: finds the next hop to forward the packet towards the destination. The chosen next hop will depend on the node position, the destination position, the node neighbours and the transport type (e.g., unicast, geographically-scoped broadcast, etc.) This module includes the proposed GeoNetworking extensionss to implement the Greedy Broadcast Forwarding and Greedy Multicast Forwarding algorithms Interface Specification Interfaces with the Basic Transport Protocol The higher layer entity (typically the Basic Transport Protocol) provides EGN with packets to be transmitted and processes the packets locally delivered by EGN. The minimum set of protocol control information (PCI) exchanged between the EGN and the upper layer entity for the transmission and reception of a packet are specified in Table 36 andtable 37 respectively. 63

72 The main novelty with respect to standard GeoNetworking is the addition of two new packet transport types, namely, Greedy Broadcast Forwarding and Greedy Multicast Forwarding, which indicate the EGN module to use the Greedy Broadcast Forwarding and Greedy Multicast Forwarding algorithms, respectively, for the multi-hop forwarding of the packet. Table 36 Minimum set of PCI passed from the upper layer entity to EGN for a packet transmission Parameter Data Requirement Optionality Upper protocol entity Higher layer entity (e.g. BTP) Mandatory Packet transport type Destination GeoUnicast, Single Hop Broadcast, Topologically-Scoped Broadcast, Geographically-Scoped Broadcast, Geographically-Scoped Anycast, Greedy Broadcast or Greedy Multicast Specifies the destination GeoNetworking address for GeoUnicast or the geographical area for GeoBroadcast/GeoAnycast. Mandatory Mandatory Communication profile Determines the lower layer protocol entity (e.g. ITS-G5) Mandatory Maximum packet lifetime Repetition interval Traffic class The maximum tolerable time a GeoNetworking packet can be buffered until it reaches its destination [18] The duration between two consecutive transmissions of the same GeoNetworking packet [ms] Optional Optional Traffic Class as specified in ETSI EN [11] and Appendix9. Mandatory Length The length in bytes of the upper layerpayload Mandatory Data Upperlayer payload Mandatory Table 37 Minimum set of PCI passed from EGN to the upper layer entity for a packet reception Parameter Data Requirement Optionality Upper protocol entity Higher layer entity (e.g. BTP) Mandatory Packet transport type Destination Source position vector GeoUnicast, Single Hop Broadcast, Topologically-Scoped Broadcast, Geographically-Scoped Broadcast, Geographically-Scoped Anycast, Greedy Broadcast or Greedy Multicast Specifies the destination GeoNetworking address for GeoUnicast or the geographical area for GeoBroadcast/GeoAnycast. The geographical position for the source of the received GeoNetworking packet. Mandatory Optional Mandatory Communication profile Determines the LL protocol entity Mandatory Remaining packet lifetime The remaining lifetime of the received packet in milliseconds Optional Traffic class Traffic Class as specified in ETSI EN [11] and Appendix9. Mandatory

73 Length The length in bytes of the data packet Mandatory Data Higher layer data packet Mandatory Interfaces with ITS-G5 EGN relies on the services of the ITS-G5 module for the transmission/reception of packets to/from the physical channel. The minimum set of protocol control information (PCI) exchanged between the EGN and the ITS-G5 SAP for the transmission and reception of a packet are specified in Table 38andTable 39, respectively. These interfaces are consistent with the service primitives IN-UNITDATA.request and IN-UNITDATA.indication defined in the ETSI ITS-G5 standards ETSI EN [18]. Table 38 Minimum set of PCI passed from the EGN to the ITS-G5 for a packet transmission Parameter Data Requirement Optionality Command reference Cyclic reference number, incremented after each transmission. Mandatory Upper protocol entity GeoNetworking Optional Source address MAC address of the source of the packet. Mandatory Destination address Transmit parameters DCC profile ID Data MAC address of the identified next hop to which the packet must be forwarded. Service class, use RTS/CTS, transmit power, modulation and coding scheme. Defines the behavior of the message in the access layer (e.g. channel number and access category). Payload consisting of the GeoNetworking packet including GeoNetworking headers. Table 39 Minimum set of PCI passed from the ITS-G5 to the EGN for a packet reception Mandatory Optional Mandatory Mandatory Parameter Data Requirement Optionality Upper protocol entity GeoNetworking Mandatory Source address MAC address of the source of the packet. Mandatory Destination MAC address of the destination of the packet. Optional Receive parameters Channel number, RSSI, modulation and coding scheme. Optional Data GeoNetworking packet including GeoNetworking headers Mandatory 65

74 Protocol Operations The high-level procedure followed by the EGN module to transmit a packet may be described as follows 2 : 1. The packet is received by the Transmit packet module from the upper layer entity through the interface GN-DATA. 2. The Transmit packet module decides the appropriate routing protocol to be used, depending on the packet type and the ego-vehicle state. 3. The packet is sent to the Forwarding decision module in order to find an appropriate next hop towards the destination. 4. Once a next hop is obtained, the packet is encoded with the GeoNetworking headers, which contain information about the source, destination and next hop GeoNetworking addresses. This process is carried by the Packet encoding module. 5. The Transmit packet module passes the GeoNetworking packet to the ITS-G5 module by means of the ITSG5-DATA interface. The other way around, when a packet is received, the procedure is the following: 1. The packet is received by the Receive packet module from the ITS-G5 module through the interface ITS-G5DATA. 2. The Packet decoding module extracts the GeoNetworking headers from the packet, which contain information about the source, destination and next hop GeoNetworking addresses. 3. Based on the packet destination and next hop GeoNetworking addresses, the Receive packet module decides if the packet must be locally delivered and/or forwarded to other cooperative entities: a. In the first case, the Receive packet module passes the packet to the upper layer entity specified in the GeoNetworking header via the interface GN-DATA for further processing. b. In the second case, the packet is passed to the Forwarding decision module in order to calculate an appropriate next hop towards the destination. Then, the packet is passed on to the Transmit packet module, which passes it back to the ITS-G5 module through the interface ITSG5-DATA. Details about the standardized forwarding algorithms used by the Forwarding decision module in the can be found in Appendixes D and E of the GeoNetworking ETSI standard ETSI EN [11]. High-level overviews of our proposed Greedy Broadcast Forwarding and Greedy Multicast Forwarding algorithms are described next Greedy Broadcast Forwarding Greedy Broadcast Forwarding (GBF) [19] is a novel forwarding algorithm designed to enable reliable and lowlatency communications in AutoNet. A typical scenario where this algorithm may be used is in information dissemination within vehicle groups, where a group member distributes relevant information among all other group vehicles. Similarly to the GeoNetworking protocol, GBF assumes that all group vehicles know their own 2 A more detailed description of the protocol operations may be found in Section 9 of the GeoNetworking ETSI standard ETSI EN [11].

75 position (e.g., by means of GPS) and have a location table with the ID's and positions of the neighbouring vehicles. The main features of the GBF algorithm can be summarized as follows: 1. The source node selects a next hop by Greedy Forwarding (GF), i.e., the neighbour with the highest forward progress towards the destination, and forwards the packet to this node. The destination is defined as the geographical position at the opposite edge of the geographical area. The selected GF next hop will in turn forward the packet by GF as well. If no next hop is found, the packet is discarded. 2. Other nodes within the communication range which overhear the transmission also process the packet. At the same time, they start a retransmission timer whose value is proportional to their distance to the GF next hop (the exact value will depend on the scenario). This way, in the case that the GF next hop does not receive the packet, other nodes are able to retransmit it. 3. If a node overhears a packet for the second time, it means that the packet has already been retransmitted by another node. Then, the node cancels its retransmission timer and discards the packet. 4. If the retransmission timer expires and no further transmission has been observed, it means that the node is responsible to retransmit the packet. The node calculates its GF next hop and forwards the packet by GF. Using this algorithm, the packets are broadcasted to all nodes within the geographical area with a low delay, since packets are forwarded to the node within communication range with the highest forward progress. Furthermore, vehicles overhearing a packet transmission exploit the information about their position compared to the GF next hop in order to set their retransmission timers to much lower values compared to generic broadcast routing protocols, such as contention-based forwarding, which sets the retransmission timer as a function of the distance to the previous forwarder only. This mechanism allows for very fast retransmissions in case of a collision in the GF transmission, which result in a low end-to-end delay even in unfavourable scenarios. 67

76 Figure 17Message dissemination in a group composed of 7 white vehicles using Greedy Broadcast Forwarding. The red solid lines represent the greedy forwarding transmissions, whereas the red dashed lines show the overhead transmissions. The dashed black lines represent the communication range of the transmitting vehicle. The black vehicle is a non-cooperative vehicle. We illustrate the behaviour of GBF in more detail by considering by considering the example shown in Figure 17 of a group composed of 7 vehicles, where the group leader (L) disseminates a packet to the other 6 group members: First transmission (Figure 17, top): the group leader L sends the packet by GF to vehicle 3, which is the closest node to the destination position within communication range of L. We assume that this transmission is erroneous and vehicle 3 cannot receive the packet. Vehicles 1 and 2 overhear this transmission and start a retransmission timer based on their distance to vehicle 3. Second transmission (Figure 17, middle): the timer of vehicle 2 expires first, since it is the closest vehicle to 3. Therefore, it sends the packet by GF to vehicle 5. Vehicles 3 and 4 overhear the packet and they start a timer based on their distance to vehicle 5. Vehicle 1 overhears the packet for the second time, so it cancels its retransmission timer and drops the packet. L also overhears the packet, but it does not start a timer since it had already received the packet before. Third transmission (Figure 17, bottom): vehicle 5 correctly receives the packet from vehicle 2 and forwards it to vehicle 6. Vehicle 6 drops the packet since it has no neighbour closer to the destination position. Vehicles 3 and 4 overhear the packet for the second time, so they cancel their retransmission timer and drop the packet as well. Vehicle 2 also overhears the packet, but it does not start a timer since it had already received the packet before. In this way, the group leader is able to disseminate the packet among all the group members with only three retransmissions, which leads to a low routing overhead. Furthermore, the reliability of the transmissions is increased since most vehicles receive the packet more than once, thereby minimizing the probability of an erroneous reception. Finally, the end-to-end delay can be reduced by selecting lower values for the

77 retransmission timers compared to the currently standardized broadcast routing protocols (e.g. Contentionbased Forwarding). In summary, the Smart Broadcast Forwarding protocol allows the dissemination of information within vehicle groups (such as platoons) with a high reliability and a low end-to-end delay. More details about the performance improvement of GBF with respect to the broadcast forwarding protocols defined in the ETSI GeoNetworking standard are found in our recent publication [19] Greedy Multicast Forwarding The broadcast forwarding protocols in GeoNetworking are designed to distribute a packet among all nodes in a geographical area. However, it may not be possible to define a geographical area covering all the members in a vehicle group (e.g., when a platoon is overtaking a non-cooperative vehicle). In such a scenario, a multicast forwarding protocol is needed to distribute a packet only among the group members. Greedy Multicast Forwarding (GMF) is a variation of GBF described in Section , which allows for a multicast distribution of packets within a vehicle group. The main differences of GMF with respect to GBF are: Every vehicle belonging to a vehicle group broadcasts its group membership information periodically to its immediate neighbours, by including it in the CAMs (see Table 24). Whenever a vehicle is added to the location table, information about its group membership (if any) is stored. When a packet is to be forwarded by greedy forwarding, only those neighbours being members of the vehicle group are considered as potential next hops. As opposed to the GeoBroadcast forwarding algorithms, no geographical area is defined. Instead, vehicles which do not belong to the same vehicle group as the packet source do not forward the packet. In short, GMF restricts the packet forwarders to those vehicles belonging to the same group, avoiding retransmissions by other vehicles. The main advantage of such a multicast forwarding algorithm is that it only needs to be implemented in the vehicles belonging to the vehicle group, which allows a high flexibility to implement specific forwarding algorithms adapted to the needs of diverse vehicle groups. More details about GMF and its performance evaluation are found in our recent publication [19] Packet Format Specification The specification of the packet format follows the structure specified in Section 8 of the GeoNetworking ETSI standard [18], with the addition of a new packet transport type, namely, platoon broadcast, to the existing packet types defined in the standard. 69

78 3 Conclusion This deliverable presents one of the major results of the work in WP3 System design of the AutoNet2030 project: the specification of new and enhancements of existing cooperative ITS communication protocols for the support of automated driving based on a decentralized decision making strategy. This deliverable first presents the high-level use-cases which are targeted by the AutoNet2030 project and which have been identified during the first phase of the project, being Convoy Driving, Cooperative Lane Change and Priority based Autonomous Intersection Management. These use-cases have driven the design of the AutoNet2030 functional architecture which consists of four major building blocks: Manoeuvring & Control, Human Machine Interface, Perception and Communication. The functional architecture of the communication block has been presented in this deliverable and follows the standardized C-ITS reference architecture by dividing the (communication) system in 4 horizontal and 2 vertical layers. Components of each layer have been presented and a detailed protocol specification (i.e. functional description, interface specification, protocol operations, message format, etc.) was presented for the following components. Cooperative Lane Change Service Convoy Control Communication Service Cooperative Intersection Control Service Cooperative EGNSS Message Service Cooperative Sensing Service GCA Information Sharing Cooperative Speed Advising Service Reliable Basic Transport Protocol Extended Cooperative Awareness Basic Service Extended GeoNetworking The next step of the AutoNet2030 project is to implement these use-cases and protocols in a cooperative automated driving prototype. This prototype will be fully integrated in test vehicles and will be used to demonstrate and validate the system on a test track. The validation results together with the specification in this document will be used as input for ongoing standardization activities of C-ITS communication protocols.

79 4 References [1] ETSI EN V1.2.1 ( ): Intelligent Transport Ssytems (ITS); Access layer specification for Intelligent Transport Systems operating in the 5 GHz frequency band. [2] AutoNet2030: Initial system design specifications for automated driving support v1.0 [3]A. Marjovi, M. Vasic, J. Lemaitre and A. Martinoli, Dynamic convoy control for networked autonomousvehicles, submitted to IEEE Transactions on Automation Science and Engineering (T-ASE), special Issue on Networked Cooperative Autonomous Systems, under review, [4]Qian, Xiangjun, Jean Gregoire, Fabien Moutarde, and Arnaud De La Fortelle. "Autonomous Intersection Management for Mixed Traffic Flow." arxiv preprint arxiv: (2014). [5] ETSI EN : Intelligent Transport Systems (ITS); Communications Architecture. [6] ETSI EN : Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 2: Specification of Cooperative Awareness Basic Service, Draft v1.3.5 ( ). [7] ETSI EN v1.2.2 ( ): Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 3: Specifications of Decentralized Environmental Notification Basic Service. [8] ETSI EN : Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 5: Transport Protocols; Sub-part 1: Basic Transport Protocol. [9] ETSI TS : Intelligent Transport Systems (ITS); Users and applications requirements; Part 2: Applications and facilities layer common data dictionary. [10] Recommendation ITU-T X.691: Information technology ASN.1 encoding rules: Specification of Packed Encoding Rules (PER). [11] ETSI EN : Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 4: Geographical addressing and forwarding for point-to-point and point-to-multipoint communications; Subpart 1: Media-Independent Functionality. [12] RTCM : Standard for Networked Transport of RTCM via Internet Protocol (Ntrip), Version 2.0 with Amendment 1 (June 28, 2011). [13] ETSI ITS WG1, meeting #23: Reliable broadcast support (contribution document #46) [14] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987, < [15] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means for Expressing Location Information in the Domain Name System", RFC 1876, January 1996, [16] ETSI EN : "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Local Dynamic Map (LDM) Specification". 71

80 [17] ETSI TS V1.1.1 ( ): "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 1: Functional Requirements". [18] ETSI TS V1.1.1 ( ): Intelligent Transport Systems (ITS);OSI cross-layer topics; Part 10: Interface between access layer and networking & transport layer.. [19] I. Llatser, S. Kühlmorgen, A. Festag and G. Fettweis, Greedy Algorithms for Information Dissemination within Groups of Autonomous Vehicles, submitted to IEEE Intelligent Vehicles Symposium [20] SAE International Surface Vehicle standard, Dedicated Short Range Communications (DSRC) Message Set Dictionary, SAE Standard J2735, Draft 29 July [21] ETSI TS : Intelligent Transport Systems (ITS); Facilities layer function; Facility Position and time management, Draft v0.02 ( ). [22]ISO 8601:2004: "Data elements and interchange format -- Information interchange -- Representation of dates and times". [23] ETSI TS V1.1.1 ( ): Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 4: Geographical addressing and forwarding for point-to-point and point-to-multipoint communications; Sub-part 2: Media-dependent functionalities for ITS-G5.

81 5 Appendix A: ASN.1 Specification 5.1 ASN.1 Specification of a CLCM This Section provides the ASN.1 representation of the Cooperative Lane Change Message (CLCM). The data elements and data frames of the CLCM are described in AppendixHiba! A hivatkozási forrás nem található.. CLCM DEFINITIONS AUTOMATIC TAGS ::= BEGIN IMPORTS ActionID, Heading, ItsPduHeader, DeltaLatitude, DeltaLongitude, LanePosition, Longitude, LongitudinalAcceleration, Latitude, ReferencePosition, Speed, SpeedValue, StationID, StationType FROM ITS-Container{ itu-t (0) identified-organization (4) etsi (0) itsdomain (5) wg1 (1) ts (102894) cdd (2) version (1)} AccelerationCapacity, BrakingCapacity, DistanceValue, GroupID FROM CommonDataDictionary; -- The root data frame for Cooperative Lane Change Message CooperativeLaneChangeMessage ::= SEQUENCE { itsheader ItsPduHeader, messageheader CooperativeLaneChange-MessageHeader, messagebody CooperativeLaneChange-MessageBody } CooperativeLaneChange-MessageHeader::= SEQUENCE { actionid ActionID } CooperativeLaneChange-MessageBody::= CHOICE { lanechangerequest LaneChangeRequest, lanechangeresponse LaneChangeResponse, lanechangeabort NULL, lanechangeprepared NULL } LaneChangeRequest ::= SEQUENCE { requestid subjectvehicles lanechangedirection targetarea targetlane targetlanechangetime targetlanechangespeed minimumlanechangedistance targetvehicleid... } LaneChangeResponse ::= SEQUENCE { requestid responsetype targetvehicle targetvehicleprecedingvehicleid predictedlanechangespeed groupid... RequestID, SEQUENCE SIZE(1..8,...) OF Vehicle, LaneChangeDirection, TargetArea, LanePosition, LaneChangeTime, SpeedValue, DistanceValue, StationID OPTIONAL, RequestID, ResponseType, Vehicle OPTIONAL, StationID OPTIONAL, SpeedValue OPTIONAL, GroupID OPTIONAL, 73

82 } LaneChangeTime ::= INTEGER {utcstartof2004(0), dotonesecafterutcstartof2004(1)} ( ) DeltaReferenceTime ::= INTEGER {onemillisecondsinpast(1)} ( ,...) RequestID ::= INTEGER (0..255) AreaWidth ::= INTEGER (0..511) DeltaAreaWidth ::= INTEGER (0,..., ) Vehicle ::= SEQUENCE { vehicleid stationtype referencetime referenceposition stationheading stationspeed accelerationcapacity brakingcapacity... } StationID, StationType, DeltaReferenceTime, ReferencePosition, Heading, Speed, AccelerationCapacity, BrakingCapacity, ResponseType ::= ENUMERATED { acknowledged (1), denied (2), interfering (3) } LaneChangeDirection ::= ENUMERATED { lanechangetoleftlane (1), lanechangetorightlane (2) } TargetArea ::= SEQUENCE { firstwaypointlatitude firstwaypointlongitude firstwaypointwidth subsequentwaypoints } TargetAreaWaypoint ::= SEQUENCE { deltalatitude deltalongitude deltawidth } Latitude, Longitude, AreaWidth, SEQUENCE SIZE(1..16) OF TargetAreaWaypoint DeltaLatitude, DeltaLongitude, DeltaAreaWidth END

83 5.2 ASN.1 Specification of a CMM This Section provides the ASN.1 representation of the Convoy Management Message (CMM). The data elements and data frames of the CLCM are described in Appendix 7.2. CMM DEFINITIONS AUTOMATIC TAGS ::= BEGIN IMPORTS ItsPduHeader, TimestampIts, LanePosition, SpeedValue, StationID FROM ITS-Container { itu-t (0) identified-organization (4) etsi (0) itsdomain (5) wg1 (1) ts (102894) cdd (2) version (1)} AccelerationCapacityValue FROM CommonDataDictionary; -- The root data frame of the Convoy Management Message ConvoyManagementNessage::= SEQUENCE { itsheader ItsPduHeader, messagebody ConvoyManagement-MessageBody } ConvoyManagement-MessageBody ::= CHOICE { joinrequestmessage JoinRequestMessage, joinacceptmessage JoinAcceptMessage, lanechangemessage LaneChangeMessage, leavemessage LeaveMessage, responsemessage ResponseMessage, modifygraphmessage ModifyGraphMessage, modifygroupspeedmessage ModifyGroupSpeedMessage } JoinRequestMessage::= SEQUENCE { timestamp convoyid vehicleinfront vehiclebehind maximumacceleration maximumvelocity } JoinAcceptMessage::= SEQUENCE { timestamp convoyid groupvelocity } LaneChangeMessage::= SEQUENCE { timestamp convoyid vehicleinfront vehiclebehind laneposition } LeaveMessage::= SEQUENCE { timestamp convoyid } ResponseMessage::= SEQUENCE { timestamp TimestampIts, StationID, StationID OPTIONAL, StationID OPTIONAL, AccelerationCapacityValue, SpeedValue TimestampIts, StationID, SpeedValue TimestampIts, StationID, StationID OPTIONAL, StationID OPTIONAL, LanePosition TimestampIts, StationID TimestampIts, 75

84 } convoyid StationID ModifyGraphMessage::= SEQUENCE { timestamp convoyid vehicleinfront vehiclebehind vehicletoleft vehicletoright } TimestampIts, StationID, StationID OPTIONAL, StationID OPTIONAL, StationID OPTIONAL, StationID OPTIONAL ModifyGroupSpeedMessage::= SEQUENCE { timestamp TimestampIts, convoyid StationID, groupvelocity SpeedValue } END

85 5.3 ASN.1 Specification of an IEM This Section provides the ASN.1 representation of the Intersection Entry Message (IEM). The data elements and data frames of the IEM are described in Appendix7.3. IEM DEFINITIONS AUTOMATIC TAGS ::= BEGIN IMPORTS Heading, ItsPduHeader, LateralAccelerationValue, LongitudinalAccelerationValue, Speed, ReferencePosition, StationID, StationType, TimestampIts, VehicleLengthValue, VehicleRole, VehicleWidth FROM ITS-Container{itu-t (0) identified-organization (4) etsi (0) itsdomain (5) wg1 (1) ts (102894) cdd (2) version (1)}; -- The root data frame for Cooperative Intersection Control Message IntersectionEntryMessage ::= SEQUENCE { itsheader ItsPduHeader, messagebody IntersectionEntry-MessageBody } IntersectionEntry-MessageBody ::= CHOICE { activerequest cancellationrequest entrystatus } IntersectionEntryRequest, IntersectionEntryCancellation, IntersectionEntryStatus IntersectionEntryRequest ::= SEQUENCE { generationtime TimestampIts, intersectionid IntersectionID, requestid RequestID, intersectionentrytimestampdelta INTEGER( ), -- in units of 0.1 second inlane LaneID, outlane LaneID, priorityclass PriorityClass, stationtime DeltaTimestampIts, stationrole VehicleRole, stationtype StationType, stationposition ReferencePosition, stationspeed Speed, stationheading Heading, stationlength VehicleLengthValue, stationlonaccel LongitudinalAccelerationValue,... } IntersectionEntryCancellation ::= SEQUENCE { generationtime intersectionid requestid... } IntersectionEntryStatus ::= SEQUENCE { generationtime intersectionid prioritygraph... } TimestampIts, IntersectionID, RequestID, TimestampIts, IntersectionID, SEQUENCE (SIZE(1..7)) OF EntryVector OPTIONAL, EntryVector ::= SEQUENCE (SIZE(1..7)) OF Entry 77

86 Entry ::= SEQUENCE { stationidentifier inlane outlane priority } StationID, LaneID, LaneID, PriorityClass IntersectionID ::= INTEGER( ) RequestID ::= INTEGER( ) LaneID ::= INTEGER(0..255) -- The value 0 indicates that the LaneID is unknown. -- The value 0 shall not be used in this context. -- The value 255 is reserved for future use PriorityClass ::= ENUMERATED { high-priority (0), normal-priority (1) } DeltaTimestampIts ::= INTEGER { onemillisecondinthepas(1) } (0..511) END

87 5.4 ASN.1 Specification of a CAM This Section provides the ASN.1 representation of the Cooperative Awareness Message (CAM). The data elements and data frames of the CAM are described in Appendix 7.4. CAM DEFINITIONS AUTOMATIC TAGS ::= BEGIN IMPORTS ItsPduHeader, CauseCode, ReferencePosition, AccelerationControl, Curvature, CurvatureCalculationMode, Heading, LanePosition, EmergencyPriority, EmbarkationStatus, Speed, SpeedValue, DriveDirection, DeltaReferencePosition, LongitudinalAcceleration,LateralAcceleration, VerticalAcceleration, StationType, ExteriorLights,DangerousGoodsBasic, SpecialTransportType, LightBarSirenInUse, VehicleRole,VehicleLength, VehicleWidth, PathHistory, RoadworksSubCauseCode, ClosedLanes,TrafficRule, SpeedLimit, SteeringWheelAngle, PerformanceClass, YawRate, ProtectedCommunicationZone, PtActivation, Latitude, Longitude, ProtectedCommunicationZonesRSU, CenDsrcTollingZone FROM ITS-Container{itu-t (0) identified-organization (4) etsi (0) itsdomain (5) wg1 (1) ts (102894) cdd (2) version (1)} BrakingCapacity, Distance, DistanceValue, GenerationDeltaTime, GroupID, LongitudinalAccelerationValue FROM CommonDataDictionary; -- The root data frame for Cooperative Awareness Message CooperativeAwarenessMessage ::= SEQUENCE { headeritspduheader, camcoopawareness } CoopAwareness ::= SEQUENCE { generationdeltatimegenerationdeltatime, camparameterscamparameters } CamParameters ::= SEQUENCE { basiccontainerbasiccontainer, highfrequencycontainer HighFrequencyContainer, lowfrequencycontainer LowFrequencyContainer OPTIONAL, specialvehiclecontainer SpecialVehicleContainer OPTIONAL,... } HighFrequencyContainer ::= CHOICE { basicvehiclecontainerhighfrequency BasicVehicleContainerHighFrequency, rsucontainerhighfrequency RSUContainerHighFrequency,..., -- further type specific RSU containers might be added as extensions [[ -- extension for automated driving automatedvehiclecontainerhighfrequency AutomatedVehicleContainerHighFrequency ]],... } LowFrequencyContainer ::= CHOICE { basicvehiclecontainerlowfrequency BasicVehicleContainerLowFrequency,..., -- further type specific RSU containers might be added as extensions [[ -- extension for automated driving automatedvehiclecontainerlowfrequency AutomatedVehicleContainerLowFrequency ]],... } 79

88 SpecialVehicleContainer ::= CHOICE { publictransportcontainer PublicTransportContainer, specialtransportcontainer SpecialTransportContainer, dangerousgoodscontainer DangerousGoodsContainer, roadworkscontainerbasic RoadWorksContainerBasic, rescuecontainer RescueContainer, emergencycontainer EmergencyContainer, safetycarcontainer SafetyCarContainer,... } BasicContainer ::= SEQUENCE { stationtype StationType, referenceposition ReferencePosition,... } BasicVehicleContainerHighFrequency ::= SEQUENCE { heading Heading, speed Speed, drivedirection DriveDirection, vehiclelength VehicleLength, vehiclewidth VehicleWidth, longitudinalacceleration LongitudinalAcceleration, curvature Curvature, curvaturecalculationmode CurvatureCalculationMode, yawrate YawRate, accelerationcontrol AccelerationControl OPTIONAL, laneposition LanePosition OPTIONAL, steeringwheelangle SteeringWheelAngle OPTIONAL, lateralacceleration LateralAcceleration OPTIONAL, verticalacceleration VerticalAcceleration OPTIONAL, performanceclass PerformanceClass OPTIONAL, cendsrctollingzone CenDsrcTollingZone OPTIONAL, distancetoprecedingvehicle Distance OPTIONAL-- breaks backwardscompatibility } AutomatedVehicleContainerHighFrequency ::= SEQUENCE { heading Heading, speed Speed, longitudinalacceleration LongitudinalAcceleration, lateralacceleration LateralAcceleration, verticalacceleration VerticalAcceleration, distancetoprecedingvehicle Distance OPTIONAL } BasicVehicleContainerLowFrequency ::= SEQUENCE { vehiclerole VehicleRole, exteriorlights ExteriorLights, pathhistory PathHistory } AutomatedVehicleContainerLowFrequency ::= SEQUENCE { drivingmode AutomatedDrivingMode, automatedcontrol AutomatedControl, targetspeed SpeedValue, targetlongitudinalacceleration LongitudinalAccelerationValue, brakingcapacity BrakingCapacity, targetdistancetoprecedingvehicle DistanceValue(0..509) OPTIONAL, targetdistancetofollowingvehicle DistanceValue(0..509) OPTIONAL, pathprediction PathPrediction OPTIONAL,

89 } groupid GroupID OPTIONAL, groupspeed SpeedValue OPTIONAL PublicTransportContainer ::= SEQUENCE { embarkationstatus EmbarkationStatus, ptactivation PtActivation OPTIONAL } SpecialTransportContainer ::= SEQUENCE { specialtransporttype SpecialTransportType, lightbarsireninuse LightBarSirenInUse } DangerousGoodsContainer ::= SEQUENCE { dangerousgoodsbasic DangerousGoodsBasic } RoadWorksContainerBasic ::= SEQUENCE { roadworkssubcausecode RoadworksSubCauseCode OPTIONAL, lightbarsireninuse LightBarSirenInUse, closedlanes ClosedLanes OPTIONAL } RescueContainer ::= SEQUENCE { lightbarsireninuse LightBarSirenInUse } EmergencyContainer ::= SEQUENCE { lightbarsireninuse LightBarSirenInUse, incidentindication CauseCode OPTIONAL, emergencypriority EmergencyPriority OPTIONAL } SafetyCarContainer ::= SEQUENCE { lightbarsireninuse LightBarSirenInUse, incidentindication CauseCode OPTIONAL, trafficrule TrafficRule OPTIONAL, speedlimit SpeedLimit OPTIONAL } RSUContainerHighFrequency ::= SEQUENCE { protectedcommunicationzonesrsu ProtectedCommunicationZonesRSU OPTIONAL,... } -- High frequency AutomatedDrivingMode::= ENUMERATED { semi-automated(0), fully-automated(1) } -- Low frequency AutomatedControl ::= BIT STRING { automaticlanechangeengaged (0), convoyengaged (1), platooningengaged (2), lanekeepassistengaged (3), caccenabled (4) } (SIZE (4)) PathPrediction ::= SEQUENCE SIZE (1..23) OF PredictedPathPoint PredictedPathPoint ::= SEQUENCE { predictedpathdeltatime PredictedPathDeltaTime, predictedpathdeltaposition DeltaReferencePosition, 81

90 } predictedpathdeltapositionconfidence DeltaPositionConfidenceEllipse, predictedpathdeltaspeed DeltaSpeed OPTIONAL, predictedpathdeltalongitudinalacceleration DeltaAcceleration OPTIONAL, predictedpathdeltalateralacceleration DeltaAcceleration OPTIONAL PredictedPathDeltaTime ::= INTEGER {tenmillisecondsinfuture(1)} ( ,...) DeltaPositionConfidenceEllipse ::= SEQUENCE { deltasemimajorconfidence DeltaSemiAxisLength, deltasemiminorconfidence DeltaSemiAxisLength, deltasemimajororientation DeltaHeadingValue } DeltaSemiAxisLength ::= INTEGER { outofminimumrange(-512), plusonecentimeter(1), outofmaximumrange(1534), unavailable(4095) } ( ) DeltaHeadingValue ::= INTEGER{ plusdotonedegrees(1), unavailable(3600) } ( ) DeltaSpeed ::= SEQUENCE { deltaspeedvalue DeltaSpeedValue, deltaspeedconfidence DeltaSpeedConfidence } DeltaSpeedValue ::= INTEGER { minusdotonemeterpersec(-1), plusdotonemeterpersec(1), outofminimumrange(- 255), outofmaximumrange(255), unavailable(16383) } ( ) DeltaSpeedConfidence ::= INTEGER { outofminimumrange(-63), minusdotonemeterpersec(-1), plusdotonemeterpersec(1), outofmaximumrange(63), unavailable(127) } ( ) DeltaAcceleration ::= SEQUENCE { deltaaccelerationvalue DeltaAccelerationValue, deltaaccelerationconfidence DeltaAccelerationConfidence } DeltaAccelerationValue ::= INTEGER { minusdotonemeterpersecsquared(-1), plusdotonemeterpersecsquared(1), unavailable(161) }( ) DeltaAccelerationConfidence ::= INTEGER { minusdotonemeterperseqsquared(-1), plusdotonemeterpersecsquared(1), unavailable(102) }( ) END

91 5.5 ASN.1 Specification of a CSM This Section provides the ASN.1 representation of the Cooperative Sensing Message (CSM).The data elements and data frames of the CSAM are described in Appendix7.5. CSM DEFINITIONS AUTOMATIC TAGS ::= BEGIN IMPORTS ItsPduHeader, ReferencePosition, StationType, Speed, Heading FROM ITS-Container{ itu-t (0) identified-organization (4) etsi (0) itsdomain (5) wg1 (1) ts (102894) cdd (2) version (1)} GenerationDeltaTime FROM CommonDataDictionary; -- The root data frame for the Cooperative Sensing Message CooperativeSensingMessage ::= SEQUENCE { itsheader ItsPduHeader, messagebody CooperativeSensing-MessageBody } -- Content of the Cooperative Sensing Message CooperativeSensing-MessageBody ::= SEQUENCE { detectedobjects SEQUENCE SIZE(1..16,...) OF DetectedObject,... } DetectedObject ::= SEQUENCE { detectiontime detectionsource objectposition objecttype objectspeed objectheading } GenerationDeltaTime, DetectionSource, ReferencePosition, ObjectType OPTIONAL, Speed OPTIONAL, Heading OPTIONAL DetectionSource ::= CHOICE { unknown NULL, sensor SensorType } SensorType ::= BIT STRING { local (0), remote (1) }(SIZE(2)) ObjectType ::= SEQUENCE { objecttypevalue objecttypeconfidence } StationType, StationTypeConfidence StationTypeConfidence ::= INTEGER(0..100) END 83

92 5.6 ASN.1 Specification of a CSAM This Section provides the ASN.1 representation of the Cooperative Speed Advising Message (CSAM). The data elements and data frames of the CSAM are described in Appendix7.6. CSAM DEFINITIONS AUTOMATIC TAGS ::= BEGIN IMPORTS ItsPduHeader, TimestampIts, ReferencePosition, Latitude, Longitude, Heading, SpeedValue, StationID FROM ITS-Container{ itu-t (0) identified-organization (4) etsi (0) itsdomain (5) wg1 (1) ts (102894) cdd (2) version (1)}; CooperativeSpeedAdviceMessage ::= SEQUENCE { itsheader ItsPduHeader, messagebody CooperativeSpeed-MessageBody } CooperativeSpeed-MessageBody ::= CHOICE { speedrequestmessage SpeedRequestMessage, speedadvisemessage SpeedAdviseMessage, speedreportmessage SpeedReportMessage } SpeedRequestMessage::= SEQUENCE { timestamp position heading } SpeedAdviseMessage::= SEQUENCE { timestamp advisedspeed relevantpolygon } SpeedReportMessage::= SEQUENCE { timestamp position heading speed } RelevantVertex ::= SEQUENCE { latitude longitude } END TimestampIts, ReferencePosition, Heading TimestampIts, SpeedValue, SEQUENCE SIZE(2..8) OF RelevantVertex TimestampIts, ReferencePosition, Heading, SpeedValue Latitude, Longitude

93 5.7 ASN.1 Specification of a Common Data Dictionary This Section provides the ASN.1 representation of the Common Data Dictionary (CDD) which holds common Data Elements (DE) and Data Frames (DF) to the ASN.1 specifications in this chapter. The DE and DF of this CDD are described in Appendix7.7. CommonDataDictionary DEFINITIONS AUTOMATIC TAGS ::= BEGIN IMPORTS LongitudinalAcceleration, LongitudinalAccelerationValue FROM ITS-Container{ itu-t (0) identified-organization (4) etsi (0) itsdomain (5) wg1 (1) ts (102894) cdd (2) version (1)}; AccelerationCapacity ::= LongitudinalAcceleration ( WITH COMPONENTS { longitudinalaccelerationvalue(0..161), longitudinalaccelerationconfidence }) AccelerationCapacityValue ::= LongitudinalAccelerationValue(0..161) BrakingCapacity ::= LongitudinalAcceleration ( WITH COMPONENTS { longitudinalaccelerationvalue( ), longitudinalaccelerationconfidence }) Distance ::= SEQUENCE { distancevalue distanceconfidence } DistanceValue, DistanceConfidence DistanceValue ::= INTEGER {dotonemeter(1), outofrange(510), unavailable(511)} (0..511) -- Confidence of the distance DistanceConfidence ::= INTEGER { equalorwithindotonemeter(1), equalorwithindottwometer(2), outofrange(31), unavailable(32) } (1..32) GenerationDeltaTime ::= INTEGER { onemillisec(1) } ( ) GroupID ::= INTEGER( ) END 85

94 6 Appendix B: SAP Specification 6.1 SAP Specification of interface CLCS.CONTROL Interface CLCS.CONTROL of the Cooperative Lane Change Service (CLCS) as specified in Chapter 2.1 provides a service to ITS Applications to cooperatively plan, prepare and execute a lane change. This section specifies the interface CLCS.CONTROL as a Service Access Point (SAP) and its related primitives Primitive CLCS.CONTROL.request The primitive CLCS.CONTROL.request may be used by an ITS Application to eithersearch for a target vehicle or request a target vehicle to prepare for the cooperative lane change, depending on the provided parameters. The parameters of primitive CLCS.CONTROL.request are as follows: CLCS.CONTROL.request ( Dialogue Identifier (Optional), Subject Vehicles, Lane Change Direction, Target Area, Target Lane, TargetLane Change Time, Target Lane Change Speed, Minimum Lane Change Distance, Target Vehicle Identifier (Optional) ) The Dialogue Identifieridentifies the dialogue between subject vehicle(s) and target vehicle for the planning, preparation and execution of a lane change. This parameter is optional and shall be set to update an existing dialogue. If not set, a new dialogue willbe created. The parameter Subject Vehicles is a list of vehicle descriptions, ordered according their order of driving with the leading vehicle first. Each described vehicle is a subject vehicle involved in the lane change and its description includes a mandatory station identifier and optional station type, position, speed, acceleration capacity, braking capacity and corresponding confidences. The Lane Change Direction indicates the direction of the lane change. The values Lane Change to Left and Lane Change to Rightindicate respectively a lane change to the adjacent left and right lane. The Target Area is a geographical area to which the subject vehicle(s) intend to change to is described using an ordered list of waypoints and the lane width at each waypoint. The Target Lane is lane number, counted from the outside of the road in driving direction, to which the subject vehicle(s) intend to change to. The most outer lane has number 1.

95 The Target Lane Change Time is the targeted time by the subject vehicle(s) to start the lane change to the Target Area. The Target Lane Change Speed is the targeted speed of the subject vehicle(s) at which a lane change should be performed. The Minimum Lane Change Distance is the minimum distance needed by the subject vehicle(s) in the Target Area to perform the lane change. The Target Vehicle Identifier is the facilities-layer identifier of the target vehicle which is requested to prepare for the lane change.this parameters is optional. If set, the request is to prepare for a lane change. If not set, the requests starts a target vehicle search Primitive CLCS.CONTROL.result The primitive CLCS.CONTROL.resultmay be used by the CLCS component to inform a requesting ITS-Application about the result of a request. The primitive CLCS.CONTROL.result has the following parameters: CLCS.CONTROL.result ( Result, Dialogue Identifier (Optional), Request Identifier (Optional) ) The Result indicates whether a request was successfully handled by the CLCS or not. The Resultmay take one of the following values: Value Success Failed The CLCS component succeeded to handle the request The CLCS component failed to handle the request The Dialogue Identifier is a station-local unique identifier identifyinga dialogue. This value can be used to link primitives of the same dialogue. This parameter is optional and shall only be provided when the Result parameter equals Success. The Request Identifier is the identifier of a certain request and allows one to relate a request and response Primitive CLCS.CONTROL.request-indication The primitive CLCS.CONTROL.request indicationis used by the CLCS component to inform ITS Applications about a received lane change request. The primitiveclcs.control.request indicationhas the following parameters: 87

96 CLCS.CONTROL.request-indication ( Dialogue Identifier, Request Identifier, Target Vehicle Identifier (Optional), Subject Vehicles, Lane Change Direction, Target Area, Target Lane, Target Lane Change Time, Target Lane Change Speed, Minimum Lane Change Distance ) The Request Identifier is the identifier of the request. This value shall be used to respond to the request. All other parameters of primitive CLCS.CONTROL.request indicationare equal to the parametersof primitiveclcs.control.request Primitive CLCS.CONTROL.resonse The primitive CLCS.CONTROL.responsecan be used by an ITS Application to respond to a dialogue request. The primitive CLCS.CONTROL.responsehas the following parameters: CLCS.CONTROL.response ( Dialogue Identifier, Request Identifier, Response Type, Target Vehicle, Target Vehicle Preceding VehicleIdentifier (Optional), Predicted Lane Change Speed (Optional), Group Identifier (Optional) ) The Dialogue Identifier is the identifier of the dialogue to which this response belongs to. The Request Identifier is the identifier of the request to which is responded. The Response Type indicates the type of response. This parameter can have the values acknowledge, denied or interfering. The value acknowledge shall be used to announce a vehicle as a potential target vehicle. The value denied shall be used to strongly object against the announced lane change with the objective to reschedule the lane change by the subject vehicle(s). The value interfering shall be used to announce a possible interference between a vehicle and the lane change. The Target Vehicle describes the vehicle which is a potential target vehicle or which is potentially interfering with the lane change. This parameter is optional and shall be set when the response type equals acknowledge or interfering.

97 The Target Vehicle Preceding VehicleIdentifier is the identifier of the preceding vehicle of the target vehicle in the same lane. This parameter is optional and may be included when the ResponseType equals acknowledge. The Predicted Lane Change Speed is the speed predicted by the target at which the lane change can be executed. This parameter is optional and shall may included when the Response Type equals acknowledge. The Group Identifier is the identifier of the group the subject vehicle shall merge into after the lane change. This parameter is optional Primitive CLCS.CONTROL.response-indication The primitive CLCS.CONTROL.response-indication is used by the CLCS component to inform ITS Applications about a received dialogue response. The primitive CLCS.CONTROL.response-indication has the following parameters: CLCS.CONTROL.response-indication ( Dialogue Identifier, Request Identifier, Response Type, Target Vehicle (Optional), Target Vehicle Preceding VehicleIdentifier (Optional), Predicted Lane Change Speed (Optional), Group Identifier (Optional) ) All parameters of primitive CLCS.CONTROL.response-indication are equal to the corresponding parameters of primitive CLCS.CONTROL.response Primitive CLCS.CONTROL.prepared The primitive CLCS.CONTROL.prepared may be used by an ITS Application to indicate the CLCS component at the target vehicle that it is prepared for the lane change. The primitive CLCS.CONTROL.prepared has the following parameters: CLCS.CONTROL.prepared ( Dialogue Identifier ) The Dialogue Identifier is the identifier of the dialogue between subject vehicle(s) and target vehicle in which the target vehicle has prepared for the lane change Primitive CLCS.CONTROL.prepared-indication The primitive CLCS.CONTROL.prepared-indication may be used by the CLCS to inform ITS Applications about a received prepared message. The primitive CLCS.CONTROL.prepared-indication has the following parameters: 89

98 CLCS.CONTROL.prepared-indication ( Dialogue Identifier ) The Dialogue Identifier is the identifier of the dialogue between subject vehicle(s) and target vehicle in which the target vehicle has prepared for the lane change Primitive CLCS.CONTROL.abort The primitive CLCS.CONTROL.abort may be used to abort a cooperative lane change. The abort may lead to a target or subject vehicle(s) to abort the lane change preparation or execution. The parameters of primitive CLCS.CONTROL.abort are as follows: CLCS.CONTROL.abort ( Dialogue Identifier ) The Dialogue Identifier is the identifier of the dialogue between subject vehicle(s) and target vehicle which is being aborted Primitive CLCS.CONTROL.abort-indication The primitive CLCS.CONTROL.abort-indication may be used by the CLCS to inform ITS Applications about a received abort message. The primitive CLCS.CONTROL.abort-indication has the following parameters: CLCS.CONTROL.abort-indication ( Dialogue Identifier ) The Dialogue Identifier is the identifier of the dialogue between subject vehicle(s) and target vehicle in which the target vehicle has aborted the lane change Primitive CLCS.CONTROL.finalize The primitive CLCS.CONTROL.finalize shall be used by an ITS Application to finalize a lane change dialogue after a successful cooperative lane change. The parameters of primitive CLCS.CONTROL.finalize are as follows: CLCS.CONTROL.finalize ( Dialogue Identifier, ) The Dialogue Identifier is the identifier of the dialogue between subject vehicle(s) and target vehicle which is being finalized.

99 6.2 SAP Specification of interface CICS.IE The Cooperative Intersection Control Service (CLCS) as specified in Chapter2.3exposes the interfaces Interface CICS.IS and CICS.IE on respectively a Road-side ITS-S and Vehicle ITS-S. This section specifies these interfaces as a SAP and its primitives Primitive CICS.IE.request The primitive CICS.IE.request is used by an application of a vehicle ITS-S to request intersection entry to the managing intersection controller. Upon the reception of the CICS.IE.request primitive, thecics of the vehicle ITS-s generates an Intersection Entry Message (IEM) using the parameters of thisprimitive and ego-vehicle parameters retrieved from other facility-layer components. A vehicle ITS-S can only make one intersection entry request per intersection. Subsequent CICS.IE.request primitives will update intersection entry request for the particular intersection. The parameters of primitive CICS.IE.request are specified as follows: CICS.IE.request ( GN Address, Intersection Identifier, Request Identifier (Optional), Intersection Entry Timestamp, In-Lane, Out-Lane, Priority-Class ) The GN Address is the GeoNetworking address of the targeted intersection controller ITS-S. The Intersection Identifier is a local unique identifier of the intersection to which entry is requested by the requesting vehicle. This Intersection Identifier is equal to the Intersection Identifier as is broadcasted by the intersection RSU in a MAP message as specified in SAE J2735 [20]. The Request Identifier is identifying the request to be updated. This optional identifier is uniquely identifying a particular request in combination with the intersection identifier and shall only be set when a previous request is updated. In case of a new request, this parameter shall be omitted. The parameterintersection Entry Timestamp is the start time of the period during which entry is requested by the vehicle. This time is estimated by the vehicle as the time of entering the intersection. The In-Lane is the identifier of the lane the vehicle will enter the intersection. The In-Lane uniquely identifies a lane in an intersection. The In-Lane shall be equal to the identifier of the lane as broadcasted by the intersection RSU in a MAP message as specified in SAE J2735 [20]. 91

100 The Out-Lane is the identifier of the lane the vehicle will exit the intersection. The Out-Lane uniquely identifies a lane in an intersection. TheOut-Lane shall be equal to the identifier of the lane as broadcasted by the intersection RSU in a MAP message as specified in SAE J2735 [20]. The Priority-Class indicates the priority class of the requesting vehicle. A high priority class may preempt the request of other vehicles and may only be used by special vehicles like an ambulance, a fire truck or police car in emergency situations. The highest priority class allowed to be requested by a particular vehicle is specified in the Service Specific Permissions (SSP) of the certificate of an IEM. The definition of the SSP of IEMs is out of scope of the current specification Primitive CICS.IE.response The primitive CICS.IE.response is returned to the upper-layer entity that has sent the primitive CICS.IE.request or CICS.IE.cancelin order to inform about the result of the request. The parameters of the primitive CICS.IE.response are specified as follows: CICS.IE.response ( Response Code, Request Identifier (Optional) ) The Response Code is a value indicating the success or failure of the sent primitive CICS.IE.request or CICS.IE.cancel. The Response Code may have the following values: Value Confirmed Unconfirmed NotAccepted_InvalidParameters NotAccepted_UnspecifiedReason The primitive was accepted by the CICS and acknowledge by the RSU ITS-S. The primitive was accepted by the CICS but no acknowledgement was received from the RSU ITS-S before the timeout. The primitive was not accepted by the CICS due to wrong parameters The primitive was not accepted by the CICS due to an unspecified reason The Request Identifier identifies the request and may be updated when the request updates a previous request. This parameter is optional and only set when the Response Code is Confirmed Primitive CICS.IE.cancel The primitive CICS.IE.cancel is used to cancel the last intersection entry request for the intersection with the given intersection identifier. The parameters of this primitive are as follows: CICS.IE.cancel ( GN Address

101 ) Intersection Identifier, Request Identifier The GN Address is the GeoNetworking address of the targeted intersection controller ITS-S. The Intersection Identifier is a local unique identifier of the intersection for which an entry request is cancelled. This Intersection Identifier is equal to the Intersection Identifier as is broadcasted by the intersection RSU in a MAP message as specified in SAE J2735 [20]. The Request Identifier is the identifier of the request which is cancelled. The Request Identifier is unique in combination with the Intersection Identifier Primitive CICS.IE.inform The primitive CICS.IE.inform is used by the CICS component to inform any upper-layer entity about an update of the priority graph. The parameters of the primitive CICS.IE.inform are as follows: CICS.IE.inform ( Generation Time, GN Address, Intersection Identifier, Priority Graph ) The Generation Time is the time at which the intersection entry message was created by the source. The Generation Time can be used by a receiving ITS-S to order priority graph updates for a particular intersection identifier and ignore out-of-order priority graph updates. The GN Address is the GeoNetworking address of the ITS-S that announced the intersection priority graph. The Intersection Identifier is a local unique identifier of the priority graph s intersection. This Intersection Identifier is equal to the Intersection Identifier as is broadcasted by the intersection RSU in a MAP message as specified in SAE J2735 [20]. The Priority Graph is the graph ordering given intersection entries. See the description of the Priority Graph of primitive CICS-IS.announce Primitive CICS.IS.announce The primitive CICS.IS.announce is sent by an upper-layer entity to the CICS component to announce the priority graph of a particular intersection with given intersection identifier. This primitive is meant to be used at the road-side unit and the upper-layer entity is likely a cooperative intersection controller. The parameters of the primitive CICS.IS.announce are as follows: 93

102 CICS.IS.announce ( Intersection Identifier, Priority Graph ) The Intersection Identifier is the identifier of the intersection for which entry is announced. The Priority Graph is a list of priority vectors. Each priority vectors contains an ordered list of vehicle entries. A vehicle entry higher in the list has priority over a lower vehicle entry in the same priority vector. Vehicles described by vehicle entries in different priority vectors are non-intersection and no right of way needs to be provided by vehicles corresponding to the vehicle entries Primitive CICS.IS.indicate The primitive CICS.IS.indicate is used to indicate to the cooperative intersection controller an intersection entry request. The parameters of this primitive are as follows: CICS.IS.indicate ( Generation Time, Intersection Identifier, Request Identifier, Is Cancellation, Intersection Entry Timestamp, In-Lane, Out-Lane, Priority-Class, Station Identifier, Station Type, Station Position, Station Speed, Station Heading, Station Length, Station Acceleration, ) The Generation Time is the time at which the IEM was generated at the vehicle-side. This Generation Time may be used in combination with the StationIdentifier to order and ignore old intersection entry requests of a particular vehicle. The Intersection Identifier is the identifier of the intersection for which entry is requested. The Request Identifieridentifies in combination with the Intersection Identifier which request is being updated or cancelled.

103 The Is Cancellation parameter is used to indicate whether the intersection entry request is a cancellation of a previous intersection entry request. The values true and false mean respectively that a previous request is cancelled or not. The Intersection Entry Timestamp is the time of arrival estimated by the vehicle requesting entry. This value is optional and shall be present when Is Cancellation is set to false. The In-Lane is the identifier of the lane the vehicle will enter the intersection. The In-Lane uniquely identifies a lane in an intersection. The lane identifier shall be equal to the identifier of the lane as broadcasted by the intersection RSU in a MAP message as specified in SAE J2735 [20]. This value is optional and is only present when Is Cancellation is set to false. The Out-Lane is the identifier of the lane the vehicle will exit the intersection. The Out-Lane uniquely identifies a lane in an intersection. The lane identifier shall be equal to the identifier of the lane as broadcasted by the intersection RSU in a MAP message as specified in SAE J2735 [20]. This value is optional and is only present when Is Cancellation is set to false. The Priority-Class indicates the priority class of the requesting vehicle. A high priority may preempt other requests with a lower priority classes and may only be used by special vehicles like an ambulance, a fire truck or police car in emergency situations. This priority class has been checked against the maximum allowed priority class of the requesting vehicle. This value is optional and is only present when Is Cancellation is set to false. The Station Identifier is the locally temporal unique identifier identifying the requesting vehicle. This value is optional and is only present when Is Cancellation is set to false. The Station Type indicates the type of the requesting vehicle. This value is optional and is only present when Is Cancellation is set to false. The Station Position contains the geographical position of the vehicle at the time the intersection entry was requested. This position corresponds to the Latitude, Longitude and Altitude of the ITS reference position of the vehicle as specified in ETSI TS [21] in addition with their respective confidence values. This value is optional and is only present when Is Cancellation is set to false. The Station Speed gives the speed of the requesting vehicle at the time the intersection entry was requested. This value is optional and is only present when Is Cancellation is set to false. The Station Heading is the heading of the movement of the requesting vehicle. This value is optional and is only present when Is Cancellation is set to false. The Station Lengthis the length of the requesting vehicle. This value is optional and is only present when Is Cancellation is set to false. The Station Accelerationis the accelerations of the requesting vehicle in longitudinal direction. This value is optional and is only present when Is Cancellation is set to false. 95

104 6.3 SAP Specification of interface RBTP.DATA The Reliable Basic Transport Protocol (RBTP) component as specified in Chapter 2.10 exposes the interfaces Interface RBTP.DATA. This section specifies this interface as a SAP and its primitives Primitive RBTP.DATA.request The primitive RBTP.DATA.request is used to request the reliable transmission of a RBTP packet. This primitive is similar as the primitive BTP-Data.request in ETSI EN [8]. Upon the reception of the RBTP.DATA.request, the RBTP component generates a RBTP packet and delivers the header together with the data and GeoNetworking parameters (i.e. indicated by the parameter names starting with GN ) to the GeoNetworking protocol via the GN-SAP. The parameters of the RBTP.DATA.request are as follows: RBTP.DATA.request ( Source Port, Destination Port, Acknowledgement Timeout, GN Destination Address, GN Communication Profile, GN Maximum Packet Lifetime, (optional) GN Repetition Interval, (optional) GN Traffic Class, Length, Data ) The parameters are similar to the BTP-Data.request primitive of the Basic Transport Protocol ETSI EN [8], except for the following parameters: The Acknowledgement timeout specifies the maximum time in milliseconds for waiting for an acknowledgement by the source. If no acknowledgement was received before this timeout, the RBTP responds to the entity that requested the RBTP.DATA.request primitive with failure. The Acknowledgement timeout period starts when the RBTP.DATA.request is received by RBTP. After the timeout, no retransmissions shall be performed by the RBTP. The Acknowledgement timeout value shall be in the range of milliseconds. The GN Destination Address is the destination s GN address Primitive RBTP.DATA.confirm The primitive RBTP.DATA.confirm is used to respond to the primitive RBTP.DATA.request whether the request was accepted or not by the sending RBTP. RBTP.DATA.confirm ( ConfirmCode )

105 The ConfirmCode may have the following values: Value Accepted NotAccepted_InvalidParameters NotAccepted_UnspecifiedReason The request was accepted by RBTP The request was not accepted by RBTP due to wrong parameters The request was not accepted by RBTP due to an unspecified reason Primitive RBTP.DATA.response The primitive RBTP.DATA.responseis used to inform the ITS facility layer entity that originated the primitive RBTP.DATA.request whether the packet was acknowledged or not. This primitive shall be sent as soon as the acknowledgement was received or upon Acknowledgement timeout. RBTP.DATA.response ( ResponseCode ) The RespondeCode may have the following values: Values Acknowledged Unacknowledged The RBTP has received an acknowledgement from the destination within the Acknowledgement timeout period. The RBTP has not received an acknowledgement within the Acknowledgement timeout period Primitive RBTP.DATA.indication The primitive RBTP.DATA.indication is used to inform an ITS facility layer entity about the reception of a RBTP SDU. RBTP.DATA.indication ( Source port, Destination port, GN Packet transport type, GN Destination, GN Source position vector, GN Security Report (Optional), GN Certificate ID (Optional), GN Permissions (Optional), GN Traffic class, GN Remaining packet lifetime, 97

106 ) Length, Data The parameters of primitive RBTP.DATA.indication are similar to the BTP-Data.request primitive of the Basic Transport Protocol ETSI EN [8].

107 7 Appendix C: of Data Elements and Data Frames 7.1 of Data Elements and Data Frames of a CLCM DF_itsHeader General message header of a CLCM in common with other Application and Facilities-layer messages. This header contains a protocolversion, messageid and temporal identifier of the station sending the CLCM. The protocolversion shall be set to currentversion(1). The messageid shall be set to 129. The stationid shall be set to the current facilities-layer identifier also used by the CA BS and DEN BS. This Data Frame (DF) shall be presented as DF_ItsPduHeader as specified in ETSI TS [9] DF_messageHeader Specific CLCM header. This header includes the protocol action identifier. This DF shall be presented as specified in Appendix DF_messageBody Payload of a CLCM. This DF shall be presented as specified in Appendix DF_actionID Identifier of a cooperative lane change dialogue. A cooperative lane change dialogue includes the cooperative planning, preparation and execution of a lane change. This DF shall be presented as DF_ActionID as specified in ETSI TS [9]. The originatingstationidentifier of this DE shall be set to the facilities-layer identifier of the station originating the cooperative lane change dialogue DF_laneChangeRequest A cooperative lane change payload used by an originating station to request and announce the cooperative lane change by the subject vehicles. This DF shall be presented as specified in Appendix

108 7.1.6 DF_laneChangeResponse A cooperative lane change payload used by a (potential) target vehicle to respond to a lane change request. This DF shall be presented as specified in Appendix DF_laneChangeAbort A cooperative lane change payload used by a originating station or target vehicle to abort an ongoing cooperative lane change This DF shall be presented as specified in Appendix DF_laneChangePrepared A cooperative lane change payload used by a target vehicle to inform the originating station that the target vehicle has opened the gap for the subject vehicles to perform the lane change. This DF shall be presented as specified in Appendix DE_requestID Identifier of a request unique for a particular dialogue. This DE shall be presented as specified in Appendix DF_subjectVehicles Ordered list of vehicle descriptions which would like to perform the lane change. This DF shall be presented as specified in Appendix5.1. If this sequence contains multiple vehicle descriptions, it shall be ordered according to their driving order with head vehicle first and tail vehicle last DE_laneChangeDirection The direction of the lane change performed by the subject vehicles. This DE shall be presented as specified in Appendix5.1. The values lanechangetoleftlane and lanechangetorightlane shall be used for a lane change to respectively the left and right adjacent lane.

109 DF_targetArea The geographical area to which the subject vehicle(s) intend to change to. This DF shall be presented as specified in Appendix5.1. This area shall overlap the targetlane.this DF consists of the firstwaypointlatitude and firstwaypointlongitude which are respectively the latitude and longitude according WSG84 of the first waypoint of the target area. This first waypoint is the closest point of the target area to the subject vehicles along the path. The target area consists in addition of subsequent waypoints ordered in descending distance to the first waypoint along the path. The waypoints in subsequentwaypoints are an offset to the previous waypoint. The width at each waypoint represents the width perpendicular to the path of waypoints DF_targetLane The lane identifier which the destination vehicle(s) intend to change to. This DF shall be presented as specified in Appendix5.1. The target lane is the lane counted from the outside of the road in driving direction. The most outer lane has number DE_targetLaneChangeTime The targeted time until lane change to the target area. This DE shall be presented as specified in Appendix5.1 in units of 0.1 seconds since T00:00:00.000Z, as specified in ISO 8601 [22] DE_targetLaneChangeSpeed The targeted speed at which the lane change is performed. This DE shall be presented as DE_SpeedValue as specified in ETSI TS [9]. For a LaneChangResponse, this value is optional and shall be set when the responsetype is acknowledged DE_minimumLaneChangeDistance The minimum distance needed between the target vehicle and its preceding vehicle in order for the subject vehicle(s) to perform the lane change. This DE shall be presented as specified in Appendix DE_targetVehicleID The facilities-layer identifier of the target vehicle. This DE shall be presented as DE_StationID as specified in ETSI TS [9]. 101

110 This value is optional and shall only be set when the originating station is targeting a specific target vehicle. If the value is not set, the originating station is searching for a target vehicle DE_responseType The type of response. This DE shall be presented as specified in Appendix5.1. The value acknowledged shall be used when a station responds as a potential target vehicle. The value denied shall be used when a vehicle denies being a target vehicle. This value shall only be used when the request was explicitly targeting the particular vehicle. The value interfering may be used by any station which cannot satisfy the request but might interfere with the cooperative lane change DF_targetVehicle of the target vehicle This DF shall be presented as specified in Appendix5.1. This value is optional and shall be set when the responsetype is acknowledged DE_targetVehiclePrecedingVehicleID The facilities-layer identifier of the vehicle preceding the target vehicle. This DE shall be presented as DE_StationID as specified in ETSI TS [9]. This value is optional and shall only be set when the targetvehicleid is set and when the responsetype is acknowledged DE_predictedLaneChangeSpeed The predicted speed by the target vehicle at which the lane change may be performed. This DE shall be presented as DE_SpeedValue as specified in ETSI TS [9]. This value is optional and shall be set when the responsetype is acknowledged DE_groupID Identifier of a platoon or convoy to which the target vehicle belongs to. Subject vehicles may choose to enter this platoon or convoy upon lane change. This DE shall be presented as specified in Appendix5.1 and 5.6. This value is optional and shall be set when the responsetype is acknowledged and the target vehicle is driving in a platoon or convoy.

111 DE_vehicleID Facilities-layer identifier of the vehicle being described. This DE shall be presented as DE_StationID as specified in ETSI TS [9] DE_stationType Type of the vehicle being described. This DE shall be presented as DE_StationType as specified in ETSI TS [9] DE_referenceTime The time at which the reference position of the described vehicle was taken. This DEshall be presented as specified in Appendix5.1. The value of the DE shall be the ITS timestamp as the number of milliseconds since T00:00:00:000Z as defined in ISO 8601 [22], wrapped around value DF_referencePosition The reference position of the vehicle being described at the referencetime. This DF shall be presented as DF_ReferencePosition as specified in ETSI TS [9]. The semimajoraxis and semiminoraxis shall be the confidence bounds of the 95% symmetric confidence interval of the reference position DF_stationHeading The heading of the vehicle being described at the referencetime. This DF shall be presented as DF_Heading as specified in ETSI TS [9]. The headingconfidence of this DF shall be the confidence bound of the 95% symmetric confidence interval of the headingvalue DF_stationSpeed The speed of the vehicle being described at the referencetime. This DF shall be presented as DF_Speed as specified in ETSI TS [9]. The speedconfidence of this DF shall be the confidence bound of the 95% symmetric confidence interval of the speedvalue. 103

112 DF_accelerationCapacity The maximum acceleration of the described vehicle This DF shall be presented as specified in Appendix5.1 and 5.6. The longitudinalaccelerationconfidence of this DF shall be the confidence bound of the 95% symmetric confidence interval of the longitudinalaccelerationvalue DF_brakingCapacity The maximum deceleration of the described vehicle This DF shall be presented as specified in Appendix5.1 and 5.6. The longitudinalaccelerationconfidence of this DF shall be the confidence bound of the 95% symmetric confidence interval of the longitudinalaccelerationvalue DE_firstWaypointLatitude The latitude of the first point describing the target area. This DE shall be presented as DE_Latitude as specified in ETSI TS [9] DE_firstWaypointLongitude The longitude of the first point describing the target area. This DE shall be presented as DE_Longitude as specified in ETSI TS [9] DE_firstWaypointWidth The width of the target area at the first waypoint described by firstwaypointlatitude and firstwaypointlongitude. This DE shall be presented as specified in Appendix DF_subsequentWaypoints List of subsequent points describing the target area. This DF shall be presented as specified in Appendix DE_deltaLatitude The latitude of a subsequent waypoint describing the target area. This DE shall be presented as specified in Appendix5.1 and shall describe the difference in latitude at the previous target area waypoint.

113 DE_deltaLongitude The longitude of a subsequent waypoint describing the target area. This DE shall be presented as specified in Appendix5.1 and shall describe the difference in longitude at the previous target area waypoint DE_deltaWidth The width of the target area at a subsequent waypoint. This DE shall be presented as specified in Appendix5.1 and shall describe the difference in width at the previous target area waypoint. 105

114 7.2 of Data Elements and Data Frames of a CMM DF_itsHeader General message header of a CMM in common with other Application and Facilities-layer messages. This header contains a protocolversion, messageid and temporal identifier of the station sending the CMM. The protocolversion shall be set to currentversion(1). The messageid shall be set to 130. The stationid shall be set to the current facilities-layer identifier also used by the CA BS and DEN BS. This Data Frame (DF) shall be presented as DF_ItsPduHeader as specified in ETSI TS [9] DF_messageBody Payload of a CMM. This DF shall be presented as specified in Appendix DF_joinRequestMessage A message payload used by an originating station to request becoming part of a convoy. This DF shall be presented as specified in Appendix DF_joinAcceptMessage A message payload used by nearby convoy member vehicles to respond to a convoyjoining request. This DF shall be presented as specified in Appendix DF_laneChangeMessage A message payload used by an originating station to inform its planned lane change manoeuvre. This DF shall be presented as specified in Appendix 5.2.

115 7.2.6 DF_leaveMessage A message payload used by an originating station to inform its intention to exit the convoy. This DF shall be presented as specified in Appendix DF_responseMessage A message payload used by nearby convoy member vehicles to respond to any received convoy message, except for aconvoyjoining request. This DF shall be presented as specified in Appendix DF_modifyGraphMessage A message payload used by an originating station to inform a change in its local neighbourhood graph. This DF shall be presented as specified in Appendix DF_modifyGroupSpeedMessage A message payload used by an originating station to inform a change in the convoy s group speed. This DF shall be presented as specified in Appendix DE_timeStamp The time at which the given message has been generated. This DEshall be presented as DE_TimestampIts as specified inetsi TS [9]. The value of the DE shall be encoded as the ITS timestamp as the number of milliseconds since T00:00:00:000Z as defined in ISO 8601 [22] DE_convoyID Facilities-layer identifier of the Convoy, which the message relates to. This DE shall be presented as DE_StationID as specified in ETSI TS [9]. 107

116 DE_vehicleInFront Facilities-layer identifier of the vehicle in front of the target location, which the message relates to. This DE shall be presented as DE_StationID as specified in ETSI TS [9] DE_vehicleBehind Facilities-layer identifier of the vehicle behind the target location, which the message relates to. This DE shall be presented as DE_StationID as specified in ETSI TS [9] DE_vehicleToLeft Facilities-layer identifier of the vehicle to the left of the target location, which the message relates to. This DE shall be presented as DE_StationID as specified in ETSI TS [9] DE_vehicleToRight Facilities-layer identifier of the vehicle to the right of the target location, which the message relates to. This DE shall be presented as DE_StationID as specified in ETSI TS [9] DF_groupVelocity The group speed of the Convoy is being described by this data field. This DF shall be presented as DF_Speed as specified in ETSI TS [9]. The speedconfidence of this DF shall be the confidence bound of the 95% symmetric confidence interval of the speedvalue DF_maximumAcceleration The maximum acceleration capability of the originating vehicle This DF shall be presented as specified in Appendix5.2. The longitudinalaccelerationconfidence of this DF shall be the confidence bound of the 95% symmetric confidence interval of the longitudinalaccelerationvalue DF_maximumVelocity The maximum speed capability of the originating vehicle

117 This DF shall be presented as DF_Speed as specified in ETSI TS [9]. The speedconfidence of this DF shall be the confidence bound of the 95% symmetric confidence interval of the speedvalue DE_lanePosition This data element defines the target destination lane, which the message refers to. This DF shall be presented as DF_LanePosition as specified in ETSI TS [9]. 109

118 7.3 of Data Elements and Data Frames of a IEM DF_itsHeader General message header of aniem in common with other Application and Facilitieslayer messages. This header contains a protocolversion, messageid and temporal identifier of the station sending the IEM. The protocolversion shall be set to currentversion(1). The messageid shall be set to 131. The stationid shall be set to the current facilities-layer identifier also used by the CA BS and DEN BS. This Data Frame (DF) shall be presented as DF_ItsPduHeader as specified in ETSI TS [9] DF_messageBody Payload of an IEM. This DF shall be presented as specified in Appendix DF_activeRequest IEM payload type used by a vehicle to request entry to an intersection controller This DF shall be presented as specified in Appendix DF_cancellationRequest IEM payload type used by a vehicle to cancel a previous made entry request This DF shall be presented as specified in Appendix DF_entryStatus IEM payload type used by an intersection controller to announce the intersection entry graph. This graph provides the order of intersection entry. This DF shall be presented as specified in Appendix DE_generationTime The generation time of the IEM by the CICS component. This Data Entry (DE) shall be presented as DE_TimestampIts as specified in ETSI TS

119 [9]. The generation time is expressed as the number of milliseconds since T00:00:00:000Z as defined in ISO 8601 [22] DE_intersectionID The local-unique identifier of the intersection to which entry is requested, entry is cancelled or for which the entry graph is announced. This DE shall be presented as specified in Appendix5.3. Note: The strategy to assign identifiers to intersections is out of scope of the present document DE_intersectionEntryTimestampDelta The estimated entry time relative to the generationtime. This entry time is estimated by the vehicle requesting entry. This DE shall be presented as specified in Appendix5.3 in unites of 0.1 second relative to the generatimtime DE_inLane The identifier of the lane at which the requesting vehicle would like to enter the intersection. This identifier shall be equal to the identifier announced in the MAP message (see SAE J2735 [20])for the same lane in the same intersection. This DE shall be presented as specified in Appendix DE_outLane The identifier of the lane at which the requesting vehicle would like to exit the intersection. This identifier shall be equal to the identifier announced in the MAP message (see SAE J2735 [20])for the same lane in the same intersection. This DE shall be presented as specified in Appendix DE_priorityClass The priority of the requesting vehicle. Special vehicles like busses, fire trucks, ambulances, etc. may request intersection with a high permission. It is up to the intersection controller to give priority. This DE shall be presented as specified in Appendix

120 DE_stationTime A time relative to the generationtime. This DE shall be presented as specified in Appendix5.3 in milliseconds before the generationtime DE_stationRole The role of the station requesting intersection entry. This DE shall be presented as DE_VehicleRole as specified in ETSI TS [9] DE_stationType The type of the station requesting intersection entry. This DE shall be presented as DE_StationType as specified in ETSI TS [9] DF_stationPosition The position of the station at time stationtime. This DF shall be presented as DF_ReferencePosition as specified in ETSI TS [9] DF_stationSpeed The speed of the station at time stationtime. This DF shall be presented as DF_Speed as specified in ETSI TS [9] DF_stationheading The heading of the station at time stationtime. This DF shall be presented as DF_Heading as specified in ETSI TS [9] DF_stationlength The length of the station at time stationtime. This DF shall be presented as DE_VehicleLength as specified in ETSI TS [9].

121 DE_stationLonAccel The longitudinal acceleration of the station at time stationtime. This DE shall be presented as DE_LongitudinalAccelerationValue as specified in ETSI TS [9] DF_priorityGraph The relative order between vehicles given entry to the intersection by the intersection controller This DF shall be presented as specified in Appendix5.3. The Priority Graph is a list of priority vectors. Each priority vectors contains an ordered list of vehicle entries for each vehicle that requested and was given permission to enter the intersection. A vehicle entry higher in the list has priority over a lower vehicle entry in the same priority vector. Vehicles described by vehicle entries in different priority vectors are non-intersection and no right of way needs to be provided by vehicles corresponding to the vehicle entries. The prioritygraph is not describing the permission of vehicle that did not request permission to enter the intersection. The intersection controller is expected to schedule those legacy -vehicles using conventional methods like a traffic light DE_stationIdentifier The facilities-layer identifier of the ITS stations This DF shall be presented as DE_StationID as specified in ETSI TS [9]. 113

122 7.4 of Data Elements and Data Frames of CAM DF_itsHeader General message header of a CAM in common with other Application and Facilities-layer messages. This header contains a protocolversion, messageid and temporal identifier of the station sending the IEM. The protocolversion shall be set to 2. The messageid shall be set to 2. The stationid shall be set to the current facilities-layer identifier also used by the DEN BS. This Data Frame (DF) shall be presented as DF_ItsPduHeader as specified in ETSI TS [9] DF_automatedVehicleContainerHighFrequency High frequency container extension to the base standard for transmitting at high frequency (e.g. 10Hz) DFs and DEs for automated driving. This DF is transmitted when driving in a convoy, platoon or when being involved in a coordinated manoeuvre (e.g. cooperative lane change). This DE shall be presented as specified in Appendix DF_automatedvehicleContaienrLowFrequency Low frequency container extension to the base standard for transmitting at low frequency DFs and DEs for automated driving. This DF shall be presented as specified in Appendix DF_distanceToPrecedingVehicle The distance and its confidence between the front bumper of the vehicle that sent the CAM and the rear bumper of its preceding vehicle in the same lane. This DF shall be presented as specified in Appendix5.4. The distanceconfidence of this DF shall be the confidence bound of the 95% symmetric confidence interval of the distancevalue DE_drivingMode The driving mode engaged by the vehicle that sent the CAM. This DE shall be presented as specified in Appendix5.4. The value semi-automated shall be used if the automated lateral or longitudinal control, but not both, of vehicle are engaged. The value fully-automated shall be used if both automated

123 7.4.6 DE_automatedControl lateral and longitudinal control of the vehicle are engaged. Lists the automated vehicle control systems engaged by the vehicle that sent the CAM. This DE shall be presented as specified in Appendix5.4. The following fields shall be set if the corresponding conditions are met for the vehicle that sent the CAM: automaticlanechangeengaged: the automatic lane change system is engaged. convoyengaged: if the vehicle is driving in a convoy. platooningengaged: if the vehicle is driving in a platoon. lanekeepassistengaged: if the lane keep assist is engaged. caccenabled: if the CACC system is engaged DE_targetSpeed The target speed of the vehicle that sent the CAM. This DE shall be presented as specified in Appendix5.4 in units of 0.01 m/s DE_targetLongitudinalAcceleration The target longitudinal acceleration of the vehicle that sent the CAM. This DE shall be presented as specified in Appendix5.4 in units of 0.1 m/s DF_brakingCapacity The maximum braking capacity and its confidence of the vehicle that sent the CAM. This DF shall be presented as specified in Appendix5.4. The longitudinalaccelerationconfidence of this DF shall be the confidence bound of the 95% symmetric confidence interval of the longitudinalaccelerationvalue DE_targetDistanceToPrecedingVehicle The target distance between the front bumper of the vehicle that sent the CAM and the rear bumper its preceding vehicle in the same lane. This DE shall be presented as specified in Appendix5.4 in units of 0.1 meter. This DE shall be set if a target distance to the preceding vehicle is set. Otherwise, this DE shall be absent DE_targetDistanceToFollowingVehicle The target distance between the rear bumper of the vehicle that sent the CAM and 115

124 the front bumper of its following vehicle in the same lane. This DE shall be presented as specified in Appendix5.4 in units of 0.1 meter. This DE shall be set if a target distance to the following vehicle is set. Otherwise, this DE shall be absent DF_pathPrediction The predicted future trajectory of the vehicle that sent the CAM This DF shall be presented as specified in Appendix5.4. This DF is optional and shall be set when the future trajectory is predicted DE_groupID The platoon of convoy identifier in which the vehicle that sent the CAM is driving. This DE shall be presented as specified in Appendix DE_groupSpeed The set speed of the platoon of convoy. This DE shall be presented as DE_SpeedValue in as specified in ETSI TS [9] DE_predictedPathDeltaTime The time of a path point in the predicted trajectory of the vehicle that sent the CAM. This DE shall be presented as specified in Appendix5.4. This time is encoded as the difference in units of 0.01 seconds with the CAM reference time or previous predicted path point time for respectively the first and subsequent predicted path points DF_predictedPathDeltaPosition The predicted position of the vehicle that sent the CAM at a path point in the predicted trajectory. This DF shall be presented as specified in Appendix5.4. This position is encoded as the difference with the CAM reference position or previous predicted path point position for respectively the first and subsequent predicted path points DF_predictedPathDeltaPositionConfidence The predicted position confidence of a predicted path point position. This DF shall be presented as specified in Appendix5.4. The position confidence shall

125 be the confidence bounds of the 95% confidence ellipse of the predicted path point position. This position confidence is encoded as the difference with the CAM reference position confidence or previous predicted path point position confidence for respectively the first and subsequent predicted path points DF_predictedPathDeltaSpeed The predicted speed of the vehicle that sent the CAM at a path point in the predicted trajectory. This DF shall be presented as specified in Appendix5.4. This DF is optional and shall be set if the predicted speed is available. The deltaspeedconfidence shall be the confidence bounds of the 95% symmetric confidence interval of the deltaspeedvalue. This speed is encoded as the difference with the CAM speed or previous predicted path point speeds for respectively the first and subsequent predicted path points DF_predictedPathDeltaLongitudinalAcceleration The predicted longitudinal acceleration of the vehicle that sent the CAM at a path point in the predicted trajectory. This DF shall be presented as specified in Appendix5.4 in 0.1 m/s 2. This DF is optional and shall be set if the predicted longitudinal acceleration is available. The deltaaccelerationconfidence shall be the confidence bounds of the 95% symmetric confidence interval of the deltaaccelerationvalue. This acceleration is encoded as the difference with the CAM longitudinal acceleration or the previous predicted path point longitudinal acceleration for respectively the first and subsequent predicted path points DF_predictedPathDeltaLateralAcceleration The predicted lateral acceleration of the vehicle that sent the CAM at a path point in the predicted trajectory. This DF shall be presented as specified in Appendix5.4 in 0.1 m/s 2. This DF is optional and shall be set if the predicted lateral acceleration is available. The deltaaccelerationconfidence shall be the confidence bounds of the 95% symmetric confidence interval of the deltaaccelerationvalue. This acceleration is encoded as the difference with the CAM lateral acceleration or previous predicted path point lateral acceleration for respectively the first and subsequent predicted path points DE_deltaSemiMajorConfidence The difference of the semi major axis of a delta confidence ellipse. This DE shall be presented as specified in Appendix5.4 in 0.01m. The value 117

126 unavailable(4095) shall be used when the difference is unavailable. The value outofmaximumrange(1534) shall be used when the difference is equal or larger than meter. The value outofminimumrange(-512) shall be used when the difference is smaller or equals than 5.12 meter DE_deltaSemiMinorConfidence The difference of the semi minor axis of a delta confidence ellipse. This DE shall be presented as specified in Appendix5.4 in 0.01m. The value unavailable(4095) shall be used when the difference is unavailable. The value outofmaximumrange(1534) shall be used when the difference is equal or larger than meter. The value outofminimumrange(-512) shall be used when the difference is smaller or equals than 5.12 meter DE_deltaSemiMajorOrientation The difference of the semi-major axis orientation of a delta confidence ellipse. This DE shall be presented as specified in Appendix5.4 in 0.1 degrees. The value unavailable(4095) shall be used when the difference is unknown DE_deltaSpeedValue A difference in speed. This DE shall be presented as specified in Appendix5.4 in 0.1m/s. The value unavailable(16383) shall be used when the difference is unavailable. The value outofmaximumrange(255) shall be used when the difference is equal or larger than 25.5 meter. The value outofminimumrange(-255) shall be used when the difference is smaller or equals than 25.5 meter DE_deltaSpeedConfidence The difference of a speed confidence bound. This DE shall be presented as specified in Appendix5.4 in 0.1m/s. The value unavailable(255) shall be used when the speed confidence bound difference is unavailable. The value outofmaximumrange(63) shall be used when the difference is equal or larger than 6.3 m/s 2. The value outofminimumrange(-63) shall be used when the difference is equals or small than -6.3 m/s DE_deltaAccelerationValue The difference in acceleration. This DE shall be presented as specified in Appendix5.4 in 0.1 m/s 2. The value unavailable(161) shall be used when the difference is unavailable.

127 DE_deltaAccelerationConfidence The difference of an acceleration confidence bound. This DE shall be presented as specified in Appendix5.4 in 0.1 m/s. The value unavailable(102) shall be used when unavailable. 119

128 7.5 of Data Elements and Data Frames of a CSM DF_itsHeader General message header of a CSM in common with other Application and Facilitieslayer messages. This header contains a protocolversion, messageid and temporal identifier of the station sending the CSM. The protocolversion shall be set to currentversion(1). The messageid shall be set to 128. The stationid shall be set to the current facilities-layer identifier also used by the CA BS and DEN BS. This Data Frame (DF) shall be presented as DF_ItsPduHeader as specified in ETSI TS [9] DF_messageBody Payload of a CSM and consists of descriptions of detected objects This DF shall be presented as specified in Appendix DE_detectedObjects A sequence of detected object descriptions. This DE shall be presented as specified in Appendix 5.5 and shall consist of at least 1 detected object DE_detectionTime The time of object detection This DE shall be presented as specified as GenerationDeltaTimein Appendix 5.5 and Appendix The detection time is represented as the remainder in milliseconds of the current TimestampIts divided by DF_detectionSource TimestampIts represents an integer value in milliseconds since T00:00:00:000Z as specified in ISO 8601 [22]. The source of detection This DF shall be presented as specified in Appendix 5.5. The option unknown shall be used when the detection source is unknown. The option sensor shall be used if the detection source is a sensor (local or remote using communication).

129 7.5.6 DF_objectPosition The measured position of the detected object. The measured position is expressed in latitude and longitude according to WSG84 and its 95% confidence ellipse. This estimated position is not necessarily the reference position of an object in CAM and defined in ETSI TS [21]. The definition of the estimated position is out of scope of the current document. This DE shall be presented as specified in Appendix 5.5 and as DE_ReferencePosition as specified in ETSI TS [9] DF_objectType The measured type and accuracy of the detected object. This optional DF shall be presented as specified in Appendix 5.5. This DF shall be included when the objecttypevalue is available and includes: objecttypevalue denotes the measured object type. objecttypeconfidence denotes the accuracy of the measured objecttypevalue as a percentage. Otherwise, the value of objecttypeconfidence shall be set to unavailable DF_objectSpeed The measured speed and accuracy of the detected object. This optional DF shall be presented as specified as in Appendix 5.5 anddf_speed in ETSI TS [9]. This DF shall be included when the speedvalue is available and includes: speedvalue:denotes the measured object speed. speedconfidence denotes the accuracy for the 95% confidence level of the measured speedvalue. Otherwise, the value of speedconfidence shall be set to unavailable DF_objectHeading The measured heading and accuracy of the detected object. This optional DF shall be presented as specified as in Appendix 5.5 anddf_heading in ETSI TS [9]. This DF shall be included when the headingvalue is available and includes: headingvalue:denotes the measured object speed. headingconfidence denotes the accuracy for the 95% confidence level of the measured headingvalue. Otherwise, the value of headingconfidence shall be set to unavailable. 121

130 7.6 of Data Elements and Data Frames of a CSAM DF_itsHeader General message header of a CSAM in common with other Application and Facilities-layer messages. This header contains a protocolversion, messageid and temporal identifier of the station sending the CLCM. The protocolversion shall be set to currentversion(1). The messageid shall be set to 133. The stationid shall be set to the current facilities-layer identifier also used by the CA BS and DEN BS. This Data Frame (DF) shall be presented as DF_ItsPduHeader as specified in ETSI TS [9] DF_messageBody Payload of a CSAM and consists of either a speed request, speed advise or speed report. This DF shall be presented as specified in Appendix DF_speedRequestMessage A message to request a speed advice from the speed advising server. This DF shall be presented as specified in Appendix DF_speedAdviseMessage A message to respond by the speed advising server to a speed request by an ITS Station. This DF shall be presented as specified in Appendix DF_speedReportMessage A message to report the speed by an ITS Station to the speed advising server. This DF shall be presented as specified in Appendix DE_timestamp The generation time of the CSAM message.

131 This DE shall be presented as the DE_TimestampItsas specified in ETSI TS [9] DF_position The position for which a speed advise is requested in case of the SpeedRequestMessage or the reported position of the ITS Station in a SpeedReportMessage. This DF shall be presented as the DF_ReferencePositionas specified in ETSI TS [9] DF_heading The heading and corresponding 95% confidence level for which a speed advise is requested in case of the SpeedRequestMessage or the reported heading and corresponding 95% confidence level of the ITS Station in a SpeedReportMessage. This DF shall be presented as the DF_Headingas specified in ETSI TS [9] DE_advisedSpeed The advised speed in units of 0.01 m/s This DE shall be presented as the DE_SpeedValueas specified in ETSI TS [9] DE_relevantPolygon The sequence of geographical positions which describe the polygon in which the speed advice is relevant. The sequence shall be ordered according to their sequence in the polygon. The polygon is described by connecting subsequent geographical positions in this DE DE_speed The reported speed of the ITS Station to the speed advising server. This DE shall be presented as the DE_SpeedValueas specified in ETSI TS [9] DE_latitude The latitude value of a geographical vertex position This DE shall be presented as the DE_Latitudeas specified in ETSI TS [9]. 123

132 DE_longitude The longitude value of a geographical vertex position This DE shall be presented as the DE_Longitudeas specified in ETSI TS [9].

133 7.7 of Data Elements and Data Frames of the Common Data Dictionary AccelerationCapacity Descriptive Name AccelerationCapacity ASN.1 representation Definition Unit AccelerationCapacity ::= LongitudinalAcceleration ( WITH COMPONENTS { longitudinalaccelerationvalue(0..161), longitudinalaccelerationconfidence }) It indicates the maximum acceleration of the ITS-s in longitudinal direction and its confidence. The DF shall include: longitudinalaccelerationvalue: the maximum acceleration of the station in longitudinal direction. longitudinalaccelerationconfidence: the confidence bound of the 95% Gaussian distributed confidence interval. N/A AccelerationCapacityValue Descriptive Name AccelerationCapacityValue ASN.1 representation Definition AccelerationCapacityValue ::= LongitudinalAccelerationValue(0..161) It indicates the maximum acceleration of ITS-s in longitudinal direction. Unit 0.1 m/s BrakingCapacity Descriptive Name BrakingCapacity ASN.1 representation Definition Unit Distance Descriptive Name BrakingCapacity ::= LongitudinalAcceleration ( WITH COMPONENTS { longitudinalaccelerationvalue( ), longitudinalaccelerationconfidence }) It indicates the maximum deceleration of the ITS-s in longitudinal direction and its confidence. The DF shall include: longitudinalaccelerationvalue: the maximum deceleration of the station in longitudinal direction. longitudinalaccelerationconfidence: the confidence bound of the 95% Gaussian distributed confidence interval. N/A Distance ASN.1 representation Distance ::= SEQUENCE { distancevalue distanceconfidence } DistanceValue, DistanceConfidence Definition It indicates a distance and its confidence. 125

134 Unit DistanceValue Descriptive Name ASN.1 representation Definition The DF shall include: distancevalue: the distance value. distanceconfidence: the confidence bound of the 95% Gaussian distributed confidence interval. N/A DistanceValue DistanceValue ::= INTEGER {dotonemeter(1), outofrange(510), unavailable(511)} (0..511) It indicates a distance The DE shall be set to unavailable(511) if the distance is temporarily unknown. Unit 0.1 m DistanceConfidence Descriptive Name DistanceConfidence ASN.1 representation Definition DistanceConfidence ::= INTEGER { equalorwithindotonemeter(1), equalorwithindottwometer(2), outofrange(31), unavailable(32) } (1..32) It indicates the confidence bound of the confidence interval of the distance. The DE shall be set to unavailable(32) if the confidence bound is temporarily unknown. The DE shall be set to outofrange(31) if the confidence bound is larger than 3.1 meter. Unit 0.1 m GenerationDeltaTime Descriptive Name GenerationDeltaTime ASN.1 representation GenerationDeltaTime ::= INTEGER { onemillisec(1) } ( ) Definition Generation time. This value shall be set as the remainder of the corresponding value of TimestampIts divided by as below: generationdeltatime = TimestampIts mod TimestampIts represents an integer value in milliseconds since T00:00:00:000Z as specified in ISO 8601 [22]. Unit GroupID Descriptive Name ASN.1 representation Definition Unit ms. GroupID GroupID ::= INTEGER( ) Identifier of a convoy or platoon N/A

135 8 Appendix D: Duplicate Packet Detection for the Reliable Basic Transport Protocol Due to the retransmission mechanism of the Reliable Basic Transport Protocol (RBTP) (see Section 2.10), the RBTP component can receive one or more duplicate RBTP packets. It is the task of the RBTP component to detect such retransmissions and drop duplicate packets accordingly. In order to detect duplicate packets, the RBTP component keeps track of the sequence numbers that have been received for a particular source node using a sliding windows principle. The highest received sequence number marks the head of the window whereas the size of the window is fixed. For each sequence number falling into the window, a receiver is keeping tracker of whether a packet with the particular sequence number has been received before. The duplicate packet detection algorithm is formally described in the following and is checked on the reception of a RBTP packet as described in Section : 1 -- P is the received RBTP packet 2 -- SN(P) is the sequence number in the received RBTP packet 3 -- SN(SO) is the last received sequence number from source SO 4 -- SN_MAX is the maximum sequence number = 2^ WIN_LEN is the window size = SN_MAX/ RCVD(SN) returns whether the received sequence number has been received before or not 7 8 SO_WIN_TAIL<- (SN(SO) - WIN_LEN + SN_MAX + 1) MOD (SN_MAX + 1) 9 P_WIN_TAIL <- (SN(P) - WIN_LEN + SN_MAX + 1) MOD (SN_MAX + 1) IF ( (SN(P) > SN(SO) AND SN(P)-SN(SO) <= SN_MAX/2) OR 12 (SN(P) < SN(SO) AND SN(SO)-SN(P) > SN_MAX/2) ) THEN 13 IF SO_WIN_TAIL < P_WIN_TAIL THEN 14 FOR SN in [SO_WIN_TAIL, P_WIN_TAIL> 15 RCVD(SN) <- FALSE 16 ENDFOR 17 ELSEIF P_WIN_TAIL < SO_WIN_TAIL THEN 18 FOR SN in [SO_WIN_TAIL, SN_MAX] 19 RCVD(SN) <- FALSE 20 ENDFOR 21 FOR SN in [0, P_WIN_TAIL> 22 RCVD(SN) <= FALSE 23 ENDFOR 24 ENDIF 25 SN(SO) <- SN(P) 26 RCVD(SN(P)) <- TRUE 27 RETURN NOT_DUPLICATE 28 ELSEIF ( (SO_WIN_TAIL<= SN(SO) AND (SN(P) <= SN(SO) AND SN(P) >= SO_WIN_TAIL)) OR 29 (SN(SO) < SO_WIN_TAIL AND (SN(P) <= SN(SO) OR SN(P) >= SO_WIN_TAIL)) ) THEN 30 IF RCVD(SN(P)) THEN 31 RETURN DUPLICATE 32 ELSE 33 RCVD(SN(P)) <- TRUE 34 RETURN NO_DUPLICATE 35 ENDIF 36 ELSE 37 RETURN OUTDATED 38 ENDIF 127

136 9 Appendix E: Traffic Classes for ITS-G5D The traffic class identifier (TC ID) provides a way to prioritize between data traffic at the network & transport layer [23]. The TC IDs for ITS-G5 CCH channels and their mapping to the access categories of ITS-G5 are defined in Section 8 of ETSI TS [6]. In AutoNet2030, we propose to extend this mapping with TC IDs for the ITS-G5D channels. Table 40specifies the proposed mapping in AutoNet2030 between traffic class identifiers and the ITS-G5 access categories for ITS-G5D channels and their intended use. Table 40 Traffic Classes for ITS-G5D TC ID AC Channel Intended Use 5 AC_BE SCH5/SCH6 CAM 6 AC_BK SCH5/SCH6 Other traffic data