Info Image

5G Drives the Distributed Edge

5G Drives the Distributed Edge Image Credit: Sergeybitos/Bigstockphoto.com

After years of anticipation, 2019 saw some of the first rollouts of 5G, with deployments growing significantly this year and continuing to increase in 2021. At the same time, according to the Linux Foundation’s State of the Edge 2020 report, by 2028, edge infrastructure will have a power footprint of 102,000 MW, and over $700 billion in cumulative CAPEX would have been spent within the next decade on edge IT infrastructure and data center facilities.

5G holds the promise of enabling incredible new applications and use cases such as autonomous vehicles, AR/VR, and IoT/IIoT among others, due to its significant throughput and latency advantages over 4G. Telecom, cloud and data center providers look forward to 5G forming a robust edge “backbone” for the industrial internet to drive innovative new apps, enterprise use cases and, ultimately, increased revenues.

However, 5G’s promised capabilities cannot simply be realized by the installation of new base stations and endpoints alone. Supporting the extreme low latency requirements for several next-gen applications (below 10ms) requires a distributed edge architecture that moves access termination and compute capabilities closer to the end user. This means increasing the number of distributed edge data centers (also known as virtual central offices) by an order of magnitude.

To take advantage of lower costs via centralization, hyperscale cloud providers (public cloud) have gone ahead with massive regional deployments, with a small number of facilities serving all of North America. The downside of this centralization is that the public cloud compute facilities are too far from the end users to meet the low latency requirements of 5G apps such as connected cars. For example, the round-trip latency to get from New York City to the nearby public cloud instance from Amazon Web Services or Microsoft Azure in Northern Virginia is greater than 20 milliseconds. This implies that a localized on-premise edge component is required to meet the required performance guarantees. The infographic below expresses 5G’s low latency requirements.

Image Credit: Kaloom

5G goes cloud native

When 3GPP initially started work on designing 5G, one of the main goals was to design a scalable and customizable network that can be tailored to requirements from multiple services and vertical markets. Other key goals of 5G include optimizing for resource efficiency and energy efficiency. There are two major technology shifts that enable the scalability, customization, and efficiency required by 5G networks. One of them is the use of containers. Containers are more lightweight in terms of code and therefore use less storage to house the networking apps and less compute to run them. They’re also more easily portable and quicker to instantiate. When a VM crashes it can take minutes to resume, whereas containers can be restored in a few seconds. The other is the separation of the 5G gateway functionality into two components; a data plane function called User Plane Function (UPF) and a control plane function called Session Management Function (SMF). This enables the control plane to be implemented on container-based cloud native network functions (CNFs) while being able to accelerate the data plane using high speed programmable ASICs to provide increased throughput, lower latency and greater energy-efficiency. Additionally, these efficiencies and separation enable a containerized mobile packet core that can be more widely distributed to meet the ever-increasing demands of mobile data at the edge. This is why service providers and enterprises are deploying 5G networking components as containers using specialized orchestration platforms such as OpenShift (based on open source Kubernetes).

5G’s challenges

In order for 5G rollouts to be profitable, there are also some financial challenges to overcome in addition to the technological capabilities mentioned before. For example, several new applications of 5G technology will provide revenues (ARPU) that are significantly lower per connected device when compared to revenues from smartphone users running 3G/4G. In order to enable such applications there needs to be a significant reduction in cost/bit across the board. The new and improved radio technologies aim to do so, but this cost reduction needs to happen across the board, including the core network as well as the application platforms.

Image Credit: Kaloom

Programmability to the rescue

In addition to containers coming of age, network programmability is another technical advancement that is critical to meeting 5G’s challenges. It allows software to flexibly program hardware to add new functions - for example network slicing, load balancing and firewalling - in a way that was not previously possible. Additionally, it future proofs network hardware investments (CAPEX) and delivers flexible functionality so providers won’t have to replace all their equipment in a few years to support changing standards or new functionalities such as network slicing.

Network slicing is a key function required to meet 5G’s low cost points. Using 5G-enabled network slicing, it’s conceivable how different service providers - for example, MVNOs - can share the same physical network resources while maintaining different SLAs and offering differentiated services. This could enable initial 5G service rollouts while minimizing costs and risks, via shared cloud and networking infrastructure.

Consolidating and offloading the data plane

Consolidating the data plane is a key part of a 5G solution as well, not just via containerization but also by logically unifying its code into the same hardware compute and storage area to avoid tromboning and replication of redundant networking code. With new P4-enabled switches adding server-like compute and storage capabilities, the switches can then “offload” these data plane capabilities from servers to the switches. This results in significant efficiencies in terms of lowering latency and increasing throughput, not to mention reducing TCO, including both CAPEX and OPEX. More importantly, it frees up many servers (rack unit spaces or RUs) to run 5G’s new revenue-generating apps.

Image Credit: Kaloom

The image above demonstrates an example of the dramatic difference that consolidating and offloading enables versus a conventional container-based edge deployment when using a half rack, or 20RUs, of space and power available. Integrating networking functions into to the switches and running them in containers doubles the number of available servers. It requires only three more units for P4-enabled switches running OpenShift masters or a similar system. That’s eight additional servers that are now available to run differentiated revenue-generating apps like connected cars, AR/VR, CDNs (i.e., Netflix) within the same limited space, power and compute resources available.

This architectural approach - leveraging containers and consolidating and offloading the data plane to P4-enabled switches - enables 5G to meet the price points required for profitability. Further, P4 delivers the programmability for 5G providers to offer innovative new services on different network slices that meet the SLAs their customers require while also delivering secure, end to end, fully isolated networks.

5G operators need a simplified operation of complex next-generation infrastructure to deliver accelerated time to market of new services. When it comes to 5G, businesses and service providers alike need an interoperable ecosystem of low-cost solutions that can evolve fluently so they don’t have to keep buying new hardware every few years. However, lowering costs alone is not enough. Businesses want 5G solutions that meet very specific technical demands that are unique to them, and that provide differentiation.

Author

Suresh Krishnan is the Chief Technology Officer at Kaloom, where his main areas of work are in data center networking, software defined networks, 5G and M2M. His leadership and experience contribute heavily to the unique IP capabilities that Kaloom supports while ensuring full compatibility across data center IP infrastructure. Suresh is a leading expert in the IETF, the main standards organization for the Internet, having led and contributed to over 45 IETF RFCs. Prior to Kaloom, Suresh was a distinguished engineer at Ericsson and a software engineer at Cisco where his work focused on Routing and Switching, IPv4/IPv6, Mobile IP, GTP, Datacenter infrastructure, Linux, C/C++ and Evolved Packet Core Networks. He has a Bachelor's degree in Electrical Engineering from the University of Madras in India and a Masters degree in Electrical Engineering from Concordia University in Canada.

PREVIOUS POST

The Ultimate Guide to Open RAN: Concept of C-RAN, Virtual RAN (vRAN) and OpenRAN

NEXT POST

Open Source and Open Standards: The Recipe for Success