CLOUD RAN

1 Cloud RAN
CLOUD RAN
Abstract
Mobile broadband is immensely important globally as a key
socio-economic enabler, as evidenced by the continuing growth
of data trafc on mobile networks. To meet this unabated growth
in demand, cellular operators must increase their network
capacity by using advanced wireless technologies like adding
more network elements like cell sites, controllers, etc.
According to growth estimation data, data trafc increases by
131 percent every year, while air interface grows 55 percent
yearly. At the same time, ARPU is constantly decreasing.
Per UMTS Forum Report 44, the total worldwide mobile trafc
will reach more than 127 Exabytes in 2020, which is 33 times
more than the 2010 gure. Signicantly, at least 80 percent of
the trafc volume remains generated by users, leading to large
variations in the total mobile trafc, in terms of time and space
variations of trafc. Future mobile networks must be designed to
cope with such variation of trafc and uneven trafc distribution,
while at the same time maintaining permanent and extensive
geographical coverage in order to provide continuity of service
to customers. In 2020, daily traffic per Mobile Broadband
subscription in the representative Western European country
will stand at 294 MB, and at 503 MB for dongles (67 times
greater than in 2010).
The cost of acquiring a new spectrum, deploying new wireless
carriers, and evolving network technologies (e.g., from GSM to
W-CDMA to LTE), while adding more processing capacity, new
radios, and antennasand managing the resulting heterogeneous
networkis becoming economically unsustainable and leads
to a vicious cycle of demand.
An increase in the number of base stations is resulting in more
power consumption, higher interference, and reduced coverage
and capacity due to interference. This also requires more radio
network controllers.
Radio Access Network (RAN) architecture requires solutions
in the following areas:
> Additional base stations and radio antennas without
increasing the number of cell sites
> Reconfigurable BSs to support multiple technologies
> Resource aggregation and dynamic allocation
> Cooperative radio technology for coordinated multi point
transmission and reception
> More capacity and coverage with reduced interference
> Distributed antenna technology for increased coverage
> Controller software enhancement to run on virtualization
environment for lower costs and elastic capacity
> Summarily reduce Capex and Opex, and overall TCO
This white paper provides an overview of the distributed RAN
architecture called Cloud RAN, which addresses solutions for
the different areas mentioned previously. It also provides a
more detailed analysis of the Cloud radio network controller
architecture.
Introduction
In a conventional cellular network, the antenna, RF equipment,
digital processor, and baseband unit (BTS) sit in the cell site as
shown in the Conventional Cellular Network diagram on the
next page. This requires more power and real estate space, and
additional directional antennas and big cell towers to support
multi-frequency bands and new air interface technologies like LTE.
Enhancing a conventional network to support data trafc demand
in a current wireless network is economically unsustainable.
2 Cloud RAN
Active Antenna Array
In order to support increasing bandwidth demand, operators
need to enhance their network to support multiple technologies,
multiple frequency bands, and new air interface technologies.
This requires new antennas to be installed, multiple directional
antennas to support MIMO, beam forming, Rx diversity, etc.
This also increases the number of antennas in an already dense
network, which in turn increases interference between diferent
cells and reduces the capacity of the cell. The end result is
increases site costs.
In the Active Antenna array solution, each element supports a
connection to a separate transceiver element. The antenna array
can support multiple transceivers, which addresses the problem
of installing multiple antennas to support multiple air interface
technologies, MIMO, beam forming, Rx diversity, etc.
Each active antenna array has the transceivers (RF and digital
components) hardware embedded with each antenna element
inside the antenna array, rather than outside in a separate RF
box called RRH or in a conventional TRDU/TMA. This reduces
loss due to the RF connection between the antenna and external
RF. With the built-in transceivers, the individual signals can be
fed into diferent antenna elements to create focused vertical
beams per each user, carrier, technology, etc., which can control
the interference and increase cell capacity and coverage.
Multi-band Radio Remote Heads
In conventional networks, BTS/NodeB contains radio (RF and
digital components) and baseband units connected to an antenna
using coaxial cables.
The Open Base Station Architecture Initiative (OBSAI) and the
Common Public Radio Interface (CPRI) standards introduced
standardized interfaces separating the server and the radio
There is an immediate need to identify a solution that reduces the
number of cell sites, efectively reuses resources, and employs
recongurable basebands, multi-band radios, and distributed
wideband antennas to support diferent air interface technologies.
Cloud RAN architecture is based on distributed radio access
network architecture consisting of the following network
elements:
> Active antenna arrays
> Multi-band radio remote heads
> Centralized baseband units
> Metro cells
> Radio network controllers on cloud
> Common management server
> SON server for seamless management and optimal
network usage
Rural Zone
Urban Zone
Conventional Cellular Network
Base Station (BTS)
MSC
BSC
(BTS)
(BTS)
Internet
(BTS)
Figure 1: CRAN Access Technology Cloud
Common
Management
Server
IMS/
Operator
Services
Active
Antenna
System
SON
Server
Centralized
Baseband
Bank
>
2G/2.5G
RAN Servers
>
GSM/GPRS
>
UMTS
>
UMTS Femto GW
>
HeNBGW
>
WiFi Access Gateway
Controllers on
Cloud
Core
Network
>
UMTS
>
HSPA
>
LTEeNB
>
LTE-A
Remote
Radio Head
Coax
IP
IP
Optical
Macro
Site
Femto
Cells/
WiFi
Internet
IP
3 Cloud RAN
part of the base station, the latter of which is supported by the
Remote Radio Heads (RRH).
A separate RRH is required for each frequency band to support
multiple frequency bands and multiple sectors in a given
geographical area. The number of RRH required proportionally
increases, and in many of the macrocell deployments, RRH is
in the top of the cell tower with the antenna to reduce the RF
loss. In denser network deployments, increasing the number of
RRH may not be feasible in all deployments, so RRH may have
to be deployed on high-rise buildings, etc. This increases the
overall cost, RF loss, and maintenance costs.
Multi-band RRH (MB-RRH) are supported by multiple vendors
for addressing the issues mentioned above. It can support
multiple frequency bands and multiple technologies like GSM,
WCDMA, and LTE in combination with the RRH units. This reduces
the number RRH required to support multiple frequency bands
and diferent technologies, while reducing the cell site costs,
power consumption, and complexity.
Centralized Baseband Units
In typical macrocell deployments, the baseband unit is located
at the base of the cell tower along with the radio and other digital
equipment. The cost of deploying new baseband units along
with radios, antennas, etc. to support additional carriers, spectral
bandwidth, different technologies, etc. and managing the
heterogeneous network is becoming economically challenging
and unsustainable.
The centralized baseband is built on the concept of Software
Defined Radio (SDR) with use of distributed radio signal
processing and baseband processing units, which are software
congurable and reduce the complexity of deploying BBU at
the location of the cell site. The increase in additional carriers,
spectral bandwidth, new technologies, etc. can be seamlessly
supported by stacking a number of baseband units in the
baseband pool and deploying remote MB-RRH and AAA with
comparatively less cost and easy maintenance.
The baseband and radio signal processing is distributed using
the CPRI interface between BBU and remote radio equipment.
The Common Public Radio Interface (CPRI) is an industry
cooperation aimed at dening a publicly available specication
for interface between the Radio Equipment Control (REC) and
the Radio Equipment (RE), which in our case is the BBU and
Remote Radio Head respectively. The scope of the CPRI
specication is restricted to the link interface only (layer 1 and
layer 2), which is basically a point-to-point interface. The Open
Base Station Architecture Initiative (OBSAI) was introduced
to standardize interfaces separating the Base-Station server
and the radio part of the base station. Figure 2 depicts a CRAN
architecture utilizing CPRI or OBSAI interface.
Key features of this architecture (Architecture A) are:
> Cells are distributed across processors and exibly connected
to radio unit through high bandwidth (order of Gbps) optical
ber links
> Board level, link level redundancy could be provided
> High-speed communication across sectors for efficient
inter-cell information sharing for cooperative/coordinated
Figure 2: CRAN Architecture A: Utilizing CPRI/OBSAI Link
Unit
Cloud RAN Unit High Speed
CPRI/OBSAI link over Fiber
Unit M
RRC, S1-AP, X2-AP, RRM, SON
CPRI/OBSAI Engine
Layer 2
- Cell 1
Layer 2
- Cell n
Layer 2
- Cell 1
Layer 2
- Cell 2
Layer 1 -
Layer 1 - Layer 1 -
RRC, S1-AP, X2-AP, RRM, SON
CPRI/OBSAI Engine
Layer 2
- Cell 1
Layer 2
- Cell n
Layer 2
- Cell 2
Layer 1 -
Layer 1 - Layer 1 -
4 Cloud RAN
radio resource management, scheduling, and power control
to optimize cell throughput and interference reduction
> Reduced need for hardware at antenna sites
> Utilizes optical links where already available to avoid laying
new links, which may make infrastructure expensive
The main disadvantage of this approach is the high-bandwidth
link required between radio equipment and the central unit.
For example, CPRI supports diferent line-bit-rate options ranging
from 614 Mbps to 6.14 Gbps. Overlaying such high-bandwidth
connections is a costly prerequisite and can be a big barrier to
this solution becoming popular. To overcome this problem, if
the split between radio equipment and control unit can be moved
higher up the network stack (i.e., from below Layer 1 to between
Layer 1 and Layer 2), then instead of sharing IQ samples, only
the demodulated and decoded data and protocol information
need to be shared over an IP-based link between the remote
unit and the central unit. This considerably reduces the
bandwidth requirement to approximately 200 Mbps for a 2x2
MIMO, 20 MHz cell. Figure 3 depicts CRAN Architecture utilizing
IP link between radio unit and the central unit.
Key features of Architecture Option B are:
> Cloud RAN unit is connected with relatively low-bandwidth
(order of 100 Mbps) IP links to Radio equipment siteIP
connectivity should be through operator-managed network
so that there is strict control over latency and jitter
> Antenna site terminates IP links and carries out Layer 1
processing according to air Interface timing
> Layer 3 and Layer 2 located in Cloud RAN unit. To handle
impact of latency of IP link on 1ms, strict scheduling of LTE
and modication in MAC will be required. A portion of MAC
should also run in the baseband unit in the antenna site to
control the time-critical L1 interface and relay messages
between Cloud MAC and antenna Layer 1.
> High-speed communication across sectors for efficient
inter-cell information sharing for cooperative/coordinated
radio resource management, scheduling, and power control
to optimize cell throughput and interference reduction
The main advantage of option B is it requires cheaper and lower
bandwidth IP links between the cell site and central unit. However,
the cell site will require more hardware compared with option
A because Layer 1 and some part of Layer 2 are being executed
in the cell site. In addition, the end-to-end latency increases due
to IP link delay and variance characteristics.
BBU POOLING:
The pooling of processing resources for multiple cell sites at a
central location (utilizing architecture option A or B) has many
benets. Based on the capacity, coverage, and number of air
interface technologies to support, additional BBU can be easily
added and remotely managed. The cell sites need to have only
RRH and antennas; this reduces the huge space, power
consumption, and management overheads of the cell site.
KEY BENEFITS OF BBU POOLING
Capex and Opex reduction
The hardware can be pooled across multiple cell sites in order
to reduce the initial capital costs, as well as regular running
(electricity, site rental, etc.) and maintenance costs.
Figure 3: CRAN Architecture B: IP Link between Cloud RAN Unit and Antenna Site Equipment
Cloud RAN Unit 1
Cloud RAN Unit M
High Speed
Delay
IP Link
RRC, S1-AP, X2-AP, RRM, SON
IP Link
Layer 2
- Cell 1
Layer 2
- Cell n
Layer 2
- Cell 2
Antenna Site 1
Antenna Site N
Layer 2
- Cell 1
Site Management
IP Link
MAC
(partial)
MAC
(partial)
MAC
(partial)
Layer 1 -
Layer 1 - Layer 1 -
5 Cloud RAN
Load Aggregation and Balancing:
Baseband processing for multiple cell sites is aggregated based
on the bandwidth requirement not increasing the number of cell
sites. The BBU units can be dynamically distributed to diferent
cell sites based on the usage patterns.
Multiple Technologies Support
The BBU units can be dynamically congured to support diferent
air interface technologies based on network load and service
requirements.
High Availability
The BBU pool has number of BBU units. During the failure of
any single BBU, other active BBUs can share the load of the
failed BBU, so that it can seamlessly recover. During multiple
BBU failures, the active BBU units can be dynamically congured
to share trafc loads from a number of cell sites supported by
the BBU pool.
Cooperative Multi-point Operation (CoMP)
The BBUs connected to different cell sites are located in a
centralized location, allowing the cell site information related
to signaling, trafc data, resource allocation, channel status,
etc. can be easily shared between BBUs. This information can
be used to optimize the allocation of resources, handovers, call
handling, scheduling for Inter Cell Interference Control (ICIC)
and improve spectral efciency. The CoMP and ICIC are the key
requirements of the LTE-A in the 3gpp Rel-11 specifications.
Because the BBUs support macrocells and small cells, the
coordinated multi-site processing helps optimize the mobility
and ICIC between heterogeneous networks.
SON Support
The shared information of BBUs can be used for advanced
SON features to optimize the various services. The SON can
dynamically configure resources to be used for the cell site
processing, optimize the handover between cells, manage
inter-RAT handovers, conduct cell-load balancing, and efciently
use HW resources. During very low load conditions, some of
the BBUs can be switched of to save energy and help achieve
green BTS.
Metrocells
As mentioned before, adding more macro cells to support
increased capacity and coverage is not an optimal solution. In
an efort to reduce the load on the macrocells, and to provide
higher capacity and greater coverage, operators are deploying
offloading solutions where the macrocells are offloaded to
lowcapacity, lowpower small cells called metrocells.
The metrocells can be deployed on lamp posts, buildings, etc.
and are connected to the operator core network through the
IP backhaul. These cells can be deployed in both indoor and
outdoor environments.
This provides an economically viable solution for the operator
to increase cell density with less cost, efcient spectrum usage,
and less time taken to extend capacity and coverage.
Radio Network Controllers on Cloud
As dened by NIST, cloud computing is a model for enabling
ubiquitous, convenient, on demand network access to a shared
pool of configurable computing resources (e.g., networks,
servers, storage, applications, and services) that can be rapidly
provisioned and released with minimal management efort and
service provider interaction.
The radio network controllers in the cloud RAN solution are built
using this cloud-computing model to support GSM BSC, UMTS
RNC, HeNB-GW, MME, WiFi-GW functions with increased capacity,
in addition to multiple technologies. This cloud computing
model can also be extended to CN elements for supporting
flexible open architecture to increase capacity, different
technologies, efective reuse of resources, and high availability.
Traditionally, radio access network controllers like BSC,
RNC, H(e)NB-GW, etc. are built on specific hardware with
customization. The controller application can only run on specic
hardware and software solutions, and are built for supporting
estimated capacity. The available resources are never used to
their full capacity, which increases the TCO, time to market,
and dependency on specific hardware and software vendor
solutions.
Software as
Service (SaaS)
Platform as
Service (PaaS)
Infrastructure
as Service
Cloud Computing Service Models
End Application like
controller applications
Application platform or
middleware as a service
Cloud HW, CPU, Core,
Disks, Fabric
Figure 4: Cloud Computing Service Models
6 Cloud RAN
Cloud computing architecture denes three diferent service
models, as shown in the Figure 5 below, where COTS solutions
can be used in diferent service layers to avoid using customized
hardware and software solutions from specic vendors.
The radio network controller applications in the cloud computing
environment still need all the software and hardware layers as
in the traditional telecom equipment. But hardware virtualization,
OS abstraction layers, and middle layers are provided to the
application through virtual service layers so that it can remain
independent of underlying hardware and software components.
Cloud computing is in the very early stages of adaption in the
telecom controller space. Using controller applications as SaaS
on the diferent vendor PaaS and IaaS is still a common interface
supported by multiple vendors that is still evolving. The standard
bodies like NIST and ETSI are working to define a standard
interface for the diferent service layers.
Per NIST, generally, interoperability and portability of customer
workloads is more achievable in the IaaS service model because
the building blocks of IaaS oferings are relatively well-dened
(e.g., network protocols, CPU instruction sets, legacy device
interfaces, etc.).
The IaaS layer is supported by multiple vendors through their
COTS virtualization solutions. A hypervisor called the virtual
machine manager provides hardware virtualization so that
multiple operating systems are able to run concurrently on a
host computer. The virtual hardware is called a virtual machine
and the operating system it runs is called the guest. Each guest
OS instance running on VM acts as an individual server for the
application. The diagram below shows the overview of the
virtual servers.
A virtual machine (VM) is a software implementation (i.e., a
computer) that executes programs like a physical machine.
Virtual machines are separated into two major categories based
on their use and degree of correspondence to any real machine.
A system virtual machine provides a complete system platform
that supports the execution of a complete operating system
(OS), while a process virtual machine is designed to run a single
program and support a single process.
A system virtual machine (virtual hardware), which provides
an abstraction of a simple x86 PC with private CPU, memory,
network interface (NIC), and le system, is used for controller
virtualization. Each VM is independent of the VMM and other VMs.
When the number of VMs increases complexity of I/O trafc, and
hardware handling in VMM increases, application handling
signicantly slows down compared with a non-virtualization
environment.
The PCI-SIG has dened a standard for how to virtualize SR-
IOV (Single Root I/O Virtualization) where a physical device
implements hundreds of images of itself, one for each VM.
Each VM communicates with its own set of I/O queues, which
can directly use the device without the performance cost of
going through a VMM while ensuring isolation between the VMs.
Figure 5: Virtual Servers
Before: 3 diferent servers for 3
operating systems and services
After: Only 1 server required for 3
diferent operating systems
and services
Hardware
OS OS
App App
DOM U
OS OS
App App
Hardware
OS OS
App App
DOM U
OS OS
App App
Hardware
OS OS
App App
DOM U
OS OS
App App
H
a
r
d
w
a
r
e
H
a
r
d
w
a
r
e
H
a
r
d
w
a
r
e
H
a
r
d
w
a
r
e
7 Cloud RAN
VMware supports this technology with its ESXi VMM called the
VMDirectPath. The VMDirectPath I/O allows a guest operating
system on a virtual machine to directly access physical PCI
and PCIe devices connected to a host. Each virtual machine can
be connected to up to two PCI devices. PCI devices connected
to a host can be marked as available for pass-through from the
hardware advanced settings in the conguration for the host.
Intel and AMD support hardware-based assistance for I/O
virtualization processes and complement single-root I/O
virtualization. Intels name for this technology is VT-d, while
AMDs version is ADM-Vi.
The controller applications in the cloud environment are based
on third-party IaaS layer interfacing with guest OS/virtual
machine or IaaS in the service-layer hierarchy. All software layers
like guest Os, middle layers, controller-specic OAM, controller
application, etc. which are above IaaS are provided by TEMs.
The guest OS can be any standard OS like Linux, VxWorks,
Solaris, etc. depending on the application architecture.
The virtual server/cluster management is part of third-party
IaaS solutions. This provides the mechanism to manage the
virtualization environment, control the execution of the virtual
machine, and loading the associated applications. Some of the
key functionalities supported by virtual machine management are:
> Centralized control and deep visibility into virtual infrastructure
(create, edit, start, stop VM)
> Proactive management to track physical resource availability,
conguration, and usage by VMs
> Distributed resource optimization
> High availability
> Scalable and extensible management platform
> Security
There are multiple vendors supporting centralized control at
the diferent levels in the virtualization environment. The VMware
vCenter is one such solution that supports scalable and
extensible management platforms as shown in the diagram
on the next page.
The operator can host the controller application software on
the operators own private cloud or on a service providers cloud
(community or public).
Using a cloud computing environment for radio network
controllers has the following advantages:
Hardware Independence
Controller software can run on COTS hardware available from
different HW vendors, hence no binding with customized
hardware solutions. Diferent applications can run on the same
hardware so that available resources can be used on demand.
Software Independence
Application software can run on COTS virtual machines available
from diferent vendors as IaaS. The application is independent of
the actual hardware used, so it can run on diferent hardwares
with no application software changes. There is also no proprietary
software supporting hardware independence.
Resource Pooling
The different hardware types can be pooled to run multiple
instances of application software to support increased capacity.
The resources can be dynamically allocated, with different
applications running on the same hardware.
High Availability
Using pooled resource to run controller applications takes care
of single or multiple units failing within a pool of resources,
while providing geo-redundancy, multi-tenancy, and elasticity.
Reduced CAPEX
Usage of the COTS hardware and software reduces TCO and
time to market. Reuse of available resources with dynamic
allocation helps use the full capacity of the resources, thus
reducing the number of resources required.
Reduced OPEX
Use of common hardware and software reduces the cost of
managing diferent customized solutions. The resource can be
afectively used depending on the load conditions. Based on
demand, some of the resources can be switched of in order
to reduce electricity and other infrastructure costs (e.g.,
cooling, etc.).
Elasticity, Best of Class Performance
The capacity of the system can change quickly according to
need. The controller applications (RNC, BSC, etc.) run in virtual
machines independent of the physical hardware. Third-party
virtualization technology from diferent vendors can be used to
host the application-specic OS, middleware, and applications.
There are multiple vendors providing the virtualization IaaS
layer. Some of the key solutions are VMware, KVM, and WR
hypervisor.
8 Cloud RAN
Multiple applications can run on the single platform with diferent
VMs running different OSs using a multi-tenant model. In a
multi-core environment, different applications can run on a
diferent core with associated VM, guest OS, middle layer, and
applications. The diferent controller applications allow common
cloud computing architecture to dynamically use available
resources.
Common Management Server
As previously mentioned, operators use more than one RAT to
support wireless data trafc demand. The converged solutions
AAA, RRH, multi-standard BBUs, and radio network controllers
are used to support multiple technologies. Management of these
converged network elements requires a common management
server capable of supporting the FCAPS features for GSM,
UMTS, and LTE network nodes.
SON Functions
In cloud RAN network architecture, each network element is
capable of supporting self-configuration, optimization, and
autonomous recovery. SON, in this architecture, is based on
decentralized algorithms as applicable at each individual network
element. The operator may support multiple technologies like
GSM, WCDMA, and LTE in the cloud RAN deployment. This
requires network-level self-optimization to support automatic
updates of network topology changes between E-UTRAN/
UTRAN/GERAN networks.
Information related to network load, performance, etc. of the
diferent wireless technologies is used by the centralized function
to dynamically allocate shared resources to diferent network
elements in the cloud RAN and support load balancing. For
example, when the GSM load is less but the UMTS is in the peak,
the shared NEs like AAA and RRH can be congured to support
additional cells, frequency bands, etc. When the network load is
low, the set of network elements can be switched of wherever
the load can be handled by a minimum set of network elements.
Conclusion and Aricent Value
Proposition
As discussed in the previous sections, the complexity of
enhancing traditional networks to support increasing broadband
capacity and coverage is not economically viable. There is
immediate need to deploy distributed networks with centralized
Figure 6: Controller Application Over IaaS layer
Diferent Applications, middle layer, OAM, etc.
An example of radio controller application on cloud environment is shown in the following diagram:
VMM
BSC RNC
M/W M/W
Guest OS Guest OS Guest OS
H(e)NB-
GW
M/W
COTS VM Manager
COTS SW/HW
VM V-10
Guest OS
VM
VM Disk
V-10
Virtual
HW
Hypervisor
Physical Hardware (Servers or ATCA)
Virtual
HW
Virtual
HW
Guest OS VM Disk
VM V-10
Guest OS
VM
VM Disk
V-10
Guest OS
Core OS Disk
Fabric HW IO HW
Disk Disk
CPU
CPU
VM Disk
9 Cloud RAN
baseband units, RRHs, AAA, and radio network controllers on
the cloud to reduce the complexity of introducing addition cell
sites and adding additional antennas and radio components.
The Radio network controllers on the cloud environment using
virtualization technology reduce the infrastructure cost to
support both multiple technologies and the complexity of
managing multiple network elements.
In the 3rd Generation Partnership Project (3GPP) international
standardization group meeting held in June, 2012, energy
saving, cost efciency, and support for diverse application
and trafc types were identied as priority areas for Release
12. Deploying a cloud RAN architecture-based network can
address these requirements. The NGMN group also initiated a
CENTRALISED PROCESSING, COLLABORATIVE RADIO,
REAL-TIME CLOUD COMPUTING, CLEAN RAN SYSTEM
(P-CRAN) [11] project to address these issues.
Implementation of a cloud RAN solution can save CAPEX up
to 15 percent and OPEX up to 50 percent over five to seven
compared with traditional RAN deployment, per the China
Mobile report [1]. According to the Alcatel-Lucent Light Radio
Economics analysis [2], these disruptive RAN architecture
designs and innovative features can reduce overall TCO by at
least 20 percent over ve years for an existing high-capacity
site in an urban area with at least 28 percent reduction for
new sites.
Aricent is actively participating in and following emerging C-RAN
architecture initiatives. Aricent eNodeB, EPC, and HeNB-GW
IPRs are ready for CRAN architecture.
eNodeB Framework
> RAN on the cloud must cater to variable capacity
requirements and host multiple cells. Aricent Layer 3 and
Layer 2 including Scheduler, MAC, RLC, PDCP, GTPU, are
scalable for multi-core architectures, support multiple
form factors (femto, pico, micro) and different capacity
requirements based on deployment.
> Single instance of Aricent Layer 3 can handle multiple cells/
sectors hosted on cloud RAN equipment and can interface
with cells/sectors hosted on other cloud RAN equipment
on the X2 link.
> Aricent Layer 2 can handle one cell/sector per instance
and multiple instances of Layer 2 can be utilized to handle
multiple cells/sectors.
> eNodeB software is modied to handle IP link (architecture
option B described previously) interface between cell site
unit and the central unit.
Enhanced Packet Core Modules
> RAN on the cloud must cater to variable capacity
requirements and host multiple cells. Aricent Layer 3 and
Layer 2 including Scheduler, MAC, RLC, PDCP, GTPU, are
scalable for multi-core architectures, support multiple form
factors (femto, pico, micro) and different capacity
requirements based on deployment.
> Single instance of Aricent Layer 3 can handle multiple cells/
sectors hosted on cloud RAN equipment and can interface
with cells/sectors hosted on other cloud RAN equipment
on the X2 link.
> Aricent Layer 2 can handle one cell/sector per instance and
multiple instances of Layer 2 can be utilized to handle
multiple cells/sectors.
> eNodeB software is modied to handle IP link (architecture
option B described previously) interface between cell site
unit and the central unit.
Universal SON Server (UniSON)
> RAN on the cloud must cater to variable capacity
requirements and host multiple cells. Aricent Layer 3 and
Layer 2 including Scheduler, MAC, RLC, PDCP, GTPU, are
scalable for multi-core architectures, support multiple form
factors (femto, pico, micro) and different capacity
requirements based on deployment.
> Single instance of Aricent Layer 3 can handle multiple cells/
sectors hosted on cloud RAN equipment and can interface
with cells/sectors hosted on other cloud RAN equipment
on the X2 link.
> Aricent Layer 2 can handle one cell/sector per instance and
multiple instances of Layer 2 can be utilized to handle
multiple cells/sectors.
> eNodeB software is modied to handle IP link (architecture
option B described previously) interface between cell site
unit and the central unit.
10 Cloud RAN
Additionally, Aricent is involved multiple services projects related
to solution architecture, implementation, and eld support of
C-RAN solutions. This includes Tier 1 OEMs in the area of multi-
RAT BTS, virtual common hardware for RNC/BSC solutions,
etc. Aricent is well-equipped to provide software frameworks,
(eNodeB, EPC etc.), necessary resources, management framework
and a strong delivery process to assist our customers for their
own C-RAN solution.
REFERENCES
(1) http://www.google.com/url?sa=t&rct=j&q=china+mobile+c-ran&source=web&cd=1&ved=0CE0QFjAA&url=http%3A%2F%2Flabs.
chinamobile.com%2Farticle_download.php%3Fid%3D63069&ei=ebXyT6uBAc7LrQfRnK2rCQ&usg=AFQjCNFDC6S_4Oth6_0vLobNzvfvrlouHw
(2) http://www.alcatel-lucent.com/wps/DocumentStreamerServlet?LMSG_CABINET=Docs_and_Resource_Ctr&LMSG_CONTENT_FILE=White_
Papers%2FlightRadio_WhitePaper_EconomicAnalysis.pdf&REFERRER=j2ee.www%20%7C%20%2Ffeatures%2Flight_radio%2Findex.
html%20%7C%20lightRadio%3A%20Evolve%20your%20wireless%20broadband%20network%20%7C%20Alcatel-Lucent
(3) http://www.vmware.com/products/vcenter-server/overview.html
(4) http://www.vmware.com/products/vsphere/mid-size-and-enterprise-business/overview.html
(5) http://www.obsai.com/obsai/content/download/4977/41793/le/OBSAI_System_Spec_V2.0.pdf
(6) http://www.cpri.info/downloads/CPRI_v_5_0_2011-09-21.pdf
(7) http://csrc.nist.gov/publications/drafts/800-146/Draft-NIST-SP800-146.pdf
(8) http://collaborate.nist.gov/twiki-cloud-computing/pub/CloudComputing/RoadmapVolumeIIIWorkingDraft/NIST_cloud_roadmap_VIII_
draft_110311.pdf
(9) http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
(10) http://www.umts-forum.org/component/option,com_docman/task,doc_download/gid,2545/Itemid,213/
(11) http://www.ngmn.org/workprogramme/centralisedran.html
Universal SON Server
SON Client
EMS
ENODEB
TR69,
2014 Aricent. All rights reserved.
All Aricent brand and product names are service marks, trademarks, or registered marks of Aricent in the United States and other countries.
frog, the global leader in innovation and design, based in San Francisco is part of Aricent.
The companys key investors are Kohlberg Kravis Roberts & Co. and Sequoia Capital.
info@aricent.com
Aricent is the worlds premier engineering services and software company.
We specialize in inventing, developing and maintaining our clients most ambitious
initiatives. Combining more than 20 years of engineering expertise with a force of more
than 10,000 dedicated product engineers, Aricent is the only company in the world that
list of global companies, bringing the next generation of breakthrough, innovative
products to market.