Content uploaded by Xuan Zhou
Author content
All content in this area was uploaded by Xuan Zhou on Jul 08, 2018
Content may be subject to copyright.
IEEE Communications Magazine • July 2016
146 0163-6804/16/$25.00 © 2016 IEEE
AbstrAct
With the blossoming of network functions vir-
tualization and software-defined networks, net-
works are becoming more and more agile with
features like resilience, programmability, and
open interfaces, which help operators to launch
a network or service with more flexibility and
shorter time to market. Recently, the concept of
network slicing has been proposed to facilitate
the building of a dedicated and customized log-
ical network with virtualized resources. In this
article, we introduce the concept of hierarchi-
cal NSaaS, helping operators to offer custom-
ized end-to-end cellular networks as a service.
Moreover, the service orchestration and service
level agreement mapping for quality assurance
are introduced to illustrate the architecture of
service management across different levels of
service models. Finally, we illustrate the process
of network slicing as a service within operators
by typical examples. With network slicing as a
service, we believe that the supporting system
will transform itself to a production system by
merging the operation and business domains,
and enabling operators to build network slices
for vertical industries more agilely.
IntroductIon
Although the data traffic of mobile terminals
is increasing rapidly, the consumer market of
mobile broadband services is going to be sat-
urated in North America, Europe, and East
Asia [1]. Meanwhile, the growing popularity of
machine type communication (MTC) terminals
and applications of vertical enterprises poses
an increasing demand for diverse services from
mobile networks. However, legacy mobile net-
works are mostly designed to provide services
for mobile broadband consumers, and merely
consist of a few adjustable parameters like pri-
ority and quality of service (QoS) for dedicat-
ed services. Therefore, mobile operators find
it difficult to get deeply into these emerging
vertical services with different service require-
ments for network design and development. For
example, the dedicated network for a railway
company just involves the coverage along the
railway with high-speed mobility management,
but exhibits apparent difference from that of
an electricity metering company, which only
requires small-volume data transmission but
massive connections at static positions. Some
vehicle communication services are strictly
delay-sensitive, while some video surveillance
services require stable and immobile high band-
width. Recently, network functions virtualiza-
tion (NFV) technology has been proposed to
decouple the software and hardware of network
elements so as to simplify service development.
A study by the European Telecommunications
Standards Institute (ETSI) shows that NFV
and software-defined networking (SDN) could
shorten time to market and facilitate innova-
tions in the technical field (e.g., saving main-
tenance cost, auto-scaling, enhancing system
resilience) [2]. Nevertheless, currently the prod-
ucts and service types from operators are still
limited. In order to enrich operators’ products
for vertical enterprises and provide service cus-
tomization for emerging massive connections, as
well as to give more control to enterprises and
mobile virtual network operators (MVNOs), the
concept of network slicing (NS) is proposed to
allow the independent usage of a part of net-
work resources by a group of mobile terminals
with special requirements [3, 4].
NS aims to logically separate the set of net-
work functions and resources within one network
entity, according to specific technical or commer-
cial demands. Although the concept of NS is still
nascent, similar techniques already exist. Among
them, IEEE 802.1Q, virtual local area networks
(VLANs), which can be regarded as the ances-
tor of NS, provides a single broadcast domain
to bring together a group of hosts possibly hav-
ing no local and physical connectivity but shar-
ing common interests. Moreover, in the field of
fixed networks, Internet Engineering Task Force
(IETF) RFC 4026, which is also known as vir-
tual private network (VPN), is another form of
NS, which could guarantee the QoS and security
requirements for logically independent sessions
[5]. However, in cellular networks, the realization
of NS faces significant challenges, since more
parameters such as mobility and authentication
Network Slicing as a Service:
Enabling Enterprises’ Own
Software-Dened Cellular Networks
Xuan Zhou, Rongpeng Li, Tao Chen, and Honggang Zhang
network And servIce MAnAgeMent
The authors introduce the
concept of hierarchical
NSaaS, helping operators
to offer customized end-
to-end cellular networks
as a service. Also, the
service orchestration and
service level agreement
mapping for quality assur-
ance are introduced to
illustrate the architecture
of service management
across different levels of
service models.
Xuan Zhou and Rongpeng Li are with Huawei Technologies Co., Ltd.; Tao Chen is with VTT Technical Research Centre of Finland;
Honggang Zhang is with Zhejiang University.
IEEE Communications Magazine • July 2016 147
management in the control plane as well as ses-
sion and charging management in the user plane
need to be customized for a group of connections
as a logical network. Fortunately, NFV and SDN
can make NS a reality, with NS allowing opera-
tors to customize networks according to various
requirements of mobile services, thus leading
to a more cost-effective way to build dedicated
networks. Therefore, NS is attracting signifi cant
interest from both industry and academia. For
example, the Fifth Generation Infrastructure
Public Private Partnership (5G-PPP) project
5GEx introduces a business model of NS among
infrastructure owners, wholesale providers, retail
providers, content providers, and end users
[6]. The Third Generation Partnership Project
(3GPP) also initiated a technical study into NS
to specify service requirements and operation-
al requirements [7]. Vendors such as Ericsson,
Huawei, Nokia, and ZTE have also published
white papers about NS to introduce the reali-
zation of NS into 5G [8]. In fi xed networks, NS
has been implemented to logically separate the
networks, allowing slice owners to manage their
own networks [9]. Another case is NS for emer-
gency communications, which provides dedicated
and priority resources to users for emergency
communications, even in overwhelming scenar-
ios [10]. However, due to the scattered service
models across radio access networks (RANs),
core networks (CNs), and transport networks,
and complex protocols in tens of 3GPP inter-
faces, the realization of mobile NS seriously lags
behind its counterpart in fi xed networks. Spe-
cifi cally, there is still lacking an end-to-end ser-
vice description of the mobile network for the
northbound interface to deploy or manage a
multi-vendor network slice across the domains
with thousands of parameters. The study and
standardization of NS are still at a rudimentary
level, and give little insight into the mapping
from business model and service operation
[7]. In this article, following the operators’
perspective provided by the Next Generation
Mobile Network Alliance (NGMN) [3], we
introduce the concept of network slicing as a
service (NSaaS) with service models and man-
agement, and introduce how to technically
realize the proposed business models.
This article is organized as follows. The next
section introduces the concept and business
models of NSaaS. We then propose the ser-
vice models and service orchestration for NS as
a bridge of business model and technical reali-
zation. After that we describe the management
features of NSaaS such as auto-configuration,
product management, and application program-
ming interfaces (APIs). The final section con-
cludes the article.
network slIcIng As A servIce
busIness Model oF nsAAs
Recently, the information and communications
technology industry is boldly embracing the con-
cept of “something” as a service (XaaS), which
refers to being able to call up reusable, fine-
grained software components across a network.
For example, Tarik Taleb et al. [11] studied the
feasibility of on-demand creation of cloud-based
elastic mobile CNs, along with their lifecycle
management; Wanfu Ding et al. [12] presented
the design of an open platform for service chain
as a service, by using the tangible capabilities of
SDN and NFV. In this article, we discuss how
operators agilely provide a customized network
slice for their customers as a service, which is
called NSaaS. According to the relationships
between service providers and consumers, the
business models of NSaaS can be categorized
into three classes as below.
Business to Business (B2B): Operators sell
the network slice to a company who owns both
the network and terminals, such as video surveil-
lance networks for security companies and smart
factory networks for manufacturing companies.
In the B2B case, operators not only provide cus-
tomized wireless connections to enterprises, but
also release full control of terminals to the enter-
prise.
Business to Consumer (B2C): End consumers
are able to purchase customized data pipes from
operators for their terminals like smart home
devices. In the B2C case, end customers could
enjoy the slice once they put subscriber identi-
fication module (SIM) cards inside their devic-
es. Generally, customers just use the customized
network, but do not possess the network with
service separation.
Business to Business to Consumer (B2B2C):
The operator plays the role of wholesale pro-
vider; meanwhile, a broker like an MVNO helps
operators to be engaged with end customers.
In this case, operators just provide dedicated
connections, called MVNO as a service, to the
broker, without involving the business part. How-
ever, the broker could get more control of the
network than traditional MVNOs, who could
only get billing fi les from mobile network oper-
ators (MNOs).
From another perspective, there are three
service scenarios of NSaaS, which have different
life cycles, service objects, and slice scales:
• Industrial slice: Customers with the same
network service requirements are regis-
tered with the same slice, which abstracts
the common demands of users, such as
high-bandwidth slice and low-latency slice.
• Monopolized slice: Anyone (usually an
enterprise) who pays for the slice monopo-
lizes and uses it as a private network.
• Event slice: A slice is launched for some
events with relatively short life cycles, such
as sports events, concerts, and even sales
promotions inside shopping malls.
NSaaS also demonstrates some advantages
to operators. First, confronted with prosperous
over-the-top (OTT) services, operators could
only provide less competitive OTT-like services
and traditional services such as voice, SMS, and
data. NSaaS makes a difference by facilitating
operators to differentiate their data pipes with
various QoS and providing additional promis-
ing services. Second, based on NSaaS, the design
and confi guration experience becomes a simple
software reconstitution procedure and short-
ens the time to market of operators’ products
from months to hours. Assuming that infra-
structure of network elements has already been
virtualized and could be allocated as a simple
reconstitution procedure of virtual machines, a
Operators sell the net-
work slice to the com-
pany who owns both
the network and ter-
minals, such as: video
surveillance network
for security companies,
and smart factory net-
work for manufacturing
companies. In the B2B
case, operators not only
provide customized
wireless connections
to enterprises, but also
release full control
of terminals to the
enterprise.
IEEE Communications Magazine • July 2016
148
component-based network could be described
by configuration files as a service template and
orchestrated by combining software packages
from a library. Third, NSaaS enriches the prod-
ucts of operators so that operators could agilely
offer dedicated network services to small and
medium enterprises rather than build expensive
dedicated networks case by case only for large
enterprises. Moreover, software-based NSaaS
facilitates the convergence of operators’ opera-
tion support systems (OSSs) and business sup-
port systems (BSSs).
ArchItectures oF network slIcIng
There are several implementations of NS, as
illustrated in Fig. 1: CN only, RAN only, and CN
and RAN.
CN Only: Tenant-level CNs are virtualized as
network slices, with component-like functional-
ities to be programmable and auto-confi gurable,
such as mobility management, session manage-
ment, and authentication. The network slices
only exist in CNs; therefore, neither the RAN
nor the user equipments (UEs) need to be spe-
cially configured for the sliced CNs. All the
interfaces and procedures remain unchanged
except the case when the UEs initially attach
to the networks, because the UEs should be
assigned to the correct slice of the CNs. Here
we propose to add a slice selection function
(SSF) intervening at the interface between the
control plane of the CN and RAN to notify the
right slice to activate the bearers with the UEs.
Another function of the SSF is to send flow
tables to SDN switches to manage connections
between the base stations (BSs) and the net-
work slices, due to different coverage require-
ments of the slices.
RAN only: Different from CN only slicing,
RAN slices run on the radio hardware and base-
band resource pool, called a wireless platform,
which exhibit less elasticity than the mature virtu-
alized infrastructure in CNs. With several logical
BSs, the slices of a RAN apply various param-
eters of the air interfaces (e.g., symbol length,
sub-carrier spacing, cycle prefi x length, and the
parameters of hybrid automatic repeat request
[HARQ]) to implement slices with different ser-
vice models. Furthermore, other parameters like
cell selection and handover threshold, as well as
coordinated transmission policies can be defi ned
for each slice in order to provide a featured wire-
less experience to the UEs.
CN and RAN: In this scenario, each slice of
a RAN is connected to a core slice, so operators
could offer an end-to-end logical network to cli-
ents. The slice selection procedure is the same as
that of RAN only, so UEs do not need to select
the slice of a CN once they have access to the
RAN part. The CN and RAN solution brings
the advantages of both the CN only and RAN
only solutions, being able to program the func-
tionalities of the CN, as well as customize the air
interfaces of the RAN.
Figure 1. The architecture of three forms of NS.
CN & RAN
Cloud OS
Cloud OS
Flow table
BS
SSF Logical BS
Logical BS
Logical BS
Logical BS
Logical BS
RAN onlyCN only
Registration
Slice management
Slice management
Slice management
APP
APP
APP
Wireless platform
Wireless platform
Core
SDN switch
SDN switch
SDN switch
Core
Core
Control plane
Core
Core
Core
Data plane
Manage plane
Physical link
Logical link
Core
Logical BS
The slice selection
procedure is the same
as that of RAN only,
so UEs do not need to
select the slice of CN
once they have got
access to the RAN part.
The CN & RAN solution
brings the advantages of
both CN only and RAN
only solutions, being
able to program the
functionalities of CN, as
well as customize the
air interfaces of RAN.
IEEE Communications Magazine • July 2016 149
FroM nFv to nsAAs
The NFV technology contains general-purpose
processor platform, cloud operating system,
hypervisor, distributed computing, and the soft-
ware of network elements, decouples software
and hardware, and shields the hardware details
for virtual network functions (VNFs). Based
on NFV, NS realizes the service separation for
multi-tenancy so as to virtually build an exclusive
network for each tenancy. However, NSaaS is
a more business-oriented concept than a tech-
nological one, with features of mapping service
demands automatically from a customer to func-
tionalities, topology, policies, and parameters
of a network slice, as well as providing compo-
nent-based and auto-configured network func-
tionalities for operators to design and launch
network services more conveniently. Table 1 lists
the abstracted comparison of NFV, network slic-
ing, and NSaaS.
An exAMple oF nsAAs
Here we take an emergency communication slice
as an example to further clarify NSaaS. Usually,
an emergency communication slice offers two
main functions in an emergency: alert broadcast
and distress call. This slice is usually provided
by a government to inhabitants for free with the
B2B2C business model. Both the CN only and
CN and RAN implementations are suitable for
the emergency service, and provide dedicated
communication resources of top priority when
others are congested. The emergency slice could
be available once launched without any hardware
integration. Moreover, we can load new func-
tions such as push-to-talk on demand just like
installing a new software.
servIce Model And orchestrAtIon
In the previous section, we point out that the key
technology of NSaaS is service mapping, which
translates service requirements into service mod-
els of operators and vendors. In this section, in
order to better match network slices to various
vertical applications, we propose to differentiate
necessary service models of mobile network into
three levels: application level, network function
level, and infrastructure level. Figure 2 illustrates
the summarized content of the service models
mapped to the NFV architecture of ETSI, as well
as the descriptor databases.
ApplIcAtIon level
At this level, we describe the traffic characteris-
tics of the applications. In view of a single UE,
the application requirements could be described
by the metrics including arrival rate, average
packet length, flow type (burst, periodic, and per-
sistent streaming), download/upload ratio, and so
on. Moreover, the application level also contains
some additional services, such as location-based
service, firewall, and service chain with third-par-
ty applications. The RAN part of network slices
provides options about the wireless experience
of an application, like the mobility of terminals,
cell selection preference, and power-saving air
interface. The application level service model
should be easy to understand even for applica-
tion developers without any telecommunication
background. Therefore, this could be standard-
ized as the application descriptors. In view of the
entire network slice, another important descrip-
tion of the application requirements is the SLA,
which defines some service-specific requirements
including capacity, coverage area, QoS require-
ments, failure duration, network issues, denial of
service, and scheduled maintenance, and so on.
The service level agreement (SLA) descrip-
tions are usually included in the business con-
tract, while the traffic characteristics with more
technical details represent the operator’s under-
standing of a vertical industry. Therefore, the
traffic characteristics of this level come from
a vertical industrial library built by operators,
while the customized SLA requirements as well
as additional services must be translated from
customers’ orders.
network FunctIon level
The network function level shows how VNFs
are interconnected and configured with non-ven-
dor-specific descriptions. As we know, the topolo-
gy of a network describes the connections among
the sites of a RAN and network elements of a
CN. In terms of the SLA of applications, all these
RAN and CN nodes are associated by VLANs
of control plane, data plane, and management
plane. The other part of the service model at the
network function level is the parameters defined
by standards, like timers within 3GPP and IETF
protocols. For example, the tracking area update
timer is set to different values for immobile smart
metering devices and high mobility vehicles, and
Figure 2. The proposed service models of network slicing.
Application
level
Traffic characteristics
Arrival rate
Packet length ⋅⋅⋅
Additional service
SLA
Capacity
Coverage ...
Topology
C/D/M plane policy
Configuration parameters
Network KPI
VNF list
CPU
Memory
Storage
Spectrum
Antennas
BS sites
Vertical
industrial
library
Customer
ordering
VM
catalog
VNF
catalog
Telco
assets
Or-Vnfm
Or-Vi
Vi-Vnfm
NFV orchestrator
VNF management
ETSI NFV framework
Virtualized
infrastructure
manager
Network
function
level
Infrastructure
level
Network slice
service model Model descriptions
Table 1. The comparison of NFV, network slicing and NSaaS.
Form NFV Network slicing NSaaS
Features Hardware/software
decoupling [2]
Multi-network
separation Service auto-mapping
Managed object Virtual machines Virtual networks Customized services
Value to operators Better resource utilization Tenancy separation Agile product
development
Value to consumers None Monopolized network Customized service
IEEE Communications Magazine • July 2016
150
the radio resource control inactivity timer also
differs between bursty instant messaging service
and persistent video streaming.
InFrAstructure level
The infrastructure level of CN is maintained by
IT engineers of operators who are responsible
for ensuring all the virtual machines working
properly to satisfy the demands of VNFs. Here,
the wireless infrastructure consists of spectrum
resource, antennas, BS sites, radio unit, and
baseband resource pool, which is plotted as a
wireless platform in Fig. 1. This level helps
operators to define the resources of infrastruc-
ture with parameters like spectrums, CPU cores,
memory, and storage. The control plane requires
short latency to access the databases, while the
data plane requires high throughput of forward-
ing modules, and the wireless part needs specifi c
signal processing acceleration. Once a network
slice starts to be instantiated, we need to fi nd the
suitable infrastructure as well as racks in data
centers to bear it.
servIce orchestrAtIon
After describing the service models in three lev-
els in terms of the requirements of the appli-
cations, we still need a service orchestrator to
bridge the descriptions with an operational sys-
tem with billing, monitoring, and vendor selec-
tion modules. According to the requirements
of a customer, the orchestrator instantiates the
network slice through assembling functionalities
of vendors, such as VNF and BS selection, ser-
vice chaining, subscriber management, as well as
monitoring and billing. One of the most import-
ant features of NSaaS is the programmability of
the network slice with the component-based net-
work functions. Therefore, operators and slice
customers could select different functions from
vendors according to their own demands. Table
2 lists the examples of the selected functionalities
for four typical applications, so that we can pro-
gram a network slice conveniently according to
the metrics.
To assemble functionalities, one challenge is
to orchestrate service from different vendors’
equipment. This challenge can be addressed in
terms of three service levels as below.
Infrastructure Level: The differences between
multi-vendor hardware servers are shielded by
cloud operating systems including OpenStack,
VMWare, and so on, and only need to expose the
infrastructure level SLAs to the VNFs. Current-
ly, products and solutions in the infrastructure
level are so mature that they satisfy the compati-
bility requirements well and could be allocated in
real time based on the demand of VNFs.
Network Function Level: Based on current
NFV technology, we could inter-connect sever-
al VNFs at very large granularity without any
interoperability and compatibility problems, such
as mobility management entity (MME), serving
gateway (S-GW), and IP multimedia subsystem
(IMS). However, when we try to decompose
VNFs into components as micro-services and
integrate them on a service bus so that a network
slice could be more customized, there appears to
be arduous and cumbersome work to standardize
functions and interfaces of the components, like
mobility management, session management, and
traffic detection. Some cellular system vendors
have already provided an orchestrator with their
NFV solutions inside the nonstandard domain
(e.g., inside an MME), which not only offers
customization capability of mobile service, but
also maintains compatibility with other vendors
through standard interfaces [13]. Furthermore,
the life cycle management of VNFs and key per-
formance indicator (KPI) data of vendors should
be compatible with interfaces of operators’ man-
agement systems. While ETSI allows operators
Table 2. The functionalities and confi gurations of NSaaS for typical applications.
Functionalities Metering Video surveillance Automobile Emergency
Mobility management Static, no handover Static, no handover High-speed Low-speed
Session management Light, no user plane Standard Multi-session Broadcast
Access protocol 3GPP S1-C 3GPP S1 standard 3GPP S1 standard 3GPP MBMS
QoS policy Bandwidth limitation Bandwidth guarantee Latency guarantee Top priority
Security N/A Standard Standard N/A
Air interface feature Power saving Carrier aggregation Small TTI N/A
Band 800 MHz 6 GHz 900 MHz 450 MHz
Bandwidth 2 MHz 100 MHz 5 MHz 2 MHz
HARQ parameters N + 14, no retransmission N + 10, no retransmission N + 3 + 3 N + 3 + 3
Topology Centralized Distributed gateway Distributed gateway Centralized
Auto-scaling Enabled Disabled Enabled Enabled
Additional service Location-based service Video compression Push-to-talk Distress call
The control plane
requires short latency
to access the databases,
while the data plane
requires high through-
put of forwarding mod-
ules, and the wireless
part needs specifi c
signal processing accel-
eration. Once a network
slice starts to be instan-
tiated, we need to fi nd
the suitable infrastruc-
ture as well as racks in
data centers to bear it.
IEEE Communications Magazine • July 2016 151
to subscribe to element management systems
(EMS) of vendors, AT&T proposes to standard-
ize the Ve-Vnfm-vnf interface to control rich
real-time data [14].
Application Level: According to general
application services running on various VNFs
of several vendors, there should be some VNF/
component selection rules and mapping meth-
ods. In other words, operators should translate
the requirements of an application into a lan-
guage that can be understood by the orches-
tration interfaces of vendors, as studied in
projects like Gohan from NTT [15] and Open-
MANO from Telefonica. In this regard, the
complicated standardization work of network
slicing could be shifted to the development of
a unified description language and thus inter-
preting by vendors.
MAppIng oF FunctIon, slA, And vendor
In Fig. 2, the service and SLA of the application
level is described in the language of slice consum-
ers. However, in order to offer an eligible net-
work slicing service with the right SLA, we have
to map the service and SLA into network func-
tion level and infrastructure level, which could
be executable for operators and vendors. As we
know, a network slice could consist of multiple
vendors with standard interfaces, although their
supported functions and SLAs are different. Fig-
ure 3 illustrates how to map the service and SLA
on the top level into lower levels, and how to find
the matched functions from different vendors.
In this figure, the service and SLA are mapped
vertically, and the vendor is mapped horizontal-
ly. The application level service descriptions are
mapped into both network function level and
infrastructure level, and some of the application
SLAs are mapped as low-level SLAs, while some
of them are mapped as functions. All the compo-
nents developed by vendors have to register their
capabilities and functions with a VNF catalog of
operators so that they can be selected accord-
ing to application requirements. For example,
an additional service named malicious website
protection could be decomposed into VNFs like
traffic detection, malicious database, firewall, and
web redirection. It is worth mentioning that the
inputs of the infrastructure-level SLA description
come from the other two levels, as well as the
components of vendors, because vendors have to
propose the specifications of infrastructure for all
the individual components.
nsAAs MAnAgeMent
In this section, the operation and process of
NSaaS are discussed so that operators could pro-
vision the NSaaS with shorter time to market.
AutoMAted conFIgurAtIon
In previous sections, the service requirements
have been translated to software packag-
es by vendors’ plug-ins so that VNF managers
(VNFMs) are able to instantiate a network slice
according to the order specification. However,
there is still some remaining configuration work
to do if the goal is to start the NSaaS automati-
cally after obtaining orders from customers. The
configurations of a newly instantiated network
slice include:
• Infrastructure information: It contains the
IP address pool of the control plane, data
plane, and management plane of data cen-
ters, and the IP addresses and VLANs of
BS lists.
• Service information: It describes basic enti-
ty identifiers and protocol interfaces, such
as public land mobile network (PLMN)
code, tracking area code, cell ID, domain
name, network element name, access point
name (APN), home subscriber server (HSS)
address, as well as interface configurations
of S1, S11, S6a, and so on.
• Subscription information: It contains the
relationship between subscribers and net-
work slices, while one subscriber may
belong to several slices and different service
chains.
• Slice registration: It connects the newly
instantiated network slice to running cellu-
lar networks so that UEs can be redirected
or assigned to it by SSF.
• Monitoring and billing interfaces: They tell
where the KPI data and billing files should
be sent.
All the configuration items above are also
non-vendor-specific. Vendors are able to gener-
ate their scripts by exploiting the plug-ins of the
network slicing orchestrator. Different from the
Figure 3. The SLA and vendor mapping of the service models of NSaaS.
Legends
1. ⋅⋅⋅
2. ⋅⋅⋅ Non-vendor-specific service description
Capability list of vendors
Component of vendors
Function & SLA mapping
Vendor X
1. ⋅⋅⋅
•••
Application level
service description
Network level
SLA description
1. Traffic characteristics
2. Additional services
3. SLA:
3.1 Capacity
3.2 QoS
3.3 Coverage
3.4 Failure duration
3.5 Scheduled maintenance
3.6 Redundancy
1. Function: A,B,C,D,E,F,G
2. SLA:
2.1 User number
2.2 QoS
2.3 KPIs of the functions
2.4 Scheduled maintenance
Infrastructure level
SLA description
1. Infrastructure type
2. SLA:
2.1 Data recovery
2.2 MTBF
2.3 MTTR
3. Spectrum/CPU/memory/
storage/network
Vendor capability mapping
Vendor B
1. Function: C,D,E
2. SLA:
2.1 User number: < 0.5 million
•••
Vendor A
1. Function: A,B
2. SLA:
2.1 User number: < 1 million
2.2 QoS: <1Gbps
2.3 KPI of the functions
2.3.1 A.kpi_1 < x
2.3.2 A.kpi_2 < y
2.3.3 B.kpi_1 > z
Vendor C
1. Function: A,B
2. SLA:
2.1 capacity: < 0.1 million
Vendor E
1. Type = wireless platform
2. SLA:
2.1 Data recovery < 10 min
2.2 MTBF > 1 week
2.3 MTTR < 20 min
3. Band 1, 2, 3, 4, 5, 8
Vendor D
1. Type = data center
2. SLA:
2.1 Data recovery < 1h
2.2 MTBF > 1 month
2.3 MTTR < 30 min
3. 512 CPUs/ 128G mem/
10 TB/ 1 Gbps VLAN
•••
IEEE Communications Magazine • July 2016
152
confi guration of service models, all the param-
eters here are related to a real mobile network
rather than application requirements. Hence,
the most challenging part of automated con-
figuration is to maintain the runtime environ-
ment information of the real mobile network,
which requires operators to keep updating the
environment information to reflect different
levels of changes within their network happen
(e.g., allocating an IP address or when a BS is
offl ine).
product MAnAgeMent
As a service or product for consumers and
enterprises, the network slicing solution
requires full life cycle management, spanning
from design, release, order, and operation to
disposal. Figure 4 describes the fi rst four steps
of product management of NSaaS. First, oper-
ators design a network slice for a general ver-
tical enterprise according to the description of
the service model, which could be named as
the vertical industrial template. However, this
general service model is not ready for instan-
tiation, because it still lacks input information
such as SLA from buyers. In order to sell the
service online, operators need to price the
slice service in terms of the subscriber number,
QoS, SLA, additional service, and spectrum
resources. Second, product managers from the
marketing department of operators prepare
the introduction and case studies of the slice
service to help consumers to understand its
value. After some internal review process, the
slice service could be released onto the market
shelf of operators. Third, customers order the
slice service and input requirements to the ver-
tical template, such as slice coverage, capacity,
and SLA. Fourth, the network slice service is
deployed and running, while both the operator
and customer are able to monitor the status
of the connections and service. Finally, if the
slice service is not suitable to sell in the mar-
ketplace, operators would dispose it and end
its life cycle.
MAnAgeMent ApIs For custoMers
Besides the product management and main-
tenance of operators, there is another kind of
interface for slice customers, management
APIs of NSaaS, which could be integrated with
third-party systems or platforms. Slice customers
could take advantage of this kind of management
APIs to add or remove service and connections,
as well as monitor the status of slices. For an
MVNO retailing connections to its own clients,
management APIs also provide an advanced
charging policy and service package for each UE.
Therefore, management APIs help operators to
fi nd new channels as a new type of broker to dis-
tribute their service, which is usually diffi cult for
them to touch in traditional architectures. The
broker orders a customized network slice just
as an enterprise customer does, but with more
capabilities like the integration of its own service
platform with the slice (e.g., billing fi le interface
and subscriber database) and user behavior data
acquirement from OSS as well as components
like traffi c detection.
conclusIons
In this article, we introduce the concept of NSaaS
to help operators to offer customized end-to-end
cellular network as a service. Moreover, the ser-
vice orchestration and SLA mapping for quality
assurance are explained to illustrate the architec-
ture of service management across three model
levels. Finally, we illustrate the detailed process
of NSaaS within operators by typical examples,
including the configuration and product man-
agement of NSaaS and management APIs for
customers.
With the growing maturity of NFV/SDN, we
believe that the supporting system will trans-
form itself as a production system by providing a
one-stop solution for future wireless connections
and services. Particularly in the 5G era, with the
merging of the operation domain and business
domain, operators will build more and more cus-
tomized network slices for vertical industries in
an agile way.
Figure 4. The lifecycle of NSaaS.
CRM Slice maintenance
NSaaS
OperationOrderReleaseDesign
Vendors
Management API
B2B2C
B2B
Slice
consumer
Order specification
B2B, B2B2C
B2C
Shared
vertical slice
Exclusive dedicated
slice
Enterprise domain Billing & subscriber
interfaces of brokers
Service model
Marketing policy
Vertical industrial
templates
Marketing managerSlice designer
The supporting system
will transform itself as
a production system
by providing a one-
stop solution for future
wireless connections
and services. Particularly
in the 5G era, with the
merging of operation
domain and business
domain, operators will
agilely build more and
more customized net-
work slices for vertical
industries.
IEEE Communications Magazine • July 2016 153
AcknowledgMent
This article was supported by the National Basic
Research Program of China (973Green, No.
2012CB316000) and the Program for the Zheji-
ang Leading Team of Science and Technology
Innovation under Grant 2013TD20.
reFerences
[1] D. George et al., “The Mobile Economy 2015,” GSMA Intelligence, Mar.
2015.
[2] ETSI, “Network Functions Virtualisation — White Paper #3,” Oct. 2014.
[3] R. El Hattachi and J. Erfanian, “5G White Paper,” NGMN Alliance, Feb.
2015.
[4] Y. Zaki et al., “LTE Mobile Network Virtualization,” Mobile Networks and
Applications, vol. 16, no. 4, Aug. 2011, pp. 424–32.
[5] N. M. M. K. Chowdhury and R. Boutaba, “A Survey of Network Virtualiza-
tion,” Computer Networks, vol. 54, no. 5, Apr. 2010, pp. 862–76.
[6] C. J. Bernardos et al., “5G Exchange (5GEx) — Multi-Domain Orchestration
for Software Defined Infrastructures,” Proc. EuCNC 2015, Paris, France,
July 2015.
[7] 3GPP TR 22.891, “Study on New Services and Markets Technology
Enablers,” v 1.0.0.
[8] 3GPP, “RAN 5G Workshop — The Start of Something,” Phoenix, AZ, Sept.
2015.
[9] Cisco Product Overview, “Cisco Extensible Network Controller Slicing
and Topology Independent Forwarding Data Sheet,” http://www.cisco.
com, 2014.
[10] M. Manic et al., “Next Generation Emergency Communication Systems
via Software Defined Networks,” Proc. GENI Research and Educational
Experiment Wksp., Atlanta, GA, Mar. 2014.
[11] T. Taleb et al., “EASE: EPC as a Service to Ease Mobile Core Network
Deployment over Cloud,” IEEE Network, vol. 29, no. 2, Mar. 2015, pp.
78–88.
[12] W. Ding et al., “OpenSCaaS: An Open Service Chain as a Service Plat-
form toward the Integration of SDN and NFV,” IEEE Network, vol. 29, no.
3, May. 2015, pp. 30–35.
[13] Deutsche Telekom AG, “DT Shows World’s First End-to-End Multivendor
5G System,” http://www.telekom.com/media/company/302118, Feb.
2016
[14] AT&T Inc., “ECOMP (Enhanced Control, Orchestration, Management &
Policy) Architecture White Paper,” Mar. 2016
[15] NTT Innovation Institute, Inc., “Gohan - REST-Based API Server to Evolve
Your Cloud Service Very Rapidly,” http://gohan.cloudwan.io, 2015
bIogrAphIes
Xuan Zhou (zhou.xuan@huawei.com) is a senior architect in the Service
Provider Operation Lab (SPO Lab) of Huawei Technologies. He received his
Ph.D. in communication and information systems from Zhejiang University,
Hangzhou, China. From 2009 to 2014, he worked as an system engineer at
China Mobile Zhejiang Company. His research efforts focus on innovative ser-
vice and network management in 5G and NFV/SDN. He is also the architect
of the world’s first 5G end-to-end network slicing demo, which was shown at
Mobile World Congress (MWC) 2016 in Barcelona.
Rongpeng Li (lirongpeng@huawei.com) is a researcher in Huawei Technolo-
gies Co. Ltd., Shanghai, China. He received his Ph.D and B.E. from Zhejiang
University, Hangzhou, China and Xidian University, Xi’an, China ,in June
2015 and June 2010, respectively, both as “Excellent Graduate.” He was a
visiting doctoral student in Supélec, Rennes, France, from September 2013
to December 2013, and an intern researcher at the China Mobile Research
Institute, Beijing, from May 2014 to August 2014. His research interests cur-
rently focus on resource allocation of cellular networks (especially full duplex
networks), applications of reinforcement learning, and analyses of cellular
network data, and he has authored/coauthored several papers in related
fields. He served as Web Design Chair of IEEE OnlineGreenComm 2015, and
Web and System Chair of IEEE ISCIT 2011.
Tao Chen (tao.chen@vtt.fi) received his Ph.D. degree from the University of
Trento, Italy, in 2007, and his B.E. degree from Beijing University of Posts and
Telecommunications, China, in 1996, both in telecommunications engineer-
ing. He is currently a senior researcher at VTT Technical Research Centre of
Finland. He is the project coordinator of the EU H2020 5G PPP COHERENT
project, and a board member of the EU 5G PPP Steering Board. His cur-
rent research interests include software defined networking and architecture
design for 5G networks, dynamic spectrum access, energy efficiency and
resource management in heterogeneous wireless networks, and social-aware
mobile networks.
honggang Zhang (honggangzhang@zju.edu.cn) is a full professor at Zheji-
ang University, China, and was the International Chair Professor of Excellence
for Université Européenne de Bretagne (UEB) & Supélec, France (2012–
2014). He is also an Honorary Visiting Professor at the University of York,
United Kingdom. He served as the Chair of the Technical Committee on
Cognitive Networks of the IEEE Communications Society from 2011 to 2012.
He is currently involved in research on green communications, taking the role
of Series Editor for the IEEE Communications Magazine Series on Green
Communications and Computing Networks.