V2X Software Development Kit

A Vehicle Ad Hoc Network (VANet) is an ephemeral network spontaneously created by a collection of connected vehicles in proximity to each other or in proximity to a similarly connected Roadside unit (RSU). The communications are generically referred to as V2V for Vehicle to Vehicle communications, V2I for Vehicle to Infrastructure communications, or, when both are operating together, V2X communications.

There are many proposed applications of V2X communications, the Connected Vehicle Reference Implementation Architecture details over 100 such applications. Communication to road side infrastructure is introduced when a traffic management organization installs Road Side Units (RSU) to monitor intra vehicle communications and use that information to act locally sending messages to connected vehicles or to act to manage the road network aggregating information from multiple road side units in an urban or regional traffic management center.

The use-cases for testing the applications of VANets in simulation include:

• Giving vehicles greater awareness of the presence and intentions of other vehicles in close proximity and evaluating the effects of the changes in vehicle behavior in response to that information.
• Making vehicles aware of local congestion on their immediate forward route and evaluation of alternate strategies.
• Implementing active collaboration between vehicles.
• Implementing network management strategies based on the rich data derived from connected vehicles.

In all cases, the simulation can be used to study the effect of the initiative under circumstances which include varying the quality and range of communications and the penetration of connectivity into the vehicle fleet.

Communications Channels

Simulation of a V2X communications network to accurately reproduce the transmission of every packet of data, to model the channel contention, the data encapsulation in routing and connection protocols, and to model the electromagnetic effects of the urban landscape on transmission is a complex task which potentially requires significant computing resources. The principle behind the Aimsun Next V2X SDK is to focus on the application of V2X communications as realized in the actions of a Traffic Management Center, the Road Side Units and the individual connected vehicles.

The V2X Systems Development Kit (SDK) included in Aimsun Next therefore implements the components of a communications systems as a set of customizable modules to manage the transmission and reception of V2X messages. The V2X channels simulate the transmission medium, in effect the radio technology in use, and the On Board Units in vehicles and the Road Side Units situated in the network simulate the transmission modules. The default implementations of these V2X components is a simplified representation of reality, for example, packet losses in a radio broadcast are simulated with a stochastic probability rather than by actually evaluating which particular packets are in contention. Similarly, the act of joining and leaving a VANet is simplified by assuming it is simply a function of range rather than being established by a negotiated membership protocol. If the more complex aspects of VANets are vital to the study being undertaken, then the design of the V2X SDK allows the default V2X components to be substituted with user supplied components and API code written to provide the capability required for the study.

Message Types

V2X applications are also a developing area and while there are some message types that have been standardized by EU and American agencies, there are many more in development. The V2X SDK therefore implements a generic message class which can be customized by the SDK programmer to create a specialization of that class which implements the new message type to be developed in the simulation. Once the new message type has been developed and added to list of available types, it appears in the message type lists of the user interface and is distributed to vehicles and road side units in range of the transmitting vehicle or RSU.

V2X SDK Components

The components of the V2X SDK in Aimsun Next are:

• Message Type: The types of messages passed between vehicles and the RSUs. The V2X SDK implements some of the common standardized message types and some generic messages. When new types of message are required for experimental applications, these can be added to the V2X SDK using the new Message methods in the V2X API and passed between vehicles and RSUs in the same way as the existing message types.

• Channel: The communications channel is the simulated representation of the radio hardware and protocols that provide communications between vehicles. Typically this might be a 5G Cell based communications network, or a Wi-Fi based protocol such as IEEE 802.11p. The default channel object in the V2X SDK is a simple range based message passing object with a stochastic probability of successful transmission. If the proposed modeling exercise requires that more detailed simulation of the communications channel is required; i.e. the protocol that determines how vehicles join and leave a VANet or how signal strength varies with urban geography, then a more complex channel can be programmed and substituted for the basic channel.

• On Board Unit: The OBU provides the receiver and transmitter in a vehicle, with the proportion of vehicles equipped with each type of OBU defined in the Vehicle Type. Each OBU is capable of using one or more channels to receive one or more message types on each channel.

• RoadSide Unit(RSU): The RSU is the "I" component of the Vehicle to Infrastructure (V2I) communications network. An RSU has a physical location, connections to road network nodes, a set of channels it is able to use, and a set of message types it is able to transmit and receive. It can also communicate with a Traffic Management Center as one of a network of similar devices.

• Traffic Management Center: The Traffic Management Center is the integrator of the data from multiple RSUs and the initiator of co-ordinated signal control and traffic management actions. It communicates to the RSUs via a separate channel type which might now be based on wired links or dedicated radio channels. This is probably a different channel to the VANet channel.

The relationship between the components is shown below. The multiple OBUs and RSUs exchange data via a channel using pre-defined message types. The RSUs can also exchange data with a TMC on a different channel type. Depending on range and connectivity, vehicles then form ad-hoc VANets based on a common channel.

Data Flow

A typical data flow in a model developed to assess traffic management techniques might be:

1. Vehicles exchange data between themselves and an RSU in a local area using standardized defined messages (i.e. CAM, BSM) using communications channels shared between the type of OBU on the vehicles and the RSU.
2. The RSUs perform some local processing and issue both standardized messages in their local area (i.e. DENM) on the same vehicle oriented communication channels and also some vendor specific aggregated messages to the TMC on other channels dedicated to management communications.
3. The TMC evaluates the information from multiple RSUs. Its actions are relayed back to the equipped vehicles in the traffic network via the RSUs and also implemented using signal control and ITS.
4. The "Vehicle Rules Engine" takes the V2X data from other vehicles and from the RSUs and adds this to the vehicle's existing knowledge of the traffic network taken from traffic signals, ITS, and from the vehicles in its vicinity. The Rules Engine then influences the vehicle's behavior.

## Message Types

The Message Types are a set of pre-defined V2X messages that can be exchanged between vehicles and RSUs. The initial list provided in the V2X SDK covers the more common established standards, but inevitably as V2X developments are proposed and must be tested in simulation, new message types will be developed. These new types can be programmed by the modeler using the V2X API, to customize an abstract message type, and in making it concrete, to provide a format for the message type, and a set of functions to create the message to be sent and to parse messages of this type.

The supplied set of messages is:

• Cooperative Awareness Message (CAM): The Cooperative Awareness Message is defined by the European Telecommunications Standards Institute (ETSI) in standard TS 302 637-2. The CAM message provides information about the presence, activity, and position of "ITS stations" which might include RSUs as well as vehicles.The message consists of one or more containers of information: These include a list of low frequency containers for static information, high frequency containers for dynamic information, and a set of application specific containers for specialized information (i.e emergency vehicles). A CAM message is generated 1 to 10 times a second depending on the activity of the ITS station.

• Decentralized Environmental Notification Message (DENM): The Decentralized Environmental Notification Message is defined by the European Telecommunications Standards Institute (ETSI) in standard 302 637-3 A DENM message contains information about events or conditions that have a potential impact on road safety or traffic conditions. An event is described by an event type, an event position, a detection time, and a time duration. A DENM message is typically sent after ITS stations have detected reportable conditions either individually, or after a station has aggregated data from the CAM messages from other vehicles. For example, a DENM message can be sent to inform about congestion in an area, a stationary vehicle or a lane closure, after information from multiple CAM messages has been received and processed.

• Signal Phase and Timing Extended Message (SPATEM): The Signal Phase and Timing Extended Message is defined by European Telecommunications Standards Institute (ETSI) in standard 103 301. The SPATEM message provides information about the signal timings and predicted times of change. The SPATEM message is accompanied by a MAPEM message to give topological information.

• MAP Extended Message (MAPEM): The MAP Extended Message is defined by European Telecommunications Standards Institute (ETSI) in standard 103 301. Its purpose is to define road and lane topology in the vicinity of a junction and provides the data required to decode a SPATEM message.

V2X Channel

A channel represents a communications protocol used to pass information between vehicles and RSUs. Typically this is based on short range Wi-Fi technology such as IEEE 802.11p or LTE cell based transmission.

In practice there are protocols for joining and leaving a data network which a member of the network must follow There are also protocols to handle channel congestion which affects latency and packet loss rates when the channel is busy and messages conflict with each other and are re-transmitted. These protocols are specific to each type of channel technology. Similarly, in physical transmission of data packets, there are different attenuation factors for different technologies as transmissions pass through buildings or across landscapes. Modeling this level of detail is expensive in computer resources and in many applications, that level of detail will not be appropriate.

Hence in the default channel object coded in the V2X SDK the characteristics of a channel are simplified to focus on reliability and range of communication expressed as:

• Latency: The delay in packet transmission.

• Range: The range of transmission, in effect determining which vehicles communicate with each other. The range is defined as the measured distance between vehicles, regardless of their connectivity by road network and regardless of any obstacles that might affect transmission.

• Packet Loss: The percentage of packets which are not received. If this value is greater than 0%, then this value gives the probability of a packet being discarded, to simulate non- delivery.

Detailed simulation of detailed packet contention, retransmission protocols, or utilization based degradation is not implemented in this default communications channel. If this level of detail is required in the simulation, then a new channel type can be added to the V2X SDK using the V2X API to develop channels with more complex algorithms to determine the transmission characteristics and to take into account existing radio traffic levels, the effect of urban buildings and aerial placement.

Create a New Channel

A new channel using the default V2X SDK channel type can be created from the Project menu. Select Project > New > V2X > Channel.

Different channels of this type can be created for different applications, each of which can carry a different set of message types.:

• Short range, high loss:- Radio V2V communications in a crowded urban area.
• Long range, zero loss:- Land line based communications between RSUs and the TMC.

A new channel will be created in the Channels folder in the V2X section of the Project Window.

Channel Settings

To edit a channel, double-click on it to open the channel editor and edit its name and its transmission characteristics: latency, range, and percentage packet loss.

Vehicle On Board Unit

An On Board Unit (OBU) is the simulation representation of the transmitter/receiver in the vehicle, it is the link between a vehicle and the messages it transmits and receives. An OBU can connect to multiple channels and relay different message types on each channel.

A new OBU can be created from the Project menu and edited to specify which channels and messages are available. If a channel is ticked in the OBU editor, and selected from the list of ticked channels in the list, then message types can be selected for that channel.

The OBU is linked to the vehicle type in the Vehicle Types Editor, V2X Tab where the proportion of vehicles of each type, with each OBU is specified.

Road Side Unit

A Road Side Unit (RSU) is a physical device which communicates through the same channels as the vehicle OBUs and exchanges the same messages, but is anchored at a specific location and has a defined range of communication. Communications are received from vehicles equipped with a compatible OBU which are currently within the RSU's defined area. An RSU can be linked to one or more nodes in the network so that the API code attached to each RSU is then able to access the nodes specifically attached to this RSU.

Creating and Locating an RSU

An RSU is created using the RSU tool. Select the tool, click on the 2D map to define the location of the RSU and draw out a circle to the required radius. Once created, position of the RSU can be adjusted by selecting the center point and moving it and its range by selecting its circular boundary and resizing it.

Editing an RSU

The RSU editor allocates channels and messages to the RSU in the same way as the OBU for a vehicle. These channels and messages define the data exchange between the vehicles and the management infrastructure. Note that the set of messages exchanged between RSU and vehicles is not necessarily the same set as those exchanged between vehicles.

The connections tab of the RSU lists the objects that are connected to the RSU. Objects can be added by using the Connection Tool or by clicking New, then selecting a the target for the link in the 2D map window. An RSU can be linked to:

• A Node
• A Detector
• A Variable Message Sign (VMS)

RSU Connections

Traffic Management Centers

A Traffic Management Center (TMC) is an aggregator of information received by a set of RSUs. Its role is to process data from the RSUs and manage the network through V2X messages that it instructs an RSU to relay, or by creating conventional ITS Traffic Management actions.

A TMC is created from the Project: New: V2X menu and edited by right clicking on its entry in the V2X folder in the Project Window. The TMC has no visual representation or location in the Aimsun Next 2D window. A TMC is a control center which is not required to be in the modeled area; it might even be cloud-based, and therefore exist solely in the Project Window for the model and in the API.

The TMC Main Tab edits the list of channels and messages in the same way as for the OBUS and the RSUs to define the common channel and messages that form the communications between the RSUs and the TMC. The Road Side Units Tab is used to specify which RSUs are linked to this TMC and hence which RSU data will be relayed to this TMC.

If a Traffic Management Center is to be included in a scenario, it must be selected in the scenario editor in the Traffic Management Center field.

Running a simulation with V2X

As a simulation is run, vehicles will join and leave VANets and connect, disconnect, and reconnect with other vehicles and with RSUs. To observe which vehicles are connected, a dynamic label can be attached to a vehicle to show the "Connected Objects" in its attributes. Alternately a View Mode can be created to show which vehicles have active connections using the attribute and, depending on the activity programmed by the rules engines in the API, what the vehicles are doing based on attributes created within that API.