Independent market research and

competitive analysis of next-generation

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 ser-
vices with diverse and demanding performance requirements, and to insert 5G into new in-
dustrial 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 per-
formance requirements across several market segments, as outlined in 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 in the wider industry,
with vendors and operators developing commercial products and systems. Through this pro-
cess there are several principles that illustrate what NG Core will look like and can inform
specification and development. These are as follows:

Meet Demanding KPIs: Performance is critical to ensure availability, latency, relia-

bility, 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 highly-
dynamic and variable services with appropriate quality of experience (QoE).
Interwork With Existing Networks: This includes existing 4G core networks, multi-
ple 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 im-
portant 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 compo-
nents, 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 momen-
tum in 2020 as more devices and networks launch. Phase 2 equates to Release 16, sched-
uled 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 proto-
type equipment that can be used to inform specification work. These prototypes can be up-
dated 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

HEAVY READING | FEBRUARY 2017 | DESIGNING CLOUD-NATIVE 5G CORE NETWORKS 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 logical
that this virtualized EPC would be cloud-native and, where possible, designed to be "5G-
ready." Even though 5G will specify new interfaces and functional elements, experience with
cloud-native 4G core networks gives operators a very good insight into the platform envi-
ronment 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 pro-
vides a guide to the new distributed "User-Plane Functions" being specified for 5G. The "5G-
ready" 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 non-

3GPP access is supported by the EPC, it requires integration of specific equipment 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 de-
vices 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 ser-
vices will also be needed.

HEAVY READING | FEBRUARY 2017 | DESIGNING CLOUD-NATIVE 5G CORE NETWORKS 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 inform
the evolution of operator networks. Figure 2 compares some high-level differences be-
tween virtualized networks and cloud-native networks. Given the timeline and the nature 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; limited, workflow/script- Extreme automation, model and policy-driven,

driven automation
Investment driven by standard refresh cycles
COTS + hypervisor + VNF (perhaps single ven-
dor) with limited orchestration
Key technologies: COTS servers, Linux, hypervi-
sors, OVS/VPP, OpenStack
Handful of VNFs (limited scaling)
Software designs and reliability/redundancy
schemes based primarily on physical appliances
Source: Heavy Reading
"post DevOps"
New investment driven by new business/models,
e.g., digital, 5G, IoT
Multi-vendor, horizontal, interoperable cloud
components
PaaS, machine learning, hyper-converged serv-
ers, "compact" DCs
Dozens to hundreds of VNFs (dynamic, ephem-
eral networks)
Software designs built with cloud principles and
cloud reliability and recovery mechanisms

These design principles are already being applied in advanced 4G networks and this rein-
forces 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 ena-
ble low-latency services and applications
Scale-out/scale-in for lower TCO, increased computing efficiency and service/applica-
tion agility
Automated operations to enable lifecycle management of individual mobile core ele-
ments and services
Network slice lifecycle management to support multiple services user groups and
commercial opportunities

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

NG CORE ARCHITECTURE
The 5G functional architecture, including the NG Core itself, is 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 non-
standalone (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 dependencies.

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 is 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 fol-
lowing 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 follow-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 directly 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 ele-
ments. It is possible, perhaps likely even, that operators will start with a point-to-point ar-
chitecture 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 selection 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 loca-
tions, according to the service type.
Policy Control Function (PCF): This provides a common policy framework incorporat-
ing 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.

HEAVY READING | FEBRUARY 2017 | DESIGNING CLOUD-NATIVE 5G CORE NETWORKS 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 man-
agement (AMF) and session management (SMF) to enable independent evolution and scaling.
On the access side, it minimizes core network dependencies by specifying common inter-
faces 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 is 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 func-
tional 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 discrete 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.

HEAVY READING | FEBRUARY 2017 | DESIGNING CLOUD-NATIVE 5G CORE NETWORKS 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 interfaces to the control-plane are simi-
larly unchanged. The difference is that rather than having predefined interfaces between the
control-plane nodes, the functions themselves present, as yet undefined, "service inter-
faces" (APIs) to each other on an on-demand basis. The NF Repository Function (NRF) pro-
vides registration and discovery mechanisms to enable the different control-plane compo-
nents 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 "com-
posed" 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 relies
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 abil-
ity 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

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

 A clean (orthogonal) split between AMF and SMF (unlike the EPC model, in which
session management is shared between the MME and the GWs), facilitating inde-
pendent 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 look like they will change radically from prior genera-
tions. For example, the N3 interface is likely 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 Janu-
ary 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 Connectionless mode to support mMTC services
IoT; decision made by RAN 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 com- Relatively complete UR-LLC specifications
munications
Cellular topology; no relay or mesh support Support for relays and mesh, pending a base sta-
tion 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 dual-
connectivity; and in the third there will be tight integration between the 4G and 5G packet
cores, as shown in Figure 6. (The latest formal 3GPP representation of the interworking ar-
chitecture can be found in TS 23.501 in Figure 4.3.1-1).

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

Figure 6: Handover Between EPS & NGS

Source: Nokia

Operating 4G and 5G cores in parallel, by nature, introduces duplication. To manage this effi-
ciently, it will be important for EPC and NG Core functions to be deployed on a cloud plat-
form with common management and orchestration, and high levels of automation.

STANDALONE & NON-STANDALONE MODES

There are two models being developed to introduce 5G radio into commercial services: non-
standalone (NSA), which uses an LTE RAN and EPC for control signaling and user plane; and
standalone (SA), which does not have dependencies on 4G.

Until recently, it had been expected that NSA would lead 5G deployment, as it has the back-
ing 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 sys-
tem 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 op-
erators 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

HEAVY READING | FEBRUARY 2017 | DESIGNING CLOUD-NATIVE 5G CORE NETWORKS 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 mode 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 sup-
port 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

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

At this stage, Options 3a and 4a (highlighted in red boxes) appear most likely to be used,
although it's worth noting that this remains a little 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 inter-
face (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 the 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 Option 4a however, the user-plane goes
from the eLTE base station over NG-U to the new core. This may help support non-collo-
cated 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, if
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 confi-
dence to support NG Core requirements in 5G
A wide range of standards-based access technologies, including wireless licensed,
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.

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