White Paper

Cloud-Native Packet Core for

Operator IoT Services

Prepared by

Gabriel Brown
Senior Analyst, Heavy Reading
www.heavyreading.com

on behalf of

www.nokia.com

October 2016
 Cloud-Native IoT Core Networks
Mobile operators are embracing software-centric, cloud-hosted core networks as
they seek flexibility, agility and a cost model that scales with the service type. The
transition from appliance-based mobile cores to virtualized, "cloudified" and "cloud-
native" core networks enables operators to better match infrastructure to services,
to pursue new commercial opportunities at relatively low incremental cost, and
then to rapidly scale them if they are successful.

One of the first areas to benefit from this transition is the Internet of Things (IoT). Cel-
lular IoT is a growth segment that has specific core network processing requirements
that are not readily addressable, at the desired price points, by the classic,
smartphone-orientated mobile core. IoT service requirements, and operator invest-
ment cycles, make it an ideal candidate for a cloud-native core network.

This white paper will discuss cloud-native mobile packet core with a focus on IoT.
The first section covers the commercial drivers and the benefits of dedicated core
networks, optimized to the needs of the IoT service. The second section looks at
network design and technology trends. The third discusses the results of a Bell Labs
total-cost-of-ownership (TCO) model that shows a substantially more favorable cost
base is possible with a cloud-native IoT core.

Mobile Operator IoT Strategies

Virtually all major industrial sectors are investigating IoT. The technology is rapidly
becoming a requirement to transform operations and to drive new lines of business.

There are many types of wireless networking solutions for IoT, from low-power wide-
area networks, to capillary networks, to WiFi, Bluetooth, ZigBee and other local area
standards. Licensed cellular networks are also highly suitable for many of these ap-
plications. Mobile operators have been active in the market for many years, notably
through the use of GSM modules for machine-to-machine (M2M) services, and the
recent standardization of Narrow-Band IoT (NB-IoT) in 3GPP Release 13 offers a long
term roadmap for low-power services.

Cellular IoT benefits from the established mobile operator eco-system: standards
help drive volume and economies of scale; radio access networks (RANs) offer
good coverage; existing RANs can be updated in software to support new IoT ca-
pabilities; the commitment to carrier-grade reliability helps ensure availability (par-
ticularly important in the core network); and where mobility is required – connected
cars, for example – cellular networks are obviously the primary option.

Support for IoT has been part of Long Term Evolution (LTE) since the initial specifica-
tions were developed (see Cat-0 Cat-1, etc.) Ongoing development has resulted in
three new/evolved solutions in 3GPP Release 13 (frozen in mid-2016), designed to
cover a range of use cases. They are: EC-GSM-IoT, which stands for Extended Cov-
erage GSM for IoT; LTE Cat M1, a low power enhancement to existing LTE radio; and
NB-IoT, which is a new radio interface that can be deployed "in-band" using existing
LTE resource blocks. Over the same period, there has been concomitant develop-
ment of the core network in 3GPP to support these new radio interfaces.

5G introduces yet more capability to IoT, targeting massive-scale and ultra-dense

deployment scenarios that are scalable across throughput, latency and energy

HEAVY READING | OCTOBER 2016 | WHITE PAPER | CLOUD-NATIVE PACKET CORE FOR OPERATOR IOT SERVICES 2
 consumption. Strategically, operators can start to develop a cloud-native IoT core
networks that will be common to both 4G-LTE and 5G access.

Diverse Performance Requirements Drives Dedicated IoT Core

There are many types of IoT service, each with specific performance or economic
requirements. Figure 1 shows how a connected car service, for example, drives a
large amount signalling traffic over the control plane due to mobility events,
whereas smart meters interact infrequently with the network to reduce power con-
sumption and therefore generate far less signalling.

Figure 1: IoT Service Types & Performance Aspects

DEVICES & CONTROL PLANE DATA PLANE

MOBILITY LATENCY
BEARER SCALE SIGNALING THROUGHPUT

Smart Me- Massive

Low (2-10 t/hr) Low None High tolerance
ters (many millions)
Non-Con- Moderate
High (2-10 t/hr) Low None Low tolerance
sumer Video (10+ thousands)
Connected High Moderate
High (millions) High Frequent
Car (500-1000 t/hr) tolerance
Smartphone Moderate Moderate
High (millions) Moderate Frequent
Users (200-500 t/hr) tolerance

Source: Nokia

This diversity of services is a major reason for operators to pursue dedicated core net-
works for IoT. The idea is to create virtual cores for different service types and optimize
this core according to the traffic profile – for example, if the service involves lots of
signalling and mobility events, a high-transaction rate is needed in the core. If a ser-
vice generates a lot of data (e.g., video surveillance), high throughput will be re-
quired, but mobility may not be needed. If a service is mission critical, quality of service
(QoS) mechanisms will be needed, and so on. Virtualization makes it far easier to de-
ploy and operate dedicated core networks based upon common service character-
istics, or for specific user groups, than was the case with physical appliances.

Propensity to Deploy IoT Core Networks

A Heavy Reading operator IoT survey released in winter 2016 indicated that a ma-
jority of operators (53 percent of individual operator employee respondents) expect
to deploy a dedicated core of some form. This is shown in Figure 2 below.

Anecdotally, based on information gathered since the survey, we believe that of

those operators that intended to select a new core, the large majority will select a
virtual option. However, for some use cases, such industrial enterprise networks, a ded-
icated physical core would be suitable (in many cases this would be a virtual "core-
in-a-box" type product, packaged as an appliance); in other cases, virtual core will
be deployed in hybrid mode where the core contains a mix of classic appliance and
virtual functions (for example, a virtual GGSN may be used with a classic MME/ SGSN).

HEAVY READING | OCTOBER 2016 | WHITE PAPER | CLOUD-NATIVE PACKET CORE FOR OPERATOR IOT SERVICES 3
 A not insignificant 25 percent expect to scale their existing core for IoT or M2M.
Where an operator is not yet ready make a strategic investment in a dedicated
core, this can be a way to participate in IoT prior to making a commitment to new
technologies and platforms.

Figure 2: What is your Company’s Plan for its IoT/M2M Core?

Source: Heavy Reading’s Operator IoT Survey, January 2016 (n=131)

The five percent of operator respondents that said they would use a cloud-based
Infrastructure as a Service (IaaS) for IoT are interesting. The low score no doubt partly
reflects the fact that operator respondents are, in general, less likely to say they
would use a third party to host their core, and partly that our survey base contained
a large proportion of large, technically-advanced operators that would typically
run their own infrastructure, especially in the core.

Informed speculation suggests that the Iaas or PaaS models may better suit smaller
operators, greenfields or subsidiaries of larger operators. It is also interesting to think
about what end customers might select; we suspect enterprises using IoT are open
to IaaS or PaaS, whether provided by a carrier or other third party.

HEAVY READING | OCTOBER 2016 | WHITE PAPER | CLOUD-NATIVE PACKET CORE FOR OPERATOR IOT SERVICES 4
 Virtual EPC Network Design & Technology
The industry has made good progress on virtual Evolved Packet Core (EPC). There
are now networks in live service all around the world, several of which are operating
at mass-market scale. This is generating confidence in the technology and encour-
aging operators to be more ambitious in their development strategies.

One learning to date is that virtualization of the existing product portfolios is only
really part of the solution – a good first step, but not transformational. More useful
over the long term would be a software-based core designed to run in the cloud,
with an attendant operations model. This is sometimes called "cloud native."

Toward 'Cloud Native' EPC & NG Core

But what is cloud native? There is no tightly agreed definition and, for stateful telecom
applications in particular, the term is open to interpretation. The Cloud Native Com-
puting Foundation refers to applications that are a) packaged in containers; (b) dy-
namically managed by a central orchestrator; and (c) micro-services oriented. At face
value, these criteria are applicable to modern EPC functions and to NG Core in 5G.

Virtual EPC design has moved from replicating boxes in software (virtualized) to devel-
oping "lean" VNFs that can run more efficiently in VMs and sit under a management
and orchestration system (cloudified). A third phase (cloud native) is now underway in
which the VNFs are deconstructed into smaller components, and operators are able
to take advantage of extreme automation in deployment and operation of the de-
constructed processes or "micro services." These three horizons are shown in Figure 3.

Figure 3: Towards Cloud NFV

Source: Heavy Reading

The differences between the three phases are outlined in Figure 4 below. The first
phase, "virtualization," has been under way for few years and has established that
VNFs are a viable option for the mobile core and that a software solution should be
the starting point for new investment and refreshes. The second phase is "cloud-
ifcation" of VNFs to run on shared infrastructure under some form of orchestration
and management system. This phase is underway and in live deployment. To date,
it tends to be restricted to a handful of carefully curated and monitored VNFs, but
progress is reasonably rapid, especially for less critical enterprise VNFs.

HEAVY READING | OCTOBER 2016 | WHITE PAPER | CLOUD-NATIVE PACKET CORE FOR OPERATOR IOT SERVICES 5
 The cloud native phase will incorporate functions designed for the cloud that are
deployable on a horizontal, shared infrastructure without the need for a manual
involvement in on-boarding, scaling and monitoring. This phase incorporates the
leading cloud technologies and application design trends, and is applicable to the
IoT core in 4G-LTE networks and with deployment of NG Core in 5G networks in the
2020 timeframe.

Figure 4: Three Horizons for Cloud Native Telecom Functions

HORIZON 1: VIRTUALIZATION HORIZON 2: CLOUDIFIED HORIZON 3: CLOUD NATIVE

Timescale: 2010-2016 Timescale: 2014-2022 Timescale: 2017-2026

Fast followers starting to adopt, main-
Early adopters starting here Early adopters aiming here
stream making plans
Limited, workflow/script-driven auto- Extreme automation, model and pol-
Manual operators
mation; some agile development icy driven, "post DevOps"
Investment driven by normal refresh Investment driven by normal refresh New investment driven by new busi-
cycles cycles ness/models, e.g., digital, 5G, IoT
Investigating open source Adopting open source Contributing open source
Vendor-integrated solution
Vendor-integrated solution Multi-vendor, horizontal, interopera-
(COTS+cloud stack+VNF(s)+orches-
(COTS+hypervisor+VNF+support) ble cloud components
tration)
Critical technologies: COTS servers, PaaS, containers, optimization, ma-
OpenStack, MANO, service orches-
Linux, hypervisors, OVS/VPP, chipset chine learning, hyper-converged
tration, SDN
enhancements servers, "compact" DCs
Dozens-hundreds of VNFs (dynamic,
Scale: single VNF (static) Handful of VNFs (limited scaling)
ephemeral networks)

Source: Heavy Reading

Control- & User-Plane Separation

Changes underway in the mobile network architecture, designed to aid scalability,
also favor cloud-native network design. Control- and user-plane separation (CUPS)
is being introduced into advanced 4G-LTE networks to help operators capture the
scale economics and flexibility associated with the "distributed processing, central-
ized control" paradigm of Web-scale cloud providers. CUPS also allows operators to
better address demand for lower-latency services, to scale the user plane at lower
costs and provide a bridge to NG Core in 5G.

One way to scale a classic EPC is to simply deploy more packet gateways (and
mobility controllers) at the edge of the network. The challenge is that EPC deploy-
ments can often be characterized by complex integration with surrounding network
functions, such as policy, charging, IMS, SGi-LAN, security and routing services, and
by moving this model to the edge, the operator would, in effect, have to "distribute
complexity," which can be costly to deploy and manage.

The CUPS architecture is a response to this. It splits the core network into simplified
user-plane nodes, known as S/PGW-U, and dedicated control-plane nodes, includ-

HEAVY READING | OCTOBER 2016 | WHITE PAPER | CLOUD-NATIVE PACKET CORE FOR OPERATOR IOT SERVICES 6
 ing S/PGW-C, MME, PCRF, etc. A key benefit is that each node type can scale inde-
pendently. Typically, at least logically, the user plane would be distributed and the
control plane centralized.

In this model, the user plane is simplified (because it no longer needs to interact di-
rectly with control-plane functions, such as policy servers and charging systems) and
can be optimized for packet processing and policy enforcement. There are several
ways to implement S/P-GW-U nodes, such as in a router, a switch, a standard packet
gateway or VNF. In practice, virtual nodes are likely to be most widely used because
with modern data-plane optimization techniques performance is now very good, and
because the flexibility of virtual nodes makes it easier to deploy and scale user-plane
nodes as and where they are needed.

The control-plane node, meanwhile, can be centralized such that it supports multiple
user-plane nodes and provides a single-point of integration with neighboring func-
tions, such as subscriber data bases, policy servers, billing engines and cloud data
stores. If changes are required to any these associated systems, they can be made
without impacting the multiple user-plane nodes. This should make mobile core net-
works far more adaptable to change, enabling operators to more rapidly adapt to
innovations in the broader online services market. This CUPS model is being adopted
for the NG Core in 5G – albeit with new interfaces and (probably) new protocols.

State Efficient Operation

The mobile core network is stateful in the sense that it keeps track of user connection
state (active, idle, bearer-type, policy, etc.). Setting up and modifying bearers is re-
source intensive and maintaining this information in state consumes significant packet
core function resources. State-efficient operation is a way to address this. The idea is
to extract the user state from the packet core functional processes and place it in a
"cloud data store" when there is no requirement to actively process state information.
This is shown in Figure 5.

Figure 5: State Efficient Core Network

Source: Nokia

For example, a device may set up a bearer (requiring control-plane transactions), but
once the session is live (a bearer is established and traffic is passing between the de-
vice and network) there may be no need to maintain the user's control-plane state in
the packet core functional process. The information can be moved to a cloud data
store, freeing up compute resources and allowing the operator to multiplex more us-
ers onto the same resource, thereby increasing efficiency. This model can be applied
to all types of services from smartphones to small-packet sensor services and is a tan-
gible example of cloud native design.

HEAVY READING | OCTOBER 2016 | WHITE PAPER | CLOUD-NATIVE PACKET CORE FOR OPERATOR IOT SERVICES 7
 Dedicated Core Networks & Network Slicing
Dedicated core networks (sometimes known as network slices) can be service spe-
cific and customer specific, or both at the same time. For example, the operator
could create a core network for meter reading services and offer it to multiple com-
panies. This multitenant core is optimized for low mobility, small packets and infre-
quent uplink transmissions, and can be dimensioned and priced accordingly. In
some cases, the operator could provide a dedicated core to a single enterprise
customer – for example, meter reading services for a single large utility company.
This general principle applies across industries and across customer types, from con-
nected car, to healthcare, to agriculture, to utilities.

Dedicated core networks enable virtual private 4G-LTE networks to operate on a

public RAN. Enterprises with specific networking requirements, or particularly sensi-
tive information, may choose a logically separated service with a private virtual
packet gateway, which they can use to manage their own users and policies. These
are sometimes called private virtual network operators (or PVNOs). Heavy Reading
expects this to be a growth segment for operators and vendors.

In other scenarios, this model can be used to offer secure, private networks over
both shared and private LTE RANs. For example, a manufacturing business may op-
erate a private RAN on-premises, using small cell technology, and also need wide-
area connectivity from the public network for off-site connectivity. A dedicated
core network can be used to unify these different access and create an enterprise-
specific virtual mobile network.

There are several mechanisms for directing traffic from the LTE RAN (shared or pri-
vate) into the dedicated EPCs. These are:

• APN Routing. This is the standard way of segmenting and routing traffic on
a public mobile networks. It is reasonably flexible and scalable and is
much easier from an operations perspective since device management
complexity has been addressed. Typically, the APN is mapped to an ap-
propriate class of service in the transport network and the user traffic de-
livered to the appropriate P-GW (or virtual instance thereof).

• MoCN. Multi-operator core networks (MoCNs) were introduced to support

radio network sharing arrangement between operators. Each operator
manages its own SIM cards and broadcasts its own network ID and, in this
sense, it is not a very granular mechanism. It is best suited to larger scale
dedicated core networks, such as used by larger MVNOs.
• DECOR. Dedicated Core Networks (DECOR) is a new capability being in-
troduced to specify how devices connect to dedicated cores over LTE
RANs without using different network IDs. It is well suited to IoT services
and general enterprise services. The initial specifications are part of Re-
lease 13, with further enhancements scheduled for Release 14.

One common theme is that, on the SGi interface, operators must be able to map
traffic and users to an appropriate IP routing path in the transport network – for ex-
ample, into an IPsec or MPLS VPN for enterprise services, to the SGi-LAN service net-
work if specialized services need to be applied (such as video optimization, URL fil-
tering and so on) or to an IoT service platform.

HEAVY READING | OCTOBER 2016 | WHITE PAPER | CLOUD-NATIVE PACKET CORE FOR OPERATOR IOT SERVICES 8
 Networks slicing is even more important in 5G. It underpins the economic case for
the technology ("many services on one network") and is integral to standards de-
velopment. The proposed new NG Core architecture introduces the Network Slice
Selection Function (NSSF) to determine to which core instances the device should
connect to. Moreover, it is anticipated that slices will extend end to end across the
radio and core. This implies the use of slice-aware scheduling in the RAN.

IoT Core Architectures

As part of the work on cellular IoT (CIoT) and narrow band IoT (NB IoT), the 3GPP has
modified the network architecture for small-packet services, such as meter reading
or environmental monitoring using sensors. These services can be transported via a
standard EPC; however, the nature of the traffic means the classic core network
dimensioning is not entirely well suited to the service.

Two simplified architectures, optimized to transport small data over the NAS control
channel, have been developed as alternative options. These are the "T6a option" with
an interface from the MME and the "S11-U option" that uses an interface from the MME
to a packet gateway for delivery via the SGi. In each case, a dedicated IoT core would
be deployed and connected to the RAN via the S1-lite interface, a modified version
of the existing S1-MME interface (which is used for control-plane signalling).

In each architecture, payload data is sent over the NAS channel. One advantage
of this is that device can re-use the security association set up with the MME and
therefore does not require new S1 and over-the-air transactions each time a trans-
mission has to be performed. These changes to session management procedures
are an important small-packet IoT optimization.

S11-U Option
In this option, the device connects to the MME over the S1-lite interface, but does not
need to set up a bearer to the serving gateway, as would be the case for a smart-
phone. Instead, the MME is modified to support payload traffic and upgraded with a
new S11-U interface that can send payload traffic to the service gateway (previously
S11 was a control-plane interface used for gateway selection), as shown in Figure 6.

Figure 6: Cellular IoT Architecture with S11-U Interface

Source: 3GPP TS 23.720 V13.0.0 (2016-03)

This is a relatively straight-forward extension of the existing architecture and has

broad operator support as a way to deploy an NB-IoT overlay core. One benefit of
using a (virtual) packet gateway is that data can routed onward, via the correct

HEAVY READING | OCTOBER 2016 | WHITE PAPER | CLOUD-NATIVE PACKET CORE FOR OPERATOR IOT SERVICES 9
 MPLS or IP VPN, to the IoT service platform; if the gateway is "IP services-capable,"
this removes the need to deploy an additional IP service routing platform.

T6a with C-SGN Option

In this architecture, the device connects over S1-lite to a new dedicated IoT core
network node. This node incorporates a combination of functions that traditionally
reside in MME, SGW and PGW to create a function called the Cellular IoT Serving
Serving Gateway Node (S-CGN). Again, no user-plane bearer is set up; only the NAS
channel is used. This is shown in Figure 7.

The C-SGN does not forward payload over an SGi interface as a S/P-GW does in the
classic architecture (or the S11-U option above), but instead forwards it over a new
T6a interface to a Service Capability Exposure Function (SCEF) and then onward to
service platform. This is less well developed than the S11-U option, but because the
SCEF connects to service platforms over a REST API it could perhaps be perceived
as more "cloud friendly" than S11-U by some parties.

Figure 7: Cellular IoT Architecture with C-SGN Node

Source: 3GPP TR 23.720 V13.0.0 (2016-03)

It is not clear the extent to which of the two new architecture options operators will
use. Both have advantages and the decision is likely to be driven the maturity of the
solution available from vendors and the operator's own timeline and operational
preferences.

HEAVY READING | OCTOBER 2016 | WHITE PAPER | CLOUD-NATIVE PACKET CORE FOR OPERATOR IOT SERVICES 10
 Total Cost of Ownership for IoT Core
The economics of IoT services demand a different network cost model. The smart-
phone orientated core network, and associated costs, is not suitable for service with
a markedly different traffic profile and end-customer pricing model. Simply put, an
operator can't charge as much per connection for an air quality monitoring sensor,
or irrigation sensor, as it can for a high-end smartphone. A new approach to the IoT
core, that offers much lower cost per connection, is needed

A TCO study carried out by Bell Labs Consulting illustrates how virtualization and
cloud can drive a radical decrease – of the order of 60 percent over five years – in
the cost of IoT core network connections. Figure 8 shows how this can apply to net-
works with 10 million and 100 million connected devices.

Figure 8: TCO Model for Cloud-native IoT Core

Source: Nokia Bell Labs Consulting

The study was developed using current (2016) market data and normalized, real-
world pricing. Heavy Reading has had a chance to review the output of the model
with individuals that helped develop it. We have not reviewed the model in detail,
however, input data, related to pricing of EPC, for example, aligns well with our own
market sources, and the output, in terms of the overall cost of a virtual IoT core, also
align well with how we understand the strike price of commercial contracts in the
market today. In short, it provides a useful guide to the TCO benefits of a dedicated
virtual core with the (obvious) caveat that the individual operator contracts are
generally customized and deviate from the model, often in multiple aspects.

The chart above shows the TCO for a mixed IoT network scenario over five years.
The traffic model includes smart meter services, non-consumer video (which in-
cludes both uplink services, such as video surveillance, and downlink services, such
as digital billboards/signage, etc.) and connected car (which includes all traffic
generated by the car, including passenger voice/data/video and services, such as
telemetry, navigation, etc.). This is a good, variegated traffic profile and is more or
less reflective of commercial networks. The traffic mix changes over the five-year

HEAVY READING | OCTOBER 2016 | WHITE PAPER | CLOUD-NATIVE PACKET CORE FOR OPERATOR IOT SERVICES 11
 period as connected cars, in particular, increase in importance. The study also in-
cludes breakouts for smart-meter-only, connected-car-only and non-consumer
video, but these are not shown in this paper.

The model shows two scenarios – a network with 10 million devices and one with 100
million devices – to show the impact of scale on cost of ownership. In each case,
the subscriber numbers increase over the five-year period. In the 10 million device
case, the network supports two million devices in year one, four million in year two,
six million in year four and so on. In the 100 million device, cases scales in 20 million
device increments.

The cost reduction associated with a cloud implementation comes in part from
lower license pricing by the EPC vendor for IoT – required for services, such as smart
meters that cannot support a high per-device licensing cost – and in part from re-
duced hardware cost.

Hardware cost savings from moving to the cloud are substantial. As a rule of thumb,
according to our sources, the COTS hardware need to run an EPC is around one-
tenth of the price of vendor-specific appliance hardware, excluding the cost of the
VIM, orchestration and non-recurring engineering cost to design the solution. Actu-
ally achieving this cost reduction today, however, requires a careful engineering
process to optimize the CPU resource utilization. It is relatively easy to achieve the
required EPC scale with a virtual solution by deploying lots of servers. However, this
is inefficient in capex and opex terms.

To optimize a virtual deployment requires a very well-designed VNF and a good

understanding of the deployment environment. CPU version, types of NIC cards,
data-plane acceleration techniques and even the firmware versions are examples
of factors that are important to real-world performance.

There is, therefore, a really significant opportunity associated with NFV life-cycle
management and SDN control. By automating network operations through the use
common ways to represent resource availability/constraints, placement and on-
boarding of VNFs, and model-driven configuration of services comprising multiple
VNF types, operators can achieve major TCO benefits. However, advances in the
cloud platform also require the VNFs themselves evolve in a cloud-native manner.

Cloud-native packet core is an ideal use case to put these technologies into prac-
tice and can generate the flexibility and efficiency saving operators need to profit-
ably provide IoT connectivity services at a cost point that will encourage customers
to adopt mobile operator IoT services.

About Nokia
Nokia is a global leader in the technologies that connect people and things. Pow-
ered 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 ser-
vices for any type of network, Nokia is uniquely positioned to help operators, gov-
ernments, 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://net-
works.nokia.com/solutions/packet-core

HEAVY READING | OCTOBER 2016 | WHITE PAPER | CLOUD-NATIVE PACKET CORE FOR OPERATOR IOT SERVICES 12