Design considerations for software-defined wireless networking in heterogeneous cloud radio access networks

Abstract

The fifth generation (5G) cellular infrastructure is envisaged as a dense and heterogeneous deployment of small cells overlapping with existing macrocells in the Radio Access Network (RAN). Densification and heterogeneity, however, pose new challenges such as dealing with interference, accommodating massive signaling traffic, and managing increased energy consumption. Heterogeneous Cloud Radio Access Networks (H-CRAN) emerges as a candidate architecture for a sustainable deployment of 5G. In addition, the application of SDN concepts to wireless environments motivated recent research in the so-called Software-Defined Wireless Networking (SDWN). In this article, we discuss how SDWN can support the development of a flexible, programmable, and sustainable infrastructure for 5G. We also present a case study based on SDWN to perform frequency assignment, interference, and handover control in an H-CRAN environment. Results allow the establishment of a tradeoff between wireless communication capacity gains and signaling overhead added by the employment of SDWN concepts to H-CRAN.

1 Introduction

Data traffic in cellular networks has increased significantly over the past few years. Arguably, the current architecture of cellular networks, largely based on the deployment of macrocells, will not be able to accommodate the ever-growing traffic and the number of connected devices [1]. To cope with such increase in traffic and number of connections, industry, and academia have been designing and gradually deploying the fifth generation (5G) cellular infrastructure. This infrastructure envisages denser and heterogeneous deployments in the Radio Access Network (RAN) through a massive number of smallcells (e.g., femtocells and picocells) to cover specific geographical areas, overlapping with existing macrocells. The high density of 5G RAN increases dramatically its cost, turning it unsustainable for operators to cope with its deployment considering current business models. This scenario motivated the introduction of a new candidate architecture for 5G, called Heterogeneous Cloud Radio Access Networks (H-CRAN) [2]. With H-CRAN, traditional radio equipment of macro and smallcells can be gradually replaced by less expensive Remote Radio Head (RRH) that offloads wireless signal workload over optical links to be processed in centralized cloud data-centers, known as Base-Band Unit (BBU) pool. H-CRAN presents benefits such as optimized energy consumption and simplified coordination, synchronization, and signal precoding [3].

The evolution towards H-CRAN also poses new challenges such as dealing with high intercell interference, accommodating massive signaling traffic, and meeting critical latency constraints in long-distance signal transmission and processing [4]. Recently, Software-Defined Networking (SDN) started being considered as a feasible paradigm to tackle important issues of the deployment and management of cellular networks [5]. Although originally conceived for wired networks, SDN introduces advantages (e.g., network programmability and flexible operation, configuration, and management [6]) that can benefit H-CRANs as well. For example, concepts of SDN can be employed to enhance mobility management, deal with inter-tier interference, and enable network-wide configuration through technology agnostic abstractions [7].

Some of the enabling H-CRAN technologies present conceptual similarities with SDN, such as separation of forwarding and control planes, i.e., RRH and BBU, and the presence of logically centralized control elements e.g., Mobility Management Entity (MME). However, the effective deployment of a wireless-focused implementation of SDN such as Software-Defined Wireless Networking (SDWN) in H-CRAN environments must still overcome a series of challenges, e.g., defining the responsibilities of programmable controllers and dealing with potential additional control signaling overhead. As opposed to wired networks, RANs require handling a multitude of wired and wireless functions, e.g., fronhaul flow control, frequency assignment, handover, and interference mitigation. High-level decisions related to these functions must be made by SDWN controllers, while their implementation in lower levels is performed through the appropriate programming abstractions. Nevertheless, the adequate programming abstractions to handle wireless resources are still missing and are not as consolidated as current solution for wired environments, such as the established OpenFlow protocol. Therefore, a design of SDWN for H-CRAN to control wireless functions using proper programming abstractions without overloading the network with signaling messages is a matter of investigation.

In this article, we discuss how SDWN can support the development of flexible, programmable, and sustainable H-CRAN infrastructures to help achieve the envisioned goal of the forthcoming next-generation cellular networks. The contributions presented in this article are: (i) the definition of the architecture and design decisions to create an SDWN-enabled H-CRAN, (ii) creation of interfaces to enable SDWN controllers to control H-CRAN wireless communications, and (iii) analyzing the tradeoff between capacity gains in the wireless communication and signaling message cost posed to H-CRAN when adopting SDWN.

We start discussing 5G and revisiting the original concepts of SDN to then discuss to what extent they can or cannot fulfill the needs of H-CRAN. Moreover, we indicate the design decisions that need to be made on the path towards the transition to a full SDWN-enabled cellular network and discuss how SDWN can be accommodated in the context of H-CRAN. Afterward, we present our prototype followed by a case study based on SDWN to control frequency assignment, interference detection, and handover execution in H-CRAN. Finally, we finish this article presenting our final remarks and future work.

2 The evolution of 5G towards H-CRAN and SDWN

In this section, we describe our view of 5G, presenting H-CRAN as a candidate architecture for its future deployments and challenges. Afterward, we show how SDWN can be used to address some of these challenges.

2.1 5G – a brief overview

Data traffic in mobile networks is increasing dramatically mainly because of the wide spread of smart devices as Users Equipment (UE) (e.g., tablets and smartphones), the popularization of streaming and real-time services (e.g., video and online games), as well as ubiquitous Internet access [1]. To cope with this increased traffic, 5G poses a target of 25 G b p s/k m ² area throughput [8], particularly considering densely populated urban areas. To achieve such an aggressive target, three main strategies are jointly exploited: (i) network densification, (ii) spectrum extension, and (iii) spectrum efficiency. Network densification involves an increase in radio nodes per square kilometer ($\frac {node}{km^{2}}$) to enhance communication quality by shortening last mile links. Spectrum extension, in turn, enables a radio node to exploit more bandwidth to communicate ($\frac {Hz}{node}$), e.g., frequency aggregation in spectrum sharing. Finally, spectrum efficiency improves throughput in terms of bits transmitted per second for a given bandwidth ($\frac {Gbps}{Hz}$), relying, for example, in spectrum reuse, massive Multiple-Input Multiple-Output (MIMO), and Coordinated Multipoint Transmission and Reception (CoMP). These three strategies combined can be represented as terms (Eq. 1) that need to be maximized to achieve the aimed average area throughput (thr) of 5G. In Eq. 1, den represents network density, ext spectrum extension, and eff spectrum efficiency.

$$ {}thr\left[\frac{Gbps}{km^{2}}\right] = den\left[\frac{node}{km^{2}}\right] \times ext\left[\frac{Hz}{node}\right] \times \textit{eff}\left[\frac{Gbps}{Hz}\right] $$

(1)

The maximization of these strategies requires operators to invest and expand their infrastructure. However, current cellular architecture has shown to be unsustainable to cope with this maximization, which motivated the introduction of H-CRAN [2]. H-CRAN inherits concepts from both Heterogeneous Networks (HetNet) and Cloud Radio Access Networks (C-RAN), such as depicted in Fig. 1. From HetNet, H-CRAN has in its architecture the presence of different sorts of smallcells spread along a macrocell coverage area, promoting heterogeneity to improve spectrum efficiency and network capacity. Picocells and femtocells are examples of smallcells created by low power base stations such as Relay Nodes (RN) and Access Points (AP). C-RAN, in turn, relies on concepts of cloud computing, where a BBU pool centralizes the workload of signal, modulation, and protocol stack processing of a set of RRHs.

Fig. 1

Cellular network architectures

The C-RAN architecture reduces the cost and complexity of RRHs enabling cost-effective deployment of a massive number of cells. Finally, in H-CRAN, concepts from both HetNet and C-RAN are combined to enable the deployment of dense and heterogeneous networks, leveraging cloud computing to centralize workload processing.

Although H-CRAN brings several benefits, its employment is not free from challenges. Interference and energy consumption control, as well as creating a scalable backhaul and complex radio resource orchestration mechanisms are examples of challenges that need to be overcome in the realization of H-CRAN. Many of these challenges can be addressed in the control plane of cellular networks [7, 9]. For example, to avoid the interference generated by massive deployment of small cells or to enable the allocation and orchestration of radio resources, an increasing number of signaling messages must be exchanged through the control plane [10]. However, the current control plane of cellular networks neither is designed to support this increased control traffic nor provides mechanisms to quickly accommodate new signaling messages [8]. We argue that the control plane of cellular networks needs to be revisited to support the flexibility and programmability to overcome the aforementioned challenges and also to meet the 5G area throughput target in H-CRAN.

2.2 Related work

Because of the evidenced benefits of SDN in wired networks, such as network programmability and flexible operation, it is natural to consider this paradigm as a framework to deliver the same benefits to wireless networks [5]. Before discussing the realization of SDN in the wireless world, we do a brief review on current SDN concepts. SDN is conceptually organized in four planes. (i) Application plane, (ii) Control plane, (iii) Forwarding plane, and (iv) Management plane [6]. Applications sitting on the Application plane are designed and operated by service providers that serve their own subscribers. Applications eventually issue requests for network resources, which are interpreted and translated into fine-grain configurations by network controllers at the Control plane. Besides handling requests coming from services, controllers also react upon receiving events generated by devices from the Forwarding plane (e.g., to recover from failure or performance degradation). Finally, the Management plane manages the components of an SDN architecture (e.g., applications, controllers, and devices) by monitoring and tuning the health of the whole network across planes to meet high-level policies and agreements.

SDN also assumes three main Application Program Interfaces (APIs): (i) Northbound API, (ii) Southbound API, and (iii) Management API. The Control plane provides the Northbound API for service providers to create their network applications.

Controllers, in turn, make use of the Southbound API to interact with devices in the Forwarding plane, i.e., by issuing low-level instructions and collecting information. The Management API enables the Management plane to handle devices and services in all other planes, through legacy management protocols, such as SNMP, or new ones, such as OF-Config¹.

Our vision of SDWN inherits many concepts from SDN as depicted in Fig. 2. The main additions we envision to the original SDN architecture are the new conceptual entities placed at the Forwarding plane (i.e., devices supporting wireless connectivity, such as BBUs/RRHs, relay nodes, and access points) and Control plane (i.e., specific controllers for wireless functions, called SDWN controllers). Since wired SDN switches and other network boxes were required to comply with ONF’s specifications of a Southbound API, we anticipate that the same will happen to SDWN devices. BBUs and eNBs, responsible for processing all the wireless stack (e.g., signaling, media access control, radio resource allocation), must also be adapted to comply with a new Southbound API for SDWN. RANs require handling a multitude of wireless functions, e.g., frequency assignment, handover, and interference control. High-level decisions related to these functions must be made by application running on top of SDWN controllers, while the implementation of these decisions to lower levels must be performed through the appropriate API calls and programming abstractions. For example, a handover function requires an API definition to exchange messages containing relevant information, such as Signal-to-Interference-plus-Noise Ratio (SINR), Packet Error Rate (PER), and Destination Point-of-Access (DPoA) indicator, to be properly coordinated.

Fig. 2

SDWN conceptual blocks

A common strategy in current SDN setups is to place controllers at the core of the network, far from the edge where RANs are located. That is likely to lead to harmful delay of signaling traffic originating at the network edges. In addition, although SDN controllers are expected to handle ultra high speed data flows in wired networks [11], their placement at the network’s core is unlikely to allow centralized SDN controllers to scale with the extra control traffic coming from RANs. As such, an important design consideration of SDWN is that the SDWN controller needs to be positioned closer to the edge of the network. This entity adds scalability to the Control plane by directly handling wireless specific functions. Although the SDWN controller is a logically centralized entity, its implementation could be distributed across the edge of 5G networks, which brings about the discussion on the definition of horizontal inter-controller APIs (e.g., Westbound and Eastbound) [12]. Therefore, SDWN controllers can still be distributed and also perform centralized logical functions, such as global topology mapping, neighbor wireless resource information retrieving, link discovery, and radio monitoring. It is also worth mentioning that some of the current SDWN proposals are distributed and present hierarchical organization of controllers that provides partial control centralization [10, 13]. Such distribution enable controllers to decrease management complexity keeping part of the centralization benefits [10]. There is also the possibility to pool resources, such as radio frequencies and processing power under the control of SDWN controllers in H-CRAN [9, 14].

In cellular networks, centralized solutions turn feasible to achieve optimized objectives because of the availability of the overall state of the network [14]; however, they are impracticable to be implemented on the current distributed architecture of the RAN, regarding complexity and latency constraints [15]. In contrast, H-CRAN already envisions a topologically centralized architecture based on resource pools to perform signal processing of the distributed RAN. Therefore, SDWN can exploit this concept to tackle complexity and latency constraint by using these pools and the existing optical backhaul [10]. In this case, SDWN controllers can take part as an enabling technology to perform centralized processing, becoming responsible for different wireless functions coordination [16, 17]. For example, SDWN controllers can be reprogrammed to analyze, allocate, and redistribute radio resources, in addition to controlling the handover, interference, energy, and radio resource sharing [18]. Also, SDWN controllers can serve as a framework to design novel solutions, for example, based on artificial intelligence to predict user handover mobility in a more harmonized manner, avoiding the need of specialized protocols and network middle-boxes, such as IEEE 802.21 and LTE’s Mobility Management Entity (MME). Although, H-CRAN can benefit from SDWN to reach, for example, optimized solution for each different supported wireless function, the definition of which wireless functions an SDWN controller must control and how, remains undefined.

As in SDN, an SDWN controller can be tuned and reprogrammed by applications at the Application plane through the Northbound API. The main difference from a typical SDN setup is that SDWN allows applications to reconfigure wireless functions, such as handover, inter-cell interference, and association control. The Northbound API allows operators to dynamically redefine their entire RAN configuration, readjusting the modus operandi of SDWN controllers.

SDWN was already proposed to be used in H-CRAN and C-RAN. For instance, in [16], the authors proposed an SDWN controller able to cope with radio resource management at physical layer. Whereas, in [13], three transport models were proposed to measure the efficiency of employing SDWN concepts in a C-RAN optimizing its usage. The authors of [10], proposed a hierarchical composition of controllers, responsible for different parts of the network, namely radio, optical, and BBU controller. Although SDWN enables endless possibilities, it is not a plug-and-play solution to all problems and despite the different architectures proposed, there is still the lack of a proper definition of what are the controller responsibilities to the realization of SDWN in H-CRAN. As a consequence, the Southbound API is weakly defined without proper specification and standardization. In this sense, we take a step further by defining the responsibilities that an SDWN controller must assume in H-CRAN and propose a new Southbound API definition.

In the next section, we introduce the responsibilities that an SDWN controller can assume to control wireless functions.

3 SDWN controller responsibilities

The main benefit of using SDWN in H-CRAN is the creation of a flexible programmability framework required to transform the current control plane into a more dynamic one that accommodates future wireless functions while still supporting current functions. SDWN controllers must assume responsibilities about these functions that nowadays are enclosed in closed-source or technology specific solutions. We selected seven wireless functions to delve into details regarding the SDWN controller’s responsibilities, such as presented in Table 1. Each row from this table presents: (i) a wireless function, (ii) responsibilities that shall be taken by SDWN controllers to cope with each function, and (iii) enabling technologies that can help controllers to fulfill their responsibility. A detailed discussion organized in subsections follows.

Table 1 SDWN controller responsibilities

3.1 Handover control

The high density of H-CRAN associated with user mobility may end up in throughput degradation issues due to, for example, frequent UE handover and infrastructure unbalancing. To avoid such degradation, different technologies were proposed for mobility support and handover control of UEs in current cellular networks, such as IETF’s Mobile Internet Protocol version 6 (MIPv6) and IEEE’s 802.21 standards, as well as the addition of the Mobility Management Entity (MME) a particular purpose element in 3GPP’ LTE architecture. To guarantee the correct operation of 5G, H-CRAN must also provide support to these technologies before implementing more sophisticated mechanisms. Therefore, these technologies can be combined with SDWN to design optimal or semi-optimal handover control solutions, which can leverage SDWN’s centralization of network status as input. Also, in a posterior moment, SDWN controllers can serve as a framework to design novel handover solutions, for example, based on artificial intelligence to predict user mobility in a more harmonized manner, avoiding the need of specialized protocols, such as IEEE 802.21. Nevertheless, SDWN is limited to the mobility detection system of H-CRAN combined to the RRH capabilities to locate UEs and has to be built with privacy mechanism to avoid user information leakage.

3.2 Interference control

As soon as macro and small cells start to intersect with each other in H-CRAN, the improved data rate provided by these cell deployments degrades due to intra and inter-cell interference [15]. As a consequence, different technologies have been exploited to alleviate interference at RANs, such as beamforming transmissions using multi-user MIMO antennas, Almost Blank Subframes (ABS), and Enhanced Inter-Cell Interference coordination (eICIC) mechanism. These technologies can have their performance improved by the use of centralized solutions for inter/intra-cell interference coordination to reach near zero interference. As opposed to distributed solutions, largely based on local signal strength indicators, centralized interference coordination has the whole network state and frequency allocation, facilitating interference management. In this sense, the processing centralization provided by H-CRAN combined to the SDWN controller enables the coordination of the inter/intra-cell interference, allowing operators to design algorithms for interference coordination that best fit their network needs [15, 16]. Since SDWN controllers centralize interference coordination, parameters, such as interference at receiver and frequency assigned for each cell, can be used as input for optimized interference avoidance in H-CRAN. Although the interference coordination can be improved, the number of signaling messages increases, radio cells need to support sensing mechanisms, and event-based systems (e.g., traps) are required to send messages in case of interference detection.

3.3 Radio resource allocation

Channels, resource blocks, and spectrum are typical examples of radio resources that can be allocated in five domains, i.e., time, frequency, space, power, and coding. For instance, frequency might be dynamically assigned to each small and macro cell in H-CRAN to avoid interference and improve spectrum efficiency by exploiting spectrum reuse [1]. Additionally, advanced radio virtualization techniques allow the allocation and sharing of radio resources among multiple (Virtual) mobile network operators [19], the exploitation of dynamic access techniques [20], and even different access techniques, such as Machine-to-Machine (M2M) [21], to allocate resources in a cellular network. Technologies such as SDR provide the programmability required to adapt the radio resource allocation in real time. This programmability also allows the utilization of advanced CoMP and eICIC mechanisms to increase the spectral efficiency of radio communications. SDWN can improve such mechanisms by centralizing the knowledge of the wireless network exposing the programmability of networking devices to high-level applications. However, the main constraints of using SDWN controllers for radio resource allocation are related to the increase of signaling messages, the integration of low-level radio baseband processing with the conventional network protocol stack and hardware, and complexity to design centralized resource algorithms that react to the local and fast paced changes of wireless channel conditions [16].

3.4 Sharing control

High leasing prices and spectrum scarcity lead operators to exploit spectrum sharing to improve their resource pool and budgeting [22]. To take advantage of spectrum sharing, different techniques can be used, e.g., Dynamic Spectrum Access (DSA) and Licensed Shared Access (LSA) in combination with cognitive radio and auction systems. With SDWN, operators can control the access technique used to explore shared frequencies. In this sense, SDWN controllers become responsible for providing information sharing among operators, enabling better control of shared frequencies, and assuring that operators’ policies are correctly applied. Nevertheless, depending on spectrum access technique taken, the SDWN controller role changes. For example, in LSA the SDWN controller becomes limited to coordinate spectrum sharing only if a spectrum broker is present in the coordinated area.

3.5 Network orchestration

H-CRAN infrastructure includes many heterogeneous elements, such as BSs, BBUs, RRHs, and APs, operating under a variety of protocols to forward data and to interact with one another. Achieving, for example, optimal traffic routing in this context is infeasible without some sort of lingua franca among technologies. SDWN can improve this scenario with network orchestration, by centralizing information from different sources and communicating with elements of interest all over the network. While requiring trap systems for event detection and possibly increasing signaling traffic, SDWN controllers become a bridge for integrating well-known protocols, such as OpenFlow and CAPWAP, to coordinate other elements (including other SDN Controllers) performing cross technology operations.

3.6 Energy control

Energy consumption in a cellular network can be divided into two perspectives from (i) operators and (ii) UEs. In the former, operators are concerned with infrastructure equipment energy consumption, for example, RRHs and BBUs. In the latter, UEs must preserve their energy to maximize battery life by minimizing transmission power and retransmissions. There is a tradeoff between both perspectives, where infrastructure equipment consumes more energy to reduce UEs consumptions [23]. SDWN can be used to turn the energy control programmable. SDWN controllers must control the energy tradeoff by configuring the maximum allowed co-channel interference and transmission power, allowing operators to balance the tradeoff as they see fit. Also, the SDWN controller shall be able to switch off/on wireless equipment that is not in use, for example, an RRH without UEs in its vicinity. Thus saving energy, but increasing node unavailability in case a cell is erroneously turned off while in use. Access to such a command must be protected against unauthorized use.

It is important to notice that the aforementioned wireless functions are not novel by themselves. In fact, there are purpose specific controllers already in place for some of them, e.g., the MME controls intra-LTE handover events. However, these controllers were not designed for dynamic reprogramming, hindering the deployment of network applications and the fast evolution of cellular networks. Moreover, SDWN can be used in H-CRAN to achieve outstanding benefits, which include optimal interference avoidance and frequency assignment, as well as improved energy control and spectrum sharing. Although SDWN enables endless possibilities, it is not a plug-and-play solution to all problems. To better understand the potential of using SDWN in H-CRAN, in the next section, we describe our prototype and a case study to quantify some of the benefits of SDWN when radio resource allocation and handover control functions are coordinated by SDWN controllers in an H-CRAN scenario.

4 Prototype and interface definition

We developed an SDWN prototype, where a controller exchange messages with H-CRAN networked nodes, e.g., BBUs, and eNBs. First, we determine the southbound interface required to implement our proposed SDWN controller based on RESTful concepts. Afterward, we describe our SDWN prototype.

4.1 SDWN controller interfaces

For each wireless function, our southbound interface summarized in Table 2 presents a set of RESTful resources that can be changed according to the methods: Create, Read, Update, and Delete (CRUD) [24]. These resources were designed to enable control and forwarding plane entities to interact.

Table 2 SDWN southbound interface

To perform radio resource allocation, the southbound resource channel can be instantiated by a controller using the create method determining which PoA (node) of a BBU will receive a determined frequency (c_f r e q u e n c y) with a certain bandwidth (c_b a n d w i d h t). Also, the resource can start to be used for a certain period (s t a r t_t i m e) and send a notification to check whether the current configuration is still valid after a certain period (t i m e_t o_k e e p). The same resource can be used to get the current status of the channel in use of a node, receiving a list of radio parameters (r a d i o_p a r a m e t e r s), e.g., average RSSI and the number of UE currently connected consuming the channel. Other methods, such as update and delete, can be used to change the current configuration or destroy it. Considering the same logic, we detail each of the other resources, briefly.

The dmimo resource can be used to enable, check, change, or stop the execution of MIMO between RRHs (n o d e _a and n o d e _b ). To perform handover control, the handover resource can be used to start, get status, change or stop a UE (ue) migration from an origin (poa) to a destination PoA (dpoa) considering different radio parameters (r a d i o_p a r a m e t e r s). Whereas, the handoff resource cannot be instantiated by the controller directly, but can be used by a BBU or eNB to notify the controller about a UE (ue) departure from one of its RRHs (poa) containing radio parameters (r a d i o_p a r a m e t e r s) when necessary.

The r s s i_e v e n t, in turn, is a resource instantiated by BBUs and eNBs to inform that an RRH (node) is facing bad channel (c_f r e q u e n c y and c_b a n d w i d t h) quality (r a d i o_p a r a m e t e r s) that must be investigated. The i n t e r f e r e n c e_c h e c k resource enables BBUs and eNBs to request the SDWN controller to check whether there are other RRHs from different RANs using the same channel frequencies (c_f r e q u e n c y and c_b a n d w i d t h). To perform sharing control, the dsa and lsa resources can be used to determine the current frequency sharing regime in use, in this case, Dynamic Spectrum Access (DSA) or Licensed Shared Spectrum Access (LSA), respectively. In both cases, a set of RRHs (n o d e_s e t) must be determined considering different inputs, i.e., frequencies in use (c_f r e q u e n c y and c_b a n d w i d t h), radio parameters (r a d i o_p a r a m e t e r s), start period (s t a r t_t i m e) and time to request update (t i m e_t o_k e e p).

Further network control can be accomplished by the usage of OpenFlow interfaces (o p e n f l o w(∗)) to perform data flow management and control. Whereas, the association and disconnection control of UEs can be performed through the use of connection and disconnection resources, using messages containing e.g., the UE id ue and radio parameters, such as PER and RSSI. Finally, power control can be performed by the usage of the resources: wakeup, standby, and m a x i m u m_p o w e r resources. In the first, wakeup enables to activate or deactivate an RRH. In the second, standby put the RRHs in standby mode, i.e., the RRH is on but do not perform transmissions or receptions. In the third, the m a x i m u m_p o w e r enables to control the maximum transmission power of an RRH. Considering the proposed interface, we developed our SDWN prototype.

4.2 SDWN prototype

Our SDWN prototype was developed to operate on top of H-CRAN scenarios. Our scenario consists of an H-CRAN with low, medium and high density of UEs ([100, 500, 1000] U E s/K m ² respectively). Each UE density is combined with a scarce, medium or dense number of RRHs ([5, 15, 30] R R H s/K m ², respectively). This results in nine different scenarios, varying from low-density-UEs-high-low-RRHs to high-density-UEs-high-density-RRHs [3]. Each of the nine scenarios was simulated in a custom-made simulation tool designed specifically for H-CRAN scenarios that have its source code publishedin GitHub².

We modeled the communication between UEs and RRHs through free space path loss, with a thermal noise of −90 dBm, Orthogonal Frequency-Division Multiple Access (OFDMA), and modulation code scheme based on ([25], Annex A). RRHs were configured with a maximum transmission power of 23 dBm, the antenna gain of 0 dBi, and connected to the closest BBU pool. The energy being consumed by the RRH varies according to its operation mode, 4.3 W when idle (sleeping) and 6.8 W when active [26]. A macrocell is placed in the center of the grid and configured with maximum transmission power of 46 dBm and antenna gain of 0 dBi. UEs move along the grid according to a random waypoint mobility model with a pause interval of 10s and with a speed ranging from 1 to 40 m/s [27]. Each UE is modeled with a Constant Bitrate (CBR) traffic demand of 5 Mbps. Thus, the total traffic demand increases with the number of UEs as follows: 0.5 G b p s/k m ² for 100 UEs, 2.5 G b p s/k m ² for 500 UEs, and 5 G b p s/k m ² for 1000 UEs.

In each scenario, we deployed an SDWN controller responsible for managing radio resource allocation and the operation mode of all RRHs. The SDWN controller receives control messages from the wireless substrate, similar to OpenFlow³ messages in wired networks and also considering the RESTful interface proposed. As a proof-of-concept, we initially considered only five types of messages regarding different resources: (i) connection (connection create), (ii) disconnection (disconnection create), (iii) connection + BBU change (handover CRUD), (iv) bandwidth (BW) update (channel update), and (v) RRH status(channel read). In Fig. 3, we exemplify the connection message, which accommodates meaningful information for handover execution, such as SINR, PER, and DPoA. This information is received and used to populate the Handover and Channel tables within the SDWN controller.

Fig. 3

H-CRAN with SDWN deployment

The connection and disconnection messages are received by the SDWN controller when a UE performs a handover, e.g., disconnects from one RRH and connects to another one. The connection + BBU change is a message sent when a UE connects to an RRH managed by a different BBU, e.g., handover from RRH 3 to RRH 4 in Fig. 1. This message is similar to connection, but with additional information about the RRH in which the UE is connecting. The BW update is sent when the RRH requires additional radio resources. Finally, the RRH status is a power control message exchanged between BBU and SDWN controller, which can change the RRH operation mode to idle (standby) or active. This set of messages can be generated in the following cases: (i) when a UE connects to an RRH, (ii) when a user disconnects from an RRH, or (iii) when the UE mobility turns the current modulation and coding scheme utilized by the RRH inappropriate, e.g., when the user moves far away from the connected RRH, and (iv) when a UE connects or disconnects from an RRH.

We designed an application in the SDWN controller that (i) reconfigures the channel bandwidth to fit best the UE demands according to the LTE configurations, i.e., [1.4, 3, 4, 5, 10, 15, 20] MHz, (ii) reduce the overall interference by assigning the channel with the lowest SINR, i.e., the channel least used in the RRH neighborhood, and (iii) switch the operation mode of RRHs based based on the number of UE’s in the RRH vicinity, i.e., idle if no UE’s are in the RRH vicinity and active otherwise. Algorithm 1 presents a pseudo code that contains the main operations performed by the application. The power control and channel bandwidth reconfiguration are executed only when the SDWN controller receives the BW update message (line 1). As the first step, the power control routine is triggered (line 2). In this routine, the SDWN controller estimates the potential set of UEs to migrate to an RRH r due to their positioning (line 17). Afterward, the application determines if an RRH being analyzed (r) will accept a UE that is migrating from other RRH (R R H _u ) determining: (a) if r’s current number of UEs connected is larger than the population of connected UEs from R R H _u ; and (b) if R R H _u is saturated or cannot afford the capacity required by the UE (line 19). Otherwise, the RRH rejects the UE access (line 22). This way RRHs are used until achieving saturation before activating a new RRH.

Further, the application estimates the necessary channel bandwidth considering the UEs modulation and coding scheme, SINR, and PER for each connected UE (line 2). Afterward, the RRH is configured with the channel bandwidth that satisfies all UEs and that corresponds to a valid LTE configuration (line 3) and updates the channel distribution (line 4). Starting the update, the SDWN controller estimates the channel with best SINR (line 7) and assigns it to RRH (line 8). Because changing the channel of one RRH modifies the interference conditions of all adjacent antennas, the ChannelDistributionUpdate is performed per RRH (lines 10−12). Moreover, as clusters of small cells will hardly interfere with each other due to the small coverage area of RRHs, it is not likely that the ChannelDistributionUpdate will be executed for all RRHs in the H-CRAN.

As a baseline, we used a traditional network planning scheme based on 4G networks to organize H-CRAN, in which RRHs receive the channel with the best SINR and with a fixed bandwidth during the network bootstrap. Finally, we measured the overall throughput and energy consumption enhancement as well as the control cost imposed by SDWN in H-CRAN against the non-SDWN baseline.

In the next section, we present a case study to quantify some of the benefits of SDWN when radio resource control, interference avoidance, and handover control functions are coordinated by SDWN controllers in an H-CRAN scenario.

5 SDWN proof of concept

We demonstrate the use of SDWN for future 5G deployments in a case study based on the H-CRAN architecture, such as depicted in Fig. 3. In this case study, we show the SDWN gains in terms of overall throughput, interference, and energy consumption in comparison to a H-CRAN without SDWN using 4G frequency planning, as well as the overhead added by control messages used by the SDWN controller.

5.1 Throughput and energy benefits of SDWN in H-CRAN

We show the benefits of SDWN comparing the overall throughput achieved by all UEs with the traditional H-CRAN network, which uses a fixed channel bandwidth. Moreover, we compared the SDWN power control gains with a baseline where RRHs are always active.

Figure 4 shows the average throughput of UEs for each of the nine evaluated scenarios. In all scenarios, employing SDWN to monitor UEs handover and perform frequency assignment increased the average throughput by approximately 40% when compared with the 3G/4G baseline. This gain occurs because SDWN reduces the inter-tier interference by managing the channel distribution during runtime, which in turn increases the average SINR and enables better modulation and coding schemes. However, for a fixed number of RRHs, increasing the number of UEs decreases the average throughput. This occurs because the limited available radio resources are divided among a larger number of UEs. For the same reason, the average throughput increases with the number of RRHs, i.e., the average number of UEs connected to an RRH is lower, facilitating the reuse of radio resources.

Fig. 4

Average throughput experienced by mobile subscribers

To better understand the benefits of the channel bandwidth and distribution application, we show the percentage of UEs transmission as a function of the number of RRHs interfering with their communication in Fig. 5 b. Approximately 70% of the transmissions were performed without interference with the H-CRAN standard channel distribution algorithm, whereas with the use of SDWN this number goes up to roughly 96%.

Fig. 5

Percentage of communications performed relative to the number of interferers

The power control application achieved energy gains maintaining RRHs in idle as long as others are not saturated, as can be seen in Fig. 6. For scenarios with small densities, such as 100 UEs/km ², this application achieved 20% of energy reduction for high number of RRHs, a significant mark for large networks. Whereas, for scenarios with high densities, such as 1000 UEs/km ², the SDWN gains decrease achieving 6% at best for 30 RRHs. It is important to notice the tradeoff between increasing the number of RRHs and the energy gains achieved. In this case, the results in this work can serve as guidelines for operators to identify which is the best number of RRHs to be deployed in an H-CRAN comparing energy gains and the total capacity achieved.

Fig. 6

Average energy consumption per RRH

5.2 Control message cost of SDWN in H-CRAN

The main drawback of employing an SDWN Controller is the additional overhead incurred by control messages. Figure 7 shows the number of control messages of each type for all evaluated scenarios. As expected, increasing the number of UEs or RRHs leads to a direct increase in the number of control messages exchanged. In the case of RRHs, this increase occurs because UEs have more handover opportunities. We also highlight that the total number of control messages exchanged per operation depends only on the number of UEs and RRH and not on external mobility factors, such as the speed in which the UE is moving or its distance to the RRH.

Fig. 7

Total of control messages in each scenario

Figure 8 a shows the average frequency of each message type for all scenarios without significant loss of generality. Connection related operations, i.e., connection and disconnection, account for 86% of all messages exchanged. The higher number of connections messages, as compared to disconnection, is due to users attempting to migrate between RRHs and having their handover denied by the power control application. Moreover, the number of BBU change, BW updates, and RRH status (i.e., Enter normal mode and Enter idle mode) is below 13%. This result indicates that the channel bandwidth distribution and power control operations are rarely executed, although these operations significantly increase the overall UE throughput.

Fig. 8

SDWN control messages frequency and bandwidth consumption. a Average frequency of each control message type in all scenarios. b Bandwidth consumption considering the message size and the average frequency of (a)

Figure 8 b shows the traffic overhead of each message type considering its size and frequency. We defined the average packet size for each control message following the summation of their content with the OpenFlow standard headers needed by each control action, resulting in: 512 bytes for connection, 288 bytes for disconnection, 800 bytes for connection + BBU change, 384 bytes for BW update, 288 bytes for Enter normal mode and 274 bytes for Enter idle mode. Results show that the connection message is responsible for 65% of the traffic overhead. The connection + BBU change message represents 6% of the overhead, although it accounts for only 3% of the messages exchanged. Moreover, the BW update summed to the RRH status message accounts for less than 10% of the traffic overhead. The low overhead of BW update and RRH status, allied with its low frequency, reinforces the advantages of moving such a mechanism to a centralized SDWN controller. It is worth highlighting that the average control overhead represents less than 3% of the overall network traffic, i.e., UE and control traffic.

6 Conclusion

In this article, we proposed applying the concepts of SDWN to support the development of flexible, programmable, and sustainable H-CRAN infrastructures to achieve the area throughput target for the forthcoming next generation cellular networks. Moreover, we observed the design decisions that need to be made on the path towards a full SDWN-enabled cellular network and discussed how SDWN can be employed in conjunction with H-CRAN. We also conducted a case study for H-CRAN where an SDWN controller handles frequency assignment and channel distribution of RRHs based on the handover performed by UEs.

Our results show mainly an increase in the overall throughput of 40% and decrease of energy consumption between 6% and 20% when SDWN is compared against traditional 3G/4G network planning. Also, we analyzed the overhead posed by SDWN in terms of control traffic considering the number of UEs and RRH, which in the worst case evaluated was 7% of the total data traffic. The overhead to employ SDWN in H-CRAN seems reasonable, considering the benefits that can be achieved as demonstrated in our case study.

As future work, we will deploy an SDWN case study over the FUTEBOL testbed⁴ to study its effect in real deployments. Also, we intend to extend the SDWN controller to a case study involving spectrum sharing for two operators to prove its usability in such context and the potential of using three or more wireless functions at once.

7 Endnotes

¹ OF-Config - https://www.opennetworking.org/technical-communities/areas/specification/1928-of-config

² Source code: https://github.com/ComputerNetworks-UFRGS/hcran-simulator

³ OpenFlow - https://www.opennetworking.org/ja/sdn-resources-ja/onf-specifications/openflow

⁴ FUTEBOL - http://www.ict-futebol.eu/