# A Roadside and Cloud-Based Vehicular Communications Framework for the Provision of C-ITS Services
## 5 Materials and Methods  
To analyze the performance of the system, on-field tests were performed using an OBU, an RSU and the cloud MQTT broker. While the OBU communicates only with the RSU through ITS-G5 using broadcast messages and vice versa, the RSU also communicates with the cloud MQTT broker using either fiber optics or LTE. The latency of the time taken for messages generated in an OBU to reach an application, such as the central C-ITS platform, connected to the cloud MQTT broker is analyzed. The OBU employs the same ITS-G5 protocol stack used by the RSUs as described in Section 3.1, running on Arch Linux while the cloud MQTT broker runs an Eclipse Mosquito instance also on top of a Arch Linux virtual machine with 4 cores and 16 GB RAM. PC Engines APU3 boards are used as the ITS-S hardware, consisting of an AMD GX-412 TC 4-core CPU @ 1200 MHz and 4 GB RAM. Any cryptographic operations carried out by the protocol stack are performed by this CPU. Time synchronization is achieved using the Network Time Protocol (NTP) for the cloud broker, which uses an NTP server in the same network, achieving sub-millisecond accuracy. For the OBU and RSU, the Precision Time Protocol (PTP) is used instead, where a dedicated Raspberry Pi is employed as a time server, obtaining current time information through a GNSS receiver's Pulse-Per-Second (PPS) signal. The connection between the OBU/RSU and the Raspberry Pi is established using a small Ethernet cable, achieving sub-microsecond accuracy. A visualization of an RSU identical to the one used in the tests is provided in Figure 8.  
Figure 7: Overview of the STEROID deployment scenario and C-ITS platform. RSUs statuses and nearby traffic perceived by the RSUs radars can be viewed. The C-ITS platform can also generate events and forward them to respective RSUs. Packets, their timestamps and other associated metadata are recorded in the ITS-S in the Facilities and Access services, and in the cloud broker server, where a lightweight C. Mosquito program functioning as a MQTT client is constantly listening and recording all ITS messages arriving at the broker. Data were recorded and stored using three MariaDB instances, one running in the OBU, one running in the RSU and one running in the cloud broker server. In the presented tests and results only CAM packets were transmitted. The generation rate of CAMs was set at 10 Hz using a static OBU. As per the ETSI ITS standards, CAMs are generated at the Facilities service, then forwarded to the Transport service to be encapsulated with the BTP protocol headers, then sent to the Networking service to be encapsulated with the GeoNetworking protocol headers and optionally sent to the Security service to be signed, and lastly forwarded to the Access service to be encapsulated with the LLC and MAC headers so that the message can be broadcasted through ITS-G5. Received messages follow the opposite path, being decapsulated by the responsible services and the signature verified by the Security service. Received messages are also forwarded by the Facilities service to the Applications service, where they are forwarded again to the cloud broker through MQTT. Access-wise, the ITS-G5 Control Channel (CCH) was used to transmit these messages on the 5.9 GHz frequency at 23 dBm power, with a default data rate of 6 Mbit/s. A distance of 35 m separated the OBU and RSU. Since ITS-G5 has a high PDR up to several hundreds of meters [10; 44] (varying according to transmission power, vehicle speed, and obstacles, among others factors), we expect the packet loss rate to remain extremely low to non-existent at 35 m. An installed on-field RSU with a fiber optics and an LTE connections provided by a commercial operator was used for the tests. The RSU is connected to a private VPN, providing access to the same network as the cloud broker. The RSU was first connected to the Internet via fiber optics and then by LTE. A representation of the described test setup is presented in Figure 9.  
Figure 8: An RSU used for performance analysis of the proposed implemented system.