Keywords

1 Introduction

Intelligent Transportation Systems (ITS) embrace a wide variety of communications related applications intended to increase travel safety, minimize environmental impact and improve traffic management. In Europe the most robust ITS development architecture is the ETSI C-ITS (Cooperative ITS) framework [1, 2]. C-ITS is, at its core, a collection of technologies and standards that regulate the information exchange between road users and infrastructure. However, its deployment faces many important problems still unresolved, such as legal, organisational, administrative, governing aspects, technical and standardisation aspects as well as implementation and procurement issues.

In order to solve some of these issues, a joint initiative of European Member States and road operators for testing and implementing C-ITS services aiming to achieve cross-border harmonisation and interoperability was created. This is known as the C-Roads Platform [3, 4]. Within the C-Roads framework, the setup and operation of the different test pilots is the responsibility of each member state, in Scandinavia in particular, the official C-Roads partner is the NordicWay Project. NordicWay is a C-ITS pilot project that enables vehicles, infrastructure and network operators to communicate safety hazards and other information from roads in the Nordic countries between different stakeholders. The current version of the pilot is NordicWay3 with the last activity report for the previous version being available since the end of the last year [8].

In this paper we introduce our implementation of a NordicWay standard compliant vehicular (V2X) communication system. This system will be used by emergency vehicles in order to request traffic light priority at signalized intersections by interacting with the specific region’s traffic light controller (TLC) [6].

2 C-Roads/NordicWay Framework

2.1 C-ITS Communication

Usually, when we talk about vehicular networks (VANETs) we assume that the communication is either vehicle-to-vehicle (V2V) or vehicle-to-infrastructure (V2I). That is, vehicles send messages directly to other neighbouring vehicles or to road side units (RSUs) which relay messages to a larger area. This is what is normally referred to as ITS-G5. However, in the C-Roads framework, the users are also allowed to communicate directly with service providers using any communication technology of their choice (IP, WiFi, etc.). These service entities then interact with the rest of the network using a specific IP-based channel called the basic interface (BI) whose purpose is to provide interoperability between different applications and service providers.

2.2 Basic Interface

In C-Roads (and NordicWay), the BI is an IP-Based information sharing channel/protocol that allows interaction between C-ITS actors (and potential third parties). It is independent of any deployment model that Member States or C-ITS actors choose to deploy. The data is exchanged using the Advanced Message Queuing Protocol (AMQP) which provides basic transport level security (TLS) and also allows for the exchange of non C-ITS messages. Optionally, this exchange may involve the use of an intermediary message broker.

2.3 AMQP Protocol

Is an Application Layer protocol that focuses on process-to-process communication across IP networks. It enables client applications to communicate with messaging middleware brokers. Thus, it can be seen as an analogue to HTTP but for publisher/subscriber transactions instead of request/response. AMQP is also payload agnostic which allows different payload formats to be carried.

2.4 NordicWay Interchange Node

The main goal of NordicWay is to establish a solution that allows for cross-border continuity and interoperability of the C-ITS use cases deployed in Finland, Sweden, Norway and Denmark. Thus, there was a need for a mechanism that could enable the information exchange between different service providers, and between service providers and the traffic data providers (e.g., in case the driver is driving abroad).

The mechanism agreed between the partners of the project was the use of an intermediary NordicWay server, which is a central hub that facilitates the interchange of messages of interest between countries, service clouds and traffic monitoring centers (TMCs). This server is referred to as the Interchange and the architectural model is shown in Fig. 1.

Fig. 1.
figure 1

NordicWay interchange architecture

Full size image

The architecture of the Interchange is based on the following two main requirements: It must allow inter-operable exchange and crowd sourcing of digital traffic information related to traffic safety like hazards, road works, etc.; and it must be lightweight, primarily capable of providing secure message routing between actors through standardized interfaces.

It is important to note that communication with the interchange works via a publisher and subscriber system (as seen in Fig. 2) in which users subscribe to specific message queues (also called topic exchanges) and the interchange acts as an AMQP message broker. This AMQP broker is based on protocol version 1.0 and is implemented (in the NordicWay2 version) using an Apache QPID server.

An important building block of the interchange is its Geo-lookup component, implemented using PostGis, this allows the delivery of messages to subscribers located in specific geographical areas (from a city to a single intersection) helping ensure that the information reaches only the affected vehicles (for example in case of a road accident or a malfunctioning traffic light) while also providing transport layer security across countries.

In summary, the Interchange Application performs the following functions: Reads and validates the AMQP messages written by the data producers; performs Geo-lookup of the valid messages and creates multiple copies of the same AMQP message depending on its results; finally, it pushes the messages to the different topic exchanges which are listened to by the subscribers.

Fig. 2.
figure 2

Traffic light priority message flow

Full size image

3 Messaging System

3.1 SAE Messages

In order to implement the Traffic Signal Priority application compliant with the NordicWay specifications the system needs to be able to send and receive three specific message types: the Signal Request Message (SRM), the Signal Status Message (SSM) and MAP Messages. The specific format and content of these messages is specified in the SAE J2735 standard for vehicular messages [7].

The basic flow of the implemented messaging system (shown in Fig. 2) can be described as follows:

  • First, an emergency vehicle equipped with our messaging interface is driving towards a signalized intersection. The vehicle is subscribed to the Interchange’s MAP publishing application [8] and is able to receive periodic MAP messages containing the geometric information of the signalized road infrastructure.

  • The Interchange is able to determine which specific MAP message a vehicle receives using the broker’s Geo-lookup capabilities. Thus, a vehicle only receives the MAP message relevant to the signalized intersections it is approaching to.

  • The vehicle decodes the MAP message and runs a trajectory matching algorithm in combination with its GPS route data in order to determine on which specific lane is going to arrive to the intersection.

  • When the matching completes, the vehicle builds a SRM and sends it to the TLC through the interchange containing the required information (Intersection ID, Vehicle ID, Estimated Time of Arrival (ETA), Approach Lane, etc.). Then, the interchange ensures message delivery to the correct TLC.

  • SAE J2735 messages are encoded using the ASN.1 interface description language with Basic Packed Encoding Rules (PER) and thus must be first wrapped around an AMQP message before sending to the Interchange.

  • The vehicle then waits and periodically receives SSMs containing the status of the request response (e.g. processing, accepted, rejected, etc.) and then adapts accordingly.

  • It is important to note that the SSMs sent from the TLC also go through the same process of ANS.1 encoding and AMQP wrapping but the publisher/subscriber roles are swapped between the TLC and the emergency vehicle for this exchange.

  • If the ETA to an intersection changes during the traffic maneuver, the SRM must be updated and resent to the TLC in order to keep it as active, otherwise, the request will expire before crossing the intersection.

The NordicWay project partners require that emergency vehicles using the traffic signal priority service send their SRMs in bunches (generating them from a list of intersections along their routes) in order to packet them together and generate what is know as a green wave in which the intersections along the route are sequentially turned green as the vehicle advances making the system operation more efficient.

Fig. 3.
figure 3

California test bed intersection map

Full size image

3.2 Preliminary Results

Since there is no MAP data readily available from the Swedish NordicWay Pilot yet, we decided to use data from the California Connected Vehicles TestBed [5]. Then, we built a simulated version of the Interchange using the same Apache QPID technology in which the NordicWay2 Interchange version is based on [8].

We were able to simulate a sample trajectory for an emergency vehicle using real time GPS data obtained from the Mapbox SDK (Fig. 4) traveling back and forth through three real intersections (see Fig. 3) while requesting traffic signal priority via the Interchange. The average trip time between these intersections ranges from 5 to 10 min depending on traffic conditions.

We also simulated the TLC side of the communication by sending SSMs with different responses to the requesting vehicle in order to test the messaging system encoding and decoding of SAE messages. The results are extremely promising, the system is able to decode geographic data from MAP messages and generate adequate SRMs on-demand using trajectory matching with real time navigation data. By using an adequate MAP database it is also possible to generate a green wave using trajectory matching on a sequence of consecutive intersections.

Fig. 4.
figure 4

Test trajectory GPS data

Full size image

Simulations show that providing the emergency vehicle with green phase at signalized intersections reduces average trip time by approximately 20% whilst increasing traffic safety by reducing the risk of collisions. Finally, the emergency vehicle can adjust its trajectory according to the received SSM status responses received from the TLC, while simultaneously, it can also update the TLC on unexpected trajectory changes by sending new SRM requests, updates or cancellations as needed.