Architectural design
Information streams
The information streams in the Mobilidata environment are based on, but not entirely the same as, the standards/protocols used by C-Roads, Talking Traffic, Neutral Server and others. Where it is essential or possible in providing the value needed, the original protocols are extended with specific arguments. These additional arguments are proposed to become part of the standard itself.
The most important part in the information chain is the Mobilidata Interchange, via which public information providers, External information providers ( e.g. the neutral server(s)) and road infrastructure (e.g. intelligent traffic lights) can interact with the service providers for end-users. The interchange (following C-Roads) is working with two interfaces: • MI interface. This is an extended, but compatible, version of the C-Roads “Basic Interface” (BI), which is in essence a metadata envelope around standard ETSI or DatexII messages being exchanged using the AMQP protocol; • II interface. This “Improved Interface” is for communicating with other mobility environments about offered capabilities, allowing actors in the information chain to and has the possibility to automatically adjust to the capabilities of an Interchange which they interact with.that other environment.
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.
Technology
Concepts
The overall Mobilidata system architecture is mainly based on two main technological concepts.
- Interchange (taken over from C-Roads)
- Intelligent traffic light control installations (iVRI, taken over from Talking Traffic)
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, able to exchange almost every type of message, and especially useful for the small mobility messages used in the Mobilidata environment (e.g. ETSI C-ITS messages). The communication is IP-based.
As standard, AMQP uses properties for internal administrative purposes, additionally, an application can add specific metadata (application properties) as well. Within C-Roads, there is a standard set of metadata defined (the Basic Interface (BI)) which is, for example, not aware of road user feedback streams or service provider specific. For this reason, there is an extension on this metadata in the application properties defined and therewith a new standard: The Mobilidata Interface (MI). So in short, the MI interface is a superset of the BI interface defined by C-Roads.
The improved Interface is used for detecting the remote's interchange capabilities. No additional features have been defined. This means that the Mobilidata II interface is identical to the II interface of C-Roads.
Access to the AMQP bus is per token-based authorization and allowlisting. A service provider can read or write only in areas where it has specific rights for. In this way, service providers are strictly separated and only offer services agreed on.
Intelligent traffic lights
Intelligent Traffic Lights (iTLC), or iVRI (as they are referred to in Talking Traffic which originally defined them), 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 therefore authorized vehicles, such as emergency vehicles.
- send the geographical layout, actual and upcoming signal group statuses including expected timings and priority request confirmations to the users nearby;
Every iTLC consists of three components:
- TLC, traffic light ontroller. This component takes care of the actual steering of the physical lights and has a standard ruleset (Vplan) of light switching in fixed order.
- ITS. This is the logic for influencing the fixed switch pattern, based on traffic offering, priority and specific rules set by the road administrator. This component will create the MAP and SPAT messages for thegeographic layout and light status.
- RIS, Roadside ITS Service. This component is the communicator with the remote world. Within Mobilidata, the RIS is communicating with the central hub, called Traffic Light Exchange (TLEX).
Whereas all iTLC are connected to the TLEX, this TLEX is connected to the MI as a special information provider in order to communicate with end-users. The speciality is given in the fact that the iTLC communication is bi-directional. Traffic is providing postion and priority messages.
Protocols
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 underlying concern for the overall Mobilidata system and its parts. After careful consideration, it was decided that the Mobilidata approach to security will adopt a two-staged approach. As designed today, the Mobilidata system architecture does not contain any usage of geo-casting network protocols on top of MAC-layer packet broadcasts, since deployment of short-range communication (ITS-G5, LTE-V2X) is not in the scope of the program. The Mobilidata system architecture can hence be seen as a rather classical ICT or IoT ecosystem. It is composed of a rather limited number of well-known services and applications which all interact with each other using the standard IP stack and in a connection-based manner. Based on thorough analysis of the PKI requirements for C-ITS in Flanders, it was decided by the Mobilidata program to base the security approach of its first stage 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 root. Hierarchical coupling with more slave systems is possible. - Binding Requirements;
New components shall only be allowed to connect to the Mobilidata system architecture deployment, once trust in them has been established through the verification of compliance with all so-called "binding requirements". These requirements will determine which prerequisites should be fulfilled by a component before it can be trusted to participate in the Mobilidata ecosystem.
Verifying this will require thorough testing activities, both on a component, and on a system level. These tests have to be performed with
the collaboration of the other participants already present in an active Mobilidata deployment. Their results need to be approved by a governing
body representing the whole Mobilidata program. No participant of the Mobilidata deployment will be allowed to connect to any 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 will be established in all components, and in all connections between them. It realizes the following security characteristics for the entire deployment:
- Authentication;
- Authorization;
- Confidentiality;
- Integrity.
After the TLS connections have been 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 requires 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 for the establishment of the TLS tunnels. Such trusted CA's 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.
If throughout the deployment of Mobilidata, indications are observed that this approach does not guarantee the secure operation of the ecosystem sufficiently, the detailed design of stage 2 will be initiated. That extension would add a signing operation on the application layer, signing every individual application layer message when it is created, using ETSI C-ITS certificates. Since this approach could potentially add a significant overhead in terms of computational load (asymmetric key signing operation needed for every message) and bandwidth consumption, while the current assessment is that stage 1 already covers all required security characteristics, this second stage was deliberately not yet included in stage 1.
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 will need to sign the appropriate Data Processing Agreements (DPA) with their peers as part of the binding-requirements introduced in this chapter. This way, it can be guaranteed that the consent given by end users regarding the processing of their personal data will not be infringed through the Mobilidata deployment. Furthermore, for all components, it will be required that access management is implemented in a sound manner, and that all used cloud platforms and data storage are physically located in the EU.
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.
