You’re in pole position, now leverage 5G at the Edge

Most people would agree that the new and upcoming services realized through 5G networks will have significant impact on our daily lives. This is echoed by folks in the telecom industry who also point out that 5G will bring vast opportunities for CSPs to create customer value beyond connectivity by pushing it to the edge. But what is the network edge and what are the benefits?

Let’s start with the technology. Ask your next-door neighbor about 5G and presumably “more bandwidth” will be the first thing they’ll mention. Sure, there are faster connection speeds (5G is around 20 times faster than 4G/LTE), which is great, but one could also argue that’s still just a sequel to the mobile broadband services available in today’s 4G.

The maybe more interesting characteristics of 5G technology are:

• the ability to handle massive amounts of connection points (a whopping 1 million devices per square kilometer)
• the impressively low latency in the radio interface (sub 10 milliseconds)
• the introduction of cloud native technology (to deliver platform consistency & scalability across diverse network locations, edge to cloud)

All these features are fantastic in themselves, but in the right circumstances, they'll also open up many interesting use cases in the hyperconnected world that’s just around the corner. But what are those “right circumstances”?

It’s all in vain if you don’t push it to the edge

To make use of this new technology – which connects endpoints in the millions, handles the radio backhaul in a blink of an eye, and delivers platform consistency across sites – networks, and more specifically network topologies, need to change. Valuable time cannot be spent over long-haul links sending data up and down the grid between the device and the cloud. If done this way, the 5G technology leap will not be used to its full potential.

We’ve established that the latency in 5G radio comes with fantastic enhancements compared to previous radio generations. But to keep that gain the rest of the latency chain needs to be properly managed, since delays and bottlenecks will, by laws of physics, appear elsewhere in the network. This brings us to edge computing, which essentially makes possible the relocation of workloads, from the cloud to the edge, to gain low latency.

Let’s break this down. Undoubtedly service providers have a set of key assets that put them in a good position to push relevant workloads towards the edge of the network. They have many sites and points of presence widely spread across the regions in which they operate. In those strategically located sites, far out in the network, there is space available since modern telecom equipment require significantly less footprint. This leaves room for new processors and storage (to be used for e.g. enterprise application, but let’s come back to that). 

Distributing the workloads to the edge also means that the drawn-out network topologies of today need to change and become more dynamic. For example, network architects will work on short-circuiting the “trombone effect” (think of the bent tube of a trombone). Short-circuiting, or avoiding, the trombone effect means you’re preventing time-critical data traffic from taking the long route from the device, via the edge and onwards to a centrally located data center (i.e., the cloud) to get analyzed and sent back down the network. By instead moving workloads and computing resources physically closer to end users, to the edge, the types of services and service agreements that CSPs can offer to their customers will dramatically change.

The role of cloud native technology for the journey to the edge

But how do you best address this? The cloud is obviously a very capable place that holds all the services a developer needs to build an application and feed it with data. If the creation of some of those apps and data handling is heading towards the edge of the network, things must be done differently.

And yes, this is where the cloud native technology that's inherent to 5G comes into play.

As stated above, cloud native and the cloud native paradigm is one of the technology leaps of 5G. Looking back, all functions delivered within telecom networks were realized using self-contained nodes, aka Physical Network Functions (PNFs), where each node solved a distinct task. Gradually this has transitioned to Virtualized Network Functions (VNFs) running in Virtual Machines typically managed by OpenStack.

Now with 5G, telecom functions like Packet Core and IMS have made careers in their revamp from PNFs and VNFs to become cloud native CNFs (cloud native network functions) by default. In essence, the CNFs are built using a service-based architecture with a microservices framework. Individual and autonomous micro services are stitched together, without sacrificing performance or quality assurance, to make up a function that gets wrapped in a software container managed by Kubernetes (the open source container orchestration platform that’s become a de-facto industry standard). 

Why is this important?

Well, what used to entail dependencies between the application and its underlying infrastructure and platform in the world of PNFs and VNFs has, with 5G CNFs, become a layered independent intelligent architecture. As a result, the 5G cloud native network functions are agnostic to the subtending layers and can run on any compliant Container as a Service (CaaS) platform. In a central data center or at the edge, with multi-cloud management through Service orchestration.

The beauty is that the same thing applies also to non-telecom applications, which means that cloud native enterprise applications can be deployed onto the same CSP infrastructure as the cloud native network functions and managed across multi-clouds.

The case may be, however, that different cloud native network functions (the CNFs) and cloud native enterprise applications are developed using different frameworks for the microservices part. There are also multiple distributions of container platforms (or CaaS if you like) on which the cloud native functions and applications get deployed. However, if both layers (the microservices framework and the CaaS layer) are based on and compliant with the Cloud Native Computing Foundation (CNCF), there is good ground for achieving interoperability.

Putting it into action: a key case study

As an example of this, Ericsson and Intel have entered a technical collaboration whereby to enable support in Ericsson Cloud Container Distribution (CCD) of a set of plugins and microservices from Open Network Edge Services Software (OpenNESS), an open source software initiative from Intel. OpenNESS is a Cloud Native Computing Foundation (CNCF) certified edge computing software toolkit that helps onboard and manage applications and virtual network functions in an optimized manner for performant edge platforms.

The OpenNESS toolkit optimizes Kubernetes for the specific differences between the edge computing and the mega-scale cloud, where Kubernetes was developed.  To address the differences in requirements between cloud scale and edge computing, OpenNESS incorporates multiple Kubernetes extensions to expose and manage the unique node attributes and capabilities within the Kubernetes cluster in the edge location.  OpenNESS makes it possible to deploy applications that consume specific accelerators and compute functions in order to deploy applications with predictable and deterministic performance requirements. 

Ericsson CCD is based on Kubernetes and is a CNCF certified CaaS distribution, and this collaboration between Ericsson and Intel will help ensure that CCD supports Kubernetes services common to CNCF and OpenNESS. Essentially, this provides the performant edge CaaS capability in CCD to on-board and manage cloud native applications within a solution defined by the OpenNESS toolkit.

The Intel and Ericsson collaboration on CCD and OpenNESS is a great example of how an application development framework and a container distribution platform complement each other. Ericsson CCD manages and orchestrates all containerized applications deployed in Ericsson products, including the cloud native 5G Core. And since OpenNESS and CCD use common Kubernetes services, and as they are both CNCF certified, it would ease the burden of solution integration. As a result, enterprise applications developed using the OpenNESS edge computing software toolkit could be validated on Ericsson CCD inspired CaaS.

Customer value beyond connectivity

For CSPs to provision cloud native network functions and cloud native enterprise applications onto the same infrastructure is not only highly efficient from an infrastructure point of view; this is also where things start to get interesting and brings the story back to the question of latency sensitive services.

The trombone effect (where time critical data traffic makes an unnecessary loop) gets short-circuited when, for example, the 5G User Plane Function (UPF) – a key component of the dual-mode 5G Core that handles local break-outs of data – is deployed in the same environment as a cloud native enterprise application at the network edge.

With this set-up, where both the injection of data to an enterprise application (via UPF), and the actual provisioning of the application is handled at the edge, the low latency of 5G radio is leveraged and maintained. CSPs can offer app developers a Kubernetes based platform for time-critical use cases – and customer value beyond connectivity is created.

Want to know more?

Read more about Ericsson Cloud Container Distribution  

Read more about Ericsson Cloud Infrastructure

Read more about Ericsson Edge computing

Read more aboute Cloud native

Read more about Open Network Edge Services Software