19
2/3/2020 1 5G NR gNB Architecture An Open-RAN (ORAN) Perspective Saidhiraj Amuru Overview Evolution of RAN architectures O-RAN Architecture O-RAN functional splits O-RAN FrontHaul Interface O-RAN Transport Protocol O-RAN C-Plane and U-Plane Protocol O-RAN Delay Management(S-Plane)

ORAN Saidhiraj Amuru CeWit 5G KS · P } Ç Z ] } h v ] P } Ç Z ] } h v ] h^ rW o v t^ o ] W } ] v ó r î Æ ] v h> ( } EZ h v o ] l ] v Z > U Z Zh P } Ç

  • Upload
    others

  • View
    114

  • Download
    6

Embed Size (px)

Citation preview

Page 1: ORAN Saidhiraj Amuru CeWit 5G KS · P } Ç Z ] } h v ] P } Ç Z ] } h v ] h^ rW o v t^ o ] W } ] v ó r î Æ ] v h> ( } EZ h v o ] l ] v Z > U Z Zh P } Ç

2/3/2020

1

5G NR gNB ArchitectureAn Open-RAN (ORAN) Perspective

Saidhiraj Amuru

Overview

• Evolution of RAN architectures

• O-RAN Architecture

• O-RAN functional splits

• O-RAN FrontHaul Interface

• O-RAN Transport Protocol

• O-RAN C-Plane and U-Plane Protocol

• O-RAN Delay Management(S-Plane)

Page 2: ORAN Saidhiraj Amuru CeWit 5G KS · P } Ç Z ] } h v ] P } Ç Z ] } h v ] h^ rW o v t^ o ] W } ] v ó r î Æ ] v h> ( } EZ h v o ] l ] v Z > U Z Zh P } Ç

2/3/2020

2

Traditional RAN Architecture

Everything is co-located

RRH: Remote Radio Head (RF + Antennas)BBU: Baseband Unit (Modem)CORE: Core Network

Centralized RAN Architecture

Remote Base Band Unit -typically proprietary closed platform

FrontHaul – CPRI/OBSAI/ORI

CPRI: Common Public Radio Interface, • a protocol for IQ data transmission between Radio Equipment (RE i.e., RRH) and Radio Equipment Controller (REC i.e., BBU) • via optical fibre • Wastage of resources (constant CPRI data streams are exchanged even when no traffic is present)• Fixed RRH-BBU mapping not good for virtualized BBU architecture• Highly inefficient – scales with number of antennas, not data rate i.e. 150Mbps data = ~2.5Gbps CPRI traffic • Requires very low latency – 200µs Optical transport; • RAN vendor proprietary format

Page 3: ORAN Saidhiraj Amuru CeWit 5G KS · P } Ç Z ] } h v ] P } Ç Z ] } h v ] h^ rW o v t^ o ] W } ] v ó r î Æ ] v h> ( } EZ h v o ] l ] v Z > U Z Zh P } Ç

2/3/2020

3

Cloud RAN Architecture

FrontHaul – CPRI/eCPRI/ IEEE 1914.3 RoEHighly efficient – 10x improvement over CPRITypically transported over Ethernet BBU: virtualization based; on-demand; centralized and coordinated

eCPRI: enhanced Common Public Radio Interface, • Advanced version of CPRI• Ethernet based IP packet flows; only when traffic is present (not point-to-point like CPRI)• BBU can be running on COTS platforms• Difficult to synchronize RRH and BBU due to bursty traffic

Cloud RAN – Supports More Splits

A CU may support multiple DUs and A DU may support multiple RUs.

Further disaggregate BBU into real-time and non-real-time functions into DU & CU

Move away from vendor lock-in, Reach out to open IP/Ethernet based technologies

RU: Radio UnitDU: Distributed/Data UnitCU: Control/ Centralized Unit

Page 4: ORAN Saidhiraj Amuru CeWit 5G KS · P } Ç Z ] } h v ] P } Ç Z ] } h v ] h^ rW o v t^ o ] W } ] v ó r î Æ ] v h> ( } EZ h v o ] l ] v Z > U Z Zh P } Ç

2/3/2020

4

Where to split CU-DU and DU-RU?

MidHaul – Option 2FrontHaul – Option 7 and 8

• Transport time/frequency domain IQ samples over FH • Scales with number of antennas/ streams (MIMO layers)• Variable data rates and variable latencies supported

Split between PDCP and RLC

BW requirement increases

Low latency requirements

Where to split CU-DU and DU-RU?

Options Option 6 Option 7.3 Option 7.2 Option 7.1 Option 8

Data Rates 100 Mbps 300 Mbps 300Mbps *(2*16)*P/8 1.2 Gbps* P*nTxRU 1.2 Gbps*P*nTxRu *nTx

Assumptions:• 100 Mbps MAC to PHY Data rate• 1/3 Coding Rate• 256 QAM Modulation Order (16 bits per I and Q)• P = Number of Antenna Ports• nTxRU = Number of RF chains• nTX = Number of transmission Antennas

NR perspective:

Option 7.2=> 3300*(2*16)*8 (layers)*13 (OFDM)/0.5 ms ~ 20 GbpsOption 8 => 61440 Msps*32*64/0.5 ms ~ 250 Gbps

Page 5: ORAN Saidhiraj Amuru CeWit 5G KS · P } Ç Z ] } h v ] P } Ç Z ] } h v ] h^ rW o v t^ o ] W } ] v ó r î Æ ] v h> ( } EZ h v o ] l ] v Z > U Z Zh P } Ç

2/3/2020

5

Enter X-RAN and O-RAN

• xRAN/O-RAN’s background• Started in June 2016 as xRAN Forum and later merged with C-RAN Alliance to form ORAN alliance in February 2018 • Operator driven: AT&T, China Mobile, Deutsche Telekom, NTT DOCOMO and Orange• Driven by openness and intelligence

• ORAN is not just open source software• Defines a white-box architecture• Open APIs• Open Architectures• Open Hardware• Open Interfaces

• Advantages• Multi-vendor deployment• Increases scalability• Decreases CAPEX & OPEX• Endless innovations

• Disadvantages• More effort in testing systems integration of multi-vendor systems

O-RAN Vision

• Two fold functional split• Horizontal split

• Splits radio protocol stack – various options• Vertical split

• Separates CP & UP functions

• Interfaces• Open FH between O-DU and O-RU• F1 between O-DU and O-CU• E1 between CU-CP and CU-UP• E2 between RIC RT and CU/DU• A1 between NMS and RIC RT

• RAN Intelligent Controller (RT-RIC)• RRM, mobility real time operations• Uses a machine learning model trained in the

non real time RIC

Figure courtesy: O-RAN Forum

Page 6: ORAN Saidhiraj Amuru CeWit 5G KS · P } Ç Z ] } h v ] P } Ç Z ] } h v ] h^ rW o v t^ o ] W } ] v ó r î Æ ] v h> ( } EZ h v o ] l ] v Z > U Z Zh P } Ç

2/3/2020

6

ORAN Standardization

• Operator Working Group• Technical Steering Committee• Working Groups

• WG1 - Use Cases and Overall Architecture Workgroup• WG2 - Non-real-time RIC and A1 Interface Workgroup• WG3 - Near-Real-time RIC and E2 Interface Workgroup• WG4 - Open Fronthaul Interfaces Workgroup• WG5 - Open F1/W1/E1/X2/Xn Interface Workgroup• WG6 - Cloudification and Orchestration Workgroup• WG7 - White-box Hardware Workgroup• WG8 - Stack Reference Design Workgroup

• Focus Groups• OSFG - Open Source Focus Group• SDFG - Standard Development Focus Group• TIFG - Test & Integration Focus Group

• O-RAN Software Community

O-RAN Split Architecture

• O-RAN has selected a single split point, known as “7-2x” but allows a small variation.

End-to-End Latency Very strictRelaxed

FH Capacity RequirementLow Very high

F1 eCPRI

236 GbpsFew Gbps

Page 7: ORAN Saidhiraj Amuru CeWit 5G KS · P } Ç Z ] } h v ] P } Ç Z ] } h v ] h^ rW o v t^ o ] W } ] v ó r î Æ ] v h> ( } EZ h v o ] l ] v Z > U Z Zh P } Ç

2/3/2020

7

O-RAN FrontHaul Interface

Traffic is classified into two types: CUS-Plane and M-Plane

CUS Plane: Control / User / Synchronization Plane• Covers real-time control-plane communications between the DU and RU

• Covers user plane traffic in DL and UL between DU and RU

• Covers synchronization of the RU generally sources from the DU

• Uses Ethernet transport and eCPRI/IEEE 1914.3 radio application transport

M-Plane: Management Plane• Covers management of the Radio Unit (RU) as governed by the DU

• Provides all non-real-time control of the RU (Real time control uses the C-Plane)

• Uses Ethernet(UDP/IP) transport

CUS-Plane – Category A and Category B RUs

Two types of RU are considered

Category A:• Precoding function is in DU allowing the RU

design to be simple

• The FH interface will carry spatial streams in the DL which can be larger than layers

Category B:• Precoding is in RU which makes RU design

complex

• The FH interface will carry spatial layers which can be less data

• This category allows modulation compression which reduces the DL throughput much more

Page 8: ORAN Saidhiraj Amuru CeWit 5G KS · P } Ç Z ] } h v ] P } Ç Z ] } h v ] h^ rW o v t^ o ] W } ] v ó r î Æ ] v h> ( } EZ h v o ] l ] v Z > U Z Zh P } Ç

2/3/2020

8

CUS-Plane – Split Point 7-2x in DL for NR

Category A Radio Unit Category B Radio Unit

CUS-Plane – Split Point 7-2x in UL for NR

• Unlike in the DL case, the RU category makes no difference in UL

• FFT, CP removal and filtering in the O-RU

• Rest of all the PHY functions in the O-DU

Page 9: ORAN Saidhiraj Amuru CeWit 5G KS · P } Ç Z ] } h v ] P } Ç Z ] } h v ] h^ rW o v t^ o ] W } ] v ó r î Æ ] v h> ( } EZ h v o ] l ] v Z > U Z Zh P } Ç

2/3/2020

9

CUS-Plane – Encapsulation

Ethernet is the selected transport, and all radio application data is conveyed within the Ethernet Payload.

The radio transport header is used to convey some radio-specific transport information, while the radio transport payload carries the C-Plane & U-Plane information.

Destination MACAddress(6 Bytes)

Source MACAddress(6 Bytes)

Type/Length(Ethertype)(2 Bytes)

Payload(42…1500 Bytes)

FCS(4 Bytes)

VLAN Tag(4 Bytes)

Preamble(8 Bytes)

IFG(12 Bytes)

Native Ethernet frame with VLAN

all radio transport & application data

Radio transport Payload(up to 1444 bytes,

or longer for jumbo Ethernet frames)

Radio transportheader

(8 bytes)

Source: O-RAN FrontHaul Working Group: CUS Plane Specification

CUS-Plane – Radio Transport Header

• There are two possible radio transport mechanisms, eCPRI (mandatory) and IEEE 1914.3 RoE (optional).

• For ease of implementation, these are aligned as closely as possible to make implementing both as easy as possible.

• Both use 8-byte headers with the exact same information content and format in 6 of the 8 bytes; only the first two bytes differ

all section types

0 (msb) 1 2 3 4 5 6 7 (lsb) # of bytes

ecpriVersion ecpriReserved ecpriConcatenation

1 Octet 1

ecpriMessage 1 Octet 2

ecpriPayload 2 Octet 3Octet 4

ecpriRtcid 2 Octet 5Octet 6

ecpriSeqid 2 Octet 7Octet 8

dataDirection payloadVersion filterIndex 1 Octet 9

frameId 1 Octet 10

subframeId slotId 1 Octet 11

slotId startSymbolid 1 Octet 12

Octet M

all section types

0 (msb) 1 2 3 4 5 6 7 (lsb) # of bytes

subType 1 Octet 1

flowID (currently unused) 1 Octet 2

Length 2 Octet 3Octet 4

orderinfo 2 Octet 5Octet 6Octet 7Octet 8

dataDirection payloadVersion filterIndex 1 Octet 9

frameId 1 Octet 10

subframeId slotId 1 Octet 11

slotId startSymbolid 1 Octet 12

Octet M

eCPRI IEEE-1914.3

Source: O-RAN FrontHaul Working Group: CUS Plane Specification

Transport Header Radio Application Header

Page 10: ORAN Saidhiraj Amuru CeWit 5G KS · P } Ç Z ] } h v ] P } Ç Z ] } h v ] h^ rW o v t^ o ] W } ] v ó r î Æ ] v h> ( } EZ h v o ] l ] v Z > U Z Zh P } Ç

2/3/2020

10

C-Plane Specification – Section Types

• eCPRI message type-2 maps to C-plane message in ORAN

• In general there are “data sections” which identify which symbols / portions of symbols (e.g. PRBs) are addressed.

• C-Plane:• sectionType=0 : DL idle/guard periods - allows Tx blanking for power savings• sectionType=1 : DL/UL Channels - provides mapping of beamforming index or weights to REs• sectionType=3 : PRACH and mixed-numerology channels• sectionType=5 : UE scheduling Info - provides UE co-scheduling info allowing real-time BF weight calculation on the

RU• sectionType=6 : UE channel info - provides UE channel info to guide real-time BF weight calculation on the RU• sectionType=7 : LAA Support – provides information specific to LAA especially listen-before-talk operation

Example: C-Plane Section Type 0

Values specific to idle/guard periodstimeOffset = number of samples from start of slot to start of CPframeStructure = 4 bits for FFT size, 4 bits for subcarrier spacingcpLength = cyclic prefix length, based on sample rate and m

Control information here describes empty-data PRBs allowing the RU to blank transmissions for energy-savings;

Section Type 0 : idle / guard periods0

(msb)1 2 3 4 5 6 7

(lsb)# of bytes

transport header 8 Octet 1dataDirection

payloadVersion filterIndex 1 Octet 9

frameId 1 Octet 10subframeId slotId 1 Octet 11

slotId startSymbolid 1 Octet 12numberOfsections 1 Octet 13

sectionType 1 Octet 14timeOffset 2 Octet 15

frameStructure 1 Octet 17cpLength 2 Octet 18reserved 1 Octet 20sectionId 1 Octet 21

sectionId rb symInc startPrbc 1 Octet 22startPrbc 1 Octet 23numPrbc 1 Octet 24reMask 1 Octet 25

reMask numSymbol 1 Octet 26reserved (16-bits) 2 Octet 27

…sectionId = P 1 Octet N

sectionId rb symInc startPrbc 1 N+1startPrbc 1 N+2numPrbc 1 N+3reMask 1 N+4

reMask numSymbol 1 N+5reserved (16-bits) 2 N+6

Octet M

Transport Header Radio Application Header Section Header #1 Section Header #n. . .

Page 11: ORAN Saidhiraj Amuru CeWit 5G KS · P } Ç Z ] } h v ] P } Ç Z ] } h v ] h^ rW o v t^ o ] W } ] v ó r î Æ ] v h> ( } EZ h v o ] l ] v Z > U Z Zh P } Ç

2/3/2020

11

Example: C-Plane Section Type 1

Common radio application header:Similar for all C-Plane messages

Repeated data sections as needed

transport header: eCPRI or IEEE-1914.3dataDirection: 0=UL, 1=DL

filterIndex points to channel filter in RU, usually 0x1frameId points to specific 10ms frame

SubframeId : points to specific 1ms subframe within a frameslotId : points to specific slot within a frame

numberOfsections : number of sections in this messageSectionType : msg applies to 1=DL, 2=UL radio channels

(only one sectionType per C-Plane message)

udCompHdr : states IQ bit width and compression method forchannel IQ data for all sections in this message

Upper 4 bits: iqWidth (range 1-16 bits)Lower 4 bits : compMeth compression method

section extension may be present based on “ef” valueSectionID : value allows matching of C and U plane msgs

rb : 0=use every PRB, 1=use every other PRBStartPrbc : first PRB this section applies to

numPrbc : number of PRBs this section applies toreMask : states population of REs in the PRB

numSymbol : number of symbols this section applies towf : 0 = no weights provided, 1 = weights follow the beamIdbeamId : index into predefined weight table for this section

section extension may be present based on “ef” value

Section Type 1 : DL/UL control msgs0

(msb)1 2 3 4 5 6 7

(lsb)# of bytes

transport header 8 Octet 1dataDirection

payloadVersion filterIndex 1 Octet 9

frameId 1 Octet 10subframeId slotId 1 Octet 11

slotId startSymbolid 1 Octet 12numberOfsections 1 Octet 13

sectionType 1 Octet 14udCompHdr 1 Octet 15

reserved 1 Octet 16sectionId 1 Octet 17

sectionId rb symInc startPrbc 1 Octet 18startPrbc 1 Octet 19numPrbc 1 Octet 20reMask 1 Octet 21

reMask numSymbol 1 Octet 22ef beamId 1 Octet 23

beamId 1 Octet 24<section extensions if any> 0-var

…sectionId = P 1 Octet N

sectionId rb symInc startPrbc 1 N+1startPrbc 1 N+2numPrbc 1 N+3reMask 1 N+4

reMask numSymbol 1 N+5ef beamId 1 N+6

beamId 1 N+7<section extensions if any> 0-var N+8

beamID value 0x0000 reserved specifically for “no beamforming”. This is primarily for SRS but could be used more generally too..

0 (msb) 1 2 3 4 5 6 7 (lsb)iqWidth compMeth

range: 1-16 bits0 = 16 bits1= 1 bit…15 = 15 bits

0 = no compression1 = block floating point2 = block scaling3 = m-law compression4 = modulation compression5-15 = reserved

udCompHdr

Transport Header Radio Application Header Section Header #1 Section Header #n. . .

U-Plane Data

• The U-Plane is used to send actual IQ data as arranged in spatial streams or layers, already mapped into the resource elements

• Data is transported in compressed format if compression is enabled

• Data is transmitted symbol by symbol as U-Plane messages.

• There is no sectionType, reMaskor numberOfsections parameter for U-Plane messages;

• the sectionType and reMaskvalues are inferred from the matching C-Plane SectionId.

U-Plane Format – All Section Types0 (msb) 1 2 3 4 5 6 7 (lsb) # of

bytestransport header 8 Octet 1

datDirection

payloadVersion filterIndex 1 Octet 9

frameId 1 Octet 10subframeId slotId 2 Octet 11

slotId symbolId Octet 12sectionId 1 Octet 13

sectionId rb symInc startPrbu 1 Octet 14startPrbu 1 Octet 15numPrbu 1 Octet 16

compParam 1 Octet 17iSample (1st sample) 1 Octet 18qSample (1st sample) 1 Octet 19

…iSample (12th sample) 1 Octet 40

qSample (12th sample) + padding when needed 1 Octet 41compParam 1 Octet 42

iSample (1st sample) 1 Octet 43qSample (1st sample) 1 Octet 44

…iSample (12th sample) 1 Octet 65

qSample (12th sample) + padding when needed 1 Octet 66…

sectionId = P 1 Octet OsectionId=P rb symInc startPrbu 1 O+1

startPrbu 1 O+2numPrbu 1 O+3

compParam 1 O+5iSample (1st sample) 1 O+6qSample (1st sample) 1 O+7

Common radio application header:Same for all U-Plane messages

SectionID : value allows matching of C and U plane msgsrb : 0=use every PRB, 1=use every other PRB

StartPrbu : first PRB this section applies tonumPrbu : number of PRBs this section applies to

compParam* : compression parameter for following IQ samplesiSample, qSample : variable-length samples for I & Q data

(shown here, I or Q bit width = 8 bits)

Each PRB (12 REs) gets a new compression parameterNote each new compParam is always on a byte boundary regardless of

IQ sample size but for some compression methods the compParamvalue is not needed so the field is omitted

Octet count assumes 8-bit I and Q samples

Page 12: ORAN Saidhiraj Amuru CeWit 5G KS · P } Ç Z ] } h v ] P } Ç Z ] } h v ] h^ rW o v t^ o ] W } ] v ó r î Æ ] v h> ( } EZ h v o ] l ] v Z > U Z Zh P } Ç

2/3/2020

12

Subcarriers

CRS

CSI-RS

User data

symbols

Use of data sections in PRBs (LTE example)

0 1 2 3 4 5 6 7 8 9 10 11 12 13

11

10

9

8

7

6

5

4

3

2

1

0

SSS data

PSS data

PBCH data

zero data

UE#1 data

UE#2 data

SSS/PSS and PBCH shown although will not be in all PRBs. It is assumed those symbols will use the same broadcast beam so can share the same data section. UE#1 data is shown in two PRBs (would typically be more) and UE#2 data in one PRB. Punctured CRS and CSI-RS REs are shown though some of those REs will be zero.

Source: X-RAN FrontHaul Tutorial

Use of data sections in PRBs (LTE example)

UE#1 data

UE#2 data

1 2 3 4 5 6 7 8 9

1 A B C D E F G H

Seventeen sections needed to specify these PRBs:sectionId 1: reMask = 1111 1111 1111 (broadcast beam for SSS, PSS, PBCH)sectionId 2: reMask = 1011 1111 1111 (UE#1 REs, all REs are user data)sectionId 3: reMask = 0110 1101 1011 (UE#1 REs, numbered from bottom)sectionId 3: reMask = 1001 0010 0100 (CRS REs, complementary reMask) sectionId 4: reMask = 1111 1111 1111 (UE#1 REs)sectionId 5: reMask = 0110 1101 1011 (UE#1 REs, numbered from bottom)sectionId 5: reMask = 1001 0010 0100 (CRS REs, complementary reMask) sectionId 6: reMask = 1111 1111 1111 (UE#1 REs)sectionId 7: reMask = 1111 1100 0011 (UE#1 REs)sectionId 7: reMask = 0000 0011 1100 (CSI-RS REs)sectionId 8: reMask = 0110 1101 1011 (UE#1 REs, numbered from bottom)sectionId 8: reMask = 1001 0010 0100 (CRS REs, complementary reMask) sectionId 9: reMask = 1111 1111 1111 (UE#1 REs)sectionId A: reMask = 1011 1111 1111 (UR#2 all REs are user data)sectionId B: reMask = 0110 1101 1011 (UE#2 REs, numbered from bottom)sectionId B: reMask = 1001 0010 0100 (CRS REs, complementary reMask) sectionId C: reMask = 0000 1111 1111 (UE#2 REs)SectionId C: reMask = 1111 0000 0000 (CSI-RS REs)sectionId D: reMask = 1111 1111 1111 (UE#2 REs)sectionId E: reMask = 0110 1101 1011 (UE#2 REs, numbered from bottom)sectionId E: reMask = 1001 0010 0100 (CRS REs, complementary reMask) sectionId F: reMask = 1111 1100 0011 (UE#2 REs)sectionId G: reMask = 0110 1101 1011 (UE#2 REs, numbered from bottom)sectionId G: reMask = 1001 0010 0100 (CRS REs, complementary reMask) sectionId H: reMask = 1111 1111 1111 (UE#2 REs)

Source: X-RAN FrontHaul Tutorial

Page 13: ORAN Saidhiraj Amuru CeWit 5G KS · P } Ç Z ] } h v ] P } Ç Z ] } h v ] h^ rW o v t^ o ] W } ] v ó r î Æ ] v h> ( } EZ h v o ] l ] v Z > U Z Zh P } Ç

2/3/2020

13

U-Plane Data: Compression

• The data rates increase linearly with spatial streams (or layers) in split option 7.2x.

• Various compression methods are currently supported.• No Compression, Block Floating Point, Block Scaling, μ -law compression, Modulation Compression

• The block compression methods are performed on Physical Resource Block (PRB = 12 subcarriers) basis

• Example:• 16 bits I and Q• 9 bits mantissa – includes 1 sign bit• 8 bits exponent (4 for I and 4 for Q)

• Without BFP compression• 1 PRB = 12 (Subcarriers) * 16 (bits) * 2 (I and Q) = 384 bits

• With BFP compression• 1 PRB = 12 (Subcarriers) * 9 (bits) * 2 (I and Q) + 8 (exponent) = 224 bits

• Compression Ratio = 0.5833

#1 #2 #3 #4 #12

384 bits

#1 #2 #3 #4 #12 Exp

224 bits

C/U-Plane – message timing

• In general, C-Plane messages precede U-Plane messages, and a single C-Plane message may cover multiple U-Plane messages.

Page 14: ORAN Saidhiraj Amuru CeWit 5G KS · P } Ç Z ] } h v ] P } Ç Z ] } h v ] h^ rW o v t^ o ] W } ] v ó r î Æ ] v h> ( } EZ h v o ] l ] v Z > U Z Zh P } Ç

2/3/2020

14

IQ Data Transfer Procedure

Delay Management (S-plane)

• The transmission windows and reception windows are determined based on:• The processing time• Receiver buffer lengths• Transport network delay variation

• In Downlink, the DU has to send data early enough to ensure the corresponding symbol time and also that it does not send data too early, risking overflow of the RU buffers

• In Uplink, the data must be received early enough to ensure the DU can process the data in time to meet HARQ loop restrictions.

• Not all U-Plane data is delay managed.

• Non-Delay managed traffic such as SRS data are sent on “best-effort” basis.

Page 15: ORAN Saidhiraj Amuru CeWit 5G KS · P } Ç Z ] } h v ] P } Ç Z ] } h v ] h^ rW o v t^ o ] W } ] v ó r î Æ ] v h> ( } EZ h v o ] l ] v Z > U Z Zh P } Ç

2/3/2020

15

Delay Management: DL

Source: O-RAN FrontHaul Working Group: CUS Plane Specification

ORAN Advantages and Summary

• Interface simplicity: Transfer of user plane data is based on Resource Elements / Physical Resource Blocks, which reduces complexity

• Transport Bandwidth Scalability: • Lower split options (e.g., splits 7-1 and 8) scale based on number of antennas. • In contrast, 7-2x interface scales based on “streams”, which allows using high number of antennas

without higher transport bandwidth. • User data transfer can be optimized to send only PRBs that contain user data for purpose of reducing

transport bandwidth (DMRS etc generated in RU)

• Less user specific parameters are used at split 7-2x (when compared to higher split options) -> simplified design

• Moves away from single-vendor design lock-in for operators

• Several new companies can contribute to individual portions of the entire design• Better enhanced start-up community

Page 16: ORAN Saidhiraj Amuru CeWit 5G KS · P } Ç Z ] } h v ] P } Ç Z ] } h v ] h^ rW o v t^ o ] W } ] v ó r î Æ ] v h> ( } EZ h v o ] l ] v Z > U Z Zh P } Ç

2/3/2020

16

Back Up Slides

U-Plane Data: Modulation Compression

• To represent the constellation points as I and Q values that also overlap allowing multiple constellation sizes to be represented by a single word-width, the constellations are “shifted” to allow a twos-complement I and Q value to represent any constellation point.

• For Decompression, un-shift the constellation and multiply with a scale factor based on modulation order

• Applicable only to DL

• Data rates almost same as split option 7.3

• Completely lossless compression

X X X X X X X X

X X X X X X X X

X X X X X X X X

X X X X X X X X

X X X X X X X X

X X X X X X X X

X X X X X X X X

X X X X X X X X

BPSK (normal, p/ 4, p/ 2)encodes 1 user bit

X X X X

X X X X

-3/4 -1/4 1/4 3/4

X X X X

X X X X

X X

-1/2 1/2

X X

I is represented by 2 bitQ is represented by 2 bits(-1/ 2, 0, and 1/ 2 are needed)

modulat ion-compression:from 32 bit s (16I and 16Q)to 4 bit s (2I and 2Q)

I is represented by 1 bitQ is represented by 1 bit

modulat ion-compression:from 32 bit s (16I and 16Q)to 2 bit s (1I and 1Q)

I is represented by 2 bitsQ is represented by 2 bits

modulat ion-compression:from 32 bits (16I and 16Q)to 4 bit s (2I and 2Q)

I is represented by 3 bitsQ is represented by 3 bits

modulat ion-compression:from 32 bit s (16I and 16Q)to 6 bit s (3I and 3Q)

QPSKencodes 2 user bits

16 -QAMencodes 4 user bits

64-QAMencodes 6 user bits

X X-1/2 1/2

Page 17: ORAN Saidhiraj Amuru CeWit 5G KS · P } Ç Z ] } h v ] P } Ç Z ] } h v ] h^ rW o v t^ o ] W } ] v ó r î Æ ] v h> ( } EZ h v o ] l ] v Z > U Z Zh P } Ç

2/3/2020

17

U-Plane Data: Modulation Compression

Assumptions: 64 TRX, Max Qm = 256 QAM, 100 MHz, 16 Spatial streams

• W/O modulation compression using block compression methods• 1 PRB = 12 x 2 x 8 bits mantissa + 8-bits exponent = 200 bits• DL data rate: 14 (symbols) x 273 (PRBs) x 200 x 16 (spatial streams) / 0.5 ms = 24.46 Gbps

• W/ modulation compression:• 1 PRB = 12 x 8 bits = 96 bits• DL data rate: 14 (symbols) x 273 (PRBs) x 96 x 16 (spatial streams) / 0.5 ms = 11.74 Gbps

FH: eCPRI data rates

• Throughput: 3/1.5 Gbps (downlink/uplink, end-user data rate, transport block from/to MAC)

• Air bandwidth: 100 MHz (5 * LTE20) -> 500 PRB

• Number of downlink MIMO-layers: 8 Number of uplink MIMO-layers: 4 (with 2 diversity streams per uplink MIMO layer)

• MU-MIMO: No

• TTI length: 1 ms

• Digital beamforming where BF-coefficients calculation is performed in O-DU

• Rate matching assumptions: Code rate: ~0.80

• Modulation scheme (Downlink & Uplink): 256 QAM

• Number of antennas: 64

• Sub-carrier spacing: 15 kHz

• IQ sampling frequency: 122.88 Msps (3.84*32)

• IQ-format: 30 bits per IQ-sample

• No IQ compression

Page 18: ORAN Saidhiraj Amuru CeWit 5G KS · P } Ç Z ] } h v ] P } Ç Z ] } h v ] h^ rW o v t^ o ] W } ] v ó r î Æ ] v h> ( } EZ h v o ] l ] v Z > U Z Zh P } Ç

2/3/2020

18

eCPRI

• Open protocol for fronthaul

• Allows data transfer over packet based network: IP or ethernet

• Allows various split options option 7.1, 7.2, 8 etc• CPRI does only Option 8

• Analog IQ has high BW requirement for 5G and hence CPRI breaks• eCPRI based on split has data rate requirements ranging from 10G to 200G (Option 8)

• eCPRI has C-plane, M-Plane, U-Plane, S-Plane• Control and management plane manage DU and RU -> Operation, maintenance, not time critical• U-plane carries 5G NR control channels, data channels• S-plane is for synch between DU and RU, frame and time alignment

• eCPRI allows different message types• 256 message types

• Packing of messages, forming of messages is where ORAN comes into picture

Functional Decomposition (eCPRI)

• Intra Phy splits ID, IID Iv

Page 19: ORAN Saidhiraj Amuru CeWit 5G KS · P } Ç Z ] } h v ] P } Ç Z ] } h v ] h^ rW o v t^ o ] W } ] v ó r î Æ ] v h> ( } EZ h v o ] l ] v Z > U Z Zh P } Ç

2/3/2020

19

Functional Splits – 7.X

Delay Management: Model

Model uses reference points from CPRI delay model• Downlink: R1 – DU transmit port

R2 – RU receive portT12 – Transmission time

• Uplink: R3 – RU transmit port; R4 – DU receive port;T34 – Transmission time

• Transport Variation in network (T12max – T12min)All transmit/ receive times relative to antenna (“Ra”)

• Model defines transmission/ reception in terms of symbol time over the air• T1a – Transmit time from DU relative to transmission over the air • T2a – Receive time at RU relative to transmission over the air• Ta3 – Transmit time from RU relative to reception over the air• Ta4 – Receive time at RU relative to reception over the air

• Since transmission time (T12/ T34) varies, T2a/ Ta4 MUST vary• Receive window at: RU (T2a_max – T2a_min); DU (Ta4max – Ta4min)• Transmission Window: Earliest/ latest transmit time to ensure reception in corresponding (DL/ UL) reception window

Reception Window Transmission Window Transport Variation

Downlink T2amax – T2amin T1amax – T1amin T12max – T12min

Uplink Ta4max – Ta4min Ta3max – Ta3min T34max – T34min