It’s almost impossible to talk about 5G without using words like “game-changing,” “revolutionary,” and “breakthrough.” And while we tech bloggers tend to use these words a lot, it’s not hyperbole in this case: 5G standards really are much more ambitious than the capabilities of LTE and legacy networks. But in order to deliver on the promises of 5G networks, the devices and applications using them will need to be as efficient as possible.
Accomplishing something big is almost impossible without breaking it into smaller, more manageable components—which is exactly what modern applications do. Today, we’ll examine the role of microservices in 5G networks.
Monolithic Applications vs. Microservices
Previously in this series, we discussed how applications evolved from monoliths—which were built and released all at once—to collections of independent functions or microservices. These small, self-contained components are each designed to do one thing well, and are developed and released as such. This facilitates easier development and enables new features to be deployed without overhauling the entire application.
Not only do microservices make applications vastly easier to develop and deploy, they come with a wealth of other benefits:
- Easier to scale
- Enables serverless management and automation
- Lower latency
- Resource efficient
But perhaps the most important long-term benefit of microservices is that they are needed to interact with 5G network architecture. To understand why applications and networks must be designed this way, it’s important to first remember what 5G networks were designed to do.
5G Requirements
As discussed in previous posts, the advantages of 5G over 4G and other legacy networks can be broadly divided into three categories of communication:
- Extreme mobile broadband (eMBB): Enhanced mobile device performance for consumers that enables faster downloads, larger data transmissions, lower latency, and higher device density.
- Ultra-reliable low-latency communications (URLCC or Critical IoT): Mission-critical services that rely on millisecond latency, such as automated driving.
- Massive machine-type communications (mMTC or Massive IoT): Huge numbers of sensors and other energy-efficient IoT devices with infrequent transmissions for use in factories and smart cities.
All three of these use cases have incredibly demanding KPIs in terms of latency, throughput, reliability, and other capabilities, but their specific requirements are a bit different, requiring different network deployments to accommodate those needs. Flexible deployments are not only needed for agile delivery, but to ensure 5G networks can interact and partner with LTE networks until standalone 5G networks are able to scale.
As a result, 5G networks are built from the ground up to be both highly modular and highly interoperable. Today, we’re going to discuss two of the architectural principles that provide these qualities: network slicing and CUPS, which stands for control and user plane separation.
5G Architectural Principles
Network Slicing
Network slicing is the architectural principle of 5G networks that allows for agility in delivering different QoS for various applications or application functions. The ITU provides a good working definition of a network slice as “a logical network serving a defined business purpose or customer, consisting of all required network resources configured together.” This includes the PLMN, control plane, user plane network functions, and 5G access network and could consist of services from a single operator or incorporate services from multiple operators.
In other words, a “slice” is a piece of a 5G network that includes all the individual components needed to run an application on that network—sort of like how containers divide up VMs into individual units with everything needed to run a specific microservice. Just like containers must be orchestrated to run and scale an application as needed, a slice service orchestrator monitors and manages the lifecycle of network slices, automatically assigning resources and creating, modifying, and deleting slices as needed to optimize performance.
Vertical vs. Horizontal Slicing
Network slicing can be done horizontally or vertically, but is most frequently discussed in reference to horizontal slicing. Horizontal slicing divides a network according to the SLAs of each application—or more specifically, that application’s individual functions. This allows URLLC, mMTC, and eMBB use cases to be delivered separately and enables more customization in how latency, energy efficiency, and other KPIs are prioritized.
In contrast, vertical slicing divides a network by businesses, putting the control of that slice in the hands of the enterprise itself. This allows enterprises more autonomy, removing the need for network operators to serve as middlemen.
Horizontal slicing
- Multi-tenant
- Networks are divided by functions
- Operators control resources
- Services can be customized for specific apps, users, devices, or contexts
Vertical slicing
- Single tenant
- Networks are divided by enterprise
- Enterprise controls resources
- Services can be customized for specific apps, users, devices, or contexts
Whether slicing is done horizontally or vertically, the ability to create multiple networks with shared infrastructure not only results in better performance, it provides numerous practical benefits for operators, such as cost efficiency and pricing according to different tenets’ needs and usage. However, locating and scaling resources for efficient network slicing requires the use of another 5G architectural principle: control and user plane separation, or CUPS.
CUPS
Separating the control and user planes is nothing new. 4G LTE’s core architecture, the Evolved Packet Core (EPC), introduced this idea to mobile networking as a means of providing more flexible service to mobile device users. This was needed to accomodate more prevalent and less predictable device use, ranging from small, intermittent packages sent by IoT sensors to entire movies streamed on smartphones. Separating the control plane (which decides how packets should be forwarded) from the user plane (which forwards the packets) made it easier to handle these variant circumstances.
EPC vs. 5GC
Not all elements of the user plane and control plane are completely separated in EPC, however. The EPC protocol stack includes the Mobility Management Entity Protocols (MME), the serving gateway (SGW), and packet data gateway (PGW). Increasingly, mobile networks are also including another element, the traffic detection function (TDF). In EPC, the control and user planes are separated for MME, which takes care of a lot of important functions, like load balancing between different SGWs. However, the gateways themselves (as well as the TDF) share functions between the control and user plane, creating bottlenecks as device usage intensifies.
Today, the popularity of video streaming and other data-hungry applications are already putting incredible strain on SGWs. Since 5G will only accelerate the amount of data individual users are consuming, the 5G core (5GC) is designed to solve this problem by separating the control and user plane functionality for the SGW, PGW, and TDF.
Benefits of CUPS
By completely detaching the control and user plane of the evolved packet core (EPC), CUPS allows the two planes to be hosted in separate locations, with a centralized control plane and a user plane closer to end users. In addition, it allows the two planes to scale independently from each other without affecting their functionality. This results in a host of benefits best summarized by 3GPP in their Release 14 specification of CUPS:
- Reduced latency on application services
- Increased data traffic
- Ability to independently locate and scale CP and UP resources
- Ability to independently evolve CP and UP
- More efficient delivery of user plane data through Software Defined Networking
Modern App Design for 5G Architecture
Just like the networks they’ll run on, 5G applications also need to be highly modular and interoperable. Monolithic applications cannot accommodate 5G architectural principles like network slicing that require functionality to be broken up to and automated to meet different QoS. In addition, CUPS is designed to move the user plane closer to end users, requiring applications to be as lightweight as possible to accommodate the resource scarcity of Multi-Access Edge Computing.
Finally, breaking applications into microservices and functions allows them to be more interoperable and reusable. Network Slicing and CUPS are enabled by 5G’s Service-Based Architecture, consisting of different network functions that interact via APIs to consume and produce services.
Conclusion
The modular design elements of 5G networks will require monolithic applications to be completely redesigned for 5G. However, transitioning to modern application architecture can be challenging. Using a serverless approach can make this transition simpler by sidestepping the difficulties of provisioning, scaling, and maintaining the underlying resources needed to run individual functions. In addition, managing next-generation applications is a complex task, requiring software-defined Virtual Network Functions (VNF) to enable automation and orchestration of their underlying resources.
Azion’s Edge Computing products are designed to make it easier for businesses to build and run modern applications. Edge Functions lets you create serverless functions to smoothly transition legacy applications to a cloud-based architecture. With Edge Functions, you can execute event-driven functions at the edge of the network by writing your own custom code, or choose from existing Edge Firewall or Edge Application functions. And since you only pay when your code runs, it allows you to migrate workloads in the most cost-effective way possible. In addition, Edge Orchestrator enables customers to deploy and manage NFVs (Network Functions Virtualization) to their edge locations. Edge Orchestrator is highly interoperable and designed to operate on most network architectures and device types, so that you can build out edge infrastructure, connect to 5GC, and automate, manage, and control edge resources in real time.
In our next post in this series, we’ll take a look at one of the most exciting capabilities outlined in 3GPP’s most recent release: the creation of private 5G networks. The ability of enterprises to create custom networks tailored to their organization’s unique needs enables new business opportunities, which we’ll examine in next week’s post, along with some of the other 5G features specified in 3GPP’s Release 16.
