Optical 5G Transport: Challenges

and Opportunities
Paolo Monti
Optical Networks Lab (ONLab)
Communication Systems Department (COS)
KTH Royal Institute of Technology
Stockholm (Sweden)

ANNUAL INTENSIVE PHD TRAINING COURSE (AITC) – Marie curie project ICONE
 Acknowledgements

• Matteo Fiorani (KTH)

• Björn Skubic (Ericsson)
• Jonas Mårtensson (Acreo Swedish ICT)
• Sibel Tombaz (Ericsson)
• Rehan Raza (KTH)
• Ahmad Rostami (Ericsson)
• Peter Öhlen (Ericsson)
• Lena Wosinska (KTH) Kista 5G Transport Lab
Sponsors: E/// and VINNOVA

2
 Outline

ØTransport service evolution from 4G to 5G

ØTransport challenges in the new 5G services paradigm
ØProgrammable and flexible transport infrastructure
ØUse case: C-RAN architecture
o Impact of different resource abstraction policies
o Benefits of dynamic resource sharing

ØData plane options for NFV

ØConclusions

3
 Mobile networks evolution

Ø What can we expect from next generation of mobile networks?

Ø 5G vision:
o user- and machine-centric communications where access to
information is available anywhere and anytime to anyone and
anything, the so called Networked Society*

4
http://www.ericsson.com/thinkingahead/networked_society
*
 What is a transport networks?

Ø Transport network is the segment connecting the base stations (eNodeB)

with their peering point in the Evolved Packet Core (EPC)

o mobility management (MME), service gateway (SGW), packet data network

gateway (PGW), home subscriber services (HSS)

Ø Transport technologies: copper, optical, and/or wireless technologies

Ø Research on 5G focused on new radio access networks (RAN): high peak-

rates per subscriber; handle very large number of simultaneously connected
devices; better coverage, outage probability, and latency

Ø So far less attention is put on defining the 5G transport network

Radio access network Transport network Evolved packet core

Optical, copper MME HSS
Public
and/or wireless
Internet
transmission
technologies SGW PGW
5
 Transport services in 4G

ØBefore getting into the specifics of what should be the requirements of a 5G

transport network it might be useful to understand how transport services
look like in 4G networks

ØWith current mobile networks the transport should be able to accommodate

o Backhaul services (distributed RAN)

o Fronthaul services (centralized RAN)

Ø and support

o Advanced radio coordination features

o (Massive) multi-input multiple-output (MIMO) antennas architectures

ØIdea: look at the current requirements and try to identify possible critical
aspects when having to serve new 5G services
6
M. Fiorani, et al.,"On the Design of 5G Transport Networks," Springer PhotonicNetwork Communications (PNET) Journal, 2015
 Backhaul services

Ø Mobile backhaul:

Transport network

Evolved packet core

Composite base station

EU FP7 Project COMBO. http://www.ict-combo.eu/

ØMacro base station composed of: (1) Antennas, (2) Remote Radio Units
(RRUs), (3) Baseband Unit (BBU)
ØBBU performs baseband signal processing and generates packet-based
backhaul traffic. The backhaul traffic is composed of: data traffic (S1) +
control traffic (X2)
ØBackhaul data traffic is proportional to the data generated by the users 7
 Backhaul: dimensioning

ØTransport dimensioning for backhaul*:

o During “quite times”, peak bitrate corresponds to one user equipment (UE)
with a good link served by one sector
o During “busy time”, many UEs are served by each sector and the average
bitrate is related to the average spectral efficiency over the coverage area
ØProvisioned capacity for a base station with N sectors typically obtained
as maximum of:
o peak bitrate for single sector
o N x (busy hour average bitrate)

8
Guidelines for LTE Backhaul Traffic Estimation”, White Paper by NGMN Alliance
*
 Peak rate and busy hour
requirements

ØThe peak bitrate of a sector depends on*:

o Radio access network (RAN) configuration
ü Channel bandwidth, MIMO (# of antennas/sector), peak spectral efficiency

o UE category (as specified by 3GPP) served by the sector

ØAverage busy hour bitrate*: simulation for an urban macro cell

environment

9
Guidelines for LTE Backhaul Traffic Estimation”, White Paper by NGMN Alliance
*
 Backhaul: required bandwidth

Data traffic S1 per macro site* Coordination traffic X2 between sites*

EU FP7 Project COMBO. http://www.ict-combo.eu/

Assumption on X2 traffic:
50 Mb/s base rate + 0.3 x S1 traffic
*

Typical values for LTE-A base station (BS):

o Macro BS: 40 MHz with 4x4 MIMO = 830 Mbps per macro base station
o Small cell Var.1: 20 MHz with 2x2 MIMO = 245 Mbps per small cell
o Small cell Var.2: 40 MHz with 4x4 MIMO = 830 Mbps per small cell
10
MIMO and larger spectrum as well as additional X2 traffic drive the need for >1G backhaul links
 Fronthaul services

Ø Centralized RAN (C-RAN):

EU FP7 Project COMBO. http://www.ict-combo.eu/

ØThe BBUs are decoupled from the base station and centralized in one or more
pools (alternatively also BBU hotels or even BBU clouds)
ØThe transport network is divided in two parts:
o Fronthaul: traffic between RRUs and BBU pool
üCarries the sampled I/Q data generated at the RRU (C1 traffic)

üPopular radio interface for D-RoF is Common Public Radio Interface (CPRI)

o Backhaul: traffic between BBU pool and EPC (S1 + X2) 11

 Motivation and challenges

Ø Motivations for C-RAN:

o More efficient radio coordination
o Energy and cost savings (sharing infrastructure, BBU functionalities, reduced
footprint outdoor equipment)
o Easy hardware/software upgrades, maintenance, and reparation
Ø Challenges for C-RAN:
o Fronthaul latency requirements
ü LTE physical layer hybrid automated repeat request process (HARQ) requires
maximum round-trip delay of 3ms, including both transport and BBU processing time
o Fronthaul traffic capacity requirements
ü Constant bit-rate → independent from traffic generated by the users equipment
ü Using CPRI*:
Ns: # sector
* http://www.cpri.info

Nant : # ant. elements

Rs: sampling rate
Nres: bit/sample
Radio Analog to digital Control OCW: overhead
overhead OLC: line coding 12
configuration conversion
 Fronthaul: latency requirements

Ø LTE physical layer HARQ requires that

eNodeB indicates within 4 ms to the
user equipment (UE) to retransmit an
erroneous packet
Ø Gives a 3ms budget including both
transport and BBU processing time
Ø Maximum theoretical RTT delay limit
for the transport: 400 µs
Ø A good practice is to limit the RoF
transmission delay to around 100 µs
Ø Maximum distance between a RRU
and a BBU not to exceed 20 km*

13
C-RAN - The Road Towards Green RAN; China Mobile White Paper, Version 3.0 (Dec 2013)
*
 Fronthaul: capacity requirements

Ø Typical values for LTE-A base station (BS):

o Macro BS: 40 MHz with 4x4 MIMO = 10 Gbps per sector, 3 CPRI links per macro BS,
total of 30 Gbps per macro BS
o Small cell Var.1: 20 MHz with 2x2 MIMO = 2.5 Gbps per sector
o Small cell Var.2: 40 MHz with 4x4 MIMO = 10 Gbps per sector 14
 Advanced radio coordination

Ø Radio coordination improves transmission spectral efficiency, in

particular at cell edges. Also used to mitigate interference in HetNet

Ø Different radio coordination schemes and algorithms:

o Enhanced inter-cell interference coordination (eICIC)

o Coordinated multi-point (CoMP)

ü Coordinated scheduling: interference management

ü Coordinated beamforming: interference management

ü Dynamic point selection: chose best signal

ü Joint tx and rx (JP-CoMP)

15
Radio coordination benefits and
requirements

Small gain: <20% - Medium gain: 20-50% - High gain: >50% 16

 Radio coordination with BH and FH

Backhaul Fronthaul

Ø An interconnection of X2 interface Ø X2 interfaces are collocated,

required, link distances between X2 delay close to zero
sites will cause delay Ø Fulfils inherently X2 delay
Ø To support JP-CoMP delay < 0.5 ms requirements for CoMP < 0.5 ms
interconnection required
EU FP7 Project COMBO. http://www.ict-combo.eu/

Ø Backhaul: X2 connection needs to support delay < 0.5 ms for JP-CoMP (difficult)
Ø Fronthaul: fulfils inherently X2 delay requirements for JP-CoMP < 0.5 ms
17
*
 Impact of MIMO

Ø Regular (i.e., a few elements) MIMO configurations already used in

current LTE deployments
Ø m-MIMO: provide BS with large spatial multiplexing gains and
beamforming capabilities thanks to hundreds of antenna elements
Ø It is expected new 5G radio access interfaces will include*: technology
backward compatible with LTE and LTE-A, new technology (NX) based on m-MIMO

Ø Transport capacity requirement with m-MIMO:

o Backhaul → rise to up to 10 Gbps (in LTE-A was ≈ 1 Gbps)
o Fronthaul: may reach the Tbps per base station

Radio Analog to digital Control

configuration conversion overhead
18
S. Tombaz, et al., ”Energy Performance of 5G-NX Wireless Access Utilizing Massive Beamforming and an Ultra-lean System Design”, in IEEE GLOBECOM, 2015
*
 Midhaul with split processing

T. Pfeiffer, “Next Generation Mobile Fronthaul and Midhaul Architectures”, IEEE/OSA (JONC), 2015
Ø Splitting the wireless processing chain so that the capacity on interface is
dependent on the amount of data to be transmitted over the air
Further study on critical C-RAN technologies”, White Paper by NGMN Alliance

Ø “PHY2” separates processing of user data from processing of cell signals with a bit
rate in the range 0% - 20% of the CPRI bit rate
Ø Split points has impact on Radio coordination (PHY1 and PHY2 still OK) and
energy savings (Layer 1 functions are the most consuming)

19
 Evolution from 4G to 5G transport

Ø Backhaul services (user rate dependent) with increased capacity

requirements (i.e., tens of Gbps or more)
Ø Centralized architectures will have to be revisited to consider the new
requirements:
Ø m-MIMO might create bottlenecks in the transport if not carefully addressed
Ø Midhaul solutions can help but there is a tradeoff with
o Achievable level of radio coordination

o Benefits of C-RAN from the mobile network side are drastically reduced (some of
the more energy consuming functionality are again distributed)

Ø No “one solution fits all” approach, but rather a solution with/without

centralized processing depending on the requirements of on the specific
5G service(s)
Ø Need to map 5G service requirements into transport requirements
20
 5G requirements

Ø EU FP7 METIS 2020 project: laying the foundation of 5G1

Ø 5G defined in terms of scenarios (S) supported
Ø Each scenario introduces a challenge (C)
Ø Each scenario multiple test cases (TC) S: Ubiquitous
things
communicating
S: Great service in a crowd TC9: Open air C: Very low
C: Very dense crowds of festival energy, cost and
users
TC3: Shopping massive number of
TC4:
Stadium mall devices
TC11: TC5: Tele-protection
Massive in smart grid networks
deployment
of sensors
TC2: Dense
TC1: virtual and actuators
urban
reality office information TC6: TC10: Emergency
society Traffic jam communications
S: Amazingly fast
C: Very high data-rate S: Super real time
TC8: Real-time remote
and reliable
computing for mobile
connections
TC7: Blind terminals
C: Very low latency
spots TC12: Traffic
efficiency and
S: Best experience follows you safety
C: Mobility
1
METIS deliverable D1.1, ”Scenarios, requirements and KPIs for 5G mobile and
21
wireless system”, April, 2013.
 5G transport requirements

Ø The 5G challenges → transport challenges: o Very high data rate → huge

aggregated traffic volumes
o Very dense crowds of users →
provide high capacity on-demand
o Best experience follows you → fast
TC9: Open air
S: Great service reconfigurability of transport resources
in a crowd
festival C: High capacity o Super real time and reliable
on-demand connections → very low latency
TC1: virtual TC3: Shopping
reality office mall

TC4:
Stadium TC2: Dense
urban
o The massive number
information TC12: Traffic of connected devices
society efficiency and not a major issue: the
safety
TC6: traffic from a large
S: Amazingly fast
Traffic jam number of machines
C: Huge aggregated TC8: Real-time remote
over a geographical
computing for mobile
traffic volumes
terminals area will be aggregated
S: Best experience follows you in the transport
C: Fast reconfigurability of
transport resources

22
M. Fiorani, et al., “Challenges for 5G Transport Networks”, in Proc. of IEEE ANTS, 2014.
 How to enable these functionalities?

Ø Two main directions for provisioning high capacity on-demand and in a

flexible way
Ø Overprovisioning: high capacity on-demand with (possibly) fast resource
reconfiguration is satisfied thanks to the ubiquitous availability of ultra-
high capacity transport
o Pros: relatively low complexity at the control plane
o Cons: potentially high cost because of inefficient use of network resources
Ø “Intelligence” in the transport infrastructure
o Dynamic resource sharing: re-configurable systems for dynamically sharing
limited transport resources
o Network functions virtualization (NFV): dynamically push network
functions to different locations, e.g., closer to the users so that a portion of the
traffic requests can be served locally

23
M. Fiorani, et al., "On the Design of 5G Transport Networks," Springer Photonic Network Communications (PNET) Journal, 2015
 How to add intelligence to transport?

Ø Programmability/flexibility (resource sharing and/or NFV) puts

requirements on the control plane
Ø A SDN-based control plane with end-to-end orchestration could provide a
framework for such a scenario
Ø One possible control plane architecture might be:

Orchestration

SDN-based
control Radio controller
Transport controller

Small cells transport controller

Dedicated small cells transport

Small cells Small cells Macro MN
access
Smart data
plane Technology Edge
Topology Access Ring Metro Ring
Small cells

24
Wireless small cells network Transport network
 Some interesting open questions

Ø If orchestration helps in using resources efficiently → what’s the best level

of details to be used to advertise the availability of transport resources?
Ø With orchestration what are the advantages brought by dynamic resource
sharing?
Ø What are good (i.e., power/cost) architectural options that allow the placement of
NFV?
Orchestration
?
SDN-based
control Radio controller
Transport controller
Small cells transport controller

Dedicated small cells transport

Small cells Small cells Macro MN
access
Smart data
plane Technology Edge
Topology Access Ring Metro Ring
Small cells

25
? ? ?
 Transport resources abstraction: the
C-RAN use case

Ø Orchestration implies knowledge of

Orchestrator
condition of the wireless and the
transport network
Ø Every time a new RRU needs to be Transport Controller Wireless Controller
turned on, lightpath needs to be
established between RRU and BBU
hotel, as well as one between BBU
and EPC BBU
Hotel
Ø Tradeoff between abstraction level
(i.e., performance) and complexity
(i.e., scalability, messaging
EPC
overhead)
RRU
BBU
Hotel

26
M. Fiorani, et al., “Transport Abstraction Models for a SDN-Controlled Centralized RAN”, IEEE Communication Letters, August 2015.
 Abstraction policies

Ø Big Switch Basic

o Transport network presented to the orchestrator as a single node
(switch)
o No updates between transport controllers and orchestrator required

Ø Virtual Link with Constant Weights

o Transport network presented to the orchestrator as a number of
potential connections (virtual links) among switch ports
o Each virtual link is assigned a constant weight
o Whenever connectivity is lost between 2 switch ports corresponding
virtual link is deleted
o Updates between controller and orchestrator are required

Ø Virtual Link with Variable Weights

o Transport network presented to the orchestrator as a number of
potential connections (virtual links) switch ports
o Each virtual link is assigned a variable weight, i.e., # of wavelength
between 2 switch ports
o Updates between controller and orchestrator are required 27
 Resources abstraction: results
Ø 38 nodes, 2 BBU Hotels,
EPC accessible via two node

Ø η = ration of amount of radio resources vs. 28

transport resources
 Advantages of dynamic resource
sharing
Ø 7 access rings with 5 access edge (AE) nodes per ring
Ø 1 metro ring with 3 metro nodes (MNs) and 1 ME connected with BBU pools
Ø 1 macro base station (MBS) and N small cells (SCs) per AE
Ø Daily traffic variations over the ARs (residential vs. office areas vs. city center)
BBU Pool

TP TP TP

AE AE
AE
ME AE
AE AE AE AE

AE AE MN metro MN AE AE
ring
AE AE AE AE
AE
AE
AE MN AE

AE AE
Macro Base access
Station AE ring AE AE
AE
TP
AE AE
TP AE
AE AE
TP
Small Cells
AE
AE AE
29
AE
 Daily traffic variations over the ARs

Ø Traffic profile over 24h for each ring, shifted by 3 hours

R(t) [Mbps/km2]

1000
Ring 1

500

0
0 5 10 15 20

1000
Ring 2

500

0
0 5 10 15 20

1000
Ring 3

500

0
0 5 10 15 20

1000
Ring 4

500

0
0 5 10 15 20

1000
Ring 5

500

0
0 5 10 15 20

1000
Ring 6

500

0
0 5 10 15 20

1000
Ring 7

500

0
0 5 10 15 20
t [hours] 30
 Simulation results
Ø No. of experiments = 100, Available lambdas per pool = 96; N=2
N=2 N=5
45 110
105
40 100

N SCs
N SCs

95
35
90

30 85
0 5 10 15 20 0 5 10 15 20
t [hours] t [hours]

80 145
140
75 135
N TPs

N TPs
130
70
125
65 120
0 5 10 15 20 0 5 10 15 20
t [hours] t [hours]

No. of transponders for N = 2 No. of transponders for N = 5

Peak Dimensioning 35 (for MBS) + 70 (for SCs) = 105 35 (for MBS) + 175 (for SCs) = 210

Dynamic Resource Sharing 77 144

31
Saving = 26.7% Saving = 31.4%
 Data plane options for NFV

Ø “Metro simplification” is a power/cost efficient architecture allowing for

the reduction of the number of local exchanges (i.e., simplification)*
Ø Two types of rings
o Optical access ring: collects the traffic from mobile network
o Optical metro ring: aggregates and transmits toward the service edge

Pico Micro Macro Access Metro

Rings Ring

LTE AP
? MN
Edge

Fixed Home net Corporate net

* Skubic B., Pappa I., “Energy consumption analysis of converged networks: Node consolidation vs metro simplification”, OFC/NFOEC, 2013
 KPIs and objective

Ø Architectures for metro simplification:

o Optical DWDM switching
o Electronic packet switching
o Electronic packet switching + caching

Complexity Capacity Power/Cost?

required number required number
of complex of optical channels
network
components
Ø Objective:
o Assess power consumption/cost of different architectures for metro
simplification
o Identify the most promising solution(s)
 Scenario: very dense urban area

Scenario: Service Requirements :

1. CO service area: 2 km2 1. Macro: 228 Mb/s

2. Macro: 60 (30 per km2) 2. Micro: 90 Mb/s
3. Micro: 600 3. Pico (indoor): 132 Mb/s
4. Pico (indoor): 6000 4. Residential user: 16 Mb/s Number Rate Traffic [Gbps] Total Traffic
per AP [Gbps] per AP [Gbps] for 60 APs
5. Buildings (in 2 km2 area): 400 5. Business user: 202 Mb/s LTE
6. Businesses: 10 per building Macro 1 0.228 0.228 13.7
Micro 10 0.090 0.9 54
7. Homes: 50 per building Pico 100 0.132 13.2 792
8. People: 200k Fixed
Residential 333 0.016 5.33 320
9. People (office): 160k Business 67 0.202 13.47 808
10. People (res): 40k
11. Devices: 200k-2M

** Note that only LTE backhaul (no CPRI) is assumed.

M. R. Raza, M. Fiorani, B. Skubic, J. Mårtensson, L. Wosinska, P. Monti, "Power and Cost Modeling for 5G Transport Networks," in Proc. of IEEE ICTON, 2015
 Data plane architecture options

AP MN AP MN

Deployment A Deployment B

AP MN Case I = optical switching at MN / no caching

Case II = optical switching at MN / caching at AP
Case III = electronic switching at MN / no caching
Case IV = electronic switching at MN / caching at MN
Case V = electronic switching at MN (hybrid 10G/100G) / no caching
Case VI = electronic switching at MN (hybrid 10G/100G) / caching at MN
Deployment C

M. R. Raza, M. Fiorani, B. Skubic, J. Mårtensson, L. Wosinska, P. Monti, "Power and Cost Modeling for 5G Transport Networks," in Proc. of IEEE ICTON, 2015
 Power consumption evaluation

Power consumption (W) at 10 Power consumption (W) at 100

Gbps Gbps
140000 140000
120000 120000
100000 100000
80000 80000
60000 SE 60000 SE
40000 MN 40000 MN
20000 AP 20000 AP
0 0
Case VI

Case VI

Case VI
Case V

Case V

Case V

Case VI

Case VI

Case VI
Case IV

Case IV

Case IV

Case V

Case V

Case V
Case I

Case I

Case I

Case IV

Case IV

Case IV
Case II

Case II

Case II
Case III

Case III

Case III

Case I

Case I

Case I
Case II

Case II

Case II
Case III

Case III

Case III
Deployment A Deployment B Deployment C Deployment A Deployment B Deployment C

Case I = optical switching at MN / no caching

Power Consumption Cost [CU] in Cost [CU] in
Case II = optical switching at MN / caching at AP
[Watt] Year 2014 Year 2018
Case III = electronic switching at MN / no caching
Ethernet 10 Gbps port 38 1.56 0.89
Case IV = electronic switching at MN / caching at MN Ethernet 100 Gbps port 205 28.89 10
Case V = electronic switching at MN (hybrid 10G/100G) / no caching WSS 10 Gbps / 100 Gbps 20 5.56 3.89
Case VI = electronic switching at MN (hybrid 10G/100G) / caching at MN

M. R. Raza, M. Fiorani, B. Skubic, J. Mårtensson, L. Wosinska, P. Monti, "Power and Cost Modeling for 5G Transport Networks," in Proc. of IEEE ICTON, 2015
 Cost evaluation: the 2014 case

2014: Total Cost (CU) at 10 Gbps 2014: Total Cost (CU) at 100
Gbps
18000

15000 18000
15000
12000
12000
9000 SE
9000 SE
6000 MN
6000 MN
AP
3000 3000 AP
0 0
Case VI

Case VI

Case VI

Case VI

Case VI

Case VI
Case V

Case V

Case V
Case IV

Case IV

Case IV

Case V

Case V

Case V
Case IV

Case IV

Case IV
Case I

Case I

Case I
Case II

Case II

Case II
Case III

Case III

Case III

Case I

Case I

Case I
Case II

Case II

Case II
Case III

Case III

Case III
Deployment A Deployment B Deployment C Deployment A Deployment B Deployment C

Case I = optical switching at MN / no caching

Power Consumption Cost [CU] in Cost [CU] in
Case II = optical switching at MN / caching at AP
[Watt] Year 2014 Year 2018
Case III = electronic switching at MN / no caching
Ethernet 10 Gbps port 38 1.56 0.89
Case IV = electronic switching at MN / caching at MN Ethernet 100 Gbps port 205 28.89 10
Case V = electronic switching at MN (hybrid 10G/100G) / no caching WSS 10 Gbps / 100 Gbps 20 5.56 3.89
Case VI = electronic switching at MN (hybrid 10G/100G) / caching at MN

M. R. Raza, M. Fiorani, B. Skubic, J. Mårtensson, L. Wosinska, P. Monti, "Power and Cost Modeling for 5G Transport Networks," in Proc. of IEEE ICTON, 2015
 Cost evaluation: the 2018 case

2018: Total Cost (CU) at 10 Gbps 2018: Total Cost (CU) at 100
7000 Gbps
6000 7000

5000 6000
5000
4000
4000
3000 SE
3000 SE
2000 MN
2000 MN
AP
1000 1000 AP
0 0
Case VI

Case VI

Case VI

Case VI

Case VI

Case VI
Case V

Case V

Case V
Case IV

Case IV

Case IV

Case V

Case V

Case V
Case IV

Case IV

Case IV
Case I

Case I

Case I
Case II

Case II

Case II
Case III

Case III

Case III

Case I

Case I

Case I
Case II

Case II

Case II
Case III

Case III

Case III
Deployment A Deployment B Deployment C Deployment A Deployment B Deployment C

Case I = optical switching at MN / no caching

Power Consumption Cost [CU] in Cost [CU] in
Case II = optical switching at MN / caching at AP
[Watt] Year 2014 Year 2018
Case III = electronic switching at MN / no caching
Ethernet 10 Gbps port 38 1.56 0.89
Case IV = electronic switching at MN / caching at MN Ethernet 100 Gbps port 205 28.89 10
Case V = electronic switching at MN (hybrid 10G/100G) / no caching WSS 10 Gbps / 100 Gbps 20 5.56 3.89
Case VI = electronic switching at MN (hybrid 10G/100G) / caching at MN

M. R. Raza, M. Fiorani, B. Skubic, J. Mårtensson, L. Wosinska, P. Monti, "Power and Cost Modeling for 5G Transport Networks," in Proc. of IEEE ICTON, 2015
 Concluding remarks

ØFocus of new 5G radio technologies: high peak-rates per subscriber; handle large
number of simultaneously connected devices; better coverage, outage
probability, and latency

ØWill not have a “one solution fits all” approach, but a solution with/without
centralized processing depending on the requirements of on the specific 5G
service(s)

ØTransport will evolve towards a programmable infrastructure able to flexibly

adapt to the various 5G service needs

ØHighlighted a few directions on how programmability and flexibility can be

achieved (joint orchestration with dynamic resources sharing) and demonstrated
some of benefits that can be obtained

ØDevelopment and deployment of new radio and transport networks need to go

hand in hand in order to be able to get the best of out the new 5G
communication paradigm
 References

Ø P. Öhlén, B. Skubic, A. Rostami, Z. Ghebretensaé, J. Mårtensson, K. Wang, M. Fiorani, P. Monti, L.

Wosinska, "Data Plane and Control Architectures for 5G Transport Networks," IEEE/OSA Journal of
Lightwave Technology, to appear, 2016.

Ø M. Fiorani, B. Skubic, J. Mårtensson, L. Valcarenghi, P. Castoldi, L. Wosinska, P. Monti, "On the Desi gn
of 5G Transport Networks," Springer Photonic Network Communications (PNET) Journal, 2015

Ø P. Öhlén, B. Skubic, A. Rostami, Z. Ghebretensae, J. Mårtensson, K. Wang, M. Fiorani, P. Monti, L.

Wosinska, "Data Plane and Control Architectures for 5G Transport Networks," in Proc. of ECOC, 2015

Ø M. Fiorani, P. Monti, B. Skubic, J. Mårtensson, L. Valcarenghi, P. Castoldi, L. Wosinska, “Challenges for

5G Transport Networks”, in Proc. of IEEE ANTS, 2014

Ø M. Fiorani, A. Rostami, L. Wosinska, P. Monti, “Transport Abstraction Models for a SDN-Controlled

Centralized RAN”, IEEE Communication Letters, 2015

Ø M. R. Raza, M. Fiorani, B. Skubic, J. Mårtensson, L. Wosi nska, P. Monti, "Power and Cost Modeling for
5G Transport Networks," in Proc. of IEEE ICTON, 2015

Ø B. Skubic, I. Pappa, “Energy Consumption Analysis of Converged Networks: Node Consolidation vs

Metro Simplification”, OFC/NFOEC, 2013

Ø METIS deliverable D1.1, ”Scenarios, requirements and KPIs for 5G mobile and wireless system”, April
2013
Optical 5G Transport: Challenges
and Opportunities
Paolo Monti
pmonti@kth.se
http://web.it.kth.se/~pmonti/
 How to enable these functionalities?

Ø The type of resources that can be dynamically virtualized depends on:

o User traffic type
o Business model (agreement between wireless and transport providers)
Ø Example of resources that can be virtualized:
o Wireless network functions: BB processing, evolved packet core (EPC)
o Transport network functions: packet aggregation
o Cloud resources: cache/storage
Ø Servers needs to be available in different network locations:

Dedicated small cells transport

Small cells Small cells Macro MN
access

Technology Edge
Topology Access Ring Metro Ring
Small cells

42