Title
Cellular-V2X experimentation in 5GinFIRE – CV2XinFIRE
Organization
Feron Technologies PC, https://feron-tech.com/
Experiment description
Feron Technologies puts a lot of effort to implement and evaluate innovative and newly introduced V2X solutions for real-world applications and scenarios. In that context, the current experiment focuses on the following activities:
- incorporation of the latest, rapidly emerging, but practically yet unexplored in real‐world conditions, C‐V2X (or LTEV2X) radio technology
- the development and seamless integration of radio control, parameterization and monitoring components into the 5GinFIRE framework as VxFs/VNFs;
- the experimentation for evaluation of fundamental radio, network and application‐level performance indicators;
- the showcase of multi‐technology proof‐of‐concept vehicular applications upon a virtualized environment.
Taking into consideration the aforementioned activities, the current experiment will provide the following outcomes:
- A configurable protocol stack for LTE‐V2X operating as a software modem will be integrated into 5GinFIRE.
- A fully operational C‐V2X OBU built on commodity hardware based on SDR principles will be added into IT‐AV.
- A set of VxFs/VNFs implementing parameterization, reconfiguration and monitoring functionalities will be developed, as well as a basic exemplary ITS applications
- A campaign of experiments will be conducted in order to specify performance requirements and limitations for all current V2X communication technologies
A. Platform Architecture
During the design phase, after evaluating different schemes and approaches, the experiment setup finally concluded to a robust and scalable solution in order to be fully integrated within the 5GinFIRE platform. Figure 1 illustrates the high level experiment architecture.
The derived architecture is as much agnostic as possible, where there is no tight coupling into the underlined hosting facilities, providing a wide range of potential integrations. Briefly, the primary components of the architecture are the following:
- OBU
- NUC
- USRP (C-V2X Software Modem)
- LTE dongle
- Yepkit USB Switchable Hub
- Open Air Interface (OAI)
- ITS-G5
- VxF
- OPENC2X
B. Experiment Configurations
The primary high-level concept that CV2XinFIRE tries to accomplish, is to successfully setup a real vehicle to vehicle or vehicle to ‘X’ communication, and gather different statistics, assisted and initiated by the 5GinFIRE Cloud. Based on the primary architecture design as presented in Section A, the fully qualified experiment configuration is presented in Figure 2.
In real time scenarios, there are different schemes that may apply based on the designed solution for V2X communications, such as:
- Side-Road infrastructure communicate to Device and Device broadcasts the information to out of coverage devices
- Message generation taking place on the device itself, and then broadcasting the information
It is feasible to raise the following configurations by differentiating on the attached interfaces and communication between VxFs and OBUs.
- Configuration A: OAI + C-V2X – Full LTE
- Configuration B: OAI + ITS-G5
- Configuration C: ITS-G5 RSU to C-V2X vehicle
- Configuration D: ITS-G5 system
Among the derived configurations, the Configuration ‘A’ is firstly introduced by FERON in the 5GinFIRE platform which seems to be a promising and realistic topology by combining the flexibility and completeness of the 4G+/5G LTE through the Open Air Interface, and the SDR-supported communications which seems an ideal candidate for V2X communications.
The sequence diagram is more or less similar between the configurations. Therefore, the diagram of the first configuration is presented as it is the most complicated configuration among the others, because it incorporates all the involved interfaces. A basic sequence diagram of the Configuration ‘A’ will be as follow:
- Data generator VxF generates the data based on the ITS-Stack
- VxF sends the generated data through 5G (OAI)
- OBU receives the data from the installed dongle
- OBU software modem processes in real time the data
- OBU transmit the data via the USRP to another OBU
- Recipient OBU gathers the data from the USRP
- Recipient OBU processes the data to extract the initial message
- Recipient OBU sends the data to the measurements and benchmarking VxF
- VxF processes the data and extracts statistics and KPIs
- VxF feed Grafana database with the data
- Grafana displays all the up to date statistics reports and charts in a visualized way
Results
Use Cases
The information flow presented in Section B, can be used to emulate several V2X communication use cases. More specifically:
Use Case 1: An Intelligent Transportation System service is provided by a provider through the 4G+/5G network. The data are reaching vehicle 1 that is located in the coverage area of a base station. However, this is not the case for the off-coverage vehicle 2. An adhoc V2X technology (ITS-G5 or C-V2X or both) is used to relay the information from vehicle 1 to vehicle 2 – operating as coverage extender for the legacy system. A schematic representation of the use case can be found in Figure 3.
Use Case 2: In this case, the Intelligent Transportation System service does not utilize conventional cellular networks. The data reach a Road Side Unit (RSU) through network infrastructure (the backhaul networking type is indifferent), and then the RSU operates as a relay or gateway and forwards the data packet to the vehicles through the ITS-G5 interface. Then, the vehicle re-transmits the information through an adhoc V2X technology (ITS-G5 or C-V2X or both), in order to relay information to the distant vehicle. A schematic representation of the use case can be found in Figure 4.
Use Case 3: The specific use case considers the cloud as part of the vehicle. The VNF is actually running in NFVI deployed inside the in-vehicle network on top of the plethora of computing devices existing in the vehicle. The vehicle gets the ITS data from the “ITS as a Service” entity and uses ITS-G5 or C-V2Xradio technology to broadcast the information. In this scenario, the in-vehicle networking is indifferent and can be emulated with any available networking technology.
KPI Factors and Monitoring
The main focus of the experiment is to export various significant KPI factors, but providing in the same time a user friendly way to monitor and display the whole process. For those purpose two different tools where used to incorporate all the functionalities, namely:
- Real-time ITS Message Monitoring
- The tool consists of multiple dragable and resizable panels. The basic panel is a map updated in real-time from OpenStreetMaps. By pressing the button “Open Menu”, the user has the opportunity to present panels populated with data that originate by:
- Ego vehicle CAM messages.
- Ego vehicle DENM messages.
- CAM messages from other adjacent vehicles.
- DENM messaged from other adjacent vehicles
- The tool consists of multiple dragable and resizable panels. The basic panel is a map updated in real-time from OpenStreetMaps. By pressing the button “Open Menu”, the user has the opportunity to present panels populated with data that originate by:
- KPI Monitoring with use of the Grafana tool
- Web service, in order to be easily accessible through the network without the need for anyinstallation at the observers pc.
- Free and open-source in order to be installed and publicly used through the VNF.
- Flexible visualization tools, with the capability to install multiple dashboards, panels and typesof figure plots.
- Embedded data analytics, for fast and efficient manipulation of data without the need to install extra processing modules or databases.
Some indicative KPI metrics that visualized through Grafana for the undertaken experiments are presented below:
- Distance between vehicles.
- SNR
- EVM
- Latency
- Number of received bits
- Throughput
- Packet Errors
- PER
- Bit Errors
- Bit Error Rate
Indicative KPIs along a route
A real-time monitoring experiment took place by two vehicles moving around the National Technical University campus, while the ITS messages are generated into VNF uploaded on the 5GinFIRE testbed, and exchanged through C-V2X radio. The messages arrive from the VNF to the vehicles through 4G+ connection. The opposite route is followed in order to feed the Real-Time monitoring tool and present the results through the website, also hosted by the VNF. In this section, we present the KPI results for the aforementioned experiment scenario. Similar results can be extracted for any measurement route.
Application Layer Latency Measurements
Another important factor of the results is the evaluation of the derived latency in the application layer.
Initially, we consider the case where the ITS stack is executed locally on the NUC that hosts the software modem and drives the USRP. Then, we compare the estimated latency, with the configurations where the OpenC2X is hosted by the VNF.
Two cases are considered:
- Configuration A: 4G+/5G is used to forward the traffic towards/from the VNF.
- Configuration C: ITS-G5 is used to forward the traffic towards/from the VNF.
The results show that there is a tripling of latency. The phenomenon is expected, since the message performs wireless hop and propagates through the software defined network of the 5GinFIRE cloud.
When comparing the latency of the Configuration A and Configuration C (Figure 13), it is noted that by a small-factor, the 4G/5G solution provides on average lower latency. Moreover, the empirical histogram shows that its behavior resembles with popular distributions (e.g. Gaussian, Weibull etc.). On the contrary, when using ITS-G5 as a backhaul, the distribution of values does not resemble with a popular distribution. Moreover, its deviation is quite limited, since the values seem bounded between a minimum and a maximum value.
In Figure 14, a comparison of latencies between the two V2X technologies is performed. The following conclusions are derived:
- Generally, the C-V2X has small standard deviation, since it does not use random access formedium access. The differences in latency is mainly caused by the variations in the packetprocessing delay.
- On the other hand, the ITS-G5 system uses random access and as a result, in many cases highlatency values occur.
- Nevertheless, in many cases the ITS-G5 has lower latency – indicating that the dedicatedhardware radio can provide quite smaller latency values.
- On average, the two systems perform similarly. ITS-G5 performs slightly better
Finally, in Figure 15, we compare two systems where:
- V2X link is performed through ITS-G5 and backhaul is implemented through 4G/5G.
- V2X link and backhauling is implemented through ITS-G5.
It can be seen that in case (a) the latency is significantly smaller. This is due to the fact that in case (b), the ITS-G5 channel is shared between two transceivers. Consequently, collisions happen, causing overall increase of latency due to the protocol backoff.
Conclusions
The experiments conducted by FERON within the 5GinFIRE platform had a number of impacts both in 5GinFIRE platform as well as FERON side. More specifically:
- CV2XinFIRE gave to FERON the opportunity to test, validate and evaluate the performance of the software modem. Moreover, there was the opportunity to perform comparisons with the conventional ITS-G5 hardware modems and identify weaknesses.
- CV2XinFIRE delivered the first real-world comparative experimentation testbed for the LTE-V2X technology (vs. ITS-G5). The 5GinFIRE IT-AV at this point hosts the first publicly available implementation of C-V2X technology and the first field test evaluation platform.
- The integration of SDR technology to the 5GinFIRE NFVi, paves the way for new types of experiments, allowing flexible waveform and radio protocol testing.
- Incorporation of live GPS and OBD2 information in software tools took place.
- Real-time experiment data visualization integrations and comparisons performed.
