Architectural design
Information streams
The information streams in the Mobilidata environment are based on (but not identical to) the standards and protocols used by C-Roads, Talking Traffic, Neutral Server and others. Additional information is provided alongside the original protocols to increase value as needed. This additional information should ideally become part of the standard itself.
The most important link in the information chain is the Mobilidata Interchange. This interchange allows public information providers to interact with external information providers such as neutral servers and road infrastructure (e.g. smart traffic lights) for the benefit of end users. The interchange (following C-Roads) uses two interfaces:
- MI interface: this is an extended but upwards compatible version of the C-Roads Basic Interface (BI), which is in essence a metadata envelope that allows for the exchange of standard ETSI or DatexII messages using the AMQP protocol
- II interface: this improved interface is used to communicate with other mobility environments about available capabilities, to which players in the information chain can automatically adjust
Architecture in detail
Above mentioned information streams are processed through a set of systems, as presented in the following archtectural overview:
The architectural overview is more indepth explained in next paragraphs.
Mobilidata has also released a whitepaper about its architecture, explaining it in even more detail then described here on this webpage. This detailed whitepaper can be downloaded here. Furthermore, the original .png file of the architecture also displayed on this webpage can be downloaded here.
Technology
Concepts
The overall Mobilidata system architecture is based on three main technological concepts.
- Interchange (adopted from C-Roads)
- Intelligent traffic light control installations (iTLC, adopted from Talking Traffic)
- Extended vehicle information (adopted from Data for Road Safety)
These items are explained in the next paragraphs.
Interchange
Following the C-Roads architecture, the concept of an interchange is implemented in the Mobilidata environment. The interchange is primarily meant as a low-latency publish-subscribe service to exchange messages with the peripheral functionality. The message-based system is built on an AMQP bus structure that can exchange most message types and is particularly useful for the small mobility messages used in the Mobilidata environment (ETSI C-ITS messages). The communication is IP-based.
As standard, AMQP uses properties for internal administration purposes. An application can add specific metadata (application properties) as well. Within C-Roads, a standard set of metadata is defined (basic interface or BI) that does not take into account road user feedback streams or specific service providers. For this reason, a new standard was created: the Mobilidata interface (MI). The MI interface is a superset of the BI interface defined by C-Roads.
The improved interface is used to detect the remote’s interchange capabilities. No additional features have been defined, which means the Mobilidata II interface is identical to the C-Roads II interface.
Access to the AMQP bus is through token-based authorization and whitelisting. A service provider can only read or write in areas for which it has specific rights. In this way, service providers are strictly separated and can only provide the agreed services.
Connected traffic lights
Connected traffic lights are also regularly called Intelligent Traffic Lights (iTLC or iVRI as they are referred to in the Talking Traffic program that coined the term). These are traffic lights that:
- Adapt their control strategy to the actual presence of different modalities and policies of the road authority
- Adapt their control strategy to priority requests from authorized vehicles, such as emergency vehicles
- Send the geographical layout and current and upcoming signal group statuses (including expected timing and priority request confirmations) to the users in close proximity
All iTLCs consist of three (shared) components:
- RIS: Responsible for maintaining a local dynamic map of a junction and handling C-ITS messages for a junction. It also manages network-related security tasks, essentially connecting the iVRI to the outside world.
- Traffic Light Controller (TLC): Responsible for actuating the lights of the different signal groups (i.e. traffic lights) at an intersection and preventing unsafe situations (e.g. checking traffic light conflicts and intersection clearance times). This means the TLC is similar to a legacy traffic light controller.
- ITSApp: Responsible for controlling the traffic flow in an optimal way and determining the best signal phase and timing values to be sent to the Traffic Light Controller. Hence the ITSApp actually puts the extra intelligence in iTLC compared to a legacy traffic light controller.
The central Mobilidata service architecture of the iVRI is built around the Road Infrastructure Exchange. This component is responsible for distributing traffic light information. It is the single aggregation point that couples all deployed iVRIs with the Mobilidata Interchange, handling C-ITS messages to and from road users and traffic lights. A sub-component is the Traffic Light Priority Validator. That component performs basic checks on priority requests coming from emergency and high-priority road users (e.g. buses, cycling groups). The responsibility to grant these requests (taking current road conditions into account) lies with the ITSApp component of the iVRI.
Extended vehicle information
Many modern vehicles are equipped with telematics units. These units are able to send safety related traffic information (SRTI) across the mobile network to data collector-specific car manufacturers. The Data for Road Safety ecosystem (dFRS), an initiative of the auto industry and European governments, is responsible for collecting the anonymized and free data in neutral servers. For the latter, the ExVE and Sensoris protocols are used.
Protocols / Messages
In principle, the standard ITS protocols as defined by ETSI are leading in the service provider information stream. However, there are a few exceptions made for logical purpose.
Standard messages are used for all iVRI related and dynamically traffic conditions information streams. Details can be found in the descriptions of the individual use cases.
Standard protocols are:
| Protocol | Short Description |
|---|---|
| IVI(M) | Used for semi-static information (changed regularly but static from character) |
| DENM | Used for dynamically changing or occurring information of limited duration |
| MAP(EM) | Geographical layout of an intersection, with detailed information about signal groups and lane numbering |
| SPAT(EM) | Providing the most current traffic light status of an intersection as described in a corresponding MAP(EM) |
| CAM | Contains position and characteristics of a mobile entity |
| SR(E)M | Used for requesting priority or providing the direction in which to cross an intersection |
| SSM | Answer from the intersection as reaction on a SR(E)M |
Exceptions are made in static road information, like standard (fixed) road signs and parking information:
| Protocol | Short Description |
|---|---|
| Static data API, TN-ITS | The static data REST API, provides access to a minimal daily updated actual set of static trafficsign information in TN-ITS format. This service prevents the constant updating from the original sources. |
| DatexII v3 | There is no ETSI ITS protocol to serve the parking information stream, hence the standard DatexII v3 is used and published via the MI bus as well as the other standard messages. |
All the above-mentioned protocols are described in depth in the section Message Types.
Security and privacy
Security
Security is a vital concern for the overall Mobilidata system and its parts. As designed today, the Mobilidata system architecture does not use the geo-casting network protocols on top of MAC-layer packet broadcasts, since deployment of short-range communication (ITS-G5, LTE-V2X ) does not fall within scope of the program. The Mobilidata system architecture can therefore be seen as a rather classical ICT or IoT ecosystem. It is composed of a rather limited number of well-known services and applications that interact with each other in a connection-based way using the standard IP stack. Based on thorough analysis, it was decided by the Mobilidata program to base the security approach on the following two main security principles:
- Transport Layer Security (TLS): All connections between components will be secured using Transport Layer Security (TLS). The Certificate Authority of Flanders Government (vlaanderen.be) is used as a root. Hierarchical coupling with more slave systems is possible.
- Binding Requirements: New components are only allowed to connect to the Mobilidata system architecture deployment once trust in them has been established through the verification of compliance with all binding requirements. These requirements determine which prerequisites should be fulfilled by a component before it can be trusted to participate in the Mobilidata ecosystem.
Note: Verifying this requires thorough testing, both on a component and a system level. Their results must be approved by the Mobilidata governing body, which is part of the Flemish Agency for Roads and Traffic (AWV). No participant of the Mobilidata deployment is allowed to connect to a new component that has not been approved by this governing body.
For connecting to iTLC functionality (display light status, requesting priority) it is an obligation to connect to the official testbed and follow the proces for certification. Ensuring that compatability with installation software and presentation rules is in order. Specific information can be found at:
CROW Testbed (Dutch)
In this way, trust is established in all components and in all connections. The following security measures are hence taken for the entire deployment:
- Authentication
- Authorization
- Confidentiality
- Integrity
After the TLS connections are established using asymmetric cryptography, symmetric cryptography is used for the TLS data payload. This does not compromise latency or throughput of the information flow, nor does it require excessive computational power at aggregation points in the system architecture. This makes the proposed approach to security cost-efficient. It also only relies on the availability of trusted certificate authorities (CA) for issuing the X.509 certificates that are needed to establish the TLS tunnels. These trusted CAs are already widely available since TLS is used to secure practically all current internet services. This approach has no dependency regarding deployment lead times on the availability of novel public key infrastructure concepts. In fact, all X.509 certificates are acquired from the existing CA service of the Flemish Government.
Privacy
All components deployed within or coupled with Mobilidata must comply with the General Data Protection Regulation (GDPR). This implies that every party deploying components in the Mobilidata ecosystem must sign the appropriate Data Processing Agreements (DPA) with their peers as part of the binding requirements introduced in this chapter. This guarantees that the deployment of Mobilidata does not infringe upon the consent given by end users as regards the processing of personal data. Furthermore, sound access management must be implemented for all components and all cloud and data storage platforms must be physically located in the EU and compliant with the Schrems II Judgement.
Messages and encoding
Introduction
In line with the adoption of the C-Roads architecture, Mobilidata is as well using the type of messages and their encoding for transmission.
The messages are encoded, to gain two benefits. The first is to be consistent with the standard given, and the second is to compress the
message to minimal size. The last is important for the fact that there is always wireless communication.
In contrary of the C-Roads, Mobilidata will solely use IP-based cellular communication for:
- V2V: vehicle to vehicle
- V2I: vehicle to infrastructure
Besides the, elsewhere in this architecture mentioned, standard ETSI messages, there are some exceptions, which are not compatible with international C-Roads environments:
- DatexII v3 for parking information
in, for example, Talking Traffic, SPDP (JSON) messages are used for parking information - Rest-API interface for static data
The real static traffic signs are not provided via IVI, saving capacity on the central MI data-bus.
Transmission
One of the issues to take care of, is the mobile character of at least one of the recipients of information. Signal interference or other disturbing influences can cause data loss in transmission. For this reason, the messages must not be mis-interpretable or have something like a CRC-check.
The public standards JSON and XML (the latter used for DatexII) are not suitable, hence not compliant to the requirement of consistency. There is too much freedom in the way of providing the message values.
To solve the consistency and content-interpretation issues, Mobilidata uses the by ETSI selected ASN.1 UPER standard. Its structure is well-defined and offers the desired flexibility:
- Coding in ASN.1 UPER will compress the resulting message to a bare minimum, optimal for usage in wireless and not to trust networks.
- Consistency by design. All values are well-defined, whereas the message cannot be made or read with values out of specification.
No separate check or control mechanism needed to be sure that the message is received in good order.
The ETSI type messages are encoded inASN.1 UPER (unaligned packet encoding rule). This is one of the several encoding types within ASN.1: BER, CER, PER and UPER. Whereas BER is the most common encoding type (Active Directory is using this for coding certificates), UPER is less common. As a result, there are few suitable compilers for generating the (de-)coding source code available.
Application
Mobilidata messaging is according the European mobility solution standards, making cross-border exchanges and usage possible. And it is proven and maintained technology.
Whereas the Mobilidata system uses standardized messages, service providers can choose to translate the messages to a proprietary protocol for communicating with end-users, if that is more efficient in their solution. This can be logical when there is a specific appliance in the vehicle, running the service provider software.
Message structure
All ETSI defined messages have a somewhat similar structure, with variations based on the specific goal of the message. However, due to different originations, there are differences in naming conventions for similar variables. For example, in IVIM messages there are two types of traces defined. They are called awareness and relevance. In DENM the traces with the same functionality are called respectively position trace and history trace. Be aware of the fact that there is an exception on the rule. In MAPEM messages, all traces are given as relative points in meters distance instead of absolute or relative WGS84 co-ordinates. Unanimous are the definitions for the reference location: always defined in WGS84 with an integer, containing 7 decimals. (WGS84 51.1910931, 4.4213078 => ETSI 511910931, 44213078). Together with the reference position, messages are grouped within QuadKeys, as explained in next paragraph.
QuadKeys
Apart from splitting and/or sorting information to use cases and therefore, in principle also to standard protocol, there is another mechanism, used to create some order in the enormous amount of information.
To get only the information over what is in the neighborhood of a given location (e.g. where the vehicle is), there is an AMQP application variable called Quadkey.
The quadkey mechanism is a widespread standard for geographical information, dividing the world map in squares. Information can be filtered on the specific square you're in.
The mechanism is quite simple:
Take the mappable surface of the world and make it flat. Split this map in four evenly sized squares and number those squares from upper left to lower right with 0,1,2 and 3. Then, for example, take the upper right square and divide that again in four parts, and put the numbers in, in the same way. The directive to the lower right square of the smallest parts will then be 13. This mechanism can be continued further down. For practical reasons, in traffic related systems, the deepest level will be 18. This represents a square of about 150 by 150 meters.
The image below shows the derivation of the quadkey numbers, according to the levels:
Example: The Imec tower in Leuven is in quadkey 120202132303203112.
To get some better understanding, the following picture shows the
quadkeys level 10, covering all of Flanders.
