See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/351083801

Defining a management function based architecture for 5G network slicing

Preprint · April 2021

DOI: 10.13140/RG.2.2.25997.87522

CITATIONS READS

0 515

3 authors:

Kostis Trantzas Christos S. Tranoris

University of Patras University of Patras
3 PUBLICATIONS   0 CITATIONS    65 PUBLICATIONS   412 CITATIONS   

SEE PROFILE SEE PROFILE

Spyros Denazis
University of Patras
140 PUBLICATIONS   2,035 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

ENDECON View project

A Distributed Complete Fault-Tolerant Edge System View project

All content following this page was uploaded by Kostis Trantzas on 24 April 2021.

The user has requested enhancement of the downloaded file.

 Defining a management function based architecture
for 5G network slicing
Kostis Trantzas Christos Tranoris
Electrical and Computing Engineering Electrical and Computing Engineering
Department Department
University of Patras University of Patras
Patras, Greece Patras, Greece
ktrantzas@upnet.gr tranoris@ece.upatras.gr
Abstract—The fifth generation (5G) of mobile networks
emerged to cover the demand for an increasingly wide range of
industrial use cases and contemporary daily aspects, in general.
Network slicing is projected as a key enabler for serving this
multitude of tenants. Network slicing, as an ongoing
standardization work, encapsulates the different vision and
terminology across Standards Development Organizations
(SDOs). That note is depicted in existing approaches that
introduce customizations severely undermining
interoperability. This work leverages Openslice, a Service
based, opensource Operation Support System (OSS), and aims
to augment its functionality by proposing a fully standardized
network slicing mechanism, combining contributions from
major SDOs.
Keywords—5G; network slicing; network slice management;
standardized data models;
I. INTRODUCTION
The exponential growth of multimedia services (e.g. high
quality streaming, mobile TV) and the increasing demand
from verticals for reliable, real time services have exposed the
weaknesses of existing networks and accelerated the need for
developing and deploying next generation networks. The
forthcoming fifth generation (5G) networks aim to facilitate
that said need of Communication Service Customers (CSCs)
by providing services with different requirements in terms of
bandwidth, reliability, latency, and overall performance [1].
The keystone of 5G networks is network slicing. Network
slicing belongs to the category of virtualization networking
paradigm, together with Software Defined Networking (SDN)
and Network Function Virtualization (NFV). Network slicing
can make use of SFN and NFV, but it can be seen as an
independent technology [2]. Its importance lies in providing a
cost-efficient solution for accommodating on-demand
services through resource sharing, thus increasing revenue [3].
Other than avoiding over-provisioning, network slices can
allocate the dedicated virtual network resources needed to
guarantee the required service quality, through network
isolation [4]. Several Standards Development Organizations
(SDOs) have acknowledged the major part of network slicing
in structuring cost-efficient, multi-tenant next generation
networks and shared their visions and approaches on that end.
This inspired many proposals in the effort to define a universal
network slicing mechanism, but the extensive introduction of
customizations in said attempts failed to establish a unified
solution.
In this paper, we first overview the work introduced by the
main SDOs and other notable related research (Section II).
Second, we present our current implementation in respect with
that of several standards bodies (Section III). Following this,
a novel, fully standards-compliant network slicing
architecture is proposed (Section IV) alongside with our
example on transformations between standardized models
Spyros Denazis
Electrical and Computing Engineering
Department
University of Patras
Patras, Greece
sdena@upatras.gr
(Section V). Lastly, we end with conclusion and future work
discussion (Section VI).
II. RELATED WORK
A. Standards Development Organizations
Despite the existence of several SDOs in the
telecommunications ecosystem, two of them appear to
interwork and share a common vision towards network
slicing: the Third Generation Partnership Project (3GPP),
addressing technology-specific standards on network slicing,
covering both the Radio and Core Networks; and the
European Telecommunications Standards Institute (ETSI),
illustrating a technology-agnostic architecture related to the
delivery of network slices in virtualized environments.
Although the internal structural components are meticulously
described by the above-mentioned organizations, a need for a
reference point between operators, providers and customers
emerges in order to identify and ultimately deploy a network
slice to accommodate a given use case. GSM Alliance
(GSMA) introduced Generic Slice Template (GST) [5] that
permits the customer to express its service requirements in a
comprehensible manner for operators and providers. To end
up, Tele Management Forum (TM Forum) is an industry
association which is actively working on providing tools in the
form of Application Programming Interfaces (APIs) to help its
members to further transform their current Operations /
Business Support Systems (OSS/BSS) among other
initiatives.
1) 3GPP
Working group TSG SA WG5 (SA5), which mainly
focuses on Management, Orchestration and Charging,
specifies requirements and procedures for provisioning of
network slices to facilitate the emerging needs of 5G network
services. Current approach is structured upon a service-based
architecture [6], which executes the provisioning and lifecycle
management of network slices through well-defined building
blocks [7], introduced as:
 Communications Service Management Function
(CSMF): Responsible for translating the CS related
requirements to network slice related requirements
and management of the communication service
instance (CSI).
 Network Slice Management Function (NSMF):
Assigned with the management and orchestration of
the network slice instance (NSI) and derives network
slice subnet related requirements from network slice
related requirements.
 Network Slice Subnet Management Function
(NSSMF): Charged with the management and
orchestration of the network slice subnet instance
(NSSI).
 Besides stating the purpose of these building blocks, their
interfaces and functionality, 3GPP does not provide any
further indication on how to implement them.
2) ETSI
Although ETSI has identified a need for a standardized
network slice architecture, it does not provide an internal
definition, but rather acknowledges propositions from other
SDOs, e.g. 3GPP. The connection is attempted between the
management functions from 3GPP and ETSI’s NFV –
Management and Orchestration (MANO) framework layer.
Specifically, the exposed Northbound Interface (NBI) of a
NFVO (NFV Orchestrator) is consumed by 3GPP’s NSMF
and NSSMF via Os-Ma-Nfvo interface [8]. CSMF leverages
information from analytics and supervision frameworks, like
fault, configuration, accounting, performance, security
(FCAPS) [9] and Management Data Analytics Function
(MDAF) [6] , or just direct input and prompts its underlying
blocks – NSMF and NSSMF – to perform the needed actions
to accommodate the requirements of a communication service
(CS). The latter interact with the NFVO and trigger lifecycle
actions on the requested network service based on the
information retrieved from their descriptors, namely Network
Service Descriptors (NSDs) [10].
3) GSMA
GST, introduced by GSMA, attempts to narrow down the
gap between network service/slice customers and vendors,
providers. To begin with, it enables the customer to express its
desired service requirements through an unanimously
accepted model among operators and service providers.
Secondly, standardized network slice templates (S-NEST) are
shared between all operators and associated organizations.
Lastly, the worldwide adoption of NESTs permits the
interconnection with broader public networks to restricted
private networks.
4) TM Forum
As a global industry confederation, TM Forum aims on
evolving current OSS/BSS, seeking solutions that facilitate i)
their consumption by verticals and ii) their integration into
existing standards-driven architectural frameworks. In these
terms, one of TM forum’s contributions is the introduction of
the Open Digital Architecture [11], which provides scenarios
for Business and Infrastructure Functions and their respective
implementation through technology neutral ‘flavors’. These
implementations are offered in the form of Open APIs,
allowing vertical customers to interact and consume offered
XaaS, where X refers to the resource under consideration (e.g.
network slice, network service, etc.). Considering the vendor-
agnostic nature of these Open APIs, accompanied with their
bottom-up composition across layers and broad adoption from
telco industry makes TM Forum’s Open APIs a perfect
candidate for integrating components among multi-vendor
environments.
B. Existing approaches
A first notable related research, on integrating network
slicing into network service delivery concept, appears under
the EU 5G Infrastructure Public Private Partnership (5G-PPP)
program umbrella [12].
The 5GENESIS project introduces a slice manager entity
based on a modular architecture which stands as a standalone
component residing in parallel to MANO layer [13]. Their
implementation does not differ from the one given by 3GPP
in terms of topology, nevertheless the interconnectivity
between components is not exclusively achieved via
standardized APIs. Also, the template that is used to define the
specific slice configuration is based on GST [14].
5GTANGO [15] promotes the flexible programmability of
5G networks with: i) an NFV-enabled Service Development
Kit (SDK), ii) a Validation and Verification (VnV) platform
for VNFs/Network Services qualification, and iii) a modular
Service Platform (SP), SONATA. SONATA SP aims to
bridge the gap between business needs and network
operational management systems. For that purpose, several
software modules are introduced with a Network Slice
Manager (NSM) [16], among others. There are two main
features in the NSM: i) Network Services Composition,
linking multiple services together to compose a completer and
more isolated network service to the final user; and ii)
Network Service Sharing: being source efficient through
sharing a network service deployment among multiple
network slices.
The 5G-Transformer (5GT) project specifies an entity
called 5GT Vertical Slicer (5GT-VS), which resides within
OSS/BSS [17]. It acts as an entry point for the vertical users
to interact with the whole system. Inside the 5GT-VS, there is
a component, namely the “Vertical Service Descriptor to
Network Service Descriptor (VSD/NSD) Translator, tasked
with performing the mapping between customer’s
requirements and NSDs, which is then interpreted from the
NFVO. Slicing ecosystem actions are performed by “Vertical
Service Instance to Network Slice Instance (VSI/NSI)
Coordinator and Life Cycle (LC) Manager”, which engages
the NSSMF and NSSMF from 3GPP.
Besides 5G-PPP projects, an interesting approach to define
the internal functions of 3GPP’s CSMF can be found in [18].
This work clearly promotes CSMF’s importance and aims to
enhance current implementations from existing projects and
help to pave the way towards further specification of its
internal components, as well as their implementation.
III. CURRENT APPROACH
Related work from the previous section clarifies the need
to define a unified service delivery architecture with network
slicing support, fully compliant with earlier mentioned
standards, incorporating their guidelines towards an
interoperable, service based solution. Even though, the
aforementioned approaches claim to employ some
functionality from 3GPP and other SDOs, it is ultimately
noticed that the introduction of several customizations
undermines their interoperability and reproducibility.
In this work, we present a service-based architecture and
design which utilizes 3GPP and ETSI standards, TMFORUM
OpenAPIs and delivers Network Slices as Services (NSaaS)
[19]. Our proposed architecture will be used next to
implement an open solution that is integrated with our open
source Operations Support System (OSS) called Openslice
[20]. Openslice currently offers the TM Forum’s TMF909
proposed API Component Suite in support of a set of
Operational Domains exposing and managing “Network”
Services [21]. Openslice’s key contribution, being an open
source project, is that allows small and medium-sized
enterprises (SMEs) or organizations to implement private
network scenarios that interact with public large scale
networks in a standardized manner.
 Figure 1 portraits how Openslice implements today the
NSaaS Instantiation and delivery of an E2E service, using
TMF909’s vision as a cornerstone and how our new approach
extends it for the emerging NSaaS cases that the 5G domain
needs. The three main phases that emerge are slice ordering,
fulfillment, and operation.
A. Slice ordering
The operational scenario commences when a customer
(5G vertical) places an order that relates to specific network
services. This order is modeled on Service Ordering API
(TMF641) [22]. The available services for ordering are
designed ahead as Service Specifications, composing a
Service Catalog (TMF633) [23], which is then exposed to
customers. Service Specifications are categorized as
Customer Facing Services (CFS) and Resource Facing
Service (RFS). CFSs are the actual services exposed to
customers, while RFSs are related to underlying resources
(NSDs). These service specifications are expressed as
NESTs, derived from GSMA’s GST model.
B. Slice fulfillment
A service order placement triggers slice fulfillment phase.
The customer provides a full description of the service related
requirements as a list of service specifications. Subsequently,
these specifications will be interpreted into slice requirements,
including information on slice topology and slice attributes.
Then, the issued order is captured by the Service Order
Management (SOM) service, which propagates it towards the
corresponding Service Orchestrator(s).
At this stage the order is processed, and the received
specifications (CFS) are interpreted into resource
requirements outlining the network slice to be instantiated
(RFS). As mentioned above, RFSs include NFVO
Figure 1. Network Slice Instantiation in Openslice with newly
introduced proposed architecture
recognizable NSDs. The Service Orchestrator provides NFVO
with the NSD and its corresponding resource requirements,
via a ETSI SOL005 interface, triggering an instantiation
action. Procedure is then carried in MANO layer, where the
NFVO allocates the slice instance, instructing its underlying
components for that end.
C. Slice operation
Following the fulfillment phase, slice is finally in
operational state. During this phase, the customer is handed
over exposed supervision capabilities of the slice instance.
Such capabilities involve current slice status tracking, control
over it via CRUD operations, and run-time information in
general. All said actions are addressed by Service Inventory
API (TMF638) [24].
Given the above phases that today Openslice currently
implements, a specific weakness is detected during slicing
fulfillment: Openslice does not make use of the 3GPP defined
data models, e.g. Service Profiles, Slice Profiles etc., thus
compromising its interoperability with the 3GPP ecosystem
efforts. As Figure 1 depicts and further mentioned in the next
section, our newly proposed architecture and implementation
is injected just before the Service Orchestrator towards
NFVOs. The service order will still be captured via TMF’s
Service Order model, but 3GPP models will be used onwards
to deliver the network slice. Thus, our work and extensions
aim to fully align Openslice with 3GPP’s Network Slice
journey (NSaaS model) [25], through steps 4-6, as Figure 2
outlines.
Figure 3 displays an example of a Service
Specification (CFS) as displayed and delivered today by
Openslice service catalog. An example of an Openslice
deployment can be seen in [26].
Figure 2. 3GPP Network Slice journey (NSaas model) - high-level call
flow on par with Openslice
Figure 3. Openslice CFS example
 IV. PROPOSED ARCHITECTURE
This section provides our architectural approach that
integrates 3GPP functional blocks in a comprehensive
network slicing architecture. It is divided in two parts: the first
subsection provides the architecture overview by defining the
internal components for each functional block (CSMF,
NSMF, NSSMF) as depicted in Figure 4; the second
subsection illustrates the process of a service order fulfillment
through network slicing provisioning.
A. Architecture overview
In this subsection we provide our architecture for the
defined 3GPP components namely, CSMF, NSMF and
NSSMF. We provide an architecture compliant with the 3GPP
defined interfaces and functionalities. To add up, we focus
specifically on Provisioning MnS from the pool of generic
management services introduced in [27] for the sake of
simplicity.
1) The CSMF
The CSMF would be the first entity to interact with CSC
upon receiving the service order. Its primary role is to translate
the communication service-related requirements to network
slice related requirements [7]. Having established that, CSMF
needs to communicate with the underlying entity (NSMF) to
prepare and allocate the required network resources, which
would host the requested network service. We define the
following internal components that implement a fully
compliant CSMF:
NBI: acts as an admission interface and receives requests
from the BSS/OSS. Such requests are CS requirements
through service orders’ service specifications with their
respective lifecycle management (LCM) instructions
(instantiate, modify, deactivate, terminate) to be applied. In
addition, with respect to telco standards adoption, it should be
able to expose the catalogue with the available services and to
notify the customer regarding the status of the CS.
CSI LCM: responsible for representing the actions
applied throughout the whole CSI lifecycle phases, as
proposed by 3GPP [28]. We defined the following actions: i)
commissioning: integrity check of the provided service
requirements, conversion of service requirements to network
requirements as derived from SLA, discovery of the network
resources - which shall accommodate the CS; ii) activation:
expected to bring CSI in operational state; iii) modification:
Figure 4. Proposed management blocks' architecture
alters the parameters on an operational CS, either by request
from other supervision elements or directly from the
customer; iv) decommission: deactivation or permanent
termination of the CS, following the release of non-shared
resources.
Service Order (SO) Validation: confirms the validity of
the requested parameters of the service, including name, type,
allowed value and range.
SLA Translation: converts the CS requirements,
expressed in GSMA’s GST [5], into network slice
requirements, in the form of 3GPP’s Service Profile [29], as
described in [28] and expected from lower-level management
blocks.
Service Order Management (SOM): provides a pool of
all available implementation sites and picks the fitting one to
request the existing network slice from (interdomain or
intradomain), considering the requirements extracted from the
SLA.
Capability Exposure: handles the notification and the
exposure of management capability to CSC.
CSI Supervision: collects information about the
communication service instances. This closed loop
management involves interaction with other functions e.g.
NSMF, MDAF.
Performance Assurance: collects performance metrics
from various functions e.g. NSMF, MDAF assuring that the
SLA is persistently fulfilled by triggering LCM actions based
on their specified inputs.
Network Service Catalogue: exposes the available
services to a customer, outlining the service type and
capability at the same time.
Network Service Inventory: stores the currently running
CSIs alongside with their allocated resources. The mapping
relationship between the CS and their respective resources
enables real time service monitoring according to input from
NSMF and rules defined by the capability exposure service.
In addition, this component is always updated with the latest
lifecycle status of the service.
2) The NSMF
The NSMF should be the underlying entity which CSMF
delegates the network slice creation task to. At this stage,
network slice related requirements are transformed into
network slice subnet related requirements [7]. We define the
following services that comprise a NSMF:
NSI LCM: represents the actions applied throughout the
NSI lifecycle phases. In-depth analysis will be omitted as
relation concept of CSI-NSI lifecycle is fully depicted in [29]
and CSI LCM is already described in the previous section.
Model Transformation: converts the ServiceProfile
received from CSMF to top-level SliceProfile. The
transformation rules are governed by 3GPP’s ServiceProfile
and SliceProfile property matching in [29].
Network Resource Discovery: contains a pool of
available top-level network slice subnets currently
implemented in all collaborating sites and picks the fitting one
to request the top-level network slice subnet from
(interdomain or intradomain). The subnet requirements are
 Figure 5. Slice provisioning activity diagram
extracted from the top-level SliceProfile, formerly created by
model transformation.
NSI Supervision: collects information about the network
slices instances. This closed loop management involves
interaction with other functions e.g. NSSMF, MDAF.
Network Slice Inventory: stores the currently running
NSIs alongside with their top-level subnets which they are
related to. The mapping between network slice and top-level
slice subnet enables real time slice monitoring according to
input from NSSMF. Furthermore, the inventory is always
updated with the latest lifecycle status of the network slice.
3) The NSSMF
The NSSMF is the underlying entity residing at the base
of this architecture, which ultimately provides the
interconnection with a NFVO. Network slice subnet creation
task is delegated to NSSMF from the NSMF. In addition, the
implementation of a service orchestrator within this entity
guarantees the consistent slice deployment along different
network domains (Core Network, Radio Access Network,
Transport Network). We define the following services that
comprise a NSSMF:
NSSI LCM: represents the actions applied to the
constituent subnets of a network slice. Being on the same page
with its respecting components of the higher-level functional
blocks extensive description is omitted.
Network Resource Discovery: decomposes a top-level
SliceProfile received from the NSMF to its constituent
SliceProfiles per network domain. In addition, it contains a
pool of available network slice subnets currently implemented
and picks the fitting one for every domain based SliceProfile
previously extracted (interdomain or intradomain).
NSSMF Orchestrator: evaluates the network resources
to request domain specific (CN, RAN, TN) network slice
subnets from. These cases are emerged: i) intradomain
orchestration, where the orchestrator requests a service
instantiation on local NFVO’s NBI (through an integrated
SOL005 translator plugin); ii) interdomain orchestration,
where the orchestrator requests a domain specific network
slice subnet from another collaborating NSSMF, which then
involves its local NFVO to instantiate the actual network
service. Upon receiving successful instantiation responses, a
local TN manager is recruited to establish the network
interfaces between the running network services.
NSSI Supervision: collects information about the
network slices subnet instances. This closed loop management
involves interaction with other 3GPP functions e.g. FCAPS,
MDAF.
Network Slice Subnet Inventory: stores the currently
running NSSIs alongside with their constituent subnets which
they are related to. The mapping between top-level network
slice subnet and its constituent slice subnets enables real time
slice subnet monitoring according to input from other
NSSMFs, MDAF and FCAPS. Furthermore, the inventory is
always updated with the latest lifecycle status of the network
slice subnet.
NSD Catalogue: exposes the NSD catalogue of the local
NFVO to the NSSMF. This should enable the mapping of the
requested network slice subnets to feasible network services
delivered by the facility.
SBI: acts as a bridge between the proposed 3GPP
Management System layer and MANO layer. Direct
interconnection with the NFVO through SOL005 interface
enables actions as NSD catalogue exposure to NSSMF and NS introductory comparison table between GSMA GST attributes
LCM as defined in [30]. and ServiceProfile, but it does not elaborate further, nor does
it refer to any SliceProfile attributes.
B. Network slice provisioning example
In this subsection we visualize the delivery of NSaaS of Therefore, we have created a map between those attributes
the proposed architecture through a UML activity diagram to indicatively presented at Table 1, given by demonstrative
illustrate the use of GST, TMF and 3GPP’s models. The most means. Furthermore, we present a NEST (Table 2) for ultra-
iconic example relates to the provisioning of a network slice, reliable low latency communication (URLLC) as found in [5],
as requested from a BSS/OSS. Of course, there are more use translated into ServiceProfile model (Table 3) and then,
cases such as lifecycle management of a network slice, transformed into SliceProfile model (Table 4).
network isolation, resource monitoring, among others. We
focus primarily on slice provisioning here as it involves all the Table 1. GST - ServiceProfile - SliceProfile attribute mapping
defined architectural components. ServiceProfile
GST attribute SliceProfile attribute
attribute
Figure 5 represents the components involved and their
respective interactions, as well the internal activities needed to coverageArea NrTac
Area of service
mcc in PlmnId mcc in PlmnId
provision a network slice. To begin with, a service order
request is initiated by an BSS/OSS, in the form of TMF641’s Area of service: coverageArea NrTac
Region specification mnc in PlmnId mnc in PlmnId
Service Order model. The CSMF captures this order and
proceeds to validate it through correlation with an already Downlink throughput
servAttrCom and areaTrafficCapDl in
per network slice:
available service offered by the interworking facilities. Each Guaranteed downlink
guaThpt in Perf for Embb of
collaborating facility exposes its offered services through the dLThptPerSlice SliceProfile
throughput quota
implementation of TMF633’s Service Catalogue. As soon as
Maximum number of
the order is validated, the network related requirements need UEs
maxMumberofUEs maxMumberofUEs
to be extracted from the received order. The service related
Simultaneous use of
requirements, expressed as GSMA’s NEST [5] within a the network slice
resourceSharingLevel resourceSharingLevel
service order item, are translated to 3GPP’s Service Profile.
With this information, the CSMF discovers the corresponding Slice quality of service sST
uEMobilityLevel
parameters: 3GPP 5QI uEMobilityLevel
NSMF to request a NSI that fulfills these requirements. It can
either be an already instantiated NSI, in case of a sharable Uplink throughput per
servAttrCom and areaTrafficCapUl in
service, or a newly requested one. An important note here is network slice:
guaThpt in Perf for Embb of
that the receiving NSMF can be out of the requesting domain. Guaranteed uplink
uLThptPerSlice SliceProfile
throughput quota
After the CSMF prompts the NSMF to supply the needed
network slice, CSMF’s service inventory is updated and this
lifecycle progress is exposed to the CSC. The following step Table 2. GSMA URRLC NEST
of the NSMF would be the transformation of the provided GST attribute Value
Service Profile to a top-level Slice Profile. On par with
Availability 99.999 %
CSMF’s discovery procedure, NSMF needs to discover the
underlying NSSMF to request the necessary NSSI to Downlink throughput per UE: Maximum
100000 kbps
downlink throughput per UE
accommodate the particular SliceProfile. Again, the requested
NSSI’s domain is not locally restricted. It is always expected Uplink throughput per UE: Maximum uplink
100000 kbps
that the CSC is notified, throughout the requested instances’ throughput per UE
lifecycle. At this point, NSSMF decomposes the top-level Slice quality of service parameters 82
SliceProfile to its constituent domain specific SliceProfiles. It Supported device velocity 2
is envisioned that each constituent SliceProfile would be UE density 1000 per km2
fulfilled by a related lower level NSSI. After the foreseeable
discovery of the domain resources that are going to implement
Table 3. 3GPP ServiceProfile
these NSSIs, the NSSMF continues with the execution. Its
purpose is to orchestrate the NSSI requests from multiple ServiceProfile attribute Value
domains, await their successful slice subnet instantiation (or latency 10
allocation for existing ones) responses and setup the network
sST 2
links between them. The provisioning procedure is concluded
as slice subnet inventory is updated, and the customer is uEMobilityLevel FULLY MOBILITY
notified of all the actions applied. availability 99.999

V. GSMA NETWORK SLICE TEMPLATE TRANSFORMED INTO delayTolerance NOT SUPPORTED

3GPP SERVICEPROFILE – SLICEPROFILE dLThptPerUe {quaThpt: 100000}

This section presents the process of transforming a uLThptPerUe {quaThpt: 100000}

received NEST into a 3GPP’s Service Profile and Slice termDensity 1000
Profile, suqsequently. As mentioned, a customer orders uESpeed 120
Service Specifications (CFSs) expressed as NESTs. Upon
receipt from the CSMF, a given NEST needs to be interpreted Table 4. 3GPP SliceProfile
to ServiceProfile, which is then routed to the underlying
components (NSMF and NSSMF) to be further transformed SliceProfile attribute Value
into top-level SliceProfile and its constituent domain specific perfReq
[ { csAvailabilityTarget: 99.999,
SliceProfiles, respectively. 3GPP’s document [28] includes an expDataRate: 100000 } ]
View publication stats
SliceProfile attribute Value
latency 10
uEMobilityLevel FULLY MOBILITY
VI. CONCLUSIONS
Current implementation of Openslice leverages the
customer facing aspects of the CSMF, exposing entities like
Service Catalogue, Service Inventory to the CSC and
accepting CS requests in the form of service orders. Service
orders contain service specifications, divided in customer and
resource facing. As expected, service related specifications are
defined by CSC in customer facing specification. On the other
hand, resource facing specification bears the link between the
ordered service and the actual network service to be requested
from the NFVO, that would facilitate said order. To add up,
Openslice currently incorporates an ETSI SOL005 compliant
component, which translates customer facing specifications
into resource facing specifications and ultimately, into their
corresponding network service lifecycle actions. Then, these
actions are handed over to the NFVO via Os-Ma-Nfvo
interface. It is safely assumed that this component should
reside at the southern part of a NSSMF.
With this work we propose an architecture to bridge that
gap (customer facing CSMF – southern NSSMF) introducing
discrete building blocks in between them. We foresee that the
above architecture will disentangle the order fulfillment
process from a strictly defined vertically driven approach,
initiated from a Service Order Management service and
terminated at a given NFVO without any intermediate
managing capabilities. Additionally, a horizontal driven
approach is introduced allowing higher level slice
management (NSI-level, NSSI-level) prior to NFVO’s slice
allocation in MANO layer. Furthermore, that enables cross-
domain slice instantiation between interconnected facilities
and consequently, along multiple NFVOs.
Future work is expected to include the incorporation of the
proposed building blocks in Openslice, confirmation of their
functionality and eventually extension to support more 3GPP
supervision frameworks, like MDAF and FCAPS. To that
extent, a complete network slice lifecycle would be supported
integrating runtime (day-2) configuration and close-loop
automation aspects.
ACKNOWLEDGMENT
This work is supported by the H2020 European Projects 5G-
VINNI (grant agreement No. 815279), 5G-VICTORI (grant
agreement No. 857201), 5G-SOLUTIONS (grant agreement
No. 856691).
REFERENCES
[1] X. Foukas, G. Patounas, A. Elmokashfi and M. K. Marina, "Network
Slicing in 5G: Survey and Challenges," IEEE Communications
Magazine, vol. 55, no. 8, pp. 94-100, May 2017.
[2] R. F. Olimid and G. Nencioni, "5G Network Slicing: A Security
Overview," IEEE Access, vol. 8, pp. 99999-100009, May 2020.
[3] K. Katsalis, N. Nikaein, E. Schiller, A. Ksentini and T. Braun,
"Network Slices toward 5G Communications: Slicing the LTE
Network," IEEE Communications Magazine, vol. 55, no. 8, pp. 146-
154, August 2017.
[4] X. Li, M. Samaka, H. A. Chan, D. Bhamare, L. Gupta, C. Guo and R.
Jain, "Network Slicing for 5G: Challenges and Opportunities," IEEE
Internet Computing, vol. 21, no. 5, pp. 20-27, September 2017.
[5] GSMA, "Generic Network Slice Template v3.0," 2020. [Online].
Available: https://www.gsma.com/newsroom/wp-
content/uploads/NG.116-v3.0.pdf. [Accessed February 2021].
[6] 3GPP, "TS 28.533; Management and orchestration; Architecture
framework (Release 16)," 2020.
[7] 3GPP, "TR 28.801; Telecommunication management; Study on
management and orchestration of network slicing for next generation
network (Release 15)," 2018.
[8] ETSI, "GR NFV-EVE 012; Evolution and Ecosystem; Report on
Network Slicing Support with ETSI NFV Architecture Framework,"
2017.
[9] ITU-T, "T M.3400, TMN management functions," 2000.
[10] ETSI, "GS NFV-IFA 014; Management and Orchestration; Network
Service Templates Specification," 2016.
[11] TM Forum, "TMF IG1167 - ODA Functional Architecture," 2020.
[12] 5G-PPP, [Online]. Available: https://5g-ppp.eu/. [Accessed February
2021].
[13] 5GENESIS, "D3.3 Slice Management," 2019. [Online]. Available:
https://5genesis.eu/wp-
content/uploads/2019/10/5GENESIS_D3.3_v1.0.pdf. [Accessed
February 2021].
[14] A. D. Zayas, G. Caso, Ö. Alay, P. Merino, A. Brunstrom, D. Tsolkas
and H. Koumaras, "A Modular Experimentation Methodology for 5G
Deployments: The 5GENESIS Approach," Sensors, vol. 20, no. 22,
p. 6652, November 2020.
[15] 5GTANGO, "Description," [Online]. Available:
https://www.5gtango.eu/about-5g-tango/description.html. [Accessed
February 2021].
[16] 5GTANGO, "5GTango Network Slice Manager (tng-slice-mngr),"
[Online]. Available: https://github.com/sonata-nfv/tng-slice-mng.
[Accessed February 2021].
[17] 5G-Transformer, "D3.3 Final design and implementation report on
the Vertical Slicer (report)," 2019. [Online]. Available: http://5g-
transformer.eu/wp-
content/uploads/2019/05/D3.3_Final_design_and_implementation_r
eport_on_the_Vertical_Slicer_report.pdf. [Accessed February 2021].
[18] L. Suárez, D. Espes, P. L. Parc and F. Cuppens, "Defining a
communication service management function for 5G network slices,"
2019 European Conference on Networks and Communications
(EuCNC), pp. 144-148, 2019.
[19] C. Tranoris, "Openslice: An opensource OSS for Delivering Network
Slice as a Service," 2021. [Online]. Available:
https://arxiv.org/abs/2102.03290.
[20] OpenSlice, [Online]. Available: http://openslice.io.
[21] TM Forum, "TMF 909A - Network as a Service (NaaS) API
Component Suite Profile," 2019.
[22] TM Forum, "TMF641 - Service Ordering Management API REST
Specification," 2019.
[23] TM Forum, "TMF633 - Service Catalog Management API REST
Specification".
[24] TM Forum, "TMF638 - Service Inventory API REST Specification,"
2019.
[25] 3GPP, "TS 28.531; Management and orchestration; Provisioning;
(Release 16)," 2020.
[26] C. Tranoris and S. Denazis, "Patras 5G: An open Source based End-
to-End facility for 5G trials," ERCIM NEWS, Special Theme 5G, no.
117, p.10., April 2019.
[27] 3GPP, "TS 28.532; Management and orchestration; Generic
management services (Release 16)," 2020.
[28] 3GPP, "TR 28.805; Telecommunication management; Study on
management aspects of communication services (Release 16)," 2019.
[29] 3GPP, "TS 28.541; Management and orchestration; 5G Network
Resource Model (NRM); Stage 2 and stage 3 (Release 16)," 2020.
[30] ETSI, "GS NFV-SOL 005; Protocols and Data Models; RESTful
protocols specification for the Os-Ma-nfvo Reference Point," 2020.