The AECC is dedicated to advancing global network architectures and computing infrastructure to address the data transfer requirements of the growing connected car services ecosystem. Our Proof of Concept (PoC) program focuses on real-world demonstrations showcasing AECC solutions’ efficacy in managing expanding data needs.
Contributing a PoC proposal is a great way to get involved with the AECC and our work in helping to shape the future of the global connected vehicle ecosystem. Any company can take part in our PoC program if at least one member company is part of the resulting PoC proposal. Explore our proposal library to see how AECC addresses current challenges in the connected vehicle realm.
If you’re interested in participating in a PoC proposal, please reach out to [email protected]
AECC Proof of Concept
Edge Relocation: Optimizing 5G Resources and Edge Networks to Enable Varied Mobility Services
By Toyota Motor Corporation and Ericsson
Abstract
The effective and efficient use of mobile networks and edge resources is vital to making the connected vehicle services ecosystem a reality. It’s the fundamental goal of AECC.
The problem is that the services provided by connected cars consume a large amount of network bandwidth and edge computing resources. The mature connected vehicle ecosystem will need to transfer up to 10 billion gigabytes of data to the cloud each month, vastly more than networks can handle today. Not only will the number of connected vehicles increase over the next decade, but the amount of resources consumed for each vehicle will also increase as new services become available.
Our proof of concept (PoC) series is designed to demonstrate that our solutions to this problem can work in real- world conditions and meet our expanding data management needs.
In this PoC, a team from Toyota and Ericsson worked together to look at how to optimize resource usage based on the specific requirements of different mobility services.
We chose two mobility services for this PoC. The first is remote driving, which requires low communication latency because it includes information related to the vehicle’s surroundings and condition. One typical example is camera and sensor data that provides the drivers with real-time visual and auditory feedback about surroundings, such as pedestrians, cyclists, and other vehicles. This data helps them make safe and informed driving decisions.
The second is an infotainment service (streaming audio and video) that requires a large amount of network bandwidth but relaxed latency conditions. While streaming services often generate a large amount of data traffic, they don’t require a real-time response because we can buffer or pre-download the contents. To keep things simpler, we did not set absolute values for the requirements of latency and bandwidth in this PoC.
As you’ll read below, the team successfully demonstrated that edge computing (for the application server) and 5G network resources can be re-routed as needed based on the requirements of specific services. The end result is a smooth flow of data for all the services in use and an optimal experience for connected vehicle users.
Business Strategy
To deal with increased traffic and congestion, cellular network operators will need to make more investments in enhancing the network capability — which will result in higher costs for connected car users. In this PoC, we show that the problem can be solved by making better use of current networks. Our strategy here is to provide an efficient and cost-effective solution to the increased data traffic of connected cars, while also generating revenue through partnerships and value-added services of operators.
Proof of Concept Objective
The objective of this PoC is to confirm that the resources of 5G and edge networks can be optimized on an ongoing basis according to the requirements of different mobility services.
Proof of Concept Scenario
This PoC uses several solutions in AECC Working Group Two’s functional architecture documents (FADs), which investigate and evaluate possible solutions with the aim of realizing an AECC System. Functionalities covered in these documents include dynamic policy adaptation, vehicle system triggering via network exposure function, configuration through the cellular network, and cellular network-based mobility service assignment.
Our scenario confirms that we can choose which data is rerouted and to where, and which data continues to follow its original process flow. In this case, we only wanted to redirect the infotainment traffic. We wanted to keep sending the remote driving data traffic to a server with specific characteristics because in our scenario only one of our two edge applications systems (EASs) could meet the latency requirements.
Here is an overview of the main steps that occurred during this scenario:
- Step 1a: The user equipment (UE) started sending and receiving remote driving data and infotainment information to the EAS. This happened via a 5G network user plane function (UPF), which connected the data to the correct destination on the Internet. The result of all this traffic was UPF congestion, which slowed everything down.
- Step 1b: The congestion was detected in the edge platform’s congestion status monitoring tool.
- Step 2: A notification containing the congestion information of the 5G network’s UPF was sent to the edgeplatform.
- Steps 3-5: The edge platform triggered traffic re-routing via a policy control function (PCF) and a session management function (SMF).
- Step 3: The edge platform triggered the AF influence on traffic routing service.
- Step 4: The SMF initiated a protocol data unit (PDU) session release procedure, and the connection was terminated. (PDU sessions provide connectivity between user equipment and applications.)
- Step 5: The user equipment initiated a PDU session establishment and selected a different user plane function, in this case, UPF2.
- Step 6: All of the infotainment traffic was routed to another edge application system (EAS) via the new UPF.
Functional Architecture
There are two sets of details that are particularly significant in this PoC.
- It was critical that the team verify that the interwork between the edge enabler system (EES), the edge application system (EAS), and the network data analytics function (NWDAF) could be implemented in a 5G network.
- The team also needed to confirm the session re-creation and how the application server handled the traffic impact. We saw that when the edge application server (EAS) was congested, the EES informed the EAS about the congestion, and then rerouted the user’s traffic to an uncongested UPF by creating a new session. It was very rewarding to watch all of this happen in real time.
Proof of Concept Results
The illustrations above include screenshots of the edge platform triggering traffic re-routing via PCF and SMF. This verifies that the third party can influence the 5G network for better use of resources.
This PoC demonstrates that the computing power of the edge computing network and the network resources of the 5G network can be utilized effectively and much more efficiently while taking into account the business quality requirements of the services the connected vehicle is using.
This use case is very advanced and can’t be executed by products currently on the market. Because the Toyota and Ericsson team agrees about the value of this use case, we have proposed a solution for this scenario with the hopes that the necessary systems will be integrated into future products to benefit users everywhere.
Next Steps
This PoC demonstrated traffic rerouting is decided by an edge enabler system (EES) — in this case, an Ericsson product named Edge Exposure Server. But there are multiple options for roles and responsibilities between the network and the application, and these could be determined by different use cases and partners in the ecosystem. Additional tests could look at making different equipment and scenarios work.
Another interesting topic to explore would be the alignment of the software development kit (SDK) and/or the application program interface (API) between the core network and industrial application. Although the edge computing and vertical industry are quite diversified, if the API could be categorized and aligned it would be much easier and more agile to implement a wide variety of use cases.
