On the impact of network slicing on 5G radio access networks

Transcription

1 On the impact of network slicing on 5G radio access networks Icaro Leonardo Da Silva, Gunnar Mildh Wireless Access Networks Ericsson Research Stockholm, Sweden Alexandros Kaloxylos, Panagiotis Spapis European Research Center Huawei Technologies, Duesseldorf GmbH, Munich, Germany Enrico Buracchini, Alessandro Trogolo Wireless Access Telecom Italia Lab Turin, Italy Gerd Zimmermann, Nico Bayer Telekom Innovation Laboratories Deutsche Telekom Darmstadt, Germany Abstract This paper presents an analysis of the impact that the network slicing concept may have on the 5G radio access networks (RAN) in order to fulfill NGMN s vision and support the wide diversity of services from different industries. 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 5G core network (CN) and has evolved to end-to-end (E2E) network slicing. However, it has not been investigated yet what network slicing would represent to the design of the 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 (NF) and the management framework that needs to support both the management of the infrastructure to be shared among the slices and the slice operation. and should also address the needs of different 5G use cases with highly diverging requirements. A network slice is envisioned to support the communication service of a particular connection type possibly with a specific way of handling control plane and user plane for this service. To this end, a 5G slice could be composed of a collection of 5G network functions (NF) and specific air interface / radio access technology (RAT) settings that are combined together for a specific use case and/or business model (see Fig. 1). Keywords network slicing; radio access network; RAN design. I. INTRODUCTION Worldwide initiatives in the mobile industry have started in the past few years in order to define the requirements and principles of what is to be standardized in the 5 th generation of mobile networks (5G). These initiatives (research projects, industry fora, etc.) have acknowledged the demand of mobile networks that are capable to cope with a much higher diversity of use cases in order to unleash new business opportunities to the telecom industry. Among these initiatives are the Mobile and wireless communications Enablers for the Twenty-twenty (2020) Information Society II (METIS-II) [1], a research project focused on standard related problems associated to the 5G RAN design, and the Next Generation Mobile Networks (NGMN) Alliance [2]. Network slicing is an important part of the NGMN s vision for the overall 5G architecture [2] 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-aservice basis and meet the wide range of use cases that the 2020 timeframe will demand e.g., for the different industries [3]. The creation of network slices is mainly business driven Fig. 1. Network slicing concept as envisioned by NGMN [2]. According to [2] [3], 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 referred to as virtual network ), 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) [4]. By exploring softwaredefined networking (SDN) and NF virtualization (NFV) principles a fully virtualized CN instance optimized per business purpose could be defined. The concept has been

2 evolved by NGMN to end-to-end (E2E) network slicing. This is somewhat underlined through statements in 3 rd Generation Partnership Project (3GPP) study items such as the network slicing 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 [5]. 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 [6]. The support for E2E network slicing appears as one of the key requirements. Even though that the first 5G Radio Access Network (RAN) study items in 3GPP start in 2016 and despite the introduction of the notion of E2E slicing, it has not been investigated yet what network slicing would represent e.g., to the RAN design, which comprise both network side and User Equipment (UE). This paper aims to provide a relevant contribution to the 5G standardization process by a detailed analysis of a set of requirements to the 5G RAN that have been identified in order 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. In this perspective the paper identifies the aspects of the 5G RAN that are envisioned to be affected by the RAN requirements related to network slicing. 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 NFs, i.e., defining which NFs should be common to multiple slices (e.g. in the case of some kind of resource sharing) and which NFs could be independent (possibly with some level of coordination). 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 three aspects are discussed in Section III. Finally, the findings of our analysis are 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 RANspecific 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) 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 for slice isolation so that events (such as congestion) within one slice do not have a negative impact on another slice; RAN should support efficient management mechanisms e.g. to efficiently setup new slices and to efficiently operate new business/services. A. Utilization of RAN resources should be maximized Network slicing should make possible to support several different virtual 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 common resources such as 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. 2. 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. 2, 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%. 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 Time to Transmit Interval (TTI) level will be better than mechanism that operate on 100 ms level. 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. In summary, slicing should be supported by static (i.e., dedicated) and dynamic resource sharing in the RAN and transport network. Dynamically shared resources raise for example the requirements on common or coordinated scheduling mechanisms between slices, access channels and/or other common channels in general. On the other hand, dedicated resources per slices should be carefully considered since it could lead to an inefficient usage of radio resources.

3 B. RAN should be slice-aware Current 3GPP networks have support for extensive quality of service (QoS) mechanisms such as bearers, QoS class indicators, allocation and resolution priority values) making it possible to prioritize different services and signalling in a different way. The question arise if these mechanisms can also be used to support E2E 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 users. For this reason it is required that 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. [7]). 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 in different slices. Therefore, in addition to make the flows and the notion of slicing visible to the 5G RAN, it should support mechanisms to prioritize different traffic over the radio and transport interfaces. 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, mechanisms are required to protect common channels or resources used for UEs accessing system 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 E2E 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. In order to achieve it, it should be needed to efficiently manage assets (such as licensed spectrum) and efficiently use 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. F. RAN should support the management of a slice 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. The main purpose should be to efficiently operate their business which could be realized via available application programming interfaces (API). The management framework for network slicing therefore should provide slice specific performance management (PM) incl. counters, key performance indicators (KPI), as well as configuration management (CM) and fault management (FM). 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 do. 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. 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 defines 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 slice for proper business operation.

4 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 slices associated to different 5G use cases or services, e.g., massive Machine- Type Communication (mmtc), Ultra-Reliable MTC (umtc) or Extreme Mobile Broadband (xmbb). This has been concluded by the fact that not all the 5G services may benefit in the same way by the same set of NFs defined for a given protocol. It is likely that slices associated to mmtc services (e.g., supporting very low cost sensors) might require different set of NFs, protocols and/or protocol configuration(s) compared to slices associated to xmmb services (e.g., requiring higher spectral efficiency) or a slice associated to umtc services (e.g., requiring very high reliability with bounded latency). 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). LTE Optimization for Smart grids integrity of the data to be transmitted under specific delay constraints is essential. In such slice 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. Fig. 3 provides an example where some of the LTE NFs are omitted from the smart grid slice and the benefit that could arise from such omission using as reference the values provided by 3GPP [9]. Obviously this example should be considered valid under specific assumptions (e.g., message size, ciphering taking place in the application layer, retransmissions being controlled and executed on the transport layer etc.). 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 these is no major cost in setting up these groups. In [10] the authors propose a group based access of the wireless medium where the cluster heads communication is coordinated (Fig. 4), whereas in [11] focus is on the omitting of redundant message transmissions. Step Description Required time for the operation Required time for the operation Explanation 0 UE wakeup time Implementation dependent 1 Average delay due to RACH scheduling period 5ms 5ms 2 RACH Preamble 1ms 1ms 3 Preamble detection and transmission of RA response (Time between the end RACH transmission and UE s reception of scheduling grant and timing adjustment) 5ms 5ms 4 UE Processing Delay (decoding of scheduling grant, timing alignment and C-RNTI assignment + L1 encoding of RRC Connection Request) 2.5ms 2.5ms 5 TTI for transmission of RRC Connection Request 1ms 1ms 6 HARQ Retransmission (@ 30%) 0.3 *5ms 0ms No HARQ 7 Processing delay in enb (Uu > S1-C) 4ms 1ms No ciphering, RohC 8 S1-CTransfer delay Ts1c (2ms 15ms) Ts1c (2ms 15ms) 9 MME Processing Delay (including UE context retrieval of 10ms) 15ms 15ms 10 S1-C Transfer delay Ts1c (2ms Ts1c (2ms 15ms) 15ms) 11 Processing delay in enb (S1-C > Uu) 4ms 1ms No ciphering, RoHC 12 TTI for transmission of RRC Connection Setup (+Average alignment) 1.5ms 1.5ms 13 HARQ Retransmission (@ 30%) 0.3 *5ms 0ms No HARQ 14 Processing delay in UE 3ms 0.6ms No ciphering, RoHC 15 TTI for transmission of L3 RRC Connection Complete 1ms 1ms 16 HARQ Retransmission (@ 30%) 0.3 *5ms 0ms No HARQ Total LTE IDLE ACTIVE delay (C-plane 47.5ms + 2 * establishment) Ts1c 34.6ms + 2 * Ts1c Fig. 3. Example of performance benefits by the omission of NFs. 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 E2E delay of less than 8 ms, whereas for the xmbb use cases such as the Dense Urban Information Society the acceptable E2E delay is of up to 50 ms for the human oriented services [11]. In smart grid networks the Fig. 4. Example of how service-tailored random access optimization can be beneficial in mmtc using cluster based access [10]. 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. 5 a Slice-ID is reported from the CN to the RAN.

5 In addition to that, the omission or selection of NFs described previously could lead to enhancements to the QoS framework where different flows per slice / bearer types could be mapped to subset of NFs. Fig. 5. One way to make RAN slice-aware is via a Slice-ID. 4) CN / RAN functional split One of the assumptions in 3GPP concerning the overall 5G system is the CN /RAN functional split [6]. 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 [6] is to keep the same functional split in the Evolved Packet System (EPS). This seems the 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 RANbased 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 [12]. Network slicing may impact the design of protocols for that interface that may need to support potentially different functional splits per slice. 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 (see Fig. 6). 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. NF 1 NF2 NF3 NF3 NF4 NF5 NF5 The level of the separation of two slices could vary depending on the considered case Fig. 6. 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. These mechanisms are further enabled and facilitated if the resources are shared among different slices, possibly distributed geographically and having distinct traffic patterns over time. In fact, given a cell set in a certain area, the traffic of different slices / 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 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 traffic is more consistent, while surrounding cells are less loaded or characterized by low blocking percentages. Moreover, in case of deployment of two or more air interfaces in the same area, the offered traffic of different services on each air interface may also be differently distributed in time and space. 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

6 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 (see Fig 7): The dynamic self-adaptation of the network configuration towards an optimal mix of supported air interfaces (AI) and frequency bands can be achieved by the exploitation of the reconfigurable hardware 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 AIs 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). Fig. 7. Resource re-configuration for shared infrastructure. According to the evolution of the technologies and the deployment strategies, from a concrete implementation perspective, baseband pooling based on centralized-ran solutions (which could be based on cloud platforms) can be exploited to accomplish the proposed objectives, allowing high degree of flexibility in managing and reconfiguring radio resources and related parameters, jointly with open evolved SON features & open API/interfaces availability in order to increase operational efficiency and effectiveness of RAN management and optimization. IV. CONCLUSION The paper presented a set of requirements that should be followed during the 5G RAN design in order to support the concept of E2E 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 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) [1]. 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] METIS-II project ( Mobile and wireless communications Enablers for Twenty-twenty (2020) Information Society II ), see [2] NGMN Alliance, 5G White Paper, February [3] Ericsson, 5G Systems White Paper, January 2015, see [4] Ericsson, The Real-Time Cloud White Paper, February 2014, see [5] 3GPP TR , Study on New Services and Markets Technology Enablers, September [6] 3GPP S , Study on Architecture for Next Generation System, October [7] Deutsche Telekom, T-Mobile USA, Deutsche Telekom s view on 5G, 3GPP RAN 5G Workshop, Sep 17 th -18 th, 2015, Doc. no. RWS [8] ICT METIS-II, Deliverable 1.1 Version 1 Refined scenarios and requirements, consolidated test cases, and qualitative technoeconomic feasibility assessment, February 2016 (to be published). [9] 3GPP TS , Feasibility study for evolved Universal Terrestrial Radio Access (UTRA) and Universal Terrestrial Radio Access Network (UTRAN), chapter C-plane latency, [10] Konstantinos Chatzikokolakis, Alexandros Kaloxylos, Panagiotis Spapis, et al., On the Way to Massive Access in 5G: Challenges and Solutions for Massive Machine Communications, CrownCom [11] Yunyan Chang, Chan Zhou, Oemer Bulakci, Coordinated Random Access Management for Network Overload Avoidance in Cellular Machine-to-Machine Communications, European Wireless [12] 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.