
The 5G Core Network Demystified
Thu, 17 Aug 2023 19:29:23 -0000
|Read Time: 0 minutes
In the first blog of this 5G Core series, we looked at the concept of cloud-native design, its applications in the 5G network, the benefits and how Dell and Red Hat are simplifying the deployment and management of cloud-native 5G networks.
With this second blog post we aim to demystify the 5G Core network, its architecture, and how it stands apart from its predecessors. We will delve into the core network functions, the role of Cloud-Native architecture, the concept of network slicing, and how these elements come together to define the 5G Network Architecture.
The essence of 5G Core
5G Core, often abbreviated as 5GC, is the heart of the 5G network. It is the control center that governs all the protocols, network interfaces, and services that make the 5G system function seamlessly. The 5G Core is the brainchild of 3GPP (3rd Generation Partnership Project), a standards organization whose specifications cover cellular telecommunications technologies, including radio access, core network and service capabilities, which provide a complete system description for mobile telecommunications.
The 5G Core is not just an upgrade from the 4G core network, it is a radical transformation designed to revolutionize the mobile network landscape. It is built to handle a broader audience, extending its reach to all industry sectors and time-critical applications, such as autonomous driving. The 5G core is responsible for managing a wide variety of functions within the mobile network that make it possible for users to communicate. These functions include mobility management, authentication, authorization, data management, policy management, and quality of service (QOS) for end users.
5G Network Architecture: What You Need to Know
5G was built from the ground up, with network functions divided by service. As a result, this architecture1 is also known as the 5G core Service-Based Architecture (SBA), The 5G core is a network of interconnected services, as illustrated in the figure below.
3GPP defines that 5G Core Network as a decomposed network architecture with a service-based Architecture (SBA) where each 5G Network Function (NF) can subscribe to and register for services from other NF, using HTTP/2 as a baseline communication protocol.
A second concept in the architecture of 5G is to decrease dependencies between the Access Network (AN) and the Core Network (CN) by employing a unified access-agnostic core network with a common interface between the Access Network and Core Network that integrates diverse 3GPP and non-3GPP access type.
In addition, the 5G core decouples the user plane (UP) (or data plane) from the control plane (CP).This function, which is known as CUPS2 (Control & User Plane Separation), was first introduced in 3GPP release 14. An important characteristic of this function being that, in case of a traffic peak, you can dynamically scale the CP functions without affecting the user plane operations, allowing deployment of UP functions (UPF) closer to the RAN and User Equipment (UE) to support use cases like Ultra Reliable low latency Communication (URLLC) and achieve benefits in both Capex and Opex.
5G Core Network Functions and What They Do
The 5G Core Network is composed of various network functions, each serving a unique purpose. These functions communicate internally and externally over well-defined standard interfaces, making the 5G network highly flexible and agile. Let's take a closer look at some3 of the critical 5G Core Network functions:
User Plane Function (UPF)
The User Plane Function is a critical component of the 5G core network architecture It oversees the managment of user data during the data transmission process. The UPF serves as a connection point between the RAN and the data network. It takes user data from the RAN and performs a variety of functions like as packet inspection, traffic routing, packet processing, and QoS enforcement before delivering it to the Data Network or Internet. This function allows the data plane to be shifted closer to the network edge, resulting in faster data rates and shorter latencies. The UPF combines the user traffic transport functions previously performed in 4G by the Serving Gateway (S-GW) and Packet Data Network Gateway (P-GW) in the 4G Evolved Packet Core (EPC).
UPF Interfaces/reference points with employed protocols:
- N3 (GTP-U): Interface between the RAN (gNB) and the UPF
- N9 (GTP-U): Interface between two UPF’s (i.e the Intermediate I-UPF and the UPF Session Anchor)
- N6 (GTP-U): Interface between the Data Network (DN) and the UPF
- N4 (PFCP): Interface between the Session Management Function (SMF) and the UPF
Session Management Function (SMF)
The Session Management Function (SMF) is crucial element that make up the 5G Core Network responsible for establishing, maintaining, and terminating network sessions for User Equipment (UE). The SMF carries out these tasks using network protocols such as Packet Forwarding Control Protocol (PFCP) and Network Function-specific Service-based interface (Nsmf).
SMF communicates with other network functions like the Policy Control Function (PCF), Access and Mobility Management Function (AMF), and the UPF to ensure seamless data flow, effective policy enforcement, and efficient use of network resources. It also plays a significant role in handling Quality of Service (QoS) parameters, routing information, and charging characteristics for individual network sessions.
SMF brings some control plane functionality of the serving gateway control plane (SGW-C) and packet gateway control plane (PGW-C) in addition to providing the session management functionality of the 4G Mobility Management Entity (MME).
Access and Mobility Management Function (AMF)
The Access and Mobility Management Function (AMF) oversees the management of connections and mobility. It receives policy control, session-related, and authentication information from the end devices and passes the session information to the PCF, SMF and other network functions. In the 4G/EPC network, the corresponding network element to the AMF is the Mobility Management Entity. While the MME's functionality has been decomposed in the 5G core network, the AMF retains some of these roles, focusing primarily on connection and mobility management, and forwarding session management messages to the SMF.
Additionally, the AMF retrieves subscription information and supports short message service (SMS). It identifies a network slice using the Single Network Slice Selection Assistance Information (S- NSSAI), which includes the Slice/Service Type (SST) and Slice Differentiator (SD). The AMF's operations enable the management of Registration, Reachability, Connection, and Mobility of UE, making it an essential component of the 5G Core Network.
Policy Control Function (PCF)
The Policy Control Function (PCF) provides the framework for creating policies to be consumed by the other control plane network functions. These policies can include aspects like QOS, Subscriber Spending/Usage Monitoring, network slicing management, and management of subscribers, applications, and network resources. The PCF in the 5G network serves as a policy decision point, like the PCRF (Policy and Charging Rules Function) in 4G/EPC Network. It communicates with other network elements such as the AMF, SMF, and Unified Data Management (UDM) to acquire critical information and make sound policy decisions.
Unified Data Management (UDM) and Unified Data Repository (UDR)
The Unified Data Management (UDM) and Unified Data Repository(UDR) are critical components of the 5G core network. The UDM maintains subscriber data, policies, and other associated information, while the UDR stores this data. They collaborate to conduct data management responsibilities that were previously handled by the HSS (Home Subscriber Server) in the 4G EPC. When compared to the HSS, the UDM and UDR provide greater flexibility and efficiency, supporting the enhanced capabilities of the 5G network.
Network Exposure Function (NEF)
The Network Exposure Function (NEF) is another key component of 5G core network that enables network operators to securely expose network functionality and interfaces on a granular level by creating a bridge between the 5G core network and external application (E.g., internal exposure/re-exposure, Edge Computing). The NEF also provides a means for the Application Functions (AFs) to securely provide information to 3GPP network (E.g., Expected UE Behavior).
The NEF northbound interface is between the NEF and the AF. It specifies RESTful APIs that allow the AF to access the services and capabilities provided by 3GPP network entities and securely exposed by the NEF. It communicates with each NF through a southbound interface facilitated by a northbound API. The 3GPP interface refers to the southbound interface between NEF and 5G network functions, such as the N29 interface between NEF and Session Management Function (SMF), the N30 interface between NEF and Policy Control Function (PCF), and so on.
By opening the network's capabilities to third-party applications, NEF enables a seamless connection between network capabilities and business requirements, optimizing network resource allocation and enhancing the overall business experience.
Network Repository Function (NRF)
The Network Resource Function (NRF) serves as critical component required to implement the new service-based architecture in the 5G core network which serves as a centralized repository for all NF’s instances. It is in charge of managing the lifecycle of NF profiles, which includes registering new profiles, updating old ones, and deregistering those that are no longer in use. The NRF offers a standards-based API for 5G NF registration and discovery.
Technically, NRF operates by storing data about all Network Function (NF) instances, including their supported functionalities, services, and capacities. When a new NF instance is instantiated, it registers with the NRF, providing all the necessary details. Subsequently, any NF that needs to communicate with another NF can query the NRF for the target NF's instance details. Upon receiving this query, the NRF responds with the most suitable NF instance information based on the requested service and capacity.
How Does the 5G Core Differ from Previous Generations?
The primary architectural distinction between the 5G Core and the 4G EPC is that the 5G Core makes use of the Service-Based Architecture (SBA) with cloud-native flexible configurations of loosely coupled and independent NFs deployed as containerized microservices. The microservices based architecture provides the ability for NFs to scale and upgrade independently of each other which is significant benefit to CSPs. The 4G EPC, on the other hand, employs a flat architecture for efficient data handling with network components deployed as physical network elements in most cases and the interface between core network elements was specified as point-to-point running proprietary protocols and was not scalable.
Another significant distinction between 5G Core and EPC is the formation of the control plane (CP). The control plane functionality is more intelligently shared between Access and Mobility Management Functions (AMF) and Session Management Functions (SMF) in the 5G Core than the MME and SGW/PGW in the 4G/EPC. This separation allows for more efficient scaling of network resources and improved network performance.
In addition to the design and functional updates, the business' priorities with 5G have been updated. With 5GC, CSPs are moving away from proprietary, vertically integrated systems and shifting to cloud-native and open source-based platforms like Red Hat OpenShift Container Platform that runs on industry standard hardware. This helps improve the responsiveness while also cutting the operating expenses will be the primary focus going forward with 5G Core for CSPs.
Key distinctions between the 4G LTE and 5G QoS models
The key distinctions between 4G LTE and 5G QoS models primarily lie in their approach to quality-of-service enforcement and their level of complexity. In 4G LTE, QoS is enforced at the EPS bearer level (S5/S8 + E-RAB) with each bearer assigned an EPS bearer ID. On the other hand, 5G QoS is a more flexible approach that enforces QoS at the QoS flow level. Each QoS flow is identified by a QoS Flow ID (QFI).
Furthermore, the process of ensuring end-to-end QoS for a Packet Data Unit (PDU) session in 5G involves packet classification, user plane marking, and mapping to radio resources. Data Packets are classified into QoS flows by UPF using Packet Detection Rules (PDRs) for downlink and QoS rules for uplink.
5G leverages Service Data Adaptation Protocol (SDAP) for mapping between a QOS flow from the 5G core network and a data radio bearer (DRB). This level of control and adaptability provides an improved QoS model in 5G as compared to 4G networks.
The Power of Cloud-Native Architecture in 5G Core
One of the standout features of the 5G Core is its cloud-native architecture. This architecture allows the 5G core network to be built with microservices that can be reused for supporting other network functions. The 5G core leverages technologies like microservices, containers, orchestration, CI/CD pipelines, APIs, and service meshes, making it more agile and flexible.
With Cloud-Native architecture, 5G Core can be easily deployed and operated, offering a cost-effective solution that complies with regulatory requirements and supports a wide range of use cases. The adherence to cloud-native principles is of utmost importance as it allows for the independent scaling of components and their dynamic placement based on service demands and resource availability. This architecture also allows for network slicing, which enables the creation of end-to-end virtual networks on top of a shared infrastructure.
Network Slicing: Enabling a Range of 5G Services
Network Slicing is considered as one of the key features by 3GPP in 5G. A network slice can be looked like a logical end-to-end network that can be dynamically created. A UE may access to multiple slices over the same gNB, within a network slice, UEs can create PDU sessions to different Gateways via Data network name (DNNs). This architecture allows operators to provide a custom Quality of Service (QoS) for different services and/or customers with agreed upon Service-level Agreement (SLA).
The Network Slice Selection Function (NSSF) plays a vital role in the network slicing architecture of 5G Core. It facilitates the process of selecting the appropriate network slice for a device based on the Network Slice Selection Assistance Information (NSSAI) specified by the device. When a device sends a registration request, it mentions the NSSAI, thereby indicating its network slice preference. The NSSF uses this information to determine which network slice would best meet the device's requirements and accordingly assigns the device to that network slice. This ability to customize network slices based on specific needs is a defining feature of 5G network slicing, enabling a single physical network infrastructure to cater to a diverse range of services with contrasting QOS requirements. To read and learn more on Network Slicing check out this amazing blog post To slice or not to slice | Dell Technologies Info Hub.
Next steps
To learn how Dell and Red Hat are helping CSPs in their cloud-native journey, see the blog Cloud-native or Bust: Telco Cloud Platforms and 5G Core Migration on Info Hub. In the next blog of the 5G Core series, we will explore the collaboration between Dell Technologies and Red Hat to simplify operator processes, starting from the initial technology onboarding all the way to Day 2 operations. The focus is on deploying a telco cloud that supports 5G core network functions using Dell Telecom Infrastructure Blocks for Red Hat.
To learn more about about Telecom Infrastructure Blocks for Red Hat, kindly visit our website Dell Telecom Multi-Cloud Foundation solutions.
1 The 5G Architecture shown here is the simplified version, there are other 5G NFs like UDSF, SCP, BSF, SEPP, NWDAF, N3IWF etc. not shown here.
2 CUPS is a pre-5G technology (5G Standalone (SA) was introduced in 3GPP Rel-15). 5G SA offers more innovation with the ability to change anchors (SSC Mode 3), daisy chain UPFs, and connect to multiple UPFs.
3 The Network Functions mentioned in this section are a subset of the standardized NFs in 5G Core network.
Authored by:
Gaurav Gangwal
Senior Principal Engineer – Technical Marketing, Product Management
About the author:
Gaurav Gangwal works in Dell's Telecom Systems Business (TSB) as a Technical Marketing Engineer on the Product Management team. He is currently focused on 5G products and solutions for RAN, Edge, and Core. Prior to joining Dell in July 2022, he worked for AT&T for over ten years and previously with Viavi, Alcatel-Lucent, and Nokia. Gaurav has an Engineering degree in Electronics and Telecommunications and has worked in the telecommunications industry for about 14+ years. He currently resides in Bangalore, India.
Kevin Gray
Senior Consultant, Product Marketing – Product Marketing
About the author:
Kevin Gray leads marketing for Dell Technologies Telecom Systems Business Foundations solutions. He has more than 25 years of experience in telecommunications and enterprise IT sectors. His most recent roles include leading marketing teams for Dell’s telecommunications, enterprise solutions and hybrid cloud businesses. He received his Bachelor of Science in Electrical Engineering from the University of Massachusetts in Amherst and his MBA from Bentley University. He was born and raised in the Boston area and is a die-hard Boston sports fan.
The 5G Core Network is composed of various network functions, each serving a unique purpose. These functions communicate internally and externally over well-defined standard interfaces, making the 5G network highly flexible and agile. Let's take a closer look at some3 of the critical 5G Core Network functions:
Related Blog Posts

Cloud-native or Bust: Telco Cloud Platforms and 5G Core Migration
Wed, 24 May 2023 12:45:00 -0000
|Read Time: 0 minutes
Breaking down barriers with an open, disaggregated, and cloud-native 5G Core
As 5G network rollouts accelerate, communication service providers (CSPs) around the world are shifting away from purpose-built, vertically integrated solutions in favor of open, disaggregated, and cloud-native architectures running containerized network functions. This allows them to take advantage of modern DevSecOps practices and an emerging ecosystem of telecom hardware and software suppliers delivering cloud-native solutions based on open APIs, open-source software, and industry-standard hardware to boost innovation, streamline network operations, and reduce costs.
To take advantage of the benefits of cloud-native architectures, many CSPs are moving their 5G Core network functions onto commercially available cloud native application platforms like Red Hat OpenShift, the industry's leading enterprise Kubernetes platform. However, building an open, disaggregated telco cloud for 5G Core is not easy and it comes with its own set of challenges that need to be tackled before large scale deployments.
In an disaggregated network, the system integration and support tasks become the CSP's responsibility. To achieve their objectives for 5G, they must:
Accelerate the introduction and management of new technologies by simplifying and streamlining processes from Day 0, network design and integrations tasks, to Day 1 deployment, and Day 2 lifecycle management and operations.
Break down digital silos to deploy a horizontal cloud platform to reduce CapEx and OpEx while lowering power consumption
Deploy architectures and technologies that consistently meet strict telecom service level agreements (SLAs).
Digging into the challenges of deploying 5G Core network functions on cloud infrastructure
This will be a five-part blog series that addresses the challenges when deploying 5G Core network functions on a telco cloud.
In this first blog, we will highlight CSPs’ key challenges as they migrate to an open, disaggregated, and cloud-native ecosystem;
The next blog will explore the 3GPP 5G Core network architecture and its components;
The third blog in the series will discuss how Dell Technologies is working with Red Hat to streamline operator processes from initial technology onboarding through Day 2 operations when deploying a telco cloud to support core network functions;
The fourth blog will focus on how Dell Telecom Infrastructure Blocks for Red Hat can help CSPs move to a horizontal cloud platform to reduce costs and power consumption;
The final blog in the series will discuss how Dell is integrating Intel technology that consistently meets CSP SLAs for 5G Core network functions.
Accelerating the introduction and simplifying the management of 5G Core network functions on cloud infrastructure
Cloud native architectures offer the potential to achieve superior performance, agility, flexibility, and scalability, resulting in easily updated, scaled, and maintained Core network functions with improved network performance and lower operational costs. Nevertheless, operating 5G Core network functions on a telco cloud can be difficult due to new challenges operators face in integration, deployment, lifecycle management, and developing and maintaining the right skill sets.
Different integration and validation requirements
Open multi-vendor cloud-native architectures require the CSP to take on more ownership of design, integration, validation, and management of many complex components, such as compute, storage, networking hardware, the virtualization software, and the 5G Core workload that runs on top. This increases the complexity of deployment and lifecycle management processes while requiring investment in development of new skill sets.
Complexity of the deployment process demands automation
5G Core deployment on a telco cloud platform can be a complex process that requires integrating multiple systems and components into a unified whole with automated deployment from the hardware up through the Core network functions. This complexity creates the need for automation that not only to streamlines processes, but also ensures a consistent deployment or upgrade each time that aligns with established configuration best practices. Many CSPs may lack deployment experience with automation and cloud native tools making this a difficult task.
Lifecycle management and orchestration of a disaggregated 5G Core
The size and complexity of the 5G Core can make lifecycle management and orchestration challenging. Every one of the components starts a new validation cycle and increases the risk of introducing security vulnerabilities and configuration issues into the environment.
Lack of cloud-native skills and experience
Managing a telco cloud requires a different set of skills and expertise than operating traditional networks environments. CSPs often need to acquire additional staff and invest in cloud native training and development to obtain the skills and experience to put cloud native principles into practice as they build, deploy, and manage cloud-native applications and services.
Breaking down vertical silos with a horizontal, 5G telco cloud platform
In recent years, many CSPs embarked on a journey away from vertically integrated, proprietary appliances to virtualized network functions (VNFs). One of the goals when adopting network functions virtualization was to obtain greater freedom in selecting hardware and software components from multiple suppliers, making services more cost-effective and scalable. However, CSPs often experiences difficulties in designing, integrating and testing their individual stacks, resulting in higher integration costs, interoperability issues and regression testing delays leading to less efficient operations.
Despite efforts to move to virtualized network functions, silos of vertically integrated cloud deployments can emerge where the virtual network functions suppliers define their own cloud stack to simplify their process of meeting the requirements for each workload. These vertical silos prevented CSPs from pooling resources, which can reduce infrastructure utilization rates and increase power consumption. It also increases the complexity of lifecycle management as each layer of the stack for each silo needs to be validated whenever a change to a component of the stack is made.
Vertically integrated 5G Core stack on a telco cloud
CSPs are now looking to implement a horizontal platform that can provide a common cloud infrastructure to help break down these silos to lower costs, reduce power consumption, improve operational efficiency, and minimize complexity allowing CSPs to adopt cloud native infrastructure from the core to the radio access network (RAN).
Horizontal platform for 5G telco workloads
Maintaining compliance with telecom industry SLAs
Creating and managing a geographically dispersed telco cloud based on a broad range of suppliers while consistently adhering to CSP SLAs takes a lot of effort, resources and time and can introduce new complications and risks. To meet these SLAs and accelerate the introduction of new technologies, CSPs will need a novel approach when working with vendors that reduces integration and deployment times and costs while simplifying ongoing operations. This will include developing a tighter relationship with their supply base to offload integration tasks while maintaining the flexibility provided by an open telecom ecosystem. As an example, Vodafone recently introduced a paper outlining their vision for a new operating model to improve systems integrations with their supply base to help achieve these objectives. It would also include following a proven path in enterprise IT by adopting engineered systems, similar to the converged and hyper converged systems used by IT today, that have been optimized for telecom use cases to simplify deployment, scaling and management.
Short-term total cost of ownership (TCO)
When it comes to optimizing short-term TCO, there are several options available to CSPs. One such option is to work closely with vendors in order to reduce integration, deployment times and costs while simplifying ongoing operations. This approach can help CSPs leverage the expertise of vendors who specialize in the software and hardware components required for a disaggregated telco cloud. By working with skilled vendors, CSPs can reduce the risk of validating and integrating components themselves, which can lead to cost savings in the short term.
Another option that CSPs can consider is to adopt a phased approach to implementation. This involves deploying disaggregated telco cloud technologies in stages, starting with the most critical components and gradually expanding to include additional components over time. This approach can help to mitigate the initial costs associated with disaggregated telco cloud adoption while still realizing the benefits of increased flexibility, scalability, and cost efficiency.
CSPs can also take advantage of initiatives like Vodafone's new operating model for improving systems integrations with their supply base. This model aims to simplify the process of integrating components from multiple vendors by providing a standardized framework for testing and validation. By adopting frameworks like this, CSPs can reduce the time and costs associated with integrating components from multiple vendors, which can help to optimize short-term TCO.
Although implementing a disaggregated telco cloud can increased investment in the short term, there are several options available to CSPs for optimizing short-term TCO. Whether it's working closely with trusted vendors, adopting a phased approach, or leveraging standardized frameworks, CSPs can take steps to reduce costs and maximize the benefits of a disaggregated telco cloud.
Your partners for simplifying telco cloud platform design, deployment, and operations
Dell and Red Hat are leading experts in cloud-native technology used in building 5G networks and are working together to simplify their deployment and management for CSPs. Dell Telecom Infrastructure Blocks for Red Hat is a solution that combines Dell's hardware and software with Red Hat OpenShift, providing a pre-integrated and validated solution for deploying and managing 5G Core workloads. This offering enables CSPs to quickly launch and scale 5G networks to meet market demand for new services while minimizing the complexity and risk associated with deploying cloud-native infrastructure.
Next steps
In the next blog we will dive deeper into the the service-based architecture of the 5G Core architecture and how it was developed to support cloud native principles. To learn more about how Dell Technologies and Red Hat are partnering to simplify the deployment and management of a telco cloud platform built to support 5G Core workloads, see the ACG Research Industry Directions Brief: Extending the Value of Open Cloud Foundations to the 5G Network Core with Telecom Infrastructure Blocks for Red Hat.
Authored by:
Gaurav Gangwal
Senior Principal Engineer – Technical Marketing, Product Management
About the author:
Gaurav Gangwal works in Dell's Telecom Systems Business (TSB) as a Technical Marketing Engineer on the Product Management team. He is currently focused on 5G products and solutions for RAN, Edge, and Core. Prior to joining Dell in July 2022, he worked for AT&T for over ten years and previously with Viavi, Alcatel-Lucent, and Nokia. Gaurav has an Engineering degree in Electronics and Telecommunications and has worked in the telecommunications industry for about 14+ years. He currently resides in Bangalore, India.
Kevin Gray
Senior Consultant, Product Marketing – Product Marketing
About the author:
Kevin Gray leads marketing for Dell Technologies Telecom Systems Business Foundations solutions. He has more than 25 years of experience in telecommunications and enterprise IT sectors. His most recent roles include leading marketing teams for Dell’s telecommunications, enterprise solutions and hybrid cloud businesses. He received his Bachelor of Science in Electrical Engineering from the University of Massachusetts in Amherst and his MBA from Bentley University. He was born and raised in the Boston area and is a die-hard Boston sports fan.

What is Happening in the Network Edge
Mon, 26 Jun 2023 10:59:44 -0000
|Read Time: 0 minutes
Where is the Network Edge in Mobile Networks
The notion of ‘Edge’ can take on different meanings depending on the context, so it’s important to first define what we mean by Network Edge. This term can be broadly classified into two categories: Enterprise Edge and Network Edge. The former refers to when the infrastructure is hosted by the company using the service, while the latter refers to when the infrastructure is hosted by the Mobile Network Operator (MNO) providing the service.
This article focuses on the Network Edge, which can be located anywhere from the Radio Access Network (RAN) to next to the Core Network (CN). Network Edge sites collocated with the RAN are often referred to as Far Edge.
What is in the Network Edge
In a 5G Standalone (5G SA) Network, a Network Edge site typically contains a cloud platform that hosts a User Plane Function (UPF) to enable local breakout (LBO). It may include a suite of consumer and enterprise applications, for example, those that require lower latency or more privacy. It can also benefit the transport network when large content such as Video-on-Demand is brought closer to the end users.
Modern cloud platforms are envisioned to be open and disaggregated to enable MNOs to rapidly onboard new applications from different Independent Software Vendors (ISV) thus accelerating technology adoption. These modern cloud platforms are typically composed of Commercial-of-the-Shelf (COTS) hardware, multi-tenant Container-as-a-Service (CaaS) platforms, and multi-cloud Management and Orchestration solutions.
Similarly, modern applications are designed to be cloud-native to maximize service agility. By having microservices architectures and supporting containerized deployments, MNOs can rapidly adapt their services to meet changing market demands.
What contributes to Network Latency
The appeal of Network Edge or Multi-access Edge Computing (MEC) is commonly associated with lower latency or more privacy. While moving applications from beyond the CN to near the RAN does eliminate up to tens of milliseconds of delay, it is also important to understand that there are many other contributors to network latency which can be optimized. In fact, latency is added at every stage from the User Equipment (UE) to the application and back.
RAN is typically the biggest contributor to network latency and jitter, the latter being a measure of fluctuations in delay. Accordingly, 3GPP has introduced a lot of enhancements in 5G New Radio (5G NR) to reduce latency and jitter in the air interface. We can actively reduce latency through the following categories: There are three primary categories where latency can be reduced:
- Transmission time: reduce symbol duration with higher subcarrier spacing or with mini slots
- Waiting time: improve scheduling (optimize handshaking), simultaneous transmit/receive, and uplink/downlink switching with TDD
- Processing time: reduce UE and gNB processing and queuing with enhanced coding and modulation
Transport latency is relatively simple to understand as it is mainly due to light propagation in optical fiber. The industry rule of thumb is 1 millisecond round trip latency for every 100 kilometers. The number of hops along the path also impacts latency as every transport equipment adds a bit of delay.
Typically, CN adds less than 1 millisecond to the latency. The challenge for the CN is more about keeping the latency low for mobile UEs, by seamlessly changing anchors to the nearest Edge UPF through a new procedure called ‘make before break’. Also, the UPF architecture and Gi/SGi services (e.g., Deep Packet Inspection, Network Address Translation, and Content Optimization) may add a few additional milliseconds to the overall latency, depending on whether these functions are integrated or independent.
Architectural and Business approaches for the Network Edge
The physical locations that host RAN and Network Edge functionalities are widely recognized to be some of the MNOs’ most valuable assets. Few other entities today have the real estate and associated infrastructure (e.g., power, fiber) to bring cloud capabilities this close to the end clients. Consequently, monetization of the Network Edge is an important component of most MNOs’ strategy for maximizing their investment in the mobile network and, specifically, in 5G. In almost all cases, the Network Edge monetization strategy includes making Network Edge available for Enterprise customers to use as an “Edge Cloud.” However, doing so involves making architectural and business model choices across several dimensions:
- Connectivity or Cloud: should the MNO offer a cloud service or just the connectivity to a cloud service provided by a third party (and potentially hosted at a third party’s site).
- aaS model: in principle, the full range of as-a-Service models are available to the MNO to offer at the network edge. This includes co-location services; Bare-Metal-as-a-Service, Infrastructure-as-a-Service (IaaS), Containers-as-a-Service (CaaS), and Platform and Software-as-a-Service (PaaS and SaaS). Going up this value chain (up being from co-lo to SaaS) allows the MNO to capture more of the value provided to the Enterprise. However, it also requires it to take on significantly more of responsibility and puts it in direct competition with well-established players in this space – e.g., the cloud hyperscale companies. The right mix of offerings – and it is invariably a mix – thus involves a complex set of technical and business case tradeoffs. The end result will be different for every MNO and how each arrives there will also be unique.
- Management framework: our industry’s initial approach to exposing the Network Edge to the enterprises involved a management framework that tightly couples to how the MNO manages its network functions (e.g., the ETSI MEC family of standards for example (ETSI MEC)). However, this approach comes with several drawbacks from an Enterprise point of view. As a result, a loosely coupled approach, where the Enterprise manages its Edge Cloud applications using typical cloud management solutions appears to be gaining significant traction, with solutions such as Amazon’s Wavelength as an example. This approach, of course, has its own drawbacks and managing the interplay between the two is an important consideration in Network Edge (and one that is intertwined with the selection of aaS model).
- Network-as-a-Service: a unique aspect of the Network Edge is the MNOs ability to expose network information to applications as well as the ability to provide those applications (highly curated) means of controlling the network. How and if this makes sense is again both an issue of the business case – for the MNO and the Enterprise – as well as a technical/architectural issue.
Certainly, the likely end state is a complex mixture of services and go-to-market models focused on the Enterprise (B2B) segment. The exposition of operational automation and the features of 5G designed to address this make it likely that this is a huge opportunity for MNOs. Navigating the complexities of this space requires a deep understanding of both what services the Enterprises are looking for and how they are looking to consume these. It also requires an architectural approach that can handle the variable mix of what is needed in a way that is highly scalable.
As the long-time leader in Enterprise IT services, Dell is uniquely positioned to address this space – stay tuned for more details in an upcoming blog!
Building the Network Edge
There are several factors to consider when moving workloads from central sites to edge locations. Limited space and power are at the top of the list. The distance of locations from the main cities and generally more exposed to the elements require a new class of denser, easier-to-service, and even ruggedized form factors. Thanks to the popularity of Open RAN and Enterprise Edge, there are already solutions in the market today that can also be used for Network Edge. Read more on Edge blog series Computing on the Edge | Dell Technologies Info Hub
Higher deployment and operating costs are another major factor. The sheer number of edge locations combined with their degraded accessibility make them more expensive to build and maintain. The economics of the Network Edge thus necessitates automation and pre-integration. Dell’s solution is the newly engineered cloud-native solution with automated deployment and life-cycle management at its core. More on this novel approach here Dell Telecom MultiCloud Foundation | Dell USA.
Last is the lower cost of running applications centrally. Central sites have the advantage of pooling computes and sharing facilities such as power, connectivity, and cooling. It is therefore important to reduce overhead wherever possible, such as opting for containerized over VM-based cloud platforms. Moreover, having an open and disaggregated horizontal cloud platform not only allows for multitenancy at edge locations, which significantly reduces overhead but also enables application portability across the network to maximize efficiency.
The ideal situation is where Open/Cloud RAN and Network Edge are sharing sites thus splitting several of the deployment and operations costs. Due to the latency requirements, Distributed Unit (DU) must be placed within 20 kilometers of the Radio Unit (RU). Latency requirements for the mid-haul interface between DU and Central Unit (CU) are less stringent, and CU could be placed roughly around 80-100 kilometers from the DU. In addition, the Near-Real Time Radio Intelligent Controller (Near-RT RIC) and the related xApps must be placed within 10ms RTT. This makes it possible to collocate Network Edge sites with the CU sites and Near-RT RIC.
Future
What has happened over the past few years is that several MNOs have already moved away from having 2-3 national DCs for their entire CN to deploying 5-10 regional DCs where some network functions such as the UPF were distributed. One example of this is AT&Ts dozen “5G Edge Zones” which were introduced in the major metropolitan areas: AT&T Launching a Dozen 5G “Edge Zones” Across the U.S. (att.com).
This approach already suffices for the majority of “low latency” use cases and for smaller countries even the traditional 2-3 national DCs can offer sufficiently low transport latency. However, when moving into critical use cases with more stringent latency requirements, which means consistently very low latency is a must, then moving the applications to the Far Edge sites becomes a necessity in tandem with 5G SA enhancements such as network slicing and an optimized air interface.
The challenge with consumer use cases such as cloud gaming is supporting the required Service Level (i.e., low latency) country wide. And since enabling the network to support this requires a substantial initial investment, we are seeing the classic chicken and egg problem where independent software vendors opt not to develop these more demanding applications while MNOs keep waiting for these “killer use cases” to justify the initial investment for the Network Edge. As a result, we expect geographically limited enterprise use cases to gain market traction first and serve as catalysts for initially limited Network Edge deployments.
For use cases where assured speeds and low latency are critical, end-to-end Network Slicing is essential. In order to adopt a new more service-oriented approach, MNOs will need Network Edge and low latency enhancements together with Network Slicing in their toolbox. For more on this approach and Network Slicing, please check out our previous blog To slice or not to slice | Dell Technologies Info Hub.
About the author: Tomi Varonen
Tomi Varonen is a Telecom Network Architect in Dell’s Telecom Systems Business Unit. He is based in Finland and working with the Cloud, Core Network, and OSS&BSS customer cases in the EMEA region. Tomi has over 23 years of experience in the Telecom sector in various technical and sales positions. Wide expertise in end-to-end mobile networks and enjoys creating solutions for new technology areas. Passion for various outdoor activities with family and friends including skiing, golf, and bicycling.
About the author: Arthur Gerona
Arthur is a Principal Global Enterprise Architect at Dell Technologies. He is working on the Telecom Cloud and Core area for the Asia Pacific and Japan region. He has 19 years of experience in Telecommunications, holding various roles in delivery, technical sales, product management, and field CTO. When not working, Arthur likes to keep active and travel with his family.
About the author: Alex Reznik
ALEX REZNIK is a Global Principal Architect in Dell Technologies Telco Solutions Business organization. In this role, he is focused on helping Dell’s Telco and Enterprise partners navigate the complexities of Edge Cloud strategy and turning the potential of 5G Edge transformation into the reality of business outcomes. Alex is a recognized industry expert in the area of edge computing and a frequent speaker on the subject. He is a co-author of the book "Multi-Access Edge Computing in Action." From March 2017 through February 2021, Alex served as Chair of ETSI’s Multi-Access Edge Computing (MEC) ISG – the leading international standards group focused on enabling edge computing in access networks.
Prior to joining Dell, Alex was a Distinguished Technologist in HPE’s North American Telco organization. In this role, he was involved in various aspects of helping Tier 1 CSPs deploy state-of-the-art flexible infrastructure capable of delivering on the full promises of 5G. Prior to HPE Alex was a Senior Principal Engineer/Senior Director at InterDigital, leading the company’s research and development activities in the area of wireless internet evolution. Since joining InterDigital in 1999, he has been involved in a wide range of projects, including leadership of 3G modem ASIC architecture, design of advanced wireless security systems, coordination of standards strategy in the cognitive networks space, development of advanced IP mobility and heterogeneous access technologies and development of new content management techniques for the mobile edge.
Alex earned his B.S.E.E. Summa Cum Laude from The Cooper Union, S.M. in Electrical Engineering and Computer Science from the Massachusetts Institute of Technology, and Ph.D. in Electrical Engineering from Princeton University. He held a visiting faculty appointment at WINLAB, Rutgers University, where he collaborated on research in cognitive radio, wireless security, and future mobile Internet. He served as the Vice-Chair of the Services Working Group at the Small Cells Forum. Alex is an inventor of over 160 granted U.S. patents and has been awarded numerous awards for Innovation at InterDigital.