Nokia 5g Core White Paper

Independent market research and competitive analysis of next-gene next-generation ration business and technology solutions for service providers and vendors

Designing Cloud-Native 5G Core Networks A Heavy Reading white paper produced for Nokia Corp.

AUTHOR: GABRIEL BROWN, PRINCIPAL ANALYST, HEAVY READING

CLOUD-NATIVE 5G CORE NETWORKS Communication service providers, working with the wider networking industry, are pushing the pace of 5G development. Their objective is to use 5G to support a wide range of services with diverse and demanding performance requirements, and to insert 5G into new i ndustrial value chains. To achieve this objective, 5G requires a new system architecture and a new core network known as Next-Gen Core (NG Core). This white paper discusses the key requirements of the new 5G core and investigates how service providers, and other organizations in the enterprise and public sectors, will deploy NG Core in commercial networks. It argues that a "cloud native" core will enable operators to achieve the flexibility, scalability, reliability and performance needed to meet 5G service targets. The paper discusses the proposed 5G functional architectures now being specified in 3GPP and how these map to cloud-native design principles in real-world implementations.

Service Requirements for NG Core The new core network (a.k.a. NG Core) should support and enable the wide range of services envisioned for 5G. The emphasis, in the first instance, will be on enhanced mobile broadband (eMBB) services, as this constitutes the bedrock of traditional mobile operator business. Over time, however, it is expected that 5G should enable many use cases with very diverse performance requirements across several market segments, as outlined i n Figure 1. Figure 1: Service Dimensions in Future 5G Networks

Source: 3GPP SMARTER

© HEAVY READING | FEBRUARY 2017 | DESIGNING CLOUD-NATIVE 5G CORE NETWORKS

2

Work on this new architecture and core is now underway in 3GPP and i n the wider industry, with vendors and operators developing commercial products and systems. Through this process there are several principles that illustrate what NG Core will l ook like and can inform specification and development. These are as follows: 









Meet Demanding KPIs: Performance is critical to ensure availability, latency, reli ability, user experienced data rates and area traffic capacity. Access Independent: The new core should support multiple access technologies and key functions should be decoupled from access when possible and appropriate. Flexible, Scalable & Programmable: To adapt to change and support dynamic services using network slicing, the new core will use cloud-native architectures and software technologies. Support Real-Time & Non-Real-Time Services: NG Core should support highlydynamic and variable services with appropriate quality of experience (QoE). Interwork With Existing Networks: This includes existing 4G core networks, multiple non-3GPP access types, and service-layer technologies such as IMS/VoLTE and IoT platforms.

5G Phase 1 & Phase 2 The performance targets and use cases envisioned for 5G are very ambitious and linked to different commercial opportunities and timelines. To make 5G introduction more manageable, the industry will deliver 5G in two phases. Phase 1 will focus on the necessary radio and core specifications needed to launch eMBB services and, to some extent, critical communications. Phase 2 will add capabilities to the RAN and core to enable more advanced services – e.g., massive-scale IoT and ultra-reliable and mission-critical services. Phase 1 5G will be forward-compatible with Phase 2, with development occurring in parallel. Coordination between Phase 1 and 2 working groups is important, and this underlines an important wider objective for 5G: to design a system that is forward-compatible, such that it can evolve to meet future service needs. Phase 1 equates to 3GPP Release 15, scheduled to freeze in mid-2018, with some components, such as non-standalone mode (where a 5G radio is deployed with an LTE RAN and core network) expected to freeze at the end of 2017 to enable early 5G deployment. Commercial operation of Phase 1 networks will likely start at a small scale in 2019, and pick up momentum in 2020 as more devices and networks launch. Phase 2 equates to Release 16, scheduled to freeze at the end of 2019, with commercial operations expected from 2020 onward. In parallel to standards development, vendors and operators have been developing prototype equipment that can be used to inform specification work. These prototypes can be updated as details of the standard become known to enable early interoperability testing and to accelerate product development. Prototyping and field tests during the development of the standards is considered very important in 5G, relative to prior generations.

Cloud-Native Evolved Packet Core (EPC) & 5G-Ready Core 4G LTE networks are tremendously successful and continue to grow and evolve. Major new capabilities have been introduced with LTE-Advanced Pro in Release 13 and will soon be


3

commercialized. This means the 4G core itself is evolving in terms of services, architecture and implementation. Many operators are using virtualized core networks to expand into new services, such as cellular IoT or connected car, and to refresh or expand legacy EPC networks. It is l ogical that this virtualized EPC would be cloud-native and, where possible, designed to be "5Gready." Even though 5G will specify new interfaces and functional el ements, experience with cloud-native 4G core networks gives operators a very good insight into the pl atform environment and operational processes needed for NG Core in 5G. Moreover, it is anticipated that 5G will interwork very closely with 4G radio and core and that, over time, the new NG Core will become the common core for 4G and 5G access. In terms of architecture, Control User-Plane Separation (CUPS) in the evolved 4G core provides a guide to the new distributed "User-Plane Functions" being specified for 5G. The "5Gready" core also refers to the underlying IP transport network and data center footprint needed to run distributed services. This secure, multi-service, SDN-controlled IP networking layer needs to be prepared in advance of 5G.

Need for a New Core Network in 5G An evolved core network is needed for 5G. Arguably, today's 4G core represents the apogee of the classic cellular network architecture that has evolved from the mobile telephony model of centralized switching. 5G needs a new, software-centric architecture designed to operate in a modern, cloud-native networking environment. This is true not only in general principle, but also in terms of specific capabilities and services provided by the NG Core. These include: 





Access-Agnostic Core. The existing core is not access-independent. While non3GPP access is supported by the EPC, it requires integration of specific equipm ent to connect, for example, WiFi into the mobile core. In NG Core, mobility management may only be instantiated as needed; fixed access would only need a subset of the NG Core features to operate. The addition of unlicensed radio will also generate new interworking requirements. Connectionless Services. 5G will move from the "always-on" model in 4G to an "always available" model in which connectivity management is used as needed – for example, for session continuity or mobility. This is particularly important for IoT devices that, to save battery life, will not frequently make contact with the network and will instead make infrequent, unscheduled uplink transmissions on both the data and control plane to transmit data and signaling traffic. Ultra-Low Latency & Mission-Critical Services. Some advanced 5G services – such as tactile Internet and industrial control systems – require ultra-low latency. This will generate a new architecture that limits the physical distance between access and core and makes use of distributed forwarding elements. A new session and service continuity model, as well as a new QoS model, that efficiently enables guaranteed services will also be needed.


4

CLOUD-NATIVE MOBILE CORE The cost and performance of Web-scale infrastructure has inspired operators to apply cloud principles to their own networks: commercial-off-the-shelf (COTS) hardware, distributed processing, centralized control, model-driven configuration, automation, etc., now i nform the evolution of operator networks. Figure 2 compares some high-level differences between virtualized networks and cloud-native networks. Given the timeline and the nat ure of 5G services, NG Core will be designed for, and deployed on, cloud infrastructure. Figure 2: Virtualized vs. Cloud-Native Networks (Non-Exhaustive) Virtualization

Cloud-Native

Manual operations; li mited, workflow/scriptdriven automation

Extreme automation, model and policy-driven, "post DevOps"

Investment driven by standard refresh cycles

New investment driven by new business/models, e.g., digital, 5G, IoT

COTS + hypervisor + VNF (perhaps single vendor) with limited orchestration

Multi-vendor, horizontal, interoperable cloud components

Key technologies: COTS servers, Linux, hypervisors, OVS/VPP, OpenStack

PaaS, machine learning, hyper-converged servers, "compact" DCs

Handful of VNFs (limited scaling)

Dozens to hundreds of VNFs (dynamic, ephemeral networks)

Software designs and reliability/redundancy schemes based primarily on physical appliances

Software designs built with cloud principles and cloud reliability and recovery mechanisms

Source: Heavy Reading These design principles are already being applied in advanced 4G networks and this reinforces the view that investment in cloud-based 4G core carries forward to NG Core and that the technology applies to both generations. Some examples are: 











Software disaggregation beyond control and user plane separation; this means smaller software elements that can be independently configured and deployed as part of the overall cloud operations and lifecycle management model Stateless functional software elements, with state efficient processing and a separate common data layer to maximize resource utilization and to support flexible resiliency models Centralized and distributed deployment models to optimize content delivery and enable low-latency services and applications Scale-out/scale-in for lower TCO, increased computing efficiency and service/application agility Automated operations to enable lifecycle management of individual mobile core elements and services Network slice lifecycle management to support multiple services user groups and commercial opportunities


5

NG CORE ARCHITECTURE The 5G functional architecture, including the NG Core itself, i s now under development in 3GPP Release 15. This specification work is fundamental to how the 5G core will be designed and then deployed and operated in commercial networks. The work covers both nonstandalone (NSA) mode, in which the 5G radio is integrated with LTE, and standalone (SA) mode, which enables 5G radio to be deployed using NG Core without any LTE d ependencies. There are two key study groups that have produced the technical reports (TRs) that will inform specification development over the next 18-month period, during what i s known as the "normative phase." TR 38.801 is the study on "RAN Architecture and Interfaces." This includes connectivity to the core network and will be discussed in more detail in the following section. TR 23.799 is the "Study on Architecture for Next Generation System" and is the document that sets out the requirements for NG Core and examines proposed options. Among other things, it identifies two preferred architectures to take forward in Release 15. A foll ow-on activity called "System Architecture for the 5G System" (TS 23.501) will define the actual architecture in Release 15. The two proposed architectures are 1) a point-to-point architecture that can be thought of as a traditional 3GPP architecture; and 2) a service-based architecture that is, arguably, more aligned with modern cloud principles. These two options are not di rectly competitive (as was the case with GTP-based S5 and PMIP-based S5 in EPC, for example), but instead can be thought of as two different ways of representing a common set of functional elements. It is possible, perhaps likely even, that operators will start with a point-to-point architecture and then migrate to a services architecture over time.

Functional Components of NG Core Importantly, the principles outlined in TR 23.799, and the main functional elements, are common to both architectures. The main components of NG Core are: 











Access and Mobility Management Function (AMF): This is a control-plane component that manages access control and mobility; capabilities such as mobility are not needed for fixed access. The AMF will likely also include network slice sele ction functionality. Session Management Function (SMF): This sets up and manages sessions, according to network policy. User Plane Function (UPF): This is equivalent to a gateway (or SGW-U/ PGW-U) in 4G. Operators can use multiple different UPFs, in distributed and centralized locations, according to the service type. Policy Control Function (PCF): This provides a common policy framework incorporating network slicing, roaming and mobility management. Unified Data Management (UDM): Stores subscriber data and profiles. This is similar to an HSS or HLR. NF Repository Function (NRF): This is a new functionality without equivalent in 4G. It provides registration and discovery functionality so that network functions (NFs) can discover each other and communicate directly.


6

Point-to-Point NG Core Architecture At this stage, the architecture shown in Figure 3 looks like it will form the basis of the first iterations of NG Core. This architecture is relatively familiar and flexible, and can meet the 5G service objectives. It splits control- and user-planes and separates access and mobility management (AMF) and session management (SMF) to enable independent evolution and scaling. On the access side, it minimizes core network dependencies by specifying common inte rfaces for 3GPP and non-3GPP access types. In the user plane, it enables advanced features, such as UPF branching, if the service requires. In short, it i s familiar, yet also novel enough, to meet the needs of 5G in the near-term, and is flexible enough to evolve over time. Figure 3: Point-to-Point Next-Gen Reference Architecture

Source: 3GPP TR 23.501, January 2017, Figure 4.2.3-2 One challenge with this model is that a change in topology occurs when a new function is added, and this requires new interfaces to be established between neighboring functions. In effect, service consumption is tied to the network function, and this is one of the factors that makes mobile core networks relatively difficult to change and adapt. NG Core should be virtualized and cloud-based to make changes of this type faster and easier. Another challenge is that while implementation is not specified by 3GPP, in practice, the functional architecture may well determine the deployment architecture and topology. Because this architecture is essentially nodal, it is easy to imagine these functional components will be developed as discrete pieces of equipment or as di screte VNFs. This isn't a bad thing per se, but a truly cloud-native model would probably lean toward a network functions as-a-service model. The problem is, the as-a-service model is difficult to implement and, to some extent, is a leap in the dark, given the maturity of "network cloud" operating systems today.


7

Service Architecture for NG Core The proposed service-based architecture is shown in Figure 4. The functional components are the same as above and the N1, N2, N3 and N4 i nterfaces to the control-plane are similarly unchanged. The difference is that rather than having predefined interfaces between the control-plane nodes, the functions themselves present, as yet undefined, "service interfaces" (APIs) to each other on an on-demand basis. The NF Repository Function (NRF) provides registration and discovery mechanisms to enable the different control-plane components to communicate directly. Figure 4: Next-Gen Service-Based Architecture

Source: 3GPP TR 23.501, January 2017, Figure 4.2.3-1 This model reflects the idea of a "Network Cloud OS," where network services are "composed" using a library of functions hosted in the cloud and "chained" together to create the end-to-end service. This is an attractive architecture, in principle, in that it aligns well with modern networking concepts. The challenge is actually implementing this model, as it reli es on the availability and maturity of cloud networking technologies outside the 3GPP domain – for example, resource and service orchestrators needed to enable this are part of the NFV cloud platform environment that NG Core will be deployed in.

Timing Phase 1 & Phase 2 Capabilities Both architectures introduce new and important architectural principles that will make NG Core flexible and able to meet service requirements. These includes capabilities such as: 

A network slicing concept allowing both vertical and horizontal slicing (with the ability to support different SLAs) and also allowing a user endpoint to access more than one slice simultaneously



Flow-based QoS to tackle better short lived non-GBR flows



Formal control-user-plane separation


8





A clean (orthogonal) split between AMF and SMF (unlike the EPC mode l, in which session management is shared between the MME and the GWs), facilitating independent evolution A new service continuity mode that allows a "make before break" approach, which is needed for ultra-reliable, low-latency applications

Some aspects of the new core don't l ook like they will change radically from prior generations. For example, the N3 interface is li kely to use GTP (with extensions to support flow based QoS) to encapsulate packets between the RAN and UPF elements, as is the case today over the S1-U between base station and gateway. Similarly, the N2 control-plane interface between RAN and the AMF will likely use the SCTP for transport in the same way that S1-MME does in 4G (the N2 application layer interface will, however, differ considerably to S1-MME in order to serve the 5G use cases). A general principle is that 3GPP will use encapsulation for routing in the 3GPP environment and will not modify the user-data packet itself, which means tunneling will continue to be used. Incidentally, the new NG Core will be designed to support non-IP PDUs, such as Ethernet. It's also important to consider timing for NG Core. Release 15 itself (Phase 1) will divide the work into three stages with a view to a freeze in mid-2018. There will then be significant follow-on work in Release 16 (Phase 2). At the start of normative specification work in January 2017, the major differences between Phase 1 and Phase 2 look like as shown in Figure 5. Figure 5: Major Differences in NG Core Features in Phase 1 & Phase 2 Release 15 / Phase 1

Release 16 / Phase 2

No support for connectionless mode, e.g., for IoT; decision made by RAN

Connectionless mode to support mMTC services in RAN and core

3GPP Access and untrusted non-3GPP (e.g., WiFi) All access types (as possible or appropriate) EPC-like access selection

New network discovery and selection mechanism

Limited UR-LLC support for mission-critical communications

Relatively complete UR-LLC specifications

Cellular topology; no relay or mesh support

Support for relays and mesh, pending a base station architecture from RAN

Source: Heavy Reading

Common 4G/5G Core Based on NGC The long-term objective for most operators is to operate common 4G and 5G core networks – with the NG Core providing the ability to support multiple access types (licensed, unlicensed, shared, WiFi and fixed). A common core provides efficiencies and opportunities to deliver a common service portfolio across access types. In the interim period, the 4G core will be critical to the successful introduction of 5G. In the first instance it will support 5G radio access in non-standalone mode; in the second, it will provide mobility between limited 5G coverage and to wide-area 4G coverage using dualconnectivity; and in the third there will be tight integration between the 4G and 5 G packet cores, as shown in Figure 6. (The latest formal 3GPP representation of the interworking architecture can be found in TS 23.501 in Figure 4.3.1-1).


9

Figure 6: Handover Between EPS & NGS

Source: Nokia Operating 4G and 5G cores in parallel, by nature, introduces duplication. To manage this efficiently, it will be important for EPC and NG Core functions to be deployed on a cloud platform with common management and orchestration, and high levels of automation.

STANDALONE & NON-STANDALONE MODES There are two models being developed to i ntroduce 5G radio into commercial services: nonstandalone (NSA), which uses an LTE RAN and EPC for control signaling and user pl ane; and standalone (SA), which does not have dependencies on 4G. Until recently, it had been expected that NSA would lead 5G depl oyment, as it has the backing of influential operators, such as NTT Docomo and Vodafone; but more recently, SA mode has been picking up momentum. It has been included in the R15 work plan, and while it is scheduled to freeze about six months after NSA, it is reasonable to think a viable system could be available for Phase 1 5G deployments. Operators, such as KT and Verizon, have been driving this initiative. It may be that full SA operation with integration to EPC is only available from Release 16 (Phase 2) onward. At this stage, there is no clear industry view on which model will prevail. Some operators like NSA; some prefer SA. However, this is a transitional phase. Eventually, virtually all operators will want a common NG Core environment.

Introducing 5G Radio Using NSA & SA Options 5G radio in NSA and SA modes are shown in Figure 7 (gNB is the new name for eNB or radio base station). In NSA mode, the 5G radio is colocated with the LTE base station and


10

controlled using the dual connectivity mechanisms already specified by 3GPP. Essentially, 5G is adding user-plane capacity to a device that connects simultaneously to LTE and 5G. This basic model is already being developed by LTE-LAA and is likely to be the simplest, fastest way to introduce 5G. In SA mode, the 5G radio connects to the NG Core directly without reference to the EPC or LTE RAN. SA m ode should be deployable in Phase 1, but may not integrate with existing LTE networks until Phase 2. Figure 7: 5G Radio in SA & NSA Modes

Source: 3GPP

Migration Options for NSA to SA Mode There are multiple options for migrating from NSA to SA mode – nine different options, in fact, have been studied in TR 38.801. Figure 8 presents two options for using EPC to support 5G radio and two options for using NG Core supporting 5G and 4G radio. Figure 8: Multiple Options for Migrating to NG Core

Source: 3GPP, Heavy Reading


11

At this stage, Options 3a and 4a (highlighted in red boxes) appear most li kely to be used, although it's worth noting that this remains a lit tle unclear. The evolution of the 4G RAN to eLTE (Evolved LTE) is also an influencing factor. Option 3a uses the LTE radio for control -signaling (dotted line), but the 5G user-plane i nterface (the customer traffic) goes direct to the EPC over the standard S1-U interface, in the same way a secondary cell in LTE does. This is perhaps preferred over Option 3 because it means the legacy eNB is not encumbered by th e traffic from the new high-speed 5G radio and will not become a bottle neck. The preference for Option 4a over Option 4 in the move to NG Core is less clear cut. In both cases the control-signaling is over the 5G radio. In Opti on 4a however, the user-plane goes from the eLTE base station over NG-U to the new core. This may help support non-coll ocated 4G radio and reduce the risk of bottlenecks on the user plane.

CONCLUSION The networking industry at large, and mobile industry specifically, is making rapid progress on 5G. To aide progress in this process, we can make the following recommendations: 







Operators and other organizations should begin their planning for NG Core now, i f they have not already. The industry should take into account the lessons from 4G LTE deployments, where the early adopters gained significant market share over their competition. Cloud-native packet core architectures being deployed today for MBB and IoT/MTC in the 4G networks provide an environment that will help operators evolve with confidence to support NG Core requirements in 5G A wide range of standards-based access technologies, including wireless li censed, unlicensed and shared spectrum, as well as fixed access, will need to be anchored in a common, converged core.

ABOUT NOKIA Nokia is a global leader in the technologies that connect people and things. Powered by the innovation of Nokia Bell Labs and Nokia Technologies, the company is at the forefront of creating and licensing the technologies that are increasingly at the heart of our connected lives. With state-of-the-art software, hardware and services for any type of network, Nokia is uniquely positioned to help operators, governments, and large enterprises deliver on the promise of the Internet of Things, the Cloud and 5G. For more information on the Nokia Cloud Packet Core, please go to https://networks.nokia.com/solutions/packet-core.


12

Nokia 5g Core White Paper

Recommend Documents