## 3 ACCA Service
### Architecture  
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. To 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. 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. However, the UDP-based communication model is used  
Figure 1: 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.  
when transparent hybrid V2X communication (i.e., V2N2V and V2I2V) is expected and end-to-end ETSI ITS [32] security is required.  
The backend service deployed at the edge cloud is composed of an Edge Geoserver application and an Edge MQTT broker. The Edge Geoserver basically processes the incoming messages from vehicles and the Edge MQTT broker and, accordingly, aggregates the information. The Edge Geoservers are provisioned to exchange MQTT messages (in JSON format) with the central cloud service hosted in a centralised cloud. The central cloud service is composed of a Traffic Management System (TMS), which is responsible for cross-border message exchange and a Central Geoserver. Similarly, both TMS and Central Geoserver may aggregate, filter, and generally process the incoming messages. TMS and Central Geoserver are both provisioned to exchange MQTT messages with each other, between TMS and Edge Geoservers, and with other external entities through the public Internet. Moreover, two types of message queues, namely, inQueue and outQueue, are utilized to publish/subscribe onto MQTT topics. The inQueue is used to send raw messages that are generated by vehicles towards the TMS and the outQueue offers the dissemination of processed V2X information by the TMS towards the vehicles through the edge cloud services.  
It is understood that different MNOs may require different technological interfaces to interconnect with the ACCA service. From the TMS's perspective, it is possible to expose the application-level information in the form of ETSI ITS messages over different underlying transport protocols. In the presented architecture, MQTT is a convenient option, as it supports geo-tiling of the messages, favouring the subscriptions to only those interested regions that are exposed in the form of MQTT topics, among others. Yet, other technological implementations are also possible. For example, ETSI ITS messages can be transported over HTTP requests, by accessing REST or SOAP APIs that are exposed by the TMS. This imposes different architectural challenges, such as ensuring that the TMS clients periodically poll the services. In some cases, the TMS's subscribers can be supervisory control and data acquisition (SCADA) systems, mainly being operated by road/infrastructure operators. In this case, and analogously to the REST interface, ETSI ITS messages can be encapsulated over standard OPC/UA services [33], enabling seamless integration to SCADA systems.