5G Non-Standalone to 5G Standalone: New opportunities for Communications Service Providers

Many CSPs are deploying 5G NSA intending to evolve to 5G SA as the technology matures. This calls for the transition from 5G NSA to 5G SA to be straightforward for the CSP and transparent to the end-user. This article describes ways to make that transition happen, focusing on the 5G core.

Content Summary

Introduction
5G core – ready for networks
5G NSA deployment
5G SA deployment
Benefits of 5G SA and new use cases for monetization
Bringing the components together
5G Non-Standalone to Standalone – Made Real
Packet Core and Control and User plane separation
Data Management
Location services
Signalling and Routing
Operations, administration and management
Role of Core Engineered Solution to simplify migration
Conclusion
Abbreviations

Introduction

By the end of 2025, Ovum expects there to be 3 billion 5G subscriptions, which will be worth USD 800 billion in annual subscription fees. 3GPP has defined several deployment options to hasten the introduction of 5G while supporting a move to fuller 5G services.

The industry has aligned on options Non-Standalone (NSA)3X and Standalone (SA)2. Option NSA3X allows Communications Service Providers (CSPs) to quickly deploy 5G enhanced mobile broadband (eMBB) service on top of their existing 4G core and radio networks, using 5G radios to provide high-speed, low-latency data capabilities for their customers. Option SA2 enables CSPs to offer their customers the full capabilities of 5G technology through the addition of a cloud-native 5G core.

5G core – ready for networks

Many CSPs have introduced the 5G NSA deployment option 3X, shortly called NSA3X in the following.

NSA3x is supported by many smartphones able to allow higher data speeds. As well as smartphones, many different types of devices can connect. All devices, from smartphones to data sticks to Internet of Things (IoT) sensors, are referred to by the generic term User Equipment (UE).

NSA3x enables 5G radio access by leveraging the existing 4G core, the Evolved Packet Core (EPC). The 5G core can be introduced in parallel to the existing EPC as an evolutionary step based on deployment options such as SA2, SA5, and NSA7. Currently, the industry is mainly using SA2 as the next step.

EPC and 5G core will both continue to exist to provide support for existing 4G devices, while 5G core will be the only core network option for 5G greenfield CSPs. Even then, roaming will require connectivity to 3G or 4G serving Public Land Mobile Networks (PLMNs).

5G NSA deployment

5G NSA Option 3/3A/3X is based on LTE-New Radio (NR) Dual Connectivity (simultaneous connectivity via LTE and NR) with EPC, where LTE becomes the master and NR is secondary. This option enables the use of the 5G spectrum and offers services including Fixed Wireless Access (FWA). Moderate enhancements are required for EPC to the MME, S/P-GW, HSS, and PCRF. Many initial rollouts use NSA3X to provide enhanced mobile broadband with reliable connectivity.

While this allows early 5G deployment, it cannot achieve many 5G capabilities such as end-to-end network slicing. A further disadvantage is that dual connectivity shortens UE battery life.

5G SA deployment

5G stand-alone deployment option 2 (SA2) is based on NR connected directly to the 5G Core, bringing several advantages over the NSA3X option:

• Single radio connectivity, only NR without simultaneous LTE connectivity
• 5G core can scale quickly to meet changing service demands not seen in traditional broadband and voice. New services like massive cellular IoT, Augmented Reality (AR) and Virtual Reality (VR) will depend on the 5G core’s lower latency, higher data rates, and increased scale.
• 5G core offers increased security and privacy. 3GPP-defined 5G UE authentication is more secure than 4G to protect the CSP and its customers against increasing cyber threats.
• End-to-end network slicing is supported, enabling CSPs to provide tight Service Level Agreements (SLAs) for customer segments.
• The 5G core is access agnostic, equally handling 3GPP and non-3GPP technologies such as fixed line access.

Benefits of 5G SA and new use cases for monetization

Distributed cloud

Traditional networks are highly centralized and optimized to provide mainly bandwidth and capacity. Different characteristics of a wider range of services and applications require both centralized and distributed network deployment architectures. For example, some mobile services will require low latency under full mobility conditions, such as autonomous vehicles that need a radio latency of around 1ms. Multi-Access Edge Computing (MEC) resources will support these low latency use cases with two main features:

• A new Session and Service Continuity mode called “make before break” allows no interruption of services when a UE transfers from one edge data center to another. This is the only way to serve low latency use cases for moving UEs.
• Distributed cloud hosts telco functions, additionally MEC resources can be used to host a real user application. Using MEC APIs, the entire application re-allocation can be initiated by the 5G core to keep a user’s latency within agreed limits.

Network slices for different industry verticals

The 3GPP has defined several network slices profiles: eMBB for mobility and high throughput, massive IoT to handle a massive number of devices providing high uplink throughput, and URLLC requiring security and reliability. Nevertheless, new 5G services may require further slice definitions.

• eMBB premium subscriptions (FWA, Enterprise): a CSP may offer an FWA service for home and business users – not simply providing FWA as high bandwidth, and reliable access but defining a slice for this segment to offer enhanced quality and customization to existing services/subscriptions for consumers and business customers.
• New 5G use cases (Cloud gaming, AR/VR, robotics, etc.): tailored network slice for demanding service requirements for new use cases.
• Alternative for a private network (Industry 4.0 where AI is used in production or public safety communication): a more cost-effective and faster time to the market solution than a fully dedicated private network
• Special services (IoT, logistics): a network slice is tailored to a use case whose characteristics may be different from MBB. Can require less capacity than MBB but is business-critical.

These scenarios show how a 5G core network slice can be adapted to a specific use case. This allows CSPs to meet different customer needs with slice definitions. The most important factor is to analyze customer needs and design the service accordingly, with the 5G core providing a flexible and programmable platform.

Bringing the components together

5G Core Service Based Architecture

5G Core architecture is fully based on cloud-native concepts and allows easily leveraging all advantages of cloud-native applications like webscale deployments and automation. This new architecture is not restricted to SA2 deployments.

Instead of defining peer-to-peer interfaces as in previous mobile network generations, services are defined. Service producers are network functions (NFs) where the service is processed. Service consumers are NFs that use the services provided by CSPs. One NF can be a provider for one service, while also being a consumer of another service.

Service producers provide their services via http-2 Service-Based Interfaces (SBI). These consist of a list of operations, divided into functionality groups known as services. Different services belonging to the same SBI are independent.

Each NF that acts as a service producer reveals its interfaces and corresponding services via a central Network Repository Function (NRF), which is used by NFs (service consumers) to find services.

The service producer can run different services belonging to the same interface on different addresses. The same service can even be run on different addresses depending on further parameters, such as slice ID.

The service consumer is free to use just some of the services provided on a specific interface. This means that different services of the same interface can be requested with different performance requirements.

As the services have independent functionality, they can be implemented by independent modules in the service producer. This corresponds to a microservice architecture in which each service is implemented by different microservices that can scale independently to meet the needs of a service producer. This helps to ensure optimal use of resources for the 5G system.

Different models are possible for communication between NFs on service-based interfaces. Nokia recommends the so-called model “B” mainly for small deployments. This model uses direct communication between NFs. NRF allows service consumers to dynamically discover the addresses of corresponding service producers.

Service Communication Proxy (SCP) is recommended for bigger deployments. SCP-based deployment simplifies the network structure and centralizes common functionality like load balancing, monitoring, and overload control.

One of the main principles of 5G is that services have independent functionality and are mostly stateless (decoupled from storage resources), so they can be instantiated and scaled according to network demand. This allows 5G services to be implemented by independent small modules rather than large servers.

This corresponds to a cloud-native architecture in which each service can be implemented by different microservices that can scale independently according to CSP requirements to help ensure the most effective use of resources for the 5G system.

Packet Core migration: combo nodes and Control and User Plane Separation (CUPS)

Packet core migration is one of the NSA3X deployment options, at least for the control and the user plane of the gateways. Most legacy gateways are not ready for the basic use case of NSA3X for high bit rates because they do not support the separation of control and user planes, which avoids heavy transport loads by distributing the user plane. This distribution also allows low latency, at least for static UEs, or for UEs moving to certain areas. The interworking of 4G and 5G also requires a combination of Session Management Function (SMF)/ Packet Data Network Gateway-c (PGW-c) and UPF/PGW-u, in other words, a combination of HSS/UDM, PCRF/PCF. This is the 3GPP standard for supporting IP address continuity when a UE moves from 5G to 4G coverage or vice-versa.

Adopting more use cases than the eMBB can support requires a move to the 5G core. To work with verticals and enterprises, a CSP will need to support network slicing to ensure security and SLA requirements are handled cost-effectively. Edge data centers must be integrated rapidly with the help of 3GPP features and not treated simply as locations to deploy functions. A new session and service continuity mode ensure no interruption of services when a UE moves between edge data centers. Ultra-reliability requires 5G core features such as redundant user plane paths, with the enhanced resilience offered by functions/services in the control plane acting as a fallback for extreme events such as a failure of a complete data center.

Subscriber data management

As with earlier mobile network architectures, subscription data and the corresponding management functions are essential for the availability of the whole 5G System. This is particularly important during the introductory phase, where stability issues may lead to message storms that are more likely than within mature networks like EPC.

Distributed across multiple sites, the Nokia SDM differentiates strictly between stateful Unified Data Repository (UDR) and state-less applications, for example, Home Subscriber Servers (HSS), Unified Data Management (UDM), and Policy Control Function (PCF). The 5G core solution uses proven techniques to handle large overloads, including those caused by unexpected UE behavior, such as toggling between 3G/4G/5G network access registrations to attach to the preferred network.

Service continuity, fulfill regulatory requirements

Even if the 5G core is introduced for new services and new service architectures like network slicing, subscribers will still expect continuity of their existing services, such as voice. Emergency calls must be possible and lawful interception is required for voice calls and cannot simply rely on intercepting the “data” to support cases like call forwarding. Multimedia Priority Services must also be available in the 5G core.

The 5G NSA solution uses the existing LTE radio and core for all these aspects. Voice in the 3X architecture is either IMS-based VoLTE or relies on CS Fallback. In the SA architecture, the voice becomes IMS-based VoIP, using the EPS Fallback or Voice over New Radio (VoNR). Further details can be found in the Nokia paper (Voice over 5G The options for deployment). This also describes several solutions for emergency calls. During the initial deployment of the 5G Core, the use of emergency fallback is recommended, as it reuses all the cells to emergency-center mapping.

Policy and charging

The role of policy management has dramatically changed over the last few years, resulting in ever more complex rules and creating a need for a better rules engine. In 5G SA deployment, the 5G core’s cloud-native network function PCF is designed to meet these challenges:

• The access agnostic 5G core must deal with a growing range of devices and the subsequent increase in the number of rules
• 5G diverse IoT use cases like Long Range (LoRA) IoT or mMTC require a huge number of new rules that may be invoked with different types of triggers.

Designed for the 5G era, charging functions must provide real-time rating and charging capabilities to enable new monetization opportunities for digital service providers. They must be tightly integrated with adjacent BSS capabilities such as mediation, billing, and a rich set of analytics capabilities.

Location services

Location services must be available reliably, for example, to allow emergency services to be used whatever the connectivity status of the device.

5G Non-Standalone to Standalone – Made Real

Evolving from non-standalone to standalone has different start points. For example, whether an existing 3G/4G network needs to be enhanced or if this is a completely new network, if a multivendor environment requires interoperability tests or whether a Core Engineered Systems solution could be applied to speed up the process.

Nokia provides a full spectrum of products for 5G support as shown in Figure 5. Within the following chapters for the different areas, the transition is explained in more depth.

Packet Core and Control and User plane separation

The Nokia cloud-native packet core consists of three product families embracing many 3GPP functionalities. As stated in the previous section, a combo SMF/PGW-c, UPF/PGW-u is needed for 4G-5G interworking. In 4G, Nokia treats the control plane and the user plane of the gateways as two independent functions, loosely coupled, rather than components of the same function.

Traditionally in 4G, the whole of a UE’s traffic is handled in a single Central Processor Unit (CPU). This is not yet possible for eMBB, as a single CPU can only achieve a speed of around 2 Gbps. Various techniques have been introduced for per-flow scheduling, although even these are not enough for 5G. Nokia supports per-packet scheduling with current computing capabilities of up to 60 Gbps per flow.

In addition, Nokia’s UPF can be supplied with built-in basic add-on services, such as Deep Packet Inspection, carrier-grade Network Address Translation (NAT), and Transmission Control Protocol optimization. This offers the smallest UPF-introduced latency on the market, allowing CSPs to fulfill even the strictest SLAs. Each packet is cracked “once”, cutting east-west traffic, minimizing the solution’s infrastructure footprint, and optimizing the number of function instances that need handling. The user plane is distributed in the form of basic functions such as Firewall (FW) and carrier-grade NAT (CGNAT) and there is no requirement to distribute FW or CGNAT before the UPF.

Figure 6 shows the architectural and functional highlights of the Nokia Cloud-Native Packet Core:

• Cloud Mobile Gateway (CMG), Cloud Mobility Manager (CMM), and Cloud Network Resource Discovery (CNRD) implemented as Containerized Network Functions (CNFs) with no loss of EPC functionality
• Full integration with Kubernetes
• Support for Nokia developed Load Balancer services
• Combined Session Management Function (SMF)+Serving Gateway-Control Plane (SGW-C) /Packet Data Network Gateway-Control Plane (PGW-C) to allow EPC interworking with 5G Core. Combined PGW-u/UPF
• Integrated with common management components
• CNFs on bare metal and in Virtual Machines (VMs) are supported.
• Integrated with Nokia CaaS (NCS) and third-party CaaS

Nokia recommends its cloud-native CUPS-based Gateways (GWs) for option 3X to handle high bit rates and take pressure off the transport. PGW-c – PGW-u could be upgraded to combinations of SMF/PGW-c, UPF/ PGW-u even before full 5G core deployment.

CSPs are free to select when they migrate and can, for example, continue to use their legacy core for 4G UEs. The MME then simply selects a legacy PGW-c and not a combination. If the CSP wants to migrate subscribed 4G UEs to the new GWs, then the MME chooses a combination of SMF/PGW-c rather than a legacy PGW-c. DNS queries have been extended appropriately to allow such options.

If a combination of SMF/PGW-c is used, then the CSP can easily select a PCF and a CHF for policies and charging. For 5G NAS capable UEs and for Access Point Names (APNs)/Data Network Names (DNNs) for which 4G-5G interworking applies and where there are no subscription restrictions if a UE registers in a 4G coverage area, the MME is forced to select an SMF/PGW-c. If it does not, it will be impossible to achieve a seamless handover when the UE moves to a 5G coverage area. In this case, the SMF/PGW-c is also forced to select a UPF/PGW-u. If a 5G NAS capable UE registers under 5G/eLTE coverage, then Access and Mobility Management Function (AMF) is selected as a mobility entity, which simply selects further 5G core elements.

If a CSP is keen to explore all 5G use cases, then it must migrate to the 5G core. Partial migration to CUPS-based gateways is recommended even for CSPs that would prefer to stay with eMBB, which can be easily served by the 3X deployment option. Partial migration to CUPS-based GWs, PCF, CHF is possible now for all 4G and 5G UEs and will soon be possible for all UEs allowed by subscription.

Nokia uses proven products for 5G core functions, ensuring that no EPC functionality is lost. Also, because the Cloud Mobility Manager offers Serving GPRS Support Node (SGSN) functionality and the Cloud Mobile Gateway offers Gateway GPRS Support Node (GGSN) functionality, Nokia’s cloud-native core supports all generations from 2G to 5G, without this implying seamless handover between 2G/3G and 4G/5G. Finally, although the Nokia cloud packet core is currently focused on deployment option 2, it can easily be extended to support other deployment options such as 4, 5, and 7.

Data Management

Data management, particularly subscriber data management, is an essential consideration when migrating from EPS to the 5G System. There are several differences between data management in EPS and 5G System, including:

• The strict separation between Data Storage Layers provided by Unified Data Repository (UDR), respectively Unstructured Data Storage Function (UDSF), and Data Access Layer with standardized Service Based Interface (SBI) in 5G System. Standardized SBI for UDSF is only available from 3GPP Rel-16
• Holistic storage concept. This not only concentrates on provisioned subscriber data managed by the UDM function but also covers PCF, application, and Network Exposure Function (NEF) data
• Interworking between different Core Network types is standardized by 3GPP Rel-16, namely the interworking between HSS and UDM.

The Nokia SDM solution supports this strict separation between the Data Storage Layer and the Data Access Layer, and there are several deployments based on One-NDS. This is a good solution to use initially as it allows the fast introduction of the new 5G System. The Ud interface is available via One-NDS.

If new 5G subscription data is added to existing subscriber data, the authentication credentials can be reused, while new 5G subscribers can also be created. For interworking with 5GC, the UDM shall be added as a new application FE. The UDM is connected to the AUSF, AMF, SMF, SMSF, and NEF within the 5G System and provides HSS-like functionality toward 5GC.

Almost all CSPs will require interworking between different Core Network types for some time. In existing 4G networks, EPC support will be necessary until complete 5G Core coverage is available. In new, 5G Core-only networks, 2G/3G/4G support is necessary to allow outbound roaming across the globe.

This requires HSS/Home Location Register (HLR) deployments as well as the corresponding subscriber data. The Nokia UDM connects to the Nokia HSS+HLR for interworking via a Nokia UHHd/UHd interface, requiring an upgrade to the HSS+HLR. The main interworking use cases are 5G Core-EPC mobility scenarios, interworking 5G System with IMS, for example, to support terminating domain selection via T-ADS feature, and interworking for terminating SMS support.

The current UHHd/UHd interface will be replaced by the NU1 interface as per 3GPP Rel-16. In addition, 5G-EIR functionality can easily be added by enhancing an existing One-EIR-based solution with 5G SBI. There are no new data requested and the same device black/grey/white lists are shared between access domains.

Another migration option is to introduce a new UDR for 5G System subscribers in parallel with the existing HSS/4G UDR. The introduction of a new 5G SDM should be based on Shared Data Layer (SDL).

SDL is the future-proof cloud-native Nokia UDR solution supporting the 5G System’s standard, namely Nudr. The corresponding subscriber and service profiles usually contain 2G/3G/4G, IMS plus 5G data. The introduction of a new, cloud-based 5G-UDR for 5G subscribers allows a separate, new data management deployment for a 5G core. Both Nudr and Ud-based interfaces can be used.

SDL is highly scalable, allowing smooth growth to meet market requirements.

Such a solution requires routing enhancements for STP/Diameter to route incoming requests for 5G System’s subscribers to the new SDM and others to the existing HSS+HLR.

Another third option is the introduction of SDL from the start.

Existing 4G subscribers shall be migrated from the existing 3G/4G-UDR to the new 5G System’s UDR. Reuse of existing FEs is possible if they are already cloud or CNF based. Existing subscriber data from One-NDS are migrated to SDL, either via script or via proxy-based migration.

With the availability of the 3GPP Rel-16 NU1/NU2 interfaces as per 3GPP TS23.632, there will be another option that allows CSPs to keep their existing EPS UDR and HSS/HLR. The existing HSS/HLR must be upgraded to support the new interfaces. Only the 5G System’s subscription is stored in the 5G System’s UDR in this case, accessed via an NU1 enabled UDM.

Such a solution allows CSPs to reuse existing EPS HSS for 5G System’s subscribers without affecting Diameter/MAP routing. The disadvantage with this is the partly redundant storage of subscriber data in two different databases.

Location services

Location services are supported via 3GPP Gateway Mobile Location Center offered via the Nokia Location Server. Figure 8 shows the basic network architecture for location services in EPC and 5G Core. The Nokia Location Server consists of components supporting the different access types.

For network-initiated transactions, the GMLC is the gateway into the 4G or 5G Core. Assuming the GMLC determines whether the UE is on LTE/NR-NSA or NR-SA, it can initiate positioning over the appropriate 4G SLg or 5G NLg interface. The GMLC knows the context based on one or more of the following:

1. If the location request arriving at the GMLC indicates 4G or 5G, for example, including the RAN-type indicator from a SIP INVITE
2. From an indicator pushed from elsewhere arriving at the GMLC that indicates 4G or 5G, such as an SLg SLR from the MME or NLg Nlmf_Location_Determine Location Request message from AMF
3. By querying the HSS or UDM or both to determine 4G or 5G.

For device-initiated Secure user Plane (SUPL) transactions, whether 4G or 5G is indicated by the ECGI or NR-CGI in the SUPL messaging, the appropriate procedures are followed.

Signalling and Routing

The Nokia Cloud Signaling Director (CSD) provides 3GPP SCP functionality. It’s recommended to introduce CSD from the beginning to simplify the migration. CSD supports two deployment options for an SCP service:

Central deployment

The SCP is deployed as a central NF, external to any NF in the network, and communicates with other NFs via corresponding SBI interfaces.

Distributed deployment

In the event of a cloud-native environment at each CNF, the SCP is deployed in each NF function. It can be deployed as a separate Pod as the smallest deployable unit that you can create and manage in Kubernetes or even as a sidecar of NF Pods. The NF Pods do not need to handle the routing of the SBI messages. They simply pass the message to the SCP Pod (or transparently to the SCP sidecar) and the SCP delivers the message to the correct destination.

Operations, administration, and management

Open operability interfaces help CSPs to create their own automation framework and then integrate the Nokia 5G Core network functions into it. To make this possible, Nokia 5G Core Network functions to support the interfaces provided by OpenSource projects from the Cloud Native Computing Foundation (CNCF). Prometheus/Grafana, FluentBit, and ELK are just some examples of such projects addressing telemetry use cases. Other open technologies are used for Configuration Management (for example NetConf/YANG) and logging and tracing (for example Homer, Jaeger).

The compatibility of Kubernetes with many cloud infrastructure and bare metal server technologies means Nokia 5G Core Network functions can be deployed and operated on any cloud.

The Nokia 5G Core improves automated operability in numerous ways. Automated lifecycle management is based on Kubernetes methods like Helm Charts and K8S Operators. Kubernetes components such as Kubelet, which is the primary “node agent” that runs on each node, and HPA are used for automatic scaling and healing. This ensures that proprietary mechanisms for lifecycle management network functions are avoided and that the Nokia 5G Core will always benefit from the fast lifecycle management operations provided by Kubernetes and any functional evolution in the Kubernetes ecosystem.

Automated orchestration is provided by the Nokia Cloud Operations Manager. It helps CSPs manage their 5G core workload over multiple Kubernetes clusters by taking the actual status/capacity of these clusters into account. For example, operational staff can automate the creation of new network instances in the right Kubernetes cluster, as selected via a policy. They can also react automatically to data center outages by recreating network functions on the remaining data center as part of a disaster recovery process. Nokia Cloud Operations Manager can also create a complete network slice with a single mouse click.

Closed-loop automation is provided by the Nokia Assurance Center, which fully automates the collection of telemetry data from all parts of the network, analyzes it, and derives optimization measures.

Role of Core Engineered Solution to simplify migration

Nokia 5G Core Engineered Systems is a collection of bundles for cloud-native environments using Nokia-certified products and services. These bundles provide better performance than using best-of-breed products from multiple vendors:

• Enables faster time-to-market for foundational services like 5G Core, Voice over X, Unified Data Management in telco cloud
• Deployed and ready for rapid commercial use, minimizing the time from initiation to acceptance
• A CSP core network will always be up to date with the latest capabilities and Core and Network Functions Virtualization Infrastructure (NFVI) infrastructure releases
• Nokia ensures a fast and proven system upgrade path, with optimized and pre-certified system-level upgrades to cut upgrade times
• The concept offloads the burden of integration, providing safe-harbor certification of product release combinations (VNF and NFVI) covering functional, operational, performance, and robustness testing.

Core Engineered systems provide core foundational services based on the latest technology. Rather than being static systems, they continuously evolve in different ways. The first is the evolution of 5G architecture – current systems can serve NSA3X and SA2 5G architecture. Using Core Engineered Systems, CSPs can migrate to SA2 architecture quickly and simply.

Conclusion

5G will support CSPs’ monetization aspirations with agile new service creation opportunities. One step to exploit the promise of 5G is the move from NSA to SA core deployment. At this stage, 5G core SBA and network functions become available as a programmable asset and the network becomes a PaaS architecture for the creation of services. Automated end-to-end network slicing will also be possible, encompassing core, transmission, and radio resources to provide defined SLAs for services. By realizing the advantages of 5G SA deployment, CSPs are opening their networks for a wide variety of new possible use cases. The new access agnostic 5G core is ready to provide a similar service portfolio, independent of the type of access technology. In its service roadmap, a CSP can include new consumer and enterprise services to satisfy its customers, reduce churn and provide a return on investment from its 5G deployments.

Abbreviations

3GPP 3rd Generation Partnership Project
3X Non-Standalone 3X deployment mode
5G 5th Generation (mobile radio)
AMF Access and Mobility Management Function
API Application Programming Interface
APN Access Point Name
AR/VR Augmented Reality / Virtual Reality
AUSF Authentication Server Function
CaaS Containers as a Service
CGNAT Carrier Grade Network Address Translation
CHF Charging Function
CMG Cloud Mobile Gateway
CMM Cloud Mobility Manager
CNF Containerized Network Function
CNRD Cloud Network Resource Director
CPU Central Processing Unit
CS Circuit Switched
CSD Cloud Signaling Director
CSP Communications Service Provider
CUPS Control and User Plane separation
DNN Data Network Name
eMBB enhanced Mobile Broadband
EPC Evolved Packet Core (4G)
ePDG Evolved Packet Data Gateway
EPS Evolved Packet System (4G)
FWA Fixed Wireless Access
GGSN Gateway GPRS Support Node
GPRS General Packet Radio Service
GW Gateway
GWCN Gateway Core Network
HLR Home Location Register
HSS Home Subscriber Server
IMS IP Multimedia Subsystem
IoT Internet of Things
LAN Local Area Network
LoRA Long Range
LTE Long Term Evolution
MEC Multi-Access Edge Computing
MIMO Multiple input multiple output
MME Mobility Management Entity
mMTC Massive Machine-Type Communications
NAT Network Address Translation
NCS Nokia Container Services
NEF Network Exposure Function
NF Network function
NFVI Network Functions Virtualization Infrastructure
NR New Radio
NRF Network Repository Function
NSA Non-Standalone
NSSF Network Slice Selection Function
PCF Policy Controller Function
PCRF Policy and Charging Rules Function
PGW Packet Data Network Gateway
PLMN Public Line Mobile Network
QoS Quality of Service
RESTful Representational state transfer
SA Standalone
SA2 Standalone type 2
SBA Service Based Architecture
SBI Service Based Interface
SCP Service Communication Proxy
SDL Shared Data Layer
SGW Serving Gateway
SGSN Serving GPRS Support Node
SLA Service Level Agreement
SMF Session Management Function
SUPL Secure User Plane
UE User Equipment
UDR Unified Data Repository
UDSF Unstructured Data Storage Function
UDM Unified Data Management
UPF User Plane Function
VM Virtual Machine
VNF Virtual Network Function
VoIP Voice over IP
VoNR Voice over New Radio