Introducing the 5GS to provide mobile broadband (MBB) in an existing 4G EPS network has significant impacts across all network domains – from the RAN, to packet core, user data and policies, and services – as well as backend systems.
The EPS is primarily used today for a variety of MBB use cases. In some cases, EPS deployments have already been upgraded for early support of 5G by non-standalone (NSA) New Radio (NR). Many such 4G and NSA NR operators have already decided to introduce – or are considering introducing – the 5GS as standardized by the 3GPP.
The 5GS introduces support for NR standalone (SA)  and is specified to support existing MBB use cases as well as new and improved ones. Ericsson believes that operators can address increasing traffic demands and quickly introduce innovative new services by using NSA NR and SA NR .
During the migration period when NR coverage is being built out, services requiring wide-area coverage are best supported through interworking between the 5G Core (5GC) and the existing Evolved Packet Core (EPC). Over time, a growing number of new use cases will utilize the established 5GS MBB scale and wide-area network build-out.
The interworking with the EPC places dependencies on the backend business support systems (BSS) system integration, since user data and policies need to support two networks (the EPC and 5GC). The new devices must support 5GS-related capabilities, while at the same time devices that only support the EPS – including inbound roaming devices – will exist for a long period and will require corresponding network support. This long-term need is a strong argument in support of the concept of a dual-mode core network solution that includes both EPC and 5GC functionality.
A key benefit of a dual-mode core network solution is the common operational model for the EPC and 5GC, which simplifies the management of the overall system. It also includes more granular life-cycle management of the individual software modules (also called microservices) based on cloud-native deployment and operational principles . The common operational model can be used for dynamic and flexible scaling of individual microservices based on capacity needs, such as rebalancing the EPC versus 5GC resource usage when the device fleet evolves over time from 4G to 5G.
5GS architecture for interworking with EPS
Introducing the 5GS to a network requires a comprehensive strategy that considers all network domains, coverage strategy, spectrum assets and devices, as well as which services to offer where. Among other things, the 5GC, the packet core in the 5GS, introduces new network functions and interfaces internally and toward operations support systems and BSS, including charging systems. It also has new interfaces and protocols toward the next-generation RAN (NG-RAN) and devices, which means that the RAN migration, including spectrum assets and device strategies, needs to be coordinated with the 5GC introduction.
Additionally, any plan to introduce the 5GC must consider its new service-based architecture, which includes a network repository function for service registration and discovery, as well as new capabilities like network slicing support and network exposure.
Operators with both NR and LTE access are able to use 5GC capabilities for tight interworking to the EPS, also known as EPC-5GC tight interworking in the first release of 5G specifications in the 3GPP . Figure 1 shows the 5GS architecture for EPC-5GC tight interworking. To enable IP address preservation when connecting over and changing between 4G and 5G access, the 5GC architecture includes a common user plane (UP) anchor point realized by the session management function plus packet data network gateway control plane function (SMF+PGW-C) and the user plane function plus PGW user plane function (UPF+PGW-U).
Figure 1: EPC-5GC tight interworking architecture
To support seamless service continuity and network-controlled handover, the Mobility Management Entity (MME) and the new access and mobility management function (AMF) interact directly through the N26 reference point, which supports devices in single-registration mode (the device is either registered in the MME or in the AMF, but not in both simultaneously). The N26 reference point is used for both idle mode and connected mode mobility; the device initiates idle mode mobility (possibly triggered by the RAN), while connected mode is initiated by the RAN, and the device is informed when handover preparation has been completed. Furthermore, tight interworking also includes how to map protocol data unit (PDU) sessions in the 5GS to packet data network (PDN) connections in the EPS and vice versa.
The interworking architecture ensures that the new 5GC-capable devices are always connected to the UPF in the 5GC independently if they are connected though 4G or 5G access, which enables IP address preservation when devices move between accesses. Thus, service characteristics are maintained, since any colocated value-added services connected to the UPF are the same, and the policy control function (PCF) applies session policies for the device when connecting over 4G or 5G access.
Policy and subscription management need to be provided in a consistent way for a device using NR or LTE access. The interworking architecture provides several 5GC capabilities also over LTE/EPC, including support for network slicing. Operators can migrate from an existing EPC to a dual-mode EPC and 5GC network solution by migrating the packet gateway, the policy control and the subscription and data management, and by introducing new functionality.
Overcoming domain-specific migration challenges
A solid EPS to 5GS migration strategy will consider and address the challenges in devices and all four network domains: RAN, packet core, user data and policies, and services.
The RAN domain
In many markets, the new NR spectrum is first available in mid and high bands. Depending on the site grid, introducing the NG-RAN with NR SA only on these bands may lead to spotty NR coverage that is only suitable for local area services. When deploying NR SA for MBB, it is preferable to ensure continuous NR coverage within the targeted service area (a city, for example) to avoid frequent mobility between NR and LTE. Alternatively, intersystem mobility could be limited by conservative mobility thresholds.
Achieving higher capacity and continuous coverage requires a combination of NR on mid and high bands for capacity and NR FDD on sufficiently low bands for coverage . The NR FDD spectrum on low band can be either new, re-farmed or an existing LTE band that is shared between NR and LTE using dynamic spectrum sharing. NR bands can be combined using carrier aggregation (CA) or, in some cases, dual connectivity.
NR CA will be vital in enabling service providers to serve the growing number of 5G devices in the network while maintaining overall network performance and user experience. This is done by activating downlink CA (FDD+TDD) in the areas with low-band and mid-band NR. This not only boosts mid-band NR coverage, and consequently capacity gain, but also provides a further coverage boost by enabling some of the NR signaling to be moved to lower bands. Ericsson has shown that this can provide up to 3-7dB extra gain in link budget on the downlink .
NR SA with CA reduces complexity in the RAN and devices compared with dual connectivity as in NR NSA. The device does not need to transmit on two uplinks at the same time. The use of NR SA also reduces the time from a device being in inactive mode to full NR capacity, enabled by all control signaling being carried over NR instead of being dependent on LTE and the setup of dual connectivity. The benefit to the consumer is faster access to the full potential of the combined NR capacity when, for example, downloading a file or starting up a video.
To support existing and forthcoming services like voice and emergency when migrating MBB to the 5GS, the NR SA needs to support capabilities and coverage demands like intersystem handover, positioning and QoS. This can be a stepwise migration.
The user data and policies domain
The EPC-5GC tight interworking architecture shown in Figure 1 assumes common subscription management support regardless of the access technology used by a given user. Although a combined HSS/UDM (Home Subscriber Server/Unified Data Management) function is depicted, first deployments support subscription management for the EPC and 5GC by interworking between a separate HSS and UDM through an HTTP/REST (Hypertext Transfer Protocol/Representational State Transfer) interface.
Existing HSS functionality must be evolved to enable interworking with UDM and to support tight interworking between the EPC and 5GC. The evolution includes an upgrade of the HSS functionality offered to EPC serving nodes with, among other things, subscription parameters that enable user access to the 5GC to ensure IP session continuity and single registration across the EPC and 5GC.
Once the 5GC for MBB is introduced, sessions are anchored in the SMF+PGW-C function. The use of SMF+PGW-C allows the policy control and charging rules function (PCRF) used for policy control in the EPC to be replaced by a new dual-mode policy management system that supports 5G-enabled devices regardless of the access technology currently used.
HSS/UDM and PCF/PCRF business logic are also highly dependent on how subscription data and policy subscription data is managed (that is, provisioned, stored and accessed). The EPC allows the support of a data-layered architecture, where the HSS and PCRF make use of an external database to manage subscription data. These databases are known as the User Data Repository (4G-UDR) for HSS subscription data and the Subscription Profile Repository (SPR) for PCRF policy subscription data. The 5GC generalizes the concept into a Unified Data Repository (5G-UDR). The 5G-UDR stores subscription, policy subscription, application and exposure data.
During the introduction of the 5GC it is beneficial to deploy new dual-mode subscription, data and policy management systems that support the EPC-5GC tight interworking architecture and procedures as depicted in Figure 2.
Figure 2: Migration to dual-mode subscription, data and policy management systems
The dual-mode data management system enables both subscription data centralization and single point of provisioning in new 5G-UDR instances for 5G-enabled subscribers. This requires subscription data migration from the legacy 4G-UDR/SPR to the 5G-UDR. This migration process can be assisted by automatic migration tools and/or by auto-provisioning/activation mechanisms enabled by notifications to the BSS/CAS (customer administration system), such as the detection of a 4G-only user using a 5G-capable device and/or being active in the 5GC.
As a first migration step, the HSS functionality in the legacy subscription management system may still be used for 5G-enabled users when they connect through the EPC. The existing HSS instances may reach subscription data for 5G-enabled users from the 5G-UDR through the local 4G-UDR/SPR using proprietary interfaces, for example. The PCF in the dual-mode policy management system supports 5G-enabled users even if they connect through the EPC.
Alternatively, 5G-enabled users may be served by HSS functionality in the dual-mode subscription management system when they connect through the EPC. The dual-mode subscription, data and policy management systems for 5G-enabled subscriptions can coexist with the existing subscription, data and policy management systems for legacy 4G subscriptions (existing HSS and PCRF instances and 4G-UDR/SPR) with the support of a signaling routing function.
In either case, the goal is that all types of subscriptions (even legacy 4G-only subscriptions) are managed on the new dual-mode system for subscription, data and policy management, as shown to the right in Figure 2. The design of this solution follows the principles of a common operational model based on cloud-native implementation and offers its benefits to manage both new 5G-enabled subscribers regardless of the access technology used and legacy 4G users who connect only through the EPC.
The packet core domain
According to our definition, the packet core domain includes functionality to handle access and mobility management (MME, AMF), session management, the serving-gateway-control plane function (SGW-C), PGW-C, SMF and UP functionality (SGW-U/PGW-U, UPF).
The initial introduction of the 5GC for wide-area services allows a migration of RAN and core independently of each other, similar to the transition from 3G to 4G. Prior to the standardization release of 5G, the 3GPP also standardized a separation of the gateway functions in the EPC into control plane (CP) and UP, known as CUPS. This separation enables new opportunities for UP distribution and edge breakout of traffic already in the EPC. Separate PDN connections can use different SGW-U/PGW-Us in central and local deployments, for example. The functional separation of the CP and UP in the EPC CUPS is carried over in the 5GC architecture corresponding to the SMF and UPF.
The availability of both CUPS and EPC-5GC tight interworking enables multiple possible migration paths from the EPC to the 5GC. One option is to first introduce CUPS into the EPS, which enables the operator to use the CP and UP separation before migrating to the 5GS. This can be beneficial to handle increased traffic demand when introducing NR NSA and prepare for a smooth migration to the 5GC based on a UP implementation that supports both the EPC and 5GC.
Another option is to introduce CUPS at the same time as the 5GC by colocating SMF+PGW-C with SGW-C functionality and UPF+PGW-U with SGW-U functionality. This allows the new high-capacity 5G devices to be served by a CP and UP split-gateway architecture when connecting over either 4G or 5G access, as shown in the middle part of Figure 3. An additional benefit of this colocation is the possibility for more flexible distribution of the UP in different locations, for example to address low-latency services by placing the UP closer to the RAN. The 5GC tight interworking can also interwork with a legacy SGW as shown in Figure 1.
Figure 3: Migration from the EPS to the 5GS utilizing EPC-5GC tight interworking
The middle part of Figure 3 also shows that it is possible to continue to use the existing SGW and PGW functionality in the EPC for legacy devices with 4G-only subscriptions when introducing the 5GC, which minimizes the impact on existing services and subscribers. However, the MME needs to support the gateway selection (SGW-C & SMF+PGW-C) for devices with 5GC subscription and 5GC-NAS (non-access stratum) capability. The latter is communicated as part of the tracking area update/attach procedure in the EPS. The MME can also utilize additional methods to assist in the gateway selection, such as dedicated Access Point Names or Domain Name System lookup enhancements. The MME may also need to support restrictions, such as if the operator wants to prevent mobility to the 5GS for certain subscribers.
The next migration step is to combine the full EPC and 5GC functionality into a dual-mode packet core, serving 5G-enabled subscribers regardless of the access technology used and legacy 4G users that connect only through the EPC, as shown on the right side of Figure 3. In this example, the new 5GC devices are served by the SMF+PGW-C, while the legacy 4G-only devices are still served by a separate PGW instance. Other deployment models are also conceivable.
The goal of the migration is therefore a solution that follows the principles of a common operational model based on cloud-native implementation and offers its benefits to both new 5G-enabled subscribers regardless of the access technology used and to legacy 4G users, who connect only through the EPC.
When introducing the 5GS, it is also important to consider future services beyond MBB. One way to future-proof the network architecture is through support for network slicing. In this context, all functions required to support MBB and needed for access and mobility management, session management and the UP (SMF+PGW-C and UPF+PGW-U) are part of an MBB network slice. Hence, a single network slice can be used both for internet access and for IMS voice and other IMS services. This arrangement can be maintained when the device starts on the EPC and moves to the 5GC or vice versa.
The services domain
Regardless of access technology, support for IMS voice, emergency services and SMS is expected to work seamlessly anywhere subscribers can connect to the network. A phone will not select NR SA access unless it detects IMS voice service. Voice and emergency services are supported by specific capabilities in the RAN and Packet Core that must be provided to the combined EPS and 5GS after migration. The IMS needs to be updated to support NR SA.
EPS fallback can be used as a first voice migration step when introducing the 5GS in deployments where NR coverage has underlying LTE/EPC coverage. EPS fallback means that the device is moved to EPS at call establishment. It is typically used prior to the deployment of all the voice capabilities in NR or before the RAN is dimensioned and tuned for voice.
The subsequent voice migration from EPS fallback to voice over NR is achieved by allowing voice calls to be established on NR connected to the 5GC instead of performing EPS fallback at call establishment. This migration step can be done once all required voice-over-NR capabilities are in place in the device and the network, and RAN is dimensioned and tuned for voice. However, devices introduced before this step will remain in the field when voice over NR is introduced, which is why the network must support voice over NR including EPS fallback.
With respect to emergency services, the 3GPP has specified different methods for emergency calls in the 5GS. For example, using a service request to perform EPS fallback of emergency calls is a possible first migration step. The benefit of this approach is that it only impacts the AMF and gNB, and it avoids regulatory requirements on the 5GS related to emergency calls. Migrating to emergency-call-over-NR requires all regulatory requirements related to emergency calls to be addressed. Operators must decide whether to start with a service request for emergency or to deploy emergency-call-over-NR directly.
SMS continues to be an important service in the 5GS. There are two basic methods to transport SMS in the combined 5GS and EPS, namely SMS-over-IP (SMSoIP) using an IMS SIP (Session Initiation Protocol) message and SMS-over-NAS (SMSoNAS) using NAS signaling. The latter uses 5G NAS when the device is in the 5GS and 4G NAS when in the EPS. Operators that use SMSoNAS for devices in the EPS are migrating to support SMSoNAS in the 5GS. Operators that are already using SMSoIP in the EPS may continue to support SMSoIP over the 5GS.
Beyond MBB, 5G also includes a multitude of new and enhanced capabilities addressing many different business segments. It is difficult to predict which of these capabilities will be required in the early introduction of the 5GS and the answer may vary for different operators. Examples of frequently mentioned opportunities for wide-area services are automotive , smart grids for utilities, and public safety.
All of these use cases will utilize the established 5GS MBB scale and wide-area network build-out, specifically if some key architectural concepts are planned for when introducing the 5GS. These include technologies like network slicing, edge computing and network exposure , for which the required functionality is already built-in from the start. These 5GS technologies are also key enablers for local network deployments at hospitals, harbors, airports and manufacturing facilities .
Introducing the 5G System for wide-area services in an existing Evolved Packet System network has significant impacts across all network domains, including the RAN, packet core, user data and policies, and services, as well as affecting devices and backend systems. Nonetheless, a combined 4G-5G network is a necessary step for most operators with existing EPS deployments.
Successful management of this transition requires a holistic strategy that considers all network domains, as well as coverage strategy, spectrum assets and which services to offer where. There are several supported migration paths per domain to a full 5GS, and the transition can be adapted to address each operator’s specific needs per domain. In the longer term, the introduction of 5GS supporting mobile broadband as initial wide-area service is a solid foundation to introduce additional services and use cases, meeting the full expectation on a future-proof 5GS.