© 2012-2015 MCN. All rights reserved. /

Outline

Motivations and Objectives

MCN Quick Overview

Challenges for an on demand RAN

A PaaS Approach for RANaaS

Conclusion


Motivations for Virtualizing

Networks

Flexible Network Operations

Flexible resource allocation

analytics tools for dimensioning the network

Automated Network operation

auto-scaling

less trouble shooting by use of automatic configurations and isolation between tenants

Faster Speed of Time to Market

Cost efficiency

sharing hardware => reduced power and space consumption

non proprietary hardware

installation, maintenance and removal costs reduction

flexible and automated network operations

multi-tenancy


Motivations: Focus on RAN

Today’s Radio Access Networks (RANs) have a large number of Base

Stations (BSs), of multiple Radio Access Technologies (RATs), of high

power consumption and

cost (CAPEX/OPEX).

Explosive capacity needs vs. falling revenues per user.

RAN is typically dimensioned for the busy hour;

still, offered load varies drastically, with large periods of low utilisation.

BSs

BSs

BSs

Backhaul

Network

Core

Network


Outline


MCN Quick Overview



Conclusion


The EU FP7 European Mobile Cloud

Networking Project

European collaborative project FP7.

Started in Nov. 2012. End: Oct. 2015

http://www.mobile-cloud-networking.eu/site/

Who?

Objective: to offer on demand a mobile network


MCN FP7 Objective: RAN as a

Service

To offer a cloud-based RAN as a Service (RANaaS): Heterogeneous, virtualised and multi-tenant RAN, following cloud

principles (infrastructure sharing, elasticity, on-demand, pay-as-you-go).

Dynamically adapted to geographic and temporal load variations and traffic type.

Centralised RAN processing architecture, based on virtualised pools of Base Band Units (BBU-pools) on datacentres.

Flexible relationship between Remote Radio Heads (RRHs) and BBUs, linked by a high bandwidth and low-latency optical fronthaul network.

Fronthaul

Transport

Network

Central Office

Datacentre

BBU-pool

RAT 2

BBU-pool

RAT 1

BBUs

...

RRHs

RRHs

RRHs

Backhaul

NetworkCore

Network


Outline


MCN Quick Overview



Conclusion


Challenges for RANaaS

Fronthaul transport network (between BBUs and RRHs)

High bit-rate CPRI links:– Site with 3 RRHs (LTE, 20MHz) requires 7.4 Gbit/s link.

Low latency:

– Maximum round trip delay of 150µs (~15 km optical fibre).

Jitter and synchronisation:– Stringent requirements for frequency and phase synchronisation

Real-time performance

base stations requires strict real time performance

– e.g., air interface LTE L2 packets to be handled in 3.66 ms


Challenges for RANaaS

Offer cloud based multi-tenant on demand RANaaS:

Offer SLA-guaranteed connectivity to multiple tenants (MVNOs)

through an elastic on-demand allocation of resources.

on demand => dynamic spectrum management

– Detect and predict resources usage to optimize the offered services.

Datacentre

D-RoF

Optical

switch

RRHs

RRHs

RRHs

BBU-pool

RAT 1

BBU-pool

RAT 2

BBU-pool

RAT N

WC-Pool

(in a data centre)

Fronthaul

Transport

NetworkRadio

Interface

Backhaul

Transport

Network

Core Network

Radio Access Network

Radio

resources

Fibre optic

resources

Computational

resources

BBU-pool

RAT 2

BBU-pool

RAT 1

BBUs

...

Virtual radio

resources

MVNO

Gold

2 Mbps to

all users

MVNO

Cheap

Best effort

for all users

RRHs

RRHs

Remote

Radio

Heads

(RRHs)


Worker

Worker

Challenges for virtualized RAN

Elasticity

by means of horizontal scalability and load balancing

LTE air interface protocols are not RESTful

Load

BalancerWorker

=>so you cannot simply add an

HTTP load balancer and add VM

hosting http servers for handling

LTE workload

=>need for redesigning the base

station software to make it

horizontally scale


Outline


MCN Quick Overview



Conclusion


A Platform as a Service for Mobile

Network

PaaS allows service providers to host and execute web applications using

third-party managed servers

e.g., Google App Engine, OpenShift

A Mobile Network using PaaS allows mobile network service providers to

host and execute network functions using a third party infrastructure


Platform as a Service by Google

[Octo.com]

A user uses the service via the web

--e.g., a web app to manage post-its

with your wife/husband/child(ren)

Google

- hosts the application software,

runs it, provides means to improve it

and log s on the service delivery

- and charges you

the developer

-designs the service using the

Google SDK and pushes the related

code to Google App Engine

http://blog.octo.com/panorama-des-differentes-offres-de-cloud-computing-google-app-engine/


Platform as a Service for RANaaS


RANaaS: Architecture

Design cloud-based RANaaS architecture, supported by a set of functional elements:

based on MCN architecture reference model– Service manager (SM): interface to client,

– Service Orchestrator (SO): In charge of the RANaaS lifecycle

– Cloud Controller (CC): Providing physical resources for RANaaS

using support services– Monitoring, charging, SLA management, analytics

Plus RAN virtualized network functions– LTE Base station protocol stacks broken down to enable

– fine mapping between layers processing requirements and physical resources

– elasticity by balancing the load from UEs on different servers


RANaaS: Architecture


RANaaS: Service lifecycle

Design

Deployment

(load components for an SLA chosen by a client)

Provisioning

(customise)

Runtime management

(scale up/down)

Disposal

(destroy)


MCN architecture under development

RANaaS components

designed by RANP to

instantiate RAN on demand

Support services

used by RANP

VNFs deployed by

RANP for its EEU

Managing lifecycle

of base stations

Use to configure the

base stations


Outline


MCN Quick Overview



Conclusion


Cloud-based RAN is a novel architecture that aims at

bringing cost and efficiency benefits from the cloud

computing model.

MCN aims at offering elastic, scalable, and on-demand

RANaaS, dynamically adapted to geographic and

temporal load variations.

It faces several challenges, regarding:

Fronthaul

Radio resource management

Real-time performance

Scalability

The approach is being developed for further evaluation

Conclusion

Thank You


Fronthaul: Scenarios and Solutions

Fibre availability is already a requirement

in Orange France LTE backhaul:

90% of sites in dense areas have fibre.

96% of links are shorter than 10km.

In urban areas, up to 28 cell sites are

connected to one Central Office.

Several solutions can be

considered for the fronthaul:

One fibre per RRH.

One fibre per site, shared by RRHs with

Wavelength Division Multiplexing (WDM).

Alternatively, microwave links can be used for small radio sites.


Fronthaul: Challenges

Fronthaul transport network (between BBUs and RRHs):

Digital Radio over Fibre (D-RoF).

Using typically the Common Public Radio Interface (CPRI) standard.

Digitation requires high bit-rate CPRI links:

Site with 3 RRHs (LTE, 20MHz) requires 7.4 Gbit/s link.

Site with 15 RRHs (LTE-A (2 bands), 3G (2 bands), 2G (1 band))

requires up to 20Gbit/s link.

Low latency:

Maximum round trip delay of 150µs

(~15km optical fibre).

Jitter and synchronisation:

Stringent requirements for frequency

and phase synchronisation.

D-RoF

D-RoF

Optical

switch

BBU-pool

RAT 1

BBU-pool

RAT 2

WC-Pool

(in a data centre)

Optical

switch/router

Fronthaul

Transport

Network

BBU-pool

RAT 2

BBU-pool

RAT 1

BBUs

...

RRHs

RRHs

RRHs

Centra Office

(datacentre)


Fronthaul: Research

Impact of Mobile Cloud Networking on Fronthaul.

Dimensioning and optimisation of the

optical link between the BBU-pools and RRHs:

Based on realistic network configurations.

To optimise the architecture and have an end-to-end picture.

Reduce required bit-rates on CPRI links:

Several propositions for function splitting between

RRH and BBU will be taken into account.

Support interoperability, multi-technology (2/3/4G, WiFi)

and RAN sharing between different operators.


With few users, only 3 RRH-BBU are sufficient to cover

the service area and provide the requested capacity.

Load Balancing: Motivation Scenario

BBU Plane

End-user Plane

RRH Plane

BBUpool 1

RRH1

RRH2

RRH3

ControllerControl Plane

BBUpool 1

BBU1 (20% load)

BBU2 (30% load)

BBU3 (20% load)


When the number of users increases, more RRHs are

activated, and associated BBUs instantiated on a single

BBU-Pool, to provide the requested capacity.


BBUPool 1

BBU1 (10% load)

BBU2 (10% load)

BBU7 (10% load)

BBU6 (10% load)

BBU5 (10% load)

BBU4 (10% load)

BBU3 (10% load)

RRH1RRH5

RRH7RRH2

RRH3RRH4

RRH6

BBU

Plane BBUpool 1

End-user

Plane

RRH

Plane

Controller

Control

Plane



With a highly loaded network, some BBUs must be

instantiated on a different BBU-Pool, as the load exceeds

the BBU-Pool capacity.

End-user

Plane

RRH1RRH5

RRH7RRH2

RRH3RRH4

RRH6

BBU

PlaneBBUpool 1

BBUpool 2

RRH

Plane

ControllerControl

Plane

BBUPool 1

BBU7 (70% load)

BBU6 (60% load)

BBU5 (80% load)

BBUPool 2

BBU1 (60% load)

BBU2 (80% load)

BBU4 (80% load)

BBU3 (70% load)


Load Balancing: Challenges

Virtualisation of a sub-set of BBU functions, which can

be scaled up and down.

Quantification of the relation between load and

processing needs.

Map user load into required processing of virtualised BBU functions.

Balance RAN processing load between BBU-pools:

Dimension the number of cell sites one BBU-pool can manage.

Account for temporal and geographical variations of load.

Take into consideration radio, fronthaul and datacentre capabilities and

constraints, as well as SLAs (and associated QoS requirements).

Efficiently allocate processing resources (locally or remotely).

Balance load between multiple RATs.

radio access network (ran) virtualization

Documents