D2.3: Initial report on the overall system architecture ...

This project has received funding from the European Union’s Horizon 2020 research

and innovation programme under grant agreement No 723172.

D2.3: Initial report

on the overall system architecture definition

Orange, Aalto, Ericsson, EI, FOKUS, Hitachi, KDDI, MI, NESIC, UT, WU

Document Number D2.3

Status Final version v1.0

Work Package WP 2.3

Deliverable Type Report

Date of Delivery June 30, 2017

Responsible Orange

Contributors Orange, Aalto, Ericsson, EI, FOKUS, Hitachi, KDDI,

MI, NESIC, UT, WU

Dissemination level PU

This document has been produced by the 5GPagoda project, funded by the Horizon 2020 Programme

of the European Community. The content presented in this document represents the views of the

authors, and the European Commission has no liability in respect of the content.

D2.3 – Initial report on the overall system architecture definition

5G!Pagoda Version 1.0 Page 2 of 118

AUTHORS

Full Name Affiliation

Sławomir Kukliński Orange

Tomasz Osiński Orange

Lechosław Tomaszewski Orange

Taleb Tarik Aalto University

Miloud Baga Aalto University

Ibrahim Afolabi Aalto University

Ilias Benkacem Aalto University

Nicklas Beijar Ericsson

Adlen Ksentini Eurecom Institute

Pantelis Frangoudis Eurecom Institute

Marius Corici Fraunhofer FOKUS

Eleonora Cau Fraunhofer FOKUS

Fabian Eichhorn Fraunhofer FOKUS

Thomas Magedanz Fraunhofer FOKUS

Daisuke Okabe Hitachi

Kota Kawahara Hitachi

Hidenori Inouchi Hitachi

Itsuro Morita KDDI Research

Yoshinori Kitatsuji KDDI Research

Zaw Htike KDDI Research

Phyo May Thet KDDI Research

Cédric Crettaz Mandat International

Kazuto Satou NESIC

Masato Yamazaki NESIC

Hiroshi Takezawa NESIC

Akihiro Nakao The University of Tokyo

Shu Yamamoto The University of Tokyo

Du Ping The University of Tokyo

Yoshiaki Kiriha The University of Tokyo

Toshitaka Tsuda Waseda University

Takuro Sato Waseda University



Executive Summary

This deliverable provides the initial vision of the 5G!Pagoda project architecture. The project aims

to align Europe and Japan views on 5G slice-based mobile network infrastructure featuring

dynamic creation and runtime management of network slices as a means to deploy private,

customized networks for different mobile services.

This deliverable is composed of a comprehensive analysis of network slicing approaches available

in the literature and a new reference architecture which is compliant as much as possible with

other network standardization activities, describes the architecture of orchestration of the multi-

domain slicing system and addresses some important topics in slicing like functional components

decomposition, RAN slicing, control plane customization and data plane programmability. The

envisioned architecture shall be composed of functional blocks and interfaces to facilitate the

creation, deployment and management of Network Slices over single administrative domain and

over multiple domains on the top of virtual network infrastructures. Whilst the proposed

architecture is designed to be closely compatible with the ETSI NFV architecture, it has innovative

extensions especially towards multi-domain resource deployment and orchestration and high

customization of the slices towards the specific requirements of the network services, these

representing the key added value of the functional developments presented.

This document will guide the future work in 5G!Pagoda in a twofold manner as follows:

• Other work packages will further devise, develop and implement the functionality and the

different algorithms and mechanisms required by the functional blocks, such as orchestration,

management, resource placement. From this perspective, this deliverable represents the

fundamental common architecture description, enabling the synchronization of the further

developments.

• The document will represent the basis for the further development of the final 5G!Pagoda

architecture including the feedback from the design and implementation efforts of the core

research as well as early integration activities.



Table of Contents

Introduction .............................................................................................................. 13 1.

1.1. Objectives ........................................................................................................................................................ 13

1.2. Motivation and scope ................................................................................................................................. 13

1.3. Relationships with other tasks in WP2 and other 5G!Pagoda deliverables ........................... 15

1.4. Structure of the document ........................................................................................................................ 15

Terminology ............................................................................................................. 16 2.

Related works ........................................................................................................... 20 3.

3.1. NGMN ............................................................................................................................................................... 21

3.2. 5G PPP overall architecture....................................................................................................................... 23

3.3. 5G PPP projects related to slicing .......................................................................................................... 26

3.3.1. 5G-Crosshaul ........................................................................................................................................ 26

3.3.2. 5G Exchange ......................................................................................................................................... 28

3.3.3. METIS II ................................................................................................................................................... 30

3.3.4. 5G NORMA ........................................................................................................................................... 32

3.3.5. 5G SONATA .......................................................................................................................................... 34

3.4. ITU-T IMT-2020 FG architecture ............................................................................................................. 36

3.5. IETF slicing ....................................................................................................................................................... 39

3.6. 3GPP activities on network slicing ......................................................................................................... 39

3.7. 5G Americas .................................................................................................................................................... 46

3.8. ETSI NFV activities on slicing .................................................................................................................... 47

3.9. Summary of the state of the art .............................................................................................................. 48

5G!Pagoda architectural requirements .................................................................. 52 4.

4.1. Generic business requirements ............................................................................................................... 54

4.2. 5G!Pagoda scenarios specific requirements ...................................................................................... 54

Design considerations ............................................................................................. 56 5.

5G!Pagoda reference architecture ......................................................................... 59 6.

6.1. Functional architecture of the system .................................................................................................. 60

6.2. Network slices structure ............................................................................................................................. 62

6.2.1. Internal architecture of the Dedicated Slice ............................................................................. 62

6.2.2. Internal architecture of the Common Slice .............................................................................. 67



6.2.3. Slice description and capability exposure ................................................................................. 68

6.3. The orchestration architecture ................................................................................................................ 70

6.3.1. Policy-Based Management of orchestration ........................................................................... 73

6.3.2. Interfaces and reference points of the orchestration architecture.................................. 75

Slicing in the multi-domain environment ............................................................. 79 7.

7.1. Multi-domain slicing orchestration ....................................................................................................... 79

7.2. Slice identification ........................................................................................................................................ 82

7.3. Inter-slice operations in multi-domain slicing .................................................................................. 83

7.4. Management of multi-domain slices .................................................................................................... 84

Slice templates ......................................................................................................... 85 8.

8.1. Slice architecture template example ..................................................................................................... 85

8.2. Application of the slice architecture template .................................................................................. 89

8.2.1. Massive IoT slice architecture template application ............................................................. 90

8.2.2. Content delivery network slice template application ........................................................... 91

8.2.3. How to extend the slice architecture template ....................................................................... 92

Key implementation elements ................................................................................ 93 9.

9.1. Generic Virtual Network Functions implementation considerations ........................................ 93

9.2. Slice selection, matching and advertisement .................................................................................... 96

9.3. Inclusion of hardware nodes and subsystems .................................................................................. 99

9.4. RAN slicing ................................................................................................................................................... 101

9.4.1. RAN slicing options ........................................................................................................................ 101

9.4.2. Core Network slicing with RAN assistance ............................................................................ 102

9.4.3. Base Station architecture for slice selection.......................................................................... 103

9.5. Data plane programmability ................................................................................................................. 105

9.5.1. Novel Data Plane architecture in 5G!Pagoda ....................................................................... 107

9.5.2. ICN/NDNICN use case of Data Plane programmability ................................................... 108

9.6. NDN/ICN example of the use of multiple slices ............................................................................ 109

9.7. Example of multi-domain mobile network slice ............................................................................ 110

9.8. The MVNO-like network implementation ........................................................................................ 112

Concluding remarks .............................................................................................. 114 10.

Appendix A. References .................................................................................................. 116





List of Tables

Table 1 – List of Acronyms .................................................................................................................................. 10

Table 2 – Terms defined in this document ................................................................................................... 16



List of Figures

Figure 1 – NGMN 5G architecture vision [3] ................................................................................................ 21

Figure 2 – NGMN network slicing concept [4] ........................................................................................... 22

Figure 3 – Overall network softwarization and programmability framework [5] .......................... 24

Figure 4 – 5G PPP Service & Infrastructure Management and Orchestration architecture [5] 25

Figure 5 – 5G PPP 5G-Crosshaul high-level architecture [8] ................................................................. 27

Figure 6 – 5G PPP 5G-Crosshaul functional structure [6] ....................................................................... 28

Figure 7 – 5G PPP 5GEx reference architectural framework [9] ........................................................... 29

Figure 8 – 5G PPP 5GEx functional model of multi domain orchestration [9] ............................... 30

Figure 9 – 5G NORMA functional reference architecture [11] .............................................................. 33

Figure 10 – SONATA Service Platform functional architecture mapped onto ETSI reference

architecture [14] ............................................................................................................................................ 35

Figure 11 – Softwarized network architecture view for IMT-2020 [18] ............................................. 37

Figure 12 – Deployment scenarios of network slicing concept (3GPP) [24] ................................... 41

Figure 13 – 3GPP Network Slice Instance life-cycle management phases [26] ............................. 42

Figure 14 – Network Slice related information model [26] .................................................................... 43

Figure 15 – The mobile network management architecture mapping relationship between

3GPP and NFV-MANO architectural framework [27] ...................................................................... 44

Figure 16 – 3GPP 5GS service-oriented architecture [28] ...................................................................... 45

Figure 17 – 3GPP 5GS architecture – interface view [28] ........................................................................ 45

Figure 18 – 5G Americas network slicing [30] ............................................................................................. 47

Figure 19 – Planes of 5G!Pagoda slices ......................................................................................................... 56

Figure 20 – Instantiated 5G!Pagoda slices on top of the same infrastructure ............................... 60

Figure 21 – Dedicated Slice internal architecture ...................................................................................... 63

Figure 22 – Common Slice internal architecture ........................................................................................ 68

Figure 23 – Orchestration architecture .......................................................................................................... 70

Figure 24 – Policy-Based Management: ECA case .................................................................................... 74

Figure 25 – Life-cycle orchestration for multi-domain architecture ................................................... 80

Figure 26 – Recursive resource orchestration ............................................................................................. 81

Figure 27 – Slice architecture template example ....................................................................................... 86

Figure 28 – Deployment network architecture example ......................................................................... 89



Figure 29 – Massive IoT slice architecture .................................................................................................... 90

Figure 30 – CDN Slice Architecture ................................................................................................................. 91

Figure 31 – Modification of the High Level Functionality with the Software Network Functions

.............................................................................................................................................................................. 94

Figure 32 – Abstract example of the concept ............................................................................................. 95

Figure 33 – Network-based slice selection mechanisms ........................................................................ 97

Figure 34 – UE controlled Slice Selection Functionality .......................................................................... 98

Figure 35 – Global overview of the envisioned Network Slicing architecture ............................. 102

Figure 36 – An overview of the eNodeB functions enforcing network slices at the RAN ....... 104

Figure 37 – Deep Data Plane Programmability i) without and ii) with ........................................... 106

Figure 38 – Deep Data Plane architecture in FLARE [44] ..................................................................... 108

Figure 39 – CDN/ICN combined content delivery service ................................................................... 110

Figure 40 – Exemplary E2E mobile network slice .................................................................................... 111

Figure 41 – E2E (RAN + CN) slicing architecture .................................................................................... 113



Abbreviations

Throughout this document, the following acronyms, listed in Table 1, are used.

Table 1 – List of Acronyms

Abbreviation Original term

3GPP The Third Generation Partnership Project

5G PPP The Fifth Generation Infrastructure Public Private Partnership

5GMF The Fifth Generation Mobile Communications Promotion Forum

AMQP Advanced Message Queuing Protocol

API Application Programming Interface

BSS Business Support System

BSSO Business Service Slice Orchestrator

CDN Content Distribution Network

CN Core Network

CPU Central Processing Unit

DM Domain Manager

DSSO Domain-Specific Slice Orchestrator

E2E End to End

EBI East-Bound Interface

ECA Event-Condition-Action

EM Element Manager

eMBB enhanced Mobile Broad Band

eMBMS evolved Multimedia Broadcast Multicast Service

FCAPS Fault, Configuration, Accounting, Performance, Security (management)

FG IMT-2020 The Focus Group on network aspects of IMT-2020

GPU Graphics Processing Unit

HNS Hardware Nodes and Subsystems

HSS Home Subscriber System

I/Q In-phase/Quadrature phase




IaaS Infrastructure as a Service

ICN Information-Centric Networking

IMT International Mobile Telecommunications

IoT Internet of Things

ITU-T International Telecommunication Union Telecommunication Standardization Sector

M2M Machine to Machine

MANO MANagement & Orchestration

MdO Multi-domain Orchestrator

MDSO Multi-Domain Slice Orchestrator

MEC Mobile Edge Computing

mMTC massive Machine-Type Communications

MQTT Message Queue Telemetry Transport

N2N Neighbor to Neighbor

NAS Non-Access Stratum

NBI North-Bound Interface

NDN Named Data Networking

NFV Network Function Virtualization

NFVI Network Function Virtualization Infrastructures

NFVO Network Function Virtualization Orchestrator

NGMN Next Generation Mobile Network Alliance

NM Network Manager

NMS Network Management System

NSaaS Network Slice as a Service

NSD Network Service Descriptor

O&M Operation and Maintenance

OFDM Orthogonal Frequency-Division Multiplexing

OSS Operation Support System




PaaS Platform as a Service

PBM Policy-Based Management

PNF Physical Network Function

QoE Quality of Experience

QoS Quality of Service

RAN Radio Access Network

RRC Radio Resources Control

SBC Slice Border Control

SBI South-Bound Interface

SDN Software-Defined Networking

SDO Standards Development Organization

SDR Software Defined Radio

SON Self-Organizing Network

SOS Slice Operation Support

SSF Slice Selection Function

TOSCA Topology and Orchestration Specification for Cloud Applications

uRLLC Ultra Reliable and Low Latency Communications

VIM Virtual Infrastructure Manager

VMN Virtual Mobile Network

VNF Virtualized Network Function

VNFaaS VNF as a Service

VNFM Virtualized Network Functions Manager

WAN Wide Area Network

WBI West-Bound Interface

WIM WAN Infrastructure Manager

WP 5D Working Party 5D – IMT systems

xMBB extreme Mobile Broad Band



Introduction 1.

1.1. Objectives

The objectives of this deliverable are to define the initial 5G!Pagoda architecture and to specify

the overall system from the functional and architectural standpoint, providing a description of

functional entities that are specific for generic network slicing, beyond the current 3GPP scope.

Part of the architecture is related to orchestration of slices that is responsible for lifecycle

management of slices and their optimization while another part is related to the effective active

service implementation within the slices.

The high level, reference architecture aims to serve as the basis for the implementation of

5G!Pagoda concepts, acting as a synchronization point between the management and

orchestration developments and the customized network functions ones.

The feedback from the implementation as well as output from other work packages of this

project will be later on used for the refinement of the architecture, which will be provided in

deliverable D2.5. The final architecture will describe functional entities, interfaces between them

(or description of messages busses if used), information model, data schemas, algorithms and

mechanisms, that are proposed for the dynamic network slicing including the design and

specification coming from WP3 and WP4 as well as the early implementation results from WP5.

1.2. Motivation and scope

In the recent years, there have been noticeable research initiatives on the Fifth Generation of

Mobile Communications System (5G System), in Europe, Japan and worldwide. However, the

focus has been merely on high-level ideas and the generic directions that assume the use of

software based solutions as much as possible, while not considering the specific needs of either

the orchestration mechanisms enabling a multi-slice environment neither on the actual software

network functions from which the service will be composed of. A comprehensive and detailed 5G

architecture is yet to be defined; leaving still space for research and standardizations activities

aiming to shape the 5G system architecture, one of the core objectives of this 5G!Pagoda project.

It is generally agreed that cloud computing, Software Defined Networking (SDN) and Network

Function Virtualization (NFV) are key enabling technologies for future 5G mobile network. For

example, ITU-T Focus Group IMT-2020 identifies ‘network softwarization’ as one of the most

crucial technology focus areas for 5G mobile networks. According to ITU-T, network

softwarization is an overall transformation trend for designing, implementing, deploying,

managing and maintaining network equipment and network components by software

programming, exploiting characteristics of software, such as flexibility and rapidity of design,

development and deployment throughout the lifecycle of network equipment and components,

for creating conditions that enable the re-design of network and services architectures; allow

optimization of costs and processes; and enable self-management.



An efficient integration of software technologies like SDN and NFV with cloud computing

provides important advantages over classical technologies in terms of network configuration

flexibility, scalability and elasticity, which are highly needed to fulfill the numerous requirements

of 5G network. Furthermore, network management procedures of 5G system should be

automated and from the operator point of view as simple as possible. The network will

orchestrate their Network Function Virtualization Infrastructures (NFVIs) and the orchestrator will

automatically manage the lifecycle of the supported Virtual Mobile Networks (VMNs) and the

corresponding Virtualized Network Functions (VNFs).

The 5G mobile networks are designed to serve all mobile users and many service types, ensuring

high degree of service-level differentiation, shaped to the individual needs of users and their

equipment type’s available infrastructure as well as to the specific requirements of mobile

services. In general, mobile services also exhibit diverse requirements in terms of offered user

data rate, latency, jitter, reliability and mobility support as well as resilience, authentication and

authorization and security. It seems however that the 5G requirements, as defined by ITU-T (IMT-

2020) are hard to fulfill by a single network system while making the offered service cost-

effective. It led to the conclusion that we can build ‘parallel’ networks and each of them can be

tailored to a specific set of services, i.e. it will be characterized by different data transmission

means (e.g. messaging, data bursts, continuous sessions, etc.), QoS and mobility (e.g. guaranteed

resources with zero-packet loss mobility) as well as control plane services (e.g. connectivity, idle

mode support, device availability and reachability). This parallel need for service level

differentiation gave birth to the network slicing paradigm. Network slicing provides creation of

logically isolated fully fledged networks that share the same infrastructure (resources) while

implementing different network services according to the specific use case requirements. The

concept is strongly linked with the software technologies mentioned in this section, bringing the

flexibility of the active services in the slices and the virtualized infrastructure paradigm, bringing

the opportunity to deploy parallel software networks.

The 5G!Pagoda architectural approach is based on comprehensive state of art analysis of network

slicing approaches that includes 5G PPP projects, 3GPP 4G and 5G slicing oriented activities, IMT-

2020 Focus Group concepts and the NGMN vision of slicing. The main goal of 5G!Pagoda

architecture is to provide a high level network slicing architecture that can be instantiated to

multiple networking solutions and is compliant as much as possible with all analyzed network

slicing concepts, including 3GPP. The concept allows also for integration of legacy systems as well

as advanced, programmable data plane operations in order to provide highly efficient data plane.

Moreover, the issues of network slicing in multi-domain environment have also been addressed.

The reference architecture described in this deliverable is flexible and allows instantiation of a

multi-domain network slice in many different ways. As it has been already mentioned, the

architecture will be updated by the end of the project after the experience related to testbeds

implementation as well as results achieved in other work packages of the project have been

gathered and carefully analyzed.



1.3. Relationships with other tasks in WP2 and other 5G!Pagoda

deliverables

The identified reference architecture from this deliverable will be used as inputs to WP5, where

integrated testbed will be designed and implemented in accordance with the concepts and

blueprints proposed here. The experiments resulting from the WP5 will validate and provide a

feedback for WP2 in order to define the final 5G!Pagoda architecture in D2.5.

Starting from the architecture here presented, further functionality and algorithms development

will be executed in WP3 and WP4. D data and control plane functions representing components

of the active services within the slices, which will be designed, specified and evaluated in WP3

and reported on the correspondent deliverables, should be consistent with the overall system

design from WP2. Furthermore, the E2E network slice orchestration and management framework

will be further designed and specified in WP4 and evaluated within the context of WP5 together

with the active services.

1.4. Structure of the document

Following this introductory chapter, the remaining part of the document is structured as follows:

• Chapter 2 provides the basic terminology used throughout this report. It includes the

descriptions of abbreviations and technical terms.

• Chapter 3 describes state of the art for network slicing architecture. It provides brief overview

of existing software networks architecture concepts, on-going standardization and research

projects related to slicing.

• Chapter 4 summarizes requirements related to 5G!Pagoda architecture, some of them were

taken from and refined from D2.1 [1].

• Chapter 5 presents basic design considerations and high-level foundations of 5G!Pagoda

architecture.

• Chapter 6 introduces the general 5G!Pagoda architecture concept that includes a generic

structure of the slices.

• Chapter 7 describes operational and orchestration-related issues of network slicing.

• Chapter 8 includes the generic functional components of multi-domain slice templates.

• Chapter 9 deals with selected implementation issues including topics like RAN slicing, data

plane programmability, etc.

• Chapter 10 summarizes and concludes the document.



Terminology 2.

Table 2 lists terms used in this document along with their definitions.

Table 2 – Terms defined in this document

Terminology Definition

The Fifth Generation of Mobile

Communications System (5G

system)

The proposed next major phase of mobile

telecommunications standards beyond the current 4G/IMT-

Advanced standards. Rather than faster peak Internet

connection speeds, 5G system planning aims at higher

capacity than the current fourth generation of mobile

communication system, allowing higher number of mobile

broadband users per area unit and allowing consumption of

higher or unlimited data quantities in gigabyte per month

and user. Note that 5G system does not strictly represent the

advancements in the radio area, mainly concentrating on the

connectivity and data services.

Cloud computing A type of Internet-based computing that provides shared

computer processing resources and data to computers and

other devices on demand. It is a model for enabling

ubiquitous, on-demand access to a shared pool of

configurable computing resources (e.g. computer networks,

servers, storage, applications and services).

Software Defined Networking A network architecture concept that allows network

administrators to manage network services through

abstraction of lower-level functionality. SDN is meant to

address the fact that the static architecture of traditional

networks doesn't support the dynamic, scalable computing

and storage needs of more modern computing environments

such as data centers.

Slice An isolated collection of programmable resources to

implement network functions and application services

through software programs to accommodate individual

network functions application services within each slice

without interfering with the other functions and services on

the other slices.

Network Function

Virtualization

A network architecture concept that uses the technologies of

IT virtualization to virtualize entire classes of network node

functions into building blocks that may connect, or chain

together, to create communication services.

Virtualized Network Function Software implementations of network function that can be

deployed on a Network Function Virtualization Infrastructure.




IMT-2020 A provisional name of equivalent standard on 5G system

defined in ITU-R WP 5D.

Working party 5D – IMT

systems

A standard community responsible for the overall radio

system aspects of International Mobile Telecommunications

(IMT) systems, comprising the IMT-2000, IMT-Advanced and

IMT for 2020 and beyond.

Network softwarization An overall transformation trend for designing, implementing,

deploying, managing and maintaining network equipment

and network components by software programming,

exploiting characteristics of software such as flexibility and

rapidity of design, development and deployment throughout

the lifecycle of network equipment and components, for

creating conditions that enable the re-design of network and

services architectures; allow optimization of costs and

processes; and enable self-management.

5G!Pagoda A research project federating Japanese and European 5G

system test-beds to explore relevant standards and align

views on 5G system mobile network infrastructure supporting

dynamic creation and management of network slices for

different mobile services.

Slices of virtual mobile

networks

A logical instantiation of a mobile network possible to create

with both legacy platforms and network functions, but

substantially lower barriers to using the technology, for

example through increased flexibility and decreased costs.

Mobile slice A slice of virtual mobile networks.

Resource Orchestrator Entity responsible for domain wide global orchestration of

network services and software resource reservations in terms

of network functions over the physical or virtual resources the

RO owns. The domain an RO oversees may consist of slices of

other domain [2].

Service Orchestrator The Network Service Orchestration is managing the lifecycle

of network services. The Resource Orchestration provides an

overall view of the resources present in the administrative

domain to which it provides access and hides the interfaces of

the VIMs present below it [2].

The Third Generation

Partnership Project (3GPP)

Collaboration between groups of telecommunications

associations, known as the Organizational Partners. The initial

scope of 3GPP was to make a globally applicable 3rd

generation (3G) mobile phone system specification based on

evolved Global System for Mobile Communications (GSM)

specifications within the scope of the International Mobile




Telecommunications-2000 project of the International

Telecommunication Union (ITU). The scope was later enlarged

to include the development and maintenance of: GSM and

related ‘2G’ and ‘2.5G’ standards including GPRS and EDGE,

UMTS and related ‘3G’ standards including HSPA, LTE and

related ‘4G’ standards, An evolved IP Multimedia Subsystem

(IMS) developed in an access independent manner and next

generation and related ‘the fifth generation’ standards.

Next Generation Mobile

Networking Alliance (NGMN)

A mobile telecommunications association of mobile

operators, vendors, manufacturers and research institutes. It

was founded by major mobile operators in 2006 as an open

forum to evaluate candidate technologies to develop a

common view of solutions for the next evolution of wireless

networks. Its objective is to ensure the successful commercial

launch of future mobile broadband networks through a

roadmap for technology and friendly user trials. Its office is in

Frankfurt, Germany.

Internet of Things (IoT) The internetworking of physical devices, vehicles (also

referred to as ‘connected devices’ and ‘smart devices’),

buildings and other items – embedded with electronics,

software, sensors, actuators and network connectivity that

enable these objects to collect and exchange data. In 2013

the Global Standards Initiative on Internet of Things (IoT-GSI)

defined the IoT as ‘the infrastructure of the information

society’.

The Fifth Generation

Infrastructure Public Private

Partnership

A group initiated by the European Commission and industry

manufacturers, telecommunications operators, service

providers, SMEs and researchers. It aims to deliver solutions,

architectures, technologies and standards for the ubiquitous

next generation communication infrastructures of the coming

decade.

The Fifth Generation Mobile

Communications Promotion

Forum (5GMF)

A group actively promoting 5G system study in line with

trends both in Japan and abroad based on a roadmap on 5G

system implementation policy published by the government

of Japan.

Mobile Edge Computing A network architecture concept that enables cloud computing

capabilities and an IT service environment at the edge of the

cellular network. The basic idea behind MEC is that by

running applications and performing related processing tasks

closer to the cellular customer, network congestion is reduced

and applications perform better.




Content delivery network A globally distributed network of proxy servers deployed in

multiple data centers. The goal of a CDN is to serve content

to end-users with high availability and high performance.

CDNs serve a large fraction of the Internet content today,

including web objects (text, graphics and scripts),

downloadable objects (media files, software and documents),

applications (e-commerce, portals), live streaming media, on-

demand streaming media and social networks.

Quality of Experience A measure of a customer's experiences with a service (web

browsing, phone call, TV broadcast, call to a Call Centre). QoE

focuses on the entire service experience and is a more holistic

evaluation than the more narrowly focused user experience

(focused on a software interface) and customer-support

experience (support focused).



Related works 3.

The 5G!Pagoda architecture is strongly focused on the network slicing, having two perspectives:

the end-user service perspective concentrating on the components within the slices and the

issues related to slice configuration in order to provide the appropriate service, and the

infrastructure management perspective concentrating on the proper allocation of resources to

slices and the interoperability between different slices in a multi-slice environment.

It is a well-known fact that the concept of slice in networking has been first introduced in the

overlay network research efforts, such as PlanetLab, in 2002. At that time, a slice has been defined

as an isolated set of network bandwidth, computational, storage, resources allocated for a group

of users that ‘program’ network functions and services over their overlay network overlaid across

‘the planet’. Since various network virtualization testbed efforts such as PlanetLab EU, PlanetLab

JP, GENI, VNode, FLARE, Fed4Fire, have inherited the concept of slices as a basis of the

infrastructures, as a set of programmable resources to tailor new network services and protocols,

it is quite natural to use the slice concept to be extended to mobile networking. Network Slicing

is an extension of the concept of a ‘slice’ originally defined to mobile networking with additional

focus on mobile network functions implemented on top of programmable resources.

The terminology ‘network slicing’ has caught much attention in research communities and

industries, as well as standards developing organizations (SDOs) such as 3GPP, IETF and ITU.

Although the definition of network slicing is still under heavy discussion, we have generally

defined ‘slice’ as an isolated collection of programmable resources to implement network

functions and application services mostly in software to accommodate individual network

functions application services within each slice without interfering with the other functions and

services on the other slices.

Network slicing is considered one of the most important concepts to realize ‘extreme flexibility’ in

5G mobile networking. The current mobile networks are optimized to serve only mobile phones.

However, 5G mobile networking needs to serve a variety of devices with very different,

heterogeneous quality of service (QoS) requirements without interference among one another.

The 5GMF white paper classifies communications to be enabled in 5G mobile networks into three

categories, eMBB, mMTC and uRLLC that means that each of the categories can be implemented

as a slice. However, the number of slices doesn’t have to be limited to 3 only, in fact any service

can be deployed as a network slice. Moreover, many virtual network or service operators can

share the same infrastructure that lead to multi-tenancy of the sliced networking solution. The

existence of many slices raises important questions related to their management which for the

sake of scalability and dynamic reaction to events has to be automated as much as possible and

follows the feedback loop based (aka autonomic) network management paradigm.

It has to be noted that the network slicing is still in its infancy and many of the existing solutions

address some specific issues of network slicing only. It is expected however that in the close

future many of the present approaches will converge and the final architecture will allow for E2E

network slicing in a heterogeneous and multi-domain environment that includes also the slicing

of RAN.



In the following sections of the chapter a synthetic overview of activities related to network

slicing is presented.

3.1. NGMN

According to NGMN [3], a ‘network slice (5G slice) supports the communication service of a

particular connection type with a specific way of handling the C-and U-plane for this service. To

this end, a 5G slice is composed of a collection of 5G network functions and specific RAT settings

that are combined together for the specific use case or business model’.

Figure 1 – NGMN 5G architecture vision [3]

The NGMN architecture is composed of three layers plus E2E management and orchestration.

The infrastructure resources layer comprises of physical network infrastructure, including access

nodes, cloud nodes (edge & central), 5G devices, networking nodes and associated links. This

layer represents a common hardware that provides storage, computing and networking resources

for the upper, business enablement layer. The role of business enablement layer is to provide

library of network software modules such as Control/User Plane functions or Radio Access

Technology capabilities that can be retrieved from the repository. These modular building blocks,

which can be seen also as different implementations of the same functionality, are desired to

communicate each other in order to fulfil requirements of business applications and use cases.

Services, that utilize lower layers, are defined at the business application layer, which contains

specific applications of the operator, enterprise, verticals or 3rd parties. This layer should define a

Blueprint of a service that uses modular functional blocks from the business enablement layer in

order to deploy specific business application. The enabler and the plane, which coordinates all

the layers is E2E management & orchestration – the contact point to translate the use cases and

business models into actual network functions and slices. It provides mechanisms to build



dedicated network slices for an application, management of the entire E2E system by placing

(geographically), chaining and scaling the relevant virtual network functions and assigns the

relevant performance configurations and mapping onto the infrastructure resources. In order to

realize all these tasks the E2E management & orchestration subsystem should have an interface to

each of the architecture layers and intelligence to optimize an orchestration process.

Additionally, NGMN has published in January 2016 the document ‘Description of Network Slicing

Concept’ [4]. It includes a detailed description of terminology and network slicing related

concepts that are presented in Figure 2.

Figure 2 – NGMN network slicing concept [4]

The network slicing architecture is comprised of three layers:

• The Resource Layer is composed of physical and logical resources. Physical components

such as compute nodes, storage, transport and radio access network equipment belongs to a

pool of physical resources. Logical resources are regarded as virtualized pool of resources

dedicated to a particular network function or shared between a multiple network functions.

The term of Network Function refers to a ‘processing function in a network’.

• The Network Slice Instance Layer includes Network Slice Instance’s. The Network Slice

Instance is ‘a set of network functions and resources to run these network functions, forming a

complete instantiated logical network to meet certain network characteristics required by the

Service Instance(s)’. The particular Network Slice Instance may be shared between multiple

Service Instances.

• The Service Instance Layer represents end-user or business services, which are deployed

over network slicing platform. The particular service is described as Service Instance.



An important functional entity is the Sub-network Instance. It acts as a subset of network

functions and resources dedicated for these network functions. The Sub-network Instance may be

a hardware-based subsystem. One or more Sub-network Instance’s may be stitched together in

order to compose a Network Slice Instance. Both the Network Slice Instance and Sub-network

Slice Instance are described by Network/Sub-network Slice Blueprint that characterizes ‘the

structure, configuration and the plans/work flows for how to instantiate and control the Network

Slice Instance during its life cycle’. The Network/Sub-network Slice Blueprint provides description

of characteristics and performance requirements of Network/Sub-network Instance that is

tailored to a specific service (e.g. URLLC service) represented as Service Instance.

The NGMN vision illustrates neatly basic architectural requirements and shed lights on overall 5G

architecture. It provides a high-level view, that clarifies well the most important assumptions, but

there isn’t any functional decomposition. Thus, design and functionality of network entities,

interfaces between them and orchestration framework should be described in more detail. Also,

multi-domain orchestration hasn’t been taken into considerations by NGMN and this gap should

be also addressed by the 5G!Pagoda architecture.

3.2. 5G PPP overall architecture

The 5G PPP architecture draft [5] defines network slicing as one of the most important parts of

the overall 5G architecture. This concept is expected to meet a wide range of business use cases

that the 2020 timeframe will demand. The 5G PPP organization defines network slicing as

‘multiple logical networks as independent business operations on a common physical

infrastructure’, composed of both physical and virtual network functions, as well as edge-

cloud and central-cloud deployments.

The 5G PPP introduces overall network softwarization and programmability framework, which is

presented in Figure 3. It’s split up into planes that are not completely independent from each

other. Thus, interactions between them are realized by reference points/interfaces.

Figure 3 covers the entire ecosystem of 5G softwarized networks. The forwarding/data plane is

the collection of resources across all network devices capable of forwarding the control and data

plane traffic. The common resources comprise the network infrastructure, including Fixed and

Radio Access Networks, Aggregation and Core Networks and Network Clouds. The Infrastructure

Control Plane is a set of functions that are responsible for controlling network devices, elements

and data processing units. This control plane is separated from the control and enforcement

functions, which are network segment-specific and integrated with data plane devices. Thus, the

control plane isn’t fully centralized and data plane contains control agents, called Common

Control & Enforcement entities. The centralized control entity – Infrastructure Control of (Virtual)

Network Functions – is responsible for managing network softwarization functions, orchestration

functions, mobility control functions, cloud functions, mobile edge computing functions as well

as includes adaptors to different enforcement functions.



Figure 3 – Overall network softwarization and programmability framework [5]

The Infrastructure Softwarization Plane enables the provisioning and operation of software and

service networks. It includes software for designing, implementing, deploying, managing and

maintaining network components and/or services by programmable interface. The key

responsibility of this plane is the deployment of new network and management services, what

may result in E2E slice provisioning. This plane acts as an Application Programming Interface to a

software network platform and enables programmability of E2E network services. The Integrated

Network Management and Operations Plane enables the creation, operation and control of

dedicated management functions operating on the top of 5G E2E infrastructure. It provides

management capabilities (FCAPS, Monitoring, Network Information Management) for each

network slice. Furthermore, functions of this plane coordinate multi-domain operations. The

functions of the Multi-Service Management Plane are able to create, install, configure and

manage a group of network functions and/or nodes. This plane includes Slice-Service Mapper

functions, Resource, Domain and Service Orchestration functions Service Information

Management functions and Network Capability Discovery functions. It can be perceived as

Operations Support System (OSS) with extensions that allow dynamically creating, operating and

controlling multiple logically isolated network services running on the top of network (virtual)

infrastructure. The Application and Business Plane defines service deployments from the business

point of view and provides a business interface for parties that want to launch a network service

on the softwarized network platform.



Figure 4 – 5G PPP Service & Infrastructure Management and Orchestration architecture [5]

The 5G PPP draft defines also the Service & Infrastructure Management and Orchestration

architecture, which in fact is a reference architecture of the E2E orchestration framework. Both

single and multi-domain mechanisms have been addressed, but the latter in limited scope. Figure

4 presents single-domain multi-service control and management platform and according to the

Figure 3 it covers three planes: the Multi-Service Management Plane, the Integrated Management

and Operation Plane and the Application and Business Service Plane. The purpose of the

orchestration framework architecture is the description of service and resource orchestration

mechanisms across the 5G network. To provide flexibility and programmability 5G PPP has

designed key functionalities, which are: the Service Development Kit to let developers quickly

implement novel network services, the Management System to take care of reliable operation

and the Service Platform including customizable Service (Domain) Orchestrator, Resource

Orchestrator, a Service Information Base and various enablers.

The Management and Operations system presented in the picture is decomposed into multiple

functionalities, what basically is highly desirable, but there is a lack of detailed description of

behavior of each function.

The 5G PPP describes also a multi-domain orchestration architecture, but the ‘multi-domain’ term

is defined loosely and it refers to as a ‘multi-technology (orchestrating resources and/or services

using multiple domain orchestrators) or multi-operator (orchestrating resources and/or services

using domain orchestrators belonging to multiple administrative domains)’. In general, it means



that the multi-domain orchestrator provides resources and services using multiple technology-

specific domain orchestrators that can belong to various operators and/or vendors.

3.3. 5G PPP projects related to slicing

There is a wide scope of projects related to 5G architecture, participating in the 5G PPP initiative

and funded within the EU program ‘Horizon 2020’. These 5G PPP projects span many topics

related to 5G system, including several projects that aim at designing the new 5G network

architecture in terms of network slicing.

3.3.1. 5G-Crosshaul

The 5G-Crosshaul project [6], [7], [8] is dedicated to a 5G integrated backhaul and fronthaul

transport network development. Based on SDN and NFV as key principles, this softwarized

network is expected to provide unified (both at data and control planes’ levels) multi-technology

(mmWave, µWave, optical and copper) E2E packet-based transport domain and support recursive

and homogenous multi-tenancy of underlying heterogeneous resources giving tenants freedom

and flexibility of, controlling, reconfiguring and operating their networks without influencing

other coexisting tenants’ networks. Dealing with various transport technologies forming specific

technological domains, the project faces the question of multi-domain slices orchestration.

The proposed 5G-Crosshaul architecture is shown in the Figure 5. It applies the principles of

decoupling of data and control planes, logically centralized control and exposure of abstract

resources and their states to external applications. In the control plane the ETSI NFV architecture

with MANO (NFVO/VNFM/VIM with plugins for controlling SDN, storage and computing

resources via 5G-Crosshaul or Non-5G-Crosshaul/legacy interface) is applied. The architecture

vision assumes a ‘domain-based approach’ and the transport domain (5G-Crosshaul domain)

control plane (5G-Crosshaul MANO, XCI – Crosshaul Control Infrastructure) interacts with 5G core

and 5G access MANOs via WBI and EBI respectively. The NBI (providing programing and

monitoring the underlying data plane by a common set of core services and primitives) is an API

for series of higher layer applications, in fact, constituting the E2E business orchestrator. The

vision of 5G-Crosshaul architecture assumes existence of autonomous legacy control functions

e.g. like MPLS/GMPLS.

In the data plane, the transport network functions will be accomplished with 5G-Crosshaul

forwarding/processing elements (as VNFs) or non-5G-Crosshaul NEs (legacy infrastructure, e.g.

radio links) controlled by XCI via its SBI. The SBI will allow the following functions:

• control and management of packet forwarding within the 5G-Crosshaul network across its

forwarding elements;

• control and management of physical layer settings of different link technologies (e.g.

transmission power on wireless links);

• control and management of 5G-Crosshaul processor units computing operations (e.g.

instantiation and management of VNFs).



Figure 5 – 5G PPP 5G-Crosshaul high-level architecture [8]

From the functional point of view, the data plane (see: Figure 6) will be composed of three layers:

• the lowest one, corresponding to overlay of all infrastructure layers, is composed of:

o interconnection plane, formed by networking infrastructure providing the higher planes a

connectivity with heterogeneous links; composed of packet forwarding elements creating

a unified packed-based network;

o general processing plane, serving for VNFs (e.g. BBUs, CDNs) located in processing units;

o end-point plane, formed by 5G network architecture elements or functions, utilizing the

5G-Crosshaul transport (e.g. RRHs, eNodeBs, core network functions in operators’ POPs

• the middle layer visualizing the common packet network based on technology abstraction,

unified framing and common data and the control and management planes; the unified

abstract view covers different technologies underneath (fronthaul and backhaul) and enables

exposure of the integrated transport network;

• the upper layer referring to functional features requested from the services of transport

network infrastructure: (1) reconfigurability – dynamic allocation of capacity or rerouting of

traffic, reallocation of resources (both networking and processing as well, e.g. dynamic NFV

relocation) between busy and idle areas in order to satisfy demands changing in time or

provide inter-domain optimization (e.g. RAN and transport) or preserve SLA obligations; (2)

energy efficiency – drowsing, de-activating or decommissioning dynamically the underused

network parts in order to reduce the energy consumption by transport network elements,



may be combined with the joint optimization of RAN and transport network resources; (3)

multi-tenancy/network slicing support – enabling recursive multi-tenancy (especially recursive

XCI architecture) for homogeneous way of sharing of heterogeneous underlying

infrastructure, the concept of introduction of ‘partitioner/slicer’ component at each

forwarding element is considered; these features will be exposed via NBI API to higher level

applications indicated in the Figure 5.

Figure 6 – 5G PPP 5G-Crosshaul functional structure [6]

The abovementioned applications built on top of XCI may cover: transport network resource

management, multi-tenancy (slicing) management, energy management, CDN management,

mobility management (for nodes in motion, e.g. high-speed trains), MEC management,

broadcasting management (media distribution) and others based on NBI (XCI API) services.

3.3.2. 5G Exchange

The 5G Exchange (5GEx) project aims to enable E2E and cross-domain orchestration of services

(multiple technology domains or administration/ownership domains as well) in multi-vendor

environments. Such orchestration tool should provide provisioning of services in automated way

and able to interact with resources exposed by various operators to one common market of

services of interconnected heterogeneous infrastructure delivered by infrastructural providers

and commercially used by service providers. This automation is expected to allow E2E feasibility

check, provisioning and validation in a timeframe of tens of minutes instead of current timeframe

of tens of days.

The project has defined a series of use cases grouped in three categories: connectivity, VNFaaS

and NSaaS. The mid one contains the generic case of network slicing, i.e. delivering separated

logical virtual partitions allowing homogeneous control independently of the ownership of the

underlying heterogeneous networks (NFV/SDN-based, but also legacy ones). The last category

defines three cases of various degree of complexity: ‘IaaS’ (VMs + associated storage +

connectivity), ‘GiLAN/roaming’ (network slicing + remotely controlled VNF placement) and ‘My

Cloud Anywhere’ (user location changes entailing dynamic rearrangement or even spatial

migration of provisioned network following user’s trace).

The proposed 5G-Ex high level framework is shown in the Figure 7. The focal point is the multi-

provider multi-domain management and orchestration. The entire reference framework



containing all involved components and interworking interfaces consists of resource domains and

their respective (Single-/Multi-) Domain Orchestrators performing resource and/or service

orchestration; Multi-provider Multi-domain Orchestrator (MdO) coordinating resource and/or

service orchestration at multi-domain level (multi-technology orchestration of resources and/or

services using multiple Domain Orchestrators or multi-operator orchestration of resources and/or

services using Domain Orchestrators belonging to multiple administrative domains). There are

three 5G-Ex APIs defined: � for interactions between business customers and MdOs (Business-

to-Customer, B2C) in order to specify the business customers’ requirements for services; � for

interactions between different MdOs (business-to-business, B2B) in order to request and

orchestrate resources and services across different administrative domains; � for interactions of

MdOs with Domain Orchestrators to orchestrate resources and services within the same

administrative domains. The MdO may also belong to 3rd party service providers not having their

own resource domains but operating multi-domain orchestrators (brokers/resellers of resources

and services owned by other providers).

Separation of contexts of APIs � and � (multi-domain context and local context), even if the

technical definition of both interfaces may be exactly the same, provides manageability of

resources/services exposed to the ‘wholesale market’ (selectiveness of what can be drawn out to

other MdO operators) and confidentiality of local infrastructure details still ensuring flexibility for

every actor of the picture. In case the definition of APIs � and � is exactly the same, the

architecture model has inherent recursiveness (refer to the case of 3rd party MdO). Indeed, as the

services exposed at the levels � and � are CFSes (according to TMF methodology) and the

‘know-how’ (mapping to RFSes and their decomposition to Rs) is accomplished at the level of

domain orchestrator, these CFSes (defined as commonly understood abstract ‘black boxes’) can

be recursively bundled or unbundled subsequently within the MdOs hierarchy.

Figure 7 – 5G PPP 5GEx reference architectural framework [9]



The foundation of 5G-Ex orchestration is ETSI NFV-MANO, however it is extended in order to

enable multi-domain and multi-operator orchestration. According to 5G-Ex approach, the

network service orchestration part covers OSS-BSS, VNF and EM area. Thus, service orchestration

means configuration of parameters within VNFs and provisioning their proper interactions. The

resource orchestration focuses on NFVO and VIM part. Building a multi-domain architecture

means setting new inter-operator interfaces and defining interactions between Multi-provider

MdO and distant: Inter-provider NFVO (implementing multi-provider service decomposition),

VNF Manager, Element Managers (responsible for FCAPS of VNFs), SLA Manager (responsible for

reporting on the performance of its own part of the service), Service Catalogue, Topology

Distribution (exchanging topology information with peer MdOs, to be included in the Resource

Topology Repository) and MD-PCE (Multi-domain Path Computation Element as defined by IETF).

The functional model of 5G-Ex concept of multi-domain orchestration, explaining both E2E and

N2N relations is shown in Figure 8. The basic relation is N2N and publically available information

about basic inter-provider topology and optionally service catalogue information may be

distributed hop-by-hop to all or predefined group of providers. This information supports initial

mapping of the multi-provider NFVO orchestration process and depending on provider policies

may also include more detailed provider internal topology, IT resource capability/location and

access information of orchestration interfaces. The extended, bilateral communication in E2E

customer-provider relationship model is intended to provide extended bilateral business

information exchange which is invisible for 3rd parties.

Figure 8 – 5G PPP 5GEx functional model of multi domain orchestration [9]

3.3.3. METIS II

The project METIS II (Mobile and wireless communications Enablers for Twenty-twenty (2020)

Information Society-II) is focused on RAN part of 5G network. Its objectives include development

of overall RAN design integrating evolved legacy and novel radio access technologies in order to

build one future holistic wireless communications system.



The METIS II approach [10] follows the vision of NGMN (‘5G RAT family’), ITU-R (IMT-2020) and

3GPP (TR 22.891, TR 23.799) and includes the fundamental assumptions and techniques like

functional split between RAT and CN, SDN, NFV, orchestration and E2E network slicing (RAN +

CN, where each slice may have its own set of CN functions, i.e. specific service architecture both

in CP and UP) into the focus of the project.

The RAN design requirements relative to Network Slicing are:

• Traffic differentiation: The RAN should support mechanisms for heterogeneous services traffic

differentiation and fulfilling stricter and more sophisticated QoS requirements than legacy

systems;

• Slice-aware RAN: slices should be visible to the RAN CP to enable a treatment satisfying the

requested slice-specific constraints, metrics or E2E QoS of all services within a slice (slice-

specific SLA);

• Slice protection and isolation: the performance of one slice must not affected by the operation

of another slice, existing 3GPP mechanisms (Access Class Barring, Enhanced Access Barring,

Service Specific Access Barring, Application-specific Congestion control for Data

Communication) to be adapted for slice-specific functions;

• Slice management and setup: efficient management mechanisms to efficiently setup and

operate slices, including dynamic activation/deactivation and parametrization – E2E

orchestration mechanisms necessary;

• Slice-specific network management: the RAN should provide slice-specific network

management functions as a service (individual FCAPS for SLA fulfillment verification, SON, etc.

for slice);

• Slice selection and multi-slice connectivity: supporting of mapping specific UE device to

specific slice and involvement of a single UE device in multiple slices;

• 5G Air Interface design incorporating APIs to higher layers: facilitating the implementation of

network slicing (both on device and network sides).

The network management and orchestration concept in METIS II follows the 5G PPP Working

Group ‘Architecture’ vision incorporating native SDN/NFV-based multi-layer architecture

covering UE devices, infrastructure, network functions up to the E2E Management and

Orchestration (5G PPP MANO) functions needed to orchestrate the entire 5G system within a

specific slice. The 5G PPP MANO is based on commonly recognized principles of ETSI, but goes

beyond current ETSI specifications in some aspects, especially for the RAN part, to achieve

required slice flexibility and programmability). The required features of METIS II MANO include:

(1) decomposition of business requests into particular network services within network slices, (2)

further decomposition of service flows into SLA-specific NFs, (3) parametrization of NFs

configurations following the requested SLA and other constraints and (4) finally mapping this

virtual network (slice) architecture onto the available infrastructure (radio/transport network,

computing and storage resources, RF units/resources). Especially for RF resources (physical

equipment, spectrum) the dynamic inter-slice coordination is highly required in order to fulfill the

requirement of slice protection within a pool of limited resources shared among multiple slices.



3.3.4. 5G NORMA

The project 5G NORMA is aimed at development of a customizable 5G mobile network

architecture with adaptability to handling portfolios of services and patterns of traffic changing in

time and with adaptability to future trends (including growing expectations about performance,

security and cost or energy efficiency), especially focusing on 3GPP roadmap adoption.

The 5G NORMA architecture principles are:

• Network customization by adaptive allocation of network functions and service specificity-

oriented network architecture;

• Service-aware resource sharing with network slicing for network multi-tenancy;

• Network programmability for flexible network control;

• Separation between dedicated and common NFs both in CP and UP;

• Full integration of PNFs and VNFs within the overall architecture;

• Split of Data/Control/MANO/Service layers;

• Hierarchical orchestration – ETSI NFV MANO-based, extended to accommodate network

slicing needs and inter-slice E2E service orchestration (5G-NORMA-MANO);

• Joint optimization of mobile access and core network functions.

These principles of 5G NORMA mobile network architecture entail specific concept of the

underlying environment of shared infrastructure, multi-tenancy management and slice/E2E

service orchestration (see Figure 9).

The actual mobile network is composed of control and data layers (CP and DP) composed of one

set of common functions (referred as a ‘common slice’) and multiple sets of dedicated functions

(called ‘dedicated slices’). Common slices may include both PNFs and VNFs. Except ‘canonical’

CP-NFs both in common and dedicated slices there are defined Software-Defined Mobile

network (SDM) Controller functions (called SDM-C for the dedicated functions and SDM-X for the

common functions). These controllers deal with MANO layer via their NBIs and with their own

NFs (CP and UP) via their SBIs. Their role will be explained later.

The MANO layer is composed of (1) EMs (performing FCAPS) and their ‘overlay’ OSS (legacy

functions, but VNF-aware) managing the actual 5G network and (2) 5G-NORMA-MANO domain

for E2E network orchestration and lifecycle management. The idea of 5G-NORMA-MANO

incorporates a constellation of ETSI NFVI-MANO objects instances: NVF-Os called ‘Slice

Orchestrators’ (each dedicated for a single CP+UP slice, either common one or dedicated ones),

VNF-Ms (one per vendor) and VIMs (one per cloud). These instances are owned and operated by

the respective owners of slice service/infrastructure. Additionally, the E2E slice instances are

instantiated by the Service Orchestrator (owned and operated either by slice tenant or slice

service provider). Its tasks are service function chaining (decomposing a service request to a set

of network services and their related SLAs/KQIs) and choosing the way of implementation (re-

parameterization of existing slices, their reconfiguration by amending service chains or creation a

new slices) based on business and policy decisions.



Figure 9 – 5G NORMA functional reference architecture [11]

The gateway for E2E slice Service Orchestrators is the Inter-Slice Orchestrator (or Orchestrator

Manager) operated by slice service provider. It’s not only a dispatcher. Having a comprehensive

view of underlying resources (aware of a ‘principle of communicating vessels’ within the

underlying infrastructure) and service requests’ requirements is able to handle the process of

dynamic provisioning of the slices and resource sharing management, coordinating globally the

resource allocation to slices/tenants in order to avoid requirements conflicts between slices

(especially slices belonging to different tenants). Additional Inter-Slice Orchestrator can be

considered on top of the one belonging to slice service provider for the tenant who wants to

have autonomy of optimization of resources among slices and/or has several slice service

providers.

The SDM Controller is a key function in 5G NORMA concept. Every single slice (both common

one and dedicated ones) has its own SDM Controller instance, translating decisions of the

higher-level control applications into commands to PNFs (in case of common slice only) or VNFs

within the specific slice and controlling these NFs’ performances. The NBI exposed to MANO

layer serves for ‘VNF insert/VNF reconfigure’ functions and management of resources assigned to

the network slice, especially in order to satisfy QoE/QoS targets (if they can’t be met, the SDM-C

may request re-orchestration). The SDM-X (controller-coordinator of the common slice) is

additionally responsible for coordination of access of all the controllers of dedicated network

slices that use common NFs the E2E chain and resolving potential conflicting requests.



It should be noted, that despite the fact, that 5G NORMA is nominally dedicated to entire mobile

network architecture (AN+CN), the applications of SDM-C/SDM-X listed in [12] focus on RAN

part of 5G network and affect the following NFs: SON, RAN Paging, eMBMS Control, NAS Control,

RRC Slice, eICIC (in case of SDM-C) and Multi-tenancy Scheduling (RRC and ICIC schemes), mMTC

RAN Congestion Control, QoS Control of radio stack (in case of SDM-X).

3.3.5. 5G SONATA

The project 5G SONATA [13] aims at design and implementation of NFV framework that provides

developer’s tools, workflow and programming model for virtualized network services. The core

objectives of SONATA consortium is to reduce time-to-market and costs of network services

deployment and operation, optimize network resources and stimulate industry to make a

transition to SDN- and NFV-based software networks.

The NFV SONATA framework is integrated with DevOps platform and orchestration system. In

fact, 5G-PPP SONATA is not strictly dedicated to network slicing approach. However, one of the

innovations of SONATA system is a support of 5G slicing. The major purpose of SONATA is

providing modular, customizable, interoperable, vendor agnostic, ETSI-based MANO framework

implementation, that supports both resource and service orchestration. The system is expected to

enable network service developers to use a Software Development Kit (SDK) and NFV DevOps

platform for creation, deployment and maintenance of VNFs.

The SONATA SDK supports:

• generating network function and network service descriptions;

• packaging the functions;

• debugging and testing (debuggers, model checkers and validators for service patterns,

emulators for executing trial runs of services);

• deployment to SONATA test and production platforms;

• analytics of monitoring data (direct feedback about the deployed services from the SONATA

Service Platform to the SDK).

The SONATA Service Platform is an extended implementation of ETSI NFV-MANO NFVO and

VNFM parts (keeping all referential MANO interfaces) cooperating with external VIMs. The

mapping of SONATA Service Platform onto ETSI NFV-MANO architecture is shown in Figure 10.

The SONATA service platform is functionally divided into service orchestration (NFVO) part and

VNF lifecycle management part (VNFM). The additional Gatekeeper module is responsible for

bidirectional mediation with the environment and the repositories serve the essential parts of the

platform. The service packages implemented and created within the SONATA SDK can be placed,

deployed, provisioned, scaled and managed on subordinated cloud infrastructures. These service

packages can be sent together with Service-Specific Managers (SSMs) or Function-Specific

Managers (FSMs), i.e. service- or function-specific lifecycle management requirements and

preferences (e.g. desired placement or scaling behavior).



Figure 10 – SONATA Service Platform functional architecture mapped onto ETSI reference

architecture [14]

The list of basic platform action scenarios include: uploading/starting a service package (fetching

from the SDK, first deployment and starting), receiving monitoring feedback, service scaling,

pausing a service (temporary suspension), restoring a paused service, terminating a service.

The slice management is supported by a specific SONATA module, a Slice Manager. This is a

plugin, which can be externally accessed via the Gatekeeper, i.e. a tenant can request a

specifically defined slice properties or an existing slice. The Slice Manager supports two models:

(1) nested (recursive) – considering a slice as a specific type of service that can be chained and

thus allowing embedding a separately managed slice within another slice and (2) flat – more

advanced – where both slices and services within them are managed by the same SONATA,

avoiding redundant resource consumption for nested instances by tenants.

The basic application of the SONATA service platform is its placement on top of underlying cloud

infrastructure. However, it is also possible to place the SONATA system on top of another

SONATA platform, building a recursive hierarchical model of infrastructure. This is achieved with a

proper plugin installed in the Gatekeeper.



3.4. ITU-T IMT-2020 FG architecture

In 2012, the International Telecommunication Union (ITU) has launched the roadmap for research

into 5G under the official name – IMT-2020. Current activities of the ITU-T Focus Group resulted

in five draft ITU international standards and four draft ITU technical reports to outline the

requirements of the overall 5G network vision. The network slice is defined by IMT-2020 FG as

‘(...) a managed group of infrastructure resources, network functions and services. Network slice is

programmable and has the ability to expose its capabilities. The behavior of the network slice

realizes via network slice instance(s).’ [15].

The document [16] provides an outstanding overview of ongoing network softwarization

activities, including open-source projects, standardization efforts and research projects. First of

all, the 3GPP SA2 activities have been widely described and 3GPP SA1 requirements have been

summarized, what has resulted in major network softwarization requirements. These are:

separation of user and control plane, applying SDN and NFV for cost effectiveness, support of

network capability exposure and support of network slicing. Apart from 3GPP research, the

document includes also report on ETSI NFV, ETSI MEC, ETSI NTECH AFI WG (GANA reference

model with Autonomic Management & Control framework for network and services), IETF Detnet,

IETF Service Function Chaining and OIF Flexible Ethernet activities, as well as open-source

projects related to network softwarization such as O3 and Open-O orchestrators,

OpenAirInterface, OPNFV and ONOS SDN Controller. Further, the need for Operating Platform for

Network softwarization – a lightweight execution framework for Virtual Network Function and

Services – is pointed out. There is no well-known and widely accepted Operating Platform

solution, but it is expected to be based on open-source tools such as OpenStack, OpenDayLight,

ONOS, MANO, TOSCA, etc. IMT-2020 Focus Group introduces also two types of network slicing

extensions: vertical and horizontal. The former defines an interface between the orchestrator and

virtual resources management function. This reference point shall be used to perform life-cycle

management of network slice instances. Moreover, data plane programmability concept has been

proposed to enhance interaction between networks and applications, enhance flexibility and

optimization of network functions and to enable a rapid development of new network protocols

such as ICN. The horizontal extension of network slicing is related to capability exposure

functions of network slice and its APIs, what will allow 3rd parties to manage and customize slices,

that belongs to them. Authors propose to realize capability exposure functions and API-based

communication in hierarchical way in order to compose E2E orchestration framework.

Major requirements and design goals of IMT-2020 Focus Group has been described in [17]. The

design goals contain:

• Service diversity, including diversity of QoS requirements, diversity of UE mobility and service

continuity and support for both IP and non-IP solutions (diversity of user data types);

• Functional flexibility and programmability;

• Converged access-independent and unified core network;

• Separation of Control and User Plane;

• Distributed network architecture in order to reduce backhaul and core network traffic;



• In-network data processing to reduce network congestion and user’s Quality of Experience;

• Unified intelligent network management – it should provide automated procedures to reduce

complexity of network operation & management systems;

• Optimization by performing adaptive data routing based on actual network’s condition

• Reliability and security;

• Energy efficiency.

The requirements have been divided into two categories: from service point of view and from

network operator point of view. The former category of requirements is related to new services

that are expected to be deployed along with 5G system such as eMBB, enhanced mMTC and

uRLLC applications. The latter provides numerous architectural principles. Most of them are in

line with design goals, but some additional requirements have been stated such as flexible

signaling (service-tailored signaling procedures) or interworking between LTE and IMT-2020

system.

Figure 11 – Softwarized network architecture view for IMT-2020 [18]

Figure 11 presents softwarized network architecture view for IMT-2020. At the bottom of the

architecture view there lies physical network infrastructure composed of network, computing and

storage resources. These resources comprise E2E telecommunication infrastructure including UE,

radio access, mobile fronthaul/backhaul, transport networks and data centers. On the top of

virtual infrastructure multiple slices can be created. A network slice can be decomposed into UE,

Radio Access Network (RAN), mobile packet core and central cloud. All the virtual network

functions, which comprise E2E network slice, can be controlled via exposed to 3rd parties, app-

driven APIs. The network and orchestration entity enables creating slices,

The document [19] describes design principles and IMT-2020 network architecture. The main

principles are:



• flexible placement of UP and CP functions (centralized or distributed),

• access network agnostic common core network,

• support of different levels of UE mobility,

• service-tailored latency between UE and the Data Network,

• support of network slicing, capability exposure and unified authentication framework,

• abstraction of transport domain to support various transport technologies,

• leveraging SDN and NFV as key enablers.

The high-level IMT-2020 framework architecture is comprised of 4 planes: resource, control,

application/service and management plane. Application plane is responsible for orchestration

and support of network softwarization, so it provides network capabilities APIs. Control plane

provides resource abstraction to support unified programmability of resources. It is assumed that

resource plane is programmable and allows Control Plane entities to dynamically modify/update

Data Plane processing and transport functions. The management plane has an interface to

manage external systems such as MANO, 3G/4G NMS/BSS, etc.

Core network architecture is comprised of underlying resources, data plane, control plane, service

plane, management plane and applications on the top of all the planes.

Control plane has been decomposed into following functional blocks:

• NSSF (Network Slice Selection Function) – responsible for core network slice selection for UE;

• MMCF (Mobility Management Control Function) – provides mobility support and functions

such as session continuity, UE registration and location management and routes NAS

signaling;

• SMCF (Session Management Control Function) – establishes IP and non-IP connectivity for

UE, handles policy and charging rules and allocates UE IP address, etc.;

• UACF (Unified Authentication CF) – provides authentication of the user identity;

• SIDB (Subscriber Information DB) – stores and manages subscriber-related information,

session context, etc.;

• PCRF – dynamic policy for QoS enforcement;

• QSCF (QoS Control Function) – provides E2E QoS (per flow, per user, etc.) with desired QoS

demands.

The data plane function is defined as UPGW (User Plane Gateway) and provides forwarding and

session anchor functionalities.

There are still several open issues that have been unresolved by IMT-2020 FG, such as whether

NSSF belongs to RAN or Core Network set of functions or how UE and CN should interact to

choose Network Slice Instance.

The document [20] describes various deployment scenarios of IMT-2020 system and required

enhancements to Network Management System. One of the key requirements for eNMS is



design of standardized device management protocol between logically centralized NMS and all

network equipment distributed in heterogeneous environment. That will allow operator to be

aware of all managed devices and to optimize management procedures without using complex

protocols and procedures.

The IMT-2020 focus group provides valuable requirements analysis, potential solution research as

well as a high-level 5G software network architecture. However, IMT-2020 Focus Group has

ended their activities in December of 2016, thus technical report drafts become outdated and the

newest trends of network slicing and softwarization are not brought up.

3.5. IETF slicing

The IETF organization has published several drafts related to network slicing. More importantly,

they have formed a working group named ‘NetSlices’, which is responsible for network slicing

research. In [21] the goal of activities is described in the following way: ‘the purpose of the NS

work in IETF is to develop a set of protocols and/or protocol extensions that enable efficient slice

creation, activation/deactivation, composition, elasticity, coordination/orchestration, management,

isolation, guaranteed SLA and safe and secure operations within a connectivity network or network

cloud/data center environment that assumes an IP and/or MPLS-based underlay’. The ‘Autonomic

Slice Networking – Requirements and Reference Model’ (ANIMA) [22] defines fundamental terms

related to network slicing and provides high-level reference model. The ANIMA concept assumes

that a one slice covers an E2E network infrastructure including the radio and non-radio domains

inclusive of access, core and edge/enterprise networks. The network slicing is defined as a

concept that ‘enables the concurrent deployment of multiple logical, self-contained and

independent shared or partitioned networks on a common infrastructure platform’. The ANIMA

document describes the reference model of Autonomic Networking approach for E2E network

slicing. In ‘Network Slicing – Introductory Document and Revised Problem Statement’ authors

provide revision of network slicing problem statement and potential work areas such as Uniform

Reference Model, Slice Templates, network slice capabilities (e.g. programmability and control of

network slices) and slice operations (e.g. life-cycle management, slice stitching/composition). The

‘Network Slicing – 3GPP Use Case’ provides analysis of 3GPP approach to 5G System including

split slice planes into common and dedicated parts, S-NSSAI slice identification, RAN slicing,

management and orchestration aspects, virtual infrastructure and security. This document is very

valuable brief overview of 3GPP activities on 5G network slicing. Its purpose is to analyze 3GPP

5G System architecture in order to enhance IETF protocols to be applicable for 3GPP network

slicing concepts.

3.6. 3GPP activities on network slicing

The first 3GPP document related to network slicing was titled ‘Architecture Enhancements for

Dedicated Core Networks’ [23], known as DÉCOR and introduced in 3GPP Release 13. The

assumption is that an operator deploys several dedicated Evolved Packet Cores (EPC), that share

the same Radio Access Network and each EPC is tailored to support a specific type of mobile

service. The purpose of DÉCOR is to specify, how users can exploit different dedicated packet



cores with no impact on UE. Besides, networks deploying DÉCOR may have a common core

network (CCN), which may be assigned to UEs when a dedicated core network (DCN) is not

available. Initially, the mobile terminal could be attached to the CCN and meanwhile redirected to

be served by DCN. So, network shall enable the redirection of affected attaching/attached UEs to

appropriate DCN.

The 3GPP TR 23.707 [23] evaluates architectural enhancements that allow a mobile terminal to

select dedicated MME (or in general a Dedicated Core). A new Subscription Information

parameter is introduced and stored in the Home Subscriber System (HSS) with name ‘UE Usage

Type’. This value should indicate the usage characteristics of the mobile equipment. Such

approach lets operators to configure each specific type of subscriber to use service-tailored

Dedicated Core Network (DCN), without any modification of the User Equipment (UE). During the

attach procedure UE contacts the default MME, then the UE is redirected to the dedicated MME

based on ‘UE Usage Type’ retrieved from HSS. The dedicated MME is responsible for choosing

the appropriate S-GW and P-GW that belong to a specific slice (DCN).

The key disadvantage of DÉCOR is that it supports only one slice to be used by UE at the same

time. We can imagine that there are devices that need sometimes to make use of other slice. For

instance, a smartphone can act as a terminal for mobile communication as well as an IoT node at

another time. So, it needs to use different types of slice during one subscription period. The

DÉCOR approach is an enhancement of existing LTE networks and cannot be treated as full-

fledged network slicing solution.

In the release 14, the 3GPP started to work on TR 23.799 ‘Study on Architecture for Next

Generation System’ (NextGen) [24]. The document lists the key features relevant to design of new

architecture for next generation networks. In conclusion the final agreements for each of the

expected features are stated and the overall NextGen system architecture is proposed. Support of

network slicing is treated as one of the key feature and is noticed as an enabler to provide

networks on as-a-service basis and meet the wide range of use cases. Technical specification of

network slicing is expected to be standardized in release 15 (Phase 1). Besides network slicing,

the list of key features contains QoS framework, mobility management, session management,

session and service continuity, efficient user plane paths, network functions granularity and

interaction, network capabilities exposure, policy and charging framework, security, network

discovery and selection, interworking and migration and NextGen core support for IMS.

Network slicing is defined by 3GPP as a concept that allows multiple logical networks to be built

on the top of common shared physical infrastructure. In the document three groups (types) of

network slicing is considered. Group A assumes that UE obtain services from different, fully-

isolated Core Network instances through a shared access network. This type of solution is similar

to the DÉCOR approach. Group B that there exists some part of network functions (NFs) that are

common to multiple network slice instances, but there are also some dedicated, slice-specific

NFs. Group C assumes that control plane functions are common for all the network slices

instances, while user plane functions are dedicated. Group A will not be pursued in release 15.



Figure 12 – Deployment scenarios of network slicing concept (3GPP) [24]

Foregoing work brings in several potential solutions related to network slicing functions e.g. slice

selection. Generally, chapter 6 of TR 23.799 should be treated as a brainstorming document only.

We refer to this document as there is a collection of different potential solutions for each of key

issues and some of them may be applied in our 5G!Pagoda architecture. However, the final

conclusions related to network slicing stated in the chapter 8 of TR 23.799 are a basis for TS

23.501 that is described later. The most relevant assumptions of the mentioned report are

following:

• Network slice is a complete logical network including RAN and core network. However, RAN

aspects are still under investigation.

• The UE may provide set of parameters in the form of NSSAI in order to indicate Network Slice

Instance preferences. The NSSAI is provided to network in RRC and NAS. Additionally, UE

capabilities and subscription data may be used in the process of slice selection.

• There is a set of Common Control Network Functions (CCNF) that includes Access and

Mobility Function (AMF) and Network Slice Instance Selection Function (NSSF). The CCNF

enables simultaneous access to multiple slices via a single RAN for particular UE.

• Selection of slice instance is performed by Core Network Functions, not by RAN.

• Handover from a slice in NGC to a Dedicated Core Network (DCN) in EPC should be possible.

• UE should be able to establish and use different, parallel PDU sessions that belong to

different network slices.

• It should be possible for network functions to change the set of network slice instances

accessible for particular UE during ongoing session.

• The CCNF should be able to redirect an attach request to another CCNF via RAN or direct

interface with another CCN.

3GPP RAN Working Group has started research on RAN slicing concept. Document [25] provides

conclusions from TR 23.799 in the area of RAN. The basic principles assume RAN awareness of

slices, what means that based on pre-configured policy RAN should be able to differentiate traffic

handling and QoS for different network slices. Beside, RAN shall select the RAN part of network

slice based on S-NSSAI. Single RAN shall be able to support multiple slices and resource

management policy enforcement based on SLA. However, despite UE connection to multiple

slices simultaneously, only one signaling connection should be maintained. According to resource

management RAN shall be able to provide resource isolation between slices. One important RAN



feature is slice availability. Due to some network slices may be unsupported in some parts of

networks, base stations should be able to exchange information about supported network slices

and RAN shall obtain list of slice availability from the core network. In conclusions, there are rules,

how RAN should select appropriate CCNF of core network. It should be done based on Slice ID

and Temp ID from RRC. If Temp ID is invalid or N/A and Slice ID is N/A default CCNF shall be

selected. If Temp ID is invalid or N/A, but Slice ID is present RAN shall select CCNF that supports

requested Slice ID. If Temp ID is present and valid, regardless of Slice ID, RAN must select CCNF

based on identity information in Temp ID.

In March 2017 3GPP has released the first version of TR 28.801 in release 15 entitled ‘Study on

management and orchestration of network slicing for next generation network’ [26]. This

document focuses on life-cycle management of Network Slice Instances (NSI) in NextGen

architecture. The lifecycle is fragmented into four phases:

• Preparation – the phase before the Network Slice Instance is created. At this point the

network slice Blueprint should be defined and the network environment should be prepared.

• Instantiation, Configuration and Activation – during this phase the network resources for

Network Slice Instance are allocated and (virtual) network functions are deployed across the

network environment. All the network resources and functions should be configured and

activated to put the NSI into ready for operation state.

• Run-time – the NSI is on and is able to serve users attached to a network slice. During this

phase maintenance operations may be performed such as upgrade/reconfiguration of NSI,

scaling of NSI or changes of NSI capacity and topology.

• Decommissioning phase – in this phase NSI is deactivated and terminated.

PreparationInstantiation, Configuration, and

Activation

Pre-provision

Network environment

preparation

Instantiation/

ConfigurationActivation

Run-time Decommisioning

Termination

Lifecycle of a Network Slice Instance

De-

activation

Supervision

Reporting

Upgrade/

Reconfiguration/

Scaling

Design

Figure 13 – 3GPP Network Slice Instance life-cycle management phases [26]

This approach takes into account also Physical Network Functions (PNFs), apart from Virtual

Network Functions (VNFs) and allows an E2E network service to be composed of several Network

Slice Instances (NSI), even of different slice types. Moreover, NSI may be only partially isolated

from other instances, so there may exist common network functions shared among several

Network Slice Instances. In general, basic assumptions are as follows:

• Network slice instances may be fully or partly, logically and/or physically isolated from each

other.

• The resources comprise of physical and logical resources.

• Network Slice Instances are defined by a Network Slice Template (NST).



• Instance-specific policies and configurations are required when creating a network slice

instance.

• Network characteristics examples are ultra-low-latency, ultra-reliability, etc.

The Network Slice Instance may be composed of several Network Slice Subnet Instances (NSSIs),

which may be treated as sub-slices. The life cycle of a NSSI is independent of the life cycle of a

network slice instance(s) served by the network slice subnet instance. Similarly to Network Slice

Instance NSSI comprises of physical and logical resources. NSSIs may be shared by one or more

NSIs and may be associated with one or more NSSIs. According to the network slice

management, several issues have been addressed, i.a. how to perform FCAPS management of

network slices, how to apply Self-Organizing Network (SON) concept, how the network slice

components should be orchestrated and how to orchestrate network slices across multiple

domains. These problems are expected to be resolved in next versions of TR 28.801.

Figure 14 – Network Slice related information model [26]

Furthermore, in the version 1.1.0, TR 28.801 includes high-level operations for particular use cases

and outlines potential requirements related to slice life-cycle management, FCAPS management

of slices, slice monitoring, etc. They also address multi-domain, multi-operator aspects of

network slice orchestration by proposing three variants of NSI creation across multiple domains

managed by various operators. These options are described from a business point of view and

provide scenarios of interactions between customer, Network Slice provider and Network Slice

Subnet provider.

Communication Service Provider (CSP) Domain

Netw ork Operator (NOP) Domain

Network Slice

Network Slice

Subnet

Network Function

Communication

Serv ice

Core Network

Function

Access Network

Function

0..*

contains

0..*

0..*

contains0..*

0..*

contains0..*

0..*

uses

0..*



The 3GPP Technical Specification 28.500 [27] provides management concepts and requirements

from operator’s point of view. These are related to mobile networks that include VNFs as a part of

EPC or IMS. The management architecture for virtualized mobile networks has been proposed in

the context of ETSI MANO framework. The architecture shown in Figure 15 extends ETSI MANO

to support also existing physical network functions (PNFs). System design assumes that legacy

3GPP Management System entities – NM, EM and DM – may take participation in process of

management of both Physical and Virtual Network Functions. NM acts as OSS/BSS and interacts

with NFVO. It may initiate life-cycle management of ETSI-defined VNFs and Network Services.

EM/DM is responsible for application-level FCAPS management of VNFs and domain- and

element-level management of PNFs. EM/DM may also interact with VNF Manager during life-

cycle management of network functions.

Figure 15 – The mobile network management architecture mapping relationship between

3GPP and NFV-MANO architectural framework [27]

The TR 28.801 is the first 3GPP document about the management and orchestration framework

for network slicing. It provides requirements on life-cycle management procedures and analyzes

important aspects such as multi-domain orchestration, multi-domain management and FCAPS

monitoring and management for network slices. The vision of management and orchestration

framework for 3GPP Management Systems presented in TR 28.500 is complement to the TR

28.801.

The TS 23.501 [28] provides the Stage 2 system architecture for the 5G System, which provides

data connectivity and services. The document contains architecture model and concepts, network

functions description, roaming and non-roaming scenarios, interworking between EPS and 5GS,

policy and charging, mobility and authentication and security aspects. The 5GS architecture is

based on principles stated in the previous TRs e.g. separation of user and control plane. An

important novelty is transition from ‘network of entities’ reference model into a ‘network of

functions’ system. Thereupon, 5GS defined by 3GPP should provide stateless, modular and



interactive with each other network functions to enable flexible and efficient network slicing.

Additionally, such requirements as minimization of dependencies between Access Network and

Core Network or support of concurrent access to local and centralized services have been stated.

The 5GS draft specification allows to implement network in legacy (based on reference points)

way or using micro-service framework with communication based on common message bus. The

chapter 5.15 of TS.501 describes network slicing feature of 5GS. The Core Access and Mobility

Management Function (AMF) is logically common to all of the Network Slice Instances (NSI) and

is responsible for handling mobile users. Also, the network slice selection function is a part of

common control plane. The UE PDU session may belong to only one NSI per PLMN and it’s

agreed that dedicated Session Management Function (SMF) will handle PDU session of Network

Slice Instance.

Figure 16 – 3GPP 5GS service-oriented architecture [28]

Figure 17 – 3GPP 5GS architecture – interface view [28]

Network Slice Instance is identified by Single Network Slice Selection Assistance Information (S-

NSSAI), which is composed of Slice/Service Type (SST) that describes type of service, which



network slice is tailored to and Slice Differentiator (SD) – the optional information that may be

used to differentiate network slice instances of the same service type. PLMN may customize S-

NSSAI. Some of the Network Slice Instances may be marked as default and associated with

default S-NSSAI.

User Equipment may contain pre-configured S-NSSAI stored in local storage that is called

‘Configured S-NSSSAI’. During initial registration UE may request access to specific Network Slice

Instance by proposing ‘Requested S-NSSAI’. Upon successful registration, UE may obtain from

AMF a list of ‘Allowed S-NSSAI’ for serving PLMN. List of Allowed S-NSSAIs should be stored by

UE and may be modified by network during registration period. IF UE has at least one Allowed S-

NSSAI in local storage, it should put it together with Configured S-NSSAI in Requested S-NSSAIs.

However, Allowed S-NSSAI is prior to Configured S-NSSAI.

The document TS 23.502 [29] describes detailed system procedures. The support of network

slicing impacts many of the core network procedures and information models at reference points

of the architecture.

The 5GS (release 15) is still in an initial phase and the 3GPP view on system architecture is still

under development and investigation, therefore some concepts may change in future. Most of

the key features are not specified in detail yet, e.g. for network slicing concept only slice

identification schemes has been defined. The DÉCOR approach (Release 13) is rather evolutionary

and is focused on enhancing current LTE architecture to support dedicated core networks using

known mechanisms and functions (e.g. HSS). At this moment, the NextGen (Release 14) provides

much more details than 5GS draft specifications, but there are many different, independent

potential solutions and no agreement has been made, which of them should be a standard.

However, some solutions proposed in TR 23.799 have already been adopted in TS 23.501.

3.7. 5G Americas

5G Americas organization has published a whitepaper on network slicing for 5G networks in

November 2016 [30]. The fundamental assumption is that E2E network slice can be composed of

RAN and CN slice (the slicing of end-user device is out of the whitepaper’s scope). Each network

slice could have a unique architecture and mechanisms. In the core network the key enablers to

provide required flexibility are SDN and NFV, which provide network elements virtualization. The

use of SDN and NFV allows operator to separate user and control plane in the core network. In

the RAN, slicing is achieved by dividing physical radio resources or resources abstracted from

physical radio resources. However, the radio access slice is defined as ‘a mapping of slice-ID to a

set of configuration rules for the RAN’. In other words, there are RAN-specific rules that fulfill

specific requirements related to radio access for each slice. The entity, which provides

interoperability between RAN and CN, is slice pairing function. The split into RAN and CN slice

allows combining E2E network slice in flexible and dynamic way.

The important aspect of 5G Americas network slicing concept is emphasis on RAN slicing, what is

a unique feature among all analyzed solutions. The dynamic configuration of RAN can optimize

distinct KPI’s requirements for each slice.



Figure 18 – 5G Americas network slicing [30]

In order to simplify network architecture the common functions for several slices are used to

coordinate RAN resources and to provide basic functionalities such as mobility management.

Moreover, 5G Americas addresses many gaps such as Slice Pairing Function, ETSI MANO

extensions for life-cycle management of slices or network slice isolation on the traffic, bandwidth,

storage and processing level. The network isolation is an important issue in context of slice

operation and hasn’t been addressed by any other project related to network slicing. Another

aspect addressed by 5G Americas is network softwarization and programmability not only in the

terms of dynamic orchestration, but also to adjust network resources and network state at slice

run-time to meet the business objectives. The innovation of this approach is Continuous

Integration & Continuous Delivery framework provided by operator for all potential slice

developers. Nevertheless, this concept uses also the 3GPP mechanisms. The slice selection and

discovery procedure uses the DÉCOR and the 3GPP QoS framework along with Policy Charging

Control is applied to QoS management in RAN and CN. 5G Americas whitepaper describes

design principles, but it’s a fresh document and there are still no details regarding architecture

and reference points.

3.8. ETSI NFV activities on slicing

In February 2017 ETSI NFV Industry Specification Group (ISG) published the white paper on

‘Network Operator Perspectives on NFV for 5G’ [31]. This paper treats network slicing as one of

the key features of 5G networks. First of all, authors notice that standard bodies and open-source

communities use term of network slicing in contextually different ways. This conclusion has been

also noticed by 5G!Pagoda consortium as one of the risks in early deployments and

standardization efforts of the network slicing concept. However, ETSI NFV ISG has defined

properly network operator’s viewpoint on network slicing as ‘service-oriented network construct

providing network-on-demand to concurrent applications’. The important aspect for network

operators is support for different services in efficient way, with required and guaranteed Quality

of Service.



ETSI NFV ISG believes that MANO framework already has the most important functions to realize

NFV-based network slicing, as this concept should not bring new requirements to NFV

architecture. They believe that network OSS may leverage APIs exposed by major entities of

MANO framework in order to realize VNFs life-cycle management or FCAPS management. They

consider standardization of a particular OSS as slice management function on the top of NFV.

However, authors realize several areas that need further investigation and standardization such as

multi-tenant/multi-site orchestration, resource isolation and security enforcement.

From ETSI’s point of view, network slicing will not bring crucial extensions to ETSI NFV-MANO

framework. Nevertheless, the NFV architecture should be adapted to network slicing and future

standardization work will focus on required enhancements.

3.9. Summary of the state of the art

There are several organizations and many research projects that are related to 5G network

architecture and all of them take into account the network slicing concept as a key enabler to

deploy services with different functional requirements. It has to be noted that at the time of

writing of this deliverable, there were many ongoing research activities and the slicing concept

has been demonstrated only in small scale trials. It seems that in the future the approaches

presented in this chapter will have to converge to more matured, accepted by operators solution

that provide reliability, scalability and all other carrier grade features and especially will be able to

address large scale deployment requirements.

Although the analyzed approaches have defined several interesting mechanisms of network

slicing, there is currently a missing cohesion on how the different architectural developments can

be integrated into a common architecture, this deterring the fast adoption and further

technology development in the area. For example, the 3GPP concepts are rather evolutionary

ones, providing a new holistic overview on how software networks have to be deployed, they are

rather at the beginning steps of standardization activities, having a high risk to settle with smaller

goals or not to be adopted by the communication. On the other hand, the 5G PPP developments

focus more on the ‘softwarized’ infrastructure, missing yet many features related to the

management and the enforcement of network slices, particularly in case of multiple domains.

All of the analyzed approaches have some different features but are also similar to each other, at

least at the high level. The common features of the analyzed architectures are following:

• There is an Infrastructure/Resources Plane that provides a pool of resources (computing,

storage, networking, radio) which can be virtualized and part of resources can be allocated

(with isolation) to network slices, this are the basis of cloudification of the network

functionality.

• The Network Function Virtualization Plane provides a set of Virtual Network Functions

implemented as software and running atop of virtual resources.

• The E2E Orchestration and Management Plane provides functionalities for dynamic

deployment of new E2E network services on the top of virtual resources and using a



predefined set of interconnected network functions (aka slice template). This plane also takes

care of life-cycle orchestration of network slices.

• The Application/Business/Service Plane providing high-level description of E2E network

service as well as a business interface to provision new services.

The state of the art analysis proved that the 3GPP has proposed the most detailed solutions and

procedures of network slicing, but the technical reports are still under investigation and are not

mature yet enough to be implemented as products. Because of their likeliness to succeed and

due to the possibility to contribute to the technological advancements in a significant manner

5G!Pagoda will include the 3GPP vision and propose extensions or new mechanisms in some

parts of the 5G architecture.

We have also discovered several topics or problems that are not addressed yet well or are

addressed in a limited scope:

• Decomposition of orchestrators – the only one approach that mention about orchestrator’s

decomposition is the architecture design delivered by 5G PPP. In order to provide reliability,

scalability and high availability (stability), the orchestrator entity should be decomposed into

functional entities, for example into Multi-Domain (Service) Orchestrator, Domain (Service)

Orchestrator and Resource Orchestrator. The Resource Orchestrator should be also

decomposed into SDN-Orchestrator and NFV-Orchestrator (MANO) and other technology-

specific orchestrators. For 5G!Pagoda architecture purposes, we should define a common

interface between the multi-domain slice orchestrator and domain slice orchestrator in order

to unify multi-domain orchestration and to provide approach, that can be neutral to

implementation. In other words we should let the implementers to use/choose any domain-

specific orchestration tool they want to, while maintaining common way of multi-domain

communication. The domain-specific orchestrators should be still able to cooperate with each

other using well-defined interfaces in order to provide multi-domain E2E network slice.

• Multi-domain slicing and orchestration issues – multi-domain architecture is the subject of

research of 3GPP, 5G Americas and several 5G-PPP project, but we have found several issues,

that should be investigated more deeply. The E2E slices should be created across multiple

technological or administrative domains, but not all of them will be composed of domains

with full functionality, because of slice specific requirements or limited ownership capabilities.

Moreover, in context of multi-domain slicing an E2E network slice description is still a subject

of research. The E2E slice template should be aware of capabilities of each administrative

domain.

• Slice selection and discovery – this functionality is one of the most important component of

the sliced network architecture. Generally, the slices should be advertised to UE and the UE

should be able to attach to multiple slices. Another possibility is UE agnostic slicing in which a

proxy entity provides traffic redirection to dedicated slices. In 3GPP drafts there are already

described several slice selection and discovery mechanisms.

• Slice composition – this problem hasn’t been addressed by any project apart from TR 28.801

v1.0.0. As 5G!Pagoda, we consider that the E2E network slice should be allowed to be



comprised of multiple sub-slices as the composition of several radio, transport and core

slices. The slice composition should follow a recursive approach and to enable a dynamic

usage of slices if they are available, thus loosely coupling of the multiple sub-slices into an

E2E slice.

• RAN slicing – the Radio Access Network slicing has been addressed by 5G Americas

approach only. As 5G!Pagoda, we consider that special radio quality of service metrics should

be ensured for particular use case. However, full support of RAN slicing may be difficult – the

data plane or application plane of RAN slicing is relatively simple, but some control plane

operations of RAN have to be common for many slices (for example the handover). The

issues related to RAN slicing should be analyzed and proper solution should be found in

order to provide an E2E service-tailored network slice.

• Data Plane Programmability – deep programmable networks may be an important enabler

for slicing of network data plane, as the data plane of the different slices may be using the

same common data plane components optimized for the data processing and forwarding,

independent of the location and number of control plane entities, through this providing the

means to optimize the E2E data path, while maintaining the flexibility of the multi-slicing

environment. We assume that various slices may use different data plane protocol stacks, so

the effective way of implementation should be developed, in which different data plane

protocols can be docked to the same data plane entity and could be dynamically composed

to be used in parallel by one or more slices. Moreover, the NFV-based functions should

guarantee high performance of forwarding plane operations by properly selecting the

architecture location of the data plane functions and by providing the appropriate shared

control. The Data Plane Programmability has been address only by IMT-2020. 5G!Pagoda will

investigate data plane programmability mechanisms for both the data path processing and

for the shared tenancy of the data plane components.

• Control Plane customization – when deploying multiple network slices there is a need to be

able to use the same software network components while deploying highly customized

services. This flexibility should be reflected into the development of the edge and core

network functional architecture of the active service components implemented as software in

order to be able to use interoperable and highly configurable products.

• Legacy systems compatibility – for telecom operators it will be a huge advantage if they

may use an existing hardware-based systems in the slicing context, this is especially about

RAN which typically takes 70% from the overall mobile network cost. This problem has been

addressed by some projects only, as an example by 5G-NORMA or 5G Americas, but without

details how the legacy systems will be adopted and later on migrated to fully sliced, software

based networking solutions.

• Slice management – one of the challenges for network slicing architecture is how to provide

effective and scalable management framework in the multi-operator, multi-tenant, multi-

domain environment. In fact the management operations, due to scalability and effective

optimization of resources should be automated as far as possible. This has to be in fact

provided by service and resource orchestration. On the other hand the slice owner/operator



should have also a management interface in order to monitor slice performance (SLA) and to

configure it according to his needs. There is no doubt that the interface should be simple and

comfortable and that the most management operations should be performed by slice

orchestrator or orchestrators if multiple orchestrators are in use.



5G!Pagoda architectural requirements 4.

In general the 5G!Pagoda architecture is driven by technical and business requirements. Some of

the requirements were collected via state of the art analysis, the analysis of 5G architectures

standardization efforts and some of them are result of work described in deliverable D2.1 [1] that

concerns 5G!Pagoda use cases.

The network slicing definitions and concepts have been described in the chapter 3. As it has been

described, a slice can be seen as a generalized networking solution. In 5G!Pagoda the following

high level requirements regarding network slicing solutions have been formulated:

• Flexibility: A slice is a dynamic entity, which lifecycle has to be managed, from both the

perspective of the service (adapting to the momentary service needs) and from the

perspective of the resources (dynamically using some of the common resources).

• Service agnosticism: The slice can support single service (1:1 mapping) or multiple services

(1:n mapping). In the latter case, the service lifetime management should be separated from

the slice lifetime management.

• Isolation: A slice has to provide physical or logical isolation from other slices that includes

security and privacy aspects.

• Functional structure: The internal architecture of a slice should be composed of Data Plane,

Control Plane, Application Plane, Management Plane and Slice Resources, each with specific

roles in the data forwarding, control of the connectivity, application level communication,

management of the virtual network and the underlying resources used.

• Functional structure: In specific cases like the legacy solutions and some RAN solutions the

slicing may concern only selected system planes. The planes also can be sliced partially,

having a common part that is used by many slices. Such approach is justified by technological

limitations for example concerning slicing of the control plane in RAN on the other hand such

approach may lead to more efficient slicing.

• Functional structure: The slicing may concern only single or some domains of the multi-

domain solution (e.g. RAN domain, EPC domain, etc.).

• Data plane performance: The sliced Data Plane has to provide mechanisms that will

guarantee high performance of data plane operations.

• E2E Slice: There may exist different types of slices like access network slice (e.g. RAN), mobile

core slice, transport slice, etc. Each type of slice has to be appropriately described for the

purpose of the E2E slicing.

• E2E Slice: The planes also can be sliced partially having a common part that is used by many

slices.

• E2E Slice: An E2E slice can be composed of many slices (called also sub-slices) by slice

stitching – this approach provide a compatibility with the NGMN network slicing approach.



• E2E Slice: A sub-slices contributing to the E2E slice may be existing ones or created on

demand. The operation of composing of the E2E slices should be recursive.

• E2E Slice: An E2E slice can be composed of slices belonging to different technological or

administrative domains (multi-domain slicing).

• E2E Slice: a slice should be able to compose the E2E slices of slices or resources that belong

to different domains.

• Legacy systems compatibility: The solution should be software oriented (use NFV, SDN, cloud

technologies, etc.). However, the slice may also accommodate network functions

implemented in hardware (PNF according to the ESTI MANO terminology) or the existing

legacy hardware subsystems. It is justified by huge amount of installed mobile network

hardware nodes and the expectation that network softwarization will be a gradual process.

• Legacy terminals compatibility: slice-agnostic terminal operations should be allowed. In such

a case the UE is not aware about the existence of multiple slices but appropriate proxy

provide required traffic redirection (to VoIP slice, to VoD slice, etc.).

• Slice discovery and selection: Due to the dynamic lifecycle of slices, a slice discovery and

selection mechanism has to be implemented.

• Slice discovery and selection: The slice selection should be based on policies.

• Slice discovery and selection: The slice selection can be driven by user equipment (statically

or dynamically, based on a list of slices provided by the orchestrator) or by the slice operator

(i.e. the network and not the UE, which is responsible for slice selection). A negotiation

between the network and UE during slice selection process should be also possible.

• Dynamic slicing: The UE should be able to attach to multiple slices and request creation of a

slice.

• Policy-based slice management: The slice operations and lifecycle management should be

based on policies. That is being currently the only dynamic mechanism that is able to

encompass dynamically different administrative requirements.

• Management functionality scalability: Slices management and orchestration should be

scalable, allowing dynamic and efficient allocation of resources to slices and dealing with

multiple domains.

• Compatibility: The 5G!Pagoda architecture should accommodate 3GPP DÉCOR, 3GPP

NextGen and 3GPP 5G approaches (mobile core slicing, slice selection mechanisms, inclusion

of not sliced RAN, full E2E slicing), however due to lack of stable recommendations the

compatibility may not be fully achieved.

• Compatibility: The 5G!Pagoda architecture should be aligned with the 5GMF architecture as

far as possible.

• Roaming: If a slice is composed of distant RANs, a roaming mechanism should be deployed

within the slice.



• Instantiation: the instantiation of the 5G!Pagoda architecture to a specific use case should

address in the most performant manner the requirements of the specific use case.

4.1. Generic business requirements

The use cases discussed in the sections 3.2 and 3.3 of D2.1 [1], clarified that 5G!Pagoda targets

multiple stakeholders. The network slicing is key enabler for a new business model that

comprises of the infrastructure providers, slice providers and operators, application providers and

end-users. The existence of multiple stakeholders impacts the architecture in the following way:

• There have to be defined interfaces between different owners/operators.

• There has to be a business interface that will allow the slice operator (tenant) slice

management, especially creation of the E2E slices in multiple administrative domains.

• The slice operator should have high-level management capabilities that include: PBM,

configuration, security operations, accounting and performance monitoring; Fault and

performance management should be automated and performed by slice orchestrator.

• The orchestrator operator, slice operator or the end-user should be able to create a slice. In

the latter case (slice on-demand) the slice should be advertised and its roll-out time is critical

one.

• There has to be an administrative interface between the slice operator and slice provider.

4.2. 5G!Pagoda scenarios specific requirements

As discussed in the section 3.4.9 of the deliverable D2.1 [1], the 5G system is expected to provide

various capability sets depending on the use case. The common capabilities have been described

in the previous sections of the chapter. The additional, architecture related requirements that

have been identified in D2.1 [1] include:

• The 5G systems equip computational resources at network edge entities for a connectivity

path (less data traffic in the core network, lower delay, secure local communication, etc.).

• The service providers have should operate on two types of stratums, i.e. physical resource

layer where various services (implemented by software) can run and the software layer which

control and manage the services.

• The software layer entities have the capability to be relocated on demand over the physical

resource layer and across different domains (business regions).

• The 5G system should manage mapping between users and capabilities belonging to the

users.

• The 5G system should track the user subscription and their capabilities dynamically.

• The hardware resources assigned to the system component implemented in software should

be updated (added, removed and replaced) when the capability set gets updated (the scaling

feature).



• The 5G system should provide control and management mechanisms between the in-

software implemented components and the physical resource layer.

• The 5G system should have a redundancy mechanism that provides individual redundancy

levels that can be enforced by service providers (as a part of policies).

• The 5G system should have a mechanism for providing the E2E QoS service warranty.

Specifically, the multiple stakeholders must be able to interwork for providing E2E service

guarantees.

• The 5G system resource allocation to software system components should be updated in a

second or shorter.

• The 5G system should include various processing capabilities that realize customer demands.



Design considerations 5.

The main goal of 5G!Pagoda was not to develop ‘yet another slicing architecture’ – as it has been

described in the chapter 3 there are already many attempts to this problem. The project ambition

however is to develop an architecture framework that provides harmonization of the existing

architectures in a converged manner. On the other hand the ambition was also to develop in

more details mechanisms that are missed or not fully addressed yet by other approaches. It is

worth to emphasize that 5G!Pagoda architecture will accommodate the 3GPP efforts related to

slicing, however, we will go beyond 3GPP approaches by integrated in a graceful manner other

network components which are not in the direct goal of 3GPP standardization. The developed

concept can be seen as a first step toward the convergent slicing that deals not only with mobile

networks but also with transport ones, etc.

As already described in this deliverable, a slice offers a dedicated, networking solution that is

tailored for needs of a specific application or several applications. In general the slice, despite it is

realized in software, should provide similar operations as hardware based networks. It has to be

however emphasized that a network slice can offer much more than a ‘pure network’ – it can

include also the application layer functions.

A software implementation of network slices atop of common hardware resources, provides high

level of flexibility and the dynamicity of slice functions and slice oriented operations. Due to some

constraints and the existence of legacy solutions, in 5G!Pagoda it has been also considered

solutions that slice may be hybrid ones, i.e. composed of both, software and hardware

subsystems.

In 5G!Pagoda we have followed the classical telecommunication network architecture template,

in which the network is composed of Data, Control, Application and Management Planes. All

types of slices can be implemented following slice template, as illustrated in Figure 19. The

pattern concerns as well Common Slices as Dedicated Slices.

Slice Resources (virtual and physical ones)

Application Plane

Management

PlaneControl Plane

Data Plane

Slice Resources (virtual and physical ones)

Application Plane

Management

PlaneControl Plane

Data Plane

Figure 19 – Planes of 5G!Pagoda slices

The Data/User Plane is controlled by a clearly separated Control Plane, following the principles of

carrier-grade telecom networks. On top of the Control Plane, the Application Plane is established

which consists of different application enablers (slice exposure) in order to offer the appropriate



services to specific applications. The Management Plane is added to the slice based network,

enabling the appropriate operations for all the other planes and their resources.

The 5G!Pagoda architecture is in line with 3GPP, but goes beyond 3GPP slicing and enables

slicing of different type of networks or sub-networks. According to NGMN it also enables the

creation of an E2E slice as combination of domain slices. Such domain slices can be RAN slices,

EPC slices (e.g. 3GPP DÉCOR), IoT slices, transport slices, etc. In order to create the E2E slice there

is a need to describe the slices in a uniform and readable manner.

In case of mobile networks the slicing of RAN is problematic. In RAN it is possible to share the

radio resources among slices (i.e. the Data Plane), but slicing of Control Plane and the

Management Plane is hardly possible. Some of the Control Plane operations have to be common

due to the mechanisms implemented in the physical radio layer. An exception is the Cloud-RAN

concept, which fully enables RAN slicing (in case of LTE at the BBU level). In general the RAN

slicing with shared Control Plane (3GPP DÉCOR, NextGen) has to be accepted. In such cases the

Control Plane can be fully or partly shared, but the Data Plane can be fully sliced. The mechanism

of independent sharing of any of the system planes (per plane slicing) can be also deployed in

general in order to simplify the design of slices – each of them may have a slice specific part that

use the services offered by the shared part of the plane. Due to the mentioned issues in

5G!Pagoda the so-called Dedicated Slices can use services of all planes that are offered by so-

called Common Slice. We have decided to go beyond the 3GPP approach which enables

Common Control Plane only. The Common Slice can be used for example for the data plane or in

case when the requested slice does not exist or it is created on-demand. In the latter case the

Common Slice Data Plane provides the communication until a Dedicated Slice will be created.

The mechanism of slice selection can be implemented in a different ways. In some cases slice

selection can be implicit (for example in the IoT case), in some of them the existing legacy

networks can be used. Another considered option is the use of specially designed lightweight

control plane and distributed mechanisms for slice selection. In the Network-on Demand

approach slices can be created dynamically as requested by the end-users.

In 5G!Pagoda both, slice and resource level operations are automated. The slice oriented

operations are logically centralized and handled by the orchestrator(s) whereas sliced network

management allows the slice operator (for example a vertical) to manage his network. In case of

the network-on-demand scenario, the management of the slice created by the end-user should

be as much automated as possible.

It is widely assumed the sliced network instances will be implemented a top of virtualized

infrastructure that offers connectivity, storage and computing resources using the ETSI NFV

approach. There are however some reasons that makes the generic network slicing and the

mobile network slicing different than the classical ETSI NFV approach:

• The E2E slicing should deal with the multi-domain issue that is so far not supported by the

ETSI MANO architecture.

• It is generally required that each slice should be isolated from other slices. Such isolation can

be done in many different ways and one of them is the isolation at the slice resource level.



The latter approach impacts the architecture that way that resources allocated to a slice have

(optionally) some resource isolation oriented mechanisms, like data/transmission ciphering,

etc. The mentioned mechanisms are in general not compatible with the ETSI NFV framework.

• The installed base of mobile networks worldwide is enormously big therefore thinking about

slicing in future mobile networks it is also desired by Telco operators to include the devices in

their future solutions that use slices. It is not only about single devices (PNFs according to

NFV terminology), but also about (for example) whole RANs.



5G!Pagoda reference architecture 6.

In this chapter, the initial concept of the 5G!Pagoda architecture is described. This version of the

architecture will be used for the implementation of selected 5G!Pagoda use cases in the later

phase of the project. After the implementation, it is expected that the architecture will be revised

according to the experience gained during the implementation. It has been assumed that the

implementation of the 5G!Pagoda architecture will follow the ETSI NFV approach (with necessary

modifications). Moreover, it will be softwarized as much as possible using common infrastructure;

but to make it generic, the approach allows also for incorporating of existing, hardware-based

nodes and solutions (networks) when creating the E2E slice.

The described 5G!Pagoda architecture is a so-called reference architecture, what means that it

can be instantiated in many different, implementation-specific ways. The architecture description

is split into two parts:

• one related to support of network slicing operations (slice selections, subscriptions, etc.) as

well as slice generic structure;

• one related to the orchestration architecture that covers also multi-domain orchestration.

The described reference architecture deals with all planes of sliced systems and adds functional

components that are required in the multi-slicing environment. At this stage, we did not provide

details on the interfaces (with some exceptions), but we described the required functionalities of

the interfaces. The reasons for that are the following:

• The functional components of a slice that belong to control, data or application plane already

have interfaces. They are related to a specific networking solution (e.g. EPC, RAN, etc.). There

is no way and no need to redefine them and make them generic. Therefore, they should be

implemented as they are. Also due to implementation of functions in software the message

bus, as recently proposed by 3G PPP in the context of 5G architecture, could be used for the

communication between them.

• The management and orchestration functional components of our architecture are software-

based and 5G!Pagoda consortium has decided not to use interfaces, but the service-oriented

architecture instead. It means that the functional components will use a common message

bus in order to exchange messages between the functional entities. Therefore, the functional

components will communicate via message broker instead of using predefined interfaces. The

major difference between service-based and point-to-point based approach is that in the

former model, service queries a service repository function, which implements service

discovery functionality (similar to the 3GPP NRF function described in the 5G core

architecture). By dint of service discovery, entity services may detect other communication

peers, what makes fixed reference points avoidable. The basic architecture of mentioned

approaches is composed of publishers, subscribers and message brokers (message buses).

The approach is in line with orchestration solutions such as Open Baton, or ONAP. However,

the service-based architecture may be translated into traditional reference point architecture.



• As much as possible we tried to align our approach with the ETSI MANO framework, ensuring

compatibility for some of orchestration related functional component interfaces of our

approach. It is worth to say that ETSI MANO framework does not define protocols that should

be used between its functional components. Moreover, they do not address multi-domain

orchestration.

• This deliverable defines only the initial draft of the architecture. The final one will include

much more detailed description based on the inputs from other work packages of 5G!Pagoda

and feedback from the testbed implementation.

6.1. Functional architecture of the system

The generalized 5G!Pagoda architecture for single-domain slicing is presented in Figure 20.

Hardware Nodes (PNFs) and

Subsystems (HNS) Physical Computing/Storage/Connectivity Infrastructure Layer (PCSCI)

Virtual Computing/Storage/Connectivity Infrastructure Layer (VCSCI)

Domain-

Specific

Slice

Orchestrator

(DSSO)

Slice #1

operator

Slice #n

operator

Common

Slice

operator

Orchestrator

operator

Infrastructure

Intra-domain

Slicing

(Single operator)

Slice Resource Layer (SRL)

Slice Sofware Layer (SSL)

Slice

Operations

Support

Common Slice owned

HNS

Slice

Management

Plane

Common Application Plane

Common Control Plane

Common Data Plane

Common

Slice

Slice Resource Layer (SRL)


Slice

Management

Plane

Slice Data Plane

Dedicated

Slice #1

Slice owned

HNS

Slice

Operations

Support

Slice Data Plane

Slice Data Plane

Dedicated

Slice #nSlice Resource Layer (SRL)


Slice

Management

Plane

Slice Data Plane

Slice owned

HNS

Slice

Operations

Support

Slice Data Plane

Slice Data Plane

Figure 20 – Instantiated 5G!Pagoda slices on top of the same infrastructure

In the figure, the following basic blocks of the architecture can be found: Infrastructure, Common

Slice, Dedicated Slices and Domain-Specific Slice Orchestrator (DSSO) that is a part of the

orchestration architecture that is described in the details in the section 6.3.

The Infrastructure consists of resources that are separated into two main groups:

• Virtual Computing/Storage/Connectivity Resources (i.e. interconnected data centers) that are

build atop of respective Physical Resources.

• Hardware Nodes and Subsystems (HNS) that can be used by the Common Slice or Dedicated

Slices. HNS may include RAN or Radio Nodes (eNodeBs), specific transport nodes, etc. These



nodes can be also programmed, but they offer different services than virtual

connectivity/storage or computing. In ETSI NFV terminology they can be seen as PNFs,

however, they can also include PNFs that form complete networking solutions.

Both types of resources mentioned above can be dynamically allocated to slices. The allocation of

Infrastructure resources to the Slice Resource Layer is done by the DSSO and is optimized during

whole life-cycle of the slice. The architecture of DSSO is specified in the section 6.3.

The architecture enables two different generic slice types: the Common Slice and the Dedicated

Slice. It has been assumed that there is only one Common Slice per technological domain and

that there can be many Dedicated Slices. All the slices can cooperate; therefore they share a

similar internal structure (Control, Data, Application and Management Planes and Slice

Operations Support functions). Both types of slices, despite they have similar architecture, have

different roles and in some cases are complementary ones – it can be said that the Dedicated

Slice is a client of the Common Slice.

The Common Slice is an entity that typically offers three types of services:

• A set of functions that provides the Dedicated Slice users information about available slices,

makes appropriate subscription of users to these slices based on their privileges and operator

policies, etc.

• A set of Data Plane, Control Plane and Application Plane functions that can or have to be

used by respective planes of Dedicated Slices that cooperates with this slice. These functions

may include for example handover handling, MAC scheduling procedure at the RAN level.

The mentioned functions are dependent on a specific use case and they together define the

networking solution that is sliced (EPC, RAN, transport, etc.).

• Basic communication means for the end-users of the system which are not attached to any of

dedicated slices (in a similar way like the default bearer in LTE). This mechanism will be used if

required slice can’t be found or before an on-demand slice is created.

The Dedicated Slice definition should be combined with the Common Slice definition – working

together they should provide a complete network. The existence of both slice types is motivated

by two reasons. The first reason is the inclusion in architecture of solutions that can’t be fully

sliced (for example the Control Plane of RAN, legacy solutions, networking solutions that are out

of the operator control capabilities in terms of slicing). The second lies on the making the

Dedicated Slices lightweight via providing the commonly used functions by the Common Slice. It

is worth to emphasize that from the flexibility and isolation of slices point of view it is preferred

to reduce the Common Slice functionality to minimum. It has to be mentioned, however, that if in

some existing cases some Control Plane are common (cf. DÉCOR), the other planes like the Data

Plane or the Application Plane (for example in the MEC case) can be mostly implemented as

Dedicated Slices.

Many slices can be instantiated and run in parallel, sharing the same infrastructure, which shows

the importance of proper allocation of resources to slices. As the resources are virtualized, the

slices can receive dynamic allocation of resources during their runtime as well as different

resources placement (if applicable). In Figure 20, each Dedicated or Common Slice has Slice



Resource Layer that consists of isolated and dynamically allocated generic

storage/computing/connectivity resources as well as allocated to slice hardware resources (HNS).

The slice life-cycle orchestration role is therefore not only to allocate resources to slices during

their deployment, but also to adapt them to different usage conditions (how the users of the slice

behave) and to the exceptional network situations related, to faults or emergency situations. The

life-cycle orchestration of slices provides automated FCAPS and its role is different than the

internal slice Management Plane operations which are specific and private to the slices and their

services. The Management Plane of a slice is seen as generally lightweight and cooperating with

the slice orchestrator to realize the management goals. In general, it has been assumed that the

orchestration architecture will be composed of multiple orchestrators. The DSSO is responsible

for the life-cycle of slices and the optimization of their operations. It is also used in multi-domain

(E2E) slicing. Each of the technology domains has its own Resource Orchestrator (RO) that is a

part of DSSO. The existence of per domain RO is motivated by different types of resources that

require different operations. It is foreseen that, for example, for the transport network, an SDN

WAN controller will act as the RO whereas for a data center, a typical VIM (e.g. OpenStack) from

the perspective of ETSI MANO may be used. The detailed description of DSSO will be provided in

the section 6.3.

6.2. Network slices structure

6.2.1. Internal architecture of the Dedicated Slice

The Dedicated Slice can offer a full set of services tailored for specific set of applications (a slice

can provide a single application or many applications). In some cases, these services will be

offered with the cooperation with the Common Slice.

Each slice is running on top of the Infrastructure Layer that consists of virtual resources

(computing, storage, connectivity and virtual radio) as well as hardware ones (PNFs according to

NFV or whole hardware based solutions). These resources are allocated on demand through the

orchestration architecture.

The Dedicated Slice Application Plane, Control Plane and Data Plane form a functional

network than can be managed by the slice operator using the Management Plane. The slice

oriented lifecycle operations and automated FCAPS are performed by Slice Operation Support

(SOS) functions that may have its internal Control, Data and Application Planes entities, that

support respective plane operations. It is assumed that the SOS structure is common for all

dedicated slices but the functionalities of internal SOS blocks may differ.



Figure 21 – Dedicated Slice internal architecture

The Dedicated Slice Data, Control and Application Planes functionalities are use case (EPC, RAN,

transport) dependent and they can provide:

Data/User Plane:

• Data forwarding components, enabling the forwarding of the data packets between the

different entities, pertaining to the same or to different slices, including functionality needed

for load balancing and high availability;

• Data storage and processing components enabling the aggregation and dissemination of

information;

• Data processing entities enabling the changing of data formats for proxy nodes and data

aggregation, derivation, splitting of data path for back-to-back;

• Data analytics enabling the generation of active and passive insight on the specific data

communicated;

• Data plane security enabling the encryption of data traffic between different entities;

• Data Plane components related to the connectivity (e.g. Serving Gateway User Plane – SGW-

U, Packet Data Network Gateway User Plane – PGW-U);

• Data Plane components related to the content routing and storage (ICN, CDN);

• Deep Data Plane programmable components enabling the sharing of the available resources

to implement the previous described data plane functions.



Control Plane:

• control of the forwarding plane for functionality such as routing and forwarding control,

including security, load balancing and high availability;

• control of data storage and processing (data path) components;

• control of connectivity over RAN and packet core system;

• control of inter-slice communication;

• control of the applications deployed at the data plane level.

The Application Plane enables the deployment of advanced services (i.e. Application Servers

according to 3GPP terminology) – it may consist of the services as well as service enabler that are

used to compose a new service.

An extensive list of functional components of planes mentioned in this section will be provided in

the chapter 8.

The Dedicated/Common Management plane of each slice is used by slice operator (for

example a vertical) for managing the network slice and its services. It has been assumed that

these operations should give as much as possible flexibility of configuration of the slice and

providing to slice operator the information about achieved slice KPIs. However, all the operations

related to troubleshooting of slice operations should be automated (for example fault

management) and/or handled by SOS. In case of slice is triggered by the end-users (the network

on-demand case) the functionality provided to user should be limited to basic operations only or

offer a predefined set of management functionalities with a basic interface to the user.

The Dedicated Slice Management is used by slice operator in order to monitor slice behavior,

change its configuration and provide billing support. It is assumed that this type of management

is lightweight and comfortable and most of the management tasks, including most of FCAPS

functions are handled by the orchestrator. The Dedicated Slice Management consists of the

following functional entities:

• OSS Support Functional Component. For the operations regarding installation, the slice

O&M should be able to request on demand the addition of a new network function to a

running slice or the reconfigure the existing one. This part provides also information about

allocated resources to slice, their consumption, SLA fulfillment and alerts. Part of this

component is a portal that allows slice management and interactions with slice orchestrator.

• Policy-Based Management is a tool for high level management of sliced network functions

by slice operator without the need of the detailed specification of the low-level operations,

necessary to achieve the management goals.

• Intent Engine translates high level description of slice operator management goals into

detailed low-level operations. In order to achieve this goal, it cooperates with PBM and the

components of other planes of the dedicated slice as well as with the orchestrator. It has

been assumed that the OSS Support functional entity is initiated for each slice and supports

slice specific operations interacting with other Dedicated Slice components, whereas the slice

orchestrator provides slice functions agnostic orchestration.



Using the Dedicated Slice Management, the slice administrator is able to:

• Request a services catalogue from the Business Service Slice Orchestrator (BSSO).

• Select and configure a slice based on the services provided in the catalogue.

• Trigger the deployment of the slice according to the configured services.

• Administrating PBM in both the orchestration and within the slice as much as allowed and

possible through policies within the policy engine. Most probably this will be done through

pre-defined templates.

• Administrating the services within the slice through policies within the slice specific OSS as

well as through user profiles.

The slice management scalability may have multiple dimensions:

• It has to deal with the number of the ‘slice events’ that need to be handled at the same time

and related to management of slices and their resources. If the number of the events

increases, unified management will be too difficult to ensure.

• Frequency of management objects state changing. The objects which have only static or

semi-static states do not influence the management performance; on the contrary the

objects, which state changes frequently, greatly influence the management performance.

In the 5G!Pagoda architecture, it is assumed that the slice management is split between in-slice

management and orchestrator(s). The objects which have high frequency of state changing

should be managed in-slice, preferably by embedded management of each node, but not by the

orchestrator which provides relatively short-term optimization and automated handling of alerts.

Basically, the management of scale is shared by orchestrator and node, but it may possible to

realize better functions to exchange the information between each other. Further, a development

of the management models for scaling to solve these problems is a very important issue.

The Slice Operations Support is a set of functions that are focused on slice level operations,

which they include: operations related to subscription to a slice, slice combination (stitching),

slice lifecycle support and automated slice management based on policies. The SOS functions

may deal with all planes of a slice in order to achieve its goal. Each slice SOS offers the same set

of services, some of which in specific implementation cases can be null. These operations deal

with:

• Slice Repository that contains a repository of active slices to which the end-users that are

allowed can subscribe. This is a local copy of Slice Repository of the Common Slice (if this

slice is in use) created for the sake of scalability and reliability. It may intentionally consist of a

more limited number of slices to which the slice user can roam (for example only these ones

which are owned by the operator of this Dedicated Slice).

• Subscriber Configuration Management. One specific type of configurations is related to

the subscription profiles. Although it is not foreseen that the subscription profiles will be

frequently modified during the runtime of the slice, two major operations have to be

considered:



o Completing the database information for authentication, authorization and access

control rules (i.e. the subscription profile) for all the users at the deployment of the slice;

this highly depends on the number of users foreseen to connect as well as on a possible

previous completed database with such subscription profiles.

o Adding new subscription profiles during runtime on-demand.

o Slice Border Control (SBC). The SBC functions can be included as both the Control and

the Data Plane functions and play key role in multi-domain operations, slice traffic

redirection, inter-slice mediation, etc.

o The SBC-Control Functional Entity ensures the interconnection at the protocol

level between the different components within the slices. It may include for

Diameter peering a Diameter Router Agent (DRA) and for IMS communication a

Session Border Controller, both with the role of peering with the foreign domain,

appropriately routing the requests to the other domain, as well as the

anonymization of the private slice information and the encryption of the

communication. It may be also used for information about domain-specific

properties, expose to other chained slices abstracted network topology, etc.

o The SBC-User Functional Entity ensures the proper interworking between the data

path components in case the communication requires other protocols than IP only.

The functionality may include GTP peering (as in the case of packet core roaming),

SFC peering, multimedia transcoding and content compression as well as possibly

the encryption of the data path.

• Slice PBM addresses the slice-related issues, including inter-slice connectivity management

policies that can be adapted depending on the momentary network function placement. For

example, if functions of two components of the different slices are co-located, it could be

better to establish between them a connection compared to components which are located

in different data centers.

• Slice FCAPS operations are used to implement slice level FCAPS functionality towards

complex events processing and NFV environment specific adaptations (e.g. actions for re-

creating the network on components’ failure, configurations depending on the dynamic

network as established by the NFVO during the runtime, differentiated accounting rate

depending on services, time of day, etc., enhanced performance and security optimizations

through the adaptation to the environment such as deployment of more appropriate VNFs to

the momentary situations, reconfiguration of the components depending on the momentary

topology of the system for increasing the resilience and the availability, ensuring of the

service KPIs across deployments on top of heterogeneous infrastructures).

• Slice Selection Function (SSF) is used for the allocation of UEs to slices. The Slice Selection

Function in a Dedicated Slice complements or replicates the Slice Selection Function in the

Common Slice. The process can be based on UE preferences, operator decisions or a result of

negotiation between the UE and network. A slice discovery is part of this function. It is also

used by the UE for the creation of a slice on-demand, if such operation is allowed. Note that

in case of slice stitching only the ‘edge slices’ will have this component. The Slice Selection

Functions should be backward compliant with NextGen and 5GS mechanisms as described in



3GPP TR 23.799 and TS 23.501, but it has to be extended. The mechanisms should allow for

attachment of slice unaware UEs, UEs with predefined slice (for example in SIM), UE able to

attach to multiple slices, creation by UE a slice on-demand if a required slice can’t be

matched.

6.2.2. Internal architecture of the Common Slice

The Common Slice is a slice that can play multiple roles in the architecture:

• For a specific technological domain, it can be used as a ‘default’ network slice which offers

services to the users, which are not yet attached to the Dedicated Slices.

• It can be also as temporary slice used before the ‘network on-demand’ slice will be created

(during the Dedicated Slice bootstrapping).

• In a reduced form as ‘Control Plane only slice’ it can be used as a signaling path for slice

redirection.

• It may offer some services that will be used by dedicated slices. Such approach makes the

Dedicated Slices simpler and shortens their booting time. This approach is especially

important in case of Network-On-Demand slices.

• It is mandatory in solutions in which there exists legacy solutions which planes are non-

splittable into dedicated slices (at least at the plane level), or depend on a hardware node.

Such a case can be 4G RAN based on eNodeBs, etc.

• As a permanent database of information about all slices, subscriptions also used for legal

intercept. This information can be copied to Dedicated Slices (it is about Slice Repository,

subscriber management, Slice Selection functions rules, etc.).

• As a basic mean of communication during emergency services in order to provide most users

connectivity.

The Common Slice is seen as permanent entity. According to research directions the functionality

of this slice should be limited and distributed among the Dedicated Slices, except the mentioned

above case when such operation is not justified. The distribution of Common Slice functionalities

among Dedicated Slices improves system flexibility, scalability and reliability.

The internal architecture of the Common slice is similar to the Dedicated Slice. The main

difference lies on its permanency and implementation of some functions in specialized hardware.

It can be assumed that the Common Slice in a minimal version will have neither Application nor

Data planes (in such case it will be similar to 3GPP DÉCOR and NextGen). The SSF is necessary in

the Common Slice in order to initially connect users to the Dedicated Slices. The Common Slice

Management is separated from the management of Dedicated Slices



Figure 22 – Common Slice internal architecture

6.2.3. Slice description and capability exposure

6.2.3.1 Slice descriptors

There are at least two reasons that require description of slice functions. The first case is related

to slice selection by the UE whereas the second one is related to slice stitching that can be used

in multi-domain environment. In the latter case, a direct implementation of a multi-domain E2E

slice, based on a single slice template is possible, but it can be much more complicated and time

consuming then the mentioned stitching of independently created domain slices. The creation of

E2E slice can be recursive and for example several transport slices can be chained together as a

single transport slice that is a part of an E2E slice that also has RAN and EPC domain slices.

Generally, an each E2E network slice should be composed of Radio Access Network, Mobile Core

Network and Transport Network.

In order to deploy an E2E network slice, the orchestration system needs to use a common and

unified model of slice description. Moreover, each network slice shall be uniquely identified in

order to allow end devices to select appropriate network slice that will provide specific network

services. In fact, in order to provide global interoperability, there is a need for standardization of

slice description and identification and it has already been addressed by 3GPP. However, at the

time of writing this deliverable the proposed by 3GPP solution is not mature yet and requires

further study. In 5G!Pagoda, we made a step forward in order to solve the problem, at least for

the purpose of our implementation. In general it is expected that this problem will have to be

solved by standardization organizations in order to be accepted worldwide.

In the heterogeneous networking environment, there exist various network slice types. In order to

provide easy operations at slice level a technology-specific categorization of slices is necessary.



This categorization enables creation of a combination of slices as sub-slices and inter-slice

operations. The slice types include:

• Access Slices (AN) and their subset Radio Access Network (RAN) Slice,

• Mobile Core Slices,

• Transport Slices,

• Composite E2E slices, being any combination of Access, Core and Transport Slices.

This technical categorization of slices impact a construction of slice template, that has to be

domain technology specific.

From business point of view there is possible another way of categorization of slices: service-

specific categorization. Slice types of this category may include:

• Generic Service slices, that describe slices tailored to generic service such as IoT or CDN;

• Service Specific slices (YouTube, Netflix, Skype, etc.), which needs specific parameters of QoS,

security, placement, etc. These may be owned and operated by 3rd parties.

This categorization impacts slice identification scheme. We assume that end- device should be

able to request an access to network slice tailored to specific service. It is worth to note that a

particular network slice instance can be created to handle a specific service or it can be used for

handling of multiple services.

6.2.3.2 Slice capability exposure

In many network slicing concepts, there is a functionality that is called slice capability exposure

that in general is used to access all the information concerning a slice through an API. This access

should be provided to all 3rd party software; then, one of them could request via the API one or

several modifications of the network slice to realize a specific use case or task. In general, it can

be seen as a sliced network API to services (as it is implemented in classical networking solutions).

As stated earlier, in it assumed in 5G!Pagoda (according to NGMN slicing vision) that there can

be a single service or multiple services per slice and these services may have a lifecycle

management separate from the slice lifecycle management. The mentioned slice capability

exposure function can be seen as an API between the (sliced) network and their services. Due to

the diversity of networking solutions, a single Slice Exposure API is not feasible to define and

there is no such need. If, for example, the sliced networking solution is EPC, it exposes the

services that have been defined by 3GPP. There is no doubt that some non-standardized solution

should provide their API, but this API is in general not dependent on sliced or not-sliced

implementation.

The management operations in the 5G!Pagoda are allowed via slice Dedicated Slice Management

and Slice Operation Support functions. It has therefore been decided to use the OSS Support

component of Dedicated Slice Management to provide slice capability exposure functionality to

slice tenants.



6.3. The orchestration architecture

The 5G! Pagoda orchestration architecture is based on set of ETSI NFV functions that are

extended to support multi-domain operations, slice specific functions and PBM of the

orchestration process. The orchestration functions defined by ETSI MANO are described in this

section together with the other new components introduced into the system, making references

towards existing specifications when needed. The overall orchestration architecture will be

developed within the work package WP4 of this project.

Figure 23 – Orchestration architecture

The functionality of the orchestration blocks is described below:

• NFVI – from the perspective of the slice management, there are no modifications to the NFVI

as defined in the high level ETSI NFV architecture. However, a specific implementation of the

virtual network is considered, covering deep data plane programmability and inter-data

center WANs.

• VIM/WIM – the Virtual Infrastructure Manager (VIM) is defined in the ETSI NFV architecture.

Additional functionality of the VIM includes the capability to control the data plane

functionality such as in the form of an SDN controller or an ICN or CDN information and

content control in order to be able to provide a separation of the data plane when the data

traffic is directly routed through the network (i.e. deep data plane programmability). Inclusion

of the SDN Controller is common in many 5G PPP projects. The Wide Area Network



Infrastructure Manager (WIM) has the role to define the virtual networks between different

parts of a slice on top of common transport networks (i.e. the inter-data center environment

sharing rules).

• NFVO – the Network Function Virtualization Orchestrator has the functionality defined by

ETSI NFV with its two roles of:

o Resource Orchestrator (RO) enabling the brokering of the NFVI resources between

the multiple parallel slices. The NFVO represents an aggregation point for the

administrative domain for resources management. The NFVO communicates with

multiple VIMs and WIMs and is able to allocate the resources appropriately across

them.

o Network Service Orchestrator (NSO) providing indications on how the system should

scale and where the network functions should be placed following the Network

Service Descriptor (NSD) information.

Additionally, the NFVO is extended to support additional commands which result in the

dynamic changing of the Network Slice Blueprint information. By this, the active service can

be dynamically modified during runtime with additional actions compared to the static

Network Slice Blueprint based decisions. For example, with this new functionality, new VNFs

can be added during runtime to a running system (e.g. a more performant firewall in case of

a network attack).

• VNFM – its role is defined by ETSI MANO specification. It should:

o allocate appropriately resources to the VNFs or to delegate this operation to the

NFVO

o receive events on the completion of the specific operations and information on the

dynamic configurations

o configure through the Element Management (EM) the VNFs with the dynamic

configurations and control the execution of life cycle events

• DSSO – it is able to communicate with multiple NFVOs located into the same domain

information on the specific slice split between the different NFVOs. Additionally, the DSSO

receives from the multi-domain slice orchestrator the information on the life-cycle

management of the part of the slice, which is allocated to run on the specific domain. Note

that this functionality is already offered by the northbound API of the NFVO in the form of

the processing of NSDs. It shall be noted that in the envisioned architecture (Figure 23), a

DSSO and NFVO may be the same entity.

• MDSO (Multi-Domain Slice Orchestrator) – its main role is to provide a slice on top of

multiple administrative domains. It contains the following functionalities:

o Receives requirements from BSSO on the requirements for the specific slice. The

requirements may be received in a static description form such as TOSCA or an NSD

file.

o Establishes secure connections to the multiple DSSOs.



o Acquires, if permissible, knowledge on the available resources in the specific

administrative domains in terms of available infrastructure and available services (e.g.

stored virtual machine images).

o Negotiates with the DSSOs the resources and their locations to be allocated for a

slice customer.

o Makes decisions based on the requirements received on the split of the slice

functionality across the multiple administrative domains.

o Commands the installation of the slice over the multiple administrative domains.

o When the installation is successful, exchanges connectivity parameters between the

different DSSOs to be able to stitch together the slice.

o Announces the tenant through the business slice orchestrator on the successful

installation of the slice as well as on the connectivity and management points.

o Informs the tenant, through the business slice orchestrator and/or the slice-specific

OSS, of any SLA breaches or any other types of major failures of the deployed slice.

o Disposes a slice from the multiple domains.

The MDSO implements Slice Placement Function that is responsible for allocating and

interconnecting slice-specific virtual network functions (VNFs) according to resource

constraints and service requirements, e.g. related to latency. The task of the multi-domain

Slice Placement Function is the selection of domains covered by the slice. In particular, the set

of domains must be connected so that there is a path from each domain to each of the other

domains. For this purpose, it may be necessary to select from a set of alternative domains the

particular domains to be on the path between two end domains, e.g. between the two

domains of a UEs participating in a call. For the above purpose, the multi-domain placement

function is required to have information on available resources and cost of intermediate

domains. Based on this information, the multi-domain slice selector can consult a domain

selection policy function to, according to given policies, determine the domain to include into

the slice. Domains can also be proactively covered by a slice, even if there is no UEs or

transport needs connected to that domain. In particular, for placement of services and VNFs,

domains such as generic virtualization infrastructure providers, can be included. This may be

e.g. based on the price of hosting infrastructure, a central location or the availability of

resources (e.g. bandwidth). The decision is made by the domain selection policy function.

VNF Placement function may use different placement algorithms that will be designed and

evaluated in WP3 of 5G!Pagoda project.

• BSSO – it has the role of a portal to advertise the possible services, to trigger their

deployment and in case of success, to transmit to the slice administrator the specific entry

points to the new slice management. It is also used by slice tenant to reconfigure their slices

after slice deployment. The BSSO provides the interface toward the slice operator (a tenant or

vertical), including the API to query for availability of resources and blueprints, pricing

information and status of deployed resources as well as the API for uploading new blueprints,

deploying new slices and destroying slices. The BSSO is connected to one or several multi-

domain slice orchestrators. The BSSO also interfaces the OSS/BSS of the domains in which it

offers services.



5G!Pagoda orchestrators utilize TOSCA for specifying the NFVs in a slice. In particular, TOSCA is

used in the interfaces between domains as the standardized slice descriptor. New node types,

relationship and properties may be required to be defined in order to describe all necessary

detail of a slice. The OASIS TOSCA standard language allows describing the topology,

relationships and the management life-cycle of nodes in a cloud based service. TOSCA is an

extendable format, allowing definition of new node types and linking to externally defined node

types. Each node can be assigned properties – for example, a network node can have QoS

properties. TOSCA is utilized to configure NFV services. It can also be used to define the

relationships between the services.

6.3.1. Policy-Based Management of orchestration

The 5G!Pagoda management framework for network slicing is based on Policy-Based

Management (PBM) approach. This model allows system administrator to define a set of

policies that govern a behavior of distributed system or network in the flexible and simplified

manner. The key benefit of PBM approach is that network services and functions can be managed

to behave in the same way, even in case of heterogeneous systems. Management entities will

benefit from using policy rules that enable scalable and consistent programmatic control over the

configuration and monitoring of network elements and services [32].

One of the major advantages of software slices, deployed on top of common infrastructures, is

that the system can be dynamically adapted to new network conditions. This includes the

adaptation within the slice (i.e. the slice management which is part of every slice due to the

flexible resources, can adapt the functionality of the system to the most proper conditions).

Additionally, it includes the adaptation at the life-cycle management (i.e. the life-cycle

management can adapt the resources allocated to the specific slices depending on their

momentary needs as well as through brokering the available resources).

With a physical system, there is not too much liberty in terms of events that could happen and

not too many actions possible. In NFV, due to the flexible virtual infrastructure used, which can

scale on demand and due to the decoupling from the physical infrastructure, new events may be

generated, sometimes highly complex combining information from different metrics of different

components. Also, the software system has more possibilities into adaptation including scaling

opportunities, network function placement and reconfigurations during runtime for the new

network conditions. For this reason, the basic event and logging system which accompanies at

this moment the network management stack is not sufficient into a software network

environment.

The domain information (e.g. performance indicators) is exposed to the slice management, which

can use the information to e.g. replicate critical function to multiple independent domains.

Additionally, information on domain preferences, in particular regarding VNFs, can be made

available to the slice management. Moreover, FCAPS operations are supported by PBM

functionality of orchestration system.

The life-cycle management plane has multiple points in which and through specific policies, the

functionality of the system may be adapted. The PBM can be implemented as Event-Condition-



Action (ECA) or as Intent. In the Intent approach a high level description of goals are translated

by the Intent Engine into low level operations using an embedded intelligence of that engine.

Both cases have similar inputs and outputs but they differ in the internal structure.

The ECA PBM functional architecture is shown in Figure 24.

Figure 24 – Policy-Based Management: ECA case

As depicted in the figure, the ECA-PBM includes the following components:

• Monitored elements – this represents the elements from which the information is gathered,

be it part of the service, of the management of the service or as part of the life-cycle

management of the service. To reduce the communication needs, the monitored elements

may aggregate part of the monitored information.

• Monitoring (server) – the monitoring server receives all the monitored information without

any processing or qualification (all information from the monitored elements is uniform).

Based on threshold policies, the monitoring server is either logging the events and raising

alarms (as in current management systems) or it provides basic events (e.g. CPU over 90% for

a component for 3 times in the last 5 minutes) to the analytics and to the management policy

engine.

• The Event Log stores information on the outstanding basic events which are logged from the

monitoring. Alternatively, it can be increased by adding more complex events.

• The Analytics component has the role to generate more complex information from the basic

events. Depending on the type of analytics, it may provide different granularity level events

such as root cause analysis in case of component failure or even subscriber usage pattern

information. Regarding the latter, per-subscriber monitoring is technically possible through

the processing of information available at the core network (i.e. HSS), however, this operation

is highly complex and coping with privacy violation may be a challenge. The complex

information is transmitted in the form of policy triggers to the policy engine or in the form of

new policies to be added to the system.



• The policy engine is the central decision entity of the dynamic adaptation stack. Based on the

received triggers from either an analytics engine or directly from the monitoring, it checks the

system conditions and based on this, it generates a set of mitigation actions which result in

the modification of the running system.

Additionally, to this system, an event broker may have to be added to the interconnection

between the various analytics engines, the monitoring server and the policy engine. The event

broker has the role to properly route the events between the different components.

Based on the monitored information from the slice, the NFVI and the life-cycle management

components using the PBM can provide the following adaptations:

• At VIM level: migration of virtual machines, fault management and mitigation at the VM

levels, configuration of the infrastructure, infrastructure security protection, authentication

and authorization, resources scheduling for performance and resilience;

• At WIM level: establishment of new data paths, traffic steering between multiple data paths,

QoS classification and differentiation, application differentiation through deep data plane

programmability;

• At NFVO level: network functions placement in the domain, scaling policies, automatic fault

management, resilience and security through application independent mechanisms,

modifying the policies in selecting domain-specific ROs;

• At DSSO level: modifying of policies of NFVOs selecting;

• Multi-domain slice orchestrator – modifying the policies in selecting administrative domains,

SLA breaching reports, re-selecting intermediary domains;

• Business Service Slice Orchestrator – transmitting to the tenant events in regard to the system

on top of which the slice is deployed (i.e. normal behavior and exceptional events which may

influence the good functioning of the slice).

6.3.2. Interfaces and reference points of the orchestration architecture

As presented in Figure 23, we have defined multiple interfaces for orchestration system entities

and some of them are compliant with ETSI MANO framework. The ETSI MANO framework doesn’t

define protocols that should be used between functional blocks within orchestration system.

Protocols for orchestration system are still an open issue. As 5G!Pagoda we suggest to use

service-based communication architecture. The service-based approach is in line with design of

industrial orchestration solutions such as Open Baton or ONAP.

Service-based architecture uses a common message bus in order to exchange messages between

functional entities. Instead of predefined interfaces between elements, a services model is used in

which components communicates with each other via message broker. The most known

realizations of this paradigm are: Advanced Message Queuing Protocol (AMQP), Message Queue

Telemetry Transport (MQTT) or Apache Kafka. The basic architecture of mentioned approaches is

composed of a set of publishers, set of subscribers and message brokers (message buses) that

organizes messages into queues, called ‘topics’. Every published message from any publisher is



eligible for delivery into any client session, where a subscription to a specific ‘topic’ exists.

Service-based approach allows distributing functional blocks and providing scalable, reliable and

lightweight communication standard between them.

The major difference between service-based and point-to-point approach is that in the former

model services queries a service repository function, which implements service discovery

functionality. By dint of service discovery entity services may detect other communication peers,

what makes fixed reference points avoidable. This approach is closer to cloud-native networking

concept, in which libraries of functions may be requested from a network micro-service catalog

and instantiated on demand.

However, a service-based architecture may be translated into traditional reference point

architecture. Thus, we describe below the functional requirements for each of interfaces that exist

within orchestration system. These functionalities should also be applied within service-based

orchestration architecture.

6.3.2.1 Interface BSSO–MDSO

The interface between BSSO and MDSO is significant for 3rd parties and/or verticals. It acts as an

API that allows slice tenants to provision and manage network slice instances. The key

functionality of the BSSO–MDSO interface is translation of business requirements and SLAs into

technical requirements, such as network latency or resource availability. MDSO should construct

TOSCA slice blueprint based on tenant’s order.

6.3.2.2 Interface MDSO–DSSO

The interface between the MDSO and the DSSO has a critical role in creating and managing slices

across multiple administrative domains. The interface is based on the business relationship

and/or the roaming agreements between the domains of the two layers. The DSSO exposes an

API that is utilized by the MDSO This API covers functions for:

• Managing blueprints, including querying, uploading and deleting blueprints.

• Creating or upgrading a slice based on an existing or included blueprint.

• Defining policies for a slice. These policies determine the rules for resource allocation, scaling

and life-cycle operations on a slice.

• Overriding policies in terms of resource allocation, scaling and life-cycle operations.

• Removing an existing slice, either immediately or when the last UE has left the slice.

• Defining rules for UE assignments to a slice.

• Collecting statistical and usage information from a slice.

• Receiving notifications on actions triggered by policies as well as error and warning messages.

An alternative approach is reactive. In this approach, the MDSO may offer the available blueprints

and slice descriptors to the DSSO. These slice descriptors are advertised to clients. When a slice is

instantiated, e.g. one or more clients connect to it, the DSSO indicates to the appropriate MDSO,

which creates the slice or complements the slice pre-created by the DSSO.



The major format utilized in the API calls is TOSCA for blueprints. TOSCA allows specifying the

service as a recursive construct or nodes and relationship between nodes, where each node can

recursively consist of a set of nodes and their relationships. Nodes are abstract entities which may

denote applications, VNFs, VMs and interfaces. TOSCA can be extended with new node types.

Each node and relationship can have life-cycle operations defined, i.e. the actions to be

performed on instantiating, starting and stopping nodes. At the highest layer, the slice is defined.

6.3.2.3 Interface SOS–DSSO

In order to perform slice-related operations such as FCAPS management or slice stitching DSSO

has an interface to Slice Operations Support subsystem. This interface is used to provision a sub-

slice (Sub-network Slice Instance according to NGMN terminology) and to configure slice

stitching/exchange points in the data and control plane of network slice. The DSSO should

manage a border gateways of sub-slice to configure (if needed) translation between slice

domains (e.g. to perform IP-ICN translation). Moreover, DSSO should be able to enforce FCAPS

operations of network slice functions.

6.3.2.4 ETSI-compliant interfaces

The 5G!Pagoda high-level orchestration architecture is compliant with ETSI MANO framework.

We have adopted following interfaces from ETSI MANO specification:

• DSSO–NFVO/SDN-O – reference point equivalent to interface between OSS/BSS and NFVO in

ETSI MANO framework. Our architecture assumes split into NFV-O and SDN-O, which

orchestrates WAN interconnections between NFVI-PoPs. DSSO-NFVO interface is responsible

for Network Slice Instance and VNF life-cycle management including instantiation,

modification, information query, scaling and termination. Moreover, it performs VNF

package/Network Slice Blueprints management and policy management and enforcement.

• VNFM–EM – interface responsible for FCAPS operations during life-cycle of VNFs.

• VNFM–VNF – interface responsible for life-cycle management and heart-beating of particular

VNFs.

• VIM/WIM–NFVI – interface responsible for resource orchestration at virtual infrastructure

level. It allocates virtual resources with indication of compute/storage, performs life-cycle

management of virtual resource runtime environment (e.g. Virtual Machine) and provides

network interconnection between them.

• NFVO–VIM/WIM – interface responsible for NFVI resource reservation, release and update as

well as VNF software image addition, deletion and modification.

• NFVO–VNFM – this interface is used to coordinate operations that are performed by NFVO

and VIM. Before VNF is instantiated this interface is used to authorize, validate and allocate

NFVI resources for VNFs, then NFVO performs life-cycle operations via NFVO-VNFM.

• VNFM–VIM – interface responsible for querying NFVI resource information and

allocating/releasing NFVI resources by VNFM.



6.3.2.5 Interface to Slice Management

The network slice tenants (3rd parties or verticals) should be able to manage a network slice

instance that they own. To make it possible, our orchestration architecture exposes an interface

from Slice Management to Slice Owner. This interface allows slice tenants to perform FCAPS

operations according to their own policies by interacting with EM entities that are associated with

VNFs. However, Slice Management may be realized as a special type of VNF Manager that is

managed by slice tenant. In this approach generic VNF Manager is responsible for life-cycle

management of VNFs, but VNF Manager owned by tenant performs FCAPS operations. This

model assumes that interface to Slice Management is realized as interface to VNF Manager.



Slicing in the multi-domain environment 7.

It is obvious that network slicing is important in 5G and the technology will be used for a variety

of purposes. Moreover, there will be various forms of the slice. For example, slices can be

‘connected’. To create an E2E slice, in many cases, it will be necessary to go across multiple

technological or administrative domains. Creation of slices in such cases can be done in two

ways:

• The first way lies on a direct creation of the E2E on slice. In such case, the first step consists of

integration of all domain resources via multi-domain resource orchestration first. Later on,

the orchestrator that initiated the process deploys the network like in a single domain case. In

this case a single slice template is used. The approach can be applied to different

administrative domains, but it has probably limited usage in domains with different

technologies, as in which it would be difficult to exchange information among the

orchestrators about each domain specificities (especially about the hardware nodes or whole

subsystems).

• The second approach lies on the creation of per domain sub-slices and stitching them

together. This case is hierarchical one, but per domain orchestrators are loosely coupled with

the BSSO. In this case, each domain orchestrator can use its own slice templates/Blueprints

and the BSSO can ask the domain orchestrator to create a slice that fulfills specific

requirements (for example QoS). In response the local orchestrator responds with a list of

slices that can be deployed. The mechanism of local slice (sub-slice) creation is similar to the

creation of slice on-demand by the end-user; it has to be noted, however, that in order to

provide proper inter-domain operations, appropriate blocks of SOS, especially SBC have to

be properly programmed.

It is worth noting that the creation of an E2E slice as a combination of sub-slices is a preferred

solution when the slices creation is triggered by the end-users. In such case the sub-slices are

created using a parallel process; hence accelerating the E2E slice creation. This solution is also

relevant if the intermediate domain operator(s) does not allow, in its domain, creation and

operation of a slice by the BSSO. Further, this model is also applicable in case when the existing

slice is enlarged. For example, existing IoT slice, in Berlin, can be combined with an existing

identical IoT slice in Tokyo and later on with another operated one in Warsaw.

It is worth to mention that mentioning connecting (chaining) slices may impact the QoS of the

E2E slice. The process of orchestration of slices should take it into account.

7.1. Multi-domain slicing orchestration

The orchestration architecture of 5G!Pagoda corresponds to the single-domain slicing

architecture as described in the chapter 6, but it also enables multi-domain orchestration. The

main functionality of the orchestration is related to the life-cycle management of slices and less

to the slice functionality itself, thus being the same, no matter which slice type is deployed and

regardless of the domain.



As the resources are virtualized, the slices can take advantage of dynamic resources provisioning,

with different resources placement during their runtime. Hence, the infrastructure is more flexible

and available in a different combination on demand. Through this, the life-cycle orchestration is

able not only to allocate resources to a specific slice during deployment, but also to adapt them

to different usage conditions and to exceptional network situations (mainly related to fault

management, performance optimization and security). All these functionalities must be covered

by a new set of functional elements, generally named life-cycle orchestration in this specification

(especially, to differentiate from the internal management plane operations which are specific

and private to the slices). 5G!Pagoda orchestrator(s) interacts with in-slice placed SOS

components as well as Slice Management functions (that provide slice specific operations) in

order to provide proper performance of slice operations (that includes dynamic allocation of

resources) and handling alerts in an automated way.

The Infrastructure illustrated in Figure 20 may be operated and managed by single telecom

operator or it can be composed of multiple sub-domains operated by multiple operators and

providers, e.g. telecom operators, MVNOs, cloud providers. As various types of slices are to be

deployed, we note that such slices are deployed on top of various configurations of the

infrastructure, where configurations are possible mainly because the resources are virtualized (i.e.

dedicated and isolated) for a specific slice.

Figure 25 – Life-cycle orchestration for multi-domain architecture

To be able to use the resources in an appropriate manner across the administrative domain, an

administrative domain resource orchestrator, named here Aggregation RO, is considered on top

of the technology specific ROs. Aggregation RO aggregates all the resources into the same RO,



through this operation, making the resources transparent to the DSSO. Aggregator RO performs

a hierarchical type of resource aggregation. For example, in Figure 26, an Aggregation RO can be

considered for the radio technology domain across the different technologies and spectrum

used.

The Aggregation RO has an overview of all the resources inside an administration domain in

order to place VNFs and create related NFFG (Network Function Forwarding Graph) across

different resources, including multiple data centers, transport and different wireless accesses. The

underlying reasons of this architecture are manifold. Primarily, with the global view of all the

resources inside an administrative domain, the global RO can optimally place VNFs on the

underlying resources, according to VNF’s requirement, such as affiliation and special hardware

requirements. Besides, inside an administrative domain, the environment could be multi-

technology as well as multi-vendor. Such recursive orchestration enables clear separation of each

domain’s responsibilities and facilitates reliability and scalability as well as enables the

enforcement of different policies in each domain.

Figure 26 – Recursive resource orchestration

The DSSO is in charge of E2E orchestration with the interaction of the global RO. In this case, the

DSSO is similar to NFVO as defined by ETSI MANO, but with additional functions. Indeed, the

latter are used to interact with the multi-domain slice orchestrator, for example, north-bound

APIs for the multi-domain slice orchestrator to consume. The entity for handling the E2E

orchestration has to be able to collect and to transmit the contact points, which enable the

interconnection with other administrative domains including: IP addresses within the technology



domains to connect different technologies from different administrator domains, IP addresses

where virtual networks from one domain are bound to the other, technologies of the virtual

networks binding the two domains and VNF level IP addresses in case the slice network is

explicitly settled across the domains. Note that IP addresses are allocated in the slice based on a

common addressing schema, which is done through the orchestration, as in the case of any PaaS

or NSaaS, but not for IaaS where only resources are allocated and the tenant has to create the

network through its own administrative means.

To be able to broker and to bind resources within multiple administrative domains, a multi-

domain slice orchestrator is introduced into the system. The multi-domain slice orchestrator

communicates with the orchestrators in the administrative domains to be able to stitch a slice

across the multiple administrative domains, by using resources allocated in each of them.

The BSSO is added in the logical multi-domain management to be able to interact with the

administrator of the slice in the management of the life-cycle operations and to offer the

administrative entry points to the software elements from which the slice is composed of.

7.2. Slice identification

As it has been already discussed there is no yet provided standardized slice identification. In the

5G!Pagoda architecture we proposed such identification looking into multi-domain operations

and slice selection issues. In the approach proposed by 5G!Pagoda, each network slice is

identified by Network Slice Identifier (NSID) and by Network Slice Identifier for

Orchestration (NSID-O), which allows identifying a particular slice instance within an

orchestration system.

The Network Slice Identifier (NSID) is comprised of:

• Operator Identifier (mandatory) – required field that specifies, which operator should handle

an end device. In 3GPP terminology, Operator Identifier may be a pair of Mobile Country

Code (MCC) and Mobile Network Code (MNC) allocated for serving PLMN as defined by

3GPP.

• Slice Class Type (mandatory) – required field that specifies the usage class of end-user

application. Network Slice Instance should be selected by mobile core based on Slice Class

Type. If there are multiple Network Slice Instances of the same Slice Class Type, selection

policy is up to a network operator.

• Slice Tenant Name (optional) – optional field that specifies tenant of requested slice instance.

This feature is required in multi-tenant mobile network. If Slice Tenant Name (and Slice

Tenant ID) is part of NSID, end-user’s attach requests should be passed directly to a network

functions managed by tenant.

• Slice Tenant ID (optional) – optional field that is strictly associated with Slice Tenant Name.

Slice Tenant Name and Slice Tenant ID should be provided together to use network slice

instance managed by tenant.



• Slice Service Linkage (optional) – optional field that may be used as assistance information to

Slice Class Type. This parameter points out specific service linkage e.g. YouTube, NetFlix,

Facebook, Twitter, etc.

• Quality Constraints (optional) – set of optional parameters that specify quality-related

properties of network slice instance. It is usable in case of NSaaS approach. 5G!Pagoda

architecture allows users to requests Network Slice Instances on demand. Then, quality

constraints should be passed. Otherwise, the best effort network slice will be allocated for

particular application (which is also the default case when a specified by UE slice can’t be

found).

• Additional Parameters (optional) – set of parameters allows 3rd parties, tenants and operators

to customize network slice identification scheme, what impacts slice selection procedure and

policy.

The Network Slice Identifier for Orchestration (NSID-O) identification format is dependent on

implementation and some hash function may be used to generate unique NSID-O. However, for

management and orchestration purposes some additional information should be associated with

NSID-O. The NSID-O set of parameters should include:

• Unique Slice Identifier (e.g. hash code);

• Slice Number;

• Slice Type – technology dependent (4G RAN, EPC, etc.). A special case of Slice_Type is the

Composite Slice, i.e. the slice that is composed of more than one sub-slice. In case of 3GPP it

can be described as eMBB, uRLLC or mMTC;

• Slice Tenant;

• Slice Quality Parameters;

• Identifier of BSSO that manages particular slice instance.

The set of parameters for NSID-O is only a suggestion and it may be treated as implementation

hint. The key agreement is that network slice instance shall be uniquely identified within the

orchestration and management systems.

The proposed schemes are in line with 3GPP approach. The concept described in this section will

be evaluated and refined during testbed implementation. The feedback from implementers will

impact Deliverable 2.5, which will describe the final architecture.

7.3. Inter-slice operations in multi-domain slicing

The multi-domain slicing requires specific orchestration, but also operations that support inter-

slice communication. From the operation point of view, the following operations have to be

implemented:

• Placement of a gateway between the neighbor slices. Any two interconnected slices may use

different communication protocols. Protocol conversion gateway is necessary in that case and



the orchestrator should place an appropriate gateway server function in a suitable place. The

conversion may deal with the data as well as control plane operations.

• Notification of the connection to a new slice. It is necessary to notify that a new sub-slice is

interconnected in order to optimize its operations (for example another area is covered by

the service). In some cases, a slice can handle such change and adapt to it, but in some other

cases the orchestrator should be involved in this process.

The slice exchange abstracts the interactions to domain-specific orchestration systems (DSSO in

this case), implemented for the individual domains. Thereby, it enables each domain to have a

single set of transactions to control and manage the network slice built over multiple domains.

This can bring the individual domains a significant benefit, when there are three or more domains

interworking with the individual virtualization platforms and operational processes.

The mentioned functionalities are part of the Slice Border Control (SBC) of Dedicated or Common

Slices. The SBC functionalities are typically split between the control plane (SBC-C) and the data

plane (SBC-U). Details are implementation specific.

7.4. Management of multi-domain slices

In case when the E2E slice is a multi-domain slice and each domain slice has its own Slice

Manager, the Slice Manager that is closest to the slice operator becomes Master Slice Manager,

whereas all other slices Managers become Slave Slice Managers. All the Slave Managers interact

with the Master Slice Manager, which is also used by slice operator to manage the E2E slice.



Slice templates 8.

In this chapter a slice architecture template is exemplified for a set of relevant 5G!Pagoda services

and components, including RAN, core network, CDN and IoT application level services, as a

means to extend the proposed concept towards the standardization of the new software based

networks. Additionally, the proposed example will be used as a blueprint for the software

implementation of the active service within the different slices as well as the main vehicle for

extending the active service implementation towards other services.

Although starting from a comprehensive example, in order to be able to show the utility of the

slice architecture template, whenever possible, the generalization of the concept will be also

included as well as the possible specific limitations towards other services.

This chapter is composed of three sections aiming to answer to the main concerns about the

application of the concept to software networks as well as specifically to 5G network slices:

• Example of a slice architecture template – the example itself will provide the means to

describe in a flexible manner a set of possible implementation architectures depending on

the service means.

• How to apply the slice architecture template – the example slice template will be instantiated

for a set of use cases and addressing a synthetic deployment model. Specifically, the massive

IoT and the content delivery applications are described, representing limit cases of the

architecture.

• How to extend the slice template – the mechanisms to add new functionality to a slice

architecture template is described giving the best practice on how to extend the network

blueprint with new components or how to create a new blueprint.

8.1. Slice architecture template example

In this section, a slice architecture template example is presented for a large number of the

components, which are expected to be part and customized for the specific requirements coming

from the use cases of the tenant of the slice.

The presentation of the slice architecture template is based on the network functions services

perspective, with a minimal initial grouping as network functions. The main reason for not

completing the grouping is that depending on the use case, the functional split may be different

between the different software components, thus resulting into new network functions.

As illustrated in Figure 27, the slice architecture template includes components coming from

different groups of functions including RAN, data plane with its data plane management, control

plane and integrated CDN functionality, IoT specific components and the slice management

components. Due to the high complexity of such a network, the slice architecture template here

presented is simplified in the sense of describing each functionality, more about how it can be

implemented being described in the deliverable D3.1.



Figure 27 – Slice architecture template example

For the RAN part of the example slice architecture template, the 4G LTE functionality was used as

being currently the latest available one. Several groupings of services are considered:

• Physical Radio Related – PHY and MAC of the radio environment. This functionality deals with

the transmission of raw packets over the environment in a scheduled manner.

• RAN Resource Scheduler – the role of the scheduler is to allocate the radio resources to the

different communication data flows for the different end devices.

• Controlled forwarding – protocols, which enable the forwarding of both data and control

plane between the end devices and the base station. The controlled forwarding ensures that

the packets are properly transmitted over the environment.

• System connectivity – functionality of data and control plane, which enables the connectivity

to the system. This includes for the data plane of the base station, the forwarding to and from

the connectivity system and for the control plane, the signaling with the core network and the

selection of the core network components to which to connect to.

For the control plane of the system, the following functionality is considered:

• Access Control – the access control includes the identification of end devices, the

authentication and authorization up to differentiated access control for devices and

applications.

• Mobility – spanning from reachability from the device to the central entities up to the zero-

packet loss seamless handovers across the environment.

• Session management – spanning from the transmission of unacknowledged messages up to

best effort bearers to guaranteed resources for a bearer.



• Security – ensuring differentiated secure levels depending on the slice deployment.

For the data plane, there are two types of functionality, related to the forwarding of the data

packets and the data plane management. The Data Plane is composed of the following groups of

functions:

• Forwarding related functionality which includes apart from the basic forwarding load

balancing, high availability, traffic engineering (traffic steering), classification and path

selection (for single or aggregated data flows), broadcast and multicast. This includes the

separation into the different QoS classes and the differentiated forwarding.

• Slicer functionality, which is able to separate the data, flows of one or more slices to execute

specific functionality on the data path which may be split at slice level or at data flow level.

The additional functionality includes:

• Downlink caching – functionality used by the idle mode devices to buffer data traffic until the

devices become active again.

• Tunneling and overlay protocols – spanning from MPLS to GTP, the tunneling and overlay

protocols have the property to provide flexibility in the processing of the data path. At least

two data path components are included.

• Security protocols – encryption protocols.

• Content storage – enabling the storing of the content at data path level as in the case of CDN

networks.

• Data aggregation – and other data processing elements located at the data path level

ensuring that the communication is optimized by providing a minimal overhead. Data

aggregation represents a mechanism for data compression.

For all the data plane functionality there is a set of control plane functions enabling the

appropriate functioning of the data plane only such as the routing protocols or the slice

controller at the network level. These functions are complimenting the control plane previously

described, which is mainly oriented towards subscriber communication with data plane only

related functionality.

IoT network related components have a similar structure including a set of services which may be

instantiated for different network areas i.e. gateways, relays, backend network, etc. The network

function services available include:

• Communication functionality which enables to communicate over the network starting from

capillary radio networks (e.g. ZigBee), SMS up to IP connectivity, proxies and adaptors for

different IoT communication protocols, data formats and processing of the data.

• Data processing functionality including data aggregation and data dissemination based on

the connectivity management functionality.

• Connectivity and data analytics enabling the processing of the received information from the

devices.



For all of these functions a set of network management functions have to be added to ensure

that the service is behaving according to the service layer agreements (SLAs) and that the system,

as much as it can, is adapting to the specific limits in order to maintain the SLAs. This includes the

monitoring, policy-based decisions and analytics functionality enabling the FCAPS functionality.

The slice architecture template model presented does not aim to present a complete set of

functions but a more holistic perspective on the slice functionality in order to provide to the

tenant a perspective on the large set of variation functions and parameters, which may be

configured into a software system. Although not complete, this Blueprint exercise gives the

possibility to the tenant to choose which functions to deploy within its system. Considering the

Figure 27 example, one tenant can choose which type of service to run by selecting one of the

network function services and then to instantiate the specific one.

As previously presented, a slice architecture template is rather complex and in order to make use

of it in live systems, most of the network functions will be pre-configured and pre-parametrized

by a set of similar slice template architecture blueprints with less flexibility in the features.

Although not directly specified, as in the case of the current architecture, there are several

grouping limitations for the different network function services, which would result into the

requirement that they will be always co-located into the same network function in order to have

the proper active service.

From the perspective of the data plane, a chain of functions will be created which functions may

have the same or different functionality for the E2E data path within the slice or differentiated for

the data services. Because of this, the implementation of the data plane presumes the proper

selection of the functionality from the slice architecture template in order to be able to reach the

expected result. Similarly, for the IoT network components or the CDN functionality, the same set

of basic functions can morph for having different roles in the E2E service delivery.

From the perspective of the control plane, next to the split into network functions of the

functionality (e.g. access and mobility together, session control separately) there is a need to

characterize the service in terms of how much is offered in each of the specific functionality

groups. From this perspective, the control plane is represented by a set of network functions,

which may have ‘more’ or ‘less’ of the specific functionality type, which has to be parametrized

from the external components. In the control plane case, the slice architecture template has to

define also a set of levels of the specific functionality, which are made available to the tenant.

The RAN components may be separated into data and control plane and thus the previous

considerations will apply.

From the management perspective, each of the different slice architecture template components

may come with their own management components as the active service functioning is a result of

the inter-operability of the data plane, control plane and application level components and not a

matter of the inter-operability at the management level. Hence, the management components

can be independent for each component, not affecting the functioning of the system, albeit

drastically increase the cost of managing the slice. For this scalability reason, several network

function services may be grouped into the same functionality especially the monitoring, analytics



and policy-based decisions and actuations while other functionality is specific to the specific

types of management e.g. fault, configuration, administration, performance or security. From the

perspective of the slice template, multiple network function services of the same or of different

types may be offered as long as they can be easily integrated into an E2E service offering. It is

important to state that the Fault, Management, Administration, Performance and Security

components shown in the Figure 27 refer to the FCAPS function located in the Slice Operations

Support part and the rest of management components shown there is located in the Slice

Management part (refer to the slice architectures defined in the section 6.2).

8.2. Application of the slice architecture template

In this section, two examples of how the slice architecture template can be applied are given, one

for a massive IoT service and one for a content delivery network. Several other examples may be

considered from the perspective of the active service and along with the two examples here

presented will be later developed in WP3 deliverables.

Figure 28 – Deployment network architecture example

For this example, a very simple network infrastructure is considered, which infrastructure includes

a set of cloned edge nodes (e.g. compute units located in the backend of local networks) and a

single central node. Some devices will connect through the local network and thus will be able to

benefit from the network function services deployed on the edge node and some other will

connect through the wide area network and thus have to connect directly to the central node.

The deployment network infrastructure is illustrated in Figure 28. Because of the uniform network

architecture assumption (the service is the same for all subscribers, the edge nodes have the

same capacity and the same service requirements), the network function services will be

deployed uniformly across the edge nodes and with a counterpart in the central node to be able

to serve the devices which cannot be served by an edge node.



These simplifications are necessary in order to be able to make easy comprehensible for the

reader the deployment model, otherwise, existing the risk to get lost into details and missing the

basic features of the proposed deployment blueprints.

Additionally, although the RAN components may be split as described in the next sections, for

the simplicity in the next examples they will be considered unitary and of the same technology.

Please note that the application examples here refer only to single customized slices, the slice

stitching and the split of a service across multiple slices being described in the other sections.

8.2.1. Massive IoT slice architecture template application

The massive IoT slice has the role to receive information from a massive number of IoT devices in

the best effort manner and to transmit commands to some actuation devices in a highly reliable

way. Detailing this requirement, a large number of devices will transmit a large amount of

information towards the central node, thus making sense to have data aggregation as close to

the device as possible, process the information in the central node and respond with reliable

actuation commands to another set of devices.

As illustrated in Figure 29, the massive IoT slice includes a set of components split between the

edge and the central node. The components of the edge node will be also deployed on the

central node in order to connect the devices, which are directly connected and are not illustrated.

Additionally, subscriber and service database are not illustrated, neither the management plane

components.

Figure 29 – Massive IoT slice architecture

The edge node includes five distinct network functions:

• Access Control ensuring the authentication and the authorization of the devices to

communicate over the environment – as the devices will communicate only with messages,

the authentication will be executed with typical core network secure authentication

mechanisms and the authorization for the sporadic messaging communication.

• Mobility and Session management component is ensuring that a ‘data path’ is established for

reaching the devices both for in-bound and out-bound communication as well as to

communicate with unacknowledged and acknowledged messages.



• The ‘data path’ is composed of two components, one enabling the broadcasting of the

downlink messages only and one, which is classifying the received messages and data traffic

towards the IoT gateway respectively the aggregated data towards the IoT backend. The

second component has the role of SCEF in NB-IoT architecture as well as of the inter-data

center forwarding.

• The IoT Gateway has the role to interconnect with the devices, to decode and encode the

messages appropriately to the devices and to aggregate them and to forward the aggregated

message to the IoT backend.

The central node includes the IoT Backend, which has role to aggregate the data from the

multiple IoT gateways, to execute the logic of the service with the specific data analytics.

In order to complete the instantiation of such a slice template the most important item to fix is to

ensure the appropriate logic of the service.

8.2.2. Content delivery network slice template application

The content delivery network slice template application has the role to distribute content in the

most efficient manner for the backhaul by caching content at the edge of the network. For this, a

low number of devices are consuming a large amount of bandwidth to download large content

such as video. In this case, it makes sense to have a content storage at the edge where the

content already sent on the downlink is stored for next usage.

As illustrated in Figure 30, the CDN slice includes a set of components split between the edge

and the central node, specifically ensuring the authentication and the authorization of the devices

at the edge while the content management is centralized. Subscriber and service database are

not illustrated.

Figure 30 – CDN Slice Architecture

The edge node includes five distinct network functions:

• Access Control ensuring proper authentication and authorization as well as differentiated

access to the services.



• Mobility and Session management component enables the zero-packet loss mobility through

default bearers, which are implemented using tunneling and overlay protocols.

• Content management – enables the control of the specific content, which is stored by the

edge node and the communication with the central content management. Additionally, it

may receive content requests from the users.

• The user plane function includes for the forwarding the means to classify the different data

flows and if needed to broadcast content to multiple devices. Additionally, for the specific

data flows it maintains the tunneling/overlay ensuring the zero-packet loss mobility as well as

the content storage. For this, the flows are split by the slicer towards different processing

paths.

The central node includes two components:

• The content manager – ensuring the control of the content distribution across the system.

• The user plane function – includes the functionality to steer the content in an appropriate

manner to the edge nodes (traffic engineering), the classification of the data flows as well as

the forwarding mechanisms.

Similarly, to all the other slice instantiations, the service logic has to be added to the slice

template architecture instantiation in order to be able to run properly the service.

8.2.3. How to extend the slice architecture template

In order to be able to use the slice architecture template for other services and application, there

should be an easy means to extend the functionality. For this, a set of interfaces have to be

defined between the different network functions or between different network function services.

As long as the interfaces are properly defined such as in the case of the high-level descriptions in

the previous sections for the massive IoT and the CDN networks, the components should be

simply added to the slice template.

For more details on how the different network function services are communicating between

them either when they are located within the same network function or when they are located in

different ones as well as on how to configure a network function service to have more

functionality within the control plane, please check the deliverable D3.1.



Key implementation elements 9.

In this chapter a series of key implementation issues are considered and further detailed as part

of the high level architecture. The concepts presented in this chapter are remaining as key

technology development items for the rest of the project and will be further detailed into the

next technical deliverables. Indeed, the conceptual description of the key implementation

elements represent the main approaches taken by the 5G!Pagoda project in order to implement

the missing key technologies as well as to enable the proper integration within a comprehensive

system of the existing 3rd party developments.

9.1. Generic Virtual Network Functions implementation

considerations

Effective network slicing approach requires high granularity of lightweight network components.

In each of the slices a set of Network Functions (NFs) will have to be deployed, representing the

different functionality required to run the active service. Depending on the type of the service

deployed the network functions may pertain to one or to many of the different network

functional domains including RAN, edge and core system components, CDN, ICN and the

correspondent active service management components including monitoring, PBM, FCAPS, etc. In

this section a new concept of slice architecture template is introduced in order to properly

describe the active service components which are running inside a network slice. In the following

architecture specification sections this high level concept is exemplified for different network

domains and an integration mechanism is described.

With the current evolution within the 3GPP environment towards software network systems, the

definition of the network functions (NFs) has suffered a major modification, which will result in

major changes on how the architecture for the system has to be described and how it will be

applied for the different customized systems.

Until the 4G networks, the NF was defined as a specific component, directly associated with one

or more physical boxes, having an input, an output, a transfer function and a state maintained

independently for each of the connected devices or data connections (Figure 31i).

Based on the input and the state, the transfer function was modifying the state itself and

generating an output. With this simple model, the network functions had to be comprehensively

characterized considering their elements from an IETF based on the interaction with the input

and output and from the perspective of 3GPP including state and parts of the transfer functions,

the rest remaining open for differentiated added value of the different implementations. A careful

planning of the state of the transfer functions resulted into comprehensive systems in which each

of the components was optimized for a specific functionality considering also the need to group

specific functionality within same physical boxes.

With the evolution towards software networks, there is a new capability emerging, namely, the

network functions may include or exclude different network services which have their own

specific input and output. Additionally, the network services may share the transfer function or



may be independent. Additionally, the different NF Services may have integrated and

independent state maintained.

As a result, the software 5G network functions are becoming more flexible in terms of which

functionality is grouped with each other, enabling for the specific use case to fully customize the

functionality not only in terms of parametrization of the various components, but also in term of

how the different functions are grouped. Two networks having exactly the same functionality in

terms of network services may have different grouping of the network services within the

network functions, resulting in different quality and performance of the service offered to the end

subscribers.

Figure 31 – Modification of the High Level Functionality with the Software Network

Functions

From this, we may consider that network functions concept is not necessary anymore as the

network function services are representing the atomic functionality from which the E2E services

are composed of, alternative which is known in the literature as micro-services architecture

(MSA). However, MSA suffer of a major limitation: each of the services has to maintain its own

state, resulting in the implementation of a large number of interfaces even when the services are

grouped within the same network function which in its turn results into large communication

delays due to the multiple encoding and decoding and transmission of messages as well as into

the requirement to manage a large number of components.

A better mechanism will be able to combine the specific network services within same network

functions with common transfer function logic and with a single state machine, through this

being able to optimize the processing within the network function while at the same time

benefiting of the flexibility of the micro-services architecture.

The 5G!Pagoda architecture introduces a new concept of slicing architecture template in which

the architecture of the active service is described in term of network functions services which are

then grouped based on the requirements of the specific use case in different network functions.

The slicing architecture template is a representation model of the network functionality



stemming and representing a fusion of the micro-services architecture (each functionality is

separately described) and the classic network functions architecture (functionality is grouped into

network functions with a single state machine and a common transfer function logic) aiming to

describe the system in terms of functionality as well as how it may be deployed.

The most important functionality which will be later described in the D3.1 is related to how to

provide the proper interaction between the different Network Function Services when co-located

within the same network function or in different network functions as well as the mechanisms of

load balancing when the communication is both types of network function services (local and

remote). To maintain certain cohesion of the service, the interactions are defined and the specific

mechanisms are deployed at the slice deployment time and remain unmodified during the

service life-cycle. Other more dynamic mechanisms may be defined, however, not under the

consideration at this moment, as we expect that a slice will not change its expected KPIs during

the life-cycle of the service.

Figure 32 – Abstract example of the concept

In Figure 20, an abstract example is presented including two paths through for the subscriber

user such as one for control plane and one for the data plane. The different network services of

the same type which are located on different network functions need to have a synchronization

interface (green) in order to be able to share the state. Additionally, the components of the

processing path which are co-located on the same network function may have an internal

interface (red) which enables the coordinated response to the input request. The internal

interface may be implemented through specific local communication mechanisms (e.g. shared

memory, inter-process communication bus, etc.) and does not necessarily needs to include the

typical interface communication (encode-decode, message processing, protocol state machine),

taking advantage of the shared resources within the same network function. The processing

paths (red) will include more network functions which will execute one or more of the services.

The processing paths may include the same network function services for all the processed

requests or only some depending on the differentiation of the services within the slice.

Additionally, the processing of a network service may be executed in the same network function

with another or in a different one (or none at all if not needed), decision which will have to be

taken through some new load balancing mechanisms.



In order to be able to properly install the specific service, the active service mechanisms have to

be exposed to a Network Service Template (NST), as defined by 3GPP, which enables the slice

tenant to select the appropriate behavior of the service. From this perspective, the slice template

architecture comes to respond to the NST high level description with the proper implementation

architecture for the active service according to the NST requirements.

The considerations here presented for the implementation possibilities for the software network

functions aiming to respond to the different use case needs will be further refined in the

description of the lightweight core network as well as in the mechanisms to further add

functionality on top of the lightweight core network according to the specific requirements of the

slice tenants.

9.2. Slice selection, matching and advertisement

In this section, an assessment of the possible mechanisms for slice selection functionality is

presented. Slice selection represents the functionality of the system which enables the end

devices to connect to the appropriate slice while accounting that slices are dynamically deployed

and removed from the system.

The available mechanisms for slice selection can be classified as:

• Network based mechanisms in which the network is in charge of selecting the appropriate

slice for the UEs while the devices are unaware which would be the selected slice;

• UE controlled slice selection mechanisms in which the UE makes the decision to which slice to

connect;

• UE assisted slice selection mechanisms in which the UE makes an indication on which slice

should be selected and the network will select based on the indication the appropriate slice.

For network based mechanisms, there are two main high level functions: proxy and redirect.

Proxy slice selection functionality presumes that there is a Slice Selection Function (SSF) located

in the network which will select the appropriate slice for processing the service of the subscriber.

In this case, part of the functionality should be located in the common slice functionality. For

example for the 5G system, as illustrated in Figure 33, if the Access and Mobility Function (AMF)

is part of the common slice, the SSF will be a functionality added to the AMF to select the proper

Session Management Function (SMF) which in its turn will select the proper data path

components. In case the AMF is not part of the common slice, then the SSF will be selecting the

proper AMF to which the devices to communicate to which will result into a redirect to the

proper AMF through the Network Slice Selection Function (NSSF) of the (R)AN.

A network based slice selection mechanism must be implemented in order to be able to handle

properly legacy devices which are not aware of the multi-slice system and are not able to

implement UE controlled or UE assisted mechanisms.

As the current standardization within 3GPP is still in very early stage, there was no clear decision

made if the AMF will be part of the common slice (as having the role to manage the access and

the mobility of the devices to the common access network) or if the AMF will be also part of



dedicated slices (as having the role to maintain customized access and mobility through the

same or through customized (R)AN components). Based on this decision, one or the other of the

mechanisms will be selected.

Figure 33 – Network-based slice selection mechanisms

In the UE controlled slice selection model the UE makes the decisions to which slice to connect.

For this, it includes a Slice Discovery Function (SDF), which should receive dynamically the

information on the slices available and to which the device is allowed to connect to. The

information on the available slices is received dynamically from the Slice Discovery Advertisement

Function (SDAF) which is located in the network and has information on the deployment and the

termination of the different slices as well as on their specific identifiers and other information

which can be transmitted to the UEs in order to make an informed selection decision.

The Slice Discovery Function (SDF) is the end-device function that is responsible for acquiring

slice attachment information, especially NSID, which is used to request an access to a network

slice. The 3GPP in TS 23.501 uses a term of S-NSSAI, which is composed of list of ‘Service/Slice

Type – Slice Differentiator’ pairs. As 5G!Pagoda we propose to use slice identification format

described in the section 7.2, because it allows to pass an additional parameters of slice like QoS,

security level or specific application requirements, e.g. YouTube. Moreover, in 3GPP terminology

Slice Differentiator is loosely defined, thus we propose more detailed parameters of NSID.

However, Additional Parameters (AP) field allows adding some customizations.

The communication between the SDF and the SDAF can be executed using two different

mechanisms:

• Slice advertisement – the SDAF is broadcasting information towards the UEs whenever there

is a change in the network slices available in order for the UEs to change their slice decision.

This type of operation requires a large number of messages to be transmitted to the UEs and



it is necessary only in case the UEs may change their slice while attached to the network (i.e. if

a new slice appears in the network, the UEs will hand-over to the slice for a better service).

Alternatively, the slice advertisement can be used to push updated slice discovery information

to the UE to be used for a subsequent attachment to the network in order to be able to

speed up the process.

• Slice discovery – the SDF is querying the SDAF on which slice to select at specific moments in

time. This can be done synchronous to the attachment procedure, in which case the UE

should connect through a default (or previously selected slice) or can be done at regular time

intervals, through which the UE queries during its attachment on which next slice to select.

The device should know all slice instances that are available in its geographic area. In case of

attach-based acquirement of NSID, SDF function is responsible for obtaining from network a list

of NSIDs. The list should contain only network slice instances that end device is allowed to use. In

this phase some procedure of Access Control should be performed using UE subscription

information. The end device may request an access to a specific network slice instance identified

by one of the NSIDs in the list.

Figure 34 – UE controlled Slice Selection Functionality

From the perspective of the functionality placement, SDAF may be part of the attachment

process or it may be only a recommendation function which transmits information over the

established communication paths.

In the first case, the SDAF entity should be the first point of contact for every UE/device that

wants to connect to a mobile network. The UE attach requests should be load-balanced and

routed to SDAF based on RAN policy. The SDAF and UE should perform basic authentication and

authorization as well as redirect the end device to appropriate network slice. The address of

network slice gateway e.g. IP address should be delivered. Then device is served by network slice

mechanisms. For instance, session management is performed within a network slice connection.

As the authentication and the authorization are performed in the AMF for the attachment to the

RAN, this type of functionality is considered redundant mainly because there is no need for

double authentication to the RAN.

In the second case, the SDAF is similar to the ANDSF (Access Network Discovery and Selection

Function of the 3GPP 4G system) in which after the device attaches to the network to either a

default slice or to a previously known slice, new slice information is transmitted to the devices. In



this case, the communication can be established over the data path and the information can be

transmitted either in the push (SDAF broadcasting) or pull (SDF queries) mode. The pull mode is

preferred as long as the devices do not have to take an immediate decision to disconnect and to

connect to a new slice in case a new slice appears. Especially in this case, a grouping with the

ANSDF would be beneficial in case the (R)AN also has to be selected as there may be a slice

separation starting from the physical environment.

The same process of slice selection may be used also for non-3GPP devices such as IoT LoRa

devices. However, it is likely that IoT nodes will have predefined slice type which will not change

during the lifetime of the device. For the sake of energy saving an IoT node does not exchange

signaling information with network and may have the NSID pre-configured in local memory. In

this case, the IoT node sends request for particular network slice instance directly, so the static

way of slice selection is used.

As the UE selection may be misused to gain access and to execute different types of Denial-of-

Service attacks, the UE selection should be complimented in the network by a proper access

control in which only the selected devices will be allowed to connect to the specific slices and by

the network slice selection means in order to properly select in the network the slice for the

legacy devices and for devices for which the discovery information is not anymore actual. These

mechanisms are generically name UE assisted slice selection. The UE assisted slice selection is

practically a combination of the UE selected mechanisms with a network backup in case the UE

slice selection is not properly made.

From the perspective of this specification, the UE assisted mechanisms present the highest

probability to get standardized by 3GPP as a similar decision was taken in the similar case of

access network discovery and selection. With this consideration, depending on the immediate

next steps in the 3GPP standardization, an implementation decision will be taken by 5G!Pagoda

to select and to foster the development and the acceptance of the proper slice selection

mechanisms for the 5G system.

9.3. Inclusion of hardware nodes and subsystems

The mobile network operators currently operate hardware-based and non-NFV enabled network

equipment. The slicing concept is mostly based on the software components. There is however

an important need to include the legacy solutions (especially 4G and data transport networks)

into the network slicing ecosystem and provide a smooth migration of NFs from hardware based

solutions to software based ones. There is no doubt that during the transition phase both

solutions will have to coexist. Therefore, the slicing environment has to be aware of HW-based

entourage and its MANO layer should be able to interact with hardware solutions. The MANO is

already incorporating hardware nodes as PNF (Physical Node Functions), but in the context of

slicing we are going beyond a single PNF and include in the overall picture also Hardware

Networking Solutions (HNS) as whole subnetworks, i.e. complete solutions based on PNFs only.

The HNS systems or PNF nodes are part of the 5G!Pagoda reference architecture. They are

typically used as a part of the Common Slice, however some of them may already exhibit some

features that will make them ‘sliceable’, for example they can be seen as virtual routers or devices



for VPN creation that in turn that can be used by different slices. It is also worth to mention that

some new networking concepts like SDN use software based components in the control plane,

however the data plane is still hardware-based that is not programmable per se (OpenFlow

switches are typically made of hardware).

The generic concept of integration of VNFs and HNSes/PNFs under the same MANO is proposed

in 3GPP TS 28.500 [27] and shown in Figure 15. The interaction of MANO with HNSes/PNFs is

performed via EM or NM/OSS functions (Ve-Vnfm-em and Os-Ma-nfvo reference point

respectively). In case of HNSes/PNFs without dedicated EMs or NMs/OSSes they can be

controlled via embedded management agents. As the MANO-NM/OSS and MANO-EM interfaces

contain FCAPS functions from the functional point of view (see: [33], [34]), the westbound

interfaces of EMs and OSSes/NMs (or management agents inside NEs) should provide mediation

of EM/NM/OSS native interface to MANO-compliant interface, especially:

• Translation of EM/NM/OSS internal data model of HNS/PNF exposed services to the required

level of abstraction of MANO data model.

• Supporting of NF lifecycle operations (except those exclusively specific for VNFs, as PNF can’t

be totally decommissioned, otherwise it will be lost for management), especially full needed

PNF (re)parametrization according to service (re)design by MANO.

• Supporting of MANO Configuration/Security Management needs – the orchestrator’s

repositories have to have the accurate vision of services installed in PNFs and PNFs

capabilities/utilization; this requirement of the on-line awareness of HNSes/PNFs utilization

status becomes acute if multiple channels of HNSes/PNFs management (terminated at

MANO and non-MANO domains) with overlapping areas of control are allowed.

• Supporting of Fault/Performance/Accounting Management operations according to the

HNSes/PNFs specificity and their services model, as it is recognized by MANO (F/P/A-related

data should follow the hierarchical model of managed objects).

From the perspective of the 5G!Pagoda, the physical nodes are seen as virtual nodes with very

limited capabilities i.e. they can maintain only a single static functionality of a single type which

has to be shared between the multiple slices. With this, the physical boxes may be remotely

managed and integrated into the different slices representing either a common part or can be

stitched as a common slice within the E2E system.

Apart from legacy systems compatibility, network slicing platform can make use of other

hardware-based networking solutions in order to increase its performance. The ETSI NFV has

specified “NFV Hardware Acceleration Technologies” concept [35]. This approach assumes that

VNF is not fully-virtualized, but some of the VNF’s functionalities are realized by hardware. The

acceleration model enables VNFs to leverage acceleration services from underlying infrastructure,

regardless of their implementation. Hardware-based accelerators may increase performance by

performing such operations as network stack acceleration, network payload acceleration,

cryptography, transcoding, storage, digital signal processing (DSP), or algorithmic acceleration.

There are various technologies supporting NFV Acceleration. For instance, DPDK or

OpenDataPlane (ODP) may be used to provide a set of libraries and drivers for faster packet

processing on x86 architecture. The NFV Hardware Acceleration technologies will be evaluated



during forthcoming 5G!Pagoda project phase, as it is related to the data plane programmability

concept described in the section 9.5.

9.4. RAN slicing

One of the key technologies into the development of an E2E customized system is the RAN

slicing, where the same RAN is offering customized functionality to different groups of

subscribers, especially related to the access and the communication over the shared wireless

environment. This functionality enables the shaping of the wireless resources according to the

service needs as represented into the specific slices.

9.4.1. RAN slicing options

Focusing on RAN slicing, there are different envisioned models to implement it. Depending on

the level of resource isolation we aim to achieve, these models are: dedicated resources and

shared resources models.

In the dedicated resource model (i.e. most of RAN functions implemented as Dedicated Slice), the

RAN slice is built by separating and isolating slices in terms of: control and user plane traffic,

MAC scheduler and physical resources. Each slice has access to its own communication protocols

(such as RRC, RLC, PDCP and MAC in case of LTE) and the physical resources are strictly dedicated

to a specific slice, e.g. a percentage of Physical Resource Blocks (PRB)s is dedicated to each slice,

or a subset of the channel is dedicated to each slice. Although dedicated resource model ensures

committing elementary resources to the slice, but, it reduces the slice elasticity as well as

scalability and limits the multiplexing gain. Indeed, using the dedicated resource model does not

allow a slice owner to easily modify the amount of resource (i.e. PRB) committed to a slice during

its life-cycle. Furthermore, dedicated resources model may lead to a waste of resources, as the

PRBs are strictly dedicated to a slice, even if they are not used.

The second approach, i.e. shared resources model allows the slice to share the same: control

plane, MAC scheduler and physical resources – it means case the Common Slice functionality is

rich, however we still add the dedicated slice for some advanced Control Plane or Data Plane

operations. In this solution, the PRBs are managed by a common scheduler that distributes the

PRB to Slices’ users according to different criteria, like Service Level Agreement (SLA), priority, etc.

Whilst this solution exploits statistical scheduling of physical resources, which ensures more

scalability and elasticity by report to the dedicated resources model, it may lack the support of

strict QoS guarantee for Slices and traffic isolation.

Regarding the literature, many works have addressed the challenges of RAN sharing from two

main perspectives: (i) resource sharing among Mobile Virtual Network Operators (MVNO), by

modifying the MAC scheduler; and (ii) radio resources isolation. For resources sharing, authors in

[36] introduce Network Virtualization Substrate (NVS), which operates on top of the MAC

scheduler. Its objective is to flexibly allocate shared resources modifying the MAC scheduler to

reflect MVNO’s traffic need and SLA. NVS was adapted to the case of RAN sharing in LTE [37],

with the aim to virtualize the RAN resources. Arguing that most of the MAC schedulers for RAN



sharing are less flexible and consider only SLA-based resource sharing, the authors propose

AppRAN [38], an application oriented RAN sharing solution. The aim is to adapt the RAN sharing

mechanism to the applications’ need in term of QoS. Looking to radio resource isolation,

RadioVisor [39] represents one of the major works that addressed this issue. RadioVisor aims to

share RAN resources, which are represented in a three-dimensional grid (radio element index,

time slots and frequency slots). The radio resources (in the grid) are sliced by RadioVisor to

enable resources sharing for different controllers, which provide wireless access to applications.

Each controller is allowed to independently use the allocated radio resources without interfering

with the other controllers. It is worth noting that these works mainly focused on RAN sharing

issues without considering flexibility and dynamicity as required to enable Network Slicing.

9.4.2. Core Network slicing with RAN assistance

Figure 35 – Global overview of the envisioned Network Slicing architecture

To demonstrate the concepts of the proposed architecture, we assume that three types of Slices

exist each with highly distinct network requirements in terms of QoS, mobility, security, number

of devices supported and network costs: xMBB, uRLLC and mMTC; i.e. each slice should belong to

at least one of these types.

Note: These three slices represent the limit cases of the 5G ecosystem motivating the need for a

multi-slice environment even into single tenant network infrastructures (i.e. an operator will have to

run at least one of each type of slices in order to efficiently cover the evolution towards broadband,

the massive number of devices and the new tactile type of services).



Figure 35 presents the network architecture after the Slice Orchestrator (SO) has instantiated the

CN elements using PNF or VNF for each of the three types of slices. Each CN instance includes a

set of VNFs or PNFs representing core network functions, such as mobility management,

authentication as well as data plane forwarding functions (e.g. mobility anchors, gateways to

Internet). The CN instances are connected to the shared RAN (i.e. eNodeB) using the concept of

the classical S1-Flex [40] configuration which allows an eNodeB to connect to a pool of MMEs in

an MME pool area on their respective S1 interfaces or the newly introduced interfaces (i.e. Gx, Gy,

N1, N2 and N3) proposed by the 3GPP SA2 group [24], thereby achieving slicing at the RAN. The

eNodeB is able to steer the Slice traffic to the correct CN instances using the concept of eDÉCOR,

in which the UE indicates a Slice ID that allows the eNodeB to select the appropriate CN elements

for the UE traffic. The Slice ID could be hard encoded in the UE (i.e. USIM) or encoded through

the Public Land Mobile Network (PLMN). Moreover, the UE communicates the Slice ID during the

RRC connection procedure as well as in the Non-Access Stratum (NAS) procedure, which allows

the eNodeB to contain the UE within the requested slice(s) and treat it according to the agreed

SLA. For instance, the eNodeB may use the appropriate MAC scheduler instance which will handle

the Slice resources to satisfy the required QoS. It is important to note that the Slice ID should

indicate the slice Type (e.g. xMBB, uRLLC or mMTC) in addition to the Tenant ID. The Tenant ID is

the entity (e.g. MVNO) that is in charge of the Slice. Finally, the eNodeB maintains a mapping

between the Slice ID and the CN elements (e.g. using IP addresses), which is communicated by

the SO during the Slice instantiation process.

This functionality is equivalent to the Slice Selection Function within the common slice, presented

in the section 9.2. However, the functionality previously presented was located in the core

network assuming that the RAN will not take any decision on the slice selection, all decisions

being taken in the core network. In this section a new alternative is presented in which the SSF is

located at RAN level which on one hand offers a faster response to requests (the functionality is

located on the already established control plane thus not requiring new message processing or a

redirection) albeit it requires that the functionality is made available in all the base stations which

may include additional deployment costs.

9.4.3. Base Station architecture for slice selection

As the 5G New Radio (NR) functionality is not yet defined, the example presented will be as in the

case of the core network selection based on LTE. Figure 36 depicts the architecture of the

eNodeB when using our proposed network slicing solution. The proposed architecture shares

many concepts with the legacy LTE architecture, particularly the usage of logical channel and

their mapping to Evolved Packet System (EPS) bearers. The main difference is related to the

abstraction (i.e. virtualization) of the physical resource blocks, where an abstraction layer (named

Resource Mapper – RM) is added. The RM acts as an interface between the shared PRB and the

Slice Resource Manager (SRM). The SRM is in charge of scheduling resources for UEs belonging

to its Slice. Any popular Scheduling algorithm (e.g. Proportional Fair – PF, Round Robin – RR,

Priority-based, Delay-based) could be used. Each SRM may use a different scheduler, as

configured by the SO. The SRM could be seen as a slice-dedicated scheduling NF, while the RM a

common scheduling NF for all slices. The RM will expose the information to each SRM regarding:



(i) the number of packets, per UE and per logical channel, waiting for transmissions, in both

directions Uplink and Downlink; (ii) the Channel Quality Indicator (CQI) of each UE; and optionally

the latency of the oldest packet in the UE’s queue as well as the history and statistics of UE traffic.

Figure 36 – An overview of the eNodeB functions enforcing network slices at the RAN

This information will be used by the SRM to schedule UEs over the Virtual Resource Blocks (vRB).

The number of the available vRBs is not limited and could be infinite; i.e. the SRM may schedule

all UEs during one cycle. However, the vRBs should be mapped to PRBs and giving that the

number of PRBs is limited and dependent on the physical characteristics (i.e. total channel's

bandwidth), not all the UEs will be served during the Transmission Time Interval (TTI). The RM will

be in charge of accommodating the vRBs sharing the PRBs between them according to the

amount of resources (noted Slice Dedicated Bandwidth – SDB) that should be allowed to each

slice. The SDB is the policy enforced by the SO to the RM when the slice is first created. It is worth

noting that the SDB is dynamic; it could be adapted as a function of workload demand and slice

requirements upon a request from the Slice. Moreover, the SDB policy can be expressed in terms

of percentage of PRB or the bandwidth to be allocated to a slice.

Another important function block is the Agent, which is in charge of the communication with the

remote eNodeB controller. Indeed, the envisioned architecture assumes that the SO is using

Northbound API exposed by an eNodeB controller to (re)configure, in real-time, the eNodeBs.

The eNodeB controller translates the SO requests to configuration messages (Southbound API)

communicated to the eNodeB Agent. For instance, the SO uses Northbound API to communicate

the SDB policy of a specific Slice as well as the Scheduler algorithm to be used by the SRM to the

eNodeB controller, which will translate these requests to MAC layer related configuration

messages to be sent to the eNodeB Agent. The latter will configure the SRM and the RM. For

more details on the eNodeB controller, agent, configuration protocol, readers may refer to the

FlexRAN work [41].

Slice Orchestrator

eNodeB Controller

Ag

en

t

SR

M

RM

SR

M

SR

M

Logical ChannelLogical ChannelLogical ChannelLogical Channel

Routing

Physical Channel

Northbound API

Msg

configuration

Control

Data



The remaining functional blocks are similar to the 4G eNodeB architecture. The User Plane is in

charge of handling per UE and Bearer traffic, including UL and DL. The Routing function is in

charge of steering the user traffic to the appropriate CN instance and steering the downlink

traffic to the appropriate logical channel queues. As mentioned earlier the eNodeB uses the Slice

ID communicated by the UE during the RRC connection procedure to know to which Slice, SRM

and CN instances, the UE belongs. Hence, the eNodeB needs to maintain a mapping between the

UE ID (i.e. Cell Radio Network Temporary Identifier – C-RNTI, Tunnel ID – TEID) and the SRM, CN

instances. Every time a packet is received from the CN, the eNodeB queues the packets to the

logical channel associated to a UE for a specific Slice; we may see the logical channels as a two

dimensions’ matrix, where the horizontal axis represents the Slice ID, while the vertical axis

represents the UE ID. Therefore, a UE may belong to more than one slice, where each logical

channel is managed by a specific SRM and CN and one SRM and CN instance may handle several

logical channels.

It is important to note that we omitted to virtualize the physical channel (i.e. RAN isolation) for

the reasons stated in the section 9.4.1. In addition, we observe that creating a specific physical

channel for a Slice will require that each Physical layer processes the common I/Q flow (e.g.

OFDM modulation/demodulation in LTE) before being able to decode the traffic dedicated to UE

from one Slice, which is very resource consuming and inefficient. However, user-specific physical

layer processing (e.g. Turbo coding/decoding in LTE) can be virtualized (i.e. shared) depending on

the required level of isolation. Finally, we believe that in the absence of beamforming operation,

affecting one PRB per UE is enough to ensure RAN traffic isolation.

9.5. Data plane programmability

In order for slices to deal with various types of QoS requirements (i.e. xMBB, uRLLC, mMTC),

demanding network softwarization should be organized through clear Control and Data Plane

separation, flexible programmability in all infrastructure functionalities (e.g. application, control

plane, data plane, management and orchestration). Among conventional R&D efforts, OpenFlow

and SDN mainly cover the Control Plane programmability through defining common API to

control network nodes, NFV and MANO mainly cover the application, management and

orchestration programmability introducing open source management and control software which

support standardized API defined by ETSI, for example. However, to the best of our knowledge,

there are only few efforts on enhancement of data plane programmability. Although

OpenDataPlane and OpenFlow HAL (Hardware Abstraction Layers) have tried to extend the data

plane programmability, these limit the flexibility only defining extended API for hardware based

functional blocks.

The University of Tokyo has developed FLARE [42], a platform for deeply programmable network

nodes, in order to solve the 3 technical challenges; (1) ease of programming, (2) reasonable and

predictable performance and (3) isolation among multiple concurrent logics. Especially, features

(2) and (3) enable network slices to be isolated QoS related capability (i.e. delay, throughput, jitter,

reliability and security) without degrading packet forwarding performance. By extending FLARE

technology, 5G!Pagoda enables to provide a globally first E2E network slicing mechanism for



coming 5G environment while being able to process the data path of multiple slices within the

same data plane components. Compared to the control and management plane network

softwarization technologies in SDN and NFV, since FLARE enables to extend such softwarization

into data plane functionalities, we refer this capability as ‘deeply’ programmable for

differentiating the conventional technologies. We note that deep data plane programmability

with high performance packet forwarding is strongly demanding in order to deal with various and

critical QoS requirements from current (3G and 4G) and emerging (5G) mobile services.

As illustrated in Figure 37, the deep data plane programmability presumes bringing functionality

which is specific to the different slices in the data path to the common forwarding entities. Thus,

performance optimization is obvious as the data packets do not have to switch context between

the common forwarding entity and the slice data plane components, being replaced with direct

processing in the common forwarding entities, with the specific functionality of the different

slices. In this case, the performance optimization highly depends on the virtualization

mechanisms as well as on the capacity of the deep programmable switches to efficiently add new

data plane functionality.

Figure 37 – Deep Data Plane Programmability i) without and ii) with

In FLARE architecture, the toy-block networking programming model has been introduced. This

allows FLARE users to develop their application and service logics in drag and drop programming

manner. The developed software modules are assigned appropriate container (e.g. Docker) and

processor cores, then executed in isolated manner directly on the programmable switch, enabling

the implementation of dedicated, customized User Plane Functions (UPFs), while being controlled

by external CP functions. In FLARE architecture, control plane software modules are usually

assigned to general purpose processing cores (i.e. CPU and optionally GPU) and data plane

software modules are usually assigned to power-efficient and low-frequency processing cores (i.e.

many-core network processors) to handle ultra-speed protocol processing thanks to massively

parallel processing.

Possible and effective use-cases of the deep data plane programmability are application specific

traffic controls, M2M Smart gateways, customized OpenFlow Switch Actions and ICN functions,

for instances described in [43]. Furthermore, we note that FLARE enables to improve security and



reliability of all networking capabilities through integrating with in-network security treatment

and in-network big data analysis.

The critical technology items which remain to be proven, as further detailed and specified in D3.1

are related to the isolation of the processing between the different slices which introduce UPF

functionality to the data plane as well as the secure and reliable communication with the control

plane.

9.5.1. Novel Data Plane architecture in 5G!Pagoda

The basic concept of FLARE Data Plane architecture is illustrated in Figure 38. As described in [44],

FLARE is an open deeply programmable node architecture that can concurrently run multiple

isolated slices on a physical network node. In Figure 38, three slices are illustrated. Each of the

slices is configured and executed in a physical network node and each slice consists of control

plane (C-Plane) modules, data plane (D-plan) modules and their virtual (logical) interfaces. A

Node Manager is responsible for management of slice resource partitioning and utilization and

for the dynamic operations for all software modules in slices. The Slicer Controller and Slicer are

responsible for classification of all incoming packets and distribute them into an appropriate slice.

The classification parameters are defined and indicated by FLARE central, outside integrated

controller, through the Slicer Controller.

In order to provide both high performance and programmable capability, FLARE utilizes general

purpose processors (i.e. Intel x86 multi-core processor) and many-core network processors (e.g.

TILERA). In such environment, C-Plane software modules are used to be executed on Intel CPUs,

similarly to current data center technologies and D-Plane Software modules are used to be

executed on network processors with various virtualization techniques (e.g. Linux hypervisor,

Docker container, processor core assignment) similar to the current added value functionality

development mechanisms for physical and software switches. Thanks to the combination of

various virtualization techniques, each slice is completely isolated from other slices and enables

to configure and execute various types of virtual network functions as specified.

Concerning the data plane performance, network processors contributes important roles for

achieving both higher programmability and higher performance. In the current implementation

for examples, power efficient and low frequency 36 core processors are available and are very

useful for massively parallel processing for a large number of flows with advanced/extended

capability (e.g. security, reliability, QoS, etc.) in isolated manner. The University of Tokyo has

already developed slicing mechanisms of eNodeB and EPC on top of FLARE Platform [44] and the

prototype system has exhibited at ITU-T FG-IMT2020 workshop and demo (12/9/2016@Geneva)

and Wireless Technology Park 2017 (5/24-26/2017@Tokyo).



Figure 38 – Deep Data Plane architecture in FLARE [44]

9.5.2. ICN/NDNICN use case of Data Plane programmability

To show the merit of providing a deep data plane programmability as one of the innovative

features of 5G! Pagoda architecture, the project is going to implement an emerging network

architecture named as NDN which is one of the popular architecture belonging to the category

classified as ‘ICN as a slice’. Especially, owing to the data plane programmability, emerging

network architectures using new packet forwarding schemes such as ICN can be realized as a

slice.

ICN is one of the emerging network architecture which is widely studied. It is expected to provide

solutions to cope with problems in 5G era such as increasing video contents traffics, shorter

response time requirement, resilience to disasters and IoT device accommodation. Because of

these possibilities, ITU-T SG13 FG IMT-2020 dealt with ICN as one of the study item and the

deliverable to ITU-T SG13 included the recommendation to establish ICN related new question,

resulting in the establishment of Q.22. In FG IMT-2020, ICN is also discussed in Network

Softwarization group as one of the possible slice applications. Waseda University submitted the

ICN slice document with IoT usage scenario to this group as one of the results of 5G!Pagoda

project (contribution to ITU-T I.218) and the proposal was included in the final output document

as the section 9.2.

Basic feature and merits that ICN will provide to answer the requirements of 5G mobile are as

follows:

• Traffic and possible response time reduction by in-network caching,

• Easy provisioning of in-network data processing,

• Contents security in terms of the genuine producer guarantee,

• Robustness to network failures by multi path routing,

• A smart routing technology that enables an efficient interest forwarding, which can be used

to collect real time sensor data effectively.



ICN is the architecture to obtain the intended content by sending the content name to the

network and the network routing the request to the possible serviceable node based on the

name based routing. The node has a dynamic content Cache capability and the content can be

provided from the node that is close to the requesting user. Since the routing scheme is by far a

different from the current IP based network, data plane programmability is necessary to realize

ICN as a slice.

In ICN concept, object that can be requested by name is not just content but also data

processing and services. This means more computing power and memory capacity is requested in

each node. FLARE switching system 5G!Pagoda will use as a key element can provide an efficient

deep data plane programmability and also a control plane programmability where data

processing and service provisioning can be performed. This fits the requirement of ICN node and

will form a unique feature of 5G!Pagoda architecture.

9.6. NDN/ICN example of the use of multiple slices

There are some cases that the services can be more efficiently provided by connecting different

slices having different characteristic. As one of the example of such cases, 5G!Pagoda project is

planning to realize an efficient contents delivery service by the connection of the Dynamic CDN

(Content Delivery Network) slice and ICN (Information Centric Networking) Slice, under the

collaboration among Waseda University, University of Tokyo, Aalto University, Hitachi and NESIC.

The aim of this proposal is to realize more efficient contents delivery service which covers wide

geometrical area that extend across the countries, by combining the strength of pre-planned

allocation with large cache capacity that Dynamic CDN slice will provide as a backbone side and

the limited cache capacity but finer grain and dynamic contents allocation capability of ICN in the

final distribution part. The use of ICN also make it easier to access the content for the user and

the protocol sequence will become simpler which helps the network to reduce the protocol traffic.

CDN is proposed to improve the web hosting. In CDN network, the files (video, voice, CCS files,

etc.) are distributed to different locations other than the single web server. The benefits of

utilizing CDN lies in the fact that, files can be pre-cached to several local CDN servers so that the

user can be served from nearby CDN servers. As a result, with CDN, network congestion can be

achieved with lower latency. The Dynamic CDN Slice is the proposal made by Aalto University

with intension to set up the Content Cache servers dynamically and more efficiently depending

on the user needs. For example, when the big game takes place, more users are expected in the

geometric regions whose teams are participating. Then, placing Content servers which provide

the game contents closer to the geometric regions is more efficient. This can be realized by

setting the big game specific slice dynamically.

In ICN, each node has dynamic contents cache and the popular contents are autonomously

cached at the nodes where the same contents are requested frequently. This enables finer grain

optimization of content location, but with limited amount of cache capacity for each node. The

traffic is further reduced than CDN and the response time can be also reduced. It is expected that

ICN user are enjoying a variety kind of contents not just a single category by accessing the same

ICN slice. This leads to the possible architecture that setting up rather stable ICN slice that



provide with a variety of contents in the distribution part of the network and when some big

event takes place and the event specific dynamic CDN slice is created, connect the dynamic

content server placed near-by to existing ICN slice as one of the new content producers. This

approach enables ICN users to enjoy a variety of contents by accessing the same ICN slice and

the service continuity will be realized and when the new CDN slice is created, user can enjoy

more contents without changing the access slice.

This is one of the examples that show the merit of using a slice stitching concept. Figure 39

shows the conceptual figure of the CDN/ICN combined content delivery service.

Figure 39 – CDN/ICN combined content delivery service

9.7. Example of multi-domain mobile network slice

In this section an example how the international E2E slice can look like is presented, in order to a

better understanding of the multi-domain slicing. The example shows also that despite typically a

slice is composed of Data, Control, Application and Management Planes their role in each slice

can be different, i.e. the Control Plane of the EPC sub-slice may have significantly different role

than the Control Plane of a Transport Slice that is linked with the EPC. Specifically, the EPC slice

control plane main role is to ensure the proper connectivity of the end-devices through the RAN

network while the transport slice control plane will have a role into the proper management of

the transport plane between the different domains including the forwarding and the QoS

insurance (not on a subscriber base, but mainly based on traffic engineering due to the large

amount of data traffic).

In the presented example it is assumed that there will be one instance of a mobile network slice

operating in Berlin and exactly the same instance will be instantiated in Tokyo. Both networks will

have to be connected by a transport network that goes from Germany via Poland and Germany

to Japan. Both mobile network instances are composed of RAN and EPC slices. The roaming

mechanism is used to provide connectivity between the mobile networks deployed in Germany

and in Japan. It has to be noted that despite a common understanding that slice provides E2E



operations of all planes in the mentioned case, the control planes operations are limited to their

administrative or technological domains and the inter-domain operations are needed in order to

provide E2E operations.

Figure 40 – Exemplary E2E mobile network slice

The example shows that not all planes of the E2E multi-domain will have (or can) be sliced.

Specifically, part of the data plane, especially towards the transport network may be common to

multiple slices. Each of the slices may transmit requirements on how its data traffic has to be

processed, however not requiring any customized functionality.

As it can be seen in Figure 40:

• RAN is not sliced at all (like in 3GPP DÉCOR), presuming that although the service is

customized, the customization is not related to the scheduling of the radio resources towards

the devices but only to the parametrization of the same scheduling mechanism according to

the control plane requirements.

• EPC is sliced but the control plane is split between the Common and the Dedicated Slices.

The common slice may contain the slice selection mechanisms and optionally the access and

mobility function in case the access and mobility functionality is the same for all the devices.

The Dedicated Slices will include the specific session management and access and mobility

management functionality in case they are not provided by the Common Slice.

• In the Domain #3 it has been assumed that the data transport network is slicing ready and

enables slicing of control and data planes. Remark: as this represents a transport network

between Domain #2 and Domain #5, the data plane encapsulates all the messages

exchanged between the Domain #2 and Domain #5 which messages belong to application,

control and data planes of these domains. Additionally, the control plane in Domain #3 is the

transport level control plane which interacts with the control plane of the Domain #2 and

controls the Domain #3 data plane.

• In Domain #4 the network is not slicing ready therefore a VPN mechanism is used and all

planes data are encapsulated as data plane packets.

• Domains #5 and #6 in Japan have similar structure like respective Domains #2 and #1 in

Germany.



This example shows importance of per plane slicing, as adopted in the 5G!Pagoda architecture. It

also shows that there is not always needed to slice all planes of the intermediary domains. It is

also worth to emphasize that control planes of neighboring domains don’t have or even can’t

communicate directly and the Slice Border Control functional entity should be used for such case.

9.8. The MVNO-like network implementation

As it has been already mentioned the network slicing approach benefits include efficient usage all

of available resources, capability of creation of a specific service oriented slice and the ability to

create slice oriented towards tenants. A tenant is a user of a network slice instance. He is able to

create network slice instances, (via the slice orchestrator,) and to manage them through a

management interface (using a portal attached to OSS Support of Dedicated Slice Management

Functions). This management interface is created when slice is created as a part of newly created

slice.

Currently MVNO (Mobile Virtual Network Operators) utilizes MNO’s (Mobile Network Operator)

network resources to offer network services to its users. The network resources, which MNO

provides to MVNO, are basically defined in terms of network capacity required by MVNO in order

to provide services at proper quality level. As already presented in the previous D2.1 deliverable,

the 5G is expected to enable operators to provide a wide variety of use cases with appropriate

and differentiated service quality to fulfil each user demand by using the network slicing concept.

Various types of devices including IoT devices are expected to be connected to the network for

various services and applications. So far MVNOs offer services similar to MNO but in the 5G era

MVNOs should exploit the network slicing concept in order to create their own highly

customized services and the new approach can impact significantly their business models. It is

expected that MVNO will provides purpose-oriented services for particular user groups with

unique business model. For this, the MVNOs will need to efficiently support a set of very specific

requirements and for the specific duration of the service. It is worth to mention that the network

slicing will enable dynamic creation of MVNO networks that are flexible and optimize the usage

of network resources while fulfilling service requirements.

The main requirement of MVNOs is the ability to create network slices in MNO’s network in order

to be able to use the infrastructure resources for specific dedicated services. Using the

5G!Pagoda architecture, the future MVNO will be able to request to the slice orchestrator the

creation of Dedicated Slice including specific functionality and potentially using some functions

of the Common Slice that is provided by the MNO. The split of functions between the Dedicated

and the Common Slice can be dependent on MVNO needs and it should be defined in that way

that will have no negative impact on the business model that will be used by MVNO (no

technological or administrative constraints), this being a key technology development which will

be further detailed in the next deliverables. Additionally, an open issue to be further addressed is

related to the proper design and specification of the who will provide the Dedicated Slice

templates (Blueprints) as well as of which of the different actors will provide it (it can be provided

by MNO, MVNO or by 3rd party).



In the proposed approach the MVNO is able to manage its Dedicated Slice while the MNO is

managing the Common Slice. Another key issue to be solved is whether the Common Slice will

have a single administrator (the MNO) or if specific administrative tasks can be offloaded to the

multiple MVNOs through dedicated APIs.

The MVNO is able to create multiple Dedicated Slices and to modify independently each slice

configuration as well as potentially to connect them to one or more Common Slices. This gives

the opportunity to the MVNOs to deploy more or less dedicated functionality according to the

requirements of the specific use case. Due to this functionality feature, there are different MVNO

deployment models, spanning from an independent subscribed and charging data base to

complete virtual networks. However, considering the advancements of the 5G system into

customized slices it is assumed that the most common model for the new generation of MVNOs

will include in the dedicated slices RAN and CN components as their high customization will

enable to address specific groups of devices especially in the area of massive IoT services and

low-delay ultra-reliable communication. Such a use case is shown in Figure 41.

Figure 41 – E2E (RAN + CN) slicing architecture

The Dedicated Slice Management functions gives the MVNO abilities to manage the MVNO slice

that includes the management of user plane and control plane functions such as subscriber data

management, policy control and session management. Using it the MVNO can offer a service

variety of services for example very low latency application such as remote medical surgery and

automated car driving, localized services such as M2M/IoT.

MVNO UERAN Slice 1

RAN Slice 2

CN Slice 1

CN Slice 2

MVNO slice

RAN Slice 3

RAN Slice 4

CN Slice 3

CN Slice 4

RAN Slice N CN Slice N

MNO slice

MNO UE

MVNO service

MNO service

Service A

Service B

Service C

Service D

Service N

Orchestrator



Concluding remarks 10.

The objective of this deliverable is to define the initial 5G!Pagoda architecture, which key feature

is support of network slicing. The 5G!Pagoda approach is based on intensive state of the art

analysis of network slicing approaches that includes 5G PPP projects, 3GPP 5G slicing oriented

activities, ITU-T IMT-2020 Focus Group concepts, IETF activities related to slicing and NGMN

vision of slicing. As it has been shown there are already many approaches to network slicing.

Some of them address specific types of slices (3GPP, 5GEx) or specific aspects of slicing only. The

analysis led to the conclusion that the research community is still looking for a proper approach

to network slicing and that the final solutions should be a convergent and standardized one.

The 5G!Pagoda consortium has decided not to design ‘yet another slicing architecture’, but rather

to make the first step towards the convergent approach that will incorporate the existing

approaches, including the 3GPP ones. It led to the definition of the 5G!Pagoda reference

architecture. The architecture is flexible and can be instantiated in many different ways.

The developed concept allows also for integration of the legacy mobile systems, an issue that

was so far neglected in many slicing concepts. Such property enables the coexistence of

hardware and software based solutions and later on smooth migration towards fully software

based ones.

The 5G!Pagoda architecture slicing can be done on each of the network planes and a slice can be

a composition of a Common Slice and a Dedicated Slice (a tandem). The approach enables

compatibility with some slicing approaches as well as with legacy solutions. The Common Slice

can be used when no appropriate Dedicated Slice can be found or until such slice is created (the

Slice On-Demand case). The slice architecture includes functional components that support

lightweight slice management by slice tenant, components specific to slice operations (Slice

Selection Function, Slice Border Control) as well as components that and automated in-slice

management that supports orchestration.

During the definition of the 5G!Pagoda architecture we have identified several topics that require

more research effort and we have decided to work on some of them. The selection was based on

the background and competences of the 5G!Pagoda consortium members. The list of topics

include: programmable data plane operations in order to provide highly efficient data plane

operations and support slicing; RAN slicing and multi-domain slicing. In the context of multi-

domain slicing we have to address both, multi-slicing operations as well as multi-domain-

orchestration. In this context we have also defined the orchestration architecture.

We have decided not to define interfaces between the functional components of our architecture.

The reason was twofold. First, some of the components are dependent on a specific type of slice

(RAN, EPC, transport) and they will be defined during the architecture instantiation. The second

reason is related to the use of software components as blocks of our architecture. In the software

world much more typical is the definition of APIs and, recently the use of message busses, like

RabbitMQ or Kafka with the publish-subscribe paradigm for information exchange. The latter



case is already in use in such solutions like OpenBaton or ONAP and provides high flexibility in

terms of dependencies (flexible hierarchy) of its components.

The high level architecture described in this deliverable will serve as a basis for the implemen-

tation of selected 5G!Pagoda use cases that were described in deliverable D2.1 [1]. The feedback

from the implementations as well as output of other work packages of the project will be later on

used for the refinement of the architecture. The final architecture that will be provided in

deliverable D2.5 will describe functional entities in more details, their APIs interfaces between

them (or description of messages busses if used), information model and mechanisms that are

proposed for the converged slicing. For the final version we will also continue to monitor

activities of other research activities in order to guarantee that our approach will be a converged

one.



Appendix A. References

[1] 5G!Pagoda, ‘D2.1 – Use Case Scenarios and Technical System Requirements Definition – ver. 1.1’; source: https://5g-pagoda.aalto.fi/assets/demo/attachement/delivrables/D2.1_Use_case_scenarios_and_technical_system_equirements_definition_1.1.pdf

[2] Network Functions Virtualisation (NFV); Management and Orchestration; Report on Architectural Options, ETSI GS NFV-IFA 009 V1.1.1 2016-07

[3] NGMN 5G White Paper, 2015-02; source: https://www.ngmn.org/uploads/media/NGMN_5G_White_Paper_V1_0.pdf

[4] NGMN, ‘Description of Network Slicing Concept’, 2016-01; source: https://www.ngmn.org/uploads/media/160113_Network_Slicing_v1_0.pdf

[5] 5G PPP Architecture Working Group – View on 5G architecture, version 1.0, 2016-07; source: https://5g-ppp.eu/wp-content/uploads/2014/02/5G-PPP-5G-Architecture-WP-July-2016.pdf

[6] A. de la Oliva, X. Costa-Pérez, A. Azcorra, A. di Giglio, F. Cavaliere, D. Tiegelbekkers, J. Lessmann, T. Haustein, A. Mourad, P. Iovanna, ‘Xhaul: Towards an Integrated Fronthaul/Backhaul Architecture in 5G Networks’, accepted for publication at IEEE Wireless Communications Magazine, Special Issue on ‘Smart Backhauling and Fronthauling for 5G Networks’. http://5g-crosshaul.eu/wp-content/uploads/2015/05/xhaul-towards-an-integrated.pdf

[7] S. González, A. de la Oliva, X. Costa-Pérez, A. Di Giglio, F. Cavaliere, T. Deiss, X. Li, A. Mourad, ‘5G-Crosshaul: An SDN/NFV Control and Data Plane Architecture for the 5G Integrated Fronthaul/Backhaul’, at Transactions on Emerging Telecommunications Technologies; source: http://5g-crosshaul.eu/wp-content/uploads/2015/05/10.1002-ett.3066.pdf

[8] X. Costa-Pérez, A. Garcia-Saavedra, X. Li, T. Deiss, A. de la Oliva, A. di Giglio, P. Iovanna, A. Mourad, ‘5G-Crosshaul: An SDN/NFV Integrated Fronthaul/Backhaul Transport Network Architecture’, at IEEE Wireless Communications, 2017-02

[9] 5GEx Initial System Requirements and Architecture; source: https://h2020-5gex.herokuapp.com/pdf/5GEx_D2.1v1.1_public_version.pdf

[10] METIS II Draft Overall 5G RAN Design; source: https://metis-ii.5g-ppp.eu/wp-content/uploads/deliverables/METIS-II_D2.2_V1.0.pdf

[11] 5G NORMA Functional network architecture and security requirements; source: https://5gnorma.5g-ppp.eu/wp-content/uploads/2016/11/5g_norma_d3-1.pdf

[12] 5G NORMA Network architecture – intermediate report; source: https://5gnorma.5g-ppp.eu/wp-content/uploads/2017/03/5g_norma_d3-2.pdf

[13] 5G-PPP SONATA, ‘Service Programming and Orchestration for Virtualized Software Networks’. source: http://www.sonata-nfv.eu

[14] 5G PPP SONATA, Architecture Design; source: http://www.sonata-nfv.eu/sites/default/files/sonata/public/content-files/deliverables/SONATA_D2.2_Architecture_and_Design_1.pdf

[15] FG IMT-2020, ‘Draft Terms and definitions for IMT-2020’, Geneva, 2016-12

[16] FG IMT-2020, Draft Technical Report: ‘Report on application of network softwarization to IMT-2020’, Geneva, 2016-12



[17] FG IMT-2020, ‘Draft Recommendation: Requirements of IMT-2020 from network perspective’, Geneva, 2016-12

[18] FG IMT-2020, ‘Report on Standards Gap Analysis’, 2015-12

[19] FG IMT-2020, ‘Draft Recommendation: Framework of IMT-2020 network architecture’, Geneva, 2016-12

[20] FG IMT-2020, ‘Draft Recommendation: IMT-2020 Network Management Requirements’, Geneva, 2016-12

[21] ‘Network Slicing – Introductory Document and Revised Problem Statement’, 2017-02, https://tools.ietf.org/html/draft-gdmb-netslices-intro-and-ps-02

[22] ‘Autonomic Slice Networking-Requirements and Reference Model’ (ANIMA), 2017-03, https://tools.ietf.org/html/draft-galis-anima-autonomic-slice-networking-02

[23] 3GPP Technical Report 23.707, ‘Architecture enhancements for dedicated core networks’, v13.0.0, 2014-12

[24] 3GPP Technical Report 23.799, ‘Study on Architecture for Next Generation System’, v14.0.0, 2016-12

[25] 3GPP Technical Report 38.801, ‘Study on New Radio Access Technology; Radio Access Architecture and Interfaces’, v2.0.0, 2017-03

[26] 3GPP Technical Report 28.801, ‘Study on management and orchestration of network slicing for next generation network’, v1.1.0, 2017-03

[27] 3GPP Technical Specification 23.500 draft, ‘Telecommunication management; Management concept, architecture and requirements for mobile networks that include virtualized network functions’, v14.1.0, 2017-03

[28] 3GPP Technical Specification 23.501 draft, ‘System Architecture for the 5G System’, v0.4.0, 2017-04

[29] 3GPP Technical Specification 23.502 draft, ‘Procedures for the 5G System’, v0.3.0, 2017-04

[30] ‘5G Americas White Paper – Network Slicing for 5G and Beyond’, whitepaper; source: http://www.5gamericas.org/files/3214/7975/0104/5G_Americas_Network_Slicing_11.21_Final.pdf

[31] ETSI NFV ISG White Paper, ‘Network Operator Perspectives on NFV priorities for 5G’, February 2017; source: https://portal.etsi.org/NFV/NFV_White_Paper_5G.pdf

[32] ‘SUPA Policy-based Management Framework’, 2017-03; source: https://tools.ietf.org/html/draft-ietf-supa-policy-based-management-framework-01

[33] ‘Network Functions Virtualisation (NFV); Management and Orchestration; Os-Ma-Nfvo reference point – Interface and Information Model Specification’, ETSI GS NFV-IFA 013 V2.1.1, 2016-10

[34] ‘Network Functions Virtualisation (NFV); Management and Orchestration; Ve-Vnfm reference point - Interface and Information Model Specification’, ETSI GS NFV-IFA 008 V2.1.1, 2016-10

[35] ETSI GS NFV-IFA 002, ‘Network Functions Virtualisation (NFV); Acceleration Technologies; VNF Interfaces Specification’, 2016-03; source: http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/002/02.01.01_60/gs_NFV-IFA002v020101p.pdf

[36] T. Guo, R. Arnott, ‘Active LTE RAN Sharing with Partial Resource Reservation’, in Proc. of the 78th IEEE Vehicular Technology Conference (VTC Fall), Pages 1-5, Las Vegas, 2013-09.



[37] X. Costa-Perez et al., ‘Radio Access Network Virtualization for Future Mobile Carrier Networks’, in IEEE Communications Magazine, Vol. 51, Issue 7, 2013-07.

[38] J. He, W. Song, ‘AppRAN: Application-oriented radio access network sharing in mobile networks’, in Proc. of IEEE International Conference on Communications (ICC), Pages 3788-3794, London, UK, 2015-06.

[39] S. Katti. L. Li, ‘RadioVisor: A slicing plane for radio access networks’, in Proc. of ACM of the third workshop on Hot topics in software defined networking (HotSDN), Pages 237-238, Chicago, Illinois, USA,2014-08.

[40] 3GPP Technical Specification 36.401, ‘Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Architecture description’, v14.0.0, 2017-03

[41] X. Foukas, N. Nikaein et al., ‘FlexRAN: A flexible and programmable Platform for Software-Defined Radio Access Networks’, in Proc. of the 12th ACM International on Conference on emerging Networking EXperiments and Technologies (CoNext), Pages 427-441, Irvine, California, USA,2016-12.

[42] A. Nakao, ‘Software-Defined Data Plane Enhancing SDN and NFV’, IEICE Transactions on Communications, Vol. E98-B, No. 1, 2015-01

[43] A. Nakao, P. Du, T. Iwai, ‘Application Specific Slicing for MVNO through Software-Defined Data Plane Enhancing SDN’, IEICE Transactions on Communications, Vol. E98-B, No. 11, 2015-10

[44] A. Nakao et al., ‘End-to-End Network Slicing for 5G Mobile Networks’, Journal of Information Processing, Vol.25, No. 1, pp. 1-10, 2017-01

Date post:	03-Oct-2021
Category:	Documents
Upload:	others
View:	7 times
Download:	0 times

D2.3: Initial report on the overall system architecture ...

Documents