A Study Paper On

5G TRANSPORT REQUIREMENT
(A Guiding Tool for Planning 5G Transport Network)

Abdul Kayum

Director

Fixed Access Division

2020
 FOREWORD

Telecommunication Engineering Centre (TEC) functions under Department of

Telecommunications (DOT), Government of India. Its activities include:

• Issue of Generic Requirements (GR), Interface Requirements (IR), Service

Requirements (SR) and Standards for Telecom Products and Services
• Field evaluation of products and Systems
• National Fundamental Plans
• Support to DOT on technology issues
• Testing & Certification of Telecom products
For the purpose of testing, four Regional Telecom Engineering Centers (RTECs) have
been established which are located at New Delhi, Bangalore, Mumbai, and Kolkata.

Abstract

This study paper enumerates the various requirements arising from 5G wireless
systems for construction of a transport network, concentrating on the fronthaul and
midhaul portion of the network, and considers how they compare with current optical
access transport systems and suggesting how to proceed in constructing 5G transport.

Keywords

5G wireless, Access, Aggregation, Backhaul, Bandwidth, CPRI, C-RAN, Core, D-

RAN, eCPRI, F1, Fronthaul, Fx, Latency, Midhaul, Networks, PON, Synchronisation,
Transport, V-RAN.

1
 TABLE OF CONTENTS
1. Introduction 5
2. Definitions 5
2.1. Latency 5
2.3. Distributed RAN (D-RAN) 5
2.4. Centralized RAN (C-RAN) 6
2.5. Virtualized RAN (V-RAN) 6
3. 5G RAN Architecture and new Interfaces 6
4. Constraints of Classical approach to Fronthaul 7
5. Choices for fronthaul and midhaul in 5G wireless network 8
6. 5G Transport Networks 9
7. 5G RAN Deployment Scenarios 11
7.1. Distributed RAN (D-RAN): 11
7.2. Centralized RAN (C-RAN): 12
7.3. Virtualized RAN (V-RAN) 12
8. 5G Transport Network Design Consideration 12
8.1. RAN and Service requirements 12
8.2. Latency requirements 13
8.3. Bandwidth Requirements 14
8.4. OAM Requirements 16
8.5. Synchronization Requirement 16
8.6. Network Slicing Requirements 16
8.7. Protection Requirements 17
9. Transport Networks choices 17
9.1. OAM Solutions 18
9.2. Synchronization solution for transport network 18
9.3. Network Slicing Solutions 20
9.4. Protection/ Restoration Solution 20
10. An Analysis of PON as a Transport for 5G Midhaul and Fronthaul
Application 20
10.1. PON Architecture for 5G fronthaul and midhaul transport 21
10.2. Legacy PON with WDM overlay to support 5G 22
10.3. Dedicated PON to support 5G 23

2
10.4. Dimensioning of aggregate data rates at F1 interface to select an
appropriate PON system 24
10.5. PON System Implementation Challenges and Resolution 26
10.5.1. Dynamic Bandwidth Allocation (DBA) 26
10.5.2. Differentiated Service 26
10.5.3. CO DBA 27
10.6. Fibre reach and split ratio limitations 27
10.7. Synchronization challenges in PON 28
10.8. Coordination between the PON and wireless interface 28
11. Conclusion/Recommendation 30
12. Way Forward 33
13. Appendix I-Latency 34
13.1. End-To-End Service Latency Budget in 5G Networks 34
14. Appendix II-Bandwidth Calculations 35
14.1. Base Station Fx Bandwidth Requirements Calculation Methods 35
14.2. Base Station F1 Bandwidth Requirements Calculation Methods 38
14.3. Base Station Backhaul Bandwidth Requirements Calculation Methods 39
14.4. Transport Network Node Capacity Calculation Methods for Backhaul 43
15. Abbreviations and acronyms 49
16. Bibliography 52

LIST OF FIGURES
Fig. 1 5G RAN Architecture Showing Different Interfaces 7
Fig. 2 Functional Split Points in Fronthaul 9
Fig. 3 Mapping of 5G Transport with Transport Network Domains 10
Fig. 4 5G RAN Deployment Scenarios 11
Fig. 5 A Typical Bandwidth and Latency Requirement of 5G RAN 15
Fig. 6 Example Synchronization Transport Network Topology 19
Fig. 7 Concept of Layered Structure Showing RNL (CU, DU, RU) and TNL (OLT,
ONT). 22
Fig. 8 F1 and Fx Based on Legacy PON with WDM Overlay 23

3
Fig. 9 NGMN Method for Calculation of Capacity Requirements per PON Port 25
Fig. 11 Dedicated Bandwidth for Low Latency 5G Fronthaul Transport 26
Fig. 12 CO DBA Mechanism for Mobile Fronthaul 27
Fig. 13 5G Transport Network Overview (ITU-T G.8300) 31
Fig. I 1 End-To-End Latency Budget (ITU-T G.8300) 34
Fig. II 1 5G Transport Layers ................................................................................... 44
Fig. II 2 D-RAN Network Case ................................................................................. 46
Fig. II 3 Small C-RAN Network Case........................................................................ 48

LIST OF TABLES
Table 1 High-level overview of expected traffic characteristics for various 5G
services (see for example Fig. 3 in ITU-R M.2083 (ITU-R M.2083) 13
Table 2 Transport bit rates and latency ranges at different functional split interfaces
(3GPP TR 38.801 V2.0.0 (R14)) 14
Table 3 Frequency offset requirement 16
Table 4 Data Rates of different Technologies 18
Table 5 Peak backhaul data rate from a single DU serving a single RU 24
Table 6 Aggregated F1 interface rate from a single DU serving 10 RUs (ITU-T G
series Supplement 66) 24
Table 7 Summary of Transport network for 5G 32
Table I 1: End to end latency requirements for selected service types 34

4
1 Introduction
Ultra-Reliability Low Latency Communication (uRLLC) application is going to be the

hall mark of fifth generation wireless network (5G) in addition to enhanced Mobile

Broadband (eMBB) and massive Machine Type Communication (mMTC). Stringent

end to end (e2e) requirements of very high throughput, ultra-low latency and RAN

virtualization in 5G require underlying transport network to be sensitive towards it.

Many of these requirements are very different from that of currently deployed 4G

network or fixed line networks. 5G nodes like DU, CU and NGC are clients to a

transport network, therefore, characteristics of these nodes with respect to throughput,

latency, synchronisation and OAM requirements have been dealt in detail to

understand underlying demands from transport network. PON as prospective

candidate for 5G fronthaul and midhaul transport network has been evaluated at

length.

2 Definitions

2.1 Latency

In 5G, e2e latency [1] refers to the duration between the transmission of a data packet

from the application layer of source node and successful reception at the application

layer of the destination node. The over-the-air latency constitutes only one part of the

e2e latency, whereas the latency of transport network and 5G core network constitute

the remaining part.

2.2 Reliability
3GPP [2] defines the reliability by the probability of successful transmission of a packet

from one radio unit to another radio unit within the given time constraint required by

the targeted service. 3GPP defines the target packet failure rate of 10 -5 within 1 ms

over-the-air latency for uRLLC whereas 10-4 has been defined for HRLLC.

2.3 Distributed RAN (D-RAN)

DU is deployed near to RU, or RU/DU/CU are integrated. No transport in fronthaul.

5
2.4 Centralized RAN (C-RAN)
DU is located far away from RU at a centralized location, the distance between DU

and RU is longer. Fronthaul transport network required.

2.5 Virtualized RAN (V-RAN)

CU is located away from DU, at a centralized location with Data Centre, known as

Mobile Edge Computing (MEC).

3 5G RAN Architecture and new Interfaces

5G RAN architecture is defined in 3GPP [3] and shown in Fig. 1 . In order to meet

stringent e2e requirement of throughput, ultra-low latency and RAN virtualization in

5G, 3GPP proposed processing of radio signal chain (RRC-PDCP-RLC-MAC-PHY) at

three different units, some parts in Central Unit (CU), some in Distributed Unit (DU),

and some in Remote Radio Unit (RRU or simply RU) in contrast to 4G where all the

processing of radio stack is done in Baseband Unit (BBU). This distribution of functions

has given rise to two new interfaces, one between CU and DU, and another between

DU and RU which are called Next Generation Fronthaul Interface-II (NGFI II or F1)

and Next Generation Fronthaul Interface-I (NGFI I or Fx), respectively, and the

associated transport links are frequently called Fronthaul-II or Midhaul and Fronthaul-

I or just Fronthaul, however in 3GPP terminology both midhaul and fronthaul altogether

is addressed as fronthaul. Interface NG links CU to NGC (CN) and interface and Xn

links two CUs or CU and eNB. Illustration of different type of logical interfaces is given

in Fig. 1 , where emphasis has been given to interfaces and not to any specific

deployment scenario.

6
 Fig. 1 5G RAN Architecture showing different Interfaces

4 Constraints of Classical approach to Fronthaul

Hitherto, in 4G wireless network, the fronthaul link is between RRH and the BBU using

CPRI/OBSAI [4] protocol without using any transport network (usually BBU and

antenna units are co-located at less than100m distance at cell site).

This CPRI [5] fronthaul is based on transport of digitized time domain IQ data. For very

high capacity applications, such as eMBB (enhanced mobile broadband) or for radio

sites with many independent antenna elements (massive MIMO or multi-layer MIMO),

these fronthaul solutions require unreasonable high transport capacities (CPRI

efficiency is ~6%) i.e. many times that of IP traffic it will carry (see appendix-II Table II

1 Required fronthaul data rate in 5G wireless network [3GPP TR 38.801], while

allowing for transport latencies between RU and DU/CU of only up to a few hundred

microseconds. If we continue with this approach, there is no problem in D-RAN

deployment (CU/DU/RU or DU/RU are co-located), however, in C-RAN (DU, RU are

7
far from each other), then a transport network will be required to carry digitalised radio

signals within these constraints which are very difficult to meet at a reasonable cost.

5 Choices for fronthaul and midhaul in 5G wireless network

Unlike D-RAN, the increase in data rates Table II 1 in 5G makes it impractical to

continue with the conventional CPRI/OBSAI fronthaul implementation in C-RAN.

However, moving towards higher level in radio signal chain split as depicted in Fig. 2

would relax [6] the latency and bandwidth requirements, but at the cost of

centralization processing functions. So distribution of radio processing functions in

different units should take into account the technical and cost-effective tradeoffs

between throughput, latency, and functional centralization.

Standardization bodies like 3GPP, xRAN [7], eCPRI [8], and the Small Cell Forum [9]

have identified different points of split in the radio signal processing chain Fig. 2 that

allow for substantial reduction of the transport requirements in C-RAN architectures

compared to the current approach (CPRI based). The choice of optimal 5G New Radio

(NR) points of functional split depends on specific deployment scenarios. So the

transport capacity and latency requirement will depend upon the split points between

which transport link will be required to be deployed. In Fig. 2 F1 and Fx interface have
been shown distinctively as midhaul and fronthaul respectively although both F1 and

Fx are called as fronthaul in RAN architecture of 3GPP.

Fig. 1and Fig. 2 below, there are 8 functional splits points from split option 1 to option

8 in both downlink and uplink direction. Option 8 is lowest layer Split and option 1 is

called Highest Layer Split (HLS) point. Option 2,4,6 are inter layer split whereas option

3,5,7 are intra layer splits. Lower the split, higher is the bandwidth required and least

latency margin. Split option 7 which is intra PHY is further sub-divided into option 7a,

7b and 7c taping advantage of reduced bandwidth at some functional splits than the

other. (PHY DL Functions- Coding rate matching, scrambling, modulation, layer

8
mapping, precoding Tx power, resource element mapping, beamforming, iFFT, cycle
prefix insertions)

Backhaul Midhaul Fronthaul

Fig. 2 Functional split points in Fronthaul

6 5G Transport Networks
The architecture (ITU-T G.8300) [10] of the transport network (ITU-T G.805) [11] is

generally described in terms of metro access/aggregation/core, and backbone

domains. The terms fronthaul, midhaul, and backhaul are used in this paper in

describing the 5G transport network to support Fx interface, F1 interface and NG

interface respectively between 5G nodes. Support to Xn interface that provides

interconnection between different NG-RAN nodes (CU-CU/gNB or eNB) can be

provided by either or both midhaul or backhaul transport network. It will be useful to

map corresponding 5G transport network which can be supported by these domains.

Mapping is illustrated in Fig. 3 with four different examples of CU and DU deployment.

9
 Access Metro Aggregation Metro Core/Backbone

Fig. 3 Mapping of 5G Transport with Transport Network Domains

As a matter of fact, support to these interfaces can be provided by any domains of

transport network but it is not prudent to do that as all the transport node need not to

have all kind of interfaces, distance support etc. Mapping of transport network domain

with 5G transport is summarised below.

Transport Access Metro Metro Core or

network domain Aggregation Backbone

terms domain Network domain

5G transport Fronthaul Midhaul and Midhaul and Backhaul

terms Backhaul Backhaul

5G Interface Fx F1, NG, Xn F1, NG, Xn NG, Xn

supported (CPRI/eCPRI) (Ethernet) (Ethernet) (Ethernet)

5G Nodes RU-DU DU-CU, CU- DU-CU, CU- CU-NGC, gNB-

involved NGC, gNB- NGC, gNB-gNB gNB

gNB

Distance <10/20km < 40km < 40-80km < 40-80km or

>100 km

10
7 5G RAN Deployment Scenarios
The deployment (ITU-T G.8300) [10] of 5G RAN can be characterized D-RAN, or C-

RAN on the basis of the location of the DU and CU and V-RAN if a data centre is

present in RAN. The different deployment scenarios are illustrated in Fig. 4.

Fig. 4 5G RAN Deployment Scenarios

7.1 Distributed RAN (D-RAN):

DU is deployed near to RU, or RU/DU/CU are integrated. In this scenario, the distance

between DU and RU is generally very short (less than 100m) as such no transport

network required between RU and DU. However, either midhaul or backhaul or both

transport network will be required depending upon location of CU. If CU is away from

DU then both midhaul to support F1 interface and backhaul to support NG interface

are required. If CU is deployed with DU then only backhaul transport network is

required.

11
7.2 Centralized RAN (C-RAN):
In this scenario, DU is located far away from RU at a centralized location, the distance

between DU and RU is longer. In this scenario, fronthaul transport network to support

Fx interface (CPRI/eCPRI) is required for sure along with either midhaul (for F1) or

backhaul (for NG) or both transport networks.

7.3 Virtualized RAN (V-RAN)

In this scenario, CU is located far away from DU at a centralized location with Data

Centre (also called as Mobile Edge Computing (MEC)). DU may or may not be co-

located with RU. If DU is not co-located with RU then all the three fronthaul, midhaul

and backhaul will be required, else only midhaul and backhaul will be required.

In actual deployment there may be exclusive D-RAN, C-RAN or a mix of the above

scenario as illustrated in Fig. 4 (ITU-T G.8300) [10].

8 5G Transport Network Design Consideration

5G NR and services that affect the requirements for the fronthaul transport layer

bandwidth, latency, synchronization/jitter, and OAM requirements are discussed

below.

8.1 RAN and Service requirements

3GPP considers RAN architectures that include 5G wireless network along with 4G

wireless network in one common wireless network (3GPP TR 38.801 V2.0.0 (R14)

[12]. Apart from this mixed architecture, 5G networks alone will comprise (ITU-T G

series Supplement 66) [13] a variety of services with traffic characteristics that are very

different from each other (Table 1) (ITU-R M.2083) [14], as well as a variety of Radio

Access Technologies (RAT) with different Radio Frequency (RF) configurations (e.g.

massive MIMO, multi-layer MIMO, below 6 GHz and above 6 GHz etc.). However,

simultaneous use of all of these technologies and services are unlikely in the same

network. Multiple mobile services may use the same RU, but the differentiated

fronthaul transport network may have to be provided to suit different services,

12
depending on traffic and latency needs. A high-level overview of expected traffic

characteristics for various 5G services is given in Table 1 below which is copied from

ITU-R M.2083.

Table 1 High-level overview of expected traffic characteristics for various 5G services

(see for example Fig. 3 in ITU-R M.2083 [14]

Radio technology Peak rate Average rate e2e delay

(service level)

Enhanced Mobile 5-10 / 20 Gb/s Normal- 100 Mbps/ user 10 ms

Broadband (eMBB) (UL/DL) Hot spot- 1 to 4 Gb/s

uRLLC / Critical MTC much lower than in much lower than in 1- 2.5 ms
(incl. D2D) eMBB: N x Mb/s eMBB: n x Mb/s
Massive Machine Type much lower than in much lower than in 1-50 ms
Communication (mMTC) eMBB: N x Mb/s eMBB: n x kb/s to n
x Mb/s
Note: N and n represents number of users at peak and average rate respectively.

8.2 Latency requirements

In C-RAN scenario, processing of radio chain stack (RRC-PDCP-RLC-MAC-PHY) is

distributed among CU, DU and RU. Latency requirement of transmission network will

depend upon which layer of stack is processed in RU/DU/CU. Higher the layer of stack

processed in RU, lower the level of stringency of latency. If part or full of radio signal

stack MAC or PHY or both are processed in RU then transport latency requirement

between DU and RU is in order of µsec but bandwidth requirement is considerably

reduced; if it does not, then transport latency is specified solely by the requirements

of the application layer which is typically in the milli second range which most of the

transmission system will be able to support.

The latency requirements of fronthaul interface eCPRI on the transport network are

specified in eCPRI Specification [8]. Four different classes of (one way) latency are

defined for eCPRI i.e. 50, 100, 200, 500 µsec. However other standardization bodies
have different approach. For example, the xRAN group has taken an approach in

13
which the latency requirement is derived from the processing capabilities of the radio

equipment at either end of the Fronthaul (Fx) link [7]. The equipment is categorized

into different classes, depending on the combination of the equipment, the one-way

residual latencies can be as large as 350 µsec or even higher. A typical latency

requirement is given in Table 2 and Fig. 5 to understand magnitude of requirements.

8.3 Bandwidth Requirements

As discussed in previous sections, transport bandwidth requirement depends upon

which layer of radio signal is processed in RU and DU. Even low PHY processing in

RU reduces the bandwidth requirement by about 2-15% (ITU-T G series Supplement

66) [13] as compared with traditional CPRI approach. Calculations methods for

bandwidth required at Fx, F1 and NG interface is given in appendix II. Table 2 and Fig.

5 provides bandwidth requirement at different layer of radio process chain at Fx and

F1. It is to be noted that the values given in the Table 2 is specific to a cell configuration

(3GPP TR 38.801 V2.0.0 (R14)) [12] which may change with different cell

configuration. It just provides a glimpse of magnitude of bandwidth requirement to

foresee and plan for 5G transport network.

Table 2 Transport bit rates and latency ranges at different functional split interfaces [12]

Protocol Required Required One way latency

split downlink uplink bandwidth (order of magnitude)
option bandwidth

Option 1 4 Gb/s 3 Gb/s

Option 2 4016 Mb/s 3024 Mb/s 1-10 ms

Option 3 [lower than Option 2 for UL/DL]

Option 4 4000 Mb/s 3000 Mb/s

Option 5 4000 Mb/s 3000 Mb/s 100 to few 100 µsec

Option 6 4133 Mb/s 5640 Mb/s

14
 Option 7a 10.1-22.2 Gb/s 16.6-21.6 Gb/s

Option 7b 37.8-86.1 Gb/s 53.8-86.1 Gb/s

Option 7c 10.1-22.2 Gb/s 53.8-86.1 Gb/s

Option 8 157.3 Gb/s 157.3 Gb/s

[Cell configuration: RF 100 MHz, 256-QAM, 8 MIMO layers, 32 antenna ports from
Annex A in (3GPP TR 38.801 V2.0.0 (R14)) [12]

It must be noted, however, that in general there is not a fixed ratio of transport
bandwidth between different split options. In field deployments, the throughput on the
air interface changes with the actual conditions of the radio channel (environmental
conditions, interferences, reflections, etc.). This throughput variation will in turn require
varying transport capacities at the different split options which is often less than the
calculated values (except for Option 8).

Fig. 5 A typical bandwidth and latency requirement of 5G RAN

15
8.4 OAM Requirements
In the 5G C-RAN architecture, especially in fronthaul, there is a need for coordination

between the transport network layer and the radio network layer. OAM functions (ITU-

T G.8013) [15] like monitoring of degradation of performance and fault detection etc.,

will need to be implemented to enable co-ordination between radio network operator

and transmission network operator to monitor its own network segment and hand over

the information to each other. Even there may be need for coordination for specific

services delivery as well.

Depending on the service, both out-of-service and in-service delay measurements

may be required. Some services may need only an out of service measurement prior
to activating the service, while others may require monitoring of delay at regular

intervals to ensure performance requirements are being met. Both one-way and two-

way delay measurements are required.

8.5 Synchronization Requirement

As per 3GPP [16], (ITU-T G.805) [11], the frequency offset at the air interface of every

RRU should be less than the value in the following table.

Table 3 Frequency offset requirement

BS class Accuracy
Wide Area BS ±0.05 ppm
Medium Range BS ±0.10 ppm
Local Area BS ±0.10 ppm

8.6 Network Slicing Requirements

Recommendation (ITU-T Y.3112) [17] describes the concept of network slicing and

use cases when a single user equipment (UE) simultaneously attaches to multiple

network slices in the 5G network. The use cases introduce the slice service type to

indicate a specific network slice and the slice user group for precisely representing the
network slice in terms of performance aspects and business aspects. This

16
Recommendation also specifies high-level requirements and framework for the

support of network slicing in the 5G network. The transport network is, in general, a

multi-service network and, in most cases, a common transport network infrastructure

will be shared between 5G services and other mobile and fixed services. It is

necessary to provide isolation between each of these services [10].

8.7 Protection Requirements

As compared to 4G, 5G is expected to carry more traffic and some of them are very

critical for example autonomous vehicle and remote surgery. Therefore, it calls for

better protection and restoration of its transport network. Protection or restoration

mechanisms should be used in the 5G transport network as necessary to meet the

requirements of the services being carried over the 5G network [10].

9 Transport Networks choices

There is general consensus (IEEP1914) [18], (ITU-R M.2083) [14] (ITU-T G series

Supplement 66) [13] on the type of interface CU, DU and RU should have eCPRI or

CPRI at RU/DU and Ethernet at DU/CU. Accordingly, transport network operating

between DU and RU are required to have devices with eCPRI or CPRI at both UNI

and SNI (RU-DU link) operating at 25GE for eCPRI, multiples of 10G/25GE for CPRI

and multiples of 10GE, 50G or a few 100GE at SNI/NNI (DU-CU/CN) in the access

network. There are a numbers of transport technologies (some of them shown in Table

4) such as point to point SDH, OTN, Ethernet, mm wave wireless, point to multi-point

PON, Time Sensitive Network (TSN) and Software Defined Network (SDN) which may

be used in fronthaul. Undoubtedly OTN meets most of the requirement of 5G transport

including latency but cost may be a factor to bother. At this point of time, PON [13] is

being considered as one of the promising technologies because of its sheer presence

in access network ecosystem and cost but it does not go without challenges. For the

backhaul and F1 interfaces, TDM-PON with data rates over 10 Gb/s should be

sufficient to meet both the bandwidth and latency requirements. However, Fx interface
will require PON with much higher data rate and lower latency. We will discuss

17
deployment of PON in detail in subsequent sections. Other technologies can also be

evaluated on the lines of PON.

Table 4 Data Rates of different Technologies

TECHN
DATA RATE
OLOGY
STM-1 STM-4 STM-16 STM-64 STM-256
SDH 155 622 2.5 10 40
Mbit/s Mbit/s Gbit/s Gbit/s Gbit/s
OTU-1 OTU-2 OTU-3 OUT-4 OUT-C2
OTN 2666 10709 43014 100 200
Mbit/s Mbit/s Mbit/s Gbit/s Gbit/s

GPON XGPON XGSPON NGPON2 WDMPON*

PON 2.5/1.25 10/2.5 10/10 40 1,2.5,10 25 50
Gbit/s Gbit/s Gbit/s Gbit/s Gbit/s Gbit/s Gbit/s
*ITU Standard for 50G PON is under study and likely to be published in 2020.

9.1 OAM Solutions

In the fronthaul link, it could be implemented through Out-of-band monitoring or In-

band monitoring. Choice of in band and out of band will primarily depend upon

requirement of bandwidth and latency by radio network layer and availability channel

for OAM functions. OAM signalling should not consume too much of bandwidth or

introduce too much latency into the fronthaul network. It is desired that OAM messages

are inserted in low layers near the physical line, e.g., PMD, PCS, or MAC layers,

instead of the IP or upper layers [14] [13].

9.2 Synchronization solution for transport network

Synchronisation solution defined in (G.8275/Y.1369) [19] should be used in the

transport network to support 5G frequency and phase/time synchronization

requirements. As per this this solution, every node between the clock server and the
end application node should support the SEC/eSEC and T-BC or T-TC clock (ITU-T

18
G.8271.1) [20]. The figure below is a generic construct for synchronization for the

transport network and depicts one example of how such a network could be designed.

Fig. 6 Example Synchronization Transport Network Topology

• The deployment position is limited by the number of hops from the clock server to

the RRU, which is described in the HRMs of [20].

• In general, the frequency reference master PRC/ePRC is deployed in the core

network, and the phase/time master PRTC/ePRTC is deployed in the access,

aggregation, or core network.

• For the frequency synchronization solution, the transport nodes between the

PRC/ePRC and RRU shall support the appropriate SEC or eSEC physical layer

clock.

• For the phase/time synchronization solution, the transport nodes between the

PRTC/ePRTC and RRU shall support the T-BC PTP layer clock. The clock

specification is (ITU-T G.8273.2) [21], and the network limit is defined in (ITU-T

G.8271.1) [20], and the PTP full timing support profile is (ITU-T G.8275.1) [22].

19
 • Optical layer nodes without optical protection/restoration are not required to

support the OEC, eOEC or T-BC. This is because these nodes do not affect the

accuracy of transport synchronization network.

9.3 Network Slicing Solutions

From a management perspective, the Network Slicing services are supported by

Virtual Networks (VNs). The forwarding plane must ensure that the traffic from one VN

does not get delivered to a different VN due to any reason. It is also necessary for the

forwarding plane to provide sufficient isolation that limits the interaction between the

traffic in different VNs.

9.4 Protection/ Restoration Solution

General transport protection mechanisms are described in the (ITU-T G.808.1) [23]

(ITU-T G.808.2 [24] series of Recommendations. In order to allow for deployment of

survivability mechanisms in multiple layers, any new protection or restoration

mechanisms should support the use of hold-off timers.

10 An Analysis of PON as a Transport for 5G Midhaul and Fronthaul Application

The PONs which can support bandwidth consumption (see Table 2) of fronthaul and

midhaul are TDM-PON (XG-PON [25]/XGS-PON [26]), TWDM-PON (NGPON2 [27])

and WDM-PON.

The single-channel TDM PON systems inherently require a quiet window to allow
activation of new or returning ONUs/ONTs. Both XG-PON and XGS-PON with 20 km

differential fibre distance, requires a 250 µs general quiet window for ONU/ONT

discovery and for a 200µs targeted quiet window for each discovered ONU/ONT.

During the quiet window, the OLT CT pauses upstream transmission of the in-service

ONUs, thus contributing to the instantaneous latency and jitter experienced by all

upstream traffic flows on the PON.

20
The multi-channel TWDM PON [27] systems have capacity to sacrifice to allocate a

subset of wavelength channel pairs to perform new and returning ONT activation,

while keeping one or more wavelength channel pairs for low latency operation without

having to do discovery and activation functions. Once an ONT is activated in an

allocated activation wavelength channel pair, it is handed over to the operational low

latency wavelength channel pair. The active ONU/ONT handover does not impede

services of other ONTs in the low latency operation channel, as long as the system

implements consistent ranging or other method of equalization delay coordination.

WDM-PON does not share its bandwidth as each ONT uses independent wavelength

channel pairs so there is no queuing.

Since Fx has strict latency requirement, WDM-PON and TWDM-PON (NGPON2) are

good candidate for this use case. A dedicated TWDM-PON would be more resource

efficient due to its ability of statistical multiplexing but with appropriate ranging

schemes and bandwidth allocation. Compared with Fx, the requirement of both

bandwidth and latency are much relaxed at F1 interface so any PON of required

capacity can be used for it.

10.1 PON Architecture for 5G fronthaul and midhaul transport

By definition, OLT/ONT belong to the Transport Network Layer (TNL) and CU/DU/RU

belong to the Radio Network Layer (RNL). PON may be used to support for both F1

and Fx interfaces. Same PON system may serve both F1 and Fx interfaces or it may

be two different PON systems as illustrated in

Fig. 7. The architecture may be called cascaded as shown in figure below or it may be

parallel or it may be just single serving either F1 or Fx. It may consist of a single PON

technology like TDM-PON, WDM-PON, TWDM-PON (NGPON2) or with WDM PtP

overlay. The ODNs topology could be point-to-point (PtP), star, or tree. The choice of

the architecture would be decided by specific deployment scenarios, service-based

21
latency and performance requirements as well as operator’s priority. Required

throughput, latency and cost will ultimately decide the choice of PON devices.

5G Backhaul Midhaul Fronthaul

Network NG Interface F1 Interface Fx Interface

5G NGC CU DU RU
Node
s

Transport
Network
node TN TN OLTA ONTA OLTB ONTB

PON

Fig. 7 Concept of layered structure showing RNL (CU, DU, RU) and TNL (OLT, ONT).

The existing PON systems may have to support the followings interfaces unless

exclusive PON network is constructed for 5G [13];

• Several F1 interfaces (one per 5G carrier) in addition to existing mobile and

fixed services;

• Several FX interfaces (one per 5G RUs) in addition to existing mobile and fixed

services;

10.2 Legacy PON with WDM overlay to support 5G interface

Readily available solution to support midhaul and fronthaul could be to overlay new

wavelengths in a legacy PON, without sharing bandwidth with legacy fixed access

services. Both NG-PON2 TWDM and PtP WDM could be used for this scenario. TDM-

PON (XG-PON/XGS-PON) may also be considered purely on the ground that it may

be cheaper compared with other two PON referred here with a caveat discussed latter.

In TWDM-PON and WDM-PON signals from the OLTs, each on a different wavelength
channel, are combined in a wavelength multiplexer before transmitting to the cell sites.

22
In the ODN, a wavelength splitter, usually a power splitter except if it is a pure WDM

deployment where it may use an Array Waveguide Grating (AWG) device, routes the

individual wavelengths to different ONTs, each of which is connected to an RU

supporting one of the three sectors of an antenna.

10.3 Dedicated PON to support 5G interface

In Indian telecom access network, fixed services are provided through GPON [28]

which in any way can’t support bandwidth requirement of 5G, so a more practical

solution is to build dedicated PONs using a separate fibre from the existing ODN

specifically for mobile fronthaul and midhaul. Network architecture of dedicated PON

will look like as given in Fig. 8 minus legacy TDM-PON i.e. GPON.

Fixed Service nodes TDMPON OLT-h ONT-h

ODN
CU WDMPON OLT CT1 Fx
F1
WM ONT RU
Fx
WDMPON OLT CTn ONT RU
splitter

DU CEx
Aggregate

NGPON2 OLT CT1 ONT RU

F1
CU

DU NGPON2 OLT CT2 WM ONT DU RU

NGPON2 OLT CTn ONT DU RU

F1

Fig. 8 F1 and Fx based on legacy PON with WDM overlay

Although not all connectivity shown in Fig. 8 but following connectivity should be

possible in PON architecture

• Each OLT can connect to multiple CU/DUs;

• Each CU/DU can have RUs over multiple PONs hence can connect to multiple

OLTs;

• Each PON can serve a mix of RUs pertaining to different CU/DUs;

• Each RU pertains to only one CU/DU;

• Each RU can have multiple interfaces, each interface connects to a ONT UNI.

23
A PON with mixed F1 and Fx is as shown above in Fig. 8 is possible but the different

requirements on bandwidth and latency could pose implementation challenges.

10.4 Dimensioning of aggregate data rates at F1 interface to select an appropriate

PON system

To calculate required aggregate data rate at F1 interface to arrive at per PON port

capacity, consider a PON system where a CU is connected to multiple DUs through

single OLT and multiple ONTs. Each DU is connected to multiple RUs via dedicated

CPRI/eCPRI point-to-point links. Since F1 rates are just upto 3% above backhaul rates,
backhaul rates as calculated from the formula given in Appendix II can be used to arrive at
aggregate data rates required at PON port. Taking an example of a single DU serving a single

RU with one UE, required peak backhaul data rate is given for different cell configuration in
Table 5 [13].

Table 5 Peak backhaul data rate from a single DU serving a single RU

Considering single DU serves 10 RUs, aggregate bandwidth can be calculated using

formula given in appendix II corresponding to the values in Table 5.

Table 6 Aggregated F1 interface rate from a single DU serving 10 RUs [13]

24
See the calculated value in Table 6. One or multiple DUs can be served by a single

optical channel operating at 2.5 Gb/s (no colour), 10 Gb/s (green), 25 Gb/s (light pink),

or 50 Gb/s and beyond (pink) depending on the radio configuration considered.

Alternative way of dimensioning can be done using methods suggested by NGMN

[29]. According to it, a cell site is considered operating at its peak capacity when one

of its antenna sectors (RUs) is running at peak rate and the other two at average rate.

Considering the example of 64T64R in Table II 2 (values rounded off), the total

transport data rate for this (peak rate) cell site is 6.72 Gb/s (= (1*4 Gb/s + 2*0.8 Gb/s)

*1.2) (factor 1.2 is transmission channel overhead). However, a cell site is considered

operating at the average value when all its RUs are running at average rate and total

transport data rate (average rate) would be 2.88 Gb/s (= 0.8 Gb/s*3*1.2). The capacity
requirement for a CU port in Fig. 9 would be 21.12 Gb/s which can be supported by

a single 25 Gb/s PON port [13]. In the figure below, peak RU/ peak site shown in red

colour and average RU/Sites shown in green colour.

RU RU
ODN F1
U U RU
U
ONT DU
F1
PON Port Avg rate cell site 2.88Gbps
splitter

RU
CU (.8Gb
21Gbps
ONT DU ps)

Peak rate cell site

6.75Gbps RU
RU (.8Gb
(4Gb ps
ps)

4 Other Avg rate cell site

connected on same PON port

Fig. 9 NGMN method for calculation of capacity requirements per PON port

25
10.5 PON System Implementation Challenges and Resolution

10.5.1 Dynamic Bandwidth Allocation (DBA)

In a TDM-PON, DBA mechanism can cause delay in the order of ms, which is not

compatible with delay sensitive 5G services, especially over the Fx interface. In TDM-

PON, the downstream latency is low, but upstream latency remains in the order of

several milliseconds. This is because each ONU/ONT must send a request to an OLT

first, and then the OLT grants an upstream bandwidth of each ONU/ONT to avoid any

upstream data collisions. In order to use TDM-PON for low-latency demanded

fronthaul transport, it is necessary to reduce upstream latency. Many latency

improving mechanisms have been proposed, some of the solutions to this TDM-PON

problem are discussed below.

10.5.2 Differentiated Service

One method could be to provide differentiated service to upstream traffic coming from

RU to ONT with highest priority [30] to reduce wait time of mobile traffic at ONT as

shown in Fig. 10 below compared to other traffic hitting same PON port at OLT. Priority

could be provided by allocating fixed bandwidth (bw) or assured bandwidth by DBA.

Flip side of this approach is that bandwidth remains locked and is not available for any

other service even if there is no mobile traffic.

Mobile Traffic
DBA

Best Non Assured Assured Fixed

Effort BW BW BW BW
Highest Priority Traffic

Fig. 10 Dedicated bandwidth for Low latency 5G fronthaul transport

26
10.5.3 CO DBA
Another way to reduce wait time of upstream traffic of ONT could be through advance

[31] allocation of upstream time slot through exchange of information between OLT

and mobile equipment where upstream time slot is allocated as per demand from

mobile equipment (UEs). This mechanism is called Coordinated DBA (CO DBA). See

Fig. 11.

Fig. 11 CO DBA mechanism for mobile fronthaul

10.6 Fibre reach and split ratio limitations

When using PON for 5G transport, the fibre reach is limited by the latency

requirements of the service (Appendix-I) and the split ratio is limited by the bandwidth

consumption (Appendix-II). The typical PON reach and number of splits in residential

implementations may not apply. Current PON systems are designed to support 20km

reach for services with maximum 1.5ms mean signal transfer delay [28] while they still

may work fine for fixed services but low latency services may fail in the same span.

For example, for 100 µs one-way latency (Table 2), it is not possible to support 20 km

reach because the propagation time in fibre alone (5µs/km) would exceed 100µs.

For the Fx interface, the tight latency requirement between DU and RU could limit the

fibre reach to be shorter than the typical reach of residential implementations. The

bandwidth requirement could limit the TDM-PON split ratio to be much lower.

27
In summary, when designing a new PON system for 5G transport, requirements on

bandwidth and latency need to be carefully considered to decide the PON fibre reach

and split ratio.

10.7 Synchronization challenges in PON

In order for PON to be a viable solution for 5G NR transport, it is critical that PON

meets the synchronization timing error requirements described in Table 3 . Several

factors affecting the synchronization timing precision are discussed as an example for

TDM-PON [26]:

• Fibre propagation delay of different wavelengths used as upstream and

downstream wavelengths: Using XG-PON as an example, the difference in the

index of refraction of the downstream (1577 nm) and upstream (1270 nm)

wavelengths result in a systematic error of 61.2 ns when transmitting over

20 km;

• Equalization Delay (EqD) accuracy: as limited by drift of window (DOW)

threshold, the EqD accuracy should stay within ±3 ns for XGS-PON;

• Internal timing correction: these are delays due to logical computation and/or

other events inside OLT and ONT. One large contributing factor is the

downstream SerDes delay, which is about ±6.4 ns for XGS-PON;

• System hardware internal error: different signals may have different

transmission paths due to the printed circuit board design. These errors can

generally be calibrated in the system level.

For higher speed PONs, constraints in the synchronization timing requirements would

impose even more challenges that need to be solved in order to use PON for 5G

transport.

10.8 Coordination between the PON and wireless interface

For requirements at the PON-wireless interface, the CO-DBA interface needs to be

supported by TDM-PON. Since WDM-PON provides point-to-point connections in the

28
physical layer, its interaction with wireless network is much easier than that of TDM-

PON to implement. For both TDM-PON and WDM-PON, multiplexing schemes to

interconnect OLT and CU/DU need to be chosen so that one CU/DU can flexibly

support more than one OLT wavelength channel.

29
11 Conclusion/Recommendation

Considering the discussion in preceding sections, latency budget in Appendix-I and

bandwidth requirement in appendix-II for 5G transport network, following conclusion is

drawn.

a) In C-RAN, for eMBB services, throughput requirement in fronthaul is

astronomically high compared with what is seen in 4G. Neither Current radio

SDH link used in 4G backhaul (which comprises 80%) nor low order optical

SDH and GPON used in 4G backhaul will be able to cater 5G fronthaul capacity

requirement.

b) Latency requirement in fronthaul is in order of 100 to a few 100µs so apart from

processing delay in transmission equipment, delay due to optical fibre itself

becomes significant. So while a transmission network designed according to

optical budget may still work fine but low latency service on the same

transmission network might fail due to exceeding latency budget. This may put

a restriction on how long a fronthaul should be, not on the basis optical budget

of devices alone but required latency budget.

c) If PON has to become a real challenger for 5G fronthaul, infact it has to address

issues of bandwidth allocation, ranging and synchronisation from ab initio as

current generation of PON is designed primarily to support fixed broadband

services. In this regard development of 25G and 50G WDM PON around the

requirement of 5G is heartening which might increase the uptake of PON as a

fronthaul transport.

d) Though there may be common wireless hardware to support different 5G

services but it may require different fronthaul solution depending upon latency

needs so transport network in fronthaul has to be flexible to serve varying traffic

and latency demands.

e) At present, wireless network and transmission network are monitored

independently as there is clear separation between these two layers, however

30
 in fronthaul, it is not an IP data but a digitalised radio signal that needs to be

controlled by radio network, and to make it happen, transmission network has

to insert necessary message in its OAM which can be retrieved by radio

controllers to serve its purpose.

f) Every node between the clock server and the end application node should

support synchronisation.

g) Assumptions and step by step calculation of bandwidth and suggested network

topology is given in appendix II for constructing the transport network for 5G

including support to existing services.

h) Though not directly related with current topic but an important requirement in

field will arise for co-locating high capacity transmission device like OTN,
DWDM etc. with CU, DU and RU to meet high capacity demand. Current flavour

of deployment of radio network in outdoor to reduce energy consumption will

pose a challenge for co-locating these devices.

i) A broader view of 5G transport network is illustrated in Fig. 12 and Table 7a

generalised 5G transport network requirement is summarised in the Table 7 to

support all the services envisaged in 5G wireless network.

Fig. 12 5G transport network overview [10]

31
 Table 7 Summary of Transport network for 5G

Transport Access Metro Metro Core or

network Aggregation Backbone
domain
domain Network domain

Fronthaul Midhaul and Midhaul and Backhaul

Backhaul Backhaul

5G Fx (CPRI/eCPRI) F1, NG, Xn F1, NG, Xn NG, Xn

Interface (Ethernet) (Ethernet) (Ethernet)
supported

5G Nodes RU-DU DU-CU,CU- DU-CU,CU- CU-NGC, CU-CU

involved NGC, gNB-gNB NGC, CU-CU (gNB-gNB)
(gNB-gNB)

Topology Hub-and-spoke, Ring, chain or Ring or dual Ring or dual

chain or ring star links homing uplink homing uplink

UNI eCPRI: 25GE 10GE/25GE/50 10GE/25GE/5 10GE/25GE/50G

GE 0GE/100GE E/100GE/400GE
CPRI:
N×10G/25Gb/s
or1×100Gb/s

NNI/SNI 10/25/100Gb/s or N×25G/50Gb/s N×25G/50G10 N×25G/50G/100G

100Gb/s 0G/200Gb/s /200G/400Gb/s
N×25G/50Gb/s
WDM

Distance <10km < 40km < 40-80km < 40-80km or

>100 km

32
Notwithstanding what is given in the Table 7 above each 5G application will require

different transmission solution especially in fronthaul and thus will require careful

planning specific to deployment scenario.

12 Way Forward

It was not possible to include all 5G technologies and all deployment scenario and its

impact on all transport technologies in the study paper due to limited resources, it is

therefore required that following areas which have not been covered, may be taken up

for further study. Areas that may be taken for further study are;

a) For the air interface, only MIMO is considered in the above discussion.

However, in 5G, other technologies like massive MIMO, mmWave MIMO, Fibre

Bank Multi Carrier (FBMC), full-duplex radio Non-Orthogonal Multiple Access

(NOMA) etc. will be used. Their deployment scenario, impact of different

technologies on the transport network may be examined.

b) Various architecture may be defined with latency requirements. For example, if

latency requirement is <1 msec, it is required to integrate CU+DU+RU in a

single unit. Similarly, other architectures may also be defined.

c) Constraints of latency may be linked with latency requirements on the opted 5G

and transport technologies.

d) Separate deployment scenarios and transport technologies for eMBB, uRLLC,

and mMTC may be examined.

e) Further elaboration on Network slicing, isolation among slices and control and

management may be carried out.

f) Deliberation on each transport technologies like OTN, TSN, SDN, DWDM with

respect to 5G transport requirement may be studied.

g) Network security aspects of 5G transport may be included in future study.

33
13 Appendix I: Latency

13.1 End-To-End Service Latency Budget in 5G Networks

End-to-end service latency is an important characteristic of 5G networks. Table I 1

summarizes requirements for end-to-end latency for some types of services based on

(3GPP TR 38.913, V14.3.0) [2]

Table I 1: End to end latency requirements for selected service types

Service Type Latency Requirement

eMBB User plane（UE-CN） 4ms
Control plane（UE-CN） 10ms
uRLLC User plane（UE-CU/MEC） 0.5~1ms
Control plane（UE-CN） 10ms

Figure I-1 illustrates an example of how the end-to-end latency budget could be
allocated to different nodes and transport networks within the 5G architecture.

UE RU DU CU/MEC CN

Process Process Frontha Process Process Process

Wireless Midhaul Backhaul
delay delay ul delay delay delay
transmis transmis transmis
transmis
sion sion sion
sion
delay delay delay
delay

T0 T1 T2T2 T3 T4 T5 T6 T7 T8

.5~1ms (uRLLC)

4ms (eMBB User plane)

10 ms (Control Plane)

Fig. I 1 End-to-end latency budget [10]

34
14 Appendix II-Bandwidth Calculations

14.1 Base Station Fx Bandwidth Requirements Calculation Methods

3GPP has decided to specify a low layer split point for the gNodeB architecture based

on an Option 6 (MAC-PHY) or on Option 7 (Mid PHY) split but the decision is awaited.

The peak throughput for an option 6 split is comparable to that for an option 2 split

(F1). The same NGMN Alliance aggregation dimensioning as used for F1 below can

also be used for option 6 split architectures. So in this case, transport capacity required

at Fx is same as F1.

It is to be noted that the ratio between peak and mean of the option 7 splits do not

follow the same analysis as is used for the F1-interface below (20% as a rule of

thumb). Therefore, the aggregation algorithm and the average throughput calculation

for intra-PHY splits needs further study. However, an approximate calculation is given
below in formula BRIU/IID.

The total bit rate needed at option 8 to deliver the appropriate number of fast CPRI [5]

streams to the gNB-DU/RRH, via the F1/Fx interface, can be determined based on the

formula [32] (1)

BR8 = S · A · fs · bs · IQ · HF · LC (1)

where S—the number of sectors per gNB-DU, A—the number of antenna modules in

array per one sector, fs—speed of sampling , bs—number of bits per sample

(depending on the format of the sampled signal: is equal 15 per one I/Q subcarrier for

4G/5G-Rel-15 (cyclic prefix orthogonal frequency division multiplexing (CP-OFDM))),

IQ—a factor indicating a separate sub-sampling I as in-phase and Q as quadrature (is

equal 2), HF (Headers Factor)—a factor indicating the redundancy of CPRI headers

(redundancy is 1/15, therefore, amounts to 16/15), LC—alphabet nB/mB line code

(8B/10B—ratio of 10/8—used in CPRI Options 1-7, 6. 4B/66B—ratio of 66/64—used

in CPRI Options 7A-10).

35
Table II 1 shows the approximate data rates for time domain IQ data fronthaul (CPRI

rates without line coding) needed to support various radio frequency bandwidths and

numbers of antenna ports in wireless networks using parameter ranges given by 3GPP

in [3GPP TR 38.801].

Table II 1 Required fronthaul data rate in 5G wireless network [3GPP TR 38.801]

Number of Radio Channel Bandwidth

antenna 10 MHz 20 MHz 200 MHz 1 GHz
ports
2 1 Gb/s 2 Gb/s 20 Gb/s 100 Gb/s
8 4 Gb/s 8 Gb/s 80 Gb/s 400 Gb/s
64 32 Gb/s 64 Gb/s 640 Gb/s 3,200 Gb/s
256 128 Gb/s 256 Gb/s 2,560 Gb/s 12,800 Gb/s

The rate consumption calculations that will occur at the Split 6 during the maximum

load, according to the CPRI Forum, can be carried out on the basis of a simplified and

adapted formula [33] [34] (2)

BR6 = S · NL · NSC · NSY · RC · K · HF · LC /TF (2)

where S—the number of sectors per gNB-DU/RRH, NL—the number of layers

(related to the number of layers needed to create and form space beams directed to

mobile UE), NSC—the number of active CP-OFDM subcarriers in BB channel (the

number of subcarriers for the new waveform from the 5G-NR interface should be

used—in the channel with a specified frequency bandwidth [MHz]), NSY—the number

of CP-OFDM symbols or newest waveform per standard time-frame (in the non-

standalone 5G-Rel-15 interface a coherent value was assumed in relation to FDD-

LTE), RC—the factor of FEC code efficiency, K = log2 M—bits per modulation symbol,

where M—modulation order (usually for M-QAM format), HF (Headers Factor)—CPRI

frame redundancy factor (redundancy at 1/15 for CPRI, so the ratio is 16/15—much
smaller and variable for the eCPRI, depending on the size of the charge in a frame

36
matched to the Ethernet frame and/or OTN/PON , LC—a line code also used as a

scrambling (for faster streams it is 64B/66B, so the code rate is 66/64) and a physical

Ethernet link control (also applicable to the RoE technology ]). The line code in the

optical Ethernet link applies only to the LAN format. Ethernet WAN interface is devoid

of this code, because physical layer functions are taken over by the transport system,

e.g., PON/OTN. When the radio samples are transported in the fronthaul/midhaul

paths using Ethernet (RoE) frames only, the LC value is included in the HF redundancy

[35].

At option 7 corresponding to option IU/IID of CPRI forum an additional parameter

appears which determines the number of quanta in the process of converting the

frequency sub-carriers. Thus, the coding and modulation rules will not be taken into

account, as the frequency components will be quantized. In order to estimate the bit

rate that will occur in the F1/Fx path at Split IU/IID, an approximate formula [33] (3) can

be used

BRIU/IID = 2 · S · NP · NSC · NSY · NQF · HF TF (3)

where S—the number of sectors per gNB-DU/RRH/AAU, NP—the number of

ADC/DAC chains (used in digital beamforming (DBF)—special application in massive-

MIMO mode), NSC—the number of active CP-OFDM subcarriers in BB channel (the

number of subcarriers for the 5G-NR waveform interface should be used), NSY—the

number of CP-OFDM or newest waveform symbols per standard 4G/5G time-frame,

NQF—the quantizer resolution in the frequency domain, HF (Headers Factor)—eCPRI

frame header redundancy factor and higher IP/Ethernet network layers, TF—frame

duration (4G/5G system parameter) [35].

37
14.2 Base Station F1 Bandwidth Requirements Calculation Methods

The peak throughput for an option 2 split (F1) is comparable to that for an option 1

split (Backhaul). It is higher than the backhaul bandwidth by up to 3%.

The peak user data rates for the F1 interface can be calculated using the same formula

as that is used for calculating backhaul bandwidth given following sections.

As per NGMN [29], the ratio of peak-rate and average-rate per cell site is between 4

to 6 in a typical operating condition. Therefore, for dimensioning the transport network

capacity at F1, an ''average rate at busy time'' can be safely assumed as 20% of the

peak rate at quiet time or it can be calculated using the formula given below.

The above value of F1 is only pay load for transmission network. The bandwidth

required for transporting the data at the F1 interface over a transmission network will

be higher because of transmission networks own overhead introduced by the

transmission protocols, scheduling and synchronization mechanisms. To account for

these overheads, 20% increase of data rate is added to the value calculated above.

So far F1 interface

The peak transmission bandwidth aggregated at DU of one 5G base station (Peak

value of 𝐵𝑎𝑔𝑟 ) could be assumed as the sum of one cell with peak value of B CELL and

the other (N-1) cell is with average value of BCELL, as shown in Equation 4, and N is

the number of cells aggregated at DU.

𝑃𝑒𝑎𝑘𝑣𝑎𝑙𝑢𝑒𝑜𝑓𝐵𝑎𝑔𝑟 = 1.2 ∗ [𝑃𝑒𝑎𝑘𝑣𝑎𝑙𝑢𝑒𝑜𝑓𝐵𝐶𝐸𝐿𝐿 + 𝐴𝑣𝑒𝑟𝑎𝑔𝑒𝑣𝑎𝑙𝑢𝑒𝑓𝐵𝐶𝐸𝐿𝐿 × (𝑁 − 1)] (4)

The average transmission bandwidth of single IMT-2020/5G station (Average value of

𝐵𝑎𝑔𝑟 ) could be calculated by Equation 5 as following,

𝐴𝑣𝑒𝑟𝑎𝑔𝑒𝑣𝑎𝑙𝑢𝑒𝑜𝑓𝐵𝑎𝑔𝑟 = 1.2 ∗ 𝐴𝑣𝑒𝑟𝑎𝑔𝑒𝑣𝑎𝑙𝑢𝑒𝑓𝐵𝐶𝐸𝐿𝐿 × 𝑁 (5)

Calculated value for F1 is given in Table II 2 for a given cell configurations.

38
 Table II 2 F1 signal bandwidth requirements for 256-QAM per carrier

Radio Number MIM Radio Peak Averag Average Peak

frequency of Tx/Rx O channel backha e transport transport
band (GHz) antennas layer bandwi ul data backha data rate data rate for
s dth rate per ul data for F1 F1
(MHz) RU rate per [1.2*3*Avg [1.2*(1*Peak
(Gb/s) RU /RU](Gb/s) /RU+2*Avg/
(Gb/s) RU)] (Gb/s)

5G, low freq 16T16R 4 100 2 0.4 2.8 3.36

(3.5/3.7) 64T64R 8 100 3.3 0.675 4.65 5.58

5G, high
4T4R 2*2 2*400 9.9 2.442 14.78 17.7
freq (26/28)

14.3 Base Station Backhaul Bandwidth Requirements Calculation Methods

In order to calculate backhaul bandwidth certain assumptions are made which are

listed below.

▪ The peak user data rates for the backhaul interface can be calculated using the

formula published by the Small Cell Forum in the Appendix C of SCF document

159.07.02 [9] for the PDCP-RLC split point and using radio channel parameters

taken from the 3GPP documents TS 36.213 for LTE [36] or TS 38.214 for 5G [37].

This model yields the maximum data rate that needs to be transported in case

there is only one UE in the cell, communicating with the cell under perfect channel
conditions at maximum possible rate (peak rate at quiet time). This rate scales

approximately linearly with the RF bandwidth, with the number of independent data

streams (MIMO layers) and with the QAM order.

▪ The aggregate data rate for multiple UEs communicating simultaneously in the cell

will be less than this peak rate due to non-optimal channel conditions, dynamic

traffic variations, and interferences etc. As per NGMN [29], the ratio of peak-rate
and average-rate per cell site is between 4 to 6 in a typical operating condition.

39
▪ According to NGMN [29], a cell site is considered operating at its peak capacity

when one of its antenna sectors (RUs) is running at peak rate and the other two at

average rate. In some 4G deployments, the radio unit and antennas are separate,

while in 5G they could be integrated in a single RU.

▪ To improve coverage and increase cell site density in 5G New Radio, it is

envisioned that both high and low radio frequency bands will be used. The low

frequency band (e.g., 3.5/3.7 GHz) will be for macro cells to provide general

coverage, while high frequency band (26/28 GHz) will be mainly for microcells in

hot spot areas.

The transmission bandwidth of one cell (𝐵𝐶𝐸𝐿𝐿 ) is calculated by Equation 6 as

following,

𝐵𝐶𝐸𝐿𝐿 = 𝐵𝑠 × 𝐸𝑠 × (1 + 0.1) × 𝑃𝑇𝐷𝐷 (6)

Here, 𝐵𝑠 is the wireless spectral bandwidth of this cell; 𝐸𝑠 represents the wireless

spectral efficiency, which has peak and average value, and the exact values depends

on the wireless vendors’ product solution; Factor 0.1 is the additional encapsulated

overhead information; PTDD represents the proportion of TDD downlink.

Using the peak and average value of 𝐸𝑠 , the peak and average value of 𝐵𝐶𝐸𝐿𝐿 could

be calculated by Equation 7 and 8 as following,

𝑃𝑒𝑎𝑘𝑣𝑎𝑙𝑢𝑒𝑜𝑓𝐵𝐶𝐸𝐿𝐿 = 𝐵𝑠 × 𝑃𝑒𝑎𝑘𝑣𝑎𝑙𝑢𝑒𝑜𝑓𝐸𝑠 × (1 + 0.1) × 𝑃𝑇𝐷𝐷 (7)

𝐴𝑣𝑒𝑟𝑎𝑔𝑒𝑣𝑎𝑙𝑢𝑒𝑜𝑓𝐵𝐶𝐸𝐿𝐿 = 𝐵𝑠 × 𝐴𝑣𝑒𝑟𝑎𝑔𝑒𝑣𝑎𝑙𝑢𝑒𝑜𝑓𝐸𝑠 × (1 + 0.1) × 𝑃𝑇𝐷𝐷 × (1 + 𝑃𝑋𝑛 ) (8)

The peak transmission bandwidth of single 5G base station (Peak value of 𝐵𝐵𝑆 ) could

be assumed as the summary of one cell with peak value of B CELL and the other (N-1)

cell is with average value of BCELL, as shown in Equation 9, and N is the number of

cells in one station.

𝑃𝑒𝑎𝑘𝑣𝑎𝑙𝑢𝑒𝑜𝑓𝐵𝐵𝑆 = 𝑃𝑒𝑎𝑘𝑣𝑎𝑙𝑢𝑒𝑜𝑓𝐵𝐶𝐸𝐿𝐿 + 𝐴𝑣𝑒𝑟𝑎𝑔𝑒𝑣𝑎𝑙𝑢𝑒𝑓𝐵𝐶𝐸𝐿𝐿 × (𝑁 − 1) (9)

40
The average transmission bandwidth of single 5G station (Average value of 𝐵𝐵𝑆 )

could be calculated by Equation 10 as following,

𝐴𝑣𝑒𝑟𝑎𝑔𝑒𝑣𝑎𝑙𝑢𝑒𝑜𝑓𝐵𝐵𝑆 = 𝐴𝑣𝑒𝑟𝑎𝑔𝑒𝑣𝑎𝑙𝑢𝑒𝑓𝐵𝐶𝐸𝐿𝐿 × 𝑁 (10)

Table II 3 provides some vendors’ specific values of Es for reference and Table II 4
provides calculation based on the formula discussed above for a particular cell

configuration.

Table II 3 Vendor Specific Values of Wireless Spectral Efficiency of gNB

(CU+DU+RRU)

Wireless Low Frequency Station High Frequency Station

Vendor 𝑃𝑒𝑎𝑘𝐸𝑠 𝐴𝑣𝑒𝑟𝑎𝑔𝑒𝐸𝑠 𝑃𝑒𝑎𝑘𝐸𝑠 𝐴𝑣𝑒𝑟𝑎𝑔𝑒𝐸𝑠
(bit/Hz) (𝑏𝑖𝑡⁄𝐻𝑧) (bit/Hz) (𝑏𝑖𝑡⁄𝐻𝑧)

1 A 40 7.8 15 3.7
2 B 48 12 12 3
3 C 50 10 25 4

Table II 4 Examples of bandwidth requirements of LF and HF gNB

Parameters Low Frequency (LF) High Frequency(HF)

Bs 100MHz 800MHz

BS Cell 3 Cells, 64T64R 3 Cells，4T4R

Parameters

Peak value: 40bit/Hz; Peak value: 15bit/Hz;

Es Average value: 7.8bit/Hz Average value:
3.7bit/Hz

PTDD 0.75, Up: Down = 1:3 0.75, Up: Down = 1:3

100MHz×40bit/Hz×1.1×0.75= 800MHz×15bit/Hz×1.1
𝑃𝑒𝑎𝑘𝑣𝑎𝑙𝑢𝑒𝑜𝑓𝐵𝐶𝐸𝐿𝐿 3.3 Gbit/s ×0.75=

9.9G bit/s

41
 100MHz×7.8bit/Hz×1.1×0.75×1.05 800MHz×3.7bit/Hz×1.1
=0.675Gbit/s ×0.75 =2.442Gbit/s

（Assume that Xn traffic mainly (The HF station is

𝐴𝑣𝑒𝑟𝑎𝑔𝑒𝑣𝑎𝑙𝑢𝑒𝑜𝑓𝐵𝐶𝐸𝐿𝐿 occurs in the mean scenario） mainly used for hot-
spot, and the Xn traffic
is calculated in the LF
station.)

3.3 +（3-1）*0.675=4.65Gbit/s 9.9G +（3-1）

𝑃𝑒𝑎𝑘𝑣𝑎𝑙𝑢𝑒𝑜𝑓𝐵𝐵𝑆
*2.442G=14.78Gbit/s

𝐴𝑣𝑒𝑟𝑎𝑔𝑒𝑣𝑎𝑙𝑢𝑒𝑜𝑓𝐵𝐵𝑆 0.675G*3=2.03Gbit/s 2.442G*3=7.33Gbit/s

Table II 5 and Table II 6 provide examples of vendor specific bandwidth requirements

of LF and HF gNB.

Table II 5 Examples of Vendor specific per cell bandwidth requirements of LF and

HF gNB

LF per cell Bandwidth (Gbit/s) HF per cell Bandwidth (Gbit/s)

Vendor Peak Value of Average Value of Peak Value of Average Value of

Bcell Bcell Bcell Bcell

A 3.3 0.675 9.9 2.442

B 3.96 1.040 7.92 1.98

C 4.125 0.866 16.5 2.64

Table II 6 Examples of Vendor specific backhaul bandwidth requirements of LF and

HF gNB

LF base station Bandwidth HF base station Bandwidth

Vendor
(Gbit/s) (Gbit/s)

42
 Peak Value Average Value of Peak Value of Average Value of
of BBS BBS BBS BBS

A 4.65 2.03 14.78 7.33

B 6.04 3.12 11.88 5.94

C 5.86 2.60 21.78 7.92

14.4 Transport Network Node Capacity Calculation Methods for Backhaul

The transport network model assumption for D-RAN (CU+DU+RU at one place)

capacity requirements calculation method for 5G is listed below: Similar calculations

can be done in case F1 and Fx if they are to be put on ring.

• Access layer: Assuming there are 4 to 8 base station sites per access ring; The

capacity requirements are estimated for two typical scenarios: general scenario

(Scenario 1) and hot-spot scenario (Scenario 2). Scenario 1 is an access ring with

4 low frequency stations; Scenario 2 is an access ring with 8 base stations including

6 low frequency stations and 2 high frequency stations;

• Aggregation layer: Each aggregation ring has six transport network aggregation

nodes, and six access rings are connected to each pair of aggregation nodes;

• Core layer: Eight aggregation rings are connected to each backbone core nodes,

and capacity requirements are estimated based on three backbone aggregation

nodes;

• Assuming the bandwidth convergence ratio of access, aggregation, and core is

8:4:1.

A general view of transport network is given in Fig. II 1 which will give a bird’s eye

view of the kind of network 5G is needed. It will also help in conceptualising various

ring formations.

43
 Fig. II 1 5G Transport layers

For D-RAN deployment, the capacity requirements for transport network are estimated

as below based on the LF and HF gNB’s bandwidth requirements example in Table II

6.

1) Access layer:

For scenario 1：General area.

Capacity of access ring = 𝐴𝑣𝑒𝑟𝑎𝑔𝑒𝑣𝑎𝑙𝑢𝑒𝑜𝑓𝐵𝐵𝑆 for LF × (N-1) + 𝑃𝑒𝑎𝑘𝑣𝑎𝑙𝑢𝑒𝑜𝑓𝐵𝐵𝑆

=2.03 × (4-1) + 4.65 = 10.74G

For scenario 2：Hot spot areas.

Capacity of access ring = 𝐴𝑣𝑒𝑟𝑎𝑔𝑒𝑣𝑎𝑙𝑢𝑒𝑜𝑓𝐵𝐵𝑆 for LF × (N-2) + 𝑃𝑒𝑎𝑘𝑣𝑎𝑙𝑢𝑒𝑜𝑓𝐵𝐵𝑆 +

frequency single station peak + high frequency single station

=2.03 × (8-2) +14.78+7.33=34.29G

2) Aggregation layer:

For scenario 1:

Capacity of Aggregation layer = Capacity of access ring × 6 × 3 × convergence ratio

=10.74 × 3 × 6 × 1/2 = 96.66G

For scenario 2:

44
Capacity of Aggregation layer = Capacity of access ring × 6 × 3 × convergence ratio

= 34.29 × 3 × 6 × 1/2 = 308.61G

3) Core ring

Calculate the bandwidth of the backbone convergence ring based on the eight

aggregation rings that are connected to each backbone aggregation node.

For scenario 1:

Capacity of Core layer = Capacity of Aggregation layer × number of aggregation ring

× convergence ratio = 96.66 × 8 × 3 × 1/4=579.96G

For scenario 2:

Capacity of Core layer = Capacity of Aggregation layer × number of aggregation ring

× convergence ratio = 308.61 × 8 × 3 × 1/4 = 1851.66G

The 5G transport network may also support 4G services and private line services. As

shown in Fig. II 1, at each base station site 5G services from RRUs are connected to

a metro access transport node. A metro access transport node may also support 4G

CPRI signals and private line services (e.g. Ethernet, SDH), which are not shown in

this figure. The metro access transport nodes are connected to an aggregation node

co-located with a DU.

Analysis of client bandwidth for each type of client (5G, various options for 4G, and

private line) is shown in Table II 7 . In cases where 4G traffic is present, typically

only one of the CPRI rates would be present.

Table II 7 Client information of metro edge node

Client type Client Client interface Number of clients

bandwidth

5G eCPRI 25GE Ethernet 3 or 6

4G CPRI3 2.4576G CPRI 3

45
 CPRI4 3.072G CPRI 3

CPRI5 4.9152G CPRI 3

CPRI6 6.144G CPRI 3

CPRI7 9.8304G CPRI 3

GE 1GE Ethernet 1+

PL 10GE 10GE Ethernet 1

STM-N Maximum 10G SDH 1+

At the early deployment stage each base station has 3 RRUs while at the mature

deployment stage the number of RRU increases to 6. It is worth noting that 4G/5G

client signals originate from RRU and terminate at DU/BBU, while PL client signals

may terminate in the core network. It is also noted the fronthaul topology is point to

point for most application scenarios.

For the D-RAN case, RRUs are deployed together with DUs/CUs. One to three

DUs/CUs are deployed in each edge site, and each DU/CU serves 3 RRUs. There are

4-6 edge transport nodes in an edge ring, which connect to an aggregation node. Fig.

II 2 D-RAN Network CaseFig. II 2 illustrates a typical D-RAN network case.

Fig. II 2 D-RAN Network Case

46
The backhaul bandwidth of each base station (based on edge node clients’ BW) is
calculated in Table II 8.

Table II 8 Backhaul Bandwidth of edge node clients

RRUs Average value (Gb/s) Peak value (Gb/s)

3*1=3 2.03 4.65
3*2=6 2.03*2=4.06 2.03*1+4.65=6.68
3*3=9 2.03*3=6.09 2.03*2+4.65=8.71

Bandwidth for the aggregation node is shown in Table II 9, assuming that one edge
node is at peak bandwidth and the others are at average bandwidth. For a mixed 5G
and 4G scenario, the 4G traffic would add 4-6 Gb/s.

Table II 9 Bandwidth at aggregate node in 5G scenario

Edge nodes RRUs BW(Gb/s)/ring

3 2.03*3+4.65=10.74

4 6 4.06*3+6.68=18.86

9 6.09*3+8.71=26.98

3 2.03*4+4.65=12.77

5G 5 6 4.06*4+6.68=22.92

9 6.09*4+8.71=33.07

3 2.03*5+4.65=14.8

6 6 4.06*5+6.68=26.98

9 6.09*5+8.71=39.16

For small C-RAN application scenario, DUs are centrally deployed at edge sites, with
5-10 DUs located in an access site, and each DU serving 3 RRUs. Fig. II 3 illustrates
a typical small C-RAN network case.

47
 Fig. II 3 Small C-RAN Network Case

As described above for the D-RAN case, the average backhaul bandwidth of each

base station (3 RRUs) is 2.03Gb/s and the peak value of each base station is 4.65

Gb/s. There are 2-3 edge nodes for each edge ring. The client information of these

edge nodes is shown in Table II 10. As in the D-RAN case, the assumption is that only

one edge node has peak bandwidth, and the others have average bandwidth. 4G and

private line traffic will increase the required bandwidth.

Table II 10 client information of edge node for small C-RAN scenario (5G traffic only)

RRUs Average BW (Gb/s) Peak BW (Gb/s)

3*5 2.03*5=10.15 2.03*4+4.65=12.77
3*6 2.03*6=12.18 2.03*5+4.65=14.8
3*7 2.03*7=14.21 2.03*6+4.65=16.83
3*8 2.03*8=16.24 2.03*7+4.65=18.86
3*9 2.03*9=18.27 2.03*8+4.65=20.89
3*10 2.03*10=20.3 2.03*9+4.65=22.92

48
15 Abbreviations and acronyms

This document uses the following abbreviations and acronyms:

Abbreviations Description
3GPP 3rd Generation Partnership Project
4G Fourth Generation
5G Fifth Generation
AWG Array Waveguide Grating
BBU Baseband Unit
CP Control Plane
CPRI Common Public Radio Interface
Co-DBA Cooperative Dynamic Bandwidth Allocation
CRAN Centralized Radio Access Network
CU Central Unit
CN Core Network or Next Generation Core
D2D Device-to-Device
DBA Dynamic Bandwidth Allocation
DL Down Link
DOW Drift of Window
DRAN Distributed Radio Access Network
DU Distributed Unit
DWDM Dense Wavelength Division Multiplexing
e2e end to end
eCPRI evolved Common Public Radio Interface
eMBB enhanced Mobile Broadband
eNB eNodeB
ePRTC enhanced Primary Reference Time Clock
EqD Equalization Delay
FBMC Filter Bank Multi Carrier (Modulation)
gNB Next Generation NodeB
GPON Gigabit Passive Optical Network
HLS High Layer Split
HRM Hypothetical Reference Model

49
HRLLC High Reliability Low Latency Communication
iFFT Inverse Fast Fourier Transform
MAC Media Access Control
MEC Mobile Edge Computing
MIMO Multiple Input Multiple Output
mMTC massive Machine Type Communication
NGC/CN Next Generation Core/CN
NGFI Next Generation Fronthaul Interface
NGMN Next Generation Mobile Networks Alliance
NGPON2 Next-Generation Passive Optical Network 2
NNI Network-Network Interface
NOMA Non Orthogonal Multiple Access
NR New Radio
OAM Operations, Administration and Management
OBSAI Open Base Station Architecture Initiative
ODN Optical Distribution Network
OLT Optical Line Terminal
ONT/ONU Optical Network Termination/Unit (used interchangeably)
OTN Optical Transport Network
PCS Physical Coding Sublayer
PDCP Packet Data Convergence Protocol
PHY Physical Layer
PMD Physical Medium Dependent
PON Passive Optical Network
PRTC Primary Reference Time Clock
PtP Point to Point
QAM Quadrature Amplitude Modulation
RAN Radio Access Network
RF Radio Frequency
RLC Radio Link Control
RNL Radio Network Layer
RRC Radio Resource Control

50
RRH Remote Radio Head
RRU/RU Remote Radio Unit
SDH Synchronous Optical Networking
SDN Software Defined Network
SNI Service Network Interface
STM Synchronous Transport Module
T-BC Telecom Boundary Clock
TNL Transport Network Layer
TSN Time Sensitive Network
T-TC Telecom Transparent Clock
T-TSC Telecom Time Slave Clock
TWDM-PON Time and Wavelength Division Multiplexed Passive Optical
Network
UL Up Link
VN VIRTUAL NETWORK
UE USER EQUIPMENT
UNI USER NETWORK INTERFACE
UP User Plane
uRLLC ultra-Reliable Low Latency Communication
VRAN Virtualised Radio Access Network
WDM-PON Wavelength Division Multiplexing-Passive Optical Network
XG-PON 10-Gigabit-capable passive optical network
XGS-PON 10-Gigabit-capable symmetric passive optical network

51
16 Bibliography

[1] Fehrenbach, LLC Services in 5G: Low Latency Enhancements for LTE by Thomas Fehrenbach Et
al.

[2] 3GPP TR 38.913, V14.3.0, 3GPP TR 38.913, V14.3.0 (2017), Study on scenarios and
requirements for next generation access technologies..

[3] 3GPP TS 38.401 V0.2.0, 3GPP TS 38.401 V0.2.0 (2017), 5G;NG-RAN; Architecture description..

[4] OBSAI, Open Base Station Architecture Initiative (OBSAI), BTS system reference document,
Version 2.0, 2006..

[5] CPRI, CPRI Specification V7.0 (2015-10-09)..

[6] Doetsch, U. Doetsch, et al., Quantitative analysis of split base station processing and
determination of advantageous architecture for LTE, Bell Labs Technical Journal 18(1), 105–128
(2013)..

[7] XRAN, XRAN-FH.CUS.0-v2.00 (2018), Control, User and Synchronization Plane Specification..

[8] eCPRI, eCPRI Specification, Requirements on Transport Network, V1.2 (2018 06 25)..

[9] SCF, Small Cell Forum, Small Cell Virtualization Functional Splits and Use Cases, document
159.07.02 (2016-01-13)..

[10] ITU-T G.8300, Recommendation ITU-T G.8300, Characteristics of transport network to support
IMT-2020/5G, 2020.

[11] ITU-T G.805, Recommendation ITU-T G.805 (2000), Generic functional architecture of transport
networks.

[12] 3GPP TR 38.801 V2.0.0 (R14), 3GPP TR 38.801 V2.0.0 (R14) (2017), Technical Specification
Group Radio Access Network; Study on New Radio Access Technology; Radio Access
Architecture and Interfaces..

[13] ITU-T G series Supplement 66, Supplement 66 to ITU-T G series Recommendation:,5G Wireless
fronthaul requirements in a PON context, 2019.

[14] ITU-R M.2083, Recommendation ITU-R M.2083, IMT Vision-Framework and overall objectives
of the future development of IMT for 2020 and beyond, 2015.

[15] ITU-T G.8013, Recommendation ITU-T G.8013/Y.1731, Operations, administration and

maintenance (OAM) functions and mechanism for Ethernet based networks, 2015.

[16] 3GPP TR 38.104, 3GPP TR 38.104 NR, “Base Station (BS) radio transmission and reception”.

[17] ITU-T Y.3112, ITU-T Y.3112, Framework for the support of network slicing in the IMT-2020
network, 2018.

52
[18] IEEP1914, IEEE P1914.1/D1.0 (2018), Draft Standard for Packet-based Fronthaul Transport
Networks..

[19] I.-T. G.8275/Y.1369, Recommendation ITU-T G.8275/Y.1369( 2017),Architecture and

requirements for packet-based.

[20] ITU-T G.8271.1, Recommendation ITU-T G.8271.1, Network limits for synchronisation in packet
networks, 2018.

[21] ITU-T G.8273.2, ITU-T G.8273.2 : Timing characteristics of telecom boundary clocks and
telecom time slave clocks, 2020.

[22] ITU-T G.8275.1, ITU-T G.8275.1 : Precision time protocol telecom profile for phase/time
synchronization with full timing support from the network, 2020.

[23] ITU-T G.808.1, ITU-T G.808.1 : Generic protection switching - Linear trail and subnetwork
protection, 2014.

[24] ITU-T G.808.2, ITU-T G.808.2 : Generic protection switching - Ring protection, 2019.

[25] ITU-T G.987.2, Recommendation ITU-T G.987.2 10-Gigabit-capable passive optical networks
(XGPON): Physical media dependent (PMD) layer specification, 2016.

[26] ITU-T G.9807.1, Recommendation ITU-T G.9807.1, 10Gigabit-capable symmetric passive optical
networks (XGSPON), 2017.

[27] ITU-T G.989.2, Recommendation ITU-T G.989.2, 40-Gigabit-capable passive optical network
(NG-PON2): Physical media depedent (PMD) Layer specification, 2019.

[28] ITU-T G.984.1, ITU-T G.984.1,Gigabit-capable Passive Optical Networks (GPON): General
characteristics, 2008.

[29] NGMN2, NGMN Alliance (2011), Guidelines for LTE Backhaul Traffic Estimation, July..

[30] Lee, H. H. Lee et al. (2016), Real-time demonstration of QoS guaranteed 25 Gb/s PON
prototype with Ethernet-PON MAC/PHY and cost-effective APD receivers for 100-Gb/s access
networks, Optics Express, vol. 24, No. 13..

[31] Tashiro, T. Tashiro, et al. (2014), A novel DBA scheme for TDM-PON based mobile fronthaul,
OFC paper Tu3F.3..

[32] Pfeiffer, Pfeiffer, T. Next Generation Mobile Fronthaul and Midhaul Architectures. J. Opt.
Commun. Netw. 2015, 7..

[33] Huwai, 5G-XHaul, D2.3. Architecture of Optical/Wireless Backhaul and Fronthaul and
Evaluation. 2017.

[34] Miyamoto, Miyamoto, K.; Kuwano, S.; Terada, J.; Otaka, A. Performance Evaluation of Mobile
Fronthaul Optical Bandwidth Reduction and Wireless Transmission in Split-PHY Processing
Architecture; IEEE: Anaheim, CA, USA, 2016..

53
[35] Z. Zakrzewski, “D-RoF and A-RoF Interface in an all-Optical fronthaul of 5G Mobile Sytems,”
Applied Sciences, 2019.

[36] 3GPP TS 36.213 V14.5.0, 3GPP TS 36.213 V14.5.0 (2017), 3rd Generation Partnership Project;
Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio
Access (E-UTRA); Physical layer procedures..

[37] 3GPP TS 38.214, 3GPP TS 38.214 V15.0.0 (2017), Physical layer procedures for data..

[38] ITU-T G.987, Recommendation ITU-T G.987, 10-Gigabit-capable passive optical network (XG-
PON) systema: Definitions, abbreviations and acronyms, 2012.

[39] ITU-T G.8271, Recommendation ITU-T G.8271, Time and phase synchronisation aspects of
telecommunication networks, 2018.

[40] 3GPP TS 22.261, V16.1.0 , 3GPP TS 22.261, V16.1.0 (2018), 5G; Service requirements for next
generation new services and markets..

[41] 3GPP R3-161813, 3GPP R3-161813, Transport requirement for CU&DU functional splits
options, CMCC..

[42] A. Babkin, A. Babkin et al. (2013), LTE Network Throughput Estimation, Internet of Things and
its Enablers (INTHITEN 2013), pp. 95-104, June..

[43] P. Chanclou, P. Chanclou (2017), How does passive optical network tackle radio access network
evolution? pp. 1030-1040, v9 (11), JOCN, Nov..

[44] NGMN, NGMN Alliance (2017), 5G End-to-End Architecture Framework, v0.6.5, May.

[45] Tayq, Z. Tayq et al. (2017), Real Time Demonstration of the Transport of Ethernet Fronthaul
based on vRAN in Optical Access Networks, Th3A.2, OFC..

54