Functional Split Options in C-RAN Architecture

Functional Split Options in C-RAN Architecture Abstract This document is made for personal use only. Proposals for functional split options in C-RAN architecture for 5G networks particularly by 3GPP, NGFI, and Small Cell Forum are discussed. The main objective of this document is to review functional split options proposed by the aforementioned bodies. Readers are expected to read the references for further in-depth information. Acknowledgments The author acknowledges solely the mentioned references in the document. This document is an abridge form of the information in those references. The information in this document can be found exactly or partially presented in the references. The author is not liable for any misinterpretation the document may lead, and it’s readers’ sole responsibility to understand and use the information in the document SAHA Rony Kumer, Ph.D. at their own accords.

06 SEP 2018

Page 0 of 30

CONTENTS 1. FUNCTIONAL SPLIT RATIONALE

2. 3GPP FUNCTIONAL SPLIT OPTIONS 2.1. Description 2.2. Observation and Analysis 2.3. Architectural and Specification Aspects and UP-CP Separation Issues [7] 2.3.1. Architectural and Specification Aspects 2.3.2. UP-CP Separation Issues on Functional Split Options 3. NGFI FUNCTIONAL SPLIT OPTIONS 3.1. Description 3.2. Observation and Analysis 4. SMALL CELL FORUM FUNCTIONAL SPLIT 4.1. Description 4.2. Observation and Analysis REFERENCES

APPENDIX: LTE BACKGROUND A.1 LTE downlink signal generation chain A.2 eNodeB Transceiver Chain A.3 Layer 2 Functionalities A.4 Layer 3 Functionalities (RRC) REFERENCES (FOR APPENDIX)

06 SEP 2018

Page 1 of 30

1. FUNCTIONAL SPLIT RATIONALE The future 5G system is required to support an increase factor of 10-100 times of the transmission user data rate and devices with delays as low as a few milliseconds [1-2]. Operators are facing the challenges to satisfy the explosion of data usage while reducing the cost. To address such constraints, CRAN has been proposed. In current Long-Term Evolution (LTE), eNodeB (eNB) contains two main parts: Baseband Unit (BBU) and Remote Radio Head (RRH). RRH is connected to BBU through optical fibers. CRAN remotes BBUs from RRHs and mitigates them to a BBU pool for centralized processing [3]. The current widely used interface protocol for In-phase (𝐼) and Quadrature (𝑄) data transmission between RRHs and BBUs is Common Public Radio Interface (CPRI) [4]. The estimated 𝐼𝑄 data throughput exceeds 10 Gbps for a 3 sector Base Station (BS) with 20 MHz 4×4 MIMO. A BBU pool which connects 10-1000 BSs will need vast transmission bandwidth in the fronthaul [5], which is one of the main issues of C-RAN. This is because, the raw 𝐼𝑄 samples transmitted between RRHs and BBUs consume too much bandwidth of the transport network. Solutions such as reducing signal sampling rate, applying non-linear quantization, frequency sub-carrier compression and 𝐼𝑄 data compression have been proposed in literature such as [6]. Alternatively, changing the current functional split architecture between RRH and BBU has been considered as one of the promising solution to overcome such high bandwidth and tight latency requirements [7]. Standardization bodies and forums such as 3GPP, NGFI, and Small Cell Forum have been actively investigating such functional split architecture. In this document, we mainly discuss the proposals for functional split options from 3GPP standard, NGFI, and small cell forum as baseline research.

2. 3GPP FUNCTIONAL SPLIT OPTIONS 2.1. Description Figure 1 shows recommended functional splits between the central unit (CU) and distributed unit (DU) for E-UTRA, with a provision that the final conclusion may need to be revised for new radio (NR) once it is defined. Factors related to radio network deployment scenarios, constraints, and intended supported services such as supporting specific QoS settings per offered services (e.g., low latency, high throughput), user density and load demand per given geographical area to address the degree of RAN coordination, and transport networks with different performance levels (e.g., ideal and non-ideal) define the choice of NR functional split in the architecture.

06 SEP 2018

Page 2 of 30

RRC

Data

HighRLC

PDCP

Option 1

RRC

Option 2

PDCP

LowRLC

Option 4

Option 3

HighRLC

HighMAC

LowRLC

LowMAC

Option 5

HighMAC

HighPHY

Option 6

LowMAC

Low-PHY

Option 7

HighPHY

RF

Option 8

Low-PHY

RF

Data

Fig.1. 3GPP Function Split between central and distributed unit [7]. A number of options, based on how much functional processing we would leave between the CU and DU, have been proposed by 3GPP as given in Table 1 in terms of their features, pros, and cons. 2.2. Observation and Analysis Observation -

Option 6 (i.e., MAC/PHY split option) demands low BW but tight latency requirements Option 1 (i.e., RRC/PDCP split option) demands the least both BW and latency requirements, and PHY/RF the most of all options. Though Intra-MAC split option demands low BW requirement, its latency demand has not been clarified yet. Only baseline result (LTE Dual Connectivity) for option 2 (i.e., PDCP/RLC split option) is available.

Analysis -

-

Throughput requirement: As split options are chosen at from a higher to a lower layer, i.e. from the split option 2 to option 8 (i.e., PHY/RF split option), the demand of BW requirement increases, with the lowest for option 2 and the highest for option 8. Latency requirement: Split options 6 and above demand tight latency requirement, whereas split options 4 (i.e., RLC/MAC split option) and below demand loose, with option 5 (i.e., intra-MAC split option) unclarified.

06 SEP 2018

Page 3 of 30

Table 1. 3PP functional split options recommendation [7]. Options 1 (RRC-PDCP split)

Central unit RRC

Distributed unit PDCP, RLC, MAC, physical layer and RF

2 (PDCPRLC split)

RRC, PDCP

RLC, MAC, physical layer and RF

2-1 (split U-plane only)

2-2

3 (intra RLC split: high RLC and low RLC split)

26June2017

3-1 Split based on ARQ

Feature 1. Entire user plane (UP) is in the DU

Low RLC (partial function of RLC), MAC, physical layer and RF

Cons

1. Allows a separate UP and a centralized RRC/RRM 2. May support handling some edge computing and low latency use cases for user data located close to the transmission end

1. Securing the interface between RRC and PDCP may be affected 2. Support for aggregation is not clarified yet for this option

1. Low RLC composed of segmentation functions

1. Have already been standardized for LTE Dual Connectivity, resulting most straightforward option and incremental efforts required to standardize 1. Can allow traffic aggregation from and facilitate traffic load management between NR and EUTRA transmission points 1. Allows a separate UP and a centralized RRC/RRM 2. Enables centralization of PDCP layer, which may scale with UP traffic load 1. ARQ may provide centralization or pooling gains

2. High RLC may be composed of ARQ and other RLC functions

2. Have better flow control across the split

3. High RLC segments RLC PDU based on the status reports and Low RLC segments RLC PDU into the available MAC PDU

3. Can allow traffic aggregation from and facilitate traffic load management between NR and E-

1. In addition to option 2-1, it can be achieved by separating the RRC and PDCP for the CP stack and the PDCP for the UP stack into different central entities

PDCP and high RLC (the other partial function of RLC)

Pros

1. Coordination of security configurations between different PDCP instances is needed

1. More latency sensitive than the split with ARQ in DU since re-transmissions are susceptible to transport network latency over a split transport network

3-2 split based on Tx RLC and Receive RLC

4 (RLC-MAC split)

PDCP and RLC

5 (intra MAC split)

PDCP, RLC, higher part of the MAC layer (High-

High-MAC

MAC, physical layer and RF RF, physical layer and lower part the MAC layer (Low-MAC)

resources

UTRA transmission points

1. Low RLC may be composed of transmitting TM RLC entity, and High RLC may be composed of receiving TM RLC entity

1. Insensitive to the transmission network latency between CU and DU, but also uses interface format inherited from the legacy interfaces of PDCP-RLC and MAC-RLC

1. Two buffers are needed for transmission, one at the CU, and one at the DU in order to perform RLC TX

2. Flow control is in the CU and for that a buffer in the CU is needed. The TX buffer is placed in the DU, so that the flow controlled traffic from the CU can be buffered before being transmitted To be revised with NR protocol stack knowledge

1. The centralized scheduling 2. The inter-cell interference coordination can be in charge of interference coordination methods such as JP/CS CoMP

06 SEP 2018

1. Reduce the bandwidth needed on fronthaul 2. Reduce latency requirement on fronthaul (if HARQ processing and cell-specific MAC functionalities are performed in the DU)

1. Complexity of the interface between CU and DU 2. Difficulty in defining scheduling operations over CU and DU

Page 5 of 30

Low-MAC

MAC)

3. Time critical functions such as the functions with stringent delay requirements (e.g. HARQ) or the functions where performance is proportional to latency (e.g. radio channel and signal measurements from PHY, random access control)

3. Efficient interference management across multiple cells and enhanced scheduling technologies such as CoMP and CA with multi-cell view

4. Limitations for some CoMP schemes (e.g., UL JR).

4. Radio specific functions can perform scheduling-related information processing and reporting.

6 (MAC-PHY split)

7 (intra PHY split)

7-1 (UL+DL)

PDCP, RLC, MAC

PDCP, RLC, MAC, part of physical layer

Physical layer and RF

Part of physical layer function and RF

5. Measure/estimate the served UE’s statistics and report periodically 1. The interface between the CU and DUs carries data, configuration, and schedulingrelated information (e.g., MCS, Layer Mapping, Beamforming, Antenna Configuration, resource block, and allocation) and measurements

1. In the UL, FFT, and CP removal reside in the DU. Two subvariants are possible 2. In the downlink, IFFT and CP

06 SEP 2018

1. In the UL, FFT, CP removal and possibly PRACH filtering functions reside in the DU 2. In the DL, IFFT and CP addition functions reside

3. Scheduling decision between CU and DU will be subject to fronthaul delays impacting performances for non-ideal fronthaul and short TTI

1. Can reduce the fronthaul requirements in terms of throughput to the baseband bitrates as the payload is transport block bits 2. Joint Transmission and centralized scheduling are possible as MAC is in CU 3. Allows resource pooling for layers including and above MAC 1. Can reduce the 1. Allows the fronthaul implementation requirements in of advanced terms of receivers throughput 2. Centralized scheduling, e.g. CoMP, and joint processing (both transmit and

1. May require subframe-level timing interactions between MAC layer in CU and PHY layers in DUs 2. Round trip fronthaul delay may affect HARQ timing and scheduling 1. May require subframe-level timing interactions between part of PHY layer in CU and part of PHY layer in DUs

Page 6 of 30

addition reside in the DU. Three subvariants are possible 7-2 (UL+DL)

3. The rest of the PHY resides in the CU

in the DU 3. The rest of PHY functions reside in the CU 1. In the UL, FFT, CP removal, resource demapping and possibly prefiltering functions reside in the DU

receive) are possible as MAC is in CU

2. In the DL, iFFT, CP addition, resource mapping and precoding functions reside in the DU 3. The rest of PHY functions reside in the CU 1. Only the encoder resides in the CU The rest of PHY functions reside in the DU

7-3 (only DL)

8 (PHY-RF split)

PDCP,

RF

1. Permits centralisation of

06 SEP 2018

1. Expected to reduce the fronthaul requirements in terms of throughput to the baseband bitrates as the payload is encoded data 1. High levels of centralization and

1. High requirements on

Page 7 of 30

RLC, MAC, and physical layer

processes at all protocol layer levels, resulting in very tight coordination of the RAN. This allows efficient support of functions such as CoMP, MIMO, load balancing, and mobility

06 SEP 2018

coordination across the whole protocol stack, which may enable a more efficient resource management and radio performance 2. Separation between RF and PHY enables to isolate the RF components from updates to PHY, which may improve RF/PHY scalability -

3. Separation of RF and PHY allows reuse of the RF components to serve PHY layers of different radio access technologies (e.g. GSM, 3G, LTE)

-

4. Separation of RF and PHY allows pooling of PHY resources, which may enable a more cost efficient dimensioning of the PHY layer

-

5. Separation of RF and PHY allows operators to share RF components, which may reduce system and site costs

fronthaul latency and bandwidth, which may imply higher resource consumption and costs in transport dimensioning (link capacity and equipment)

Page 8 of 30

2.3. Architectural and Specification Aspects and UP-CP Separation Issues [7] 2.3.1. Architectural and Specification Aspects Number of split options: Performances of transport networks vary from high transport latency to low transport latency in the real deployment. Hence, preferable option would be different between different types of transport networks, i.e. ranging from lower layer split for transport networks with lower transport latency to higher layer split for transport networks with higher transport latency. In addition, there are both demands to reduce transport bandwidth and demands to support efficient scheduling and advanced receivers within lower layer split discussion in 3GPP. Though the Option 8 has been available in today deployment based on a de facto standard from a forum other than 3GPP, it is recommended that 3GPP should not attempt to specify this option 8. Granularity: 3GPP has specified some possible options for the granularity of the CU/DU functional split that are listed below. 1. Per CU: Each CU has a fixed split, and DUs are configured to match this. 2. Per DU: Each DU can be configured with a different split. The choice of a DU split may depend on specific topology or backhaul support in a given area. 3. Per UE: Different UEs may have different service levels, or belong to different categories, that may be best served in different ways by the RAN (e.g., a low rate IOTtype UE with no need for low latency does not necessarily require higher layer functions close to the RF). 4. Per bearer: Different bearers may have different QoS requirements that may be best supported by different functionality mapping. For example, QCI=1 type bearer requires low delay but is not SDU error sensitive, 5. Per slice: It is expected that each slice would have at least some distinctive QoS requirements. Regardless of how exactly a slice is implemented within the RAN, different functionality mapping may be suitable for each slice. Followings are noted by 3GPP regarding the aforementioned granularity options. -

Per CU and Per DU options pertain to flexibility of network topology, and should be straightforward to support. In the Per DU option, one CU may need to support different split levels in different interfaces, which is not the case in the Per CU option. Further granularity, e.g. Per UE, Per bearer, and Per slice, requires analysis and justification based on QoS and latency requirements. Hence, in Per UE, Per bearer, and Per slice option, at a particular instance, the interface between CU/DU would need to support simultaneously multiple granularity levels on user plane.

26June2017

Remarks -

-

For Per CU and Per DU options, through configuration or negotiation taking into account capabilities of the two units and deployment preference, e.g. based on backhaul topology, CU and DU split can be coordinated. The baseline is CU based or DU based. Justification should be made for any finer granularity such as Per UE, Per bearer, and Per slice.

Centralized RRM functions: Most of the defined functional splits allow for having RRM functions, e.g. Call Admission Control and Load balancing in the CU which controls multiple DUs. This results in increased efficiency in inter-cell coordination for RRM functions including the coordination of interference management, load balancing and Call Admission Control. Note that such efficiency can only be realized if the CU can have reliable and accurate understanding of the current environment at the DU, including radio conditions, current processing capabilities, and current terrestrial capacity for wireless or mesh backhauling. Centralized scheduling Options: Having centralized scheduling can provide benefit particularly for interference management and coordinated transmission in multiple cells such as CoMP in LTE. However, this requires the followings in place: - the CU to have an good understanding of the state of the DU radio conditions - either very low latency/jitter transport or sufficiently tight coordination of timing and reception of user plane data which can be challenging particularly for lower latency use cases in NR. Functional split Option 5, Option 6, Option 7 and Option 8 allow for scheduling of data transmission in the CU. Note that centralization of RAN functions has strong potential for benefits such as the followings. - reduced cost, - improved scalability, - more efficient inter-cell coordination for interference management, and - improved mobility in ultra-dense deployments. Transmission of RRC message over the CU-DU link: It is recommended that the RRC related functions should be located in the CU for all functional split options. The RRC message between the gNB (a node that supports the NR, i.e. new radio, as well as connectivity to NGC, i.e. next generation core) and the UE should be transferred through the interface between the CU and the DU as illustrated in Fig. 2.

06 SEP 2018

Page 10 of 30

RRC

CU

CU-DU Interface

RRC message

DU gNB

UE Fig.2. Transmission of RRC message between the CU and the UE via the DU [7]. CU-DU specification aspects: The architecture of gNB with CU and DUs is shown in Fig.3. FsC and Fs-U provide C-plane and U-plane over Fs interface, respectively. Central Unit (CU) is a logical node that includes the gNB functions excepting those functions allocated exclusively to the DU. CU controls the operation of DUs. Distributed Unit (DU) is a logical node that includes, depending on the functional split option, a subset of the gNB functions. The operation of DU is controlled by the CU.

gNB CU

Fs-C

DU

Fs-U Fs-C

Fs-U

DU

Fig.3. gNB architecture with CU and Dus [7].

06 SEP 2018

Page 11 of 30

Transport network requirements for an example RAN architecture for NR: According to TR 38.913, the NR shall support up to 1GHz system bandwidth, and up to 256 antennas. A calculation relative to one of several possible transport deployments applied to a possible RAN architecture example shows that transmission between base band part and radio frequency part requires a theoretical maximum bitrate over the transport network of about 614.4Mbps per 10MHz mobile system bandwidth per antenna port. When the system bandwidth is increasing as well as the number of antenna ports, the required bitrate is linearly increasing. An example with rounded numbers is shown in the following table. Note that the values in Table 2 are a maximisation of the needed bandwidth per number of antenna ports and frequency bandwidth. The followings have been considered for calculation. - Peak bitrate requirement on a transmission link = Number of BS antenna elements * Sampling frequency (proportional to System bandwidth) * bit width (per sample) + overhead - The calculation is made for sampling frequency of 30.72 Mega Sample per second for each 20MHz and for a Bit Width equal to 30. Note: For 20 MHz system BW and 2 antenna ports, the peak bit rate calculation is as follows. Peak bit rate= (2*30.72 samples/s*30 bits/sample)+ overhead =61.4*30*2=1842 Mbps ~ 2 Gbps (upper rounded) >> check Table 2.

Table 2. Examples of maximum required bitrate on a transmission link for one possible PHY/RF based RAN architecture split [7]. Number of Frequency System Bandwidth Antenna 10 MHz 20 MHz 200 MHz 1 GHz Ports 2

1 Gbps

2 Gbps

20 Gbps

100 Gbps

8

4 Gbps

8 Gbps

80 Gbps

400 Gbps

64

32 Gbps

64 Gbps

640 Gbps

3200 Gbps

256

128 Gbps

256 Gbps

2560 Gbps

12800 Gbps

Conclusions on functional split between CU and DU For Higher Layer Split - There shall be normative work for a single higher layer split option. - In the meantime, if other decisions cannot be made, it is RAN3’s recommendation to progress on Option 2 for high layer RAN architecture split. For Lower Layer Split

06 SEP 2018

Page 12 of 30

-

-

The study on lower layer split RAN architectures is not completed. Further study is required to assess on low layer splits, their feasibility, the selection of options and assess the relative technical benefits, based on NR. Options 6 and 7 are favored for future study items.

2.3.2. UP-CP Separation Issues on Functional Split Options Rationale: Next Generation networks will see an increasing use of very dense deployments where user terminals will be able to connect to multiple transmission points simultaneously. Hence, it may be favourable and beneficial for the next generation RAT, to base the architecture on a separation of the CP and UP functions. This separation would imply to allocate specific CP and UP functions between different nodes. The following points can be taken as examples for expected benefits of a separation of CP and UP. - A centralization of CP functions, controlling different transmission points, has the potential to achieve enhanced radio performance. - Flexibility to operate and manage complex networks, supporting different network topologies, resources and new service requirements. - Alignment with SDN concept that would result in a functional decomposition of the radio access, based on a partial de-coupled architecture, between user and control plane entities and on network abstractions. - For functions purely handling with CP or UP processes, independent scaling and realization for control and user plane functions operation. - Support of multi-vendor interoperability. UP and CP Functions Description and Grouping: In current TS 36.300[2], the LTE functions are listed as in the figure below. Note that the subsequent analysis considers the LTE protocol Stack as listed by RAN3 in 3GPP TR 38.913. The functions are augmented and aligned with the RRM functionalities defined in 3GPP TS 36.300.

06 SEP 2018

Page 13 of 30

eNB Inter Cell RRM RB Control Connection Mobility Cont. MME Radio Admission Control NAS Security eNB Measurement Configuration & Provision Idle State Mobility Handling

Dynamic Resource Allocation (Scheduler)

EPS Bearer Control RRC PDCP S-GW

P-GW

RLC Mobility Anchoring

MAC

UE IP address allocation

S1 PHY

Packet Filtering internet

E-UTRAN

EPC

Fig.4. Function Split between E-UTRAN and EPC [7]. In the figure above, the blue boxes denote radio protocol layers. -

The functions in RRC layer could be considered as belonging to control plane, which is controlling all the radio resources.

-

The Inter-Cell RRM, RB control, Connection Mobility Continuity, Radio admission control, eNB measurement configuration and provision, Dynamic resource allocation are functions with a control plane component; while transfer of user data are user plane functions. Note that the functions listed above are those existing in LTE.

There were identified two basic architectures for UP-CP split, which conduct to a difference in the assignment of control functions to the central control plane. - A flat UP-CP separation architecture where there is a clear UP-CP function separation as LTE function separation. - A hierarchical UP-CP separation architecture where the UP-CP are not separated for the functions used in LTE. Instead the less time-sensitive operation of these functions could be coordinated by a higher hierarchy Central Coordinator. Note that since the protocol stack for the new RAT will most likely a being based on what has been introduced for LTE, the synthesis of CP and UP functions will need to take this circumstance into account. While Inter-Cell RRM, RB control, Connection Mobility Continuity, Radio admission control, eNB measurement configuration and provision have a strong CP component, all other radio protocol layers are shared by user plane and control plane, as they are sharing the same radio resources. The mobile system especially the air interface design is quite optimized. The frequency resource is limited, and the air condition changes quickly. Therefore, the LTE protocol stack has been carefully design and strict time pattern during the interaction of the radio protocol layers for the 06 SEP 2018

Page 14 of 30

Uu interface have been considered. The function for control plane and user plane have been considered together to maximise the performance of the air interface. The functions have strong dependency and are very difficult to separate. Some examples of the mix of control plane/ user plane function in Uu interface are as follows. - PHY: There are several control channels including PBCH, BCH, PDCCH, PDSCH, EPDCCH, and also the channel data i.e. PDSCH. However, the PDSCH can also carry the PCH which is the function for control plane. The whole system operates relying on other control signaling including reference signals and synchronization etc. - MAC: It is designed as user plane to unify the data transmission regardless the data is for signaling or real package. However, there are still controlling functions/procedures in MAC including RACH procedure, cell activation/deactivation, TA command, PHR etc. There is only one MAC entity in E-UTRAN for a UE. The entity is responsible for all the control signalling and data transmission. It is impossible to separate the user plane and control plane in MAC layer in network side. - RLC/PDCP: The two layer are relatively simpler. However, there are still controlling PDU for the two layers, e.g. RLC status reporting, the encryption, and integration protection for the signalling and data etc. - Scheduling: Scheduling is ruled via policies established via CP and influences future CP settings, while at the same time being the core of the UP resource provisioning mechanism. In order to provide optimal centralised scheduling a real time detailed knowledge of the UP traffic available in UL and DL is needed. For this reason, scheduling has a role both in the CP and in the UP. - Logical channel multiplexing: This function is in charge of multiplexing data of different logical channels into the same time frequency resources. This is clearly a task performed on UP traffic to increase the efficiency of UP data transmission. However, multiplexing is controlled by CP established configurations and policies, which make it difficult to classify this function as a pure UP one. Unless further analysis proves a difference in the outcomes above, the dependencies between some control and user plane functions, as described in the examples above, make the separation of CP and UP for all functions of an E-UTRAN based function set for NR, difficult and likely not practical. RAN architecture and interfaces for UP-CP Separation: Figures 5 and 6 show some deployment scenarios below based on Higher Layer Split Option 2 as example and reusing Release 12 Dual Connectivity concepts. This CP-UP separation permits flexibility for different operational scenarios as follows. - Move the PDCP to a Central Unit while keeping RRM in a master cell. - Move RRM to a more central location where it has oversight over multiple cells; while allowing independent scalability of user plane and control plane. - Central RRM with local breakout of some data connections of some UEs nearer (or at) the base station site.

06 SEP 2018

Page 15 of 30

The following figure illustrates how a higher layer CU/DU functional split based, e.g. on Option 2 would allow for user and control plane separation. It allows for the independent scalability and evolution (e.g., addition of new encryption algorithms) of user and control planes. Note that though Some of the benefits of Control and User Plane separation based on Release 12 Dual Connectivity were identified, solutions details were not discussed in 3GPP study items. Note: From the departmental meeting on 26 June 2017, It has been known that Option 2 (PDCP-RLC) is considering for C-/U-plane splitting in 3GPP for investigation. In addition, Option 5 (MAC-PHY) split is also under consideration for investigation in 3GPP.

Fig. 5. Centralised PDCP-U with Local RRM [7].

06 SEP 2018

Fig. 6. Centralised PDCP with Centralised RRM in separate platforms [7].

Page 16 of 30

3. NGFI FUNCTIONAL SPLIT OPTIONS 3.1. Description The advantages of C-RAN is limited by the properties of the link that connects central unit to the remote radio unit. The link is termed as fronthaul link. Existing fronthauls use CPRI or OBSAI interfaces. However, the major bottlenecks of CPRI are its high bandwidth and low latency demand such as when using in LTE systems, and is struggling to support next generation C-RAN. Further, in contrast to dynamic features of mobile services, CPRI and OBSAI are fixed rate interfaces based on TDM that transmit information during offload resulting low resource utilization. To resolve the constraints of CPRI, NGFI is considered for the next generation radio network infrastructure. NGFI is an open interface with two distinct properties as follow Fig. 7. - It shifted some functionalities in BBU to remote radio head (RRH) such that the modified BBU and RRH are termed respectively as radio Cloud Center (RCC) and Remote Radio Systems (RRS). - The fronthaul network changes from point-to-point to multiple-to-multiple fronthaul network.

Fig. 7. C-RAN Radio Network Architecture Based on NGFI [8]. Authors in [8] proposed the following functional split options between RRS and RRC which are illustrated in Fig. 8.

06 SEP 2018

Page 17 of 30

Fig.8. Division Plans for the RCC-RRS Interface [8]. Option 1: Intra layer 2 (high MAC/low MAC) function split Option 2: MAC/PHY function split Option 3: Bit-level/Symbol-level function split Option 4: Symbol-level/Sample-level function split Option 5: Baseband/RF function split Option 1: this option mainly advantageous for centralized scheduling in RRC and delay intolerant services such as HARQ (4 ms) which is placed at the RRS. In Option 2, all Physical layer related functionaries are moved to the RRS making it independent of the MAC and upper layers’ impact so that hardware and software of Physical channel can be evolved independently. Centralized scheduling, virtualization, resource sharing, CoMP and so on can be executed easily. Since MAC data are transmitted mostly in burst, the instantaneous BW requirement is expected to be high. Note that since BBU functionalities are moved to RRS, the system upgradation and maintenance cost would be high. However, this option is helpful for CoMP and Control-/User-plane separation architecture. Since HARQ functionalities lie in centralized cloud, the delay requirement of the NGFI is strict. 06 SEP 2018

Page 18 of 30

The bandwidth of the scheduling and configuration data for option 3 (bit-level/symbol-level function split) is similar to that for the MAC/PHY function split. Also, the transport delay requirement on the fronthaul is strict because of being constrained by the HARQ mechanism. Sample-level functions are moved from the BBU to the RRH such that system upgradation and maintenance are complex. However, this option is helpful for CoMP, Control-/User-plane separation architectures. Similar to option 3, option 4 also enforces strict delay limit on fronthauls. Since sample level processing is invariable, unlike option 3, the upgrade and maintenance remain unchanged. Moreover, this option is helpful for CoMP, Control-/User-plane separation architectures. Option 5: this split option is the existing solution where only RF functionalities are located to the RRS and BBU is located to the RRC. Hence, upgrading and maintenance of the RF unit is easy. Further, the BW of this split is constant and traffic load independent. In the following, relative performance comparison of the peak BW and delay requirements are show in Table. 3 and Table.4. Table 3. The comparison of the peak bandwidth [8].

Table 4. The comparison of the delay requirements [8].

3.2. Observation and Analysis BW requirement -

Highest BW requirement for the fronthaul requirement for both uplink and downlink is option 5 Lowest BW requirement for the fronthaul requirement for downlink is option 3 Lowest BW requirement for the fronthaul requirement for uplink is option 2

06 SEP 2018

Page 19 of 30

-

Optimum (summation of uplink and downlink) BW requirement for the fronthaul requirement is option 2

Delay requirement -

Lowest delay requirement is option 1, i.e. 100 ms All other options for splitting has the same delay requirement of less than 1 ms

Analysis -

-

From both BW and delay requirement perspectives, the Optimum split is option 2 (MAC/PHY Split) when considering aggregate BW requirement from uplink and downlink For others (CoMP, RRS complexity, fronthaul interface complexity, pooling gain, the complexity of upgrading and maintenance, and iteration receiver), option 5 provides the best performances of all.

06 SEP 2018

Page 20 of 30

4. SMALL CELL FORUM FUNCTIONAL SPLIT 4.1. Description Figure 9 shows the recommended functional split options by small cell forum. There are in total 7 split options, namely services, RRC-PDCP, PDCP-RLC, RLC-MAC, Split MAC, MAC-PHY, and Split PHY. Functions to the left of the split are resided in the central small cell, while functions to the right reside in the remote small cell. For the intra-MAC and intra-PHY splits, the upper portion resides in the central small cell and the lower part in the remote small cell. Table 3 shows relative performances in terms of latency and bandwidth requirements for each split option. In Table 5, split I to split IV for the PHY layer is shown in Fig. 10.

Fig.9. Functional split proposal by Small cell forum [9].

Fig.10. PHY layer Split recommendation by Small cell forum [9]. From Table 5, use cases (splits) up to the MAC-PHY split have similar bandwidth requirements (i.e., 151-152 Mbps for DL and 48-49 Mbps for UL). However, for each PHY split, the bandwidth requirements increase significantly, i.e. 173Mbps for split I to 2457.6 Mbps for split

06 SEP 2018

Page 21 of 30

IV in the DL. The similar trend can be seen in Table 3 for the UL for the throughput requirement. For latencies, the requirements for split options can be shown in three groups as follows. - RRC-PDCP and PDCP-RLC (non-ideal with 30 ms) - RLC-MAC and split MAC (sub-ideal with 6 ms), and - MAC-PHY and PHY split (ideal with 250 micro seconds or near-ideal with 2 ms). Table 5. Bandwidth and latency requirements for each functional split option [9].

Note: 1Although centralized RRC could be made to run over a non-ideal (30ms) backhaul, certain key performance indicators may be degraded due to the extra delay in handling of RRC procedures. 2 Bandwidth when user plane data is routed via central small cell or virtualized network function (VNF). If user plane data has distributed routing the bandwidth is control only and < 10Mbps. 3 With 2 ms latency, the achievable throughput for a single UE will be halved.

4.2. Observation and Analysis From the above Table 5, it can be considered that Split MAC or MAC/PHY could provide better performances in terms of both throughput and latency requirements with a view to shifting majority of the function to the central small cell.

06 SEP 2018

Page 22 of 30

REFERENCES [1] J. Duan, X. Lagrang, and Frédéric Guilloud, Performance Analysis of Several Functional Splits in C-RAN, IEEE, 2016. [2] A. Osseiran, F. Boccardi, V. Braun, K. Kusume, P. Marsch, M. Maternia, O. Queseth, M. Schellmann, H. Schotten, H. Taoka, H. Tullberg, M. Uusitalo, B. Timus, and M. Fallgren, “Scenarios for 5G mobile and wireless communications: the vision of the METIS project,” IEEE Communications Magazine, vol. 52, pp. 26–35, May 2014. [3] C.-L. I, J. Huang, R. Duan, C. Cui, J. Jiang, and L. Li, “Recent Progress on C-RAN Centralization and Cloudification,” IEEE Access, vol. 2, pp. 1030–1039, 2014. [4] “Common Public Radio Interface (CPRI); Interface Specification V6.0,” August 2013. [5] A. Checko, H. Christiansen, Y. Yan, L. Scolari, G. Kardaras, M. Berger, and L. Dittmann, “Cloud RAN for Mobile Networks – A Technology Overview,” IEEE Communications Surveys Tutorials, vol. 17, no. 1, pp. 405–426, 2015. [6] “C-RAN: The Road Towards Green RAN (white paper),” China Mobile Research Institue, Dec 2013. [7] 3rd Generation Partnership Project, “Technical Specification Group Radio Access Network; Study on New Radio Access Technology, Radio Access Architecture and Interfaces (Release 14),” 3GPP TR 38.801 Ver. 2.0.0, Mar. 2017. [8] NGFI, “White Paper of Next Generation Fronthaul Interface,” Ver. 1.0, Oct., 2015 [9] Small Cell Forum, “Small cell virtualization functional splits and use cases,” Document 159.07.02, Jan. 2016.

06 SEP 2018

Page 23 of 30

APPENDIX LTE BACKGROUND A.1 LTE DOWNLINK SIGNAL GENERATION CHAIN In Fig. A.1 the components of the downlink physical layer signal generation chain can be seen. 1. First a 24 bit CRC (Cyclic Redundancy Check) field is introduced to detect errors in the receiver. 2. After the CRC module comes a turbo encoder as forward error correction (FEC) channel coder. The LTE downlink turbo encoder has R = 1/3 as basic code rate and is (can be) with puncturing. 3. There is an HARQ module following the turbo encoder. HARQ stands for Hybrid Automatic Repeat Request and is a mechanism based on stop and wait ARQ which transmits the packets again in case of errors detected by the CRC. 4. In order to achieve more coding gain, a scrambling module based on a 31 bit Gold sequence is used after the HARQ module. 5. The final module is the modulator, which can use QPSK, 16QAM or 64QAM in LTE downlink. 6. In LTE there is the possibility to use MIMO. In this case an antenna mapping module decides on which antenna the packets are to be sent. In LTE downlink up to 4 antennas can be used. 7. Finally, the resource management module selects the appropriate resources, which are in LTE time slots and subcarriers to transmit the packet.

06 SEP 2018

Page 24 of 30

Fig. A.1. Signal generation chain in LTE downlink physical layer. A.2 eNodeB TRANSCEIVER CHAIN

Fig. A.3. eNodeB physical transmit chain [A2].

06 SEP 2018

Page 25 of 30

Fig. A.4. eNodeB physical receive chain [A2]. Segmentation is done if transport block (TB) size is greater than 6144. Turbo coding is a kind of channel coding for forward error correction (FEC). ARQ and HARQ In ARQ, when we have a 'bad' package, the system simply discards it, and asks for a retransmission (of the same package). And for this, it sends a feedback message to the transmitter [A1]. The HARQ is the use of conventional ARQ along with an Error Correction technique called 'Soft Combining', which no longer discards the received bad data (with error). With the 'Soft Combining' data packets that are not properly decoded are not discarded anymore. The received signal is stored in a 'buffer', and will be combined with next retransmission. That is, two or more packets received, each one with insufficient SNR to allow individual decoding can be combined in such a way that the total signal can be decoded [A1]. Rate matching (puncturing/repetition) is used if the transmitted data is more/less than the transport block size. Scrambler is used for interference randomization. Layer mapping defines mapping of symbols to antenna ports Precoding is a technique which exploits transmit diversity by weighting the information stream, i.e. the transmitter sends the coded information to the receiver to achieve pre-knowledge of the channel. The receiver is a simple detector, such as a matched filter, and does not have to know the channel side information. The FFT estimates the spectral content (the harmonic content) of a 06 SEP 2018

Page 26 of 30

time-domain sequence of digital signal samples. The results of the FFT are frequency-domain samples. The IFFT is a process to convert frequency-domain samples back to time-domain samples. Rank Indicator: The rank indication or the RI in LTE is one of the control information that a UE will report to eNodeB on either PUCCH or PUSCH based on uplink scheduling. The eNodeB configures the RI reporting periodicity for every UE during the attach procedure and UE has to honour it. The RI reporting periodicity can overlap with CQI reporting periodicity in which case the UE will drop CQI and report RI. The contents of RI is just a couple of bits. The number depends on antenna configuration. If the eNodeB is configured with 2 transmit antennas on downlink then the number of bits reported in RI will be one and if its 4 then number of RI bits will be 2. Lets consider the two antenna case where RI is indicated using one bit, so a bit 0 indicates RANK1 and a bit 1 indicates RANK2. RANK1 means the UE is seeing a good SINR only on one of its receive antenna so asking the eNodeB to bring down the transmission mode to single antenna or transmit diversity. A RANK2 from the UE means good SINR on both the antenna ports and eNodeB can schedule MIMO. Its very essential for the eNodeB to decode a UEs RI report to know the channel conditions so that it can schedule downlink appropriately. The LTE specifications also say that if the UE is not reporting any RI then the eNodeB should assume RANK1. Fourier Transform: The Fourier transform is used to convert the signals from time domain to frequency domain and the inverse Fourier transform is used to convert the signal back from the frequency domain to the time domain. The Fourier transform is a powerful tool to analyse the signals and construct them to and from their frequency components. If the signal is discrete in time that is sampled, one uses the discrete Fourier transform to convert them to the discrete frequency form DFT, and vice verse, the inverse discrete transform IDFT is used to back convert the discrete frequency form into the discrete time form. To reduce the mathematical operations used in the calculation of DFT and IDFT one uses the fast Fourier transform algorithm FFT and IFFT which corresponds to DFT and IDFT, respectively. In transmitters using OFDM as a multicarrier modulation technology, the OFDM symbol is constructed in the frequency domain by mapping the input bits on the I- and Q- components of the QAM symbols and then ordering them in a sequence with specific length according to the number of subcarriers in the OFDM symbol. That is by the mapping and ordering process, one constructs the frequency components of the OFDM symbol. To transmit them, the signal must be represented in time domain. This is accomplished by the inverse fast Fourier transform IFFT. So, in summary the signal is easier synthesized in discrete frequency domain in the transmitter and to transmit it must be converted to discrete time domain by IFFT. Equalization is a process of compensating the effects that distort the received signal. A.3 LAYER 2 FUNCTIONALITIES 06 SEP 2018

Page 27 of 30

In Fig. A.5, Layer 2 Structure for DL and in Fig. A.6, Layer 2 Structure for UL are shown [A3].

Fig. A.5. Layer 2 Structure for DL [A3].

Fig. A.6. Layer 2 Structure for UL [A3].

06 SEP 2018

Page 28 of 30

PDCP sublayer: The main services and functions of the PDCP sublayer for the user plane include: -

Header compression and decompression: ROHC only Transfer of user data In-sequence delivery of upper layer PDUs at PDCP re-establishment procedure for RLC AM Duplicate detection of lower layer SDUs at PDCP re-establishment procedure for RLC AM Retransmission of PDCP SDUs at handover for RLC AM Ciphering and deciphering Timer-based SDU discard in uplink

The main services and functions of the PDCP for the control plane include: -

Ciphering and Integrity Protection Transfer of control plane data

RLC sublayer: The main services and functions of the RLC sublayer include: -

Transfer of upper layer PDUs Error Correction through ARQ (only for AM data transfer) Concatenation, segmentation and reassembly of RLC SDUs (only for UM and AM data transfer) Re-segmentation of RLC data PDUs (only for AM data transfer) In sequence delivery of upper layer PDUs (only for UM and AM data transfer) Duplicate detection (only for UM and AM data transfer) Protocol error detection and recovery RLC SDU discard (only for UM and AM data transfer) RLC re-establishment

MAC sublayer: The main services and functions of the MAC sublayer include: -

-

Mapping between logical channels and transport channels Multiplexing/demultiplexing of MAC SDUs belonging to one or different logical channels into/from transport blocks (TB) delivered to/from the physical layer on transport channels; scheduling information reporting Error correction through HARQ Priority handling between logical channels of one UE Priority handling between UEs by means of dynamic scheduling Transport format selection Padding

A.4 LAYER 3 FUNCTIONALITIES (RRC) 06 SEP 2018

Page 29 of 30

The main services and functions of the RRC sublayer include: -

-

-

Broadcast of System Information related to the non-access stratum (NAS) Broadcast of System Information related to the access stratum (AS) Paging Establishment, maintenance and release of an RRC connection between the UE and EUTRAN including: - Allocation of temporary identifiers between UE and E-UTRAN - Configuration of signalling radio bearer(s) for RRC connection: - Low priority SRB and high priority SRB Security functions including key management; Establishment, configuration, maintenance and release of point to point Radio Bearers; Mobility functions including: - UE measurement reporting and control of the reporting for inter-cell and inter-RAT mobility - Handover - UE cell selection and reselection and control of cell selection and reselection - Context transfer at handover Notification for MBMS services Establishment, configuration, maintenance and release of Radio Bearers for MBMS services QoS management functions UE measurement reporting and control of the reporting NAS direct message transfer to/from NAS from/to UE

References (for appendix) [A1] http://www.telecomhall.com/what-is-retransmission-arq-and-harq.aspx [A2] R. Budhiraja, “3GPP Long Term Evolution Physical Layer,” presentation slides, CEWiT 2011. [A3] ETSI “LTE; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (3GPP TS 36.300 version 8.9.0 Release 8),” ETSI, TS 136 300, Ver. 8.9.0, July 2009.

06 SEP 2018

Page 30 of 30