The fact that 5G brings enhances to radio technology to support high speed and low latency has been well documented. Additionally, it also makes architectural changes in the way the mobile packet core network is realized. An operator looking for a green field deployment of 5G network may look into a standalone 5G network right away. However, for an operator with an existing 4G network, and the end goal of a standalone 5G network, deployment means keeping a few operational challenges in mind:
To overcome these, most operators are considering non-standalone deployment options, particularly, Options-3 variations. We will look at these options and how they enable an operator to migrate from a standalone 4G network (Option-1) to a standalone 5G network (Option-2).
With an NSA deployment, like option 3, an operator can take advantage of the improved speed and bandwidth of the 5G Radio (NR), while at the same time leveraging the existing investments in the 4G core network (EPC). This immediately enables new services like eMBB that the operator can benefit from monetizing.
1. An architectural comparison of 4G and 5G networks
Let’s do a side-by-side comparison of the 4G and the 5G network – Fig. 1. Both are fundamentally an all-IP network. Though 5G supports non IP PDU sessions like Ethernet as well as unknown, it is out of scope for this paper.
Fig. 1: 4G packet core (EPC) functional mapping to 5G core
We have grouped together the functions in 4G, with separation of Control and User Plane to map them to the functions in 5G. As illustrated:
These three functions (AMF, SMF, and UPF) together form the control and user plane for the 5G core. The rest of the functions for the OSS/BSS – for instance, the subscription database from HSS is separated from the operations logic to form the UDM and AuSF respectively. The policy data from PCRF is centralized in UDM, and the policy control logic is separated as PCF. There isn’t a distinction of offline and online charging, both are performed by the ChF in 5G core. AF supports application influence on traffic routing and carries forward from 4G.
NRF, NSSF, and NEF are new to 5G core. The service-based architecture, in which the 5G core is defined, paves the way for a cloud-native realization of the network functions. This allows the network functions to scale independent of each other. Each instance of the network function, when they come up, must register with the NRF. Network functions must query the NRF to get the URI to a service exposed by another network function.
Since the physical network can be partitioned into multiple virtual instances, each instance with possibly different service characteristics, it is possible to reserve these functions to provide an end-to-end quality of experience. This is realized with network slicing and NSSF is a means of selecting the slice to which a particular PDN session must be attached.
Finally, the NEF is the function through which applications beyond the 5G core can access the operating characteristics. These can be fed back into the orchestration systems to get a self-managing 5G core.
While there are fundamental differences in the architecture in which the 4G and 5G packet cores are realized, some of the artefacts like CUPS have been applied to the 4G core as well. This along with some enhancement to EPC, specifically related to support for high-speed UE sessions, will speed up the deployment of 5G services like eMBB for an operator. This would also enable an eventual migration into a fully cloud-native 5G core.
2. Non-standalone deployment (Option-3)
Fig.2 depicts the NSA option-3 variations. These are based on support for dal radio access technology, LTE and NR, with EPC as the mobile packet core.
Fig. 2: NSA deployment options 3/3a/3x
While the differences between the various variations of option-3 are subtle, we feel option-3x is the best bet for operators looking to support 5G services alongside their existing 4G offerings. Here, the voice services (VoLTE) continue to be with 4G radio, whereas the 5G data is over 5G radio connected directly with EPC. The signalling from the UE towards EPC is over 4G radio.
3. Enhancements to EPC to support 5G
First, the most pressing need in EPC to support 5G PDU sessions is to enhance the user data path to support high-speed UE sessions. This is achieved through high-speed packet-handling technologies like FD.io/VPP using DPDK.
Second, 4G-CUPS allows independent scaling of user plane and data plane in EPC. While this is not essential for 5G deployment, it helps in future migrations in a gradual manner. That is, upgrade the data plane (UPF) followed by the control plane or vice versa.
Third, the charging function in 5G (ChF) supports both online and offline charging over the same interface. To support this, enhancements are required to mimic the ChF behavior over Gy (P-GE interface towards Online Charging Server).
Finally, to make sure that the heavy user data load induced by the introduction of 5G users does not impact the quality of experience of the existing 4G users, there must be a mechanism for resource monitoring and selective throttling of data rates.
4. Deployment and Testing considerations
Typical EPC deployments are appliance based – an integrated control plane and data plane running on custom hardware. The architectural enhancements in 5G provide an option to have cloud-native deployment, with standard hardware and cloud-orchestration tools on which network functions may be realized. In other words, the deployment model transitions from a collection of custom appliances to a collection of applications (Network Functions) in the operators’ data centre cloud.
While the operators would like to continue the existing EPC as is, to support the existing user base, the capacity expansion is also thought of as a means to migrate to a new 5G core. Hence, some of the architectural artefacts of the 5G core are introduced into EPC. The first of these is the introduction of Control Plane and User Plane Separation (CUPS) into EPC. The EPC user plane (SGW-U + PGW-U), after separation from the control plane is functionally equivalent of 5G UPF. The EPC control plane blocks (MME, SGW-C, and PGW-C) can be realized as virtual appliances. These can be running in operators’ data centres with standard hardware and cloud orchestration tools. The same data centre may eventually migrate to run 5G core network functions.
The network functions may be independently tested as standalone, by having tester functions to exercise the services provided by the network function. This simplifies automation. A set of automated scripts may be executed against network functions for their acceptance prior to testing the collection of network functions for an end-to-end deployment test.
Summary
The improved speeds/ bandwidth with the new 5G RAT allows services like eMBB. NSA option 3x provides an immediate opportunity for a network operator to support some of the 5G use cases like eMBB that can be monetized, while at the same time, supporting the existing 4G deployment. This improves the time to market and provides a longer return on the investments in EPC. This also provides the much-needed time for networking vendors to implement a fully cloud-native 5G core from the ground up. While the eventual goal is to get to a stand-alone 5G core deployment, the EPC is here to stay in many NSA options in the years to come.
Jayanta Dey
Vice President and Business Head, Network & Edge Providers and Consumer Electronics Vertical, Wipro Limited.
Jayanta is responsible for CTO initiatives undertaken by the Technology Business Unit on emerging themes like 5G, AI, and Cloud-Native. He has over 30 years' experience in the Telecommunications industry. Jayanta holds a BE (Hons) Electronics Engineering from BITS Pilani and an MBA from Northeastern University, Boston.
Narayana Pai
DMTS – Senior Member
Narayana is a Principal Architect in the Packet Core Portfolio of NEPC Practice. He is currently working on 5G core functions at Wipro. Narayana has over 25 years of experience in the Telecommunications industry spanning 5G core, BNG, and L2/L3/Forwarding.