radio access network (ran) virtualization - cld.pt · ran-as-a-service . lúcio ferreira (1), navid...
TRANSCRIPT
© 2012-2015 MCN. All rights reserved. / Page 1
Este documento é propriedade intelectual da PT e fica proibida a sua utilização ou propagação sem expressa autorização escrita.
Innovation in the Cloud
January 28-29, 2015 Forum Picoas, Lisbon
RAN-as-a-Service
Lúcio Ferreira(1), Navid Nikaein(2), Eryk Shiller(3), Desislava Dimitrova(3), Islam Alyafawi(3), Sina Khatibi(2),
Dominique Pichon(4), Alexander Georgiev(5), André Gomes(6),
(1) INOV-INESC, Portugal (2) EURECOM, France (3) Univ. of Bern, Switzerland (4)Orange, France (5)Cloudsigma, Bulgaria (6) One Source, Portugal
RAN-as-a-Service Lúcio Ferreira(1), Navid Nikaein(2), Eryk Shiller(3),
Desislava Dimitrova(3), Islam Alyafawi(3), Sina Khatibi(2), Dominique Pichon(4), Alexander Georgiev(5), André Gomes(6),
(1) INOV-INESC, Portugal (2) EURECOM, France (3) Univ. of Bern, Switzerland (4)Orange, France (5)Cloudsigma, Bulgaria (6) One Source, Portugal
Innovation in the Cloud Workshop Lisbon, Portugal, Jan. 2015
© 2012-2015 MCN. All rights reserved. / Page 3
Introduction Cloud-RAN Motivation Scenario Requirements Open Issues and Goals BBU Processing Load Profiling Virtualised Environments Prototyte of RANaaS Architecture Conclusions
Outline
© 2012-2015 MCN. All rights reserved. / Page 4
Introduction (1)
Today’s Radio Access Networks (RANs) face: Increasing capacity needs vs. falling revenues per user. Large base stations deployments of high costs
(CAPEX/OPEX) and power consumption. Resources dimensioned for peak traffic loads. Large fibre availability in urban areas.
[GSMA, The Mobile Economy 2013]
© 2012-2015 MCN. All rights reserved. / Page 5
Introduction (2)
The Mobile Cloud Networking (MCN) project aims to extend the cloud computing paradigm to communication networks, leading to efficient resources’ exploitation.
MCN aims at offering RAN-as-a-Service (RANaaS): Cloud-based, on-demand, elastic, adaptable to load
variations.
© 2012-2015 MCN. All rights reserved. / Page 6
Cloud-RAN (1)
In Cloud-RAN (C-RAN), base stations are split into: Remote Radio Head (RRH), a hardware component. Base Band Unit (BBU), software-based.
RRHs and BBUs are linked by an optical fronthaul. Aims fast, cost- and energy-efficient deployments.
BBUs
RRHs
© 2012-2015 MCN. All rights reserved. / Page 7
Cloud-RAN (2)
Currently, BBUs run on custom dedicated hardware platforms.
RANaaS aims to extend C-RAN by: Taking advantage of general purpose platforms. Integrating virtualisation and the cloud paradigms. Using shared computation, storage and networking
resources of cloud infrastructures.
BBUs
RRHs
© 2012-2015 MCN. All rights reserved. / Page 8
Motivation Scenario (1)
With few users, 3 RRH-BBU pairs cover the service area and provide the requested capacity.
© 2012-2015 MCN. All rights reserved. / Page 9
Motivation Scenario (2)
With more users, extra RRHs are activated and BBUs instantiated, to provide the requested capacity.
© 2012-2015 MCN. All rights reserved. / Page 10
Motivation Scenario (3)
With a highly loaded network, some BBUs must be instantiated on a different DC, as the needed processing resources exceed the BBU-Pool capacity.
© 2012-2015 MCN. All rights reserved. / Page 11
Requirements (1)
To guarantee that the RRH-BBU fibre fronthaul is shorter than 15 km and with a throughput above 20 Gbps.
To satisfy BBU processing requirements in a virtualised environment (processing time of radio frames < 3 ms).
To be able to quantify the relation between traffic load, allocated radio resources and BBU processing needs.
To be able to allocate resources dynamically on-demand, considering temporal and geographical load variations.
© 2012-2015 MCN. All rights reserved. / Page 12
Requirements (1)
To guarantee that the RRH-BBU fibre fronthaul is shorter than 15 km and with a throughput above 20 Gbps.
To satisfy BBU processing requirements in a virtualised environment (maximum allowed latencies).
To be able to quantify the relation between traffic load, allocated radio resources and BBU processing needs.
To be able to allocate resources dynamically on-demand, considering temporal and geographical load variations.
© 2012-2015 MCN. All rights reserved. / Page 13
Requirements (2)
Exceeding LTE latencies results in packet loss and decrease of throughput.
© 2012-2015 MCN. All rights reserved. / Page 14
Open issues: Can a General Purpose Platform (GPP) cloud
infrastructure meet the processing requirements of a software-based BBU?
Can the time constrains of the LTE radio interface be guaranteed in a virtualised environment?
Goals: Profile BBU components to evaluate processing
constraints. Evaluate different virtualised environments. Prototype a RANaaS architecture.
Open Issues and Goals
© 2012-2015 MCN. All rights reserved. / Page 16
BBU has various dimensions and dependencies, characterised by diferent processing loads.
Processing in BBU
Downlink Uplink
PHY
MAC
Usage characteristics – number of users – traffic profile
System characteristics – Bandwidth [MHz] – Modulation and Coding
Scheme (MCS) – number of antennas.
BBU
© 2012-2015 MCN. All rights reserved. / Page 17
OpenAirInterface (OAI) LTE base station emulator: EURECOM’s Open source software implementation of
LTE radio stack. Implements hard real-time requirements. Used as a BBU, enables the evaluation of the various
BBU components.
CloudSigma public cloud scenario: OAI running on a VM on top of a XEON
2.5 GHz CPU and 2 GB of RAM. Host CPU is not dedicated. The hypervisor does not support Real Time (RT)
management nor RT processing.
Evaluation Testbed
© 2012-2015 MCN. All rights reserved. / Page 18
PHY Layer Procedures
Uplink decoding is the most time consuming procedure.
0
1
2
3
4
5
6
0 9 10 16 17 24 27
Proc
essi
ng ti
me
[ms]
MCS Index
Total
Coding
Modul.
Scramb.0
1
2
3
4
5
6
0 9 10 16 17 24 27
Proc
essi
ng ti
me
[ms]
MCS Index
Total
Decoding
Demodulation
OFDM demod.
Downlink / Transmission Uplink / Reception
© 2012-2015 MCN. All rights reserved. / Page 19
PHY Resources Usage
The amount of used PHY resources (one vs. all) strongly impacts the BBU processing.
0200400600800
100012001400
0 9 10 16 17 24 27
Proc
essi
ng ti
me
[µs]
MCS Index
20MHz full use
20MHz min use
10MHz full use
10MHz min use
5MHz full use
5MHz min use
© 2012-2015 MCN. All rights reserved. / Page 20
System Bandwidth
The system bandwidth strongly impacts processing. Reception (RX) is more processing consuming than
transmission (TX).
0
1
2
3
4
5
6
0 9 10 16 17 24 27
Proc
essi
ng ti
me
[ms]
MCS Index
20MHz RX
20MHz TX
10MHz RX
10MHz TX
5MHz RX
5MHz TX
© 2012-2015 MCN. All rights reserved. / Page 21
MAC and PDCP layers Profiling
MAC is responsible for scheduling users and HARQ. PDCP does header compression and ciphering.
0
100
200
300
400
500
600
1 2 3 4 5 6 7 8 9 10 15 20 25 30
Proc
essi
ng ti
me
[µs]
Number of UEs
PDCP
MAC
MAC processing is dependent on the number of users
© 2012-2015 MCN. All rights reserved. / Page 22
400
800
1200
1600
2000
0 9 10 16 17 24 27
Proc
essi
ng ti
me
[µs]
MCS Index
10GHz
8GHz
6GHz
4GHz
2GHz
Increasing the CPU (KVM enables to virtualise cores), the scheduler will migrate processing among multiple cores, increasing overhead.
Profiling CPU Clock Speed
© 2012-2015 MCN. All rights reserved. / Page 24
Virtual Machine (VM) – e.g., KVM: Virtualisation infrastructure that emulates a physical
computing environment (guest). Managed by a hypervisor running on top of the
infrastructure (host).
Virtualisation Environment (VE) – e.g., LXC and Docker: No hardware emulation nor hypervisor (containers). Bare metal performance characteristics, relying on OS’s
functionalities of the underlying infrastructure.
Virtualisation Flavours
© 2012-2015 MCN. All rights reserved. / Page 25
General Purpose Platform (GPP): dedicated machine. Kernel-based Virtual Machine (KVM): Linux virtualisation
infrastructure that turns it into a hypervisor.
Linux Container (LXC): operating-system-level capability for running isolated Linux Virtual Environments (VE) on a single control host.
Docker: LXC-based portable container engine that encapsulates an application with all its dependencies.
Options: Non-Real Time (NRT) kernel. RT kernel / low latency kernel, prioritization of processes.
Evaluated Environments for BBU Profiling
© 2012-2015 MCN. All rights reserved. / Page 26
Communication between host and guest (LXC, Docker, and KVM) under different traffic patterns.
KVM is worse, has 5 times bigger RTT: It is a problem for connecting to RRHs As well as EPC and eNB, as this delay will be added to
all packet exchange.
Round Trip Time
© 2012-2015 MCN. All rights reserved. / Page 27
DL and UL BBU processing load for various modulations (MCS) and bandwidths (PRB).
GPP, LXC, Docker, and KVM environments with low latency Kernel seem to have similar results.
BBU Processing Load
© 2012-2015 MCN. All rights reserved. / Page 28
% of subframes with delay below processing time. Fully loaded BBU using maximum modulation and 20
MHz bandwidth.
LXC and Docker performance is closer to GPP,
while KVM has more variations.
BBU Processing Distribution (1)
© 2012-2015 MCN. All rights reserved. / Page 29
Results for a different machine settings. KVM is unpredictable, even RT! LXC/Docker performance shall be similar to RTLinux.
BBU Processing Distribution (2)
© 2012-2015 MCN. All rights reserved. / Page 30
Results for a different machine settings. KVM is unpredictable, even RT! LXC/Docker performance shall be similar to RTLinux.
BBU Processing Distribution (2)
© 2012-2015 MCN. All rights reserved. / Page 31
LXC/Docker proved to provide a bar metal performance: Exploit native Linux Features. Does not require a hypervisor. Lightweigth, lower overhead and potentially better
performance. LXC/Docker ecosystem: Growing popularity, promising! Integration with OpenStack.
Limitation: Does not support multi-OS. Require support from the host OS.
Design Choices for Virtualisation
© 2012-2015 MCN. All rights reserved. / Page 33
Prototype Architecture
Based on a Heat orchestration Template (HoT), Heat orchestrator uses OpenStack control plane to build Heat stack, a composite environment (web services, HSS, EPC and eNB). LXC provides a VE in OpenStack. environment.
© 2012-2015 MCN. All rights reserved. / Page 34
…
RANaaS Prototype OAI LTE Virtual eNB and EPC
© 2012-2015 MCN. All rights reserved. / Page 35
HSS, EPC, eNB, …
Virtual networks, router, firewalls, …
Heat Template
= Heat Template
Cloud orchestration tool that allows to create big cloud deployments.
The Heat orchestration Template (HoT) is amazing! The instantiation of a whole system (e.g., an LTE
ecosystem) can be easily achieved with it.
© 2012-2015 MCN. All rights reserved. / Page 36
Heat orchestrator is key, in the life cycle.
RANaaS Prototype Message Sequence
© 2012-2015 MCN. All rights reserved. / Page 37
Future RANaaS Prototype
When RT hypervisors appear, we can change LXC into them (e.g., RT-ZEN shall be tried).
© 2012-2015 MCN. All rights reserved. / Page 38
Conclusions
RANaaS aims to integrate virtualisation and cloud paradigms.
C-RAN software-based base-stations (BBUs) have critical processing requirements.
The feasibility to run a single BBU on a GPP platform was evaluated using OAI LTE base station emulator: BBU processing has multiple dependencies, the heaviest
being uplink decoding. LXC and Docker are lightweight virtualization
environments that outperform KVM. A prototype of RANaaS was presented, based on Heat,
OpenStack and Linux Containers. It is a promising approach.