Dimer-Specific Potentiation of NGFI-B (Nur77) Transcriptional ...
Function split and deployment scenarios for NGFI
Transcript of Function split and deployment scenarios for NGFI
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
Next Generation Fronthaul Interface - Use Cases & Scenarios
Date: 2016-10-26
Author(s):
Name Affiliation Phone [optional] Email [optional]
Lujing Cai AT&T [email protected]
Abdellah Taz AT&T
IEEE [WG Project #][WG Name]
[WG Chair Name and Email]
– Preferred function split options
– Deployment scenarios
– High level requirements of NGFI
4
Contents
Preferred RAN function split options for transport
Option 2
– Split between PDCP & RLC
– Already standardized for LTE Dual Connectivity in 3GPP
– Benefits of aggregation of different transmission points
Option 3
– Intra-RLC split
– Candidate break point: Lower RLC: segmentation & concatenation, High RLC: ARQ retransmission & packet ordering
– Benefit: More robust under unreliable transport conditions
Option 6
– Already used in nFAPI (network Function API) specified by Small Cell Forum Release 7.0
– Benefit: Centralized scheduler
Option 7
– Intra-PHY split
– Split point consideration to facilitate:• Implementation of advanced receivers
• Ability of joint processing (JR and JT)
• Reasonable transport bandwidth requirement
– Candidate break point: after FFT &CP removal for uplink, and before layer mapping for downlink
– Benefits: realization of full CoMP gain and advanced receiver
Insert Date hereInsert Title here 6
Transport requirement for the preferred RAN split options
7
Option 2 Option 3 Option 6 Option 7
RLC&PDCP split Intra-RLC split MAC&PHY split Intra-PHY split
Throughputrequirement
Proportional to the user data rate
Proportional to the user data rate
Proportional to the userdata rate
Proportional to channel BW, number of antennas, or MIMO layers
Throughput comparison
TP2≈<TP3≈<TP6<<P7 TP3≈<TP6<<P7 TP6<<TP7 (by factor of 5-10)
TP7
Latency requirement
ms range ms range User-plane: ms rangeControl-plane: μs range
μs range
CoMPperformance
LTE: slow coordinationNR: new CoMP scheme pending
LTE: slow coordinationNR: new CoMP scheme pending
fast scheduling coordination
joint processing & fast scheduling coordination
Data types RLC PDUs ARQ packets Physical channels Sub-carrier symbols
• Option 2 & 3 have similar latency&BW requirement
grouped into the same category in terms of transport aspect
• Option 6 requires separation of control-plane (fast) and user-plane (slow)
• Option 7 is another transport category with much different latency and BW requirements
Transport requirements derived from above function split categories to be further discussed & studied
Centralized-RAN based macro deployment
– Centralized/cloud-RAN
– Cell coordination to improve cell edge user experience
– BBUs in a coordination cluster co-located in the same BBU pool
– Joint Transmission(JT)/Joint Reception (JR) performed among the BBUs in the same cluster
– Multiple sector deployment per site
– Near term solution for evolution to 5G
Insert Date hereInsert Title here 9
Fronthaul requirement
• Option 7 as candidate function splitting option to enable inter-site/intra-cluster fast coordination • Site transport BW requirement (UL):
UL: ~(# of sectors/site)x(# of RX chains)x (signal BW)x(CP removal factor)x(sample data resolution) DL: ~(# of sectors/site)x(# of DL spatial layers)x (signal BW)x(CP removal factor)x(sample data resolution)
• Stringent latency requirement: (e.g. ~100us)• Average transport distance to BBU pools: large due to large ISD (inter-site distance)smaller cluster size due to
transport cost concerns
• Possible legacy CPRI transport with function split option 8 as existing solution
Core NW
NGFI fronthaul
BBUs(C-RAN/V-RAN)
backhaul
BBUPool 1
PDCP
RLC
MAC
H PHY
RF
L PHY
RRC
Coordination cluster 2
Coordination cluster 1
RRUs
BBUPool 2
RRU RRU
RRU
RRU RRU
RRU
Centralized-RAN based small cell deployment
– Micros/pico RRUs at poles/buildings for dense small cells
– Stadium/high-capacity venues
– Evolving to mmWave
– Omnidirectional or multi-sectors
– Advanced CoMP technology required for interference management• CS/CB
• JT/JR
• Dual connectivity
• LAA
– Coordination within cluster
Insert Date hereInsert Title here 10
Fronthaul requirement
Option 7 as candidate function split to support advance CoMP• Site transport BW requirement:
UL: ~(# of sectors/site)x(# of RX chains)x (signal BW)x(CP removal factor)x(sample data resolution)
DL: ~(# of sectors/site)x(# of DL spatial layers)x (signal BW)x(CP removal factor)x(sample data resolution)
• Stringent latency requirement: (e.g. ~100us)
Option 6 as candidate function split• To support nFAPI• To reduce the transport cost• Site transport BW requirement for user-plane:
~(# of sectors/site) x (peak user data rate)
• Stringent latency requirement for control-plane• Relaxed latency requirement for user-plane
• Aggregated transport traffic/cluster: function of coordination cluster size• Average transport distance to BBU pool: small
Core NW
NGFI fronthaul
BBUs(C-RAN/V-RAN)
backhaul
BBUPool 1
PDCP
RLC
MAC
H PHY
RF
L PHY
RRC
Coordination cluster 2
Coordination cluster 1
RRUs
BBUPool 2
PDCP
RLC
MAC
RRC
RF
PHY
1376Gbps
688Gbps
172Gpbs
43Gbps
Coordination cluster size (# of RRUs /cluster)
Transport BW requirement example for small cell deployment
Further Densification
172Gbps
Transport BW/cluster (Gbps)
Channel BW: 800MHz
344Gbps
86Gbps
344Gbps
688Gbps
1400
1200
1000
800
600
400
200
2 4 6 8 10 12 14 16
Channel BW: 400MHz
Channel BW: 100MHz
Hig
her
Bandw
idth
Assumptions• 2x2 antenna configuration• 2 layer MIMO• 2 sectors/site• Carrier aggregation to utilize large BW• UL with option 7 split after IFFT/CP removal
Massive-MIMO macro deployment
– FD-MIMO/Massive-MIMO at Macro tower
– Active array systems (AAS) to steer beams in both azimuth and elevation directions
– Simultaneous narrow beams to support high order MU-MIMO
– Virtual small cells formed by narrow BF
– Multiple sector deployment
– Carrier aggregation
– Coordination among the virtual cells performed by massive MIMO processing
Insert Date hereInsert Title here 12
NGFI
FD-MIMO at Macro tower
Core NW
BBUs (C-RAN/V-RAN)
backhaul
BBU
BBU
BBU
BBU
PDCP
RLC
MAC
PHY
TxRU
RF RRC
Fronthaul requirement
• Massive transport connections required to each cell site• Option 2&3 as candidate function splitting option to cope with the large transport BW
requirement• Transport BW requirement/site:
~(# of sectors/site) x (peak user data rate) x (# of beams (virtual cells))
• Relaxed latency requirement• Average transport distance to BBU pools: large due to large ISD
3 sectors4 MU-MIMO users /sector
960Gbps
480Gbps
120Gpbs
24Gbps
User data rate (Gbps)
Transport BW requirement example for massive-MIMO deployment
Futh
er
Densific
ation
1 2 3 4 5 6 7 8 9 10
96Gbps
Transport BW/site (Gbps)
6 sectors8 MU-MIMO users /sector
1000
800
600
400
200
6 sectors16 MU-MIMO users /sector
192Gbps
60Gbps
240Gbps
480Gbps
Evolution to 5GAssumptions• Max 800MHz BW• 4 layer MIMO• Multiple sectors/site• Carrier aggregation to utilize large BW• Option 2&3 function split
IOT/MTC deployment
14
Current 3GPP IOT
R13 Cat-M1 R13 NB-IOT
Max BW 1.4MHz 200kHz
Peak data rate 1Mbps 70kbps
RF Sample frequency
1.92MHz 480kHz
Modulation order Max: 16QAM QPSK
Operation mode Standalone StandaloneGuard-bandIn-band
Low bandwidth
Low data rate
Low sample rate
Low modulation
cell site
Core NW
Edge Core
NGFI
IOT use case categories
Non-critical apps Critical apps
• Low cost/low power• Low mobility• Small data packets• Infrequent transmission• Massive numbers
• Ultra reliable• Very low latency• Very high
availability
5G IOT/MTC
Low rate mMTC
URLLC based MTC
Transport requirement
• Co-exist in the same cell site with other LTE/NR DUs • Two types of transport traffic carried in NGFI:
• Very low latency, small packets, ultra low error rate
• Slow & small packets• Requirement on scalability of aggregating massive
small data packets
LTE/NR DU
IOT DU
URLLCIOT DU
LTE/NR CU
IOT CU
Very low latency
Support of legacy deployment by NGFI
– Co-exist with legacy 3G/4G deployment in the same cell site
– Co-exist with 4G C-RAN deployment with CPRI fronthaul in the same cell site
Insert Date hereInsert Title here 15
Transport requirement
• To accommodate existing legacy services via converged transport • Merge all transport traffics into NGFI for simplification of transport architecture & reduce deployment cost
• 3G/4G Backhaul• CPRI fronthaul
cell site
Core NW
NGFI
NR DU
LTE DU
4G eNB
NR CU
LTE CU
Backhaul
CPRI
Central site/Hub
3G NBBackhaul
Summary of NGFI deployment scenarios
Insert Date hereInsert Title here 16
Evolution to 5G
NGFI
Legacy deployment
CPRI
backhaul4G
3G
CU
C-RAN based macro C-RAN based small cell
CU CU
Heterogeneous network
HetNet over massive MIMO, mmWave, LAA
Massive-MIMO macro
CU
IOT/MTC mMTC/URLLC
CUEdge Core
nFAPI. u-plane: Relaxed latency, small BW
Relaxed latency, large BW
Relaxed latency, small packet
Very low latency, small packet, ultra low error rate
Legacy backhaul
CPRI
CU
Low latency, large BW
nFAPI
Summary
• Selection of function split option alone is not sufficient to determine the needs of NGFI specifications
• Under consideration of the preferred function split options together with the intended deployment scenarios, a number of classes of service in terms of transport requirement may be of special interest:
• Consider priority mechanisms to combine multiple classes on one NGFI link
• Consider non-switching mechanism to accommodate the needs of ultra low latency& jitter classes
Proposal for the way forward:
• Define a sufficient set of classes of service according to NGFI scope and supported deployment scenarios
• FFS the class requirement parameters (range of latency, jitter, data rate, error rate, etc.) for each of the classes
Insert Date hereInsert Title here 17
Service class Deployment scenario Transport requirement
1 C-RAN based macroC-RAN based small cell
Low latency, large BW
2 nFAPI based small cell Low latency control-planeRelaxed latency for user-plane, small BW
3 Massive-MIMO macro Relaxed latency, very large BW
4 URLLC/critical IOT Very low latency, small data packets, ultra low error rate
5 Non-critical IOT Relaxed latency, small data packets
6 4G/3G backhaul Relaxed latency, small BW
7 C-RAN based 4G CPRI
Desired NGFI features/challenges
– Backward compatibility
• Include legacy 3G/4G backhaul traffic in case of co-site deployment with 5G NRs
• Include CPRI to ensure fronthaul transport continuity for legacy RRUs/BBUs
• Migration from CPRI/WDM architecture to CPRI/packet/WDM architecture
– Forward compatibility
• Provide ‘future proof’ transport interface architecture
• Maximally avoid replacement of equipment when migration occurs
• Collaborate with eCPRI/TSN/nFAPI to support 5G transport network
– Scalability
• Allow graceful migration on each stage of evolution from 4G to 5G
• Accommodate vast BW requirement variation on each level of cell densification
– Flexibility/versatility
• Support multiplexing of different Classes of Service, i.e. ability to carry both (e)CPRI and Ethernet traffic over the same interface.
• Support multiple medium deployment (copper, fiber, MW, etc.)
• Allow flexible switching of function split points in a DU/CU configuration for different applications
– Vendor interoperability
• Enable multiple vendor deployment at both DU/CU ends
• Interoperability over intra-PHY/intra-RLC function split
Insert Date hereInsert Title here 19