Anticipated cooperative collision avoidance (ACCA) service architecture with two connected vehicle original equipment manufacturers (OEMs). Vehicle OEM A communicates over the UDP/IP and HTTP protocols, and vehicle OEM B communicates over the TCP/IP with MQTT protocol.

Anticipated cooperative collision avoidance (ACCA) service architecture with two connected vehicle original equipment manufacturers (OEMs). Vehicle OEM A communicates over the UDP/IP and HTTP protocols, and vehicle OEM B communicates over the TCP/IP with MQTT protocol.

Source publication
Article
Full-text available
Vehicle-to-everything (V2X) communications enable real-time information exchange between vehicles and infrastructure, which extends the perception range of vehicles beyond the limits of on-board sensors and, thus, facilitating the realisation of cooperative, connected, and automated mobility (CCAM) services that will improve road safety and traffic...

Contexts in source publication

Context 1
... is important noting that this work focuses on the ACCA service architecture designed and implemented in the context of the 5GCroCo project [14]. Figure 1 shows the high-level architecture of the ACCA service, illustrating the communication interfaces between vehicles and the applications that are deployed outside of the vehicles. For the sake of brevity, we shall refer these applications as backend services hereafter. ...
Context 2
... achieve the low-latency benefits, the backend services are deployed close to end-users, i.e., at the edge clouds configured on the MEC infrastructure. Moreover, for the sake of simplicity, two edge cloud instances are depicted in Figure 1, where each edge cloud instance is operated by a different mobile network operator (MNO), e.g., MNO1 and MNO2, and these two edge cloud instances are connected to a centralised cloud deployment. There are two types of vehicles, i.e., OEM A and OEM B, which indicate two different automakers. ...
Context 3
... are two types of vehicles, i.e., OEM A and OEM B, which indicate two different automakers. A vehicle can communicate with the backend service at the edge cloud through an MNO using the preferred V2X communication protocol, i.e., either UDP/HTTP for vehicle OEM A or MQTT for vehicle OEM B, as can be seen in Figure 1. It is obvious that the use of MQTT for V2X communication is a natural choice when the backend services are also based on MQTT. ...
Context 4
... client may subscribe to topics specifying part of such path as well as using wildcards. In the ACCA service architecture that is depicted in Figure 1, the messages exchanged between different clients are belonging to either inQueue topic or outQueue topic roots. The inQueue topics (e.g., inQueue/v2x/denm/source_id/roi) are used to publish messages from OBUs towards the Edge Geoservers, and from the Edge Geoservers towards the TMS. ...
Context 5
... have considered three different test cases to validate the functionalities and V2X communication interfaces of the OBU. For each test case, we have used a different combination of V2X communication protocols between the OBUs connected with one edge cloud, which consists of an Edge Geoserver and an Edge MQTT broker, as depicted in Figure 1. The schematic representation of the test cases is shown in Figure 7 and the operation of the OBUs in each test case is described below. ...
Context 6
... have measured the application-level latency in two different scenarios based on the ACCA service architecture that is presented in Figure 1. In the first scenario, a road hazard is detected by one vehicle, and its OBU transmits a DENM message to the edge cloud application. ...
Context 7
... the first campaign, OBU 1 and OBU 2 were connected to the same edge cloud and the V2X information exchange between both OBUs did not traverse through the TMS. In the second campaign, the OBUs were connected to two different edge clouds, with OBU 1 and OBU 2 being connected to edge cloud 1 and 2, respectively, establishing the communication between both edge clouds through the TMS, as shown in Figure 1. ...

Similar publications

Article
Full-text available
Cooperative intelligent transport systems (C-ITS) are expected to considerably influence road safety, traffic efficiency and comfort. Nevertheless, their market penetration is still limited, on the one hand due to the high costs of installation and maintenance of the infrastructures and, on the other hand, due to the price of support automated driv...

Citations

Chapter
In this work, we integrated three quantum-safe digital signature algorithms, CRYSTALS-Dilithium, FALCON and Rainbow, into notification messages used in intelligent transport systems. We evaluated the performance of the algorithms by measuring the time required to sign and verify messages, as well as the size of the signed messages, and compared the quantum-safe options to the elliptic curves currently accepted by the standards. Our results show that quantum-safe digital signature algorithms could be used for signing notification messages in intelligent transport systems, with only moderate changes to performance. The results also provide an evaluation of three quantum-safe digital signature algorithms’ suitability for this purpose, thus helping to choose suitable algorithms when migrating intelligent transport systems towards quantum resistance.KeywordsPost-quantum cryptographyDigital signatureIntelligent transport systems