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

net/publication/353490533

Dynamic Slice Scaling Mechanisms for 5G Multi-domain Environments

Conference Paper · June 2021

DOI: 10.1109/NetSoft51509.2021.9492716

CITATIONS READS

2 209

8 authors, including:

David Breitgand Alexios Lekidis

IBM Research -- Haifa Intracom Telecom S.A.
68 PUBLICATIONS   1,909 CITATIONS    38 PUBLICATIONS   262 CITATIONS   

SEE PROFILE SEE PROFILE

Rasoul Behravesh Vasileios Theodorou

Fondazione Bruno Kessler Intracom Telecom S.A.
16 PUBLICATIONS   72 CITATIONS    33 PUBLICATIONS   245 CITATIONS   

SEE PROFILE SEE PROFILE

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

Riabiligame View project

Small cEllS coordinAtion for Multi-tenancy and Edge services (SESAME) View project

All content following this page was uploaded by Alexios Lekidis on 23 August 2021.

The user has requested enhancement of the downloaded file.

 Dynamic Slice Scaling Mechanisms for 5G
Multi-domain Environments
David Breitgand ⇤ , Alexios Lekidis † , Rasoul Behravesh ‡ , Avi Weit ⇤ ,
Pietro Giardina § , Vasileios Theodorou † , Cristina E. Costa ‡ , Katherine Barabash
⇤ †
IBM, Haifa, Israel, Intracom Telecom, Greece, FBK, Trento, Italy, Nextworks, Pisa, Italy
email: {davidbr,weit,kathy}@il.ibm.com, {alekidis, theovas}@intracom-telecom.com,
{rbehravesh, ccosta}@fbk.eu, {p.giardina}@nextworks.it
Abstract—Network slicing is an essential 5G innovation
whereby the network is partitioned into logical segments, so that
Communication Service Providers (CSPs) can offer differentiated
services for verticals and use cases. In many 5G use cases,
network requirements vary over time and CSPs must dynamically
adapt network slices to satisfy the contractual network slice QoS,
cooperating and using each others’ resources, e.g. when resources
of a single CSP are not sufficient or suitable to maintain all it’s
current SLAs. While this need for dynamic cross-CSP cooperation
is widely recognized, realization of this need is not yet possible due
to gaps both in business processes and in technical capabilities.
In this paper, we present a 5GZORRO approach to dynamic
cross-CSP slice scaling. Our approach both enables CSPs to
collaborate, providing security and trust with smart multi-party
contracts, and facilitates thus achieved collaboration to enable
resource sharing across multiple administrative domains, either
during slice establishment or when already existing slice needs to
expand or shrink. Our approach allows automating both business
and technical processes involved in dynamic lifecycle management
of cross-CSP network slices, following ETSI’s Zero-Touch Net-
work and Service Management (ZSM) closed-loop architecture,
and relying on resource-sharing Marketplace, Distributed Ledger
(DL), and Operational Data Lake. We show how this approach
is realized in truly Cloud Naive way, with Kubernetes as both
business and technical cross-domain orchestrator. We then show-
case applicability of the proposed solution for dynamic scaling of
Content Delivery Network (CDN) service.
Index Terms—5G, Network Slicing, NFV, ETSI ZSM
I. I NTRODUCTION
5G telecommunication networks introduce drastically im-
proved Key Performance Indicators (KPIs) in terms of band-
width, latency, reliability, availability, and device density. While
this opens up possibilities for numerous novel applications,
the “one-size-fits-all” approach is highly inefficient due to
the diverse QoS requirements of applications. The need to
simultaneously and cost-effectively address different use cases
has motivated the use of novel technological solutions such
as SDN and NFV to virtualize the physical 5G network into
multiple logical networks having different resource allocations
and providing different QoS levels [1]. This approach is termed
network slicing and offers isolation and differentiated QoS
guarantees to network silces [2].
Network slicing enables multiple heterogeneous and service-
specific logical networks to share a physical substrate network
that spans the Radio Access, the transport, and the core
network. Until recently, industrial and research communities
978-1-6654-0522-5/21/$31.00 ©2021 IEEE
⇤
‡ §
have focused mostly on static single CSP slicing use cases,
where the slice resources and services belong to one domain,
and their usage changes slowly in time once the slice is created.
However, some more complex use cases are emerging. These
require dynamic network slices, capable of following QoS
requirements variation and adapting the number of services and
resources employed to the actual demand. In such use cases,
services may span more than one CSP’s domain to properly
address demanding requirements, thus motivating the creation
of dynamic cross-domain slices.
Some system-oriented aspects of dynamic cross-domain 5G
network slices have been recently addressed in EU H2020
projects [3–5]. In [6], an architecture that addresses technical
aspects of multi-POP slice establishment are addressed. Still,
this area is in its infancy and present solutions can not easily
address some recent highly dynamic use cases, such as health-
care and vehicular scenarios [7].
The 5GZORRO project [8] engages in a comprehensive study
on facilitating CSP collaboration to enable cross-CSP dynamic
slicing. 5GZORRO uses distributed Artificial Intelligence (AI)
to implement cognitive network orchestration and management
with minimal manual intervention (zero-touch automation).
DLTs are adopted to implement flexible and efficient distributed
security and trust across the various parties involved in a 5G
end-to-end service chain. Cloud-native orchestration at the busi-
ness and technical level is employed to drive inter-operation of
these technologies in the context of the business and technical
workflows for dynamic cross-domain slice scaling.
Collaboration between CSPs is an important principle that
allows mutually beneficial capacity sharing to mitigate resource
scarcity during workload peaks and to extend services footprint.
Traditionally, CSPs engage in manually-managed long-term
peering agreements, suitable for inter-CSP collaboration for
static cross-domain slicing, but inadequate for highly dynamic
cross-domain end-to-end network slicing scenarios of 5G and
beyond. This is because static peering agreements result either
in over-provisioning or under-provisioning and do not reflect
the actual dynamics of the network usage by applications [9].
The key challenges that hinder a more dynamic collaboration
across CSPs are the lack of: (i) ubiquitous standards for dy-
namic allocation and configuration of RAN, transport, and core
resources, standard mechanisms for ad hoc trust establishment,
and (iii) protocols for seamless inter-domain collaboration.
 With the recent advancement of open standards, such as O-
RAN [10], Operator Platform Concept [11] and open source
projects like Free 5GC [12], traditional vertically integrated
telecommunication industry gradually opens up and creates an
ecosystem of standards abiding implementations that enable
better runtime collaboration across CSPs. In this work, we
focus on another aspect of inter-CSP collaboration, related to
lack of standard for coordination and orchestration of busi-
ness processes across domains, a major obstacle for efficient
resource sharing across CSPs. So far, this topic has not re-
ceived sufficient attention and we intend to fill this void by
presenting a position and making the first step towards a more
comprehensive study.
The basic design principles that we put forward include: (i)
autonomy of CSPs in their business and technical processes.
This includes freedom to use any NFV Management and
Orchestration (MANO) framework and any NFV Infrastructure
(NFVI) platform as long as QoS of a slice network service
are satisfied; (ii) non-intrusive extensions to the existing NFV
MANO so that these existing frameworks are used as actuators
to the higher level orchestration mechanisms; (iii) preserve
slice isolation so that dynamic cross-domain slice scaling does
not disrupt or interfere with the QoS of slices and services
already provided in the involved domains; (iv) clean separation
of concerns between the technical and business aspects of
orchestration; (v) cloud-native declarative orchestration and
use of Kubernetes as the cross-domain control plane for scal-
able, portable, and reproducible business flow orchestration;
(vi) rapid innovation orientation allowing to encompass novel
cross-CSP business models.
The rest of this paper is organized as follows: Sec-
tion II introduces 5GZORRO slice scaling mechanisms; Sec-
tion III presents workflow-based cross-domain slicing archi-
tecture along with relevant components; Section IV highlights
optimization-based slice scaling workflow; Section V gives
illustrative example with 5GZORRO vCDN use case; Section
VI concludes the paper and outlines future work.
II. BACKGROUND
A. Intent-based orchestration
Intent-based mechanisms are defined as means of automation
in 5G networks, where each network action is automatically
derived from the business needs instead of adhering to technical
network specifications. Three types of intent mechanisms are
defined according to ETSI ZSM: (i) intent-based Application
Programming Interface (API), which is an interface for users to
declare their intent, (ii) intent-based networking, which trans-
lates the intent into a concrete network setup and (iii) intent-
based orchestration, which allows to control and orchestrate
resources and network services dynamically.
A cloud-native approach to intent-driven management is
embodied by Kubernetes(k8s) [13]. It orchestrates applications
though reconciliation loops based on controllers [14] and allows
developing special mechanisms called K8s operators to define
and manage custom resources. Being highly extensible, this
Fig. 1: ETSI ZSM closed-loop architecture [20]
approach has been widely applied to infrastructure orches-
tration. In 5GZORRO, we follow this approach and create
domain specific Custom Resources (CR) and k8s operators
that continuously maintain CRs’ desired states. In addition,
we create custom Argo [15] workflows for 5GZORRO cross-
domain inter-CSP orchestration, building upon our previous
work reported in [16].
For automatic translation from high-level business intent into
lower-level technical intents understood by k8s, we propose
leveraging Machine Learning (ML) algorithms such as Nat-
ural Language Processing (NLP) [17]. NLP algorithms can
be trained to receive input in form of textual description of
the desired service characteristics and to produce a domain
specific encoding corresponding to the original intent. This
process is step-wise: first, the intents are pre-processed, then
keywords are extracted and translated into meaningful actions
and, finally, aggregated and validated for lack of conflicts.
Current NLP algorithms have limitations [18] and need to be
further improved to be effectively used in 5G orchestration.
B. Slice scaling overview
Our goal is to enable horizontal scaling of network slices.
For scaling-out, a subset of network service instances can
be replicated and added to the network slice to handle the
increased workload, while for scaling-in unneeded network
service instances can be decommissioned to avoid unnecessary
costs. Horizontal scaling, that can take place over the infras-
tructural resources of a single domain, as well be extended to
multi-domain setups, calling for inter-CSP collaboration and
cross-domain resource discovery mechanisms [19]. We also
note that horizontal scaling actions have to be accompanied
by automatic adjustment of additional resources, e.g., load
balancing mechanisms.
Our work goes beyond state-of-the-art through proposing a
business-level orchestration approach harmonised with techni-
cal orchestration practices and consistent with the ETSI ZSM
[20] closed-loop architecture (Fig. 1).
III. 5GZORRO A PPROACH
In this section, we first formulate the dynamic cross-domain
slice scaling problem (Subsection III-A). Next, in Subsec-

Fig. 2: A high-level 5GZORRO architecture
tion III-B, we briefly outline the 5GZORRO approach and high-
light the importance of orchestration. In Section III-C, we focus
on the proposed orchestration and management mechanisms.
A. Cross-Domain Slice Scaling Challenges
Dynamic cross-domain slice scaling poses a number of
challenges. First, while a CSP is aware of its own resources
and network services inventory, network topology, and service
areas, it does not have the same information about another CSP.
Second, multiple trade-off optimisation might be involved
in resource selection optimisation (e.g., cost-efficiency, energy
efficiency, etc.). Typically, these problems are NP-hard. Given
a large number of potential resource choices, high frequency of
decision making, on-line nature of the problem (slice scaling
requests are not known in advance), heuristics are required to
find good sub-optimal solutions fast enough. Also an overhead
of configuration should be taken into account.
Third, when a CSP procures resources from another one,
this transaction should assure non-repudiation, avoid resource
double booking, and deny unilateral retractions of the resources
by one of the leasing side. Given a dynamic nature of the
problem and a need to avoid subjective judgement, a human
operator cannot be placed in the loop and these transactions
should occur automatically, but subject to the terms and policies
set by the human agents in the respective CSPs.
Fourth, once a slice is scaled into another domain, monitor-
ing information should be exchanged and compliance to Service
Level Agreements (SLA) should be monitored and enforced.
This poses the following questions: at which level the technical
owner of a resource should share monitoring data with the legal
owner of a resource? What mechanisms should be deployed to
facilitate this sharing in a secure and trusted way? Another
important issue is how to factor in the cost of monitoring (e.g.,
hauling monitoring data from the technical to legal owner?).
Fifth, the slice scaling is driven by requirements of appli-
cations, e.g., those running in Multi-Access Edge Computing
(MEC) Platforms (MEP) as suggested in [21]. However, MEC
applications cannot directly influence network slices so there is
a need to mediate between the high level dynamic application
intents, the MEC orchestrators, and the slice orchestrators.
Sixth, the complex cross-ISP interactions should execute
in reliable repeatable manner which calls for codification and
standardisation of the cross-domain process, so that they can be
driven by the automated orchestration. However, cross-domain
collaboration on slice scaling is not standardised yet and fast
innovation is required to address business aspects involved.
B. 5GZORRO Architecture
Fig. 2 outlines the 5GZORRO architecture as four groups of
functionalities. Detailed explanation of every functionality is
beyond the scope of this paper and is covered in [22]. We
focus only on the most relevant components, necessary for
understanding how we address the cross-domain slice scaling
challenges outlined in the previous subsection.
Resource/Service Trading Functions (address the first and
third challenges): provide a Marketplace functionality pow-
ered by DLT, including Smart Contracts, to enable trading of
5G resources with no human intervention. Resource offers put
on Marketplace follow [23] and include descriptive parameters,
such as cost, service area, Service Level Agreement (SLA), and
observability. The marketplace resources can be discovered
through the Smart Resource Discovery (SRSD) component that
offers two interfaces: (a) simple catalog interface and (b) a more
sophisticated search interface that returns resource selection
where resources are already scored by some criteria.
Security and Trust Functions (address the third challenge):
help to ensure the authorization, authentication and integrity of
all communications and transactions within the platform, and
provide distributed identity, and secrets management function-
alities for the 5GZorro platform participants as well as reliable
trust and security scores for Marketplace resources.
Analytics and Intelligence Functions (address the second
and fourth challenges): provide functionalities in the Orient
and Decide blocks of the ETSI closed-loop architecture. In
5GZORRO, these functions can be deployed by CSPs internally
(a usual use case) as well as on top of a logically centralised
Data Lake. A typical example of this functionality is slice
optimisation. Another typical example is SLA compliance
prediction [24]. Each technical resource/service owner CSP
pushes monitoring data into the Data Lake and the legal
owner of the resources can execute analytic pipelines that
infer predictive models on the incoming data to forecast SLA
violations. Likewise, analytic pipelines can be run on the Data
Lake to [re-]train these models.
Zero-Touch Management and Orchestration Functions (ad-
dress aspects of the sixth challenge): comprises two types of
management and orchestration functionalities: (a) technical and
(b) business-level. The technical orchestration and management
functionality (NS and Service Orchestrator (NSSO)) adheres to
the MANO standards, such as those by ETSI NFV MANO. An
innovative aspect of the technical orchestration in 5GZORRO
is its ability to horizontally inter-operate with other MANO
engines (a feature that we leverage to facilitate technical
orchestration across domains). The higher-level orchestrator
(Intelligent Slice and Service Manager (ISSM)) manages and
orchestrates components that are outside of the scope of MANO

Fig. 3: Intelligent Slice and Service Manager architecture
(Marketplace, DLT, Data Lake, SRSD, Security and Trust, etc.),
which are essential to tackle the challenges of the 5G slicing
cross-CSP scale out as described in Section III-A. Zero-Touch
Management and Orchestration is guided by Machine Learning
(ML) technologies to ensure automation of orchestration and
management in NSs and the services they are handling.
Intelligent Slice and Service Manager (ISSM), described in
the next subsection, ties up interactions among the 5GZORRO
components into workflows, e.g. for scalable slice scaling.
C. Intelligent Slice and Service Manager
As we introduced in the previous subsections, the challenges
posed by cross-domain slice scaling call for new platform
components. The ETSI ZSM reference architecture specifies
intra-domain and cross-domain Integration Fabric functionality
and E2E Service Orchestration functionality [20]. The Inte-
gration Fabric is a special management function that allows
cross-domain service exposure and composition. It enables
registration, discovery and invocation of management services
and the communication between management functions.
The E2E Service Orchestration functionality of ETSI ZSM
provides services related to E2E lifecycle management of a
service within and across domains. However, it does not offer
details on which component should drive the high-level inter-
actions enabled by Integration Fabric and E2E Orchestration.
The cross-domain slice scaling management entails a high
level inter-operation workflow involving the aforementioned
components of the platform. It is facilitated in 5GZORRO by
ISSM, which focuses on the automation of the management
of secure cross-domain slices and of the services within them
(including optimisation). Hence, its components can be placed
in the Decide and Act blocks of the ETSI ZSM closed-loop
architecture (Fig. 1).
In our approach, ISSM is a generic cloud-native orchestrator
following the design principles outlined in Section I and relying
on Kubernetes as this is a de facto enabler for cloud-native
software. As such, it can be programmed to execute any high
level flows, not only the slice scaling related ones.
Fig. 3 shows the ISSM’s high-level architecture. ISSM
comprises three components: (1) Workflow Manager (ISSM-
WFM), (2) Optimiser (ISSM-O), and (3) MEC orchestrator
(ISSM-MEC). These components are interconnected via Event
Bus. The events are forwarded to the right subscribers via
Event Mediator. Intents can be submitted to ISSM through three
different channels: (a) a human operator submits a high level
intent in natural language and it is transformed by NLP into
a lower level intent conforming to e.g., GSMA NEST [2], (b)
MEC application control plane, and (c) continuous optimisation
executed by ISSM-O.
An intent reception causes a codified business flow to execute
by ISSM-WFM. The workflow that reaches the appropriate
5GZORRO components to automate their interactions and
facilitate the slice scaling mechanisms. During the workflow
execution, 5GZORRO components are triggered in order to
orchestrate their business process. One such component is
the Smart Resource and Service Discovery (SRSD), which
allows to discover relevant resources and then purchase them
to form or extend a NS. SRSD follows an NLP approach
to translate intents originating from an API into concrete
requests on resources that are also ranked according to their
relevance for the given intent. Following the ranking process,
the best resource candidates are selected, which allows ISSM
to navigate to a Marketplace Portal for purchasing them.
The workflows themselves are declaratively defined as Ku-
bernetes CRs in YAML and represent events and dependencies
that are triggered by these events.
ISSM-WFM allows executing multiple workflows asyn-
chronously and handles error conditions. The progress of the
workflows can be examined at any time. ISSM-O monitors
performance of slices as reflected on the Data Lake as well as
the Marketplace resource offers. ISSM-O continously proposes
slice optimization intents that, in particular, include slice scal-
ing to ensure the the QoS of each slice (described in Section
IV). These events trigger ISSM-WFM workflows to execute.
Likewise, a MEC application control plane might submit an
intent to ensure its Quality of Experience (QoE). This intent is
transformed into a lower level intent by ISSM-O. In particular,
this might include slice cross-domain scaling, which will trigger
a corresponding ISSM-WFM workflow.
On the technical side, the slice extension is performed
through the use of the NS and Service Orchestrator module
(NSSO), which represents the actuation part in the slice and
service orchestration stack, responsible for the vertical and
network service deployment across different administrative
domains, under the responsibility of two main internal modules:
Vertical and Network Service Management Function (VSMF
and NSMF). The NSSO abstracts the concept of vertical service
by using custom templates called Vertical Service Blueprints
(VSB) representing a class of Vertical Services. Once a VSB
is filled with specific values it becomes a Vertical Service
Descriptor (VSD) which actually represents the Vertical Service
and its characteristics. The set of parameters that can be
specified inside a VSB includes the list of network func-
tions and vertical applications to be deployed (called “atomic-
components”), along with all the information required for the
orchestration in terms of dimensioning (e.g., bandwidth, num-
ber of users/sessions, etc). Various aspects of the connectivity
can be also set, in terms of service type (e.g., L2/L3 VPN),
QoS, Internal and External interconnections (i.e. intra or cross-
domain slice/service connections). In 5GZORRO, the ISSM
creates the VSD by specifying in the selected VSB the proper
parameter values derived by the results of the process of smart
resources selection, and requests its instantiation to the NSSO.
At instantiation time, the VSD is translated into a set of NS
Templates (NST), partially aligned with 3GPP specification
[25], whose lifecycle is managed by the NSMF by direct
interaction with the NFVOs. VSMF and NSMF are NSSO
modules running separately under a one-to-many relationship
and interacting through the REST interface exposed by the
NSMF, where each NSMF can support several NFVOs. The
This design enables high flexibility in the deployment of the
NSSO and in the management of different services and slices
across different administrative domains. A VSMF peer-to-
peer mechanism is supported, allowing the deployment of a
federation of NSSOs.
IV. S LICE O PTIMISATION
Different from resource optimisation in a single domain,
in which the CSP has complete information about the net-
work topology and state of resources, the problem becomes
complicated when it comes to optimisation across domains,
because CSPs do not access to the topology and resources
information of other CSPs. In this regard, the optimisation
should be performed at different levels, namely intra- and inter-
domains.
A. Optimisation technologies
We adopt an approach presented in [26]. Although that work
performs slice placement in different technological domains,
namely RAN, core, and cloud under the control of single
CSP domain, it can be adapted to the scenario of multi-CSP
optimisation by carefully defining the properties of available
resources in the 5GZORRO Marketplace.
The NSSO slice optimisation is a two-step process that
leverages two specialised modules, called Translator and Arbi-
trator. These modules implement the decision logic in terms of
resource selection and optimisation during the instantiation and
actuation processes. The NSSO implements its own Arbitrator
and Translator that base their decisions on a set of policies
and rules. ML-based optimisation algorithms implemented by
external modules are also supported. The Translator module
associates to a VSD a set of proper NSTs that will contain
proper resource specifications to meet the requirements of
the Vertical Service as set of NSs and Vertical Applications.
NSTs may contain, as result of the translation process, RAN
specification, Network Service Descriptors, characterized by
a properly selected deployment flavour, and QoS constraints
as specification for the building of the NS(s) associated to
the Vertical Service. The Arbitrator checks the requirements
expressed in the various NSTs and decides on the most ap-
propriate way to deploy the required services and slices while
satisfying feasibility constraints.
Fig. 4: A slice establishment workflow
B. Workflow Automation
With the proposed method we aim at resolving of two main
scenarios: 1) the automation of the slice establishment across
multiple CSPs and 2) the slice scaling in the case that an
existing CSP slice needs to be extended with the resources from
another CSP when its own are saturated. For both challenges,
the ISSM provides a concrete workflow that is automated using
Argo. Here we focus on the first scenario, while the second is
depicted in Fig. 6.
The ISSM workflow for slice establishment involves two
CSPs (CSP A and CSP B) and consists of the following steps
illustrated in Fig. 4:
1) The service owner starts a business process by submitting
an intent on slice profile to ISSM and the latter starts
executing an explicitly codified business flow.
2) The ISSM-WFM requests the ISSM-O to translate the
provided slice blueprint into intent-based resource requests
for the SRSD.
3) The ISSM-WFM calls the SRSD to perform contextual-
ized queries for available resources.
4) The SRSD returns the obtained resources to the ISSM-O
for further optimization.
5) The ISSM-WFM uses DLT to acquire resources.
6) The ISSM-WFM links the retrieved resources with the
slice blueprints of the NSSO for each CSP using Translator
and Arbitrator.
7) The slice subnets are formed by the NSSO.
8) The slice subnets are activated and glued together through
NSSO orchestrating a tunnel creation via SDN.
At the end of this process, the formed NS includes VNFs
containing applications from different CSPs and 5G infrastruc-
ture resources of both operators. In example shown in Fig. 4,
NS includes a MEC [21] platform, RAN resources and a UPF.
The VNFs, along with the infrastructure resources, are glued
together through virtual links. Upon NS establishment, ISSM-
WFM can instantiate an SLA breach prediction pipeline in the
5GZORRO Operational Datalake and CSPs can start pushing
annotated monitoring data for this NS’s resources through their
own data ingestion pipelines
 1 "id": 127218,
2 "resourcename": "virtual node",
3 "resourceType": "edge",
4 "location": "Madrid",
5 "category": "vCDN",
6 "transactionID": 145678,
7 "resourceVirtualCapabilities": [
8 {
9 "nodeId": "51787e4a-1783-414b-82f9-95cd85231724",
10 "isMaster": 0,
11 "type": "storage",
12 "virtualCapabilities": {
13 "NoOfCPUcores": {
14 "virtualCapKey": "SSD",
15 "virtualCapValue": 100,
Fig. 5: ISSM GUI (Argo based) 16 "virtualCapUnit": "GB"
17 } } } ]
V. CDN USE - CASE IN 5GZORRO Listing 1: SRSD resource representation snippet
In this section, we demonstrate a scenario that leverages the
method proposed in Section III to mitigate the challenge of quires the resources from the 5GZORRO Marketplace. When
resource saturation of a CSP, who is leasing a NS instance from all resources are acquired, ISSM-WFM instructs the NSSO to
another CSP to provide a vCDN service for end users. The slice create the slice subnet for the vCDN service. A snippet of such
embeds performance guarantees related to e.g., throughput and subnet is illustrated in Listing 2.
latency in certain service areas, based on a profiling of the
service workload. Large-scale social events or very densely 1 "vsBlueprint": {
2 "name": "VideoStreaming",
populated areas demonstrate workloads significantly above the 3 "description": "Entertainment vCDN service",
predefined workload profile (e.g., number of ongoing video 4 "nsdIdentifier": "vCDN_NSD_v01",
5 "nsdName": "vCDN Network Service",
streams), rendering default resource allocation inadequate. To 6 "parameterId": "bandwidth" [
provide improved QoE to the end users, CSPs can rely on edge 7 "minValue": "20",
8 "maxValue": "40" ]
computing technologies, such as MEC platforms [21]. Spikes 9 virtualLinkDesc: [
in demand may exhaust the compute capacity, e.g. for video 10 {
11 connectivityType: {
transcoding or object recognition, and impact the slice QoS. 12 layerProtocol: "IPV4"
Our vCDN scaling use case consists of several steps. First, 13 },
14 qos: {
the slice is established using the workflow depicted in Fig. 4. 15 latency: 10ms,
The workflow specification is a YAML Argo CR that specifies 16 packetLossRatio: 0.001%
17 } } ], }
dependency on instantiating a GSMA-based [2] slice template.
We omit the YAML specification due to the lack of space and Listing 2: NSSO slice subnet
show a snippet of the Argo Graphical User Interface (GUI)
executing the workflow in Fig. 5. Next, a custom intent towards This slice subnet includes information on QoS requirements
the SRSD is created with phrases at different abstraction levels, of the vCDN service (bandwidth) as well as on the individual
such as: ”Edge-based near Madrid with more than 60 GB virtual links (virtualLinkDf ). Additionally, the connectivity
RAM” or ”minimal edge storage nearby”. Then, intent phrases protocol that is used is also defined (layerProtocol). This slice
are translated using NLP techniques, e.g. cossine or jackard subnet is then provided to ISSM, in order to stitch it with the
similarity [17], into a concrete query to the SRSD resource second CSP that has usable and spare resources.
database, then results are ranked uses ranking algorithms.
The highest ranked resource returned to ISSM- based on the VI. C ONCLUSION
given intent, is depicted in Listing 1. The resource representa- This paper presented a novel approach to dynamic NS
tion is following the TM Forum 634 [23], which is stardardizing scaling through dynamic collaboration between multiple CSPs
the definition of resource offers. supported by DLT transactions. The collaboration on the busi-
In this listing, the characteristics (resourceType) and capabil- ness process side allows resource sharing across different 5G
ities (resourceVirtualCapabilities) of a resource are provided. infrastructure segments and on the technical process side, slice
Additionally, there is the transactionID that refers to the DLT stitching from different CSPs or the extension of already
transaction identifier that CSPs use to annotate the data so that formed slices for ensuring QoS requirements. Furthermore,
it belongs to this transactional context. Moreover, within these both processes are automated using ML techniques inspired
capabilities the type of resource is included (storage type in by ETSI’s ZSM closed-loop architecture.
Listing 1). The format for this resource type (virtualCapKey) In this work, we applied this approach to 5GZORRO vCDN
as well as its value (virtualCapValue) and unit (virtualCapUnit) use-case that focuses on providing QoS in large-scale social
are also part of the returned response. events as well as in densely populated areas. In this use-case,
Next, ISSM-O can use the provided representation to per- the increased demands lead to a saturation of resources in the
form further optimizations (Section IV) and ISSM-WFM ac- CSP 5G infrastructure, and hence the slice is extended with

Fig. 6: Saturation of CSP resources and corresponding slice
scaling actions
additional resource from other CSPs. Our approach has been
validated in a development environment.
The business level workflows orchestration have been im-
plemented using Kubernetes native workflow management. We
believe that Kubernetes can play a threefold role: (a) VIM,
(b) MANO, and (c) business level orchestrator. The first role is
widely utilised. The second role was previously reported in [16]
and the third one is explored in this work.
As a part of our future work, we plan to evaluate our
architecture in a larger testbed and with additional use case,
to quantify the benefits that are accrued for CSP through inter-
CSP slice scaling in use cases studied in [27].
ACKNOWLEDGMENTS
This work has received funding from the European Union’s
Horizon 2020 research and innovation programme under grant
agreement No 871533 (5GZORRO).
R EFERENCES
[1] X. Li et al., “Network Slicing for 5G: Challenges and
Opportunities,” IEEE Internet Computing, 2017.
[2] GSMANG.116, “Generic Network Slice Template Version
3.0,” 2020.
[3] “SliceNet: End-to-End Cognitive Network Slicing and
Slice Management Framework in Virtualised Multi-
Domain, Multi-Tenant 5G Networks,” 2020. [Online].
Available: https://slicenet.eu/
[4] “5G-MONARCH: 5G Mobile Network Architecture
for diverse services, use cases, and applications in
5G and beyond,” 2019. [Online]. Available: https://5g-
monarch.eu/
[5] “Novel Enablers for Cloud Slicing (NECOS),” 2019. [On-
line]. Available: http://www.h2020-necos.eu/motivation-
and-vision/
[6] P. Valsamas, P. Papadimitriou, I. Sakellariou, S. Petridou,
L. Mamatas, S. Clayman, and F. Tusa, “Multi-PoP Net-
work Slice Deployment: A Feasibility Study,” in 2019
IEEE 8th International Conference on Cloud Networking
(CloudNet), 2019.
View publication stats
[7] Kukkalli et al., “Evaluation of Multi-operator dynamic 5G
Network Slicing for Vehicular Emergency Scenarios,” in
2020 IFIP Networking Conference (Networking), 2020.
[8] Gino Carrozzo et. al., “AI-driven Zero-touch Operations,
Security and Trust in Multi-operator 5G Networks: a
Conceptual Architecture,” in EuCNC 2020, 2020.
[9] T. Subramanya and R. Riggio, “Centralized and Feder-
ated Learning for Predictive VNF Autoscaling in Multi-
Domain 5G Networks and Beyond,” IEEE Tran. on Net.
and Serv. Man., 2021.
[10] “O-RAN Alliance,” 2021. [Online]. Available:
https://www.o-ran.org/
[11] “Operator Platform Concept, phase 1: Edge cloud com-
puting.”
[12] “Free 5G Core,” 2021. [Online]. Available:
https://www.free5gc.org/
[13] Cloud-Native Computing Foundation (CNCF), “CNCF
Cloud Native Definition v1.0,” 2018.
[14] “Kubernetes Controllers,” 2021. [Online]. Available:
https://kubernetes.io/docs/concepts/architecture/controller/
[15] “Argo Project: Open Source Kubernetes Native
Workflows, Events, CI and CD,” 2021. [Online].
Available: https://argoproj.github.io/
[16] D. Breitgand, “Using Argo and Knative to Orchestrate
Media-intensive Services in 5G Edge,” in KubeCon and
CloudNativeCon Europe 2020.
[17] H. Schütze and et. al, Introduction to information re-
trieval. Cambridge University Press Cambridge, 2008.
[18] C. Benzaid and T. Taleb, “Ai-driven zero touch network
and service management in 5g and beyond: Challenges
and research directions,” IEEE Net., 2020.
[19] Adamuz-Hinojosa et al., “Automated network service
scaling in nfv: Concepts, mechanisms and scaling work-
flow,” IEEE Comm. Mag., 2018.
[20] ETSI, “Zero-touch network and Service Management
(ZSM); Reference Architecture – ETSI GS ZSM 002
V1.1.1 (2019-08),” Jul 2019.
[21] ETSI, “GR MEC 017: Mobile Edge Computing
(MEC);Deployment of Mobile Edge Computing in an
NFV environment,” 2018.
[22] 5GZORRO, “Design of the 5GZORRO Platform for Se-
curity & Trust,” 2021.
[23] TM Forum, “TMF634 Resource Catalog API User Guide
v4.1.0,” 2020.
[24] V. Theodorou et al., “Blockchain-based Zero Touch Ser-
vice Assurance in Cross-domain Network Slicing,” To
appear in the proceedings of EUCNC/6G summit 2021.
[25] 3GPP, “Management and orchestration; 5G Network Re-
source Model (NRM); Stage 2 and stage 3,” Mar 2020.
[26] Behravesh, Rasoul et. al, “Joint User Association and
VNF Placement for Latency Sensitive Applications in 5G
Networks,” in Proc. of IEEE CloudNet, 2019.
[27] Sayadi, Bessem et al., “5G-PPP Software Network Work-
ing Group Cloud-Native and Verticals Services,” 08 2019.