John Kaippallimalil, Tony Saboorian, and Amanda Xiang
Published: 24 Nov 2021
CTN Issue: November 2021
A note from the editor:
Wikipedia says that “the origins of edge computing lie in content delivery networks that were created in the late 1990s to serve web and video content from edge servers that were deployed close to users. In the early 2000s, these networks evolved to host applications and application components at the edge servers, resulting in the first commercial edge computing services that hosted applications such as dealer locators, shopping carts, real-time data aggregators, and ad insertion engines.”
Now days edge computing is synonymous with low latency, high data traffic and verticals requiring low latency. Operators are partnering with cloud providers to deliver “edge” computing capabilities, and academics are intensely working on how this edge can be pushed closer and closer to where the data is generated. Regardless of the time horizon and application, there’s no doubt that the edge will continue to be defined in years to come.
On this article, the authors provide a whirlwind tour through what edge computing means in the context of 5G and inform the reader of the state of this technology as it relates to wireless standards and wireless applications. There’s no doubt that the list of publications on edge computing are vast but the role of this technology within wireless standardization is just starting to be understood. As always, your comments and feedback are most welcome.
Yingzhen Qu, CTN Associate Editor
Miguel Dajer, CTN Editor-in-Chief
Edge Computing in 5G Is Not Just for Public Networks
What Does Edge Computing in the Context of 5G Mean?
Edge Computing has been a subject that one can find a reference to in almost any industry related to computing, communication, and telecom. “Edge” is a term that is used a lot and means different things depending on the context. Some think of Edge Computing as cloud computing in a few cloud/centers/sites distributed at the edge of the network while others may have a more distributed model in mind in which edge can be a site as close as possible to the UE (User Equipment) or CPE (Customer-Premises Equipment). In all cases the goal is to have the computing done in a site close to the end users to provide the best user experience by reducing communication delay or latency, increasing reliability for applications, as well as providing privacy and security protection for the applications and users. In the context of 5G, edge computing provides processing that is close to the UE relative to a cloud compute server. According to 5GAA (5G Automotive Association), Edge Computing refers to a broad set of techniques designed to move computing and storage out of the remote cloud (public or private) and closer to the source of the data.
5G has defined capabilities to support applications with a range of communication requirements from enhanced mobile broadband (eMBB) to ultra-reliable low latency communications (URLLC) and massive machine type communications (mMTC). While broadband (eMBB) applications are being deployed widely and get even more bandwidth than in 4G, URLLC applications from different vertical industries that depend on low latency, high reliability connectivity, such as control for industrial applications, have yet to be deployed at scale. Many of these are likely to be in non-public, private, or enterprise networks. 5G provides several features and capabilities including slicing, enhanced session, mobility handling and capabilities for edge computing [3GPP TS 23.548] which is the topic in this discussion.
Example Use Cases for 5G Edge Computing
One of the main drivers for edge computing in 5G is to provide low latency for demanding applications and at the same time provide better privacy and lower overall network bandwidth usage with local processing and caching. While edge computing in 5G can be used in public network scenarios to reduce overall bandwidth usage for content delivery or to reduce latency for gaming, business drivers and use cases in non-public networks are even more compelling. For example, the EU 5G-DIVE project describes various edge computing use cases for Industry 4.0 and autonomous drones.
For example, the digital twin control of a physical device like a robot benefits when the control instructions are processed at the edge with low latency. Sensor data and feedback can likewise be processed at the edge with more privacy protection and lower aggregate network bandwidth required in comparison to transferring data back to the centralized cloud server. Zero Defect Manufacturing (ZDM) is another example where physical devices on the production line are monitored using video cameras and analyzed using AI /pattern recognition algorithms deployed at the edge and cloud networks for analyzing quality and defects. 5G connectivity provides low latency and reliability that are required for keeping the production and operation optimal. Other use cases include support for fleet navigation and image processing for autonomous drones in rescue scenarios where the 5G edge can provide low latency communications for end points that are in motion and a major portion of the communication may occur locally.
5G ACIA (5G Alliance for Connected Industries and Automation) is working on identifying edge computing use cases and requirements for industry applications. Use cases being considered include mobile robot control, production management with digital twin and eXtended Reality (XR) which require highly efficient video and high volume data handling. In these scenarios, the primary reasons for using edge computing include providing low latency communication; the ability to offload heavy computation to (relatively) centralized edge location rather than having it distributed within individual devices in the factory. Business logic over aggregated inputs across standalone factories or a cluster of factories in a region can use a combination of edge, private or hybrid cloud computing.
Some Key Standards for Edge Computing
3GPP as the main body for specifying 5G standards has defined capabilities to support various 5G applications. 3GPP Release 16 standards provide basic support for edge computing. However advanced capabilities for service discovery for the different connectivity models are being added in 3GPP Release 17 [3GPP TS 23.548]. Since an application may be served by multiple Edge Application Servers (EAS) deployed in different edge locations, service discovery procedures are enhanced to select the closest/best EAS for different network scenarios (operator hosted servers, 3rd party deployed) and connectivity models.
The latest 3GPP standards support various Connectivity models that allow for example the breakout of data sessions to EAS in local sites/edge cloud (routed via local IP Data Network (DN)), while also supporting data sessions to Application Server (AS) in central sites/cloud (routed via DN from a Central Site). Connectivity models supported include distributed anchor point, session breakout and multiple packet data sessions (known as Packet Data Unit (PDU) sessions in 3GPP terminology). In a data session with a distributed anchor point the User Plane Function (UPF) anchor is in a local site from where the data packets can be routed to the closest EAS in the Data Network. In a multiple Packet Data (PDU) sessions model both central and local connectivity may be realized by setting up multiple corresponding data sessions. In an Industry 4.0 scenario, the connectivity session setup may be a distributed anchor point or multiple Packet Data (PDU) sessions. In a Mobile Network Operator (MNO) setting where the UE is accessing centrally deployed applications and edge applications, a session breakout connectivity session can be set up. In each of these connectivity scenarios, session setup, traffic filters and service discovery with Domain Name System (DNS) is needed prior to forwarding data packets.
European Telecommunications Standards Institute (ETSI) group on Multi-access Edge Computing (MEC) has meanwhile studied various aspects of edge computing including how to integrate it with 3GPP 5G systems (ETSI GR MEC 031). MEC and 5G system are complementary in that the MEC system behaves as an Application Function to influence traffic route and UPF selection in 3GPP 5G system. ETSI report on Inter-MEC systems and cloud systems coordination (ETSI GR MEC 035) describes use cases and patterns of business relationships between MEC and external systems, including private cloud.
MEC platform (Application Function in 3GPP system) may be federated and have agreements with edge cloud in the same or another MNO, or have agreements with external public or private cloud as illustrated in the figure above. These patterns of interaction and business relationships cater to a range of scenarios such as vehicle-to-everything (V2X) federation, multi-operator transfers and edge node sharing. There is still a lot of work to be done including for MEC platform discovery and exposure of information.
Identifying Gaps and Future Direction for 5G Edge Computing
Edge computing has progressed significantly in 3GPP and other related standards organizations. However, a lot of work still needs to be done for it to operate in a seamless and scalable manner. There are a few interesting and open problems. One basic challenge which the industry has started to work on is how to optimize the handling of both computing and network resources in a network where the users may be mobile (i.e., the user’s point of attachment to an edge changes during an application session).
For example, what is an optimal edge server for a moving user? The closest server may not always be the best choice. Suppose we pick the closest edge server from a user’s new point of attachment, it may not be the best if that edge server is heavily loaded. And, if we select the most available edge server it may not have the lowest latency path to the user. Lambda functions, serverless and joint optimization of resources may offer some answers on how to make the service experience great including low latency, especially when the mobile network and edge compute servers are operated by different providers. This may be more than a technical concern as it would be about how these issues are discussed for multiple domains (connectivity, processing) and with all interested parties.
Another area that merits further exploration is failure handling for a complex service like XR that has multi-modality flows where different devices within the XR service may change the point of network attachment at different times during the XR session. Anycast routing may provide a measure of resilience by rerouting to new server instances when there are partial failures. Let us also assume for now that connectivity can be carried seamlessly to the new server instance with new transports like Quick UDP Internet Connections (QUIC) and application state synchronized with Conflict Free Replicated Data Types (CRDT) and stored across distributed servers. There can still be the issue that in some cases it may be better to keep the old server rather than reselect and route to a new server instance after the user moves due to various business and operational considerations. The network has few means to convey such semantics today but there are promising efforts such as Dyncast (Dynamic-Anycast).
We should also not forget about the concerns with privacy either especially for enterprises or vertical applications. Apart from just encrypting packets from end-to-end, the application domain may not want to reveal some Uniform Resource Locators (URLs) or other sensitive information. For example, names may be resolved by a private DNS server, yet it should be possible to select an application/server instance close to the 5G edge. This may look somewhat incompatible but smart routing and service discovery approaches may be able to provide answers.
As edge computing servers are placed ever closer to the UE, newer mechanisms with decentralized orchestration and dynamic connectivity handling along with better models of predicting resource demand will be needed. Future edge computing work should consider the combined needs of private and public networks as well as interworking between them for seamless and secure service delivery.
In Conclusion
This has been a whirlwind tour through what edge computing means in the context of 5G, related use cases especially in private and vertical applications, networking standards, gaps, and future direction. There are well identified use cases and requirements for low latency along with the need for a high degree of security and privacy. Current standards in 3GPP and ETSI MEC provide a solid foundation to build on. But edge computing is still maturing in 5G and requires cooperation across UE /operating system vendors, network component vendors and operators, and application providers for compute resources to address the many challenges for an optimal and secure service.
References
- 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 5G System Enhancements for Edge Computing; Stage 2 (Release 17), 3GPP TS 23.548.
- 5G Automotive Association (AA), https://5gaa.org/
- 5G-DIVE Architecture and Detailed Analysis of Vertical Use Cases (D1.1), H2020-859881 EU 5G Dive Project
- 5G Alliance for Connected Industries and Automation (ACIA), https://5g-acia.org/
- Multi-access Edge Computing (MEC): Study on Inter-MEC systems and MEC-Cloud systems coordination, ETSI GR MEC 035 035 V3.1.1 2021-06.
- Dyncast: Use Dynamic Anycast to Facilitate Service Semantics Embedded in IP address, Yizhou Li et al., IEEE Xplore, 15 July 2021.
Statements and opinions given in a work published by the IEEE or the IEEE Communications Society are the expressions of the author(s). Responsibility for the content of published articles rests upon the authors(s), not IEEE nor the IEEE Communications Society.