Practical approach to converged FH/BH network architecture and...
Transcript of Practical approach to converged FH/BH network architecture and...
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 ([email protected])
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