Edge computing brings benefits to users by reducing network latency, thus improving services, but needs management orchestration. Here, we demonstrate how orchestration improves latency in an automotive edge-computing use case by reallocating network resources.
Multi-access edge computing (MEC), commonly called “edge computing,” moves data processing to the edge of communication networks. Bringing computing close to the source and/or destination where such data is produced and consumed means that data need not travel to the cloud for processing. MEC therefore reduces the latency perceived by end-users, in part by reallocating network resources.
5G systems aim to deliver enhanced network performance, focusing on enhanced Mobile Broadband (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine Type Communications (mMTC). Each 5G development phase, specified in a 3GPP release, focuses on one of the above enhancements. The latest, Release 16, set the technical enhancements to deliver URLLC, where the 5G network not only be improved by new radio and core technologies, but by relying on the MEC and its orchestrated services as well. Several services can be located and run at the edge. These services tackle the diverse needs of the different sectors, known as industrial verticals, that include health, finances, and transportation.
Figure 1. An orchestration layer handles CAM services for vehicles in 5G ecosystem.
(Click image to enlarge.)
Figure 1 illustrates the 5G ecosystem consisting of the 5G NR, 5G core, and MEC infrastructure. In this automotive use case, orchestrated services deliver Connected and Automated Mobility (CAM) services located at the network edge to minimize communication latency. In this application, MEC enhances driving and safety, being less dependent on driver’s actions, and ensures the higher safety needed for vehicle/end-user needs. Instructions from the network infrastructure can arrive in less than 100 msec.
Network orchestration performs specific tasks in a network operating as a subset of network-management software called management and orchestration (MANO) systems. A MANO system manages the network and its computing resources. There are several MANO products on the market, both private and public (open-source). Indeed, MANO is standardized by the European Telecommunications Standards Institute (ETSI), the so-called ETSI NFV MANO. As a part of the future Release 17, 3GPP is now standardizing an architecture for enabling edge applications, which includes native/by design interaction between the 5G communication system and the MEC orchestrated by MANO.
Figure 2. High-performance testbeds let us test orchestration of vehicular services at the edge.
(Click image to enlarge.)
Experimentation setup
To understand the impact and benefits of edge computing in 5G mobility services, our research group tested several publicly available MANO systems. We performed tests relying on our high-performance computing and networking facilities for mobility (also known as test beds) located in Belgium. Figure 2 shows the proof-of-concept (PoC) we built to measure the performance of our MEC application orchestrator. This experimentation setup consists of the components from two testbed facilities, i.e., the Virtual Wall test bed (Ghent, Belgium), and the Smart Highway test bed (Antwerp, Belgium). In particular, the Virtual Wall is a test bed for large networking and cloud experiments, whereas the Smart Highway is a test site built on top of the E313 highway for the purpose of vehicle-to-everything (V2X) research. In such a PoC setup, the roadside units (RSUs) on the smart highway function as MEC hosts, creating a distributed edge-cloud environment where MEC application services are deployed, and the vehicle on-board unit operates as a client. The setup is based entirely on the open-source Kubernetes container orchestration engine, where corresponding extensions enhance orchestration decisions to enable data analytics and therefore enable proactive application relocation.
Our MEC application orchestrator runs on the master node and it supports an optimized MEC host selection for application-context relocation. Thus, the network function virtualization infrastructure (NFVI) in our PoC consists of three distributed MEC hosts located on the highway site (worker nodes). The client in our PoC is on-boarded to the vehicle’s on-board unit (OBU), which connects to the distributed MEC application services over long-range 4G.
Response-time measurements
For experimentation purposes, we created a testing V2X application service that generates notifications for vehicles based on the current conditions on the road. We deployed this service in the distributed MEC hosts in our PoC, as a cloud-native application and a containerized piece of software, with RESTful APIs exposed to vehicles for retrieving information about driving conditions on the road.
Figure 3. The MEC service response time measured at the vehicle/user side, where we observe the network and computing latencies with and without MEC orchestration.
(Click image to enlarge.)
Figure 3a shows the values of the measured round-trip time (RTT), which is the network latency — the time between the moment when the request is initiated (vehicle sending request for the latest conditions on the roads) and receiving information from the MEC service. We measured these RTT values at the vehicle/user side. Three curves represent RTT measurements for all three application servers deployed in distributed MEC environments. This setup tests the impact of the network on the overall service response time, shown in Figure 3b. The response time contains the transmission and propagation delay (network impact) and the computational delay on the application server (MEC impact). Figure 3b also shows the application server’s overall response time, measured on the vehicle (user) side, for two different scenarios. This response time is important because it shows the delay in retrieving the important contextual driving information from the server. Keeping this response time low (below 100 ms) is essential for the vehicle to make efficient maneuvering decisions.
Host selection decisions
As you can see in both scenarios, the MEC application orchestrator never selects MEC host 1 for an application placement due to its high resource consumption. This happens due to the load test we ran on this MEC host, thereby artificially increasing the CPU load to train our prediction model. On the other side, MEC hosts 2 and 3 are selected based on the projected resource consumption due to the RTT of similar scale.
In the first scenario, the network does not perform application-context relocation, which means that the vehicle remains connected to the MEC host 2. Once the load increases on the MEC host 2 after 200 sec (Figure 3b), the response time of the application service increases. Driving information about the conditions on the road might be significantly delayed at the vehicle side, leading to the inefficient decisions that will affect the whole maneuver.
In scenario 2, the CPU load increases on the MEC host 2 (i.e., resource availability decreased), as predicted by our algorithm for the time after 200 sec. The proactive decision on relocating the application-context from application service on the MEC host 2 to MEC host 3 results in the relatively stable response time. Such response time does not increase when the vehicle starts retrieving service information from the application service on the MEC host 2. Similarly, such a decision to proactively relocate the service and avoid service disruptions can be made by our algorithm in case user mobility event notification is received from the core network. Testing such a scenario is part of our future work.
We obtained mean values of 331.117 msec and 252.924 msec, and standard deviations are 117.543 msec and 29.786 msec, for the scenario with no application-context relocation, and for the one with relocation, respectively. We can see that in scenario 1, when there is no application context relocation for the observations that appear after the 200th second, the deviation from the mean is large — the increase in response time is statistically significant. Thus, in scenario 2, we show that optimized and proactive MEC host selection results in application-context relocation that helps to improve the overall response time. MEC also prevents service unavailability, which leads to outdated information about the conditions on the road. That, in turn, highly affects the vehicle’s maneuver decisions.
Takeaways
Management and orchestration play a significant role in modern service deployments often present in highly distributed and heterogeneous environments. Such environments become even more important in the case of mobility, where service continuity is essential. We showed how performing an orchestrated and optimized application-context relocation from one edge host to another lets the vehicle always connect to the most suitable application server to retrieve important information about driving conditions on the road. This information is important, especially for autonomous vehicles that need to derive decisions about maneuvering without any assistance from the driver.
Johann Marquez-Barja is a Professor at University of Antwerp, as well as a Professor in IMEC, Belgium. He is a member of ACM, and a Senior member of the IEEE Communications Society, IEEE Vehicular Technology Society, and IEEE Education Society where he participates in the board of the Standards Committee. His main research interests are: 5G advanced architectures including edge computing; flexible and programmable future end-to-end networks; IoT communications and applications. He is also interested in vehicular communications, mobility, and smart cities deployments. Prof. Marquez-Barja is co-leading the Citylab Smart City testbed, part of the City of Things programme, and the SmartHighway testbed, both located in Antwerp, Belgium.
Nina Slamnik-Kriještorac is currently a Senior PhD researcher in the field of Applied Engineering Sciences, at the University of Antwerp and the IMEC research center in Belgium. She obtained her master’s degree in telecommunications engineering at Faculty of Electrical Engineering, University of Sarajevo, Bosnia and Herzegovina, in July 2016. From 2016 to 2018, she worked as a Teaching Assistant at University of Sarajevo. She authored or co-authored several publications in journals and international conferences. Her current research is mostly based on NFV/SDN-based network architectures with edge computing for vehicular systems, and the management and orchestration of the flexible and programmable next-generation end-to-end network resources and services.
