radio access network (ran) virtualization - cld.pt · ran-as-a-service . lúcio ferreira (1), navid...

39
© 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

Upload: buique

Post on 06-Jul-2018

217 views

Category:

Documents


0 download

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]

Presenter
Presentation Notes
60% network costs come from RAN (site rental, energy, maintenance). still, traffic varies strongly geographically and temporally (20% of BS carry 50% traffic, while 50% of BSs generate 10% revenue). in Orange France LTE backhaul, 86% of sites (in blue) within 10 km of central offices (in green). Central offices are connected up to 28 sites.

© 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.

Presenter
Presentation Notes

© 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

Presenter
Presentation Notes
cheap and small RRHs in almost infrastructure-less sites, with all the digital processing being elastically supported by cloud-based data-centres 1/3 roll-out time Reduction of 15% CAPEX and 50% OPEX 71% energy saving

© 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.

Presenter
Presentation Notes
most critical parameter: 3ms UL sync HARQ loop target latency If the UE receives no ACK/Nack in UL -> retransmission

© 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

Presenter
Presentation Notes
processing in hardware is faster

BBU Processing Load

© 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

Presenter
Presentation Notes
leading to expect different processing requirements for downlink and uplink at the eNB. Common for all users: (e.g., OFDM signal generation) per user: (e.g., modulation and coding).

© 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

Presenter
Presentation Notes
for 20 MHz UL is unrealistic MCS > 17

© 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

Presenter
Presentation Notes
Min use: one PRB per subframe Full use: all PRBs per subrame

© 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

Presenter
Presentation Notes
Min use: one PRB per subframe Full use: all PRBs per subrame

© 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

Presenter
Presentation Notes
KVM enables to virtualize cores

Profiling Different Virtualisation Environments

© 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)

Presenter
Presentation Notes
On UL KVM has longer tail (worse performance) On DL KVM has higher

© 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)

Presenter
Presentation Notes
RT-OAI: kernel is low latency and OAI process is prioritised Example processing times at the UL eNB for BW=20MHz, MCS=16 UL is most time consuming (decoding)

© 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)

Presenter
Presentation Notes
RT – OAI, kernel is low latency and OAI process is prioritised RTLinux: no virtualisation, low latency kernel, prioritised prcesses

© 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

Prototype of RANaaS

© 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.

Presenter
Presentation Notes
Resource provisioning: Uses HoT to call Nova, Glance and Neutron to build the heat stack OpenStack has drives for KVM, LXC, Docker, etc. configurable for the user LXC provides a VE in Openstack. LXC builds a container in the OS where components’ images are put. OpenStack deploys it, creating dedicated directories, and starts the containers. Binaries in the container are natively executed in the kernel by the host.

© 2012-2015 MCN. All rights reserved. / Page 34

RANaaS Prototype OAI LTE Virtual eNB and EPC

Presenter
Presentation Notes
LXC and OS delay Speed of virtual L2\L3 interface (nmeasures at layer 3)

© 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.

Presenter
Presentation Notes
Heat template does not know anything about virtualisation Region of the cloud specifies that it will use LXC. It is hard encoded.

© 2012-2015 MCN. All rights reserved. / Page 36

Heat orchestrator is key, in the life cycle.

RANaaS Prototype Message Sequence

Presenter
Presentation Notes
Heat orchestration Template (HoT)

© 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).

Presenter
Presentation Notes

© 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.

Thank You For Your Attention