5G White Paper : RAN Slicing Slicing... · X1\01 E@0G 6û4ý¶5 5 7(w,´ ² % ¦ * 4ï Õ 5 5 _ ... Network slicing has been recognized as a core enabling technology in 5G networking

$Page 1: 5G White Paper : RAN Slicing Slicing... · X1\01 E@0G 6û4ý¶5 5 7(w,´ ² % ¦ * 4ï Õ 5 5 _ ... Network slicing has been recognized as a core enabling technology in 5G networking$

5G White Paper: RAN Slicing

RAN Slicing: Logical Private RAN to Verticals

Version 1.0

FuTURE Forum 5G SG

2019/11/20


内容摘要

网络切片是公认的 5G核心使能技术。切片赋能 5G运营商打造垂直行业服务

能力，推动网络即服务能力建设。网络切片是端到端的能力，基于核心网虚拟化

网元隔离的切片，是业界广泛认可的切片方式。本白皮书重点探讨为了支持端到

端的网络切片能力，无线接入网络是否需要进行切片，以及如何进行无线切片的

问题，以期能明确无线网络如何对端到端网络切片进行支撑，从而保证为不同垂

直行业、不同客户、不同业务，提供相互隔离、功能可定制的网络服务，进一步

推动网络切片的实用化。

白皮书首先在第一章引言部分介绍了网络切片的概念并提出无线接入网络

是否需要进行切片，以及如何进行无线切片的问题，在第二章论述了网络切片的

整体发展现状，其中包括了端到端的网络切片定义以及现有的技术和标准状态。

在第三章讨论了在端到端的网络切片中，无线切片的角色定位，并讨论了无线切

片的研究需求。在白皮书第四章中，针对第三章列出的对无线切片的研究需求，

提出了对应的技术解决方案。并在第五章中给出了具体的无线切片应用案例。

由于篇幅所限，未能将对无线切片技术与产业进行更深入的分析与研究，谨

希望白皮书能够发现并解决一些关键问题，进一步明确无线切片所面临的挑战与

发展趋势，为网络切片技术的进一步实用化贡献力量。


Executive Summary

Network slicing has been recognized as a core enabling technology in 5G

networking environments. It empowers 5G operators to build the capability of vertical

industry services, promoting Network as a Service (NaaS) innovations. Network

slicing indicates an end-to-end (E2E) service capability. A slice-isolating approach

based on virtualized network elements (NEs) of the core network has been widely

accepted in the industry. This white paper focuses on whether Radio Access Network

(RAN) slicing is required and how it is implemented, for the purpose of E2E network

slicing. The paper aims to clarify how an RAN supports E2E network slicing to

ensure isolated and customizable network services for different vertical industries,

customers and services. This paper intends to further promote practical network

slicing.

Chapter One introduces the concept of network slicing, and puts forward the

questions of whether RAN slicing is required and how it is implemented. Chapter

Two describes the overall development situation of network slicing, including the

definition of E2E network slicing and the existing technologies and relevant standards.

In Chapter Three, the role of RAN slicing in E2E network slicing is described, and the

research requirements of RAN slicing are discussed. Chapter Four proposes the

corresponding technical solutions for research requirements of RAN slicing listed in

Chapter Three. Chapter Five provides specific application cases of RAN slicing.

Due to space limitation, RAN slicing technology and industry is not further

analyzed and investigated in the white paper. We hope that the paper helps to identify

and solve certain key problems, further clarify the challenges and development trend

of RAN slicing, and contribute to further practicality of network slicing technology.


目录

Executive Summary ..................................................................................................... 3

1 Introduction ....................................................................................................... 1

2 Overview ............................................................................................................. 2

2.1 What is Network Slicing? ............................................................................. 2

2.1.1 Network Slicing Definition ................................................................ 2

2.1.2 Network Slicing Identifier ................................................................. 2

2.1.3 Network Slicing Instance ................................................................... 3

2.2 Technical Standards ...................................................................................... 4

2.3 Industrial Progress ........................................................................................ 5

3 RAN Slicing Requirements ............................................................................... 6

3.1 Role of RAN Slicing .................................................................................... 6

3.2 Requirements of RAN Slicing ...................................................................... 7

3.2.1 Resource Isolation .............................................................................. 7

3.2.2 QoS Guarantee ................................................................................... 8

3.2.3 Access and Mobility Enhancement .................................................. 10

3.2.4 Monitoring and Management ........................................................... 11

3.2.5 Logical Resource Construction and Orchestration .......................... 12

4 RAN Slicing Technology ................................................................................. 14

4.1 Slice-separated management in RAN ......................................................... 14

4.2 QoS Guarantee based on slicing ................................................................. 15

4.3 Mobility enhancement based on slicing ..................................................... 15

4.3.1 Slice-aware idle/inactive UE Mobility ............................................. 15

4.3.2 Slice-aware connected UE Mobility ................................................ 19

4.4 Slice Association Technology ..................................................................... 20

4.4.1 Non-Public Network ........................................................................ 20

4.4.2 Simulated Slicing Technology in Non-standalone (NSA) Mode ..... 21

5 RAN Slicing Use Cases .................................................................................... 24

5.1 Unmanned Aerial Vehicle (UAV) ............................................................... 24

5.2 Industrial Internet ....................................................................................... 26

5.3 Public Service Slicing ................................................................................ 29

6 Conclusion and Vision ..................................................................................... 30

7 Reference .......................................................................................................... 32

Abbreviation ............................................................................................................... 32

Acknowledgement ...................................................................................................... 33


1

1 Introduction

This white paper focuses on Radio Access Network (RAN) slicing requirements,

meaning, key technologies and use cases.

Network slicing has been recognized as a core enabling technology in 5G

networking environments. It empowers 5G operators to build the capability of vertical

industry services, promoting Network as a Service (NaaS) innovations.

Network slicing indicates an end-to-end (E2E) service capability, which is

required by both the core network and the access network. Slice isolation based on

virtualized network elements (NEs) of the core network appears as a slicing approach

widely accepted in the industry. So, is it applicable that RAN slicing is implemented

by means of QoS control of user traffic flows and QoS-based RAN resource

allocation? Do we need to define RAN slicing, and how to define RAN slicing? This

white paper tries to provide some ideas about the requirements and meaning of RAN

slicing.

1. Does a RAN require network slicing?

2. How to define RAN slicing? What about the role of RAN slicing in E2E

slicing?

3. What are the key technologies of RAN slicing?

4. Regarding the differences and connections between RAN slicing and existing

related technologies:

a) What about the association between RAN slicing and QoS?

b) What is the relationship between RAN slicing and network isolation

technologies (such as non-public network) which are hot topics of

current standards?

5. What about the specific applications of RAN slicing?


2

2 Overview

2.1 What is Network Slicing?

2.1.1 Network Slicing Definition

Network slicing is an E2E concept and also a tool that enables customized

network services for the third-parties. Network slicing adapts to diversified service

scenarios and provides customizable network services that are isolated from each

other to suit different service requirements. In addition, network slicing reduces the

separately deployed networks by utilizing one common physical infrastructure. It is

proven to be a smart investment to lower the expensive deployment and O&M

expenditures on separate networks in various service scenarios. One network slice

includes the complete network functionalities, including the access network and core

network[1].

One network supports multiple different network slices, each meeting different

network needs including:

1. Various network functions, such as priority, billing, policy control, security

and mobility.

2. Various customers to be served, such as public safety users, group users,

roaming users, specific virtual mobile operator users, and media priority users.

According to 3GPP specifications [2], network slicing is used by operators to

provide customizable network services that are isolated from each other for different

vertical industries, customers and services, based on the service agreement signed

with customers. By nature, a network slice is a logical network offering specific

network capabilities and features.

2.1.2 Network Slicing Identifier

One network slice is uniquely identified by a single network slice selection

assistance information (S-NSSAI). An S-NSSAI is comprised of two parts:


3

1. A mandatory slice/service type (SST) field, which identifies the slice type

and consists of 8 binary bits (ranging 0 to 255). The SST field refers to the expected

network slice behavior in terms of features and services. Based on 5G typical service

types, 3GPP specifications have defined four types of standardized network slice

service: enhanced mobile broadband (eMBB), ultra-reliable low latency

communications (URLLC), massive machine type communication (mMTC), and

vehicle to everything (V2X)[2][2].

2. An optional slice differentiator (SD) field, which is used to differentiate

among network slices of the same SST field and consists of 24 bits. The SD field

complements the slice/service type(s) of services in different scenarios, to further

differentiate among multiple network slices of the same slice/service type.

2.1.3 Network Slicing Instance

A logical network slice is carried by a network slice instance. A network slice

instance is a physically deployed network slice that includes some network function

implementations and required resources (such as computing, storage, or network

resources).

According to [4][3], the characteristics of a network slice are described by the

network slice template. A network slice instance is created by using the network slice

template and instance-specific resources.

A service instance in a third-party service scenario is implemented by one or

more network slice instances corresponding to one or more network slices. Each

network slice instance will further include multiple network slice subnet instances,

such as access network subnet instances, core network subnet instances and transport

network subnet instances.

Obviously, network slicing is an E2E concept and also a tool that enables

customized network services for the third-parties. Network slicing adapts to

diversified service scenarios and meets different service requirements. In addition,

network slicing reduces the separately deployed networks by utilizing one common


4

physical infrastructure. It is proven to be a smart investment to lower the expensive

deployment and O&M expenditures on separate networks in various service

scenarios.

2.2 Technical Standards

As of 3GPP R15, the first version of the 5G standard supports E2E slice identifier

awareness and the E2E slicing process. Where,

1. 3GPP RAN specifies the basic principles of E2E network slicing on the RAN

side. These principles include: RAN slice awareness, network slice selection on the

RAN side, inter-slice resource management on the RAN side, QoS support of slice,

CN entity selection for RAN, access control, inter-slice resource isolation, multi-slice

support of UE, slice granularity, and slice admission verification for UE. Till now,

how to implement these principles on the RAN side is not standardized.[3].

2. In addition to the definition of slice identifier and slice standardization, 3GPP

SA2 specifies the E2E slice support process, including how a terminal perceives the

capabilities enabled by network slicing. Specifically, the end user perceives network

slice information available at different locations through a registration area update

process. The same network tracking area supports the same slices.

In 3GPP R16, 3GPP SA5 also puts an emphasis on the definition of network slice

enforcement management and orchestration, as well as network slice performance

management. In particular, network slice enforcement management and orchestration

contains the lifecycle management of network slices, spanning the preparation, startup,

configuration, activation, operation and getting-offline processes. [4][3] Roles in

network slicing and service transfer regarding the supply and demand relationship are

also defined. Roles include communication service users (end users, vertical

industries, etc.), communication service providers, network operators, network slice

users and network slice providers. Communication service providers are served by

network operators, while service consumers are served by communication service

providers. Both service consumers and communication service providers may be


5

network slice consumers and served by network slice providers. Both communication

service providers and network operators may act as network slice providers[5][4].

In addition, ETSI and ONAP also provide support for network slicing from the

perspectives of NFV, model orchestration, etc.[6][7]

2.3 Industrial Progress

In May 2019, GSMA released a white paper on the network slice template[8].

The white paper defines the attributes of the Generic Network Slice Template (GST)

and provides an example of the Network Slice Type (NEST) with IMS support. The

GST is a set of attributes that can characterize a type of network slice. An example of

the NEST gives the recommended minimum set of attributes and their suitable values.

GST attributes can be grouped into two categories, and a specific attribute can be

mandatory, conditional, or optional.

1. Character attributes - characterize a slice that is independent of the network

slice customer and provider. Such attributes include throughput (user- or slice-level),

latency, isolation level, and application programming interfaces (APIs).

2. Scalability attributes - provide information about the flexibility and

scalability of a slice (e.g. the number of users, coverage, etc.). These attributes are

specific for the network slice customer and provider.

Character attributes can be further tagged. The following three tag types apply to

character attributes:

1. Performance related - define the Key Performance Indicators (KPIs)

supported by a slice (e.g. throughput, latency, etc.). Performance related attributes

need to be determined before the slice is instantiated.

2. Function related – define the functionality supported by a slice (e.g.

positioning, prediction, etc.). Function related attributes also need to be determined

before the slice is instantiated.

3. Operation related - define which operations are provided to the network slice

customer for maintaining the operation of slice. Generally, operation related attributes


6

are used after the slice is instantiated, and they comprise control and management

aspects.

Compared with the traditional QoS-based quality control, network slicing has

introduced the functions dedicated to network customers (e.g. positioning, instead of

telecommunication basic functions) and customized operation and maintenance (in a

monitorable and programmable manner). In addition, slice-level performance

character attributes (slice-level throughput, availability, reliability, etc.) and slice-level

scalability attributes (the number of users, coverage, etc.) have been introduced in the

KPIs, besides the traditional user-level/service-level quality control system.

Slice-level character attributes may provide an overall description of a group of users

having a common character attribute, such as the same service, the same service

scenario, or the same application provider.

Up to now, the domestic three major telecom operators have cooperated with

major telecom equipment manufacturers and network application providers to carry

out a wide range of investigations and tests. Network slicing has become a hot topic in

the business end customers such as the power supply industry, telemedicine,

automatic driving, industrial scenarios, public services and drone applications, except

the media entertainment field.

3 RAN Slicing Requirements

3.1 Role of RAN Slicing

As an indispensable component of E2E network slicing, the wireless part of

network slicing mainly involves the RAN, wireless fronthaul network and terminal.

The characteristics and requirements introduced by E2E network slicing, in terms of

the wireless network part, cannot be enforced simply by the existing wireless network.

E2E network slicing guarantees equipment isolation on the core network side. Till

now, how to separate network slices on the access network to guarantee the

air-interface resource allocation for the UE in network slices has not been explicitly


7

defined.

The traditional wireless network guarantees the user-level/service-level quality

of services based on QoS control and wireless dynamic scheduling, while RAN

slicing goes further. It introduces slice-level attributes on the wireless network side, in

addition to the user-level/service-level quality assurance. These slice-level attributes

include the aforementioned slice-level throughput, availability, service continuity,

isolation level, the number of users, coverage, etc. Beyond that, RAN slicing also

introduces slice-level monitoring and management requirements. Operators need to

consider, in the wireless spectrum/resource environment, how to maximize the

utilization of wireless resources while meeting the need of slice isolation. This is also

a new challenge to traditional resource allocation methods.

The wireless part of network slicing is not only a configuration issue but also a

new technical challenge. RAN slicing aims to enable a high-performance and efficient

wireless network that provides customized and differentiated network services to meet

the requirements of various industries, customers and services over shared RAN

infrastructures and resources. RAN slicing is an important part of E2E network

slicing.

3.2 Requirements of RAN Slicing

3.2.1 Resource Isolation

Compared with the core network and transport network, the RAN faces a major

challenge of RAN slicing in how to enforce inter-slice resource isolation efficiently

and maximize the utilization of wireless spectrum, in the context of limited spectral

resources. RAN slicing plays an important role in realizing flexible management and

sharing of inter-slice spectral resources, resource isolation, differentiation and

customization.

Obviously, a 5G base station may be required to support a variety of network

slices, including standard and non-standard network slices. A wireless network should


8

be aware of the characteristics of different slice service requests, thereby allocating

appropriate wireless resources to slices.

Some vertical industry customers have isolation or security requirements for

users in the slice. For example, a factory park wants to guarantee 50 MHz radio

resources (similar to private line). Users in the slice share the bandwidth, and are not

affected by other slice users.

One possible solution is to configure the slice group for the users to be

guaranteed, and to configure the proportion of the reserved PBR resources. Some of

the reserved resources can be configured for the exclusive use of the users in the slice,

and the remaining reserved resources can be shared with other slice users when they

are free, which can achieve a certain isolation of the radio resources. Specific schemes

for resource reservation need to be further studied.

3.2.2 QoS Guarantee

UE NR UPF

Network Slice

PDU Session

Radio N3/NG-U

NG-RAN 5GC

Radio Bearer NG-U Tunnel

QoS Flow

QoS Flow

Radio Bearer

QoS Flow

PDU Session

Figure 0-1 Network Slice and QoS Flow


9

UE2

NR2

UPF3

Radio N3/NG-U

NG-RAN 5GC

UPF1

UPF2

NR1

UE3

Network Slice 2

Network Slice 3

UE1

Network Slice 1

Figure 0-2 Network Slice and Multi-user access

As shown in Figure 0-1, a network slice is carried by a user's PDU session(s); a

user's network slice may be carried by one or more PDU sessions; each PDU session

includes one or more QoS flows. As shown in Figure 0-2, a network slice can be

shared by multiple users.

As a continuation of the PCC feature in 4G, the PCF feature in 5G provides

user-level/service-level QoS quality control. The slicing capability introduced in 5G is

applied to the operation and maintenance center (OMC) and NEs via the slice

manager CSMF/NSMF/NSSMF[4][3]. The slice manager may generate the quality

indicator requirements for slices that are decomposed by the slice Service Level

Agreement (SLA).Both PCF and network slice manager have service indicators for

BS. If there is no coordination, there will be double-headed management problem.

RAN does not know which QoS indicator should be followed, and when radio

resources are limited, it does not know which QoS should be guaranteed first.

Therefore, PCF and slicing mechanism must be coordinated, but it should be made

clear how and at which level to coordinate.

One possible solution is that the user-level/service-level radio performance


10

requirements (such as delay, rate and reliability) are only communicated to RAN

through PCF mechanism, and the slice manager does not duplicate the similar

performance requirements. Only the slice-level reserved bandwidth (PRB resources)

and the number of connections (users) are sent to the base station by the slice manager.

If the same services for different slices need to be differentiated, they should be

configured as different QCI/5QI by PCF.

Based on the QoS mechanism and network slicing, the wireless network can be

optimized in depth from three dimensions, including radio rate, delay and reliability,

so as to achieve qualitative and/or quantitative radio performance assurance.

In the aspect of delay guarantee, the delay can be reduced from every part of the

delay, including scheduling waiting delay, transmission delay and HARQ

re-transmission delay. Base stations can quantitatively guarantee the minimum delay

under ideal conditions by adjusting parameters/algorithms. However, the actual

end-to-end delay is closely related to channel quality, number of users, and the

deployment location and performance of the service server. How to provide

quantitative delay guarantee needs to be further studied.

In the aspect of rate assurance, the minimum rate for guaranteed services can be

guaranteed by setting absolute lower rate limit. In addition, the relative scheduling

priority weights can be set for Non-GBR bearers on demand to guarantee the relative

rate advantages. However, if the channel quality of user is too poor or the number of

high priority users is too large, the user rate cannot be guaranteed even if all the radio

resources are distributed to it.

3.2.3 Access and Mobility Enhancement

According to the current protocol, the basic process of user access and mobility

management for network slicing has been defined. However, there is still room for

further optimization. The existing problems are described below, and further

enhancement schemes need to be proposed.

(1) When the user initially registers the network slice, if base station that the


11

user chooses to access does not support the user’s slice type, can the base station

allow the access process? According to the current protocol framework, RRC

connection is allowed to be established in such situation. However, PDU Session is

strongly associated with network slice, so it can not be established, which results in

invalid access of users, inability to initiate business, and unnecessary signaling

overhead.

(2) According to current protocol, idle users choose the resident frequency

according to the frequency priority. Frequency priority is set per-cell without

distinguishing different slices. For the local private networks with strong isolation

requirements, the network slices need to be strongly bound to the frequency bands

(for example, factory terminals want to reside in 4.9G band). At present, the

corresponding scheme is not considered.

(3) According to current protocol scheme, in the handover process, slice

information is carried in the message such as handover request. If the target base

station belongs to the same registration area of UE (the same slice type is support), the

slice admission decision is made according to the network resources. If the target base

station does not belong to the registration area of UE, the admission decision is made

according to the supported slice type of the target BS. If the target base station does

not support the slice of the ongoing service, the target base station requests session

release and informs the source base station of the message and the corresponding

reason(the slice type is not supported). If all the slices of the ongoing services are not

supported, user access is refused. Therefore, when the target base station does not

support the slices initiated by the terminal during the handover request, the service

may be interrupted.

3.2.4 Monitoring and Management

SLA requirements for wireless network slices as well as slice-related

configurations are delivered on the OMC northbound interface, for the purpose of

wireless network slice management. The configuration information such as RAN slice


12

subnet service instances and RAN slice subnet service templates is interacted between

NSMF and RAN-side NSSMF through the interface procedures. The relevant

management process may include the interface procedures such as RAN slice subnet

instance creation/termination/inquiry/update/change notification and RAN slice

subnet service template inquiry.

The RAN slice services are monitored by KPIs. Specifically, the statistical

parameters and KPI indicators of slice granularity and QoS stream granularity as well

as the statistical parameters and KPI indicators of slice granularity are introduced and

reported in the NRM configuration parameters, PM statistical parameters and network

operation indicators, which are included in the existing 5G RAN NE statistics

requirement specifications.

3.2.5 Logical Resource Construction and Orchestration

The RAN slicing happened in air interface and RAN entity, while the processing

in entity determine the actual resource allocation and isolation in air interface. As we

known, the slicing is tightly related with physical or logical resource construction.

The resource in air interface are defined by waveform in time, frequency/code and

space, e.g., LTE/NR use OFDMA and the frame structure to separate the air interface

resource as PRB, TTI, space beam, etc.. Because the space resource is not orthogonal,

and inter-cell interference exist in the cellular environment, the isolation and

orchestration of air interface resource is more hard than that in RAN entity. A

sophistic MAC/L1 scheduler is needed to allocate resource and guarantee the

transmission performance of traffic.

The resource in RAN entity, for example DU, is almost the same as that in CU

and core network, except that more hardware accelerator is used in DU, frontHaul and

RU. Therefore, the hardware resource should also be represented and linked with the

whole software platform. In addition, the real time requirement is a challenge for the

soft RAN processing. As stated above, the construction and orchestration of air

interface resource is determined by RAN process, the RAN architecture should be


13

designed to facilitate the resource orchestration in air interface. In the following

paragraphs, a guideline for the RAN architecture is described with the aim of flexible

air interface resource orchestration.

As described above, there is no perfect construction scheme for air interface

resource, because it’s non-orthogonal and self-interfered. A sophistic scheduler, or

orchestrator in slicing term is needed to trade off the resource allocation and

performance guaranty. Here we introduce a guideline architecture design helpful to

manipulate the resource efficiently.

Coverage Unit

Antenna1

Antenna2

Antenna3

Antenna4

Coverage

Forming

Resource1

Resource2

Resource3

Resource4

Process Unit

Internet

User 1

U0 U1 U2

User 2

Global M

Centralized

Independent CUser

1-C

User

2-C

Figure 0-3 User Flow Oriented RAN Process and Soft Defined Coverage Forming

According to above concept, the RAN process is decoupled into Management

Plane, Control Plane and User Plane. Process Unit in user plane process is user flow

oriented before layer mapping, while Coverage Unit is layer oriented and the execute

the mapping between layer and flow, and the mapping is controlled by ‘Global M’.

‘Global M’ is also responsible for the orchestration of User Plane and Control Plane

processing. It’s observed that the control plane could almost be decoupled into

independent per-user process.

Since the RAN process is decoupled into user flow in user plane and control

plane, for which resource allocation is flexible. Consequently, the slicing in RAN

entity could be determined and orchestrated in user flow granularity. The processing

in Coverage Unit, including RU, frontHaul and low PHY in DU, could be controlled

by global orchestrator flexibly. Even distributed MIMO and the cooperation between

different base station is accommodated in such design.

Not only the RAN processing could be orchestrated in per user flow level


14

smoothly, also the air interface resource could be orchestrated with such flexible RAN

architecture. Not really the air interface resource is isolated for each slice, just the air

interface resource for each flow are labeled with different slicing identification, then

the MAC/L1 scheduler or orchestrator could allocate the air interface resource with

such constrain, and the decision could be executed well in Coverage Unit in a soft

defined manner. If self-contain frame structure is adopted, different waveform could

be defined for each slice.

In one words, with the help of above RAN architecture, the end to end network

slice is designed in RAN and air interface, and the slice is in user flow granularity.

4 RAN Slicing Technology

4.1 Slice-separated management in RAN

When the UE successfully accesses the network, the RAN may provide

slice-specific configuration and differentiated handlings to meet the slice requirements

and SLA.

⚫ Slice-customized Protocol adaptation

The RAN can tailor the slice-specific protocol layer and protocol functionalities

to adapt to the slice-specific requirements. The following gives several illustrative

examples.

- The UE is configured with full L2 protocol stack and all functionalities for

eMBB slices

- To support URLLC slices, the UE with packet duplication in CA/DC case in

L2 and short TTI numerology mapping

- mMTC slices may not be configured with ciphering function or even without

PDCP sublayer

⚫ Slice-separated Resource allocation

The RAN can also allocate isolated resources for different RAN sub-systems.

For example, dedicated frequency bands can be used for particular slices. Even within

the single band, the separated radio resources can be allocated, which could be used

for public safety, vertical applications with stringent isolation requirements etc.


15

⚫ Slice-separated security

Due to the different service requirements, when one UE supports multiple

network slices simultaneously, the RAN may support slice-specific keys for UP

protection between the UE and the RAN. And RAN may use different cryptographic

algorithm, key length for different slices.

4.2 QoS Guarantee based on slicing

As we know, for each PDU session/DRB/QoS flow, its characters and QoS

requirement can be identified by a set of QoS parameters. Regarding to slicing, we

can also describe the SLA by a set of parameters, e.g., Maximum number of UEs per

Network. However, different from the QoS parameters of PDU session/DRB/QoS

flow which are enforced for one UE on one or two RAN nodes, the SLA parameters

of slice may be enforced for multiple UEs on multiple RAN nodes. Hence, it is more

difficult and complex to enforce the SLA parameter of slicing, and how to allocate the

SLA parameters to the RAN should be addressed. One simple solution is that the SLA

parameters is enforced by RAN and its assignment is based on OAM. That is, the

OAM signals the specific SLA parameters, for each supported slice(s), to the RAN. If

the RAN meet the bound of the SLA parameters, it can signal the situation to the

OAM, and the OAM may adjust the SLA parameters. On the other hand, a slice level

Allocation and Retention Priority (ARP) could be defined to indicate the relative

importance of slice(s), such that in case of multiple slices are supported by a RAN,

the ARP allows to decide whether and which a slice PDU session could be accepted or

needs to be rejected in the case of resource limitations.

4.3 Mobility enhancement based on slicing

4.3.1 Slice-aware idle/inactive UE Mobility

To support the branded RAN sub-system, the UE should access the 3GPP

network as if it connects to its supported RAN sub-system directly. As 错误!未找到


16

引用源。 shows, when the UE registries and accesses the network, it may perform the

selection and reselection of the RAN sub-system, and treat the RAN sub-system as its

own “private” network.

In order to achieve this, the RAN node may broadcast its supported RAN

sub-systems, to assist the UE to perform RAN sub-system (re)selection. It may also

broadcast those neighbouring frequency bands and their supported RAN sub-systems

for inter-frequency sub-system (re)selection.

We envision two potential solutions for the UE to be aware of RAN sub-system.

The exemplary example is given in 错误!未找到引用源。.

Figure 0-1 Device awareness of RAN sub-system

• Option 1: each cell broadcasts its supported S-NSSAIs

The UE try to access 3GPP network based on its supported S-NSSAIs and cell

broadcasted S-NSSAIs. As the RAN may support hundreds of slices, and should

ensure scalability feature with more slices in the future, it is essential to reduce the

broadcasting overhead. Hence the RAN node may broadcast the SST as minimum SI,

and treat the left as other system information either be broadcast or provisioned in a

dedicated manner upon UE request. The UE acquisition of SI is provided in Figure 0-.

• Option 2: each cell broadcasts its supported RAN part IDs.

In this option, the UE may map its supported S-NSSAIs to RAN part IDs, and try

to camp on those cells which supports it supported RAN part IDs. Similar to option 1,

this option may treat the essential information of RAN part IDs as minimum SI, and

Subsystem#1Subsystem#2

……Subsystem#N


17

the left as other SI to reduce the broadcast overhead. This option requires the UE to

maintain the mapping relationship between S-NSSAIs and RAN part IDs, which

could be provided in case registration update request by RAN node.

Figure 0-2 UE acquisition of system information

The principles of RAN sub-system selection are given as follows.

o The UE NAS layer identifies the network slices the UE supports, and

transfers to UE AS;

o The UE AS searches the NR frequency bands, and for each carrier frequency

identifies the strongest cell which broadcasts S-NSSAIs or RAN part IDs,

and tries to camp on the cell

o If the UE is not able to identify a suitable cell which supports its associated

slices, it seeks to identify an acceptable cell.

- The suitable cell is the one for which the measured cell attributes satisfy

the cell selection criteria, and the UE’s associated RAN sub-system is

supported;

- The acceptable cell is the one for which the measured cell attributes

satisfy the cell selection criteria but the cell does not support the UE

associated cells.

The principles of RAN sub-system reselection for idle and inactive UEs are

given as follows.

o The UE makes measurements of attributes of the serving and neighbouring

cells to enable the reselection process.

o The UE will prioritize the frequency band which supports its associated RAN

sub-systems with corresponding S-NSSAIs or RAN part IDs.

o The UE will prioritize the cell which supports its associated RAN

sub-systems from those cells satisfying the cell reselection criteria.

In the current deployment scenario, from the network point of view, the

granularity of the supported slice(s) is per tracking area (TA). That is, the supported

SST or only part of RAN part ID asMinimum SI

The left as on-Demand SI via

broadcast or dedicated signalling

UE


18

slice(s) shall be the same for cells belongs to a TA. On the other hand, from the UE

point of view, the granularity of the slice availability is per UE’s registration area

(RA), where RA is defined as a set of tracking areas in TAI List. That is, the slice

availability shall be the same with in the UE’s registration area. The current

deployment will result in a restriction and dilemma, especially from the UE point of

view.

Slice1

Slice2Slice1

Frequency

band#1

Slice1

Slice3

gNB1, TA#1 gNB2, TA#2 gNB3, TA#3

Figure 0-3 RAN slicing deployment example

We show the restriction and dilemma by considering the RAN slicing

deployment as Figure 0-3 shows, and we suppose the UE supports slice 1, slice 2 and

slice 3. The network (i.e., AMF) shall allocate the slice availability and RA to the UE,

e.g., during a Registration procedure. According to the deployment as in Figure 0-1,

according to the above mentioned principle, we gives three options:

• Option 1: RA={TA#1, TA#2, TA#3}; Slice availability={Slice 1}

• Option 2: RA={TA#1}; Slice availability={Slice 1, Slice 2}

• Option 3: RA={TA#3}; Slice availability={Slice 1, Slice 3}

According to the above three options, we find that the restriction is UE cannot

use Slice 1, Slice 2 and Slice 3 within one RA. And we find the dilemma is: the more

TAs the RA includes, the less slice(s) the UE could use, whereas the less TAs the RA

includes, the more registration procedure be triggered, which results in large signaling

cost.

To deal with the above issues, we should relax the current deployment restriction.

For example, from the UE point of view, the granularity of the slice availability within

the RA could be per TA. That is, for Option 1 where the RA includes TA#1, TA#2 and

TA#3, the slice availability could be denoted as

Slice availability = {TA#1={Slice 1, Slice 2};TA#2={Slice 2};TA#2={Slice 1, Slice


19

3}}.

As we can see, by adapting the above slice availability, the UE could use all the

slice(s) for each TA, without registration procedure. That is, the UE knows the slice(s)

could be used in each TA within the RA, e.g., if the UE access to the TA#1, it could

request to setup the PDU session on Slice 1 and Slice 2.

4.3.2 Slice-aware connected UE Mobility

The network controlled mobility should take the slice information into account.

Specifically, the RAN will take the RAN subsystems supported by neighbour cells as

one factor to select the proper target cell for the connected UE. The RAN node and its

neighbouring nodes may exchange their supported RAN subsystems with each other.

Based on this, the RAN can endeavor to support the service connectivity for this UE.

When the UE moves within areas where the RAN subsystem is supported, the

service continuity could be ensured. But when the UE moves to areas which do not

support the RAN subsystem, as Figure 0- shows, the RAN can try to ensure the

service continuity. For example, some slicing mapping policies could be predefined,

and the traffics could be switched to another slice for data continuity.

Figure 0-4 Slice service continuity during Inter-cell handover

The detailed Xn based handover is given in Figure 0-. When gNB2 founds that

the active PDU sessions associated with S-NSSAI#1 are not supported, based on the

mapping policy as one of UE contexts, it could map the S-NSSAI#1 to S-NSSAI#2,

so that the service continuity of S-NSSAI#1 is ensured.

subsystem1 subsystem2Inter-slice mapping


20

Figure 0-5 Xn based Inter-cell handover

4.4 Slice Association Technology

4.4.1 Non-Public Network

A Non-Public Network (NPN) is a 5GS deployed for non-public use instead of

the general public, e.g., a factory or a campus. The NPN could be deployed as a

public network integrated NPN which is deployed with the support of a PLMN, e.g.,

by one or more network slice instances. It is worth mentioning that for NPN, it is

required that the UE, which is not a member of the NPN, is not allowed to access the

NPN. However, the network slicing does not enable the possibility to prevent

non-member UEs from trying to access the NPN, the concept of closed access groups

is used to apply access control. That is, a CAG is identified by a CAG Identifier

which is unique within the scope of a PLMN ID and broadcasted by the CAG cell(s).

The existing network slicing functionalities can be applied to the NPN, such as

slice-separated management in RAN, the SLA parameters of slicing, flexible slicing

deployment as described above. Regarding to the slice aware mobility, as shown in

gNB1 in Registration Area 1 AMFUE

1. Handover Request (PDU Session + S-NSSAI List)

UE in active mode with n slices configured at NAS-level and with m PDU Sessions active at AS level

gNB2 in Registration Area 2

Slice aware handover preparation from gNB1 to gNB2

triggered

7. Registration Area Update (alignment of slices supported in the new RA between UE and network)

4. Handover Execution

3. Handover Request Ack (List of accepted and rejected PDU Session + S-NSSAI)

5. Path Switch Request(mapped S-NSSAI)

6. Path Switch Request Ack

2. Slice mapping if with mapping

poloicy


21

the following figure, the general principle can be described as:

• The CN keeps a mapping relationship between the CAG ID and the slice ID

(negotiate with RAN or configured by OAM), and notifies the UE by the NAS

message

• gNB broadcast CAG ID(s), and thus the UE is notified of the supported slice ID,

so as to the NPN.

RAN

CN Slice ID #1

Slice ID #2

…

Slice ID #5

CAG ID #1

Slice ID #6

Slice ID #7

…

Slice ID #n

CAG ID #n

. . .Coordination

NAS: Mapping between

CAG ID and NPN ID

SI: Supported CAG ID(s)

Figure 0-6 Slice aware mobility in NPN

4.4.2 Simulated Slicing Technology in Non-standalone (NSA) Mode

As one of the key technologies of 5G networks, network slicing allows a variety

of customized exclusive network services to be created over a shared physical

infrastructure, and provides multi-level isolation and security features, thereby

reducing the expenditure of network deployment and meeting the needs of various

vertical industries. Network slicing is an enabling technology for the 5G networks to

serve vertical industries in the future. Network slices include RAN sub-slices, core

network sub-slices and transport network sub-slices. To put it simply, network

sub-slices serve different slices by identifying and perceiving the Single Network

Slice Selection Assistance Information (S-NSSAI) field.

In a 5G network, a slice is indicated by NSSAI. To enforce E2E network slicing,

the 5G core network (5GC) needs to acquire and configure S-NSSAI for each


22

sub-slice. However, the NSA architecture does not support network slicing because it

uses 4G core network (EPC). To implement some primary slicing functions in NSA,

consider logical isolation of functions and simulation of the slice identifiers by

specifying the existing identifiers. On one hand, apply logical separation and

differentiated identifiers based on network architecture; on the other hand, design

function enforcement and overall service flow on the RAN side. It can be realized in

the following ways:

⚫ Service-specific PLMN: The network is divided based on multiple PLMNs.

Dedicated PLMNs are deployed for specific types of terminal devices. The

RAN selects the core network and performs wireless resource reservation or

slicing based on PLMN. Different slices share the base stations. Various local

services can be configured for the local edge clouds. For example, IoT and

the common UE are configured with independent PLMNs, respectively.

⚫ Service-specific APN: Configuration of multiple APNs (such as IMS APN,

roaming APN, MVNO APN, etc.) on the PGW enables the separation of

multiple services. Dedicated PGWs and PCRFs are configured for some

APNs to enforce network slicing.

⚫ DECOR: A method of routing specific users to a dedicated core network

(DCN) based on user information and operator configuration. The operator

configures multiple DCNs using one PLMN, and selects the qualified MME

based on the user information (UE USAGE TYPE) stored in the HSS and the

newly added Reroute NAS Request procedure.

⚫ eDECOR: The UE delivers DCN-ID to the RAN for MME selection in the

initial registration phase (for the purpose of reduced signaling burden). The

DCN ID configured on the UE is required by the specified core network. The

RAN selects the MME by DCN ID provided by the UE. On one hand, the

eNB obtains the DCN information (such as DCN ID) of the serving node

through the S1 establishment process. On the other hand, the UE carries the

DCN assistant information to the eNB through an NAS message and RRC


23

signaling, during the initial attachment, TAU request or RAU request process.

Finally, the eNB selects the correct DCN based on the above two information

sources.

Figure 0-7 Simulated Slice Architecture in NSA Mode

For the RAN side, the overall service process invovles the following parts:

⚫ Requirement analysis: Analyze and group the requirements for the UE;

define separate sub PLMN, UE USAGE TYPE, and APN for customers with

the same requirements; and define differentiated user identification

mechanisms.

⚫ Custom design of RAN analog slicing functions: Divide and identify the

functions in multiple dimensions such as RAN resources, scheduling policies,

and other cell or user parameters. Shared or separate cells can be used to

implement the sharing mechanism in which a base station supports

mult-identifier slices and different implementations under slices.

⚫ Establish separate local gateways. In the service process, users access a

network from different cells, and different service gateways are selected for

traffic offloading.

Compared with 5G slicing technology, the NSA-based analog slicing technology

is difficult to meet the comprehensive slicing requirements, including flexibility, and


24

flexible multi-slicing at one terminal. It is also more complex for the quantity,

scalability and reconfiguration of slices.

5 RAN Slicing Use Cases

5.1 Unmanned Aerial Vehicle (UAV)

Figure 5-4 UAV architecture for the 5G network

Note: NR: New Radio; NC: New Core; UTM: UAS Traffic Management; NEF:

Network Exposure Function

The UAV network architecture for the 5G network is shown in Figure 5-1. The

whole system is based on the 5G access and core networks. It enables the NEF to

bidirectionally define and open the UAV system and the mobile communication

network. The UAV data links mainly cover UTM data links, UAV command and

control (C2) data links, and UAV payload pod service links. They are respectively

used for the functions of the UAV, such as flight management service, telecontrol and

telemetry link, and data image acquisition.

In the three types of data links, the UTM system consists of a UAV cloud

platform and a government management platform. The UAV cloud platform is served

by a government-authorized UAV cloud operator. The government departments

manage the UAV system by forwarding messages on the UAV cloud platform. The


25

UTM data links require low latency and high reliability (latency of less than 20 ms,

and reliability of 10^-6). Therefore, they need to be specially designed, as shown in

Figure 5-2.

Figure 5-5: UTM data links

Link 0: It serves for manufacturing data. It is used only for the data

communication between government departments and licensees. The security of

identity information needs to be considered.

Link 1: It transmits the end-to-end and high-security management data between

the UAV and government departments during the use of the UAV system. The UAV

cloud platform transparently transmits and forwards data. However, it cannot view

and tamper with the content of such data. This link mainly serves for the legal control

and emergency handling of UAVs by government departments.

Link 2: It transmits the medium-security management data between the UAV and

the UAV cloud platform during the use of the UAV system. This link mainly

implements the state and instructions related to the flight management of the UAV

cloud platform for the UAV, such as keepalive for heartbeat, flow control,

authorization for take-off, and emergency alarms.

Link 3: It transmits the low-security management data between the UAV and the

UAV cloud platform during the use of the UAV system. This link mainly implements


26

status reporting and monitoring, and notification service between the UAV cloud

platform and the UAV.

Link 4: It serves for registering the cloud service between the UAV user or

operator and the UAV cloud platform. It requires secure registration data.

Link 5: It serves for the data communication between the UAV cloud platform

and government departments. It requires secure servers in the government

departments.

Link 6: It achieves the real-name registration between the UAV owner and

government departments. It requires secure registration data.

Links 1–3 transmit data in radio links. They use different frequencies and carrier

resources to establish different link slices to ensure the SLA. Moreover, they

accomplish the slice-based connection and mobility management. Links 4–6 involve

government departments and platforms. They mainly use slices for secure isolation, to

monitor and manage different slice KPIs, achieve high-security servers in the

government departments, and to reduce malicious online attacks from illegal

platforms to the government departments.

5.2 Industrial Internet

The emerging service scenarios of 5G networks, eMBB, URLLC, and mMTC,

raise more rigorous requirements on the bandwidth, latency, throughput, and

reliability of existing networks.

As mentioned earlier, the features such as throughput, latency, availability,

service continuity, isolation level, the number of users, and coverage at the slice level

can flexibly adapt to the differentiated requirements of emerging service scenarios in

the 5G networks. RAN slicing aims to enable a high-performance and efficient

wireless network that provides customized and differentiated network services to meet

the requirements of various industries, customers and services over shared RAN

infrastructures and resources.

As a product of the deep integration of the new-generation information


27

technology and manufacturing industry, the industrial Internet has become a key

support and an important driver for the digital transformation of the industrial

economy by comprehensive connection of humans, machines and things. As

industries become more automated and decentralized, RANs become particularly

important in the industrial environments where wired infrastructure is scarce or

difficult to implement. Moreover, network connection failure and transmission latency

are increasingly serious in the network interconnection issues of the industrial Internet.

In the industrial field, even a one-millisecond latency of signals between devices may

cause a serious damage to a production line, and a huge loss to the enterprise.

Therefore, the speed, real time and reliability of network communications are critical

to today's industrial Internet. However, the existing conventional RANs suffer from

the structurally closed rigidity, highly limited data transmission and forwarding

performance, and low network resource utilization, failing to meet the diverse service

requirements in the future. As a result, 5G networks need to be constructed flexibly.

For mobile network operators, 5G networks should be an E2E flexible, scalable and

requirement-oriented system. E2E RAN slicing in 5G networks is considered as a key

driver for this challenging goal.

As a typical high-reliability and low-latency communication service, industrial

remote control has high latency and reliability requirements for data transmission

networks. Compared with the limitations of conventional networks, the preceding

related RAN slicing technology applies to the industrial Internet. For example, it

reserves dedicated radio resources for industrial Internet services by reservation based

resource isolation schemes to fully use the limited network resources. It also flexibly

allocates network resources for specific service types on demand. Moreover, it can

shorten the latency from various aspects of the air interface. Consolidating the slicing

and QoS mechanisms, it deeply optimizes the RAN by three important indicator

dimensions such as the rate, latency, and reliability of the air interfaces to ensure the

qualitative and/or quantitative performance.

Inverted pendulum is a typical scenario applied in the industrial remote control.


28

Its working principle is widely used in various mechanical control devices such as

balance bikes, robots, and spacecrafts. Now, the remote automatic inverted pendulum

is taken as an example to introduce the application of RAN slicing in the industrial

Internet.

Figure 5-6 Remote automatic inverted pendulum

As shown in Figure 5-3, the remote automatic inverted pendulum consists of the

hardware components, data collection/feedback module, RAN module, policy control

module, Open vSwitch(OVS), and SDN controller. The data collection/feedback

module collects sensor data for motor encoders and angle potentiometers of the

underlying hardware through the embedded master development board. It sends the

motor speed value to the policy control module through the RAN module by means of

network communication. The policy control module calculates the feedback result by

the control algorithm according to the motor speed value in the current state. The

motor works as the action execution unit. It balances and adjusts the inverted

pendulum according to the feedback result. In this way, the inverted pendulum

maintains its vertical inverted balance. In the data interaction process, multiple virtual

ports are set on one physical OVS switch by means of Software Defined Networking

(SDN) and Network Function Virtualization (NFV) technologies. The queues and


29

queue rules are also flexibly set on each port according to the service requirements, to

allocate dedicated RAN resources for the inverted pendulum service. In addition, the

SDN controller completes related management processes. For example, it creates,

allocates, deletes, queries, and updates slices. It uniformly allocates resources,

orchestrates network functions, implements RAN slicing, and logically divides the

unified physical network into multiple virtual networks. It allocates differentiated

network resources to the service data in the network as needed, to guarantee the

inverted pendulum service quality.

5.3 Public Service Slicing

The most basic RAN slicing technique is slicing customization and resource

isolation (slice-separated management in RAN). The resources are pre-allocated to

ensure slicing performance. For example, physical resources can be cut and

pre-allocated for slicing. A frequency or frequency band can also be allocated

exclusively for slicing. For resource isolation, the RAN device needs to ensure that

resources allocated for slicing are not affected by other sliced services. Therefore, it

must perform a slice-based admission control check at the time of the service request

at the terminal. When the resources for new services exceed those allocated for slicing,

the access request will be rejected.

Operators may provide dedicated slices for public services involved in public

security, government administration, and police, etc. These services feature stable and

low resources used in most service hours. Therefore, the pre-allocated slicing

resources are low and stable. Slice-separated management in RAN can ensure the

public services. Private service requests do not use the most basic resources required

for public services.

In the event of a regional or nationwide emergency, the resources pre-allocated

for the public service slicing are seriously insufficient. In this case, the bandwidth or

resources need to increased in time. However, the resources are allocated statically for

current slicing according to the SLA, and they cannot be expanded rapidly through the


30

process. In case of emergency, the public sliced services cannot use the resources for

other slices because of resource isolation. Consequently, huge idle resources still exist

in other slices.

Therefore, slice resources can be preempted in the industrialization of network

slicing. Priority is assigned among slices. If resources are insufficient, a high-priority

public security slice can occupy resources of a low-priority commercial slice. These

resources may include bandwidth, CPU, and transmission resources. Slice preemption

can also be at PDU level. When a user of public service slices requests new resources,

the access device checks the user's slice attribute under the slice-based admission

control. If the attribute is the public service with the highest priority, it allows access

and allocates resources of other slices for the request. When the emergency subsides,

the service requests from users of the public service slices change to the normal

situation. As a result, the impact on other slices is reduced to a minimum.

The public service slices are subject to a combination of the slicing and QoS

technologies. The public service slices do not have sufficient dedicated resources

from the operators. However, they expand rapidly in an emergency due to their

high-priority QoS. They can preempt the resources of other non-emergency important

slices to ensure normal public services.

6 Conclusion and Vision

The RAN requires slicing. RAN slicing covers the service flow QoS, slice-level

quality parameters, slice-customized network functions, and O&M monitoring. It is

essential for E2E slicing. For the slice indicators, the RAN slicing needs to be further

studied and standardized in technologies. This involves many aspects including

custom slice functions, slice-separated resources, slice-level QoS guarantee,

perceptual slice access and mobility enhancement, and optimization of slice

monitoring management. Sophisticated RAN slicing enables network slicing to fully

meet the requirements of the vertical industries for high communication quality,

including the requirements for highly reliable services such as UAV, industrial


31

Internet, and public services.


32

7 Reference

[1] 3GPP TS 22.261 V16.2.0 (2017-12), Service Requirements for 5G System

(Release 16)

[2] 3GPP TS 23.501 V16.2.0 (2019-09), System Architecture for the 5G System

(5GS); Stage 2 (Release 16)

[3] 3GPP TS 38.300 NR; Overall description; Stage-2

[4] 3GPP TS 28.801 Telecommunication management; Study on management and

orchestration of network slicing for next generation network

[5] 3GPP TS 28.530 Aspects; Management and orchestration; Concepts, use cases

and requirements

[6] R5 (El Alto) for Orchestration of Network Slicing Model

[7] TOSCA based service and network slice modeling

[8] GSM Association Non-confidential, Official Document NG.116 - Generic

Network Slice Template, Version 1.0, 23 May 2019

Abbreviation

3GPP the 3rd Generation Partner Project

5G the Fifth-Generation Mobile Communications

6G the Sixth-Generation Mobile Communications

API Application Programming Interface

CN Core network

eMBB enhanced Mobile BroadBand

ETSI European Telecommunications Standards Institute

KPI Key Performance Indicator

IMS IP Multimedia Subsystem

mMTC massive Machine Type Communication

NaaS Network as a Service

NPN Non Public Network

OMC Operation and Maintenance Center


33

ONAP Open Network Automation Platform

PCC Policy and Charging Control

PCF Policy Control Function

PDU Packet data unit

QoS Quality of Service

RAN Radio Access Network SD slice differentiator

SLA Service Level Agreement

S-NSSAI Single Network Slice Selection Assistance Information

SST Slice/service type

URLLC Ultra-Reliable Low Latency Communications

Acknowledgement

Grateful thanks to the following contributors for their wonderful work on this white

paper:

Editors:

CMCC: Chih-Lin I, Chengkang Pan

Contributors:

CMCC: Yami Chen, Yali Guo, Zhao Sun, Xuanyu Guo, Long Zhang, Jian Ma, Huan

zhang

China Unicom: Jing Li, Qiuli Dong

Huawei: Wei Tan, Yinghao Jin, Feng Han, Gang Li

ZTE: Dapeng Li

Xidian University: Yanjun Guo, Yayong Hua

Tsinghua University: Ming Zhao, Zhigang Tian


Documents

5G White Paper : RAN Slicing Slicing... · X1\01 E@0G 6û4ý¶5 5 7(w,´ ² % ¦ * 4ï Õ 5 5 _ ... Network slicing has been recognized as a core enabling technology in 5G networking