Toward Operator-to-Waveform 5G Radio Access Network Slicing

TL;DR

This paper introduces a comprehensive framework for 5G RAN slicing that integrates multiple levels of network operations, from MNO decisions to waveform scheduling, significantly enhancing resource utilization.

Contribution

It presents a novel holistic framework for operator-to-waveform 5G RAN slicing, addressing inter-level operations often overlooked in prior work.

Findings

Up to 150% increase in resource block utilization.

Improved coordination and synchronization among base stations.

Enhanced support for 5G transmission technologies.

Abstract

Radio access network (RAN) slicing realizes a vision where physical network resources that belong to a specific infrastructure provider can be shared among multiple mobile network operators (MNOs). Existing work in this area has addressed RAN slicing at different levels of network abstractions, but has often neglected the multitude of tightly intertwined inter-level operations involved in real-world slicing systems. For this reason, this article discusses a novel framework for operator-to-waveform 5G RAN slicing. In the proposed framework, slicing operations are treated holistically, including MNO's selection of base stations (BSs) and maximum number of users, down to the waveform-level scheduling of resource blocks. Experimental results show that the proposed framework provides up to 150% improvement in terms of number of resource blocks that can be used to enable 5G transmission technologies that require coordination and synchronization among BSs.

Full text

I Introduction

Radio Access Network (RAN) slicing is expected to be a pivotal component of next-generation (5G) networks [1] and the Internet of Things [2, 3]. RAN slicing leverages virtualization to enable real-time sharing of the physical infrastructure – owned by an infrastructure provider (IP) – among multiple mobile network operators (MNOs). The IP assigns MNOs one or more slices of the RAN, each representing a virtual network built on top of the underlying physical RAN. For each slice, the IP specifies the amount of network resources (e.g., base stations (BS), spectrum, transmission power, among others) that can be used by MNOs to provide network services to the Mobile Users (MUs).

A key aspect of RAN slicing is that MNOs are assigned slices that are strictly independent from one another. In other words, the physical-layer allocation of radio resources (e.g., resource blocks in LTE) is completely up to the MNO, who can allocate them at will based on the proffered demand, pricing schedules, and Quality-of-Experience (QoE) levels. This provides MNOs with a great deal of flexibility, since they can leverage the IP’s RAN infrastructure without the need to share business-specific information or low-level scheduling policies with the IP.

Thanks to these core features, RAN slicing has recently attracted considerable interest from academia and industry alike [4, 5, 6, 7]. This is not at all surprising – indeed, RAN slicing provides a cost-effective, flexible and efficient solution to core challenges faced by IPs, including (i) the scarcity of networking resources (e.g., spectrum, antennas and BSs); (ii) the need for cost-effective resource allocation strategies; and (iii) the ever-increasing demand for service differentiation through slices tailored to provide services with diverse QoE requirements, e.g., video content delivery, web browsing, real-time surveillance monitoring, among others. Indeed, MNOs can adapt their RAN slice requests to subscribers’ requirements and traffic patterns in real-time (e.g., by increasing the resource demand when MUs request high data-rate services, or reducing it in small crowded areas), thus avoiding extra costs due to overbuying of network resources.

By allowing network sharing, IPs can finally overcome the dreaded resource under-utilization issue – which necessarily comes by using static and exclusive allocation policies and that has plagued previous network generations [8]. This latter aspect makes RAN slicing a beneficial technology for MNOs – who are now obliged to compete with each other to provide the best possible service – and a profitable business model for IPs [7]. On the other hand, IPs expand their business to the continuously growing market of flexible, high performance and on-demand network deployment for differentiated service typical of 5G networks.

Despite being one of the most promising 5G technologies, RAN slicing and its application to next-generation networks do not come without key challenges [5]. To be considered an integral part of future 5G networks, RAN slicing will have to be simultaneously cost-effective, easy to use, as well as providing high-level network performances. Poor performance, high prices, and a cumbersome slicing interface may indeed discourage potential MNOs from joining the RAN slicing market. Similarly, high maintenance and management costs may make RAN slicing an unprofitable business for IPs. Furthermore, to obtain the tens of Gbps [9]-level data rates envisioned for 5G, deployed RAN slices will have to support advanced transmission technologies such as Coordinated Multi-Point (CoMP), multi-user and massive MIMO [6]. These technologies, however, have strict timing requirements (in the order of few milliseconds), require in-depth understanding of low-level details of the physical network and demand for coordination among BSs, which results in increased networking and operational costs.

From the above discussion, it is clear that the ability of IPs to efficiently trade-off between business and networking aspects is a cornerstone to the success of RAN slicing. On the business side, this crucial trade-off can only be reached when IPs will implement holistic, operator-to-waveform 5G slicing solutions, where MNOs are enabled to express high-level networking need, yet obtain and retain full control of the right amount of physical and spectrum resources needed to achieve it. Simply put, we envision a framework where an MNO can ask the IP something in the tune of “There is an event between 7:30 and 10:30 at TD Garden in Boston, where approximately 1000 spectators will be present. I expect each user to generate traffic of 10 MB/s.” The framework will then automatically generate the physical resources to achieve this goal, and leave to the MNO the task to handle the waveform-level scheduling operations according to his QoE business plan, e.g., “premium” users get maximum 20MB/s data rate, whereas “basic” users get instead only 5MB/s.

Although existing work has already tackled slicing-related problems, to the best of our knowledge a unified operator-to-waveform 5G RAN slicing framework is still missing to this day. For this reason, in this work we discuss the road ahead to achieve this ambitious yet crucial goal. Specifically, we identify the architecture design features and we discuss them in detail. Our focus is also toward the identification of crucial aspects that are of extreme importance to enable advanced communication technologies envisioned and strongly utilized in 5G networks.

The remainder of this article is organized as follows: Section II gives an overview of the RAN slicing problem, with particular emphasis on its application to 5G networks. Section III discusses the architecture design of a unified RAN slicing ecosystem spanning across MNOs and IPs domains. The effectiveness of the proposed architecture is assessed in Section IV, and concluding remarks are given in Section V.

II RAN Slicing:

Requirements and Challenges

Fig. 1 provides an overview of the main procedures involved in RAN slicing. In a nutshell, we can divide the core operations into three broad yet logically distinct phases. First, each MNO declares the desired slice configuration (slice request generation phase), e.g., how many resources are required, which BSs should be included in the slice, the desired QoE level, among others. Then, the IP decides which MNO requests can be accommodated and how many networking resources should be allocated to each slice (network slice generation phase). Virtual RAN slices are generated by allocating physical networking resources (e.g., resource blocks) to each MNO. Finally, each MNO takes control over the slice to schedule MUs’ transmissions (MUs scheduling and transmission phase).

The need for a unifying slicing system

At first blush, RAN slicing might look a minor variation of already well-established cloud-related slicing technologies [10, 11]. However, RAN slicing is an intrinsically different problem, since (i) spectrum is a scarce resource for which over-provisioning is not possible; (ii) the network capacity is dynamic and heavily depends on rapidly fluctuating RAN-specific factors such as location of both MUs and BSs; (iii) electromagnetic interference rapidly varies over time and threatens orthogonality across different slices belonging to different MNOs; and (iv) the agreements with MNOs usually impose stringent requirements on the subscriber QoE, which however strongly depend on channel conditions and MU mobility patterns.

In other words, we need radically novel approaches where heterogeneous yet interdependent tasks such as resource virtualization (high-level), interference management and data transmission (low-level) are jointly considered to develop a unified slicing framework.

Different time-scales

A crucial aspect is that the three phases in Fig. 1 work at different temporal scales. Indeed, as shown in Fig. 2, while the request and generation of virtual RAN slices take place within a slicing window whose overall duration fluctuates from few tens of milliseconds to several months [12], MU scheduling and data transmission follow more minute dynamics. For example, scheduling and data transmission in 4/5G networks is performed on time slots lasting one millisecond only – the duration of a Transmission Time Interval (TTI). This is because scheduling requires network state information which is available only at network runtime (e.g., MU position, channel state information (CSI), size of scheduling queues, and so forth).

Enabling emerging multi-BSs wireless technologies

The promise of high-speed 5G communications heavily relies on key multi-BS technologies including CoMP, Massive MIMO, and beamforming [6], which ground their effectiveness on the tight cooperation and coordination among the different serving BSs. Yet, surprisingly, traditional slicing algorithms neglect to consider this core aspect, leading to network performance degradation. Only recently [13] it became evident that designing fine-grained RAN slicing algorithms that partition network resources to create a flourishing ground for cooperation- and coordination-based communications will become more and more crucial in the years to come.

Complexity vs. Optimality vs. Privacy

Another main challenge in designing an operator-to-waveform RAN slicing framework is the need to find an efficient balance among complexity, optimality, and privacy. This balance can be represented with the triple constraint in the left-hand side Fig. 3.

Figure 3 shows that centralized approaches generally produce optimal slicing policies to the detriment of privacy. Indeed, these strategies assume that the IP is aware of MNOs’ relevant information, e.g., monetary budget, subscribers’ number and position, business strategies, among others. MNOs, however, are extremely reluctant to disclose such sensitive information in real-world scenarios. Also, it has been shown that centralized formulations of the RAN slicing problem are provably NP-hard [13]. For this reason, distributed approaches are more desirable [14].

Addressing these triple constraint requires deep understanding of the dynamics governing each phase of the RAN slicing problem. As shown in Fig. 3, the slicing request generation phase has mild timing constraints and mostly involves MNOs only. The network slicing generation phase, instead, requires direct control of the IP to efficiently apportion the available network resource while reducing intra-MNO interference and enabling coordination-based communications. Lastly, the MU scheduling and transmission phase is individually controlled by each MNO, does not involve the IP at all yet has very strict timing constraints.

The above discussion suggests that the RAN slicing problem has diverse and generally opposing requirements. Recent research work has suggested to let MNOs handle the slicing request generation and MU scheduling and transmission phases, while leaving the network slicing generation phase to the IP [14]. Conversely, the network slicing generation phase is left to the IP which possess the global network view required to implement fine-grained RB allocation [13]. This approach offers a balanced trade-off between centralization, complexity, optimality, and privacy, yet also captures requirements and distinctive interactions among IPs and MNOs.

III System Architecture

The proposed operator-to-waveform RAN slicing framework is illustrated in Fig. 4. It consists of a three-tier architecture. The IP space enables IPs to (i) process MNOs’ requests, and (ii) generate RAN slices according to such requests. The MNO space concerns functionalities required by MNOs to (i) visualize the available network resources, (ii) generate slice requests, and (iii) control the obtained RAN slices and network resources. Finally, the I/O Middleware enables and regulates interactions among MNOs and between every MNO and the IP.

III-A The I/O Middleware Tier

Database Visualization Interface (DVI): the DVI provides MNOs access to the list of available BSs, their location, leasing price and coverage details, as well as useful metrics such as provided QoS (e.g., average QoS Class Identifier (QCI) and throughput) and the current congestion and utilization levels of each BS, among others.

Submission Interface (SI): the slicing requests generated by the Slice Request Generator block (Section III-C) are submitted to the IP through the SI. The design of the SI can rely upon web-based services [14] or client-based software with dedicated GUIs to facilitate the submission process [13].

Slicing Request Collector (SRC): this block collects MNOs’ requests submitted through the SI. As discussed earlier, MNOs are expected to submit RAN slice requests that substantially differ one from another. For example, some MNOs might be willing to include a specific BS to their slice [14, 13]. Instead, other MNOs could be interested in covering a specific point-of-interest (PoI) (e.g., landmarks, schools, theaters, and other locations that might be of interest for MNOs) disregarding which BS is actually used to serve subscribers [5]. Requests are organized into multiple classes, where each class contains homogeneous requests in terms of requested RAN configuration and QoS. Each class is then assigned to a dedicated buffer where all requests for that specific class are stored.

Messaging Broker (MB): this block is used by the IP to send slice admission/rejection notifications to each requesting MNO and, if accepted, to specify which BSs have been included in the current slice, the amount of networking resources that have been assigned to the MNO, and the price to be paid to rent the physical infrastructure. When a slice request is accepted, this information is stored inside the Resource Pool (RP) (Section III-C) residing within the MNO space. Together with the DVI and the RP, this block is used by MNOs as feedback channel to gather information on the current slicing configuration. Section III-C will show that such feedback is crucial to realize the decentralized vision where MNOs autonomously compute their slicing requests.

III-B The IP Tier

RAN Database: it contains detailed information on the network topology (e.g., position of each BS and its interfering BSs), leasing price and the amount of available resources at each BS (e.g., number of antennas, operational frequencies and RBs availability). Furthermore, the database has information on coverage and performance properties of each BS (e.g., whether or not a BS covers a given PoI and what are the congestion and QCI levels at specific points of the network).

The RAN database contains sensitive information that the IP uses for maintenance and monitoring purposes (e.g., how many resources are allocated to each MNO, MNO preferences toward a specific subset of BS and historical data on the RAN slice requests received in the past). Since the IP might be reluctant to share such abundant information with MNOs, they can visualize information contained in the RAN database through the DVI only. This way, the DVI obfuscates any IP-related sensitive information.

Slicing Computation Module (SCM): this block is responsible for computing optimal RAN slicing strategies based on MNOs’ slice requests received by the Slicing Request Collector (SRC) module. This block also takes care of (i) deciding which requests can be admitted; (ii) computing a slicing policy to allocate the available resources to the admitted MNOs; and (iii) enforce the computed slicing policy on the underlying physical RAN. The IP specifies a desired objective function (e.g., throughput maximization, congestion [14] and interference [13] minimization) subject to one or more constraints (e.g., guarantee Service Level Agreements (SLAs) or minimum QoS level). The SCM computes a slicing strategy that meets IP’s directives via the following three procedures:

$\bullet$ Admission Control (AC): this procedure determines which requests can be admitted and which are to be rejected. If a MNO submits an unfeasible request (e.g., it demands an excessive minimum data-rate guarantee for subscribers in a very congested area, or a large amount of resources on a BS already assigned to other MNOs), the AC procedure refuses the request and notifies the corresponding MNO through the MB;

$\bullet$ RAN Slice Allocation (RSA): admitted requests are assigned with a portion of the available networking resources commensurate with the amount of resources they requested. An example is illustrated in Fig. 1 where MNO 1 obtains $20\%$, $100\%$ and $50\%$ of the available resources on BS $1$, $2$ and $3$, respectively;

$\bullet$ Slicing Enforcement (SE): this procedure completes the RAN slicing process. An example is depicted in Fig. 1 where we show how the slicing policy $(50\%,50\%)$ generated by the RSA procedure for BS $3$ is then enforced over the RB grid by assigning specific RBs to the two requesting MNOs. This procedure is also aware of the network topology, with particular focus on adjacency (or interference) matrices [13]. These matrices provide extremely useful information with respect to adjacency among close BSs, thus enabling algorithms for technologies such as MIMO, beamforming and CoMP transmissions. Hence, these matrices are used to allocate the same RBs (in the time/frequency domain) to the same MNO when BSs are close enough to interfere among themselves [13].

We remark that the above three procedures are tightly intertwined – and their impact on network performance and IP’s profit is extremely significant. As such, these procedures must be tailored to admit as many slice requests as possible, improve network performance (e.g., maximize throughput and spectral efficiency, minimize interference) and enable advanced transmission technologies.

III-C The MNO Tier

Slice Request Generator (SRG): after having visualized information related to the underlying RAN via the DVI (Section III-B), MNOs formulate their request through the SRG – by specifying, for example, which BSs should be included in the slice, which PoIs should be covered, the required number of resources and minimum QoS levels, among others. The generated requests are then submitted through the Submission Interface (Section III-B). As remarked earlier, it is important that this process is autonomously executed by each MNO, so that they can adapt their RAN slice to network changes and lower the computational burden on the IP. Moreover, by granting MNOs access to cumulative metrics such as overall network congestion, interference measurements and total amount of resources allocated to the RAN slice, it is possible to achieve distribute RAN slicing [14]. This eliminates the need for any coordination mechanism among MNOs and preserves their privacy. In view of the above, the SRG gathers such cumulative information from the DVI and RAN Resource Pool and formulates a new RAN slice request accordingly. Lastly, the generated request is submitted to the IP through the Submission Interface (SI).

Control Abstraction (CA): the CA allows the MNO to define high-level control directives to optimize specific objective functions (e.g., transmission rate, latency, spectral efficiency) subject to one or more constraints (e.g., minimum data-rate, maximum end-to-end delay and transmission power). This block operates as an abstraction layer hiding low-level network details – such as resources allocated to the RAN slice and MUs’ position, number and generated traffic, among others – to the MNO.

Control Framework (CF): this block transforms MNO’s control directives defined in the CA (e.g., maximize spectral efficiency while guaranteeing a minimum data-rate to each MU) into low-level resource allocation policies to serve MUs. The CF consists of the three following elements:

$\bullet$ MU Database: this database – akin to the Home Subscriber Server (HSS) already used in current 4G cellular networks – contains information on MNO’s subscribers such as position, QoS requirements, identities and addressing. MNOs use it to (i) determine which BSs should be included in their slice; and (ii) how many resources are needed to serve MUs and satisfy their QoS requirements;

$\bullet$ RAN Resource Pool: as soon as the MNO is granted with one or more RAN slices, this block collects information on networking resources assigned to each slice (e.g., operational frequencies, RBs, antennas, and transmission power, among others). This way, MNOs are kept aware of which resources can be utilized to provide network services to mobile subscribers;

$\bullet$ Automated Transmission Controller (ATC): this block provides the MNO with an abstraction layer that hides all low-level network details (e.g., MU position and CQI, employed modulation, resources allocated to the RAN slice and power budget at each BS). This is achieved by converting high-level directives into optimization algorithms that optimally allocate RAN slice resources and meet MNO’s requirements and directives [15]. It follows that any MNO may efficiently and automatically control RAN slices without any in-depth knowledge of the underlying physical network as well as resource allocation and optimization algorithms.

IV Multi-BS Coordination: A Case Study

We consider a cluster of $8$ BSs deployed in Boston (USA) extracted from the OpenCellID database (https://opencellid.org), which is shown in Fig. 5. We consider an LTE deployment where RAN slicing is performed at the RB level [13]. Each BS has $50$ RBs, and MNOs distributively submit RAN slice requests through the SI (Section III-A), aiming at minimizing the network congestion and cost per slice [14]. Requests are collected by the SRC and converted into effective slicing strategies by the SCM (Section III-B) which slices network resources so that interference is minimized and multi-BS coordination is maximized [13].

In Fig. 5 we show how RAN slicing policies affect 5G-related transmission technologies such as MIMO and CoMP. Specifically, Fig. 5 shows the percentage of RBs that can be leveraged for multi-BS wireless transmissions for different slicing enforcement strategies, i.e., shared RBs. We compare the approach proposed in [13] – which maximizes the chances that a RB can be used to serve MUs via two (or more) BSs in close proximity – with greedy (i.e., RBs are first allocated to those MNOs that have been assigned with the the largest amount of RBs) and First Come First Serve (FCFS) (i.e., RBs are sequentially allocated to MNOs according to the temporal order of their RAN slice request submission). We notice that the number of shared RBs decreases with the number of MNOs for both full coordination (i.e., all BSs can serve the same MU in the same RB) and partial coordination (i.e., at least two BSs can serve the same MU in the same RB). The approach in [13] provides a performance gain of up to $150\%$ in terms of number of RBs that can be used to enable 5G technologies that require coordination.

V Conclusions

We discussed a unified framework for operator-to-waveform 5G RAN slicing, which allows control from the MNO’s selection of base stations and maximum number of users to the waveform-level scheduling of resource blocks. Experimental results show that our framework allows for up to 150% improvement in terms of number of RBs that can be used to enable coordination-based 5G technologies, such as MIMO and CoMP.