Jouni Korhonen

Broadcom Ltd.

8/22-24/2016

IEEE 1914.1 TF

Practical approach to converged FH/BH network architecture and functional partitioning

Compliance with IEEE Standards Policies and Procedures

Subclause 5.2.1 of the IEEE-SA Standards Board Bylaws states, "While participating in IEEE standards development activities, all participants...shall act in accordance with all applicable laws (nation-based and international), the IEEE Code of Ethics, and with IEEE Standards policies and procedures."

The contributor acknowledges and accepts that this contribution is subject to

• The IEEE Standards copyright policy as stated in the IEEE-SA Standards Board Bylaws, section 7, http://standards.ieee.org/develop/policies/bylaws/sect6-7.html#7, and the IEEE-SA Standards Board Operations Manual, section 6.1, http://standards.ieee.org/develop/policies/opman/sect6.html

• The IEEE Standards patent policy as stated in the IEEE-SA Standards Board Bylaws, section 6, http://standards.ieee.org/guides/bylaws/sect6-7.html#6, and the IEEE-SA Standards Board Operations Manual, section 6.3, http://standards.ieee.org/develop/policies/opman/sect6.html

2

Practical approach to converged FH/BH network architecture and functional partitioning

Date: 2016-08-22

Author(s):

Name Affiliation Phone [optional] Email [optional]

Jouni Korhonen Broadcom Ltd. +1-408-391-7160jouni.korhonen@broa

dcom.com

IEEE 1914.1 TFNGFI

Bomin Li (bomin.li@comcores.com)

3

Outline

• Architecture proposal for converged fronthaul and backhaulnetwork for 4.5/5G RAN.

• Functional splits from a general purpose circuit point of view.

• Proposal NGFI interfaces and functional splits.

4

Objective

• Evolutionary path from 3/4G to 5G RAN.

• Identify the essential features from 4.5/5G RAN transport circuit & equipment realization point of view:

– Flexibility vs Bandwidth/time-synchronization/complexity/cost.

• Propose an architecture and functional splits to 4.5/5G RAN that:

– Allow E2E packet & Ethernet solutions.

– Allow converged fronthaul and backhaul network deployments.

– Scale up to 5G numbers keeping align with optics evolution.

– Aim at transport level interoperability.

5

Disclaimer

• Most numbers (that are known & fixed) are for LTE/LTE-Advanced.

• 5G numbers are estimations at best based on the publiclyavailable material from 3GPP.

6

Architectural Motivations

• Relaxed backhaul bandwidth requirements, support for lowlatency applications and radio/proximity optimized applications.

• Converged fronthaul and backhaul with unified E2E networkinginfrastructure and OAM.

• Fully virtualized coordinated RAN.

• Reduced buffering in vRAN nodes and centralized higher layerradio resource/mobility management

7

Mistakes we must avoid

• One design for 4G and a new design for 5G:

• Migration path is key.

• Scalability is key.

• Overly complicated solutions (difficult path to interoperability).

• Solution requiring new transport architectures:

• Leverage existing OAM, standard protocols, etc.

• Reinventing the wheel:

• Reuse existing time-synchronization solutions.

• Reuse existing time-sensitive networking solutions.

8

High level architecture – proposal

Intra- or

Internet

Intra- or

InternetEvolved

RRHs

Packet Core

in Data Center

vRAN/MEC DC

vRAN/MEC DCEnterprise

L2 Aggregator

Aggregator

BTS Caches etc

Old

RRHs

Legend: IP/Eth/MPLS Backhaul

Fronthaul (p2p connections)

Packet-based fronthaul

vRAN-vRAN X2-like midhaul

3C-like split midhaul

9

Transport view

Intra- or

Internet

Intra- or

InternetEvolved

RRHs

Packet Core

in Data Center

vRAN/MEC DC

vRAN/MEC DCEnterprise

L2 Aggregator

BTS Caches etc

Fronthaul connections

Backhaul (Eth/IP/MPLS)

Packtized Fronthaul (Eth/MPLS)

Midhaul’ (Eth/IP/MPLS)

DC (Eth, ..)

Midhaul (Eth/IP/MPLS)

DC (Eth, ..)DC (Eth, ..)

Old

RRHs

10

Aggregator

Latency requirements

Intra- or

Internet

Intra- or

InternetEvolved

RRHs

Packet Core

in Data Center

vRAN/MEC DC

vRAN/MEC DCEnterprise

L2 Aggregator

BTS Caches etc

<few ms ..

must be within the same total FH budget~100 µs in 4G and

<50 µs in 5G

several ms

few µs

~1 ms ..

few µs few µs

Old

RRHs

11

Aggregator

Time-synchronization requirements

Intra- or

Internet

Intra- or

InternetEvolved

RRHs

Packet Core

in Data Center

vRAN/MEC DC

vRAN/MEC DCEnterprise

L2 Aggregator

BTS Caches etc

< 1.5 µs phase/time

~65 ns phase/time, ~50ppb (depends on radio system requirements)

depends..

< 1.5 µs phase/time < 1.5 µs phase/time

depends..depends..

Old

RRHs

12

Aggregator

Summarizing..

• Multiple functional split points – not just how it splits in the radio stack but also how it fits into network architecture.

• Different functional splits affect latencies and synchronizationrequirements on specific parts of the transport network – theydo not change the overall system level radio synchronizationrequirements

• Highly accurate Time-syncronization distribution becomes key.

• Traffic isolation (no traffic interferes other traffic) becomes key.

13

Networking nodes and Interfaces

A *lot* of nodes,low power, simplesplit-L1 functions, ideally no state, ..

Many nodes, mappings to RoE, advanced split-L1 functions, processing element interface, ..

Fewer nodes,high bandwidth,service provider funtions

high bandwidth,a lot of queues,”Dual Connectivity”type functions, ..

NGFI1 NGFI2 NGFI3 <- Interfaces

14

3GPP TR38.801 functional split view

Each ”interface” has different set of requirements to the networking.

PDCPLow-

RLC

High-

MAC

Low-

MAC

High-

PHYLow-PHY

PDCPLow-

RLC

High-

MAC

Low-

MAC

High-

PHYLow-PHY

Option 5Option 4 Option 6 Option 7Option 2Option 1

RRC

RRC

RF

RF

Option 8

Data

Data

High-

RLC

High-

RLC

Option 3

NGFI1NGFI2NGFI3

15

Work in Progress Definitions

• Transport Element:

– Low level packet forwarding functions and pipeline.

– Simple and relatively static NGFI functions only.

– Radio over Foo encap/decap including possible mappers.

– TSN and time-synchronization features.

– Standard functions and fully interaoperable!

• Processing Element:

– Programmable.. complex NGFI (L1 and L2) functions.

– No guaranteed interoperability except for transport & packetization of data.

– Includes everything Transport Element.

16

LTE downling ”split” example following3GPP TS36.212 and 36.211 layering

• NGFI3:– Dual Connectivity

look-a-like – just IP transport.

• NGFI2:– Incrementalal to

NGFI1; some partslikely outside the transport element.

– Split point may float.– Converged FH and BH.

• NGFI1:– Keep it simple -

”~same” functions in DL and UL.

– Little radio expertise.– ”No software”..

Resource element mapping

LTE front end, FFT, CP insert, ..

TB CRC attachment

Code block segmentation & Code block CRC attachment

PDSCH Precoding

Channel coding

Rate Matching

Code block concatenation

Scrambling

PDSCH Modulation

PDSCH Layer Mapping

RLC / MAC

PDCP

Upper layer UP/CP stuff..

Transport Element, TSN features

Processing Element

NGFI1 Split

NGFI2 Split

NGFI3 Split

Eth/MPLS

L1

L2

L3

17

Requirements based on interfaces

Split functions:• (I)FFT and CP

insert/remove.

Transport latency/jitter:• Few tens of µs – based

e.g., on the FFT blocksize.

Time-synchronization:• ~1ns timestamping

accuracy (radio still has65ns TA & 50ppb freq. accuracy or strickter..)

• 1588 + SyncE.• OC/TC support.

Transport functions:• Ethernet, MPLS (PW).

Split functions:• NGFI1 + mappers.• ..possibly upper PHY,

PRACH handling, etc.

Transport latency/jitter :• Around NGFI1..

Time-synchronization:• NGFI1 + BC support.

Transport functions:• NGFI1 + some service

provider features.• Strict isolation &

protection (FH vs BH vs MH).

Split functions:• 3GPP 3C-like (Dual

Connectivity)..

Latency and Time-synchronization:• Existing ITU-T and MEF

specified for BH and MH.

• NGFI2 support.

Transport functions:• Typical service provider

features.

NGFI1 NGFI2 NGFI3

18

Some nodes may have dual role e.g., speak both NGF1 and NGFI2, etc

The unknowns

• NGFI work is supposed to eventually cover ”5G” but..

• However, the details of the 5G radio are still unknown:

– Max bandwidth (200MHz?, continuous or CA style?)

– Radio framing? TTI length? ng-HARQ? FFT block size?

– Radio system level latency and time-synchronizationrequirements set by 3GPP..

– etc..

• Dimensioning & deployment scenarios.. some numbers availablein 3GPP TR38.913 but how accurately they reflect realdeployments?

19

Proposal

• Define requirements and functions for a small number of splits (2? 3?).

• Functional splits should aim for simplicity:

• Identify the most common and important functions that are easy to design ”5G ready”.

• Adopt the three interfaces proposed in this contribution as a baseline:

• NGFI1 – simple split functions, high volume standard networkingsolutions with little software involvement.

• NGFI2 – more complex split functions, aggregation, convergedfront- and backhaul, software functions are likely needed.

• NGFI3 – ”L2 splits” with full service provider functions.

20