Defining 5G Services
What is a 5G Service?
With the promises of 5G (lower latency, increased throughput, increase in the number of connected devices to name a few) emerges the grouping of 5G use cases into classes such as mMTC (massive Machine type communication), uRLLC (ultra-reliable low latency) and mMTC (Massive machine type communication). These use cases or service types enable new market segments where service providers can expand their business model. Below is a service map and a quick summary of the differentiating services and characteristics aligning them to one or multiple use case.
- Massive Machine Type Communication:
- Connectivity for millions of devices is the main scenario or use case
- Not latency critical and requires relatively low bandwidth
- Devices are generally low cost with low battery life (IoT etc)
- Critical Machine Type Communication
- Resilient, instantaneoud connectivity are key useage scenarios
- There are stringent throughput, latency and availability requirements
- Some examples would include the wireless control of industrial manufacturing, remote medical surgery, smart grid distribution automation etc
- Enhanced Mobile Broadband
- Usage scenario would be the need to ensure massive mobility connectivity
- Data Rates, connection density and mobility
- Some use cases include gaming, AR/VR
5G Key System Areas
A 5G network consists of many layers that are all required to run in real time, on multiple clouds and across a distributed network. Below is a quick overview of each of these layers that compose a mobile network
- Application Cloud – This area adds the opportunities for new business with exposure of cloud capabilities for enterprises and/or governments to facilitate deployment of cloud based applications with different degree of SLAs attached.
- Management & Monetization – This is the layer that contains BSS, Customer, Business & Partner management, OSS (Network & Cloud mgmt) Service & Network orchestration as well as Analytics & Exposure that adds actionable insights about user experience and network performance.
- Network Slices – This is dedicated connections , SLA-optimized per service both in terms of cost & performance. Network slices could also be “offered” or exposed for enterprises. E.g. large scale of sensors can be connected in a very cost effective way.
- Access, Mobility & Network Applications – VNFs, (software) can be deployed or trialed, very quickly compared to traditional appliances.
- Cloud Infrastructure – Offers a more effective and versatile infrastructure than purpose built hardware appliances. Redundancies can be applied in software instead of hardware.
- Transport – Microwave links, Routers and Optical transport are increasingly improved with scale & capacity. SDN programmability make the utilization higher as well as time to market with VPN services & Software Defined Wide Area Networks (SD WAN)
Figure 8: High Level Service Provider Network View
5G Cloud Infrastructure
Implementing a Service Based Architecture (SBA), cloud native infrastructure is a crucial first step in deploying a standalone (SA) 5G Core network. A critical inflection point is occurring as service providers implement SBA are entering into an application centric world where workloads can be dynamically scaled in real time to meet the ever-changing consumer demands. 5G makes it possible to deploy and manage distributed networks needed to satisfy the growing number of enterprise initiatives from Industry 4.0, Smart Cities, Fintech to autonomous vehicles. Service providers now need to build a multi-cloud network to satisfy the increasing demand for instantaneous access to cloud services from the core, edge and far-edge of the network. 5G cloud native infrastructure is the catalyst that merges traditional service provider “IT” and “network” groups creating an IT centric 5G network.
The one size fits all approach no longer applies to 5G networks where multiple cloud deployments are merely a starting point. 5G infrastructure is built on a cloud-native containerized architecture where container workloads are managed using Kubernetes which orchestrates applications based on network requirements. However, Kubernetes was not specifically designed for carrier grade deployments and the business need for Service Providers to keep complexity and cost to a minimum. This drives the need to prioritize the following requirements when designing and deploying 5G Cloud Native Infrastructure:
- Visibility: Network traffic visibility is vital in any mobile network and even more so in a 5G network. Kubernetes inherently does not provide ingress or egress traffic visibility into the Kubernetes nodes and clusters.
- Security: Security controls need to be applied at multiple points in the network and across multiple layers. Enabling packet capture and the ability implement security at container ingress is critical in ensuring that bad traffic stays out of a Service Provider’s network. Enabling encryption is also fundamental in a 5G network security offering.
- Control: Policy management and analytics enable network control and are essential in automating an already complex 5G network.
Service providers migrating to a 5G Cloud Native environment will have a combination of Physical Networks Functions (PNFs), Virtual Networks Functions (VNFs) and Cloud Native Networks Functions (CNFs). 4G LTE networks are still experiencing some growth and will need to be supported alongside 5G Non standalone NR and 5G CORE.
Cloud Native 5G architecture along with containers are critical in enabling diversified service requirements. A container is a software package with the entire toolset needed to run an application. Containers are lightweight and efficient for quick development time and they provide security as there are no software dependencies outside of the container. Container workloads are managed with Kubernetes which automates and scales applications based on the network requirements. Containers are critical in 5G because with their dynamic nature, they can easily adapt to the needs of the network allowing for the proper placement of the application and their workloads within a network enabling agility, speed, and efficiency within the network.
Figure 9: 5G Core is architected as “cloud native first” but supports running on IaaS environments
How devices and applications map to the edge
The introduction of 5G has revitalized interest in edge computing and has become a vital component in driving new business models. Onboarding of enterprise solutions at edge locations is critical for network investment monetization. CSPs need to determine which edge-enabled services to offer that are aligned with their existing business models.
Service Providers are in the business of delivering ever more creative and immersive digital experiences. They must also accommodate the ever-growing bandwidth requirements resulting from IoT and the explosion of connected devices as they are entering into the enterprise edge. Delivering a pervasive digital experience where everything is connected to everyone, everywhere, requires a vast, complex, distributed and secure infrastructure.
Multiple edge locations need to be considered depening on the application requirements, there are multiple edge locations to consider. 5G edge computing and distributed cloud deployments address the ever-increasing need for bandwidth and lower latency requirements that modern applications demand. For a Service Provider, the logical extension is into the enterprise edge, either through a private instance, as an extension of the existing network, or as part of a managed services offering.
Figure 10: Where is the Edge? Delivering a unified 5G edge platform - Private Edge Clouds Run on Enterprise Prem; Public EDGE Clouds are located on 3rd Party Prem
As 5G deployments are becoming more widespread, an underlying question remains: How will service providers be able to monetize their investments? Service providers will need modern edge strategies not only to attract different enterprise verticals, but also to deliver on the promise of 5G—increased bandwidth and lower latency close to end users. The edge endgame is somewhat in focus, but how will service providers get there? With the playing field being relatively level, what will be a CSPs’ key differentiator? How can CSPs bring new service offers to market faster, reduce their TCO and manage the increased complexity bought on by 5G’s distributed multi-cloud network? All this can be answered with our ServiceNow TMT product suite.
Distributed Cloud Architecture for Next Gen Mobile Networks
A distributed mobile architecture requires that compute capacity is also distributed across various locations in a mobile network and most commonly at edge locations. Distributed mobile network architecture is designed to be able to provide flexibility and agility in enabling the distribution of mobile network functions across various edge locations. This also enables the possibility to scale thereby allowing for a seamless expansion of network capacity to accommodate the increasing number of connected devices requiring addition throughput and stringent latency requirements.
Cell Site: This is the location where the antennas, transceivers, power supply, radios, base band unit (DU/CU-CP/CU-UP), shelter or cabinet, and compute. A cell site is divided into 3 sectors (similar to dividing a pie into 3 sections) where each sector contains a antenna and radio to be able to provide mobile coverage for that specific area. With a distributed architecture, the base band unit can be further distributed and placed in varying locations near and around the cell site (additional information will be described in the RAN (Radio Access Network) section.
Enterprise Edge: The enterprise edge is essentially a cell site or multiple cell sites that are dedicated to the enterprise industry it is serving.
Edge Data Center: Smaller data centers that are locater closer to where the edge applications need to run or the end user that generates or consumes data. Thus helping to reduce latency by processing data close to the souce which in turn improves the overall performance of applications and services.
Local Data Center (LDC): A data center that is placed in close proximity to a 5G edge location. A local data center is normally confined to a major city or region surrounding a city.
Regional Data Center (RDC): An RDC is normally located in a specific state. It can also house many components of the 5G core to improve specific KPIs but normally not in it’s entirety.
Figure 11: Virtualize RAN deployments (both NR and LTE)
National Data Center (NDC): The national data center houses the majority of the 5G CORE, IMS, Positioning Functionality, Authentication functions and many additional VAS (value added Services) that are needed for a mobile network. As a result of the distributed nature of a mobile network, part of the 5G Core can also be instantiated at multiple locations within the network. For instance, the User Plane Function (UPF) which is responsible for all the user plane data and connectivity to the internet, can be available at any or all edge locations in order to decrease latency.
Figure 12: Distributed Mobile Network Definitions
5G Service Decomposition
Delivering a 5G service requires the understanding of the entire mobile network that is deployed to be able to provide the services to end customers whether it be enterprise or regular consumers. To be able to properly model a 5G service you will need to be able to decompose the service into the RAN, Core and transport components. Each will be described below.
5G CORE
The 5G Core (5GC) is fundamental in unlocking the full potential of 5G technology. It is the crucial compenent in delivering enhanced performance, flexibility and efficiency required by 5G technology. As part of the 3GPP standard (3rd Generation Partnership Program – designing mobile systems for both RAN and CORE).
The 5GC provides connectivity to network for end users and enables access to its services. The 5GC controls both the user plane (UPF - handling user data traffic including data forwarding and routing) and control plane functions (CPF - responsible for signaling and control messages within the 5G network and controlling the establishment, maintenance and termination of communications sessions) of the network. The 5GC is also responsible for managing and controlling session management functions which enables the creation and management of communication sessions for services including voice, video and data. The 5GC is responsible for a number of functions including authentication and security, policy control, and charging.
Network slicing is only capable with the introduction of the 5GC. With the introduction of the 5GC, it is now possible to create isolated and customizable virtual networks that meet the stringent requiments for different use cases such as eMBB, uRLLC and mMTC.
With it’s cloud native service based architecture, the 5GC enables faster service creation and provides enhanced support for distributed cloud. The 3GPP 5GC architecture is depicted below:
Figure 13: 3GPP network diagram including 5G core and RAN.
5G Core Service Based Architecture
The 5G Core service based architecture incorporates the use of Service-Based Interfaces (SBI) thus allowing for the faster creation of services. Some of the improved service capabilities will include:
- UE (User Equipement and/or mobile device) can connect to multiple network slices simultaneously,
- Mobility on Demand concept allows service differentiations, e.g. limit access to certain geographical areas for Fixed Wireless Access (FWA).
- Enhanced support for distributed cloud where the UE can access both local and centralized networks within a single connection
- Improve and simplify QoS, as well as enhance support for distributed Cloud; the UE can access both local and centralized networks within single connection.
- Support for devices without SIM cards
- Support for fixed broadband access which will prepare for non-3GPP access integration.
Figure 14: 5G Core Service Based Architecture
5G RAN (Radio Access Network)
Low band, Mid band, High band Radio Access
5G is divided into three main frequency bands (low, mid, high).
- Low-band 5G operates within the frequency range of 600 to 700 MHz, offering expansive coverage over a larger geographical area. However, the trade-off is that speeds are notably slower, reaching a maximum of 50 Mbps. This frequency band is particularly advantageous for widespread coverage and used in private networks for industries to establish communication with remote rural sites.
- Mid-band 5G generally operates within the frequency range of 1.7 GHz to 2.5 GHz, representing an optimal choice that strikes a balance between expansive coverage and high-speed performance. This frequency band is widely employed for 5G connectivity, specifically designed to provide extensive coverage in suburban and urban environments. Speeds achievable in the mid-band spectrum typically range from 100 to 900 Mbps. Although the actual speeds may fluctuate based on factors such as network conditions and device capabilities, mid-band 5G consistently delivers notably faster speeds in comparison to 4G LTE networks.
- High-band 5G, also known as mmWave (millimeter wave), functions at frequencies starting from 24 GHz and beyond, delivering the swiftest speeds but over relatively short distances. The high band stands out for offering peak 5G performance, achieving speeds of up to 1 Gbps and even reaching speeds as remarkable as 10 Gbps in controlled settings. However, it's important to note that high-frequency signals, characteristic of the mmWave spectrum, can be influenced by reflections and obstructions from buildings and construction materials, significantly restricting transmission range and coverage.
Migration Path from 4G to 5G
Several connectivity options are available and standardized as per the 3GPP standard. Figure 15 depicts the different connectivity options that are supported.
- Option 2, 4, 5 and 7 include connectivity to the 5G Core Network.
- Option 3 is based on tight interworking between LTE and NR on RAN-level providing NR support with minor impact to EPC (Evolved Packet Core – 4G CORE)
- Option 3, 4 and 7 enables RAN to support dual connectivity over both LTE and NR in order to optimize capacity and spectrum utilization.
Within customer networks, there maybe a combination of these supported deployment paths. The deployment options are also something that need to be considered when modeling the network within an inventory system.
RAN Evolution
Figure 16: High Level Overview of different Open RAN initiatives and their interrelationship with vRAN/C-RAN
A description of each of the open RAN initiatives are described below.
- Open RAN is a generic term that refers to open RAN architectures including open interfaces, virtualization, and use of AI.
- OpenRAN is a project initiated by the Telecom Infra Project (TIP). It's an attempt to realize the Open RAN concept. Its work covers 2G/3G/4G/5G. As inputs, OpenRAN uses 3GPP and O-RAN specifications.
- O-RAN can refer to the O-RAN Alliance or standards created by the Alliance. It complements 3GPP specifications by defining interface profiles, new open interfaces and new nodes. O-RAN addresses 5G RAN interfaces including the X2 interface between 4G and 5G base stations.
- vRAN (Virtualized RAN) makes the RAN software-defined and programmable. Whereas Open RAN focuses on openness, vRAN is really about moving functionality from hardware to software. vRAN started in 4G with proprietary interfaces, later extended to 2G/3G (OpenRAN) and 5G (OpenRAN or O-RAN).
- C-RAN (Cloud RAN) is vRAN built on cloud native technologies, such as microservices, containers and CI/CD. Confusingly, C-RAN is also sometimes used to mean Centralized RAN where processing is centralized in CU or DU, away from RU.
Radio Base Station Disaggregation Evolution
The decoupling of hardware and software on the RAN side has added benefits but additional complexities now need to be entered into the fold. In 4G, the radio baseband unit was monolithic meaning that there was dedicated hardware required to support a 4G eNodeB. 3GPP has introduced (in the 2nd diagram of Figure 17) the disaggregation of the RAN. The baseband unit is now completely software based and divided between the RU (Radio Unit), DU (Distributed Unit) and the CU (Centralized Unit). The CU is further divided into the Control Plane (CP) and User Plane (UP). In later sections additional details are added in terms of their interfaces. This was meant to ignite a multi-vendor environment but to date, deployments have mainly been single vendor. The virtualized RAN (vRAN) also introduces the RAN components as wither VNFs or CNFs with a network.
Figure 17: Visualization of delta between legacy 4G RAN Models and 5G Disaggregated Model as per 3GPP
Distributed Nature of vRAN
The distributed nature of vRAN is an architectural approach where we saw earlier, the traditional functions of the RAN are virtualized and distributed across several locations. Having a distributed network enables greater efficiency in the deployment and management of RAN components as well as enabling greater scalability and flexibility. Many different deployment scenarios are available depending on the service provider’s use cases. Having both centralized and distributed processing functions enables the ability to move away from the cell site into an edge location. Distribution of the network functions also provides improved resiliency and redundancy. From a deployment perspective, it is rare that the DU and CU are instantiated at different locations due to latency SLAs brought about by the end customer. As a result, the DU and CU are usually either instantiated close to the cell site or at an edge location not far from the cell site. The DU and CU can be at the same location but also on separate servers, in which case the physical connectivity between the servers needs to also be modeled from a network inventory perspective.
Figure 18: Different vRAN deployment scenarios
O-RAN Alliance Architecture
Why O-RAN?
O-RAN is an open, multi-vendor interoperable ecosystem that drives healthier competition, higher innovations and lower costs for RAN equipment from a larger pool of vendors. Thus, O-RAN moves away from proprietary, vendor-specific protocols for communication, SW functions and interfaces.
RAN deployment and management is one of the most expensive part of a wireless network. Being able to manage 5G profitably means that the high cost areas need of network evolution, growth and maintenance need to be managed. With the support for automation that O-RAN provides, deployment and management costs are further reduced.
O-RAN enforces network scale and agility as network components are scaled per user, network capability and capacity demand.
Figure 19: O-RAN Architecture
Next Generation NodeB (gNodeB)
The gNodeB is the node that supports the connectivity between the UE (User Equipement) and the 5G core based on 3GPP for a specific coverage area or cell site. The gNodeB consist of the antenna, RU (or RRU), DU and CU. The gNodeB functionality include:
- Mobility management (Radio Resource Management)
- Radio Signalling processing
- Connection Management, packet & baseband processing
- Security, Quality of Service (QoS) and Charging.
When modeling the gNodeB, the characteristics are related to the above tasks.
Figure 20: Detailed view of a gNodeB composed of all the respective logical interfaces, hardware and software components that need to be modeled as part of the 5G Network
5G Transport Infrastructure
The 5G transport is the underlying network infrastructure that connects the entire network from the RAN all the way to the 5G Core. The transport is often divided into the fronthaul, midhaul and backhaul.
Fronthaul: Is a fiber based connection between the radio (or Remote Radio Head – RRH) and the DU. This connection is usually a CIPRI (4G) or eCIPRI (5G)but it may also be ethernet depending on the vendors.
Midhaul: The connectivity between the DU and CU is often referred to as the midhaul. He midhaul is typically an ethernet connection.
Backhaul: The mobile backhaul is the connectivity between the RAN (CU) and the 5G Mobile Core. The backhaul is typically an ethernet connection.
Figure 21: High Level End to end transport depiction for a mobile network
A variety of Transport Network Paths exist at different parts of the Network
- Some are self-contained without crossing multiple parts of the Network.
- Some cross multiple parts of the Network: UNI-ENNI-UNI
- Some UNIs are Mobile UNI (mUNI) and some are Virtual UNI (vUNI) due to vBBU and vCORE
- Transport Path can span a single transport layer (L0, L1, L2) or multiple layers (L0/1/2)
Below is an example of the transport visualization of of a network.
Figure 22: Example transport network that provides the underlay of the mobile 5G network.
Please stay tuned for the 3rd installment: 5G Modeling within Network Inventory
