1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47  48  49  50  51  52  53  54  55  56  57  60  61  62  63  64  65  

Impact of Network Slicing on 5G Radio Access Networks

Icaro da Silva1, Gunnar Mildh1, Alexandros Kaloxylos2, Panagiotis Spapis2, Enrico Buracchini3, Alessandro Trogolo3, Gerd Zimmermann4, Nico Bayer4; 1Ericsson, Sweden; 2Huawei Technologies ERC, Germany; 3Telecom Italia, Italy;

4Deutsche Telekom AG, Germany

Abstract—Network slicing addresses the deployment of multiple logical networks as independent business operations on a common physical infrastructure. The concept has initially been proposed for the 5th Generation (5G) core network (CN) however, it has not been investigated yet what network slicing would represent to the design of the 5G radio access network (RAN). The paper explains how network slicing may impact several aspects of the 5G RAN design such as the protocol architecture, the design of network functions (NFs) and the management framework that needs to support both the management of the infrastructure to be shared among the slices and the slice operation.

Keywords—network slicing; radio access network; RAN design; METIS; METIS-II.

I. INTRODUCTION

Network slicing is an important part of the NGMN’s vision for the overall 5th Generation (5G) architecture [1] that addresses the deployment of multiple logical networks as independent business operations on a common physical infrastructure. The ultimate goal would be to provide “network slices on an as-a-service basis” and meet the wide range of use cases that the 2020 timeframe will demand e.g., for the different industries [2]. The creation of network slices is mainly business driven and should also address the needs of different 5G use cases with highly diverging requirements. According to [1] [2], a slice is seen from an end customer perspective or slice customer as an independent network. However, in contrast to deploying an independent network infrastructure, each slice will be realized together with other slices on a common infrastructure, also including assets such as licensed spectrum. In this way, the infrastructure and assets utilization will be much more cost and energy efficient compared to present realizations.

The concept of network slicing has initially been proposed for the 5G core network (CN) [3]. By exploring software-defined networking (SDN) and network function virtualization (NFV) principles a fully virtualized CN instance optimized per business purpose could be defined. Within 3rd Generation Partnership Project (3GPP), network slicing is considered to primarily targets a partition of the CN, but it is not excluded that RAN may need specific functionality to support multiple slices or even partitioning of resources for different network slices [4]. The work in 3GPP about the overall 5G system has recently been kicked-off with an approved study item in the 3GPP Working Group SA2 [5]. The support for network

slicing appears as one of the key requirements. The first 5G Radio Access Network (RAN) study items in 3GPP start in 2016 and the network slicing impact to the RAN and the User Equipment (UE) should certainly be in the scope.

This paper contributes to the RAN design by analyzing requirements to be fulfilled to support network slicing. These requirements, discussed in Section II, are intended to guide the design of a future proof RAN enabling the smooth introduction of new features and services. The paper identifies parts of the RAN that will likely be affected by the network slicing requirements. The first is the “protocol architecture”, i.e., how is the split between functions among the layers of the protocol stack and how different functions may be relevant or not to different slices and/or services. The second aspect is the “design of network functions (NFs)” as common or dedicated NFs per slice. The third aspect relates to the “management of the infrastructure to be shared among multiple slices” and “the management of individual slices to enable a proper business operation”. These aspects are discussed in Section III and findings summarized in Section IV.

II. RAN REQUIREMENTS RELATED TO NETWORK SLICING

A first step to understand the impact of network slicing to the 5G RAN design has been given by identifying RAN-specific requirements needed to fulfill the network slicing vision. The derived set of requirements is the following:

Utilization of RAN resources, such as radio resources (e.g. time, frequency, power, etc.) and hardware (HW) / software (SW) platforms, should be maximized among multiple slices;

RAN should be slice-aware via some explicit or implicit identification (e.g., based on an abstraction model);

RAN should support mechanisms for traffic differentiation in order to be able to treat different slices differently and/or different services within the multi-service slices;

RAN should support protection mechanisms to minimize inter-slice effects (such as the congestion of one slice negatively affecting the other);

RAN should support efficient management mechanisms e.g. to efficiently set up new slices and to efficiently operate new business/services.

EuCNC2016-BusAsp 1570257560

1

A. Utilization of RAN resources should be maximized

Network slicing should make possible to support several different logical networks on the same physical network infrastructure in order to reduce costs and energy consumption compared to deploying separate physical networks for the different use case or business scenarios. In order to fully exploit this benefit, it is required that the slicing concept allows for efficient usage of radio resources and infrastructure, and transport links between the slices such as fronthaul and backhaul. In any case, this requirement does not preclude the possibility to assign dedicated (static) resources.

Fig. 1. Radio resources shared in a dedicated and dynamic manner.

For example, static splitting of the available resources and users into two equal slices, as illustrated in Fig. 1, could, depending on the service bit-rate requirements, easily lower the overall (busy hour) capacity by 20%, while splitting into 5 equal slices lead to a loss of more than 50% (result from simple Erlang B calculations, assuming a maximum of 1% blocking and maximum of 30 active users sharing the resources). In the case multiple slices are sharing the physical resources it would be preferred that the sharing is dynamic, making it possible to adapt to rapid changing traffic patterns as typical for many Internet services. It is expected that sharing mechanisms being able to operate on radio frame or Time to Transmit Interval (TTI) level (i.e. in the low ms range) will be better than mechanisms that operate on longer time scales (e.g. 100 ms level or above). Considering the above example with dynamic sharing of resources between different slices it is assumed that the slices could either use common or coordinated radio and transport schedulers. In this way one slice can utilize the full bandwidth if there is no traffic in the other slice achieving maximum efficiency.

B. RAN should be slice-aware

Current 3GPP networks support extensive quality of service (QoS) mechanisms such as bearers, QoS class indicators (QCI), allocation and resolution priority values making it possible to prioritize different services and signalling in a different way. The question arises if these mechanisms can also be used to support network slicing as is and thus avoiding the need to make the RAN slice-aware. Most likely, existing mechanisms are not enough to support all possible slicing scenarios. For instance let us assume a slice A with both high and low priority traffic but where the traffic at congestion is not allowed to consume say more than X% of the total system resources (the rest is given to other slices). In this case there might be a will to treat the high priority traffic of slice A with absolute high priority up to X%, but after that the traffic from other slices should have higher priority. These

types of mechanisms are currently not directly supported using existing QoS concept since there is no mechanism to apply specific policies in the RAN to a group of UEs. For this reason the RAN should be made slice-aware. This can be done e.g. by providing information such as some form of Slice-ID, another abstraction framework or by extended individual data packet tagging on the interface between RAN and CN (see e.g. [6]).

C. RAN should support mechanisms for traffic differentiation

One of the drivers for network slicing is the ability to support 5G use cases with diverging requirements. Therefore, in addition to make the flows and slices visible to the RAN, mechanisms to prioritize different traffic over the radio and transport interfaces should be supported. Current 3GPP systems already support such mechanisms using radio schedulers and Diffserv, etc. It is assumed that similar mechanisms are also required for the 5G RAN. Further investigations are ongoing in order to verify whether the slicing in the 5G RAN requires any additional functions that are not currently in place.

D. RAN should support protection mechanisms

In addition to prioritization of traffic over the radio and transport interface, protection mechanisms are required in order to minimize negative inter-slices effects especially important in the case slices share radio resources (e.g. common radio channels) so that congestion in one slice does not have a negative impact on another slice. Currently in 3GPP system there is some support for protecting common control channels for extensive load from different services. These mechanisms include Access Class Barring, Enhanced Access Barring, Service Specific Access Barring, as well as implementation specific admission control etc. It needs to be investigated whether existing barring and admission control mechanisms used in LTE are enough to support network slicing, or if additional slice specific barring and admission control mechanisms are required to provide enough isolation and protection between slices.

E. RAN should support the management of the infrastructure

The slicing concept should efficiently enable fast set up of new services and applications or modification of existing ones. It should also enable an efficient management of operators’ assets (such as licensed spectrum) and the network topology, including the HW and SW resources available at the different sites (processing, networking, and storage capabilities). It shall be also possible to properly and efficiently take into consideration the corresponding performance and business requirements for the different slices such as the number of the devices, their mobility and traffic patterns, the delay, and the jitter requirements, the device capabilities, etc.

It is also envisioned that the vertical industries, mobile virtual network operators (MVNOs), over-the-top (OTT) service providers or mobile network operators (MNOs) themselves should be allowed to manage aspects of a network slice as if it was a separate dedicated network. This could be realized e.g. via the definition of application programming interfaces (API). The management framework for network slicing therefore should provide slice specific performance

2

management (PM) which should include PM counters, key performance indicators (KPI), as well as configuration management (CM) and fault management (FM) techniques. For the slice specific CM and FM functions it is expected that there will be close interactions with the CM and FM of the whole network which governs (based on policies) what the slice specific CM and FM functions are allowed to see and to execute.

III. IMPACT OF NETWORK SLICING TO THE 5G RAN DESIGN

The first 5G RAN study items in 3GPP start in 2016, where the definition of the RAN architecture (or design) is one of the main topics to be addressed. Ongoing investigations conducted within METIS-II have concluded that three of the aspects that will be impacted by the requirements discussed in Section II are the following:

Protocol architecture, which defines the NFs per protocol necessary to fulfill the 5G requirements. A special attention is given to the air interface protocols. However, network slicing might also impact the CN / RAN functional split, i.e., which NFs are logically defined as CN or as RAN NFs.

Design of NFs, which affects which of the NFs should be common to multiple slices and which NFs could be independent (possibly with some level of coordination between them).

Network management, which defines how the current RAN management frameworks (e.g., PM, CM, FM) could potentially be extended to enable both an efficient management of the infrastructure and the network slices for proper business operation.

A. Protocol Architecture

The requirement that multiple slices should be served by the same network infrastructure leads to a solution based on a common protocol architecture addressing multiple slices. The protocol architecture defines the set of NFs per protocol necessary to fulfil the end-user and system requirements. Network slicing will likely affect the design of this common protocol architecture since there will be the need to support different 5G use cases or services, e.g., Massive Machine-Type Communication (mMTC), Ultra-Reliable MTC (uMTC) or Extreme Mobile Broadband (xMBB) [7] which could each be mapped to a given slice or multiple of these services defining sort of multi-service slice. It is likely that mMTC services (e.g., supporting very low cost sensors) will benefit in having different set of NFs, protocols and/or protocol configuration(s) compared to xMMB services (e.g., requiring higher spectral efficiency) or uMTC services (e.g., requiring very high reliability with bounded latency). It is envisioned that the following features should be supported by the RAN architecture.

1) Selection / omission of NFs per slice The fact that the set of required NFs could differ from one

slice to another is mainly driven by the fact that different services may have quite different sets of performance requirements and overall characteristics (e.g., traffic and

mobility patterns). That could also be driven by different Service Level Agreements (SLA).

For instance, let us assume a “slice provided for uMTC smart grid network” compared to a “slice provided for xMBB”. Smart grids are static nodes that have to transmit only small messages with end-to-end delay of less than 8 ms, whereas for the xMBB use cases such as the Dense Urban Information Society the acceptable delay is of up to 50 ms for the human oriented services [7]. In smart grid networks the integrity of the data to be transmitted under specific delay constraints is essential. In such slices the NFs related to handover, location updates, fragmentation and reassembly may be possibly tailored (e.g., by introducing grouping schemes to assist their operation) or even proven unnecessary since the service requires the transmission of very small packets from static nodes.

2) Slice-tailored NFs optimizations In addition to the selection and/or omission of NFs per

slice, different slices and/or services should possibly benefit from slice-tailored NFs optimizations. Regarding the random access of a massive number of devices, the collision rate could be drastically reduced by the introduction of grouping schemes with various prioritizations in the devices trying to access the wireless medium, especially in the case of static groups where there is no major cost in setting up these groups. In [8] the authors propose a group based access of the wireless medium where the cluster heads’ communication is coordinated (Fig. 2), whereas in [9] focus is on the omitting of redundant message transmissions.

Fig. 2. Example of how service-tailored random access optimization can be beneficial in mMTC using cluster based access [10].

For three specific service examples, Fig. 3 shows the potential of service-tailored NFs.

3) QoS framework for slice awareness Another aspect of the protocol architecture that may need

enhancements is the QoS framework. The envisioned scenarios for network slicing may lead to cases where a slice may be composed by multiple services which may have different treatment in the RAN. Therefore, in that case, the QoS framework needs to take into account some slicing level information in addition to service level information. That could be explicit information or some abstraction (such as an enhanced identity, like the QCI). In the example of Fig. 4 a Slice-ID is reported from the CN to the RAN. In addition to that, the omission or selection of NFs described previously

3

could lead to enhancements to the QoS framework where different flows per slice / bearer types could be mapped to subset of NFs.

Fig. 3. Example of service-tailored optimization for different slices.

4) CN / RAN functional split One of the assumption in 3GPP concerning the overall 5G

system is the CN /RAN functional split [5]. This would allow an independent evolution of the RAN and CN functions in order to speed up introduction of new technology and services and facilitate multi-vendor CN/RAN interoperability. One of the options in [5] is to keep the same functional split in the Evolved Packet System (EPS). This seems a reasonable choice, at least for xMBB slices, however, there could be new 5G services and use cases that could benefit from a different CN/RAN split, e.g., static devices benefiting from a RAN-based paging, which is currently a core NF.

In order to support the tight integration of LTE to the 5G RAN, a common CN/RAN interface denoted S1* that evolves from the existing S1 is considered as one alternative [10]. Network slicing may impact the design of protocols for that interface that may need to support potentially different functional splits per slice.

Fig. 4. One way to make RAN slice-aware is via a Slice-ID.

B. Impact to the Radio NFs

In order to fulfill the requirement regarding the sharing of RAN resources among different slices, it is required to efficiently use radio and transport network resources between different slices (including both common channels and dedicated channels). From that perspective some radio NFs (such as schedulers) are either defined as “common NFs” or “independent/dedicated NFs” with (at least some) coordination mechanisms between NFs from different slices. This means that the radio NFs of one slice do not operate in complete isolation from another slice. Possible

implementation of such scenario could include a set of common radio NFs which provides slicing as a service to higher layers. It is also possible to have more dedicated radio NFs running that communicate with some common resource management framework. One possible example that could be a set of common radio NFs related to radio resource management (e.g., scheduling, random access, etc.) and a set of dedicated NFs e.g. core NFs.

The choice among common or dedicated NFs may be affected by the way radio resources are used. In LTE it is theoretically possible to introduce different protocols and/or NFs on dedicated channels as soon as contention resolutions have been performed. On the other hand, when it comes to protocols related to the access of common channels such as the random access channel (RACH) the same or compatible protocols need to be used to allow efficient multiplexing and therefore the task becomes more challenging. For the 5G RAN design it could be envisioned to further reduce the number of common channels allowing for different NFs, protocol configurations, or even protocols to be used in parallel. One could also try to harmonize as much as possible the protocol stack to maximize the reuse of different NFs in order to speed up standardization and product (UE and RAN) development and testing. A possible scheme is shown in Fig. 5.

NF 1 NF2

NF4NF3

NF5’NF3’

NF5

The level of the separation of two slices could vary depending on the considered case

Fig. 5. Common NFs providing services to independent/dedicated NFs.

C. Impact to Network Management

1) Performance monitoring and optimization per slice As described earlier, the PM solution at the 5G RAN may

consist of counters, traces and/or KPIs possibly aggregated at least in a per slice granularity (in addition to existing granularity e.g. per service, flow, etc.). Such monitoring could be essential to verify the fulfillment of SLAs and/or to properly operate the different business associated to different slices. In the case of CM, some features could be tuned, turned on/off and/or possibly configured differently from different slices. That may also affect the way Self-Organizing Networks (SON) functions are designed.

2) Sharing of HW/SW platforms for multiple slices Novel management schemes for radio resources

reconfiguration may be adopted for their more efficient use e.g. in order to adapt the network to the dynamic behavior of the traffic and to globally maximize the capacity. In fact, given a cell set in a certain area, the traffic of different slices or services e.g. on a specified air interface may change from one sub-area to the other according to the day period (e.g., in a stadium before, during and after an event such as a football match or a concert). It often happens that some areas may be congested (with high blocking percentages) in some particular area (the so-called hot-spots as the stadium) in which the

4

traffic is more consistent, while surrounding cells are less loaded or characterized by low blocking percentages.

A management framework, enabling the use cases just described, includes both radio reconfiguration management and reconfigurable HW. The radio reconfiguration management functionality spans different air interfaces managing and controlling the nodes inside the network, with the goal of self-adapting towards an optimal mix of supported air interfaces and frequency bands. This function could act on the basis of some input parameters, such as the available resources (spectrum and HW), the traffic demand, the capabilities of the UEs within the network (supported air interfaces, frequency bands, etc.), the requested services (bandwidth, QoS, etc.), etc. In addition, this functionality could exploit a collaborative radio reconfiguration management scheme, where the decision making functions are shared among different network nodes. The main features can be summarized as follows:

The dynamic self-adaptation of the network configuration towards an optimal mix of supported air interfaces and frequency bands can be achieved by the exploitation of the reconfigurable HW and the application of radio reconfiguration management functionalities;

The dynamic self-adaptation (e.g. network configuration) can be based on the traffic patterns variations in time and space for the different deployed air interfaces or according to specific needs (i.e., IoT service provision, integration of high frequency air interfaces, etc.);

Ability to provide sufficient information to the terminals for initiating a communication session appropriately in a dynamic context (e.g. wireless control channels).

IV. CONCLUSION

The paper presented a set of requirements to guide the 5G RAN design in order to support the concept of network slicing, envisioned by NGMN. These requirements should drive the design of a common protocol architecture supporting multiple slices and services, but allowing slice-tailored optimizations and NFs usage (where different subsets of NFs can be possibly used per slice). The most efficient way to

realize and/or standardize this common architecture is still under investigation. It has also been concluded that the identified requirements may also impact the CN/RAN interface (e.g., to possibly support different functional splits) and the QoS framework (e.g., to possibly support slice awareness in the RAN and traffic differentiation within a slice). Finally, the paper also provided the envisioned impact to the management framework of the 5G RAN. Two aspects have been investigated, the need to support the management of the infrastructure to be shared and the management of the different slices that may be associated to different business purposes.

ACKNOWLEDGMENT

This work has been performed in the framework of the H2020 project METIS-II co-funded by the European Union (EU) [11]. The views expressed are those of the authors and do not necessarily represent the project. The consortium is not liable for any use that may be made of any of the information contained therein.

REFERENCES

[1] NGMN Alliance, “5G White Paper”, February 2015.

[2] Ericsson, “5G Systems White Paper”, January 2015, see http://www.ericsson.com/res/docs/whitepapers/what-is-a-5g-system.pdf

[3] Ericsson, “The Real-Time Cloud White Paper”, February 2014, see http://www.ericsson.com/res/docs/whitepapers/wp-sdn-and-cloud.pdf

[4] 3GPP TR 22.891, “Study on New Services and Markets Technology Enablers”, V1.2.0, November 2015.

[5] 3GPP S2-153651, “Study on Architecture for Next Generation System”, October 2015.

[6] Deutsche Telekom, T-Mobile USA, “Deutsche Telekom’s view on 5G“, 3GPP RAN 5G Workshop, Sep 17th-18th, 2015, Doc. no. RWS-150033.

[7] ICT-671680 METIS-II, Deliverable 1.1 Version 1 “Refined scenarios and requirements, consolidated test cases, and qualitative techno-economic feasibility assessment”, January 2016..

[8] Konstantinos Chatzikokolakis, Alexandros Kaloxylos, Panagiotis Spapis, et al., “On the Way to Massive Access in 5G: Challenges and Solutions for Massive Machine Communications”, CrownCom 2015.

[9] Yunyan Chang, Chan Zhou, Oemer Bulakci, “Coordinated Random Access Management for Network Overload Avoidance in Cellular Machine-to-Machine Communications”, European Wireless 2014.

[10] I. Da Silva, G. Mildh at al., “Tight integration of new 5G air interface and LTE to fulfill 5G requirements,” IEEE 81st Vehicular Technology Conference (VTC Spring), Glasgow, May 2015.

[11] METIS-II project (“Mobile and wireless communications Enablers for Twenty-twenty (2020) Information Society II”), see https://5g-ppp.eu/metis-ii/.

5

本文献由“学霸图书馆-文献云下载”收集自网络，仅供学习交流使用。

学霸图书馆（www.xuebalib.com）是一个“整合众多图书馆数据库资源，

提供一站式文献检索和下载服务”的24 小时在线不限IP

图书馆。

图书馆致力于便利、促进学习与科研，提供最强文献下载服务。

图书馆导航：

图书馆首页 文献云下载 图书馆入口 外文数据库大全 疑难文献辅助工具