D2.3: Initial report on the overall system architecture ...
Transcript of 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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 3 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 4 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 5 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 6 of 118
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 7 of 118
List of Tables
Table 1 – List of Acronyms .................................................................................................................................. 10
Table 2 – Terms defined in this document ................................................................................................... 16
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 8 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 9 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 10 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 11 of 118
Abbreviation Original term
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 12 of 118
Abbreviation Original term
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 13 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 14 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 15 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 16 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 17 of 118
Terminology Definition
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 18 of 118
Terminology Definition
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 19 of 118
Terminology Definition
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).
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 20 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 21 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 22 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 23 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 24 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 25 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 26 of 118
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).
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 27 of 118
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,
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 28 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 29 of 118
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]
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 30 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 31 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 32 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 33 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 34 of 118
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).
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 35 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 36 of 118
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;
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 37 of 118
• 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:
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 38 of 118
• 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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 39 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 40 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 41 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 42 of 118
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).
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 43 of 118
• 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..*
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 44 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 45 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 46 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 47 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 48 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 49 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 50 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 51 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 52 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 53 of 118
• 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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 54 of 118
• 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).
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 55 of 118
• 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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 56 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 57 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 58 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 59 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 60 of 118
• 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 Sofware Layer (SSL)
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 Sofware Layer (SSL)
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 61 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 62 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 63 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 64 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 65 of 118
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:
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 66 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 67 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 68 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 69 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 70 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 71 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 72 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 73 of 118
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-
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 74 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 75 of 118
• 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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 76 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 77 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 78 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 79 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 80 of 118
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,
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 81 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 82 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 83 of 118
• 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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 84 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 85 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 86 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 87 of 118
• 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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 88 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 89 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 90 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 91 of 118
• 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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 92 of 118
• 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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 93 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 94 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 95 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 96 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 97 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 98 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 99 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 100 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 101 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 102 of 118
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).
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 103 of 118
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:
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 104 of 118
(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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 105 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 106 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 107 of 118
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).
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 108 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 109 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 110 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 111 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 112 of 118
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).
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 113 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 114 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 115 of 118
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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 116 of 118
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
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 117 of 118
[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.
D2.3 – Initial report on the overall system architecture definition
5G!Pagoda Version 1.0 Page 118 of 118
[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