Flexible C-RAN: Radio Technology for 5G
Liljana Gavrilovska, Valentin Rakovic, Aleksandar Ichkov, Davor Todorovski, Simona Marinova
 x Support of multiple air interface standards and flexible
Abstract—Conventional radio access networks are designed to
utilize static configuration and are statically deployed. As results
they are inefficient in handling any spatio-temporal fluctuations
of the underlying traffic demand. Cloud-RAN represents a novel
centralized technology based on softwareization and
virtualization technology that can efficiently address the
problems of legacy networks. Cloud-RAN facilitates high data
rates as well as high network and radio adaptability across the
software defined wireless networks. This paper elaborates the C-
RAN concept providing overview of current status, relevant
features and research challenges related to it. Moreover, the
paper presents a developed demo platform capable of efficient
virtualization of different types of wireless technologies that
belong to a heterogeneous wireless environment. It utilizes
commercial and open-source solutions, such as OpenStack and
SDR software. The performance analysis highlights the behavior
of GSM and LTE technologies, with respect to cloud resource
allocation. The paper also discusses some aspects and technical
requirements for a C-RAN based dynamical resource allocation.
Keywords— C-RAN, GSM, LTE, Virtual resources, SDN,
NFV, OpenStack.
I. INTRODUCTION
The volume of the wireless data traffic is increasing rapidly
due to the unprecedented penetration of smartphones, tablets
and machine-type devices [1],[2]. Moreover, the dramatic
increase in population density in both residential and business
areas, results in network load that changes in a spatio-
temporal pattern known as the “Tidal Effect” [3]. The growth
of the wireless data traffic cannot be effectively satisfied by
traditional cellular system due to high per-bit cost and limited
spectrum resources. The mobile operators are seeking new
technologies to meet the diverse and increasing demands of
users, applications and services [4]. The current Radio Access
Networks (RAN) deployments can use the processing
capacity of a given Base Station (BS) only for its own mobile
users. Thus, during the day the BSs in business areas are over-
subscribed while the BSs in residential areas stay idle, still
consuming a large amount of power, and vice versa. It
becomes a pressing need to improve the existing RAN
architectures to better solve these problems and to effectively
use the available capacity. Moreover, the network throughput,
service coverage, spectrum and energy efficiency should be
jointly considered and optimized.
Aiming to address these apt issues, future RANs should
meet several requirements:
All authors are with the Faculty of Electrical Engineering and Information
Technologies, Ss Cyril and Methodius University in Skopje, Rugjer Boskovic
18, 1000 Skopje, Macedonia
{liljana,valentin,ichkov}@feit.ukim.edu.mk).
978-1-5386-1800-4/17/$31.00 ©2017 IEEE
software upgrade.
x Provision of reliable services with reduced cost, while
maintaining healthy revenue.
x Optimization among capacity, mobility, and coverage
in broadband cellular wireless systems.
Such functional necessities demand the evolution of the
whole network, not only the RAN itself. The cloud
computation approach can provide the necessary tools for
addressing the protruding issues related to modern mobile
networks. More specifically, introducing the concepts of
Software-Defined Network (SDN) [5] and Network Function
Virtualization (NFV) [6] can leverage the abstraction of the
different physical resources, components and functional
entities into a logic resource pool, which can be effectively
orchestrated to meet the diverse and varying user demands.
Therefore, the radio front-ends in RAN can be abstracted as
sole hardware and antennas with different transmission
capabilities. The main signal processing will be performed in
the cloud, thus facilitating on-the-fly and complete flexible
allocation of the underlying heterogeneous resources. This
concept of softwareization and virtualization of the RAN
resources is named Cloud-RAN (C-RAN) The C-RAN
concept has attracted significant attention both from academia
and industry [2], [4], [5]. It has been regarded as an auspicious
technology that will pave the road for the fifth generation
(5G) wireless systems.
This paper presents the definition, function, and current
research challenges of C-RAN. Moreover, the paper
introduces a cloud platform based on OpenStack and SDR
that deploys a multi-RAN network, comprising of fully
virtualized GSM, UMTS and LTE capabilities. The paper is
organized as follows. Section II presents the generic concepts
and current trends in the area of C-RAN. Section III
elaborates on the proposed system setup. Section IV describes
the specific scenarios of interest for the given C-RAN
platform. It also provides practical insights, findings and
results regarding the cloud resource allocation for GSM and
LTE systems, and discusses the requirements for an end-to-
end dynamical resource allocation C-RAN solution. Section V
concludes the paper.
II. C-RAN
C-RAN represents a new wireless system paradigm that
features centralized processing, collaborative radio, real-time
cloud computing, and power efficient infrastructure. Fig. 1
depicts the generic C-RAN architecture. It is consists of two
core entities: i) Centralized Baseband Units (BBUs) and ii)
(e-mail:
distributed Radio Remote Units (RRUs). The BBUs are
255
implemented on the cloud IT platform and virtualize the
different RAN technologies. The RRUs represent simple radio
antennas that are dispersed over a given geographical area and
communicate with the BBUs via ultra-fast, low-latency
communication links.
Fig. 1. Generic C-RAN architecture.
The C-RAN architecture facilitates several benefits, compared
to the legacy wireless systems, such as:
x Increase in capacity and reduction in inter-channel
interferences: The centralized BBU can share the
resources dynamically and cooperatively among the
multiple cells (i.e. RRUs). Thus, the resources can be
utilized effectively as per service demand. The inter-
channel interference can be alleviated as a result of the
joint scheduling and processing.
x System throughput improvement: C-RAN can facilitate
dense RRU deployment schemes in areas that require
high throughput services.
x Coexistence of multiple wireless technologies: C-RAN
and its centralized BBU design can support multiple
wireless standards, which can be effectively deployed,
managed and utilized based on the user demands,
leveraging a fully heterogeneous wireless system.
x Energy efficiency and green communications: C-RAN
can improve the energy efficiency by reducing the
number of active cell sites when required, and thereby
decreasing the overall power consumption of the
operator. Moreover, during low traffic periods,
underutilized BBUs can be turned off and their traffic
can be redistributed to the active BBUs.
x Reduction in capital and operational expenditure: The
deployment and maintenance cost of per cell site can
be reduced significantly, because the BBUs are
centralized and only the RRUs are distributed at
different cell sites.
x Business Model Transformation: The C-RAN concept
256
will generate more business models, such as the BBU
pool resource rental system, cellular system as a
service, as well as more freemium services.
The reminder of the section will present and focus on C-RAN
open issues as well as ongoing activities.
A. C-RAN Open Challenges
Although, C-RAN is envisioned to bring and foster many
improvements in wireless systems, it is still in development
stages, prompting a number of challenges that need to be
addressed.
1) Transport Network
The C-RAN architecture brings a significant overhead on
the communication links between the RRUs and the BBU
pool. Compared with the backhaul requirements, the fronthaul
transport capacity is envisioned to be approximately 50 times
higher [7],[8]. Moreover, the centralized BBU pool should
support 10–1000 base station sites [7], resulting in an
enormous amount of data that will be carried towards the
cloud. TABLE 1 depicts the data rates between the RRU and
BBU for the different legacy RANs.
TABLE 1
BIT RATES BETWEEN RRU AND BBU [7]
RAN technology and Bit rate
configuration
GSM 25.6 Mbp
TD-SCDMA 330 Mbps
LTE 2.5 Gbps
LTE-A 13.8 Gbps
The transport network not only needs to support high
bandwidth and be cost efficient, but also needs to support
strict latency and jitter requirements. Several works have
identified that latencies on the transport network must not
exceed 1ms, and can also require tight synchronization slots in
the range of micro, even nano-seconds [9],[10]. The
researchers have recognized several novel technologies such
as SDN/NFV [10] and Mobile Edge Computing (MEC) [11]
that will facilitate these strict transport requirements.
2) BBU design
One of the core features of C-RAN is the capability to
dynamically adapt to the underlying conditions. In order, to
leverage this feature, BBUs must be capable of cooperation
and even clustering. To achieve optimal throughput and
energy savings, at the same time, the C-RAN base stations
need to be chosen in a way that will optimize the number of
active RRUs/BBU units within the BBU pool. There are many
ongoing research activities that focus on developing efficient
resource sharing algorithms. Moreover, many works argue
that providing optimal C-RAN performance requires the
synergy between the resource sharing and BBU clustering
algorithms. For example, the authors in [12] propose a
mapping scheme for C-RAN that can dynamically adapt the
connections of BBUs and RRUs in respect to traffic demand.
In [13] authors propose different semi-static and adaptive
BBU-RRU switching schemes for C-RAN and prove that the
number of BBUs can be significantly reduced when compared
to static assignment.
3) Virtualization
Virtualization facilitates the creation of logically isolated
instances over abstracted physical hardware, which can be
shared in a dynamic, efficient and flexible manner.
Virtualization has been utilized for many years in the area of
data storage and cloud services. Network virtualization
represents a novel evolution of virtualization that plays a
crucial role for the realization of the C-RAN concept.
Deploying the virtual networks in C-RAN architecture
promotes flexible control, low cost, efficient resource usage,
and diversified applications [6].
The C-RAN virtualization can be implemented on several
different levels:
x Wireless network virtualization: The actual concept
of C-RAN is an example of network virtualization
[7]. Ongoing research activities in this area have
focused on providing virtualization for different
wireless network technologies, such as WiFi and
LTE [14].
x Hardware virtualization: Hardware virtualization
mainly focuses on virtualizing the underlying
hardware in a most efficient way, with respect to C-
RAN operation [15].
x Resource virtualization: This concept represents a
virtualization framework that enables multiple
Virtual Operators and/or base stations to share the
same resources and spectrum [16].
Virtualization and cloud infrastructure for IT applications
have been already well studied and developed. However, the
C-RAN concept poses completely different requirements on
the cloud infrastructure. Table 2 compares cloud computing
and C-RAN requirements for cloud infrastructure.
TABLE 2
CLOUD COMPUTING VS C-RAN REQUIREMENTS [7]
Cloud computing Cloud RAN
Client/BS data rate Mbps range, bursty Gbps range, constant
stream
Latency and jitter Range of ms Range of ms to Ps
Data life-time Long (content data) Extremely short
(baseband signaling)
Allowed recovery time Range of seconds - Range of ms (avoid
minutes outage)
Number of clients per Thousands, even Hundreds
centralized location millions
It is evident that C-RAN will require novel technical
solutions and concepts in the cloud in order to address its
diverse technical requirements.
B. Ongoing activities
1) R&D activities
Both academic and industrial communities have already
intensively started to focus their attention on C-RAN in a
number of R&D activities. China Mobile has collaborated
with industrial partners in order to sign a Memorandum of
Understanding (MoU) on C-RAN. Also several companies
such as, ZTE, IBM, Huawei, Intel, Orange, Alcatel-Lucent,
Ericsson, Nokia Networks have already signed a MoU with
China Mobile Research Institute, and started to work on novel
C-RAN architectures. Equipment vendors such as, Huawei
257
and Ericsson have also started to develop C-RAN
fundamental building blocks. The Next Generation Mobile
Networks (NGMN) alliance has proposed requirements and
solutions for a new RAN implementation describing use cases
for C-RAN and suggestions for solutions on building and
implementing C-RAN.
China Mobile, together with its industry partners developed
3GPP based C-RAN platform supporting GSM, UMTS, and
LTE. The platform is running on Intel processor-based servers
and has been operated as field-trials in commercial networks
in several cities in China [18]. Also, the Ericsson branch in
China has already proved and implemented the concept of
interconnecting RRUs and BBUs via Wavelength Division
Multiplexing – Passive Optical Network (WDM-PON) and
microwave E-band links [19]. Cisco have also recently
developed an end-to-end product that integrates virtualized
instances of packet core, RAN Management Dystem (RMS),
Centralized Self Optimizing Network for heterogeneous
wireless systems [20].
2) Standardization activities
The standardization activities related to C-RAN can be
separated in two main categories, i) standardization of
virtualization aspect and ii) standardization of transport
network aspects. The relevant standardization activities are
presented in Table 3.
TABLE 3
C-RAN STANDARDIZATION ACTIVITIES
Standardization Standardization activity
category
Virtualization ETSI NFV Industry Specification Group
(ISG) [21]
Open Networking Foundation (ONF) [22]
Metro Ethernet Forum [23]
Open Platform for NFV [24]
Transport network IEEE 1914 - Next Generation Fronthaul
Interface(NGFI) [25]
IEEE 1904.3 [26]
IEEE 802.1Qbv, 802.1Qbu [27]
IEEE 802.1CM [28]
IEEE 1588 [29]
The standardization activities mostly focus on the: i) cloud
virtualization aspects; ii) transport layer mechanisms that
facilitate advanced fronthaul operation such as per stream/user
QoS, enhanced scheduling and ultra-fast synchronization.
The following sections will elaborate and present the
practical aspects and implementation of the C-RAN concept
onto a laboratory demo platform.
III. VIRTUALIZED MULTI-RAN CELLULAR CLOUD PLATFORM
This paper implements the C-RAN concept in a realistic
demo cloud platform. The goal is to create a completely
virtualized heterogeneous multi-RAN cellular network with
centralized management of the available network resources in
the cloud. Utilizing the centralized RRM unit, the demo
platform enables implementation of a flexible and agile cloud-
based network architecture. The platform setup utilizes widely
available open-source solutions, such as OpenStack, and
commercial hardware peripherals in terms of Software
Defined Radios (SRDs).
A. OpenStack
OpenStack is free, open-source, cloud operating system
widely used in software platforms. It allows deployment of
Infrastructure-as-a-service (IaaS), where virtual servers and
other resources are available for the users. The software
platform consists of interconnected components that control
the processing, storage and network resources through a data
center. Users manage the available resources through
Command Line Interface (CLI) or a web-based service
(dashboard). We can also use the Representational State
Transfer Application Programming Interface (RESTful API)
to implement additional functionalities and services. The
OpenStack cloud operating system is completely free, easy
and fast to implement [30]. It has a large community, with
detailed tutorials and documentation for installation,
management and development. Moreover, it doesn’t require a
lot of hardware resources and it can be implemented on
standard desktop/laptop devices.
OpenStack has modular architecture, which contains a lot
of different services that have different functions and can be
dynamically added and deleted, as shown in Fig. 2. There are
some basic/core services that have to be installed so we can
have functional platform and additional services whose
implementation depends on the scenarios that we want to
analyse. The following text presents some of the basic
services.
Fig. 2. Openstack services [31].
OpenStack Compute (Nova) is the main controller that
manages all the resources in the cloud and is capable of
creating, destroying and managing the virtual
machines/servers. Nova does the coordination, allocation and
provisioning that is needed so the cloud can properly function.
This service is written in the programming language Python
and uses more external libraries, for communication, access to
SQL databases etc. The architecture of the service is designed
for horizontal scaling of standard hardware without
requirements for commercial hardware or software and
enables integration with existing systems and technologies
[32].
OpenStack Networking (Neutron) is the service that
manages the networks and IP addresses. Neutron ensures
avoiding of bottlenecks in the network and gives the users a
tool to self-configure the network. Neutron enables network
models for different applications and user groups. Standard
models include flat networks and VLANs that share servers
258
and traffic. Neutron manages the IP addresses, enabling static
and dynamic assignment. Floating IPs allow traffic to be
dynamically rerouted to any source in the IT infrastructure, so
users can redirect traffic in case of maintenance or decline of
the network. Users can create their own networks, control
traffic and connect servers and devices of one or many
networks. Administrators can use technologies such as SDN
to support high levels of multi-tenancy and massive
scalability. Neutron allows extensive framework that can
develop and manage additional network services such as: IDS,
Load balancing, Firewalls and VPNs.
OpenStack Identity (Keystone) is the service that offers
authentication and authorization of the users in the cloud
operating system. It supports different types of authentication.
Including standard procedures with username and password,
token-based systems, AWS-style authentication etc.
Additionally, it enables a list of all installed OpenStack
services in one central registry. Users can programmatically
decide which resources to use.
Open Stack allows easily implementing new services and
rules.
B. Telemetry Service (Data Collection)
OpenStack Telemetry Data Collection (Ceilometer) is an
additional service that enables tracking of the resource
utilization in the system, particular metrics of interest,
statistics, alarm thresholds that could be triggered. There is a
possibility for additional configuration of other services
(Cinder, Glance, Heat, Keystone, Neutron, Swift) so they can
be able to use the Telemetry Data Collection service [33].
This service offers the following functionalities:
x Efficient data polling of various metrics connected to
OpenStack services.
x Data gathering of specific events and metrics through
monitoring and receiving notifications from other
OpenStack services.
x Publishing the gathered data to data centers and other
services.
The Telemetry service consists of the following
components:
x Compute agent (ceilometer-agent-compute): This agent
runs on each compute node and pulls statistics about the
utilization of the resources.
x Central agent (ceilometer-agent-central): Runs on the
central management server in order to pull statistics
about the utilization of the resources that are not
connected to the Virtual Machines (VMs) or compute
nodes. It is possible to implement more agents in order
to horizontally scale the service.
x Notification agent (ceilometer-agent-notification): Runs
on the central management server and receives message
queues about creating events and metering data.
x Collector (ceilometer-collector): It is installed on the
central management server and transfers the data to a
data center or external user, without modifications.
 x API server (ceilometer-api): Runs on one or more central
servers and enables access to data.
The Data Collection service enables tracking of enormous
number of metrics that can be seen with the command
“ceilometer meter-list”. The variety of metrics includes
different system parameters such as: processing power (CPU),
RAM, disk, network parameters, storage etc.
There are three types of metrics:
x Cumulative: Increasing over time.
x Gauge: Discrete values, for example, floating IPs
assignment.
x Delta: Changing over time, for example bandwidth.
If we want to extract a general conclusion about the system
and the overall resource utilization, we can use the commands
that are part of the official OpenStack documentation. The
output of those commands includes information about the
minimal and maximal resource utilization, as well as the
average and the sum over a time period. The utilization of the
virtual compute resources, processing power and RAM varies
over time, depending on the corresponding software tools that
are running on the virtual server. The Data Collection service
also offers the possibility of more specific requests, such as
resource utilization statistics for specific metrics and resource
ids on a specific virtual server (VM) and much more.
C. Telemetry Service (Alarming)
Telemetry alarming represents a logical continuation of the
Data Collection service. This service is mostly used to trigger
alarms when data exceeds predefined thresholds [34].
Telemetry Alarming consists of the following components:
x API server (aodh-api): It is installed on one or more
central management servers to enable access to
information about the alarms that is stored in databases.
x Alarm evaluator (aodh-evaluator): It is installed on one
or more central management servers to decide when an
alarm should be triggered based on the statistical
tendency that exceeds the threshold in many evaluation
periods or a maximal value that is reached (critical
scenarios).
x Notification listener (aodh-listener): It is installed on a
central server and decides when to release the alarm. The
alarms are generated based on predefined rules about
different events that are followed by the notification
agents of Telemetry Data Collection service.
x Alarm notifier (aodh-notifier): Runs on one or more
central servers and allows alarms to be set, based on the
evaluation of the thresholds.
The basic usage of this service is alarm creation and
constant tracking for the state of the alarm. This service
allows creating the alarms with many parameters such as:
threshold, metric name, time frame, number of evaluation
periods that have to be reached in order to evaluate the state of
259
the alarm, actions that have to be taken after we get the state
of the alarm.
The alarm can be found in three different states:
x Insufficient data: This means that the VM doesn’t
work long enough so we can extract a conclusion
about the state. Usually happens when we configure
the alarm with more evaluation periods.
x Ok: This state means that the evaluation has finished
and the threshold that we have put is not exceeded,
so the VM is working in the predefined boundaries.
x Alarm: The alarm is found in this state when the
threshold is exceeded and the aodh evaluation agent
sends publishing request to the notification agent.
Depending on the state of the alarm, this service allows us
to take different actions. Such actions can be driven by
advanced algorithms for monitoring and optimization of
resource utilization, different types of traffic and so on.
D. OpenSDR
The functionalities of different RAN nodes, i.e. base
stations, are implemented using the SDRs, which enable
implementation of hardware capabilities using software tools.
In our setup, we use Universal Software Radio Peripheral
(USRP) devices, developed by National Instruments. The
USRPs are very flexible and easily reconfigurable, allowing
implementation of different radio access technologies such as
GSM, UMTS and LTE. The virtualization of the RAN nodes
is achieved through the usage of open-source software tools
that are installed on separate virtual servers running on the
demo platform. The available pool of compute resources can
be easily managed and reconfigured, depending on the
network load. The following text provides a brief overview of
the software tools used for virtualization of GSM/UMTS/LTE
network segments.
1) OpenBTS
OpenBTS is an open source software project dedicated to
substituting legacy telecommunication protocols and
traditionally complex, proprietary hardware systems with
Internet Protocol and a flexible software architecture [35].
This is achieved by using a software-defined radio to present a
standard 3GPP air interface to user devices, while
simultaneously presenting those devices as SIP endpoints to
the Internet.
OpenBTS allows the “Um” radio interface of the traditional
mobile network to directly interconnect with Internet
telephony protocols. The Session Initiation Protocol (SIP) and
Real-time Transport Protocol (RTP) are the two protocols that
OpenBTS uses to convert GSM traffic into VoIP [36]. This
enables users to develop a complete "network-in-a-box"
solution with a virtualized GSM base station and a network
core comprised of open protocols which uses IP as its
transport. Commercial mobile phones can be used as user
devices, presented as SIP endpoints in a standard Voice over
IP (VoIP) networks. They are capable of establishing standard
communications, such as voice calls, SMS messaging and
data usage via GPRS.
The OpenBTS software packet consists of four separate
components with different functionalities (Asterisk-voice
calls, SIPAuthServe – authentication, SMQueue – SMS
messaging, OpenBTS - GSM air interface). By installing all of
the following components on a single system, users can set up
and operate a fully virtualized and functional standardized
GSM network.
2) OpenBTS-UMTS
OpenBTS-UMTS presents an open-source software tool for
implementation of software-defined UMTS network nodes,
built upon the same framework as OpenBTS. OpenBTS -
UMTS utilizes SDR devices (URSPs) for implementation of
standard 3GPP air interface with a fully virtualized UMTS
base station (NodeB). Commercial mobile phones can be used
to register on the UMTS thus being treated as an IP endpoint
at the edge of the network [37]. OpenBTS – UMTS
implements 3GPP Release 99, therefore it supports maximum
data speed of 324 Kbytes/s in downlink and 52 Kbytes/s in
uplink.
The main advantage of the software implementation of the
base stations utilized by both OpenBTS and OpenBTS-
UMTS, is the ability to configure the main transmission
parameters such as the central frequency, channel bandwidth,
antenna gain etc. This is accomplished simply by executing
commands to manipulate keys stored in a SQLite3 database.
The key values can be modified and applied to the running
system within a few seconds without interrupting service, thus
increasing the network flexibility and adaptability to different
scenarios.
3) srsLTE
srsLTE is an open source library that provides the tools for
the virtualization of LTE RAN node capabilities (eNodeB)
and LTE UE capabilities. The code is written in ANSI C and
makes extensive use of Single Instruction Multiple Data
(SIMD) operations for maximal performance.
srsLTE is based on LTE Release 8 which is compliant in
FDD configuration. It supports from 1.4 MHz to 20 MHz
bandwidth, for SISO (1x1) and MISO (2x1) downlink
transmissions. The PHY LTE in srsLTE supports all DL
channels for both the eNodeB and the UE, as well as all UL
channels for the UE. There is an additional open-source
software tool based on the srsLTE library called srsUE, which
represents a software radio LTE UE covering all layers of the
network stack from PHY to IP.
srsLTE implements a modular architecture with
hierarchically organized modules in 4 different categories
(Core, Physical Channels, UE Processes, Example
Applications). This approach allows users to easily customize,
improve or completely replace components without affecting
the rest of the code.
In terms of hardware, srsLTE can be executed on General-
Purpose Processors (GPP) and deals with buffers of samples
in system memory, making it compatible with any RF front-
260
end. SrsLTE currently provides interfaces to the Universal
Hardware Driver (UHD), giving support to the Ettus and
National Instruments USRP devices. The capabilities of the
srsLTE software tool are addressed in details by the
developers in [38].
This section presented the core software tools utilized for
the development of the heterogeneous multi-RAN cellular
cloud platform. There exist many different options for
virtualizing the cellular technologies of interest, however the
research community as most efficient and reliable identifies
the employed tools.
IV. SCENARIO SETUP (PROOF OF CONCEPT)
This section presents the practical results and lessons
learned regarding the virtualization of different wireless
technologies on the developed cloud platform. The demo
cloud platform is based on several logical entities
implemented on commercial hardware components, as shown
at Fig. 3.
Fig. 3. Demo platform generic architecture.
The main components/nodes are based on the OpenStack
Newton version and installed on separate computers:
x The controller: enables a centralized control and
management of network functionalities and resources.
It is installed on a virtual machine running Ubuntu
Server 16.04 LTS (using VirtualBox), with 8 GB RAM
and 100 GB of storage capacity.
x The compute nodes: represent the available pool of
compute resources in terms of vCPU and vRAM that
are allocated between the virtual servers. The compute
nodes storage capacities are shared among the running
virtual servers. We have implemented two compute
node that are running on separate laptop devices
(Lenovo ThinkPad with Intel i7 processors, 4 GB
RAM and 100 GB of disk memory with Ubuntu Server
16.04 LTS installed).
x The Block memory node: enables easy expansion of the
storage capacity, with volume blocks that can be
attached to the virtual servers running on the platform.
x The RRU nodes: are implemented on separate virtual
servers running on Ubuntu Cloud Server 14.04.5 LTS.
The GSM node is implemented using the software tool
OpenBTS, which utilizes the N210 USRP device. The
 LTE eNodeB is implemented using the software tool
srsLTE, which utilizes the x310 USRP device. The
RRU resource pool is represented by the radio
capabilities of the corresponding USRP devices. The
overall BBU pool depends on the flavors (in terms of
vCPU and vRAM) of the virtual servers that are
hosting the software tools. The virtual servers can be
dynamically resized, through the use of different
flavors, depending on the configuration parameters and
the overall network load. Additionally, one UMTS
node is running on a separate compute node using the
software tool OpenBTS-UMTS, which utilizes the
N210 USRP device. It uses a dedicated pool of
compute resources (depending on the hardware
capabilities of the corresponding compute node) that
cannot be dynamically reallocated due to the software
limitations of the UHD driver in virtualized
environment.
The remainder of the section presents the practical
implementation and lessons learned about the virtualization of
different wireless technologies and the possibilities for
developing and providing an end-to-end dynamic
reconfiguration solution.
A. System Utilization Results
The scenario of interest focuses on the performance
evaluation of the developed platform, in a homogeneous
wireless system setup, where the platform virtualizes either
the GSM or the LTE system. Fig. 4 presents the generic
demo-platform layout.
Fig. 4. Performance evaluation scenario setup.
The scenario analyzes the behavior of the GSM/GPRS and
LTE systems regarding their virtual resource utilization (CPU
and RAM). Specifically, the scenario evaluates the achieved
system utilization (U) for both GSM and LTE in the downlink
(DL) direction, for a specific and dedicated portion of the
CPU or RAM. The system utilization can be defined as:
(1)
where denotes the achieved average system throughput for
a given (CPU,RAM) configuration and denotes the
261
maximum achievable throughput by the system. In the
remainder of the section, the virtual CPU and RAM resources
will be denoted as vCPU and vRAM. Table 4 presents the
performance evaluation parameters and their respective
values.
TABLE 4
PERFORMANCE EVALUATION PARAMETERS
System parameters Parameter value
GSM standard 3GPP: Release 1998
No. of GSM mobile devices 1
GSM ARFCN 51
GSM packet data mode GPRS
GSM slot allocation 5+2
LTE standard in use 3GPP: Release 8
No. of LTE mobile devices 1
LTE mode FDD
LTE band number 30
LTE Resource Blocks 6
LTE antenna configuration SISO
Fig. 5 depicts the system utilization of the GSM and LTE
systems versus the respective vCPU utilization. The figure
clearly shows that the vCPU has effect on the achieved system
performance. It is evident that the LTE system performance is
significantly affected by the underlying CPU capabilities of
the C-RAN platform. This is a result of LTE’s complex
system design. Since LTE is based on OFDM, it requires
significant computational power for the baseband signal
processing such as FFT calculations, equalization, encoding,
modulation, etc. This poses high load on the processing
capabilities of the underlying communication hardware,
which acts as the bottleneck in the communication process.
The GSM system performance is less affected by the
computational power and allocated CPU resources compared
to LTE, as a results of the significantly less complex system
design and PHY layer.
Fig. 5. System utilization vs Number of vCPUs for GSM and LTE.
Fig. 6 depicts the system utilization of the GSM and LTE
systems versus the respective vRAM utilization. The figure
clearly shows that the vRAM has significant effect on the
achieved system performance for both communication
systems. The figure shows that the GSM system is more
depended on the RAM resources when compared to the
behavior of the LTE system. Moreover, the LTE system is
capable of achieving the maximal system utilization for lower
vRAM allocations compared to the GSM system. This
phenomenon is tightly related to the discussion for Fig. 5.
Specifically, the LTE relies more on the raw computational
resources and capabilities of the cloud as a result of its highly
complex baseband processing.
Fig. 6. System utilization vs vRAM for GSM and LTE.
The results presented in Fig. 5 and Fig. 6 can provide valuable
information for the dynamic resource allocation process of C-
RANs and can be utilized as an input information into the
decision making the Virtual Resource Manager (VRM) [39].
However, the end-to-end design and orchestration of a
Fig. 7. Ceilometer statistics for CPU and memory utilization.
Fig. 8. Ceilometer statistics for specific meter and resource id over a predefined time period.
262
dynamic resource allocation also requires specific C-RAN
tools such as alarming and telemetry. The following
subsection will specifically focus on the capabilities and
features of the alarming and telemetry tools.
B. Telemetry/Alarming Results
OpenStack’s Telemetry service is composed out of two
main services, Data Collection (Ceilometer) and Alarming
(Aodh), as detailed in Section III. Ceilometer collects event
and metering data by monitoring notifications that are
periodically sent from the other OpenStack services (Nova,
Neutron, Cinder, Swift and Heat). Its main goal is to reliably
collect data on the utilization of the available virtual resources
comprising the deployed cloud platform and persist these data
for subsequent retrieval and further analysis [10]. It publishes
the collected data to various targets including SQL databases,
MongoDB or as message queues. Aodh enables us to create
alarms of interest based on the collected data, to trigger
specific actions when the defined criteria are met.
 Fig. 9 - Creating of alarm (90% of vCPU utilization over a time period of 1 minute).
Fig. 10 - Ceilometer alarm list and their alarm states.
We are using ceilometer as a service to monitor the general
system behavior and the overall resource utilization in real
time. The main focus of our scenario setup is the virtual
compute resource utilization (vCPU and vRAM). Using
ceilometer statistics commands, we can monitor their
respective utilization over time, average utilization over time,
max and min values and more. As seen at Fig. 7, the
processing power (vCPU) varies over time depending on the
network load. When all network segments are active, the max
values reaches up to 100%, with minimal values of less than
1% when the RAN nodes are turned off and all virtual servers
are shutoff as well. On the other hand, memory utilization
(vRAM) is less dynamic and strongly depends on the state of
the processes that are active on the virtual servers (higher
number of active processes means more vRAM is utilized).
Additionally, ceilometer allows us to take statistics over
predefined time periods for specific meters and resource ids
such as vCPU/vRAM utilization on a certain virtual server.
Fig. 8 shows the output for the vCPU utilization on a running
virtual server over a time period of 50000 milliseconds, as
well as the max and min values, the average and the sum over
the time period and the duration and the starting point of the
data collection process.
We are also using the alarming service Aodh to create
specific alarms to trigger actions based on the collected data
from ceilometer (see Section III.C for more details). The
creation of specific alarm (90% of vCPU utilization on a
263
specified virtual server over a time period of 1 minute) is
show at Fig. 9. Generally, the alarms can be found in three
states: Insufficient data, OK and Alarm. The Alarm state is of
our close interest, as it triggers the further actions that are
taken based on the alarm’s nature. The output of the
‘ceilometer alarm-list’ command is show at Fig. 10, with
several established alarms that are monitoring different
thresholds for the vCPU utilization when all RAN nodes are
active. We are increasing the network load to trigger the high
vCPU utilization alarms established on the virtual server
running srsLTE (LTE uses more processing power compared
to the other RAN, as elaborated in Sec. IV.A). The varieties of
alarms that can be created enable a real-time monitoring of the
resource utilization. It can be used to establish intelligent
resource management and avoid overloads or under-utilization
of the available resource pools [39].
V. CONCLUSION
Cloud-RAN represents an auspicious technology, which
proposes centralization and virtualization of the baseband
processing resources in a cloud environment and addresses the
requirements for the next generation of networks, i.e. 5G.
Operators and telecom vendors started to be havily involved
in the C-RAN technology in attempt to facilitate significant
cost savings, improved system performance and new business
models and opportunities. While the concept of C-RAN has
been clearly identified, intensive and focused research is still
required to find an optimal architecture that maximizes the
benefits of the C-RAN. [13]
This paper presents the generic definitions, basic
functionalities and current research challenges of C-RAN.
Moreover, the paper presents a cloud platform based on [14]
OpenStack and SDR that deploys a multi-RAN cloud-based
heterogeneous network, comprising of fully virtualized GSM,
UMTS and LTE technologies. The paper also provides [15]
practical insights, findings and results regarding the cloud
resource allocation for virtualized GSM and LTE systems.
The provided results clearly show that every RAN technology [16]
has a different footprint on the cloud resources, which opens
the possibilities for advanced cloud resource allocation
mechanisms. Moreover, the paper pinpoints the requirements [17]
and technical directions for an end-to-end dynamical resource
allocation solution for C-RAN environments. [18]
[19]
REFERENCES
[1] H. Niu, C. Li, A. Papathanassiou and G. Wu, "RAN architecture [20]
options and performance for 5G network evolution," 2014 IEEE
Wireless Communications and Networking Conference Workshops
(WCNCW), Istanbul, 2014, pp. 294-298. [21]
[2] K. Wang, K. Yang, X. Wang and C. S. Magurawalage, "Cost-effective
resource allocation in C-RAN with mobile cloud," 2016 IEEE [22]
International Conference on Communications (ICC), Kuala Lumpur,
2016, pp. 1-6. [23]
[3] J. Wu, Z. Zhang, Y. Hong and Y. Wen, "Cloud radio access network [24]
(C-RAN): a primer," in IEEE Network, vol. 29, no. 1, pp. 35-41, Jan.- [25]
Feb. 2015. [26]
[4] M. Peng, C. Wang, V. Lau and H. V. Poor, "Fronthaul-constrained [27]
cloud radio access networks: insights and challenges," in IEEE Wireless [28]
Communications, vol. 22, no. 2, pp. 152-160, April 2015. [29]
[5] D. B. Rawat and S. R. Reddy, "Software Defined Networking
Architecture, Security and Energy Efficiency: A Survey," in IEEE [30]
Communications Surveys & Tutorials, vol. 19, no. 1, pp. 325-346, [31]
Firstquarter 2017.
[6] J. van de Belt; H. Ahmadi; L. Doyle, "Defining and Surveying Wireless [32]
Link and Network Virtualization," in IEEE Communications Surveys &
Tutorials , vol.PP, no.99, pp.1-1, 2017. [33]
[7] A. Checko et al., "Cloud RAN for Mobile Networks—A Technology
Overview," in IEEE Communications Surveys & Tutorials, vol. 17, no. [34]
1, pp. 405-426, Firstquarter 2015.
[8] X. Costa-Perez et al., "5G-Crosshaul: An SDN/NFV Integrated [35]
Fronthaul/Backhaul Transport Network Architecture," in IEEE Wireless [36]
Communications, vol. 24, no. 1, pp. 38-45, February 2017.
[9] D. Chitimalla, K. Kondepu, L. Valcarenghi, M. Tornatore, and B. [37]
Mukherjee, "5G Fronthaul–Latency and Jitter Studies of CPRI Over [38]
Ethernet," J. Opt. Commun. Netw., vol. 9, pp. 172-182, 2017.
[10] C. Ranaweera, E. Wong, A. Nirmalathas, C. Jayasundara and C. Lim,
"5G C-RAN architecture: A comparison of multiple optical fronthaul
networks," 2017 International Conference on Optical Network Design
and Modelling (ONDM), Budapest, Hungary, 2017, pp. 1-6.
[11] J. Kang, O. Simeone, J. Kang and S. Shamai, "Control-Data Separation [39]
across Edge and Cloud for Uplink Communications in C-RAN," 2017
IEEE Wireless Communications and Networking Conference (WCNC),
San Francisco, CA, 2017, pp. 1-6.
[12] Y. S. Chen; W. L. Chiang; M. C. Shih, "A Dynamic BBU–RRH
Mapping Scheme Using Borrow-and-Lend Approach in Cloud Radio
264
Access Networks," in IEEE Systems Journal , vol.PP, no.99, pp.1-12,
2017.
S. Namba, T. Warabino and S. Kaneko, "BBU-RRH switching schemes
for centralized RAN," 7th International Conference on Communications
and Networking in China, Kun Ming, 2012, pp. 762-766.
J. Feng, Q. Zhang, G. Dong, P. Cao and Z. Feng, "An Approach to 5G
Wireless Network Virtualization: Architecture and Trial Environment,"
2017 IEEE Wireless Communications and Networking Conference
(WCNC), San Francisco, CA, 2017, pp. 1-6.
H. Zhu, Z. Zhang, J. Wu, D. Guo and S. Tang, "Scheduling Algorithm
Design for Virtualized Hardware Accelerator in C-RAN," 2016
International Conference on Cloud Computing Research and
Innovations (ICCCRI), Singapore, 2016, pp. 25-29.
M. Richart, J. Baliosian, J. Serrat and J. L. Gorricho, "Resource Slicing
in Virtual Wireless Networks: A Survey," in IEEE Transactions on
Network and Service Management, vol. 13, no. 3, pp. 462-476, Sept.
2016.
“Intel heterogeneous network solution brief,” Santa Clara, CA, USA,
2014, Tech. Rep.
C. Liu, K. Sundaresan, M. Jiang, S. Rangarajan, and G.-K. Chang,
Z. Ghebretensae et al., “Transmission solutions and architectures for
heterogeneous networks built as C-RANs,” in Proc. 7th Int. ICST Conf.
CHINACOM, 2012, pp. 748–752.
Online information:
http://www.cisco.com/c/en/us/solutions/collateral/service-
provider/small-cell-solutions/datasheet-c78-736621.html
Online information: http://www.etsi.org/technologies-
clusters/technologies/nfv
Online information: https://www.opennetworking.org/sdn-
resources/technical-library
Online information: https://mef.net/resources/technical-specifications
Online information: https://www.opnfv.org
Online information: https://standards.ieee.org/develop/wg/NGFI.html
Online information: http://www.ieee1904.org/3/tf3_home.shtml
Online information: http://www.ieee802.org/1/pages/802.1Q.html
Online information: http://www.ieee802.org/1/pages/802.1cm.html
Online information: https://standards.ieee.org/findstds/standard/1588-
2008.html
Online information: https://www.openstack.org/software/newton/
Online information: http://www.unixarena.com/2015/08/openstack-
architecture-and-components-overview.html
Online information: https://docs.openstack.org/newton/install-guide-
ubuntu/
Online information: https://docs.openstack.org/admin-
guide/telemetry.html
Online information: https://docs.openstack.org/project-install-
guide/telemetry-alarming/newton/get_started.html
Online information. http://openbts.org/
Michael Iedema, Getting started with OpenBTS, O'Reilly Media,
January, 2015
Online information. https://fairwaves.co/blog/openbts-umts-3g-umtrx/
Gomez-Miguelez, I., Garcia-Saavedra, A., Sutton, P.D., Serrano, P.,
Cano, C., & Leith, srslte: An open-source platform for LTE evolution
and experimentation, Proceedings of the Tenth ACM International
Workshop on Wireless Network Testbeds, Experimental Evaluation, and
Characterization, WiNTECH '16, pp. 25-32. ACM, New York, NY,
USA.
V. Rakovic, A. Ichkov, S. Marinova, D. Todorovski, V. Atanasovski
and L. Gavrilovska, “Dynamic Virtual Resource Allocation in
Virtualized multi-RAT Cellular Networks,” Springer Journal on
Wireless Personal Communications, July 2017. Online access at:
https://www.springerprofessional.de/en/dynamic-virtual-resource-
allocation-in-virtualized-multi-rat-cel/12350738