intelligent Converged network consolIdating Radio and ... · LC Lucent Connector . LTE Long Term Evolution . LAN Local Area Network . MAC Media Access Control . MAN Metro Area Network

iCIRRUS Contract No. 644526 1 Jan 2015 – 31 Dec 2017

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 644526

intelligent Converged network consolIdating Radio and optical access aRound USer equipment

DELIVERABLE: D3.2

Preliminary Fronthaul Architecture Proposal

Contract number: 644526 Project acronym: iCIRRUS Project title: Intelligent converged network consolidating radio and optical access

around user equipment Project duration: 1 January 2015 – 31 December 2017 Coordinator: Nathan Gomes, University of Kent, Canterbury, UK

Deliverable Number: D3.2 Type: Report Dissemination level Public Date submitted:

Editors: Luz Fernandez del Rosal (HHI) Authors / contributors (contributing partners)

Luz Fernandez del Rosal, Volker Jungnickel (HHI), Daniel Muench, Helmut Griesser (ADVA), Philippos Assimakopoulos, Nathan Gomes, Yuan Kai (UniKent), Howard Thomas (VIAVI/JDSU), Mike Parker, Chathura Magurawalage, Kezhi Wang (UEssex), Philippe Chanclou, Daniel Philip Venmani (Orange)

Internal reviewers Philippe Chanclou (Orange), Ping-Heng Kuo (IDCC), Nathan Gomes (UniKent)

Contract No: 644526 iCIRRUS 1 Jan 2015 – 31 Dec 2017

Page 2 of 110


Document history

0.0 Document creation 25/04/2016 0.1 First contribution from Orange

(section 5), ADVA (section 1, 3 and 4) and HHI (section 1, 3 and 4) merged

18/05/2016

0.2 Added: internal reviewers, requirements, mobile cloud networking, low-cost high-speed transmission section

25/05/2016

0.3 Viavi (5.3) and Kent (3.1.1, 3.1.2, 4.1.2, 4.3.1) inputs added, already solved comments deleted, comments from Orange processed, introductions to section 3 and 4 added

07/06/2016

0.4 Abstract, executive summary and Kent input (1.1, 1.4, 4.1.1 and 4.3.1) added, latency variation results moved from timing and synchronization (4.3) to time-sensitive switching/aggregation (4.4), contribution from Orange placed as introduction to section 5 moved to a new created section 5.1, new introduction to section 5 added

10/06/2016

0.5 Inputs from Kent (3.2.2) and Essex (1.5 and 5.5) merged, solved comments deleted

10/06/2016

0.6 Inputs from Kent (section 3) and Orange (section 2) merged, conclusions added, structure section 4 changed.

13/06/2016

0.7 References not referred deleted, introduction of PDCP-RLC split in section 1.3 and 2, introduction to 4.4 added,

14/06/2016

0.8 Index of terms added, major comment/changes cleaned

15/06/2016

0.9 Document structure overview added as introduction in section 1. Most open points/comments solved.

16/06/2016

0.91 Version for internal review 17/06/2016


Page 3 of 110


0.92 Internally reviewed 24/06/2016 0.93 Internal reviewers comments

processed 29/06/2016

1.0 Final version 01/07/2016


Page 4 of 110


Abstract

This deliverable describes a preliminary architecture for the iCIRRUS mobile fronthaul for future radio access networks (RANs). The new approach is based mainly on the introduction of Ethernet as a transport protocol and on a modification in the functional split between Digital Unit (DU) and Remote Unit (RU). The key enablers for the realization of the iCIRRUS fronthaul are assessed with special attention to the required mechanisms that can guarantee an accurate and reliable synchronisation over a packet switched network. An overview of current contributions to the definition of mobile fronthaul requirements is presented and a preliminary set of key performance indicators (KPIs) is established in order to validate the proposed concepts and mechanisms. Finally, initial feasibility findings are presented and discussed.


Page 5 of 110


Executive Summary

In order to support the demands of future radio access networks, a rethink of mobile fronthaul is required. A mobile fronthaul arises due to the physical separation of the functions of a base station between centralised digital unit (DU) and remote unit (RU). The main benefits of greater network efficiency, flexibility and scalability derive from the centralisation of DUs to common locations, the introduction of Ethernet as a transport protocol and the redistribution of the functionalities between DU and RU, shifting more processing capabilities to the RU replacing current fronthaul implementations (e.g. Common Public Radio Interface (CPRI)) with an evolved fronthaul that enables statistical multiplexing gains. The implementation of device-to-device (D2D) communications as well as new technologies such as mobile cloud networking will also have a direct impact on the transport over this new fronthaul.

The mobile fronthaul interface is an evolution of a hidden and, in many cases, proprietary interface inside the base station. This hidden interface has been, until recently, not formally addressed in most current mobile network performance standards. Therefore, the definition of any requirement for this interface becomes challenging. However, this discussion is gaining attention from standards bodies and interest groups and thus the first KPIs are being established.

The iCIRRUS fronthaul comprises data streams with different performance requirements including synchronization (e.g. IEEE 1588 precision time protocol (PTP)), legacy fronthaul (e.g. CPRI), evolved fronthaul user data, fronthaul control data (e.g. if cooperative multipoint (CoMP) is implemented), and potentially backhaul traffic thanks to the structural convergence enabled by Ethernet. In order to realize this fronthaul several enablers, namely functions and mechanisms, are required.

First, at both ends of the fronthaul interface, a convergence layer is required to interface the different kinds of traffic with the Ethernet layer. This convergence layer must perform the required mapping or encapsulation into Ethernet frames as is currently being standardised for CPRI.

Second, native Ethernet presents some weaknesses in a mobile fronthaul, notably the lack of inherent support for synchronization (timing is of vital importance in the operation of a modern radio network) and latency (delay). Both of these limitations have already been addressed for other applications, including mobile backhaul. However, the more stringent requirements for fronthaul still present challenges. The combination of Synchronous Ethernet (SyncE) with packet-based synchronization approaches such as PTP can deliver accurate timing and synchronization over a packet switched network, whereas time-sensitive networking, e.g. with queuing and forwarding or registration and reservation, offers methods to reduce latency and latency variations (packet delay variations (PDV) or packet delay asymmetries), e.g. to provide a reliable synchronization.

Once the key technological enablers of the evolved fronthaul have been resolved, the greatest challenge before iCIRRUS is the validation of the proposed architecture. Initial analyses indicate that most KPIs are feasible within the iCIRRUS architecture and that the challenges will reside, as initially expected, in meeting timing and synchronization requirements. More advanced demonstration scenarios are needed to completely verify that the proposed architecture can meet the demanding fronthaul requirements.


Page 6 of 110


Index of terms

ADC Analogue to Digital Converter

APTS Assisted Partial Timing Support

ATM Asynchronous Transfer Mode

BBU Baseband Unit

BER Bit Error Rate

BF Basic Frame

BTS Base Station

BW BandWidth

CDR Clock Data Recovery

CFO Carrier Frequency Offset

CPRI Common Public Radio Interface

C&M Control and Management

CRC Cyclic Redundancy Check

C&M Control and Management

C-RAN Cloud Radio Access Network

CSI Channel State Information

CP Cyclic Prefix

CCDF Complementary cumulative distribution function

CO Central Office

CoMP Coordinated MultiPoint

CQF Cyclic Queuing and Forwarding

D2D Device-to-Device

D2I Device-to-Infrastructure

DAC Digital to Analogue Converter

DD Direct Detection


Page 7 of 110


DL Downlink

DMRS Demodulation Reference Signal

DMT Discrete Multitone

DSP Digital Signal Processing

DU Digital Unit

FCS Frame Check Sequence

FEC Forward Error Correction

FFT Fast Fourier Transform

FIFO First In, First-Out

FLR Frame Loss Rate

FPGA Field Programmable Gate Array

FQTSS Forwarding and Queuing Enhancements for Time-Sensitive Streams

FRP Frame Result Packet

FTTx Fibre To The x

3GPP 3rd Generation Partnership Project

GNSS Global Navigation Satellite System

GPS Global Positioning System

GPON Gigabit Passive Optical Network

HARQ Hybrid Automatic Repeat Request

HetNet Heterogeneous Network

ID Identifier

IDFT Inverse Discrete Fourier Transform

IM Intensity Modulation

IF Intermediate Frequency

IFFT Inverse Fast Fourier Transform

IMT International Mobile Telecommunications


Page 8 of 110


ITU-T International Telecommunication Union-Telecommunication Standardization Sector

iRRH Intelligent Remote Radio Head

IQ In-phase / Quadrature

IP Internet Protocol

JT Joint Transmission

KPI Key Performance Indicator

LC Lucent Connector

LTE Long Term Evolution

LAN Local Area Network

MAC Media Access Control

MAN Metro Area Network

MB Mobile Cloud

MCS Modulation and Coding index

MEF Metro Ethernet Forum

MIMO Multiple-Input Multiple-Output

NFV Network Function Virtualization

NGFI Next-Generation Fronthaul Interface

NGMN Next Generation Mobile Network

OAI Open Air Interface

OAM Operations, Administration and Management

ODN Optical Distribution Network

OFDM Orthogonal Frequency Division Multiplexing

OLT Optical Line Termination

OMC Operations and Maintenance Center

OSS Operation Support System

OTA Over-The-Air


Page 9 of 110


PAM Pulse Amplitude Modulation

PDSCH Physical Downlink Shared Channel

PDV Packet Delay Variation

PHICH Physical Hybrid-ARQ Indicator Channel

PHY Physical (Layer)

PMA Physical Medium Attachment Sublayer

PMD Physical Medium Dependent Sublayer

PMI Precoding Matrix Indicator

PON Passive Optical Network

POTS Plain Old Telephone Service

PRACH Physical Random Access Channel

PRC Primary Clock

PRE Packet Routing Engine

PLL Phase-Locked Loop

PSFP Per-Stream Filtering and Policing

PtMP Point-to-Multi-Point

PtP Point-To-Point

PTP Precision Time Protocol

PUCCH Physical Uplink Control Channel

PUSCH Physical Downlink Shared Channel

QAM Quadrature Amplitude Modulation

QoE Quality of Experience

QoS Quality of Service

RAN Radio Access Network

RAT Radio Access Technology

RE Radio Equipment


Page 10 of 110


REC Remote Equipment Controller

RF Radio Frequency

RLC Radio Link Control

RoE Radio over Ethernet

RRH Remote Radio Head

RRS Radio Remote System

RRU Remote Radio Unit

RSTD Reference Signal Time Difference

RTT Round Trip Time

RU Remote Unit

Rx Receiver

SDH Synchronous Digital Hierarchy

SDN Software Defined Network

SFO Sampling Frequency Offset

SFP Small Form-factor Pluggable

SISO Single Input, single Output

SLA Service Level Agreement

SN Sequence Number

SON Self Optimising Network

SONET Synchronous Optical Networking

SP Strict Priority

SRAM Static Random-Access Memory

SRS Sounding Reference Signal

SyncE Synchronous Ethernet

TB Transport Block

TDD Time Division Duplex


Page 11 of 110


TDM Time Division Multiplexing

TDMA Time Division Multiplexing Access

TSN Time-Sensitive Networking

TTI Transmission Time Interval

Tx Transmitter

UDP User Datagram Protocol

UE User Equipment

UL Uplink

UTC Coordinated Universal Time

vBBU Virtual Baseband Unit

VLAN Virtual Local Area Network

WDM Wavelength Division Multiplexing

WRR Weight Round Robin


Page 12 of 110


Contents 1. Key concepts in the evolved fronthaul / midhaul ......................................................................... 15

1.1. Architecture overview ........................................................................................................... 15

1.2. Ethernet as convergence layer ............................................................................................. 17

1.2.1. Multiple topologies ....................................................................................................... 17

1.2.2. Ethernet OAM for SLA and SON .................................................................................... 19

1.2.3. Aggregation and different treatment of multiple traffic classes .................................. 20

1.2.4. Agnostic to any functional split ..................................................................................... 20

1.3. Flexible functional split ......................................................................................................... 20

1.4. Device to device communications ........................................................................................ 24

1.4.1. D2D traffic offloading scenarios .................................................................................... 24

1.4.2. Function splitting scenario ............................................................................................ 24

1.5. Mobile cloud networking ...................................................................................................... 25

2. Fronthaul requirements and KPIs ................................................................................................. 27

2.1. Data rates .............................................................................................................................. 27

2.2. Latency .................................................................................................................................. 29

2.3. Frequency accuracy .............................................................................................................. 31

2.4. Phase and timing accuracy .................................................................................................... 32

2.5. Latency imbalance ................................................................................................................ 32

2.6. Bit error rate ......................................................................................................................... 33

2.7. Packet delay variation ........................................................................................................... 34

2.8. Security ................................................................................................................................. 34

2.9. Fronthaul KPIs ....................................................................................................................... 35

3. Architectural building blocks ........................................................................................................ 36

3.1. Ethernet mapping and encapsulation ................................................................................... 36

3.1.1. Legacy Traffic ................................................................................................................ 38

3.1.1.1. Generic IQ mapper .................................................................................................... 40

3.1.1.2. CPRI mapper structure-aware mapper [37] .............................................................. 41

3.1.2. LTE-based functional split traffic ................................................................................... 42

3.1.2.1. Split II mapper ........................................................................................................... 45

3.1.2.2. Split MAC-PHY mapper ............................................................................................. 48

3.1.3. High-Speed functional split traffic ................................................................................ 51

3.2. Timing and synchronization .................................................................................................. 54


Page 13 of 110


3.2.1. Physical layer approach – Synchronous Ethernet ......................................................... 54

3.2.2. Packet-based approach – IEEE 1588 ............................................................................. 55

3.2.3. Packet-based approach – IEEE 802.1AS time synchronization ..................................... 56

3.3. Time sensitive Ethernet switching /aggregation .................................................................. 57

3.3.1. Standards overview ....................................................................................................... 57

3.3.1.1. Queuing and forwarding: IEEE 802.1Qav forwarding and queuing for time-sensitive streams 58

3.3.1.2. Queuing and forwarding: IEEE P802.1Qbv enhancements for scheduled traffic ..... 59

3.3.1.3. Queuing and forwarding: IEEE P802.1Qbu / 802.3br frame pre-emption ................ 61

3.3.1.4. Queuing and forwarding: IEEE P802.1Qch cyclic queuing and forwarding .............. 62

3.3.1.5. Registration and reservation: IEEE 802.1Qat stream reservation protocol .............. 63

3.3.1.6. Registration and reservation: IEEE P802.1Qcc enhanced stream reservation ......... 64

3.3.1.7. Reliability and redundancy: IEEE P802.1Qci per-stream filtering and policing ........ 64

3.3.1.8. Reliability and redundancy: IEEE P802.1CB seamless redundancy ........................... 65

3.3.1.9. Overall system architecture: IEEE P802.1CM mobile fronthaul ............................... 65

3.3.2. Proposal for the evolved fronthaul ............................................................................... 66

4. Feasibility analysis ......................................................................................................................... 68

4.1. Bandwidth and data rate ...................................................................................................... 68

4.1.1. Legacy traffic ................................................................................................................. 68

4.1.2. LTE-based traffic ............................................................................................................ 69

4.1.3. High-speed system-based traffic .................................................................................. 71

4.2. Latency .................................................................................................................................. 74

4.3. Timing and synchronization .................................................................................................. 79

4.4. Timing-sensitive Ethernet switching / aggregation .............................................................. 82

4.4.1. Time-sensitive networking methods ............................................................................. 82

4.4.2. Delay variation measurements ..................................................................................... 83

4.4.2.1. Frame inter-arrival delay ........................................................................................... 83

4.4.2.2. Frame delay variation and fronthaul latency ............................................................ 88

4.4.2.3. Background traffic and its effects on HARQ re-transmissions .................................. 91

5. Further architectural considerations ............................................................................................ 93

5.1. Transmission network ........................................................................................................... 93

5.2. Scalability and adaptability ................................................................................................... 94

5.3. Structural convergence ......................................................................................................... 95


Page 14 of 110


5.4. SLA monitoring and SON concepts ....................................................................................... 96

5.4.1. SLA monitoring for next generation fronthaul .............................................................. 96

5.4.2. SLA monitoring for mobile cloud based components ................................................... 97

5.5. Low-cost high-speed transmission techniques ..................................................................... 97

6. Conclusions ................................................................................................................................. 100

References .......................................................................................................................................... 101

List of figures ....................................................................................................................................... 107

List of tables ........................................................................................................................................ 110


Page 15 of 110


1. Key concepts in the evolved fronthaul / midhaul This deliverable proposes a preliminary architecture for the evolved fronthaul discussed within the iCIRRUS project. It is mainly based on the key concepts addressed in WP3 and enhanced by those discussed in WP4 and these are briefly presented in this section. An overview follows in Section 2, covering the preliminary requirements and KPIs for the mobile fronthaul that will validate the feasibility of the proposed architecture. In order to realize the iCIRRUS fronthaul proposed in this document, different technology enablers have been identified and are described in Section 3. Section 3 focuses on the concepts investigated in WP3, namely the combination of Ethernet with a modification in the functional split between a baseband unit (BBU), or digital unit (DU) and a remote radio head (RRH) or remote unit (RU), sometimes also referred to as remote radio unit (RRU) in this document. Preliminary feasibility analyses have been performed and the corresponding findings and results are discussed in Section 4. Finally, in Section 5, further architectural aspects are considered.

1.1. Architecture overview The iCIRRUS project is based around an intelligent Ethernet-based fronthaul, the intelligence assisting in the provision of services such as network-controlled/-assisted D2D communications and mobile cloud networking at the network edge. The advantages of using Ethernet in the fronthaul have been described in the iCIRRUS deliverables D2.1 [1] and D3.1 [2] and are summarised in Section 1.2. In [1] and [2], it was also described how the fronthaul of future broadband mobile networks needs to evolve in order to avoid the transportation of sampled radio waveforms, which result in fronthaul bit-rates many times higher than user data rates. In fact, a number of new split points or interfaces between central unit and remote unit were identified, and as discussed further in Section 1.3, it was proposed that the split point be flexible to cater for different use case and deployment scenarios. This flexible functional split between central unit and remote unit has led to an overall iCIRRUS architecture as shown in Figure 1.1.


Page 16 of 110


Figure 1.1 iCIRRUS architecture overview

In the upper part of Figure 1.1, sampled radio waveforms are transported in Ethernet frames (this is the IQ Transport fronthaul) over a switched Ethernet network between a Base Station or Baseband Unit (BBU) pool and the remote radio heads (RRHs); other than the insertion of Ethernet switching, this type of fronthaul is similar to that found in current Cloud-Radio Access Networks (C-RANs). In the lower part of Figure 1.1, a next-generation fronthaul interface (NGFI) is used. The split between what is now termed the Radio Cloud Centre (RCC) and the remote aggregation unit (RAU) and remote radio unit (RRU) involves moving some of the mobile network layer 1 (and possibly layer 2) functions to the RAU and/or RRU. In the event of moving all layer 2 functions into the RAU/RRU, this entity effectively becomes a small base station (micro-BTS) which can be controlled from the (macro-) RCC pool. (Note that the connection of small base stations to a macro-site is what is termed “midhaul” by the Metro Ethernet Forum (MEF) [3]). This “midhaul” connection can be made over the switched Ethernet network1. Similarly, the backhaul using Internet Protocol (IP) links can also be connected through the same switching equipment. Figure 1.1 also shows a “legacy” RRH with IQ transport connecting through the same switches as used by the NGFI. Thus, the architecture represents a fully flexible “X-haul”.

1 The term midhaul has been used to refer to transport over different functional splits (as was done in the iCIRRUS proposal). We now reserve this term for the functional split that corresponds to the MEF definition, and use the term next-generation fronthaul to refer to the transport for the new functional spits.


Page 17 of 110


Finally, Figure 1.1 also shows the user equipment (UE) scenarios envisaged in iCIRRUS. The intelligence at the BBU, and now RCC pool, enables the location of cloud processing functions, including the presence of clones for computation and communications offloading, closer to the network edge. The assistance to localization of UEs through the RRUs/RRHs can be used in the D2D discovery, control and signalling processes. The relationships of these aspects to the fronthaul are summarised further in Sections 1.4 and 1.5, but mobile cloud networking and D2D communications are not in themselves a focus of this deliverable report.

1.2. Ethernet as convergence layer The application of Ethernet as a basis for the evolved fronthaul and midhaul comes with following advantages:

• Multiple topologies • Ethernet Operations, Administration and Management (OAM) for Service Level Agreement

(SLA) and Self Optimising Network (SON) • Aggregation and different treatment of multiple traffic classes • Agnostic to any functional split

1.2.1. Multiple topologies One advantage of the Ethernet technology is to enable applications requiring different topologies. Figure 1.2 depicts a point-to-point and a multiple point-to-point (star) topology. An application for this can be seen in a scenario where at a cell an Ethernet switch can work as an aggregator (multiple point-to-point/star) for three RRHs of an example cell. The time constraints are addressable with the time-sensitive networking (TSN) extensions of IEEE 802.1. The aggregator at the cell side is connected via a high-bandwidth point-to-point link with the central office or BBU hotel (point-to-point). Within the central office, another Ethernet switch distributes the high-bandwidth point-to-point link to three BBUs (multiple point-to-point/star). This switch also behaves like a (de)aggregator.


Page 18 of 110


Figure 1.2 Point-to-point and multiple point-to-point (star) topology (aggregator)

Another topology is the tree topology, shown in Figure 1.3, which allows the aggregation of cells and, in addition, the adding and dropping of cells to or from the main trunk connection.

Figure 1.3 Tree topology (add and drop)

A ring topology, as shown in Figure 1.4, is an enabler for redundancy to increase the reliability for a cell connection to the central office.


Page 19 of 110


Figure 1.4 Ring topology (redundancy)

1.2.2. Ethernet OAM for SLA and SON Another advantage of the application of Ethernet is that the available Ethernet mechanisms for OAM, for SLA and for SON can be used as the basis for OAM, SLA, and SON for front- and/or mid-haul. For example, available Ethernet pluggable monitoring probes can be used for components not supporting internal monitoring probes (see Figure 1.5).

Figure 1.5 Ethernet-based OAM with built-in probes or pluggable probes for OAM, SLA, and SON


Page 20 of 110


1.2.3. Aggregation and different treatment of multiple traffic classes Ethernet, and especially Ethernet with TSN extensions (IEEE 802.1 TSN), allows the aggregation of different traffic classes and the different treatment of traffic classes. Ethernet allows up to eight different traffic classes which can each be handled differently by time-sensitive networking mechanisms such as IEEE 802.1Qci per stream filtering and policing or IEEE 802.1Qbv time-aware shaping. In the case of mobile fronthaul, this could be applied for fronthaul timing and synchronization data (e.g. CPRI timing and synchronization data), fronthaul control data (e.g. CPRI control data), fronthaul user data (e.g. CPRI user data), and other traffic (e.g. exchange of data between BBUs and or cells for coordinated multipoint (CoMP) or mobile backhaul traffic) (see Figure 1.6).

Figure 1.6 Aggregation and different treatment of multiple traffic classes

1.2.4. Agnostic to any functional split A further point is that employing Ethernet as the transport layer enables a transparent transport of fronthaul data, independent of where the split point in the signal processing chain between RRH and BBU is performed (see Figure 1.7). In Figure 1.7 and Figure 1.8, it is shown that even different split points for uplink and downlink seem to be possible. For further details regarding the functional split for RRH and BBU see Section 1.3.

Apart from the above-mentioned points, Ethernet is considered as a potentially low cost technology due to its ubiquity.

1.3. Flexible functional split In previous deliverables the advantages and challenges of transmitting intermediate signals over the fronthaul instead of digitized waveforms have been discussed [1], [2]. The transmission of such intermediates signals requires that more processing is moved from the DU to the RU with the aim of reducing the bit-rate and enabling statistical multiplexing gains when aggregated with other traffic over the same Ethernet links. Where exactly this fronthaul interface can be defined is shown in Figure 1.7 for the downlink and in Figure 1.8 for the uplink.


Page 21 of 110


Figure 1.7 Possible split points in the downlink for single-input single-output (SISO), massive multiple-input

multiple-output (MIMO) and CoMP and massive MIMO scenarios

Figure 1.7 shows a simplified block diagram of the signal processing in a 4G system for the downlink. Currently, the physical layer (PHY), in light blue and extending from the forward error correction (FEC) block to the inverse fast Fourier transform (IFFT) and cyclic prefix (CP) addition block, together with the medium access and control (MAC) layer and the higher layers in different shades of green, namely the radio link control (RLC) and packet data convergence protocol (PDCP), are located at the eNodeB, DU or BBU. At the RU or RRH only the digital to analogue conversion and radio functionalities are located.

Three scenarios are depicted in Figure 1.7 depending on the advanced features that are supported, namely, SISO, massive MIMO and CoMP. The different split points are marked as dashed orange lines vertically through the three scenarios. In current fronthaul implementations like CPRI, which transports digitized waveforms, the split is done at the centralized split shown in Figure 1.7 on the right. Recently the idea of moving part of the processing to the RU has gained attention in the research community [4], [5] [6], [7], [8], [9] and [10], where different split options have been discussed, with the main finding being that a split between MAC and PHY in the downlink might be


Page 22 of 110


most appropriate in terms of data rate reduction, and that other split interfaces at higher layers such as between MAC and RLC or between PDCP and RLC layers might be more interesting in terms of latency. The resulting trade-off leads to the understanding that a flexible split point would be the most interesting implementation for 5G, as discussed in [7], [8], [9] and also in [11] for small cell deployment, since the wide range of scenarios and uses cases envisioned by 5G and the associated requirements set on the fronthaul makes it unlikely that one option will be the optimal for all situations.

Nevertheless, and although a completely flexible split might seem the best solution to match the heterogeneous and wide spectrum of uses cases in 5G, this implies on the other hand, several challenges, especially from an implementation point of view. For example, the physical layer processing can benefit from the integration of application-specific silicon at the RU improving both cost and energy efficiency, whereas higher layers, which can be fully implemented in software, can take advantage from centralization through the use of the more powerful computing resources or virtualization. Moreover, in iCIRRUS, we understand that some split points are more beneficial than others when considering the support of advanced techniques like massive MIMO and CoMP, and that is why two split-points are highlighted and considered in the preliminary technical feasibility analysis described in Section 4 in the current deliverable.

In the downlink we proposed to shift the fronthaul interface to the upper-PHY split point. In the SISO case only the transport blocks need to be transmitted between DU and RU at this point, which leads to significantly reduced data rates and a traffic profile that is proportional to the actual data load.

If massive MIMO is supported, multiple antennas are used and the data traffic at the centralized split increases linearly with the number of antennas. However, these antennas are used to form beams partly carrying the same data towards an intended user. That indicates that setting the fronthaul interface in the upper-PHY split point might be beneficial, and so the required beam-forming operation would be shifted to the RU as shown in the second diagram of Figure 1.7. The scheduling information has to include additional information about the assigned beam, which is included in the precoding matrix indicator (PMI) in the LTE standard. If multiple beams are used in parallel to transmit data to multiple users (multi-user MIMO), then the data rate at the upper-PHY interface will be increased compared to the single-user MIMO case. The advantage is that, often, fewer streams are used compared to the number of antennas. This offers an additional degree of freedom for spatial compression compared to the traditional split.

CoMP has also been added to the system in Figure 1.7 on the bottom block diagram where massive MIMO is also supported. It can be observed that, locally, the data from other cells, and the channel state information (CSI) of the user terminals, are made available to be processed jointly with the desired data in the downlink. In this way, the desired signal quality can be improved, essentially by subtracting the interference from other cells. However, we need to take into account that now, besides the scheduled user data, the exchange of data and CSI between cells needs to be supported, which is commonly a task of the X2 interface, also shown in Figure 1.7, over which the base stations are interconnected. Hence the new X2 information exchange becomes a part of the fronthaul transport too. Fortunately, it has been shown in [12] that this information exchange can be reduced if massive MIMO and CoMP are combined in future 5G systems.


Page 23 of 110


Additionally, from a mobile operator perspective, a split at the higher layers, e.g. between PDCP and RLC or RLC and MAC layers, might be of interest. Such backhaul-like traffic might offer a potentially easier and faster deployment, but it is not capable of supporting advanced techniques such a CoMP. This makes the PDCP-RLC split a transition from the transmission of legacy traffic over the fronthaul to the evolved traffic from the functional split proposed previously. Since those splits will be transported over the same infrastructure, the PDCP-RLC split is also considered in the requirement analysis of Section 2.

Figure 1.8 Possible split points in the uplink for SISO, massive MIMO and CoMP scenarios

Figure 1.8 shows a simplified diagram of the signal processing in a 4G system for the uplink. Currently, as for the downlink, the higher layers PDCP, RLC and MAC together with the physical layer are currently located at the DU whereas the analogue to digital conversion and the radio functionalities are placed at the RU.

Three different scenarios are shown in Figure 1.8 for the uplink, as they were for the downlink, depending on the advanced features that are supported, namely, SISO, massive MIMO and CoMP.

It is more difficult to find a good location for the fronthaul interface in the uplink. Note, that it is the symbol decision which is known at the transmitter (but not at the receiver) which causes a large fraction of the possible compression gain in the downlink; this, however, is not available in the uplink. In a SISO configuration, both hard and soft bits after the decoder can be used as an interface for the uplink as shown in Figure 1.8 by setting the fronthaul interface at the upper-PHY split point. In interference-limited scenarios, cooperative signal processing among the base stations can be used


Page 24 of 110


to make better symbol decisions. Therefore, the sampled baseband signals after conversion to the frequency domain, at the lower-PHY split point, is probably the best choice in order to make better symbol decisions in the uplink.

1.4. Device to device communications D2D communication would bring numerous benefits to the current cellular networks including the proximity gain, frequency reuse gain and hopping gain, etc. There are some vital requirements for D2D communication, for instance, the proximity between transmitter and receiver, which will limit the D2D user scenarios. Therefore, assistance from the cellular network is essential to guarantee the quality of service (QoS) for all active users and achieve optimal system performance. However, central control for D2D communication underlay in a C-RAN architecture is quite challenging since the fronthaul delay cannot be neglected in practical system. In this section, first, different D2D traffic offloading scenarios are introduced. Functional splitting scenarios for D2D communication are then discussed.

1.4.1. D2D traffic offloading scenarios D2D communication has been considered as a substitution of conventional cellular communication to reduce the latency and power consumption and improve the system spectrum efficiency as the transmission distance and resources for data transmission are greatly reduced. However, the traffic offloaded by D2D is related to the use scenario as follows:

1. When two users are communicating within a small area, e.g. interactive video gaming or sharing self-created content, D2D communication could be used and both uplink and downlink data traffic would be offloaded from the cellular network.

2. In a dense user scenario where the same data is stored in a number of user equipment and required by other users in a small area, D2D communication could be used and downlink data traffic would be offloaded from the cellular network.

The amount of traffic that can be offloaded from cellular communication to D2D communication are crucially dependent on the traffic pattern and the number of “potential” D2D pairs in different user scenarios.

1.4.2. Function splitting scenario For D2D communication, since the data traffic is offloaded from the C-RAN, the latency of data traffic is significantly reduced. However, latency from the signalling overhead between D2D and infrastructure, especially for D2D resource allocation, becomes the bottleneck of the general service delay. Moreover, the non-negligible fronthaul delay in a C-RAN architecture would further increase the delay. Therefore, L2 function splitting for D2D resource management is introduced, as shown in Figure 1.9.


Page 25 of 110


Figure 1.9 Function block for D2D function splitting

With some functions from MAC and RLC layer moved to RRH, local resource allocation for D2D communication [13] could be performed. The control signalling overhead between BBU Hotel and RRHs is significantly reduced and could be performed in a much longer time scale than instant resource allocation signalling. Therefore, the impact of fronthaul delay on D2D resource management becomes insignificant and can be ignored through system design.

1.5. Mobile cloud networking

Figure 1.10 Mobile cloud networking architecture

With the ever increasing popularity of mobile devices such as smart phones, tablets and hand-held terminals, and the explosion of resource-hungry applications such as high definition video playing, gaming and social interacting, users are expecting to receive much improved experiences than ever before. However, the improvement of the mobile devices’ batteries is not matched with the increase of the attractiveness of the applications. Also, the limited computational resources in the mobile device may not be able to complete the computational resource intensive task in required time.

Therefore, to deal with the above mentioned problem, we propose to have a mobile clone in a mobile cloud co-located with the BBU pool, as shown in Figure 1.10. The mobile clone can be realized by a cloud-based virtual machine, which holds the same software stack, such as operating

L3

OAM

x2

s1

RRC

L2 at BBU hotel

PDCP

RLC

MAC

L2 at RRH

L1 at RRH

RFMAC

RLC

FEC

QAM

FFT

Resource mapping Eth Eth+ +

Eth Eth

Allocated RB and power

+D2D ID

D2D Tx

D2D Rx

CSI measurements

+D2D ID

Allocated spectrum for RRH ID

Number of D2D pairs + RRH ID

BBU HOTEL RRH

Data packets


Page 26 of 110


system, middleware, applications, as its corresponding mobile user. A mobile user with increasing computing demands but limited computing resource can offload tasks to the mobile clone, which will execute the task on the mobile user’s behalf [14, 15].

In this case, the mobile clone is responsible for the execution of the computational intensive task while the BBU is in charge of receiving the request from the mobile user and returning the execution results back to the user via RRHs. We can assume that each mobile user has the computational intensive task A to be executed as follows:

( , , , )A F U D T= (1.1)

where F (cycles) describes the total number of the CPU cycles for this computational task, U (bits) denotes the uplink request that the user equipment sends to the mobile clone through the wireless channel and fronthaul link before task execution, U also includes other necessary user data, D (bits) denotes the downlink response which the mobile clone transmits back to the user equipment, T (seconds) is the time constraint that this task’s completion in order to satisfy the mobile user's QoS requirement.

Then the QoS requirement in application layer can be expressed as

U U D D

F U U D D Tf r v r v+ + + + ≤

(1.2)

where f (cycles/second) is the computation capability of the mobile clone serving the user

equipment, Ur (bits/second) denotes the wireless uplink transmission speed and

Dr (bits/second) describes the wireless downlink data rate, Uv (bits/second) denotes the uplink transmission speed in fibre fronthaul and Dv (bits/second) describes the downlink data rate in fibre fronthaul. Note that

the speed of Ur and

Dr should take both the wireless channel and fronthaul link into consideration. Thus, given the wireless channel condition, we can derive the minimal data speed for the fronthaul of uplink and downlink. This QoS (1.2) should be taken into consideration when designing the fronthaul.


Page 27 of 110


2. Fronthaul requirements and KPIs Recently, much effort has been dedicated to identifying the requirements for 5G networks by industry and the research community. Nevertheless, and since the overall 5G system, and particularly the Radio Access Technology (RAT), are still under discussion, the identification of specific performance requirements is challenging. The METIS Project [16] and its continuation the METIS II project [17], together with the Next Generation Mobile Network (NGMN) Alliance [18] and the IMT-2020 [19] are some of the main promoters of this discussion.

Additional difficulties arise when trying to establish the requirements for the evolved fronthaul from a not yet defined overall 5G system. As already discussed in [1] and [2], one of the main challenges relies in the hidden or proprietary nature of the fronthaul interface in current implementations. Moreover, with Ethernet as the transport protocol proposed in iCIRRUS for the evolved fronthaul, the differences in terminology and performance measurement methods between specifications for packet networks such as [20], on the one hand, and application specific methods, such as [21] from 3GPP mobile specifications, on the other hand, makes a performance comparison between them very challenging. Nevertheless, the increasing interest in 5G systems has brought many actors to contribute to this task, e.g. China Mobile [4], and standardisation activities such as the P1914.1 (standard for packet-based fronthaul transport networks) [22] from the IEEE Next Generation Fronthaul Interface (1914) Working Group, among some of them.

This section aims to define requirements for the evolved fronthaul introduced in Section 1, which will have to support legacy traffic (e.g. CPRI) and the traffic from the split points proposed in Section 1.3, which includes not only the splits discussed within the physical layer but also the higher layer split between PDCP and RLC. An extra grade of complexity in the requirement identification task derives from the variety of traffic being transported by the fronthaul network and the different needs and challenges faced by each one. Hence, the target is to establish a preliminary set of requirements for the different supported traffic flows in order to define performance indicators for analysing the feasibility and evaluating the performance of the proposed fronthaul architecture in Section 4 and later work.

2.1. Data rates The increasing traffic demand has led to a common agreement that in 5G systems 1000 times more traffic volume should be served by the network [17]. One requirement for 5G is the data rate experienced by the user which is measured in bits per second at the application layer. This user-experienced data rate varies from 50 Mbps to 1 Gbps depending on the use case and should be available at least 95% of the time in at least 95% of the locations, including the cell-edge [18]. These demanding requirements on the availability of the data rate indicate that the use of some techniques may be mandatory for 5G. Such is the case of massive MIMO (MIMO currently only uses up to 8x8 antennas in 3GPP release 10 and above, but with massive MIMO that will be extended significantly, e.g. to 64x64 [18]) and cooperative techniques such as CoMP. The impact of these techniques on the fronthaul data rate has been briefly discussed in Section 1.3 for the selection of a split point that leads to a relaxation of some fronthaul requirements. Additionally, the deployment


Page 28 of 110


of small cells will play an important role in 5G systems in order to guarantee the expected coverage and availability, especially in ultra-dense networks. As analysed by the Small Cell Forum in [23], the deployment of small cells is expected to increase in the next years with 40% of the deployed small cells in hyper-dense environments by 2020, with a density of 150 small cells per square kilometre. A preliminary data rate estimation based on a similar scenario to this was performed in [12] and is shown in Figure 2.1. A future 5G heterogeneous network (HetNet) was considered with 100 MHz spectrum LTE-based macro-site, 10 small cells per macro cell, joint transmission (JT) CoMP and 16x16 MIMO.

Figure 2.1 Over-the-air and backhaul traffic vs. the number of small cell [12]

If we compare the backhaul data rates for a 20MHz LTE 2x2 MIMO macro site to the 5G macro site rates as depicted in Figure 2.1, it can be seen how the traffic increases by a factor of approximately 1000. Moreover, the expected backhaul data rates for 5G are estimated as 300 Gbps for the downlink. Considering the evolved fronthaul, where the interface between the DU and the RU is set at the upper-PHY and digitized waveforms are no longer being transported but unmodulated symbols, the expected data rates for the fronthaul are at least comparable to the backhaul data rates; or even higher when the additional control information in the fronthaul is considered, e.g. the new X2 interface indicated in Section 1.3.

The different data rate requirements, depending on the functional split, are illustrated in Table 2.1. The table presents different data rates for an LTE signal for one carrier, one sector, 20MHz RF bandwidth (BW), and 2x2 MIMO [11]:

Table 2.1 Fronthaul data rate requirements depending on modified functional split

Split point Downlink data rate Uplink data rate PDCP-RLC split 150 Mbps 50 Mbps


Page 29 of 110


RLC-MAC split 150 Mbps 50 Mbps MAC-PHY split 150 Mbps 50 Mbps Upper PHY split 170 Mbps 452 Mbps Lower PHY split 2 Gbps 2 Gbps CPRI 2.4576 Gbps 2.4576 Gbps

From this discussion, it can be concluded that the evolved fronthaul should be able to support data rates from at least 100 Gbps and up to 400 Gbps. The implementation of such high-speed communications in a low-cost manner is the target of further investigations within iCIRRUS and its achievements will be reported in later deliverables, as addressed in Section 5.5.

2.2. Latency The latency in the evolved fronthaul includes the processing delay at the DU, the latency due to the optical transmission, the processing delay at the RU, when a modified split is considered, and the latency introduced by any switching or aggregation network equipment. For the one-way latency, only the delay for the downlink or the uplink is considered, whereas the round-trip-delay considers both the downlink and uplink delays. In a packet switched network, a packet passes through network equipment on the way from the source to the destination, e.g. routers or switches. Each time a packet is passed to the next piece of equipment, a hop occurs.

Latency remains a critical parameter for the fronthaul with a great impact on radio performance. In current LTE-based systems, the procedures that are most sensitive to latency are the network entry, or physical random access channel (PRACH) procedure, and the hybrid automatic repeat request (HARQ), on the one hand, and the aging of CSI, on the other hand. HARQ manages the retransmission of information and imposes more stringent requirements on the system. It sets a maximum on the overall end to end latency that should not be exceeded in order not to violate the protocol timings. On the other hand, an excess of latency will result in CSI aging. CSI is sent from the UE to the DU for computing the precoding matrix in a massive MIMO and JT CoMP scenario; this information is expected to be updated with a certain periodicity [24] and any additional delay will result in CSI aging effects as studied in [25] or [26].

Latency is being actively addressed by research and standardisation activities. For China Mobile, as addressed in [4], the main latency constraint is imposed by the HARQ protocol. The HARQ is a function allocated in the MAC layer and hence the delay between the MAC layer at the DU or RU and the UE has a direct impact on its performance. China Mobile come to the conclusion that the fronthaul network should support at least 6 hops and the one-way transmission delay should not exceed a maximum of 220 µs in total. The one-way delay includes a maximum optical fibre transmission delay of 100 µs for a maximum transmission length of 20 km (given by the speed of light in optical fibre). Considering 6 hops, the data forwarding time of a piece of transport equipment should be 20 µs per hop. This conclusion agrees with that made by the NGMN Alliance [27] where it is stated that the one-way delay over the fronthaul network should be lower than 250 µs. In [1] the


Page 30 of 110


same values were discussed, where a more stringent round-trip delay requirement of 150 µs is set by RAN providers such as Nokia [28] when cooperative techniques such as CoMP are used.

Also, CPRI cooperation has contributed to the fronthaul requirements discussion in the context of the IEEE 802.1CM time-sensitive networking for fronthaul [29] standardisation. In [30], the requirements for the access points to a TSN network between remote equipment controller (REC) and radio equipment (RE) are discussed. Regarding the latency experienced by the IQ data stream, which includes the latency introduced by the TSN network, less than 100 µs delay is expected end-to-end (or one way), as shown in Figure 2.2. Nevertheless, this requirement does not consider the delay due to processing at the REC (or DU) and RE (or RU).

Figure 2.2 End-to-end fronthaul latency requirement from CPRI cooperation [30]

Similar to the data rates, the latency figures on the fronthaul are a function of the modified functional split. Table 2.2 presents one-way latency values for different split points [11]. We consider that full CoMP features (e.g. inter-site interference mitigation) are possible only for low part splits with low latency, namely MAC-PHY (limit of the segment depending of HARQ), upper PHY, lower PHY and CPRI splits.


Page 31 of 110


Table 2.2 Fronthaul latency requirements depending on the modified functional split

Split point One-way delay (max.) PDCP-RLC 30 ms RLC-MAC 6ms MAC-PHY fully CoMP: 250µs;

400 µs Upper PHY fully CoMP: 250µs

400 µs Lower PHY fully CoMP: 250µs

400 µs CPRI fully CoMP: 250µs

400 µs

From Table 2.2, the latency round-trip delay of 60 ms is taken as reference for the PDCP-RLC traffic. The most stringent requirement values for the round-trip-delay of 440 µs (if CoMP is not implemented) and 150 µs (if CoMP is implemented) in the fronthaul are taken as reference for later feasibility analysis and future performance evaluation. These values will be reviewed in later work, if required.

2.3. Frequency accuracy In practical system implementations, all clocks needed for sampling and up-conversion in the RU are derived from the same clock source or reference, namely the same local oscillator. However, this frequency needs to be locked to a common reference. In current fronthaul implementations, at the RU, the clock for frequency generation is locked to the bit clock of the received CPRI signals from which it is recovered. Any imprecision in the CPRI signal will be transferred to the clocks generated from this reference and introduce carrier frequency offset (CFO) and sampling frequency offset (SFO).

The frequency accuracy in the air interfaces must meet 0.05 ppm [21] (measurement time 1 ms) in current radio systems. Additional accuracy constraints can be directly imposed on the local oscillator, as shown in [31], where the effects of synchronization impairments is analysed in a CoMP scenario. They conclude that a free-running oscillator accuracy of +/- 0.1 ppb is needed to guarantee the system performance after the precoder (beamforming) update, which shall occur every 10 ms. Additionally, all cooperative base stations must be locked to the same reference, which in an Ethernet-based system will be distributed over the network through SyncE or eventually with the support of Global Navigation Satellite System (GNSS) as discussed in Sections 3.2.1 and 4.3, respectively. For 4G systems, the CPRI specification [32] states that the maximum impact of jitter from CPRI on the frequency accuracy of the RU should be less than +/- 2 ppb per link or hop. As already indicated in [2], since the principles involved in the operation of SyncE are no different to those in CPRI, there is, in theory, no impediment in achieving similar or better performance. However, some parameters such as the number of hops between primary reference clock and application have to be considered for compliance at the air interface. For CPRI, as collected in [30], it


Page 32 of 110


is still an open issue whether, in order to meet the frequency accuracy at the air interface, the existing telecom profiles are sufficient, or whether additional frequency accuracy requirements must be met by the network.

The constraint to the air interface has led China Mobile to provisionally set the frequency accuracy for the fronthaul as +/- 4.6 ppm as described in [4]. Nevertheless, the most stringent requirement value of +/- 2 ppb is taken as a reference for later feasibility analysis and future performance evaluation, and will be reviewed in later work, if required.

2.4. Phase and timing accuracy Phase synchronization means equipment (RU and/or REC) A and B receive a common reference signal and significant instants must be aligned in time within a given accuracy and stability, but are not necessarily traceable to a common time scale (for example, Coordinated Universal Time (UTC)). And time synchronization means equipment (RU and/or REC) A and B receive a common reference signal and significant instants are aligned in time, as well as being in-phase with each other, with a known traceable reference clock (e.g. UTC, same reference for leap seconds, etc.). Here a slave clock updates its internal clock’s time accordingly to maintain tight synchronization with the master clock. Thus end equipment (RU and/or REC) is synchronized in time and phase. Furthermore, when adjacent RUs and/or RECs are accurately synchronized by the same master clock in phase and time, the time error between adjacent RUs and/or RECs must be strictly low. On the other hand, a slave clock therefore could temporally lead or lag the master clock up to a specified value, and thus we talk about a timing error in the slave that can be up to +/- this specified value. In [21] it is specified that for MIMO or TX diversity transmission, the Time Alignment Error (TAE) between base station antenna ports shall not exceed 65 ns, which is the most stringent case. The CPRI specification [32] proposes an accuracy of +/- Ts/2 (Ts is the basic time unit = 1/(15.000 x 2048) ≈ 32.552 ns [33]) which corresponds to +/- 16.276 ns. Recently, CPRI has proposed in [30] some new timing accuracy requirements for the fronthaul as follows: if MIMO and TX diversity is used, a timing error up to +/- 10 ns is required whereas +/-1.36 µs is the maximum timing error required for LTE time division duplex (TDD). The stringent accuracy requirement for the radio interface has led China Mobile to provisionally set the timing accuracy for the fronthaul at +/- 30 ns as described in [4].

In [2] it was discussed that commercial networks are beginning to offer +/- 1 µs SLA’s with respect to UTC and that some planned mobile network features already suggest targets of 0.5 µs or even 100 ns. These are already very challenging values, but not as stringent as the requirements set by NGFI, that has been taken as a preliminary reference for the modified split traffic, or the proposed requirement from CPRI, also taken as a reference. These values will be reviewed in later work, if required.

2.5. Latency imbalance Latency imbalances between the downlink and the uplink in the fronthaul have a direct impact on the performance of PTP which is crucial for delivering timing and phase synchronization over a


Page 33 of 110


packet switched network. A latency imbalance or asymmetry can be introduced either by active equipment (DU, RU or switching / aggregation equipment) or the transmission medium (i.e. different optical cable lengths, use of different wavelengths), and any delay asymmetry in the fronthaul will directly introduce a phase error of the same magnitude unless corrected. Different delays due to processing at the DU and RU can be corrected through buffering, at the expense of increasing the overall latency. In the case of network equipment, if the equipment is PTP aware (on-path support), any potential asymmetry introduced by the equipment can be corrected. Regarding the optical transport, the different propagation speed for different wavelength is a predictable delay and can be corrected. In some critical applications to avoid different fibre lengths, the use of Single Fibre Working is a trend.

One interesting development in this area is so called Assisted Partial Timing Support (APTS) which uses PTP in conjunction with GNSS timing distribution, improving resilience and allowing for automatic asymmetry correction of the PTP path as discussed in Section 4.3. CPRI also assumes that the upstream and downstream delays are equal.

In [1], and in order to set a reference value, it was considered that the fronthaul latency must not affect the UE positioning error (localization) which is based on the time report of the reference signal time difference measurements (RSTD). Thus, in [1], it is concluded that any uncompensated delay difference between up and down-link in the fronthaul network must be below the minimum accuracy of 5 Ts, approximately 163 ns. More stringent requirements are set by RAN vendors, such as Nokia, for CPRI. In [28], the maximum allowable latency imbalance or asymmetry is set to +/- 16 ns. These values of +/- 16 ns for CPRI and +/- 163 ns for the other functional split traffics are taken as a preliminary reference for the feasibility analysis and performance evaluation, and will be reviewed in later work, if required.

2.6. Bit error rate The NGMN alliance sets 10-12 as the maximum allowable BER in the fronthaul [27]. Modern optical networks are reliable with bit error rates (BER) far superior to this regularly achieved.

However, in the evolved fronthaul with Ethernet as the transport protocol, the consequences of errors cannot be ignored since, as discussed in [2], standard Ethernet forwarding behaviour is to discard any frame with an FCS (Frame Check Sequence) error, even when only a single bit error is present. This loss can significantly impact on the radio performance. Nevertheless, in [4], for standard Ethernet behaviour, a packet loss rate of 0 is established for high-priority data packets and 10-7 for non-high priority packets. Similar requirements are proposed by CPRI in [30], where a frame loss rate (FLR) up to 10-7 is also required in the fronthaul for IQ data whereas a more relaxed FLR is set for control and management (C&M) data of up to 10-6. For the backhaul or backhaul-like traffic coming from a PDCP-RLC, split a FLR of 10-6 as reported in [34] could be applied.

The significant impact of standard Ethernet behaviour on the radio performance suggests that FCS should be disabled in a fronthaul network, allowing damaged frames to be forwarded. This is not a standardised behaviour, and is not normally possible, requiring equipment specifically supporting


Page 34 of 110


this feature. However, this behaviour is a necessary side effect of a technique called “cut-through forwarding” which, though not (yet) standardised Ethernet behaviour, is supported on an increasing number of carrier Ethernet devices in latency sensitive applications. Hence, the most stringent values are taken as a preliminary requirement for feasibility analysis and performance evaluation, and will be reviewed in later work, if required, as collected in Section 2.9.

2.7. Packet delay variation The implementation of PTP in the evolved fronthaul for synchronisation will impose some restrictions in the number of hops and the topologies supported by the network. Packet delay variation (PDV) refers to the variation in the arrival time of data packets and may have a direct impact on the synchronization performance of PTP. Methods such as priority implementation might be useful to minimize PDV effects on sensitive or critical traffic as discussed in Section 3.3.

While [35] specifies the fundamental operation of PTP, its application to specific applications and use scenarios is not addressed. It is, however, possible to specify profiles, intended to tailor PTP to different operating environments and applications. Profiles may define mandatory, allowed and prohibited PTP options or place restrictions on network topology or technologies. ITU-T and others have already produced a number of profiles for telecommunications applications, e.g. [36], with more in development. For CPRI, as collected in [30], it is still an open issue whether the existing telecom profiles are sufficient to meet the frequency accuracy at the air interface or whether additional PDV requirements must be met by the network.

2.8. Security As discussed in [2] the potential vulnerabilities which may result from the deployment of an Ethernet-based fronthaul (e.g. device authentication), in a converged network topology, and new security challenges that may be presented by the wider C-RAN architectures considered in iCIRRUS [1] need to be analysed. In particular, the iCIRRUS fronthaul architecture will provide a new service delivery model with open multiple service agreements and therefore new security threats will evolve and present themselves as issues to be solved. These threats derive, e.g., from the virtualization of the network architecture, the open access in a heterogeneous network, or the implementation of device-to-device communications. Additionally, the evolved fronthaul exposes control and data flows other than those in current fronthaul implementations, for example, as discussed in Section 1.3 for a cooperative (CoMP) scenario, which may become significantly vulnerable. For CPRI [30], security in the fronthaul is still an open issue where the potential security restrictions that may prevent users to ensure data protection and privacy have to be further studied. All of these issues will be addressed more in detail in later deliverables.


Page 35 of 110


2.9. Fronthaul KPIs Table 2.3 collects the values discussed in the previous sections for the different fronthaul requirements. Four different kinds of traffic can be distinguished for the traffic that the proposed fronthaul should support: legacy traffic (e.g. CPRI), modified split for the non-cooperative scenario (upper-PHY split in the downlink and in the uplink), modified split for cooperative scenarios (upper-PHY split in the downlink and lower-PHY split in the uplink), and higher layer split (PDCP-RLC split).

Table 2.3 Fronthaul requirements and KPIs

Different kind of traffics supported by the evolved fronthaul

Fronthaul Requirements

Legacy traffic (CPRI)

upper-PHY split in down and

uplink (no CoMP)

upper-PHY split in downlink

lower-PHY split in uplink (CoMP)

PDCP-RLC split

Data rate 100 to 400 Gbps Max. latency (round-trip-delay)

150 µs (CoMP) 440 µs (no CoMP) 440 µs 150 µs 60 ms

Min. frequency accuracy +/- 2 ppb (per hop) +/- 2 ppb

(per hop) +/- 2 ppb (per hop)

+/- 2 ppb (per hop)

Min. phase and timing accuracy

+/- 10 ns (MIMO & TX diversity)

+/-1.36 µs (LTE TDD) +/- 30 ns +/- 30 ns not already

defined

Max. latency imbalance +/- 16 ns +/- 163 ns +/- 163 ns not already

defined Max. error 10-12 BER 10-6 FLR


Page 36 of 110


3. Architectural building blocks The term architectural building blocks refers to the key components and mechanisms which will make possible the fronthaul architecture as introduced in Section 1, enabling its advantages and leading, at the same time, to the challenges in making this evolved fronthaul proposal meet the requirements discussed in Section 2.

3.1. Ethernet mapping and encapsulation The first enablers for the evolved fronthaul described in Section 1 are the Ethernet encapsulation or mapping functions which will allow the use of Ethernet as a convergence layer of the different traffic that must be supported. The supported traffic types, and the corresponding required Ethernet mappers, are: legacy traffic (either CPRI or, in general, any generic transport of digitized waveforms as described in Section 3.1.1), the transport of information from a modified functional split (either based on current 4G LTE as described in Section 3.1.2 or based on a high-speed custom system with characteristics closer to those of future 5G systems as described in Section 3.1.3). In any case, at both DU and RU, a convergence layer is needed (interfacing the physical layer with the Ethernet layers). Here, it is assumed that the convergence layer is based on the radio over Ethernet (RoE) work [37]. Thus, the RoE mapper will encapsulate the radio samples into a RoE packet and then the Ethernet process will encapsulate the RoE packet.

Under centralised processing or functional split processing, the division of traffic is based on flows for different antennas (or, possibly, codewords, if the split point is before the layer mapper) and packet types (pkt_types) for different streams (control and data). Depending on the choice of split point, different advantages/disadvantages can be realised. A reference scenario for different splitting options is shown in Figure 3.1. Different mappers will be used to encapsulate data generated from different functional splits. Each mapper will define the necessary data and control processes required to transport the encapsulated system.

Mapper selection is based on current traffic conditions and whether CoMP is employed in the uplink. Mapper selection can be carried out “in-band”, through Virtual Local Area Network (VLAN) IDs or through the convergence layer encapsulation (e.g. pkt_type), or “out-of-band” through an SDN controller. Additionally, all options can be used concurrently for increased redundancy.


Page 37 of 110


Figure 3.1 Different split point options and division of data among packet types and flows

For the mappers that will be presented in Sections 3.1.1 and 3.1.2, a container includes extracted data from the system that is being encapsulated for one flow (e.g. one antenna carrier, one codeword, etc.) while the number of segments implicitly defines the amount of data collected before starting to construct one or more packets (see Figure 3.4 for an example for packet contruction and [38] for more information). For each mapper a number of parameters are used which are tabulated with the relevant definitions in the following sections, and these are used to assign values to the different mapper primitives. A list of some of the primitives used in RoE is shown in Table 3.1. It is assumed that the mappers can generate variable length payloads. The RoE demapper needs to be aware of the payload size it is transporting and to this extent RoE standardisation is considering the addition of a “length” field in the RoE header [38]. Please note that the mapper primitives and parameters are highlighted in bold when defined in figures and tables, as well as the first time they are referred to in the text.


Page 38 of 110


Table 3.1 List of primitives used by the mappers in RoE [37]

Primitive Definition Comment RoE.numContainer Number of containers Each container includes

extracted data from the system that is being

encapsulated for one flow (one antenna or one carrier)

RoE.lenContainer Length of each container RoE.container.lenSkip Number of unused bits. Affective only when

storing/extracting data to/from some other source

than RoE payload. When containers are stored/read

into/from the payload, these unused bits are not stored or

read. RoE.container[0].flow_id Identifies to which flow or

group of flows the segment belongs to.

May equal to a single antenna carrier (AxC, IQ data flow for

one physical antenna, definition from CPRI) that is

placed into separate packets/flows or may equal to

a list of AxCs. RoE.numSegment Number of segments Implicitly defines the amount

of data collected before starting to construct one or

more packets RoE.lenSegment Length of each segment

RoE.segment.lenSkip Bit field preceding each container

Describes a bit field that precedes all containers within

a segment SeqNumMin Minimum value of Sequence

number

SeqNumMax Maximum value of sequence number

SeqNumIncrement Value by which sequence number gets incremented

3.1.1. Legacy Traffic A detailed view of the BBU processing is shown in Figure 3.2 for the legacy fronthaul. The SDN-type controller entity is used to for a number of purposes, including traffic steering and switching protection. But it is also used to adjust “gating” windows in the switch scheduler (for example to obtain un-contended windows for particular traffic (e.g. PTP)). Additionally, a SON entity can be used to obtain long-term performance measures and can then instruct the SDN controller to adapt the fronthaul operation, based on those measures. Both entities obtain inputs from a probing system


Page 39 of 110


implemented through the use of “smart Small Form-factor Pluggable (SFP)” Ethernet probes. The different data flows are “switched” to the destination through VLAN IDs while individual flow IDs within these VLANs are used to address the different antennas. Also shown in Figure 3.2 are the proportional data rates of the C&M, time and data planes. Two mappers will be presented in this section that can be used to map CPRI or generic IQ data flows.

Figure 3.2 BBU side processing. Example for 2x2 MIMO. The clock frequencies shown are examples based on 4G data rates. CDR= Clock and data recovery unit


Page 40 of 110


3.1.1.1. Generic IQ mapper

Table 3.2 Parameters used for the generic IQ mapper

Parameter Definition Comments IFFF_length Length of IFFT 2048 for 20 MHz, 1024 for 10

MHz, etc S Sample size of In-phase and

quandrature (IQ) components

Num_MIMO Number of MIMO antennas

Each packet carries the data for one MIMO antenna and for one carrier. Each container carries a number of time domain IQ samples from each LTE slice (each OFDM symbol) while the number of segments is based on whether a whole LTE slice (one OFDM symbol) or part of an LTE slice is inserted into each container. Specifically, the mapper extracts No_IQ_Samples_per_container LTE IQ samples from a generic IQ sampling block for each antenna port and each aggregated carrier. Each IQ sample has a length of IQ_sample_length bits. The IQ samples are inserted into the payload section of the RoE packet with a maximum payload size of Max_RoE_payload_size sequentially that is: I sample first then Q sample and so forth. Padding bits are used if necessary to get full octets into the payload field. The sequence number wraps around every 10 ms (one radio frame). An example of RoE packet creation using this mapper is shown in Figure 3.4.

Figure 3.3 Primitives used for the generic IQ mapper (based on RoE definitions)

Note: Other ratios of i and k that give an integer number of samples are possible depending on the value of IFFT_length.

No_IQ_Samples_per_container=IFFT_length/i, for i power of 2 (i.e. ≤IFFT_length)

IQ_sample_length=2 x s //two times sample length for I and Q

Max_RoE_payload_size ≥ (No_IQ_samples_per_container x IQ_sample_length) x k

RoE.numContainer= Num_MIMO

RoE.lenContainer= Num_IQ_samples_per_Container x IQ_sample_length

RoE.numSegment= k, for k ≤ i and k power of 2 // For k=i the whole radio “slice” (OFDM symbol) is inserted into the packet

seqNumMin=1

seqNumMax= (i/k)x140 //Sequence wraps around every 10 ms frame

seqNumIncrement=1


Page 41 of 110


Figure 3.4 RoE packet construction for generic IQ transportation. Example is for Num_MIMO=2

3.1.1.2. CPRI mapper structure-aware mapper [37] Figure 3.5 shows the creation of RoE packets using the CPRI mapper. For this mapper, each container includes IQ data bytes for one antenna carrier while the number of segments implicitly defines the amount of data collected before starting to construct one or more packets. For more information on CPRI operation see [32].

Figure 3.5 Construction of RoE packet using containers and segments based on the example for the CPRI

mapper in IEEE 1904.3 draft [37].Note that the containers should probably be interleaved i.e. cont.0, cont.1, cont.2, cont.3 etc

For this mapper, each packet contains: 8 (segments) x 8 (containers) x 30 (bits per IQ sample) = 1920 bits = 64 (IQ samples) x 2 (IQ) x 15 (bpS) = 8 (basic frames (BF)) x 15 (words) x 32/2 bits.

Each segment contains the data from 1 BF (480 bits).

The sequence number wraps around every seqNumMaximum which corresponds to the full transmission of a 10 ms frame in CPRI (10 ms = 150 hyperframes x 256 BFs x Tc, where Tc is the transmission time of one CPRI BF and is equal to a UMTS chip time (= 1/3.84MHz)).


Page 42 of 110


The mapper will send CPRI control words (these are the 32 skipped bits from the example above (note that the RoE packets in Figure 3.5 are carrying data from 15 words only) within the time of a CPRI hyperframe (= 256 x Tc = 66.7 µs), i.e. a hyperframe worth of control words. This may require more than one packet to be sent based on packet size considerations.

The “control process” will extract the control words for the CPRI fast C&M channel and create an appropriate Ethernet packet out of them. Control words for the CPRI fast C&M channel are sent / received as native Ethernet traffic.

3.1.2. LTE-based functional split traffic A detailed view of the BBU processing is shown in Figure 3.6 for the evolved fronthaul. Compared to Figure 3.2, the sampling block has been removed while two mappers have been included for the two split options. The SDN controller (informed by the probing system and SON) is used to “switch” between the two possible splits by selecting the relevant functionality in the LTE processing block and the relevant mapping functionality. The control process is more important now (compared to the centralised approach of Figure 3.2) as it will be used to transport LTE MAC primitives and other control-plane information of the transported signals. The different types of data flows are separated by packet type. Note that with regards to the proportional data rates shown, the control-plane and user-plane traffic streams of the transported system are included as part of the data-plane rate.


Page 43 of 110


Figure 3.6 DU side processing. Example of 2x2 MIMO

Proper synchronisation, in terms of buffer play-out in the receiving nodes, of the different data streams in the evolved fronthaul will be very important. The use of sequence numbers for synchronisation is illustrated in Figure 3.7 for the case of a MAC-PHY split. The different steps are described as follows:

1. Control primitives are received from the ETH interface once every 1 ms. 2. The FIFO buffer with size equal to the maximum possible RoE control packet size is written in

(Buffer size=max RoE control packet size). The example here shows a buffer of size 1500 bytes, which is initially empty, and then is filled with 1496 bytes.

3. Control primitives are extracted. The number of user allocations for current transmission time interval (TTI) is read.

4. Info from (3) is used to generate the necessary number of FIFOs in the RoE interface (and possibly the size of each FIFO (alternatively size of FIFOs is set by default to the maximum allowed RoE data packet size).

5. Data is “played out” once all data queues from the current TTI have received data (unless excessive delays are introduced, see below for more information).


Page 44 of 110


Note that this is an “event-based” buffer design. Buffers are read out when a certain event occurs. There may be cases where a packet has been dropped or has been extensively delayed in transit within the Ethernet network. For these cases and to ensure that there are no excessive delays from buffering, a playout timer will be used that will set the maximum allowed time that data can stay in the buffers. Once the timer expires, the data will be played out from the buffers even if all transport blocks for a certain TTI have not yet been received. Proper logging/monitoring of the rate of occurrence of this event will be important so that actions can be taken to mitigate the causes (for example by employing traffic steering/load balancing in the Ethernet interfaces within the fronthaul network).

Figure 3.7 An “event-based” buffer design for syncronising primitive and user-plane buffer “play-out” for a MAC-PHY split

The evolved fronthaul testbed will be based on the open-air interface (OAI) software [39] by adapting and/or adding functionality that is already present within the OAI stack. Figure 3.8 shows the main processes for the fronthaul with split functionality based on OAI. For Split I, MAC primitives are mapped to RoE control packet (control pkt_type) while the codewords are mapped to the RoE


Page 45 of 110


data packet (user-data pkt_type). The RU generator block extracts primitives and passes them on into blocks for PHY channel generation, QAM, layer mapping and resource mapping.

For Split II, MAC primitives are mapped to a RoE control packet (control pkt_type) while the physical downlink shared channel (PDSCH) is mapped to RoE data packets (user-data pkt_type). Primitives are extracted by an RU generator block which generates the PHY channels. Primitives are passed to a resource mapper block for multiplexing of channels into OFDM symbols.

Figure 3.8 The architectural building blocks for the fronthaul with split functionality, using OAI for (a) Split I and (b) Split II

3.1.2.1. Split II mapper Figure 3.9 shows the resulting flows after resource demapping which consist of physical uplink shared channel (PUSCH), physical uplink control channel (PUCCH), sounding reference signal (SRS), demodulation reference signal (DMRS) and PRACH.


Page 46 of 110


Figure 3.9 Uplink process for resource mapper

Table 3.3 Parameters used for the Split II mapper

Parameter Definition Comments Sj Sample size of I and Q

components Index j used to indicate that

this value may be different per sample

Num_MIMO Number of MIMO antennas NRB RBs allocated per user per TTI NRE REs per allocated RB that can

be used for user-plane data

NPUCCH,CR Number of PUCCH control regions

NPUCCH,RE Number of REs within PUCCH control region

Num_user Number of user allocations per TTI

Equal to the number of user-plane FIFO queues

PRACH_period PRACH periodicity 1 ms, 2 ms, 3 ms, 10 ms etc.

Synchronisation with the radio frame timing is achieved through sequence numbers (SN). But the only SN used for this purpose is the one in the control process (carrying the MAC control primitives). The SNs for the data packets are used for inserting user data into the queues at the RU in the correct order (as packets may be received out of order), as shown in Figure 3.7.

UL (data-plane pkt_type 1, PUSCH):

Each packet carries the data for one MIMO antenna. The mapper extracts Num_IQ_Samples_per_Container frequency domain samples from the resource demapper block (PUSCH queues), i.e. each container will be of different length. Each IQ sample has a length of

Resource de-mapping(Uplink)

PUSCH

PUCCH

SRS

DMRS

PRACH


Page 47 of 110


IQ_sample_length bits. The IQ samples are inserted into the payload section of the RoE packet with a max payload size of Max_RoE_payload_size sequentially, that is, I sample first then Q sample etc. Padding bits are used if necessary so that there are integer numbers of octets in the payload field. At a minimum, each packet contains the data for one PUSCH queue.

Figure 3.10 Primitives used for the Split II mapper for the PUSCH (based on RoE definitions)

UL (control pkt_type 1, PRACH):

The control process will create one control RoE packet (control pkt_type 1) containing PRACH IQ samples per PRACH period:

Figure 3.11 Primitives used for the Split II mapper for the PRACH (based on RoE definitions)

Num_IQ_samples_per_Container = NRB x NRE // Total number of REs used for data per PDSCH queue.

IQ_sample_length=2 x Sj //two times sample length for I and Q

Max_RoE_payload_size ≥ 2∑ �∑ SjNum _IQ_samples _per _Container 𝑘𝑘j=1 �𝑘𝑘

1

RoE.numContainers= Num_MIMO

RoE.container[0….Num_MIMO-1].lenContainer= 2∑ SjNum _IQ_samples _per _Containerj=1

RoE.numSegments=k where k|Num_users //Defines the number of PDSCH queues inserted into the payload section of each packet. For K>1 more than one queue worth of samples is inserted in a packet. K divides Num_users.

RoE.container[0…. Num_MIMO -1].flow_id=1,…., Num_MIMO

RoE.segment.flow_ids=1… Num_MIMO

seqNumMin=1

seqNumMax= Num_user // will depend on number of allocations per TTI and will be different every TTI i.e. sequence wraps around every TTI. The sequencing is used to synchronise the equivalent queues at the RU i.e. packet for first queue will have the lowest SN while packet for the last queue will have the highest SN.

seqNumIncrement= k

seqNumMin=1

seqNumMax= Floor([10/ PRACH_period(ms)] //Sequence wraps around every 10 ms frame

seqNumIncrement= PRACH_period


Page 48 of 110


UL (control pkt_type 2, PUCCH):

Each packet carries the data for one MIMO antenna. The mapper extracts Num_control_IQ_Samples_per_Container frequency domain samples from the resource demapper block (PUCCH queues), i.e. each container will be of different length. Each IQ sample has a length of IQ_sample_length bits. The IQ samples are inserted into the payload section of the RoE packet with a max payload size of Max_RoE_payload_size sequentially, that is, I sample first then Q sample etc. Padding bits are used if necessary so that there are integer octets in the payload field.

Figure 3.12 Primitives used for the Split II mapper for the PUCCH (based on RoE definitions)

3.1.2.2. Split MAC-PHY mapper

Table 3.4 Parameters used for the MAC-PHY mapper

Parameter Definition Comments Num_TB Number of transport blocks

(TB) per user per TTI Equal to the number of

codewords Nlayers Number of layers to be used for

Num_control_IQ_Samples_per_Container = NPUCCH,CR x NPUCCH,RE

IQ_sample_length=2 x S //two times sample length for I and Q. Note that s is constant now.

Max_RoE_payload_size ≥ 2∑ (𝑁𝑁𝑁𝑁𝑁𝑁_𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐_𝐼𝐼𝐼𝐼_𝑆𝑆𝑆𝑆𝑁𝑁𝑆𝑆𝑐𝑐𝑆𝑆𝑆𝑆_𝑆𝑆𝑆𝑆𝑐𝑐_𝐶𝐶𝑐𝑐𝑐𝑐𝑐𝑐𝑆𝑆𝐶𝐶𝑐𝑐𝑆𝑆𝑐𝑐 × 𝑆𝑆)𝑘𝑘1

RoE.numContainers= Num_MIMO

RoE.container[0….Num_MIMO-1].lenContainer= 2 × 𝑁𝑁𝑁𝑁𝑁𝑁_𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐_𝐼𝐼𝐼𝐼_𝑆𝑆𝑆𝑆𝑁𝑁𝑆𝑆𝑐𝑐𝑆𝑆𝑆𝑆_𝑆𝑆𝑆𝑆𝑐𝑐_𝐶𝐶𝑐𝑐𝑐𝑐𝑐𝑐𝑆𝑆𝐶𝐶𝑐𝑐𝑆𝑆𝑐𝑐𝑐𝑐 × 𝑆𝑆

RoE.numSegments=k where k| NPUCCH,CR //Defines the number of PUCCH queues inserted into the payload section of each packet. For K>1 more than one queue worth of samples is inserted in a packet. K divides NPUCCH,CR.

RoE.container[0…. Num_MIMO -1].flow_id=1,…., Num_MIMO

RoE.segment.flow_ids=1… Num_MIMO

seqNumMin=1

seqNumMax= NPUCCH,CR // will depend on number of control regions per TTI and will be different every TTI i.e. sequence wraps around every TTI. The sequencing is used to synchronise the equivalent queues at the DU i.e. packet for first queue will have the lowest SN while packet for the last queue will have the highest SN.

seqNumIncrement= k


Page 49 of 110


user allocations NRB RBs allocated per user per TTI NRe REs per allocated RB that can

be used for user-plane data

M Modulation order C Coding rate

NPUCCH,CR Number of PUCCH control regions

NPUCCH,RE Number of REs within PUCCH control region

PRACH_period PRACH periodicity 1 ms, 2 ms, 3 ms, 10 ms etc.

Synchronisation with the radio frame timing is achieved through sequence numbers. But as for the Split II mapper case, the only SN used for this purpose is that in the control process (carrying the MAC control primitives). The SNs for the data packets are used for inserting user data into the queues at the RU in the correct order (as packets may be received out of order).

If a user has more than one TB allocated per TTI (for MIMO schemes), each TB will be sent through a separate packet (as each TB is processed separately at the receiver). The receiver knows which packets in a TTI are for the same user by comparing the SN of each packet, i.e. the SNs of all packets for a single user per TTI will have the same sequence number.

DL (data pkt_type 1, TBs):

The mapper extracts TB_length bits from the LTE MAC processor output that is, a full transport block worth of data. The size of each TB is variable depending on modulation and coding scheme/index (MCS) and resource allocation. The associated primitives for all user TBs per TTI allocation are sent separately by the “control process” with a separate sequence number. The RoE maximum packet payload size is given by Max_RoE_payload_size. Padding bits are used if necessary so that there are only complete octets in the payload field.


Page 50 of 110


Figure 3.13 Primitives used for the MAC-PHY mapper for the TBs (based on RoE definitions)

DL (control pkt_type 1, MAC control primitives):

The control process will create one control RoE packet (control pkt_type 1) containing MAC control primitive bits per TTI:

Figure 3.14 Primitives used for the MAC-PHY mapper for the MAC control primitives (based on RoE definitions)

UL (control pkt_type 1, PRACH):

The control process will create one control RoE packet (control pkt_type 1) containing PRACH bits per PRACH periodicity setting:

TB_length = Nlayers x NRB x NRE x M x C // TB length calculation per codeword per user

Max_RoE_payload_size ≥k x TB_length

RoE.numContainers= Num_TB

RoE.container[0…. Num_TB -1].lenContainer= TB_length

RoE.numSegments= k // In case we want to send more than one queue length worth of data.

RoE.container[0…. Num_TB -1].flow_id=1,…., Num_TB

RoE.segment.flow_ids=1… Num_TB

seqNumMin=1

seqNumMax= …. //will be equal to the number of allocations per TTI and will be different every TTI. The sequencing is used to synchronise the equivalent queues at the RU i.e. packet for first queue will have the lowest SN while packet for the last queue will have the highest SN.

seqNumIncrement= // this will be 1 if every packet contains data for just one allocation i.e. one packet per 1 ms for each queue.

seqNumMin=1

seqNumMax= 10 corresponding to 10 TTIs per radio frame//Sequence wraps around every 10 ms radio frame

seqNumIncrement= 1


Page 51 of 110


Figure 3.15 Primitives used for the MAC-PHY mapper for the PRACH (based on RoE definitions).

UL (control pkt_type 2, PUCCH):

Mapper extracts Num_PUCCH bits from the PHY processor per user queue. The bits are inserted into the payload section of the RoE packet with a maximum payload size of Max_RoE_payload_size. Padding bits are used if necessary so that there are only complete octets in the payload field.

Figure 3.16 Primitives used for the MAC-PHY mapper for the PUCCH (based on RoE definitions)

3.1.3. High-Speed functional split traffic At HHI a custom solution for future converged fixed-mobile networks has been developed [40], [41], which symmetrically transmits and receives 5 Gbps baseband signals in real-time. The real-time system compensates for the major impairments of a radio link, namely the CFO and the IQ imbalance, and has been tested in a lab setup. With a gross data rate of 5 Gbps and an analogue signal BW of approximately 2 GHz (up-converted signal) the system presents high-level features similar to that to be expected in 5G.

The proposed flexible split point at the upper-PHY not only reduces the data rates and latency requirements compared to current fronthaul implementations and enables statistical multiplexing gains, but since intermediate signals are now being transported instead of a digitized waveform, the fronthaul transport becomes waveform agnostic. Thus, the platform described in [41] will be further developed to experimentally demonstrate the advantages and challenges discussed in the project. The custom system presents similarities with 5G in terms of bandwidth and data rates and it is an

seqNumMin=1

seqNumMax= Floor([10/ PRACH_period(ms)] //Sequence wraps around every 10 ms frame

seqNumIncrement= PRACH_period

Num_PUCCH = C x M x NPUCCH,RE

Max_RoE_payload_size ≥ Num_PUCCH x i // for i | 10 i.e. i divides 10

seqNumMin=1

seqNumMax= …. //will be equal to the number of allocations per TTI and will be different every TTI. The sequencing is used to synchronise the equivalent queues at the RU i.e. packet for first queue will have the lowest SN while packet for the last queue will have the highest SN.

seqNumIncrement= i // this will be 1 if every packet contains data for just one allocation i.e. one packet per 1 ms for each queue.


Page 52 of 110


attractive platform to enable an early proof-of-concept of the evolved fronthaul proposed in iCIRRUS.

Figure 3.17 Real-time transceiver building blocks (reference high-speed DU)

The system consists of two identical transceivers. The functionality of one of the real-time transceivers we are taking as a reference DU is depicted in Figure 3.17 and is described in detail in [40] and [41]. Currently, a standard 10G Ethernet interface, Figure 3.18 (left), serves as data input (backhaul) to the DU. At the transmitter, 4 outputs that correspond to 2 complex valued channels (twice I and Q component), and 4 inputs at the receiver, Figure 3.17 right, can be connected to a RU for digital-to-analogue/analogue-to-digital conversion and radio conversion. In Figure 3.17, the orange dashed line shows the position of the upper-PHY split point where the evolved fronthaul interface will be set as discussed in Section 1.3. In the original system, if the digitized waveforms were transmitted, setting the fronthaul interface right after or before the digital-to-analogue (DAC) or analogue-to-digital (ADC) converter interfaces, respectively, in Figure 3.17, the resulting data throughput would be beyond 100 Gbps in each direction (4 DACs x 2.5 GSps sample rate x 14 bit/Sample = 140 Gbps). However, by shifting the fronthaul interface to the upper-PHY as depicted in Figure 3.17 a data throughput of only 5 Gbps has to be transported by the fronthaul network.

The resulting evolved DU with the fronthaul interface at the upper-PHY split point is shown in Figure 3.18. For Ethernet transport, the information coming from the FEC block in the downlink has to be mapped into Ethernet frames. That is performed by the Ethernet mapper in Figure 3.18. In the uplink, the incoming frames from the fronthaul are processed and demapped at the Ethernet demapper as shown in Figure 3.18.


Page 53 of 110


Figure 3.18 High-speed evolved DU building blocks

The current custom system is not as complex as an LTE-based system. Originally developed to overcome wirelessly a broken fibre connection, the system does not support at this current implementation stage a multi-user scenario, not being required to share or assign resources such as BW among several users. The resulting fronthaul will only transport Ethernet frames containing user data.

The original system implements a Reed Solomon (239,255) encoder and decoder for FEC. In order to enable real-time processing for the incoming 10 Gbps Ethernet stream, the signal processing has to be parallelized to meet the throughput when working only at a couple of MHz clock speed in the FPGA. Due to this required parallel signal processing the resulting encoded FEC block is 2040 octets long. In order to minimize any penalty in the performance due to packet loss it is convenient not to split the encoded FEC block among several Ethernet frames. Additionally and in order to minimize the overhead due to the Ethernet mapping process, it is better to use payloads as large as possible but, on the other hand, the larger the payload the longer the latency associated with the processing at the DU. Since latency is a very stringent requirement for the fronthaul, as discussed in Section 2, a single encoded FEC block will be mapped to a single Ethernet frame which, due to being longer than 1518 bytes, is a jumbo frame.

Figure 3.19 Ethernet Frame structure to transport user data from the high-speed evolved DU

Figure 3.19 shows the structure of the resulting Ethernet frame for the upper-PHY split point. The MAC destination address is the MAC address of the RU and the DU for the downlink and uplink, respectively, and vice versa for the MAC source address. The Ethernet type and RoE header are based on the discussions from the IEEE 1904.3 task force [37]. Figure 3.20 shows the RoE header for non-control packets that it used in the high-speed fronthaul. The definition of each field of the RoE header illustrated below can be found in [42].


Page 54 of 110


Figure 3.20 Accepted baseline proposal for RoE header format for non-control packet

The RoE header shown in Figure 3.20 has been updated in the IEEE 1904.3 standard draft [38] after the implementation and evaluation of the Ethernet mapping here proposed. The required modifications to comply with the new format will be performed in the near future and will be reflected in later work.

For the proposed Ethernet mapping procedure described above, the performance, in terms of resulting data rates and latency, depends on how the incoming frames are actually mapped into the FEC blocks. Two approaches can be identified, one focused on reducing the latency, the other focused on reducing the overall overhead. In order to reduce the latency, the incoming frames should be processed by the DU as fast as possible minimizing the latency due to signal processing in the DU. To achieve that, if data arrive but the information is not enough to fill one FEC block, idle data will be used to complete the remaining bytes if no data is available, e.g. at lower input traffic rates. The main drawback is the higher overhead that is generated at lower data rates, which reduces the statistical multiplexing gain. In order to optimize the resulting overhead, the second method only maps user information to the FEC blocks leading to the lowest overhead possible but, on the other hand, increasing the latency, especially at lower data rates. Both methods have been implemented in real-time and tested in order to evaluate and compare performance. The results are shown and discussed in Section 4.1 and 4.2.

3.2. Timing and synchronization In essence, there are two approaches of synchronization:

• Physical layer approach (for example Synchronous Ethernet (SyncE) [43], [20], [44], [45]) • Packet-based approach (for example IEEE 1588 [35] or IEEE802.1AS [46])

3.2.1. Physical layer approach – Synchronous Ethernet Briefly, SyncE technology is a physical layer technology. The idea of SyncE is that frequency synchronization is transported with the bits over the physical layer. Common receiver clock recovery mechanisms as part of the physical layer functionality establish the frequency synchronization (cf. Figure 3.21). This allows recovering the clock from the code stream on the Ethernet link. As an asynchronous system, Ethernet can function properly without a high-precision clock. Consequently, most Ethernet devices do not provide high-precision clocks. With the use of SyncE over Ethernet, frequency synchronization is achieved. At a certain point, a master clock (primary reference clock (PRC)) feeds a phase-locked loop (PLL) controlling the transmitter part of the Ethernet PHY of a


Page 55 of 110


switch or router. A receiver of another switch connected to that transmitter can recover the clock frequency and control its PLL. This PLL drives then the transmitter of this switch. Through such a chain, the frequency synchronization can be propagated via the physical layer.

Figure 3.21 SyncE - Frequency synchronization by physical layer clock recovery

3.2.2. Packet-based approach – IEEE 1588 Precision Time Protocol (PTP), or IEEE1588 [47], is a standardized protocol defined by the IEEE, initially developed for the industrial automation sector. It was then adapted for mobile networks and developed by ITU-T Q13/SG15 for distributing phase and time. Several PTP telecom profiles for phase and time are currently under definition at the ITU-T Q13/SG15 [48, 49].

The main idea of the packet-based approach of IEEE1588 is to measure with the help of time stamping the packet propagation delay between a source (master) and the device to be synchronized (slave). Then this measured delay is used to correct the time offset of the slave to the master.

Figure 3.22 depicts the measurement process for the packet propagation delay –also called path delay.

At first, the timestamp T1 is taken when the Sync message is transmitted from the master to the slave. If the master is able to put the timestamp at once into the Sync message, only the Sync message is required. Otherwise, a Follow up message is required, which contains the timestamp T1. Secondly, the slave takes the timestamp T2 when the Sync message is received. When the slave sends the Delay_req message in the opposite direction back to the master, the slave takes the timestamp T3. The master takes the timestamp T4 when he receives the Delay_req message. The master packs T4 in a Delay_resp message and sends this message back to the slave. Then the slave knows all timestamps required to calculate the mean path delay according to (3.1):

𝑀𝑆𝑆𝑆𝑆𝑐𝑐𝑀𝑆𝑆𝑐𝑐ℎ𝐷𝑆𝑆𝑐𝑐𝑆𝑆𝐷 =

(𝑇2 − 𝑇1) + (𝑇4 − 𝑇3)2

(3.1)


Page 56 of 110


Figure 3.22 IEEE 1588 -packet-based approach for time synchronization

3.2.3. Packet-based approach – IEEE 802.1AS time synchronization The packet-based approach of IEEE 802.1AS for time synchronization is based on IEEE 1588v2. IEEE 802.1AS can be considered as subset or profile of IEEE 1588v2.

As in IEEE 1588, the main idea is to calculate the delay between a source and the device to be synchronized with timestamps. The terminology differs slightly. The master is called the responder whereas the slave is called the initiator. Then this measured delay is used to correct the time offset of the initiator to the responder. The measurement and calculation procedure is outlined in the left part of Figure 3.23. At the beginning, the initiator takes the timestamp T1 when he transmits the request message the responder. The responder takes the timestamp T2 when he receives this message. The responder puts T2 and the timestamp of transmitting this response message back to the initiator (T3) in the response message and sends this response message back to the initiator. The initiator takes the timestamp (T4) when the response message is received at the initiator. Then the initiator can calculate the mean path delay (cf. Equation (3.1)). Finally, the initiator corrects the time offset of the initiator to the responder with the mean path delay. In essence the difference between IEEE 802.1AS and IEEE1588 and is that the correction is requested by the initiator (slave) and not by the responder (master).

In addition to IEEE 1588, IEEE 802.1AS defines additional formal interface definitions for time-aware applications (cf. right part of Figure 3.23).


Page 57 of 110


Figure 3.23 IEEE 802.1AS -packet-based approach for time synchronization

3.3. Time sensitive Ethernet switching /aggregation In the following, section 3.3.1 describes time-sensitive networking mechanisms which are provided by available standards or are under consideration or development by standards committees. Section 3.3.2 provides a summary and outlines some of the main issues and possible design choices that are currently under investigation within the iCIRRUS project.

3.3.1. Standards overview In the context of the 802.1 IEEE standards committee for LAN / MAN standards, the Time-Sensitive Networking task group is currently investigating approaches for time-sensitive networking. The time-sensitive networking approaches consist of multiple parts. The parts with capital letters, for example 802.1CB or 802.1CM are independent standards. In contrast, the parts termed with lower case letters, for example 802.1Qbv or 802.1Qbu are amendments or extensions to existing standards. From time to time, a revision of the main standard incorporates these extensions. For example, 802.1Qav and 802.1Qat are part of 802.1Q-2014, as clause 34 and clause 35. The distinct parts of the time-sensitive networking can be clustered as follows [50]:

• Time synchronization • Queuing and forwarding • Registration and reservation • Reliability and redundancy • Overall system architecture

The item time synchronization encompasses 802.1AS [46], which is based on IEEE1588v2 [35] (cf. also previous section about timing and synchronization).


Page 58 of 110


The queuing and forwarding part contains approaches to reduce latency and latency variation. These are 802.1Qav Forwarding and Queuing Enhancements for time-sensitive streams (FQTSS, credit-based shaping) [51], P802.1Qbv Enhancements for Scheduled Traffic (time-aware shaping) [52], P802.1Qch cyclic forwarding and queueing [53], and P802.1Qbu frame pre-emption [54].

The item on registration and reservation comprises procedures for the management of latency reduction, for example 802.1Qat Stream Reservation Protocol (SRP) [51] and P802.1Qcc Enhanced Stream Reservation Protocol [55].

The item on reliability and redundancy encompasses P802.1Qci Per-Stream Filtering and Policing (PSFP) [56], also called input gating, and P802.1CB seamless redundancy [57].

802.1BA for audio video systems is often referenced for overall system architecture since audio video bridging was the umbrella for all timing-related networking activities at the outset. After the focus was widened from audio and video issues to automotive and industrial applications, the umbrella term was renamed to time-sensitive networking. For telecommunications, and in particular for fronthaul, the P802.1CM mobile fronthaul RoE [58] is representative for the overall system architecture.

3.3.1.1. Queuing and forwarding: IEEE 802.1Qav forwarding and queuing for time-sensitive streams

IEEE 802.1Qav Forwarding and Queuing for Time-Sensitive Streams (FQTSS) credit based shaping requires that a transmitting device (also called talker) has to make use of priorities and traffic classes.

The idea of IEEE 802.1Qav credit based shaping is, as the name states –the credit based shaper. Here, the network traffic is shaped by the scheduling of packet transmissions based on priorities and traffic classes. The shaper algorithm calculates the credit based on the terms idleSlope and the sendSlope. IdleSlope is the term for the data rate (bit/s) by which the credit increases if there is no transmission or outgoing packet. The sendSlope decreases the credit value if there is a transmission (sendSlope=idleSlope minus portTransmissionRate). A transmission is only allowed if the credit value is positive.

The benefit of the IEEE 802.1Qav credit based shaping is that burst traffic is distributed over the time axis. This reduces the excessive extra latency or delay caused by congestion, which is induced by burst traffic.

Figure 3.24 depicts the IEEE 802.1Qav credit based shaping by an example.


Page 59 of 110


Figure 3.24 IEEE 802.1Qav credit based shaping In the beginning, the queue contains three packets. An interfering packet prevents the transmission of the first of the stored packets. While the interfering packet blocks the packet transmission, the idleSlope increases the credit value. When the interfering packet is completed, the first stored packet is sent. While the first packet is sent, the sendSlope decreases the credit value. After the first packet is finalized, the credit value is negative. The transmission of the second packet is deferred until the credit value gets positive. During the sending, the sendSlope decreases the credit value. The transmission of the third packet has to wait until the credit value is positive again. A fourth packet is queued. Then the third packet is sent while the sendSlope decreases the credit value. The transmission of the fourth packet is performed when the credit value is positive again.

3.3.1.2. Queuing and forwarding: IEEE P802.1Qbv enhancements for scheduled traffic

IEEE P802.1Qbv time-aware shaping requires time synchronization, which IEEE 802.1AS, IEEE1588 or similar can provide. IEEE P802.1Qbv time-aware shaping is based on IEEE 802.1Qav credit based shaping. Further, IEEE P802.1Qbv time-aware shaping requires a fully managed network. All switches have to be made aware of the cycle time for the scheduled or protected traffic.

The idea of the IEEE P802.1Qbv time-aware shaping is to enable a bridge or an arbitrary end-point to transmit packets from a traffic class queue with reference to a known timeframe. It uses a transmission gate per traffic class queue to allow only one traffic class queue to access the network at a specific time (cf. Figure 3.26). In addition, a so called “guard band” time period before the start time of the protected or scheduled traffic section in a time periodic window prevents the transmission of any non-scheduled best effort packet, which could delay a scheduled or time-sensitive packet (cf. Figure 3.25). This enables a protected interference free connection through the network.

The big benefit of IEEE P802.1Qbv time-aware shaping is the reduction of latency by avoiding interfering traffic.


Page 60 of 110


Figure 3.25 depicts the connection between periodic time window, scheduled or protected section, best effort section, and guard band in more detail. In the guard band the transmission of any packet is blocked. The guard band is required to prevent that a best effort packet can reach the protected section and delays a time-sensitive packet. The size of the guard band section has to be large enough that the impact of the largest occurring packet can be eliminated.

Figure 3.25 IEEE P802.1Qbv time-aware shaping –guard band

Figure 3.26 shows how the transmission gates achieve the enforcement of the scheduled or protected window and the guard band. A gate control list controls the transmission gates belonging to a distinct traffic class queue dependent on the time. For example, at time T00 the transmission gate of queue 4 is open whereas all other gates are closed. This enables a protected section. At time T01 the transmission gate of queue 4 is closed and all other transmission gates are open. This is a possible configuration for a best effort section. The point in time T02 shows a feasible configuration for a guard band section where all transmission gates are closed.


Page 61 of 110


Figure 3.26 IEEE P802.1Qbv time-aware shaping –transmission gate

3.3.1.3. Queuing and forwarding: IEEE P802.1Qbu / 802.3br frame pre-emption

The IEEE P802.1Qbu Frame Pre-emption is based on IEEE 802.1Qav credit based shaping and extends it.

The idea of the IEEE P802.1Qbu frame pre-emption is to reduce the guard band by interrupting and pre-empting the transmission of a low priority packet by a higher priority packet. The minimum fragment size is 124 byte (64 byte packet and 60 byte cyclic redundancy check (CRC) [54]).

The benefit of the IEEE P802.1Qbu frame pre-emption is that the guard band has no longer to be as large as the largest possible interfering frame. The guard band can be shrunk so that it only has to eliminate the effect the largest possible fragment. This enhances the efficiency of the transmission system significantly.

Figure 3.27 illustrates the above mentioned reduction of the size of the guard band.


Page 62 of 110


Figure 3.27 IEEE P802.1Qbu frame preemption – shrinking the size of the guard band

3.3.1.4. Queuing and forwarding: IEEE P802.1Qch cyclic queuing and forwarding

The IEEE P802.1Qch cyclic queuing and forwarding (CQF) requires both the IEEE P802.1Qbv time-aware-shaper and the IEEE P802.1Qci per steam filtering and policing. In addition, IEEE P802.1Qch cyclic queuing and forwarding is considered to be applied together with IEEE P802.1Qbu / 802.3br frame pre-emption.

The idea of IEEE P802.1Qch cyclic queuing and forwarding is a traffic shaping method using two transmission queues and a cycle timer (cf. Figure 3.28). The cycle timer should be designed large enough for the stream data during a measurement interval plus at least one maximal interfering frame or frame fragment.

The benefits of the IEEE P802.1Qch cyclic queuing and forwarding approach is that if the cycle time is set appropriately, the latency of a packet through the network can be calculated by computing the sum of the per-hop delays. The per-hop delays are dominated by cycle time and are unaffected by any other topology considerations. This is a clear advantage compared to IEEE P802.1Qbv time-aware shaping where the worst-case delays are topology dependent and not so easily calculable.

Figure 3.28 outlines the cyclic queuing and forwarding approach combining the per stream filtering stacked upon the queuing and transmission selection by transmission gates.


Page 63 of 110


Figure 3.28: IEEE P802.1Qch cyclic queuing and forwarding (CQF)

3.3.1.5. Registration and reservation: IEEE 802.1Qat stream reservation protocol

The idea of the IEEE 802.1Qat stream reservation protocol (SRP) is to provide a standardized mechanism or protocol to manage the management of the resource allocation or resource reservation within a network consisting of more than one switch. It operates on streams, which are identified by the source MAC address plus a higher level identification like the IP port address to satisfy bandwidth and latency requirements.

In the first phase (cf. Figure 3.29 left side), the talker (the transmitting device) initiates the propagation of its stream advertisement or reservation request through the bridges in the network to the listener (the receiving device). If this is successful and the requested resources are available, the listener (cf. Figure 3.29 right side) initiates the propagation of this “ready” state back the reserved and allocated path to the talker.

Figure 3.29 IEEE 802.1Qat stream reservation protocol


Page 64 of 110


3.3.1.6. Registration and reservation: IEEE P802.1Qcc enhanced stream reservation

IEEE P802.1Qcc enhanced stream reservation is based on and extends the IEEE 802.1Qat stream reservation protocol.

In essence, the IEEE P802.1Qcc enhanced stream reservation relies on an explicit centrally managed network. In addition, the size and the frequency of reservation messages are optimized.

3.3.1.7. Reliability and redundancy: IEEE P802.1Qci per-stream filtering and policing

The IEEE P802.1Qci Per-Stream Filtering and Policing (PSFP), which is also known as input gating or input gates, extends the idea of the stream filters that are defined in clause 6 of IEEE P802.1CB seamless redundancy.

The idea of the IEEE P802.1Qci per-stream filtering and policing is to enable a filtering and policing on the level of single streams for bridges and end-points. It is suggested to accomplish this by the combination of stream gates and flow meters or counter components (cf. Figure 3.30).

The benefit of the IEEE P802.1Qci per-stream filtering and policing is that this mechanism allows filtering and policing decisions and subsequent frame queuing decisions. Advantageous applications are the protection against software bugs on end-points or hostile devices. For example, the excess of bandwidth, excess of burst size, excess of packet size or misuse of labels can be confined.

Figure 3.30 describes an example setup for the combination of stream gates and flow meters. At first at the incoming stage, a stream is assigned a priority, a stream gate and a flow meter. For instance, Stream 2 is assigned priority 3, stream gate 1 and meter 5. Each stream gate has an own gate control list that controls whether a stream gate is open or closed at a distinct point in time. In addition, it assigns an internal priority specification value (IPS) with or without respect to the previous assigned priority value. This value is used to match the stream to the corresponding traffic class queue in the following step of the packet forwarding process, the “queuing of frames”. Parameters for the flow meter can be committed information rate, maximum committed information rate, committed burst size, excess information rate, etc. In addition, a flow meter can take metrics like counting the number of passed frames or blocked frames.


Page 65 of 110


Figure 3.30 IEEE P802.1Qci Per-Stream Filtering and Policing (PSFP)

3.3.1.8. Reliability and redundancy: IEEE P802.1CB seamless redundancy

The idea of the IEEE P802.1CB seamless redundancy is to allow a selective packet replication on stream basis. Address, traffic class and sequence number identifies this stream. The selective replication is accompanied by the duplicate frame elimination before the destination (cf. Figure 3.31). To limit the required memory, timing information is used in addition to address traffic class and sequence number.

Figure 3.31: IEEE P802.1CB seamless redundancy

3.3.1.9. Overall system architecture: IEEE P802.1CM mobile fronthaul IEEE P802.1CM mobile fronthaul (radio over Ethernet) is currently in a rough draft status. Latency and frequency requirements are currently under discussion. IEEE P802.1CM mobile fronthaul will require IEEE 802.1Q VLAN Bridge specification, IEEE 1588 time synchronization, IEEE P802.1Qbv


Page 66 of 110


time-aware shaping, and IEEE P802.1Qbu / P802.3br frame pre-emption. For low FLR, IEEE 802.1CB seamless redundancy may be applied.

3.3.2. Proposal for the evolved fronthaul Based on the envisaged architecture presented in Section 1.1, the evolved fronthaul will need to transport a number of traffic streams originating from sources with different transmission characteristics. Therefore, the type and method of scheduling is still an open question and a subject of on-going research within the project, but it is expected that a combination of scheduling techniques will need to be employed. The time-aware shaper that has been discussed in Section 3.3.1 does offer certain advantages in theory but whether it can provide the necessary performance in a practical implementation is an open question (that will be addressed through extensive simulation). Issues include the ability of the guard bands to ensure that different traffic streams will not mix, especially in a fronthaul with a number of sources of different transmission characteristics. Also the latency imposed in the fronthaul by using a large number of guard bands (to ensure that traffic types do not mix) will have to be considered.

In this document and specifically in Section 4.4, a number of scheduling algorithms have been tested, based on their effects on a number of KPIs from an Ethernet fronthaul with mixed-traffic types. Although it is unlikely that these scheduling algorithms will be used directly in the evolved fronthaul (but perhaps in some modified version) they have been used here to demonstrate the KPI monitoring system and the improvement brought on to the monitored KPIs by the different queueing regimes. The KPIs include inter-frame delays (which are related to inter-slice delays in IQ over Ethernet transportation), FDV, fronthaul latency, fronthaul link utilisation (not shown in this document but present in [2]) and over-the-air (OTA) performance including HARQ retransmissions and LTE MAC throughput (not shown here). It is important to note that the KPI extraction can be done at very high resolution (to the level of a single Ethernet frame transmission time) and therefore, the “intelligence unit” (or SDN-type controller as described in Figure 3.5 in Section 3.1.1) can potentially adapt the fronthaul operation at very small time windows.

The question of whether to use store-and-forward or cut-through switching (note that store-and-forward is unavoidable when scheduling is performed in the switch i.e. contention happens) comes into play only when considering the fronthaul latency (and perhaps the FDV performance). As there will be at least one serialisation delay at the input of the fronthaul, a second serialisation delay in the aggregation unit (Ethernet switch) will not affect the inter-frame delays, but only the end-to-end latency which will have to conform to HARQ operation round-trip time (RTT) limits. The FDV results in Section 4.4 do indicate that an extra serialisation delay increases the FDV slightly, so any possible improvement with cut-through switching in the FDV performance will need to be verified in future measurements. Of course, if the choice is available (e.g. in a fronthaul with static transmission characteristics), then the option would be to use cut-through switching and ensure that the latency is kept to a minimum.

However, the switching technique and the scheduling algorithm used will be very important in ensuring that PTP performance is not affected. The combination of these two design elements will


Page 67 of 110


need to ensure that PTP packets do not encounter variable DL / UL delays. Furthermore, if this cannot be guaranteed then some added functionality will need to be implemented so that timestamps can be corrected. This could be done by a learning algorithm based on delay variation statistics (such as those presented in Section 4.4.1 although other methods for offsetting (correcting) timestamps may be possible).

Another issue that is currently being investigated is the use of SDN in the fronthaul. SDN can be used for a number of applications (including traffic steering, load balancing and switching protection), but for scheduling, the latency of the communication channel between an SDN-capable switch and the SDN controller will need to be investigated. This latency will also depend on the overall architecture (i.e. placement of the controller within the fronthaul, number of controllers used, etc.).


Page 68 of 110


4. Feasibility analysis In order to evaluate the capability of the architecture proposed in Section 1 in meeting the requirements discussed in Section 2 with the functions and mechanisms presented in Section 3, different performance estimations are presented in following subsections. The work done so far comprises performance evaluation of state of the art implementations, as well as numerical simulations and tests in the laboratory with different kinds of equipment.

Special attention is given to the resulting data rates from the implementation of a modified functional split between DU and RU in Section 4.1 as well as to the latency in the proposed fronthaul in Section 4.2. Section 4.3 reviews the state of the art of timing and synchronization and the achievable accuracy of the proposed methods. Due to the important impact on the performance of the packet-based synchronization methods, delay variation measurements are also addressed in Section 4.4.

4.1. Bandwidth and data rate

4.1.1. Legacy traffic The transportation of legacy (IQ-based) traffic will still be important in future C-RAN implementations. This is mainly due to backward compatibility and prior investment from operators. This means that the fronthaul will need to support a mixture of traffic-types as was discussed in the architecture overview (Section 1.1). The choice of which processing is implemented (either split processing or centralised) will depend on the operator (perhaps in a multi-operator scenario), network conditions, number of users, etc. The increased data rates and lack (or loss) of synchronisation are the main challenges of the legacy fronthaul implementation. The former issue becomes apparent when considering multiple antenna techniques (e.g. massive MIMO) and is shown in Table 4.1.


Page 69 of 110


Table 4.1 Required data rates following CPRI encapsulation into Ethernet assuming RoE mapping

Number of antennas 4 8 16 64 128

CPRI line rate (Mbps) 4915.2 9830.4 19660.8 78643.2 157286.4

ETH data plane data rate (Mbps) 3903.4 7806.7 15613.4 62453.7 124907.5

ETH control plane data rate (Mbps) 254.2 507.7 507.7 507.7 507.7

ETH frame size for control (octets)1 2119 4231 4231 4231 4231

Total ETH average data rate (Mbps) 4157.6 8314.4 16121.1 62961.4 125415.1

4.1.2. LTE-based traffic Two interesting split points have been identified in the iCIRRUS project as discussed in Section 1.3. Referring to Figure 4.1, these are Split I and Split II. Note that Split I is very similar to a MAC-PHY split but it does offer smaller data rate reductions due to the transportation of soft bits. It is assumed that the general mode of operation will be based on Split II (in both UL and DL), but for users at the edges of cells and for which CoMP is used; Split II will be used in the UL. In this Section, the data rate requirements for Split II and a MAC-PHY split are presented with some simplifications.


Page 70 of 110


Figure 4.1 Different split point options and division of data among packet types and flows

Figure 4.2 shows the uplink fronthaul data rate for different number of MIMO antennas (N) under different loads. A few simplifications have been made: all UEs are assumed to have data and thus there are no separate PUCCH transmissions. PUCCH data is sent through the PUSCH. The sounding channel is assumed to be disabled. Maximum modulation level (64-QAM) is assumed for all data.

Figure 4.2 Uplink data rate for different numbers of antennas, for Split II

Figure 4.3 shows the uplink fronthaul data rate for up to two layers and up to 100 MHz BWs. Only user plane data (PUSCH) are used for these calculations. Note that number of layers ≤ number of antennas i.e. a number of layers can map to a larger number of physical antennas (this is important


Page 71 of 110


when comparing these results with Figure 4.2). Maximum modulation level (64-QAM) is again assumed for all data.

Figure 4.3 Uplink data rate for different numbers of layers (per radio unit) for different loads for split MAC-PHY The presented fronthaul data rates do not include additional overheads from the transport infrastructure. Taking additional overheads into account the following representative values, shown in Table 4.2, are obtained. Assumptions here include Ethernet encapsulation, RoE header of 10 octets, 64B/66B line code, C&M of 6% overhead (constant) and PTP per DU-RU pair (insignificant overhead).

Table 4.2 Uplink fronthaul data rates resulting from different functional splits per sector/cell/carrier. Assuming 8 antennas and 100 MHz BW. For splits III & II the sample resolution is 8 bpS

Split selection

Sector load

20% 50% 100%

Data rate (Gbps)

Split III 12.2 12.2 12.2

Split II 2.5 6.1 12.2

Split MAC-PHY1

0.2 0.5 1

1Assuming two codewords

4.1.3. High-speed system-based traffic A first evaluation of the evolved fronthaul performance, based on the real-time system and Ethernet encapsulation presented in Section 3.1.3, has been carried out. The real-time DU processing depicted in Figure 4.4 has been implemented in a Xilinx Virtex 7 FPGA and both 10G Ethernet interfaces are SFP+. Figure 4.4 shows the experimental setup used to evaluate the resulting throughput in the fronthaul using a protocol analyser. The protocol analyser is used as traffic source to emulate the backhaul and generate different input frame lengths and different input throughputs.


Page 72 of 110


Figure 4.4 Experimental setup for measuring the resulting throughput on the fronthaul interface for the upper-PHY split

The two methods described in Section 3.1.3 to map the incoming frames to FEC blocks, namely the latency-optimized and the overhead-optimized methods, have been tested and the results are shown in Figure 4.5 and Figure 4.6, respectively. The fronthaul throughput is depicted as a function of the input (backhaul) traffic throughput for different input frame lengths. In both figures, the diagonal has been drawn as a reference for the overhead since it refers to the overhead-free case, a constant overhead resulting in a constant slope above the diagonal.

Figure 4.5 Fronthaul throughput for a latency-optimized mapping to FEC block

For the latency-optimized mapping, idle data are used when no user information is available to complete the FEC blocks. This results in a high overhead especially for lower traffic loads and small packets as shown in Figure 4.5 for input traffic under 1 Gbps fronthaul rates between 6 and 7 Gbps are generated for 66 and 128 byte long frames. This high overhead results in a load that quickly saturates the fronthaul, reaching the maximal fronthaul data rate. For a given input throughput the overhead decreases as the frame length increases, due to more user information being mapped to


Page 73 of 110


the FEC block. Larger frame length, such as 1024 or 1518 byte frames, present a constant overhead at data rates where the frame gaps are long enough such that every single frame is packed in an FEC block and not split between two. As the frame gap becomes smaller, traffic load increases, the probability of a frame being split over two FEC blocks increases and the resulting overhead varies non-linearly with the load (see non-linear range around 6 Gbps input traffic for 1024 byte long frames), otherwise as long as the frames are not split, the resulting throughput is linear until it saturates. For intermediate frame lengths, the performance is strongly dependent on the packet inter-arrival time (see the non-linear behaviour for 256 and 512 byte long frames), which will determine how the frames are split into FEC blocks and how many FEC blocks are generated for a given number of input frames, and consequently how much overhead is generated.

Figure 4.6 Fronthaul throughput for a overhead-optimized mapping to FEC blocks

Figure 4.6 shows the fronthaul throughput when the overhead-optimized mapping is used to mapped the input traffic in FEC blocks. In this case no idle data is used to complete FEC blocks just user data are used. That eliminates the performance dependence on the input packet arrival time and can be clearly observed when comparing Figure 4.6 with Figure 4.5 and realizing the linear behaviour of the first one for all input data traffic and frame lengths. Figure 4.6 also shows a different slope depending on the frame length, smaller for larger lengths. That is due to a custom header that is added to every input frame for internal processing. The header consists of 64 bit for every frame length which leads to an overhead that decreases as the frame length becomes larger. The more linear behaviour and the lower overheads allow for greater statistical multiplexing gains.

Apart from the throughput, the processing latency is also a critical parameter in the evolved fronthaul and has also been evaluated for both mapping options. In the following section the experimental latency setup is presented and the results are discussed.


Page 74 of 110


4.2. Latency Figure 4.7 shows the experimental setup used to evaluate the processing latency at the DU with the fronthaul interface at the upper-PHY split point. The same protocol analyser used for the throughput measurements is used for the latency measurements. The measurement method is based on time stamping the outgoing frames and analysed the returning time stamping of the incoming frames. To enable this kind of analysis a loopback is made on the fronthaul interface in order to recover the frames originally sent as shown in Figure 4.7 on the right.

Figure 4.7 Experimental setup for latency measurement on the fronthaul interface for the upper-PHY split

The two methods described in Section 3.1.3 to map the incoming frames to FEC blocks, namely the latency-optimized and the overhead-optimized has been tested and the results are shown in Figure 4.8 and Figure 4.10 respectively. The processing latency is depicted as a function of the input (backhaul) traffic throughput for different input frame lengths. The measured latency includes both the downlink and the uplink processing at the DU site. The values shown in the following figures are the average of all individual latency values measured by the protocol analyser during the tests.

Figure 4.8 Processing latency at the DU for an latency-optimized mapping to FEC blocks

Figure 4.8 shows the processing latency at the DU when the latency-optimized mapping method is used, where idle data are used to complete FEC blocks when no user data are available. The high


Page 75 of 110


peak in the latency occurs at very high data rates, around 9 Gbps input traffic, when the system is overloaded and flow control mechanisms, according the IEEE 802.3x standard, have to be applied to regulate the input data throughput and not incur in data corruption due to an overrun or underrun.

The regulation of the input data throughput with flow control mechanisms uses the support of an input buffer and two flags to indicate when the buffer is, for example, three-quarters full and the other to indicate when it is almost empty with, for example, only a quarter of the capacity used. When the almost full flag activates, a request is sent to the traffic source to stop the transmission of Ethernet frames. When the data on the buffer reduces so that the almost empty flag activates, another request is sent to resume the Ethernet transmission. With this mechanism, the frames contained in the buffer experience a processing latency proportional, not only to the buffer size but also to the value of the empty threshold which regulates the flow control process. In Figure 4.10 similar peak latency values can be observed, since the same buffer is used for both measurements, independently from the method used to map the information to FEC blocks.

Figure 4.9 shows an amplification of the range where the processing latency is influenced by the chosen mapping method, in this case the latency-optimized.

Figure 4.9 Zoom of the processing latency at the DU in the range from 0 to 30 µs for an overhead-optimized

mapping to FEC blocks

For every frame size, the same behaviour can be identified in Figure 4.9, namely the latency takes two values. The first latency value at lower data rates corresponds to the scenario where the frame gaps are big enough so that one frame is mapped to a single FEC block. In this case only an FEC block has to be decoded in the uplink to recover the original frame. As the frame gap becomes smaller because the data throughput increases, at some point the frames start to be split in two FEC blocks. This generates the second and higher value in the average latency. In this case, in the uplink, two FEC blocks have to be decoded before the original frame can be recovered. The first latency value is greater for longer frames because the processing time is proportional to the frame length. The


Page 76 of 110


increment in the average latency at higher data rates occurs later (at higher input traffic) for larger frames since the frame gaps reduce more slowly than for small packet as the input traffic increases.

Figure 4.10 Processing latency at the DU for an overhear-optimized mapping to FEC blocks

Figure 4.10 shows the processing latency at the DU when the overhead-optimized mapping method is used, where only user data are used to complete the FEC blocks. The high peak in the latency occurs at very high data rates, around 9 Gbps input traffic, when the system is overloaded and flow control mechanisms are applied as explained before.

Figure 4.11 shows an amplification of the range where the processing latency is influenced by the chosen mapping method, in this case the overhead-optimized.


Page 77 of 110


Figure 4.11 Zoom of the processing latency at the DU in the range from 0 to 30 µs for an overhead-optimized mapping to FEC blocks

For every frame size the same behaviour can be identified in Figure 4.11, namely that the average latency decreases as the input throughput increases. Since only user data are mapped to the FEC blocks, the time required to fulfil a single FEC block decreases as the frame gaps become shorter at higher data throughput. For a given input data throughput the average latency increases with the frame size due to two factors; one is the higher processing time associated to a larger length and the other is the greater inter-frame gaps for larger frames to generate the same average throughput.

The results from Figure 4.9 and Figure 4.11 show as expected that for lower input data throughputs the average latency is lower for the latency-optimized method. However, the smaller the frame length, the sooner the overhead-optimized method results in lower average latency values. Nevertheless, for large frame length (1024 or 1518 byte long frames) the range where the overhead-optimized method achieves better average latency values than the latency-optimized grows smaller.

Figure 4.12 shows the effect of the input buffering size on the processing latency at the DU under an overload situation when flow control mechanisms have to be applied as described at the beginning of this section. For this test the worst case scenario was chosen, namely the maximum achievable input throughput for 1518 byte long frames. Different buffer sizes were tested and for every size the threshold for activating the flags were proportionally set (three quarters for almost full, one quarter for almost empty).


Page 78 of 110


Figure 4.12 Processing latency at DU depending on input buffer size

Figure 4.12 shows that the average latency reduces with the buffer size. However, the size of the buffer cannot be designed just to achieve the lowest latency possible since the rest of the network strongly affects the dimensioning of this buffer. The size does also have an impact on packet loss and data corruption if the size is insufficient.

Additionally, Figure 4.13 shows the effects of the almost empty threshold on the latency. For these measurements the largest buffer size measured in the previous test, approximately 128 kB (16k words x 8 byte/word) deep, was chosen. The almost empty threshold limit was changed from the original one quarter full to lower values. Again the worst case scenario was chosen where 1518 byte frames are transmitted at a load of 100%.

Figure 4.13 Processing latency at the DU depending on input buffer characteristics


Page 79 of 110


In Figure 4.13, it can be observed how the processing latency decreases when the empty threshold is reduced and how at very low values it remains at an approximately constant value even though the threshold still decreases. As explained above, the flow control process is characterized by two moments; first when the almost full threshold is exceeded and the traffic source is requested to stop and second when the almost empty threshold is exceeded and the traffic source is requested to resume the Ethernet transmission. As the almost empty threshold reduces, less and less words remain in the buffer when the source is requested to continue with the Ethernet transmission reducing on average the time required to process the remaining samples in the buffer. At a certain level, the buffer will actually empty and it will then be unable to further reduce the latency since no frames are available to be processed. In this case we obtain the minimum latency for the given buffer size, and almost full threshold. However, in an efficiently designed system the buffer should not go empty, especially if the line is 100% loaded.

This first evaluation of the evolved DU in terms of latency has shown not only how much latency in the fronthaul is caused by processing at the DU but also which are the main aspects in terms of implementation that significantly contribute to those values. Currently, the implementation of the evolved remote unit is taking place. Apart from some refinement in the mapping process into FEC blocks, also in the DU, a more accurate evaluation of the fronthaul performance will be performed once both evolved digital and remote units are implemented. However, this preliminary evaluation in terms of latency shows how much of the available latency budget as discussed in Section 2 is already consumed by the active equipment. With a target of maximal round-trip-delay up to 440 µs, a typical latency between 10 to 20 µs at the DU let enough margin for the optical transmission (typically 100 µs for 20 km) and the processing at the RU and the network equipment. Nevertheless, further tests are required.

4.3. Timing and synchronization The following paragraphs contrast the approaches for timing and synchronization (physical layer based (SyncE), packet based (IEEE 1588), packet based (IEEE 802.1AS)) described in Section 3.2.

The physical layer based SyncE approach, as the name says works solely with the physical layer. Layer 2 or higher protocol layers are not involved. The consequence of this is that only pure frequency synchronization is possible since no information about packets and their propagation delay is available and retrievable. Since the physical layer based SyncE approach is chained, all devices in the chain must be compatible. SyncE can fulfil the stringent frequency requirements of SONET/SDH (+/- 4.6 ppm for Stratum 3 & 3E) [59]. For this case, it is faster and more precise than IEEE 1588 and IEEE 802.1AS approaches. Moreover, SyncE can be up to factor 100 better than the packet-based approaches [60] [61]. From this perspective the requirements stated in Section 2.9 will be challenging to achieve.

The packet based IEEE1588 approach is based on packets. It can make use of layer 2 (MAC layer) or layer 3+ protocols like UDP/IP, but layer 1 functionality is not involved. Since information about packets and their propagation is available, synchronization of frequency, phase and time is possible. IEEE 1588 does not require that all devices in the network path must be compatible with IEEE 1588. However, the precision will be higher, since mechanisms like transparent clocks determining the


Page 80 of 110


residence time of a packet within a bridge element can be used. One disadvantage is that this approach is sensitive to packet delay variation and packet delay asymmetry. The achievable precision for phase and time alignment is usually below 1 µs, if transparent clock mechanisms are applied [59] [62]. 500 ns are achievable with Cisco Nexsus 3000 switches [63]. In special cases, 100 ns to 20 ns are possible [64] [65]. Therefore, meeting the requirements in Section 2.9 will be difficult.

The packet based IEEE 802.1AS approach uses layer 2 (MAC layer) packets without requiring layer 1 functionality. Like IEEE 1588, synchronization of frequency, phase and time is possible. In contrast to IEEE 1588, all network devices must be compatible to IEEE 802.1AS. In addition to IEEE 1588, IEEE 802.1AS defines additional formal interface definitions for time-aware applications. Like all packet based approaches, IEEE 802.1AS is also sensitive to packet delay variation and packet delay asymmetry. The achievable accuracy for phase and time synchronization is below 1 µs [62]. Precision below 500 ns is possible [66] [67].

Table 4.3 summarizes the contrasting of these three approaches.

Table 4.3 Contrasting of the physical layer based (SyncE), packet based (IEEE 1588), and packet based (IEEE 802.1AS) approaches

Physical layer based (SyncE)

Packet based (IEEE 1588)

Packet based (IEEE 802.1AS)

-only Layer 1; Layer 2 is not involved -only frequency sync -all devices must be compatible -can fulfil SONET/SDH requirements (+/- 4.6 ppm) -faster and more precise than packet-base (up to factor 100 better than packet-based solutions)

-uses packets (Layer 2(MAC) or Layer 3+ UDP/IP); Layer 1 is not involved -frequency sync, phase sync and time sync -not all devices in the network must be compatible (but more accurate) -sensitive to packet delay variation and asymmetry -sub µs phase alignment accuracy possible (with transparent clock mechanism) --< 500 ns, 20-100 ns possible

-uses packets (Layer 2(MAC); Layer 1 is not involved -frequency sync, phase sync and time sync -all devices must be compatible -includes additional formal interface definitions for time-aware applications -sensitive to packet delay variation and asymmetry -sub µs phase alignment accuracy possible --< 500 ns possible

A further consideration targets the interoperability and multiple timing domains. Usually it is considered that one network operator fully owns and operates a network. If we assume that a network is partitioned, for example there is a core network operator and an access network operator, the packet-based and the physical layer approaches come with additional advantages and disadvantages. A physical layer approach like SyncE requires that all network elements operate with the same frequency resulting that an access network provider and a core network provide would have to agree on this frequency. In contrast to this, a packet-based approach would allow multiple


Page 81 of 110


timing domains separated at the demarcation point. On this basis, separated timing domains or hierarchies would be possible.

Packet delay variation and packet delay asymmetry are inherent issues for packet based synchronization approaches. The following paragraph will outline approaches mitigating these issues:

• Minimizing delay asymmetry by design • IEEE 1588 mechanisms • QoS means • Delay equalization • Averaging of sync messages • Ranging mechanisms • Calibration by external means

The first approach against packet delay variation and packet delay asymmetry is the minimization of the delay asymmetry by design. An example for this is the use of the same fibre for uplink and downlink.

Another approach is the application of the optional IEEE 1588 means (cf. [68]). Boundary clocks can be used to mitigate the packet delay variation by other interfering sync packets by partitioning of large networks. Using transparent clocks mitigates the variation induced by the residence time of a sync packet within a network bridge device by additional input and output timestamping.

A further approach is applying available quality of service means. One example is the prioritizing of time synchronization packets by IEEE 802.1Q priority-based scheduling [68]. Another promising approach is the reservation of timeslots for time synchronization packets within a protected and scheduled section in a periodic time window using time-sensitive networking means like 802.1Qbv.

Delay equalization is another approach [68]. This is used for ATM and IEEE 1588. Packets are tagged with timestamps to help to balance packet delay variation for related input data by output data buffering.

The next approach is the averaging of sync messages. This means the mean value is calculated to balance the variation of sync packets [68].

Ranging mechanisms are further approaches. Algorithms try to filter or select the sync packets, which experience the minimum packet delay within an observed window [69] [70].

Another approach is the calibration by external means like the Assisted Partial Timing Support (APTS). APTS uses an additional GPS receiver at the remote radio head or radio base station to compensate a network where not all network elements are time synchronized (cf. Figure 4.14).


Page 82 of 110


Figure 4.14: Assisted Partial Timing Support (APTS).

4.4. Timing-sensitive Ethernet switching / aggregation Section 4.4.1 describes the findings of the investigation of the mechanisms for time-sensitive networking depicted in Section 3.3.1 whereas Section 4.4.2 reports the experimental set-ups that have been implemented for monitoring different KPIs and the associated results.

4.4.1. Time-sensitive networking methods For mobile fronthaul, the minimum remedies for time-sensitive networking would be:

• Time synchronization • Queuing and forwarding

For time synchronization, time-sensitive networking offers IEEE 802.1AS. IEEE 1588 is also possible. Since IEEE 802.1AS is essentially not deployed in telecoms, the preference is IEEE 1588. Almost all currently applied configurations for time synchronization use a combination of IEEE 1588 and SyncE for accuracy reasons. Therefore, it depends on the distinct setup whether the precision of the combination is preferred over the flexibility (multiple timing domains/hierarchies) of a packet-based IEEE 1588 approach.

Regarding the queuing and forwarding mechanisms, the most important part is IEEE P802.1Qbv time-aware shaping. For the iCIRRUS mobile fronthaul this is the most important part. Since IEEE P802.1Qbv time-aware shaping bases on IEEE 802.1Qav credit-based shaping, IEEE 802.1Qav is also required.

The other parts for queuing and forwarding, registration and reservation or reliability and redundancy are potential extensions for further enhancements.


Page 83 of 110


For queuing and forwarding, IEEE P802.1Qbu frame pre-emption reduces the guard band and increases efficiency in terms of throughput. In addition, IEEE P802.1Qch cyclic forwarding and queueing makes the latency calculation independent of the topology, which is interesting for bigger networking scenarios.

The means for registration and reservation like the IEEE 802.1Qat Stream reservation protocol or its extension –the IEEE P802.1Qcc enhanced stream reservation protocol allows a standardized management of the resources (for example allocation of time slots). This is in particular interesting for larger networks, where simple proprietary mechanisms are no longer sufficient.

For scenarios where an improved reliability (for example a very low FLR is required, mechanisms like IEEE P802.1Qci per-stream filtering and policing (input gating) or in particular IEEE P802.1CB seamless redundancy can be taken into account.

4.4.2. Delay variation measurements Several testbed set-ups for monitoring different KPIs have been implemented. Although similar in their implementation, they require different processing according to the KPI that is being monitored. The KPIs include, frame inter-arrival delay [71], [72], frame delay variation (FDV), fronthaul latency [73] and fronthaul utilisation. Additionally, OTA performance (throughput, HARQ re-transmissions) can be monitored and related to the traffic conditions in the fronthaul. Note that the testbeds and processing are applicable to both fronthaul types (legacy and evolved).

4.4.2.1. Frame inter-arrival delay Figure 4.15 shows the testbed used for the measurement procedure. A workstation runs an emulated LTE base station (Amari LTE-100, or the OAI softmodem) that produces IQ samples corresponding to a 5 MHz channel BW (sampling rate of 6.25 MHz). The samples are then inserted into the payload section of a UDP packet and transmitted over a pure layer 2 network. The network comprises of two 3COM-5500G Ethernet switches with standard 1000BASE-LX SFP transceivers with LC connectors and Single Mode Fibre (SMF) patch-cords. The stream of packets containing the IQ samples is received by an Ettus N210 RRH where, following Ethernet processing, the samples are de-quantised and sent to a DAC. Following the DAC, they pass through a digital modulator for DC offset correction and are then up-converted to one of the LTE bands and amplified prior to transmission over the wireless channel. In the uplink the reverse processes take place.

An additional workstation is used to generate background traffic of variable payload sizes and at variable data rates, using an open-source Linux-based traffic generator (Ostinato). The two streams of traffic are logically separated using two different VLAN IDs (through the switch port i.e. a port-based VLAN configuration). The link between the two switches forms a trunk that allows the pair of VLAN IDs to pass through. As both VLAN IDs will be transmitted through the same port there will be traffic contention.


Page 84 of 110


The LTE traffic is captured using a Viavi in-line Ethernet probe that comes in the form of a 1000BASE-LX SFP. A filter is applied that instructs the probe logic to capture all packet headers containing the destination MAC address and destination UDP port of the RRH. Once captured, the headers are timestamped (using a propriety form of PTP) and re-encapsulated (with the discovered network encapsulation), and with an additional Viavi proprietary header that includes the timestamp (in addition to other metadata fields). The captured packet headers are re-injected into the network as frame result packets (FRPs) and sent to a packet routing engine (PRE) which routes them to a management station for further processing. The PRE also serves as the timing reference source for the probes.

Figure 4.15 Testbed used for the measurement procedure. PRE=Packet Routing Engine, GbE=Gigabit Ethernet, SFP=Small Form-factor Pluggable

Figure 4.16 shows the algorithm used for obtaining the delay statistics. What is important here is that replicated or missing SFP injection numbers are treated properly. For these measurements, the algorithm looks for these conditions and ignores (pairwise) delay values with corresponding injection numbers that re not in-sequence.


Page 85 of 110


Figure 4.16 Algorithm used for the frame inter-arrival delay measurements

Figure 4.17 (A) shows that under a weighted round robin (WRR) scheme, increasing the weight of the background traffic causes the mean and standard deviation (std) of the LTE stream delay to increase by approximately 2.6% and 13.7% on average respectively, for each weight increase. The increase for higher data rates is a result of the corresponding increase in the frame transmission rate of the background traffic which will cause the background traffic queue to be filled more often (note that the traffic source is bursty). The increase among the different weight combinations for each data rate is simply a result of allocating more resources to the background traffic. Figure 4.17 (B) shows a comparison between different frame sizes with background traffic data rate of 215 Mbps. The results show that using larger frame sizes in the background traffic will lead to an increase in the mean and std of the inter-arrival delay (compared to using smaller frame sizes) for all WRR weight combinations and all background traffic data rates (although not shown in this figure). This can be explained since larger frames require a longer time to be serialized out of the trunk port and as a result occupy the channel for longer time.


Page 86 of 110


Figure 4.17 Comparison for mean and std of frame inter-arrival delays of the LTE traffic for different WRR weights for A) different background traffic data rates for a frame size of 1500 bytes and B) different

background traffic frame sizes at a data rate 215 Mbps. The “LTE” trace corresponds to transmitting only the LTE traffic (i.e. no background traffic)

Figure 4.18 (A) shows the results for a strict priority (SP) scheduler for different frame sizes and two different data rates for each frame size, while Figure 4.18 (B) shows the corresponding complementary cumulative distribution functions (CCDFs). The results show that with SP, using larger frame sizes will cause a small reduction in the mean frame inter-arrival delay but will lead to a higher std. This behaviour can be explained using Figure 4.18 (B) as follows: when a background traffic frame is being serialized out of the switch port while a new LTE frame arrives in the queue (which until that point was unoccupied), the time that the LTE frame will have to wait, until the serialisation of the other frame is complete, will be higher for larger background frame sizes (and bounded by one background frame serialisation delay), resulting in an increase in the std. The mean value on the other hand reduces, as with larger background frame sizes the occurrence of such an event is less likely (as the packet transmission rate is reduced). These results clearly show the effects of lack of pre-emption (that is the interruption of a lower priority frame by higher priority traffic) in this set-up.


Page 87 of 110


Figure 4.18 Mean and std of frame inter-arrival delays of the LTE traffic under SP regime for A) different Frame sizes and background traffic data rates (105 Mbps, 450Mbps). B) CCDFs of the results in A)

The difference between using no-priority (i.e. a single queue) and WRR with equal-weights (i.e. two queues with equal priority) can also be investigated. These two special cases are important for two reasons: with many different types of traffic streams potentially being transported through the fronthaul, there may be cases where two streams have equal (or approximately equal) weight definitions. Additionally, there are only a limited number of priority definitions at layer 2 which means that different streams may need to be accommodated by the same queue. The results in Figure 4.19 (A) show that using no priority in the network will cause higher mean delays than using two equal-weight queues for smaller frame sizes (not jumbo frame regimes) for both measured LTE traffic rates. On the other hand, the no-priority case will result in smaller mean delay than the equal-weights WRR case when using jumbo frames in the background traffic, for both LTE traffic rates (see Figure 4.19 (B)). Note that for the no-priority case the delay does not change considerably between the two frame sizes in Figure 4.19 (A) and Figure 4.19 (B). This is expected since a smaller frame size simply means that the traffic source will be transmitting a larger number of frames (in this case eight 500 byte frames instead of a single 4000 byte frame) over the same time interval. The delay of the equal-weight case in Figure 4.19 (A) remains very low in value even at higher data rates. Note that


Page 88 of 110


the delay here is bounded by the sum of the serialisation delays of the two traffic sources (approx. 36.4 µs) but the mean delay will also depend on how frequently frames from the two sources interact in the port (i.e. how often both queues are filled due to the bursty nature of the sources). Obviously, there is a clear increase in the delay for higher frame sizes for the equal weight case as now the serialisation time of each background frame will be higher (by a factor of eight in this case).

Figure 4.19 Comparison for the mean of the frame inter-arrival delay of the LTE traffic for equal-weight (WRR4) and No-priority cases with different LTE traffic BWs and different background traffic data rates with frame

sizes A) 500 Bytes and B) 4000 Bytes. The “LTE” trace corresponds to transmitting only the LTE traffic (i.e. no background traffic)

4.4.2.2. Frame delay variation and fronthaul latency Figure 4.20 (a) shows the testbed used for the FDV measurements. The difference between this testbed and the one in Figure 4.15 is the addition of another probe so that latency (and FDV) measurements can be carried out. Additional fields, which include the SFP probe ID and FRP injection number, are used as inputs to the algorithm for calculating the FDV. A flow chart for the algorithm implemented in Matlab is shown in Figure 4.21 (a). Results are obtained from the management station through a Wireshark capture of the FRP frames (step a). Within the FRP frames, sending and receiving IP addresses correspond to the eNodeB and RRH (and not to the management station and PRE). As there is no guarantee that the PRE will route FRPs to the management station in a specific order, the timestamps need to be ordered according to which probe they came from (step b). Additionally, the range and values of the injection numbers across the two probes may not be the same. Therefore these have to be normalised to start at the same value (step c). The algorithm looks


Page 89 of 110


for missing injection numbers, for example, due to dropped packets or captures that were not injected back in-line due to congestion and removes the equivalent injection number for the other probe (step d). Then, transit delays are calculated by subtracting timestamps corresponding to the equivalent injection numbers of the two probes (step e). The FDV is then found as the absolute value of the difference between one transit delay and the next (i.e. across successive transit delay values). The final step is the calculation of the histograms (step g).

Figure 4.20 (a) A Test-bed for FDV measurements and (b) Delay asymmetry issue due to contention of PTP timing messages with in-line traffic. GbE=Gigabit Ethernet, DSP=Digital Signal Processing, RF=Radio Frequency

Figure 4.21 (a) Flow-chart of Matlab algorithm and (b) Dealing with uncertainty of timestamping

Delay asymmetry is a result of contention of the PTP timing messages with the in-line traffic (which in this case, is the traffic the probes are capturing). Figure 4.20 (b) is used to describe the problem for this specific set-up in more detail. PTP protocol assumes no path delay asymmetry between downlink and uplink paths. It estimates the timestamps by two-way delay measurements. If there is delay asymmetry, then every time the timestamps are updated, there will be an offset in the timestamp of each probe by one-half of the asymmetry. More importantly, though, the asymmetries between the two paths (from PRE to the two probes and back) will be different. Referring to Figure 4.20 (b), in the PTP downlink direction there will be contention in the switch port, while in the PTP uplink direction there will be contention at the probe itself (the probe waits for a gap in transmission to inject it’s timing response message).


Page 90 of 110


Further steps shown in Figure 4.21 (b), are added to the algorithm described in Figure 4.21 (a), between steps e and f. Long-term averaging for the measured delay is carried out, and from this, a long-term average of the fabric delay (if the probing includes both switches, this will be the sum of the fabric delays of the two switches) is obtained. Delay values that are higher or lower than the long term average by 10% of the average fabric delay, are ignored.

As a demonstration, the FDV is measured at two different locations within the testbed, but both include a VLAN trunk. Figure 4.22 shows part of a delay and corresponding FDV measurement. The long-term average discussed in the previous section is indicated through the solid red line.

Figure 4.23 (a) is a complementary-cumulative distribution function (CCDF) for the FDV. The three traces show that the FDV statistics do not vary significantly with sample size (number of captured Ethernet frames). The mean FDV was measured as 52.9 ns while the standard deviation was measured as 53 ns.

Figure 4.22 Delay (fronthaul latency) and FDV measurements. Note that this is a concatenation of a number of measurement results

Figure 4.23 (b) is a similar measurement but with the second probe at the output of the second switch. This end-to-end measurement now includes the effects of both switches across the trunk. The mean and std values are worse than in the single switch case. The mean was measured as 55.7 ns while the std as 60.1 ns.

(a)


Page 91 of 110


Figure 4.23 (a) CCDF of FDV from a measurement across the first switch. Mean=52.9, std=53 and (b) CCDF of FDV from end-to-end measurements. Mean=55.7 ns, std=60.1 ns

4.4.2.3. Background traffic and its effects on HARQ re-transmissions When inter-frame delays in the fronthaul are such that the inter-slice delays are longer than Ts (the LTE OFDM symbol duration), then HARQ re-transmissions will be generated. This is explained in Figure 4.24. When two traffic streams have to be output over the same Trunk port, the switch scheduler will attempt to balance the output traffic by inserting a number of background traffic frames in the output queue. These frames, depending on their length, can lead to inter-slice delays that are longer than Ts. The occurrence of this can be measured with the smart probes (statistically) and related to the amount of HARQ re-transmissions (employing the timestamps generated by PTP).

Figure 4.24 A background traffic frame is inserted in the switch port queue in-between LTE-carrying frames

The measured effects on HARQ re-transmissions of the background traffic, is shown in Figure 4.25 for different data rates and packet sizes. Note that the increase with data rate in Figure 4.25 (a) is linear. These results are for bursty background traffic and it is this bursty nature that can lead to larger numbers of retransmissions (as the occurrence of inter-slice delays larger than Ts will be higher within one TTI, as compared to a constant frame rate traffic source at the same data rate). Thus, it is important in the evolved fronthaul where traffic sources will be bursty (from Splits I or MAC-PHY, for the C&M channel, etc.) that the measuring window (or the averaging) is carried out over time scales that can properly measure the bursty characteristics of the sources.

(b)


Page 92 of 110


Figure 4.25 Effect of background traffic on HARQ re-transmissions. (a) re-transmissions versus data rate and (b) re-transmissions versus packet size


Page 93 of 110


5. Further architectural considerations The combination of Ethernet with a modification to the functional split in the iCIRRUS evolved fronthaul has significant potential in itself to improve efficiency and reduce costs. The key enablers for its realization have been presented in Section 3 and preliminary analyses have been presented in Section 4 aiming to validate the feasibility in achieving the fronthaul requirements addressed in Section 2. Nevertheless, it is also necessary to review other architectural aspects such the scalability and adaptability of the iCIRRUS architecture or its structural convergence. Since the introduction of Ethernet also enables the use of monitoring and management capabilities in the fronthaul, the potential of new SLA monitoring and SON concepts should also be addressed. Deeper in the physical layer, new transmission schemes will be investigated to deliver the huge aggregated data rates expected in the fronthaul (see Section 2.1) in a low-cost manner.

5.1. Transmission network Before discussing the further architecture of the transmission network attached to RAN, we begin by presenting the existing backhaul architecture. Figure 5.1 shows this Ethernet architecture which is based on PtP (Point to Point) topology using switches or routers to achieve traffic aggregation from different BBU mobile technologies (2G, 3G and 4G). PtMP (Point to MultiPoint) could also be used to achieve this transmission network (e.g. G-PON) but it is not so common. Presently, operators prefer PtP Ethernet topology and equipment.

Figure 5.1 Existing backhaul architecture

Now, we consider the further RAN architecture and we focus our interest on transmission network. We propose Figure 5.2 to resume the different architectures trends based on fronthaul (e.g. CPRI) and modified functional split. The first item of this description is CPRI which could be encapsulated over an Ethernet frame. Due to the latency issue this network segment is limited to 15km. For this reason, we propose here two descriptions with BBU pool located either in master Central Office (CO) or in local CO plus a regular backhaul to reach the master CO. The fronthaul segment is composed of different CPRI links between all the RRHs at the antenna site and the BBU pool. The second item of this further RAN architecture considers the modified functional split. To transport this new functional split interfaces, the Ethernet network might be located i) between the local CO to the central CO based one the aggregated traffic of the L1/L2 BBU pool, and ii) between cell site aggregator (gateway) of several iRRHs (intelligent RRH with L1/L2) to master CO equipped with vBBU pool as shown in Figure 5.2.


Page 94 of 110


Figure 5.2 Possible scenarios based on RAN evolution

5.2. Scalability and adaptability The network scalability is a driver that operators are looking from to secure the investment of infrastructure (fibre) and equipment. Infrastructure is the main important item because this part drives most of CAPEX cost. Scalable equipment is also required for 5G to follow what was already done by existing and past Ethernet backhaul to support 2G, 3G and 4G. Concerning the time aspect of scalability, if a new RAN generation is proposed with a time cycle about 5 years, the renewal of transmission network follows a slow timing about 10 years or more.

In term of bit rate scalability of the Ethernet transmission, we have to consider the bit rate evolution of CPRI, compressed CPRI and functional split interface which could be framed over an Ethernet frame. Figure 5.3 shows this possible evolution.


Page 95 of 110


Figure 5.3 Bit rate evolution of CPRI and CPRI compressed per RRH and aggregated traffic of new functional split at antenna site

In association with bit rate scalability, other linked items need also to be supported by this scalable Ethernet transmission network: synchronisation, bit error rate (packet loss), latency control.

5.3. Structural convergence The first driver of the structural convergence will be the feasibility for the Ethernet transmission system to support either backhaul or fronthaul (existing CPRI interface or new functional split). The fact that fibre will be the preferred medium for either backhaul and fronthaul for 5G, a structural convergence could be proposed with FTTx deployment based on:

• fibre cable infrastructure: due to the modularity of fibre cable, there are always supernumerary fibres. This available fibre could be dedicated to an Ethernet X-haul network,

• optical distribution network: most of FTTx deployments are based on time division multiplexing (TDM) and time division multiple access (TDMA) passive optical network (PON) (e.g. G-PON) using a power splitter optical distribution network (ODN). This optical distribution network is and will be present at most of antenna location. The wavelength overlay allows sharing the same ODN with different PON systems. One of these overlay systems could be dedicated to the Ethernet X-haul network (e.g. TWDM(A) or PtP Wavelength Division Multiplexing (WDM) PON ITU-T G.989),

• reserved BW allocation of the TDM/TDMA PON system: this solution authorizes TDM/TDMA PON system to share the BW and the ODN between different customers including the Ethernet backhaul or fronthaul. In other words, this solution uses a structural convergence over OLT (Optical Line Termination) port,

• the last structural convergence is the feasibility to use the same shelf equipment to host transmission interfaces dedicated to either residential or mobile customers. This shelf


Page 96 of 110


equipment could be a MultiService Access Node (MSAN) which supports various transmission cards like: optical PtP, G-PON, XG-PON1, WDM PON, xDSL, POTS, etc. In this use case, the back plane of the shelf will be the structural convergence element.

5.4. SLA monitoring and SON concepts A service level agreement (SLA) describes “the level of service expected by a customer from a supplier, laying out the metrics by which that service is measured, and the remedies or penalties, if any, should the agreed-upon levels not be achieved. Usually, SLAs are between companies and external suppliers,” [74]; as such, it is a very general construct applicable to many domains.

However, our primary concern in T3.3, which deals with the SLA Monitoring and SON Concept for the converged fronthaul architecture, is with in defining or updating the part of the SLA that relates to technical performance metrics and associated measurement methodologies on the fronthaul that arise as a consequence of the architectural modifications under investigation within iCIRRUS, namely,

• Introduction of an Ethernet-based fronthaul with a modified functional split and • Investigation of mobile cloud based components for supporting applications such as

application offload.

Conceptually, these performance metric measurements will, together with other available data such as RF signal quality and application performance be collated by a performance management system, and form the input to the SON algorithm that will dynamically determine the choice of network configurations and associated parameter settings. Subsequently, the configurations will be autonomously deployed in the network through coordinated action by the network management element controlling the radio access network (typically OMC / OSS) and the network management element controlling the access network (typically SDN controller).

5.4.1. SLA monitoring for next generation fronthaul The focus of the investigation for the new fronthaul will be on both choice / definition of fronthaul SLA metrics required by introduction of Ethernet and also on means to measure them. In contrast to CPRI, the fronthaul data is no-longer monolithic but comprises data streams with different performance requirements as addressed in Section 2. Furthermore, impairments to each data stream have varying impact scope, e.g. subscriber, cell, cell cluster and potentially out of band emissions / non-compliance to standard’s requirements, etc. The data streams carried on the fronthaul are expected to include PTP synchronization data, fronthaul user data, fronthaul control data (e.g. for setup and path switching), L2/L3 control primitives (exchanged between the functions now separated by the fronthaul), and potentially X2 data exchanged between eNodeBs.

The work will investigate development of customised probes to monitor fronthaul performance considering both hardware probes and probes virtualized within the switch fabric. The probes will be adapted to the frame structure adopted for the fronthaul by iCIRRUS as discussed in Section 3.1.


Page 97 of 110


Measurements will include packet loss, packet delay and packet delay variation. Measurement methodologies based on synthetic traffic and also labelling and of monitoring live traffic will be investigated. The verification of PTP operation and potentially performance analysis of PTP will also be addressed.

The existing methodologies for Ethernet functionality test and performance management including RFC 2544, ITU-T Y.1564 and ITU-T Y.1731 will be reviewed for suitability / applicability and possible need for extension / enhancement.

5.4.2. SLA monitoring for mobile cloud based components The introduction of network function virtualisation (NFV) into mobile networks creates a need to measure the performance and resource consumption of the virtualised function and thence to provide a SON function to autonomously optimise overall performance.

iCIRRUS is investigating cloud based components and as a means to investigate these concepts and potential use cases that are being considered include mobile application offload to the cloud and potentially enterprise storage / identity.

The Quality of Experience (QoE) / QoS metrics that will form the basis of performance evaluation of mobile cloud operation are being investigated within iCIRRUS WP4, as will be potential methodologies for measuring associated performance metrics. However, within the scope of T3.3, which deals with the SLA monitoring and SON concept for the converged fronthaul architecture, the influence of the fronthaul performance on the ability to support mobile cloud operation is relevant for investigation.

5.5. Low-cost high-speed transmission techniques In Section 2.1 the expected data rates that will be supported by the fronthaul network have been analysed. In order to deliver a low-cost yet scalable Ethernet-based fronthaul network beyond 100 Gbps, suitable transmission methods will be investigated. The state of the art in data centre developments will be closely observed since some of the requirements are similar to those of the evolved fronthaul, namely the high data rates, the low latency or the low cost, whether other such as synchronization may differ.

The focus of this investigation will be set on intensity modulation (IM) and direct detection (DD) schemes since they employ low cost optical components, and on fibre link lengths going from 1 to tens of km. Two different approaches will be considered.

On the one hand, current IEEE work (e.g. [75]) will be monitored and evaluated with respect to its potential to share common building blocks and thus benefit from the ecosystem of a standardized solution (e.g. the 400GBASE-LR8 interface employing 8 wavelengths of 53.25 Gbps each and PAM4 modulation in the 1300 nm region). In addition, alternatives are investigated that would allow to increase the data rate per wavelength to 100 Gbps. The most interesting candidates for this


Page 98 of 110


approach are PAM4 with a baud rate of 50 GBd and more complex DSP to cope for the limited bandwidth of low-cost components, and DMT (Discrete Multitone) with a potential benefit of a higher dispersion tolerance. On the other hand, a more disruptive approach will be investigated to achieve more than 100 Gbps also over a single wavelength. The transmission rate in short-range transmission systems is mainly limited by the bandwidth BW of low-cost optical components or the bandwidth and bit resolution of high-speed DACs and ADCs, required for higher modulation formats. Since commercially available optical components present greater bandwidths (> 40 GHz) than commercially available converters (DAC ~ 30 GHz), in order to increase the total signal bandwidth at the transmitter and the receiver, the use of electrical up and down mixing and signal combining with baseband signals is proposed [76] and will be further investigated.

Additionally, not only is attention being paid to the high-speed and low-cost requirements, but also to energy efficiency in the fronthaul network. To that end, we have been considering how the iCIRRUS architecture can be adapted to offer a low-power, low-cost and high-speed 5G transmission solution. Figure 5.4 below shows a possible scenario, with a 60-GHz wireless link between the RRH and Base Station, offering multi-Gbps fronthaul capacity over 802.11ad. Such a wireless fronthaul approach offers cost savings from not needing wireline (i.e. optical fibre) infrastructure with its associated high CapEx trenching costs. In addition, a stand-alone RRH (i.e. not physically tethered by cabling to the main infrastructure) is also obligated to exploit renewable energy sources (e.g. solar and wind, etc.) for its powering requirements, and so additionally reduce its carbon footprint. Compact millimetre-wave (mmWave) technologies with their high throughput capacities, directivity, and advanced modulation formats also offer additional spectral and energy efficiency savings, such that the overall architecture represents a highly efficient 5G solution.

Figure 5.4 Possible modified iCIRRUS fronthaul architecture for low-cost, low-energy, high-speed transmission

Wireless mmWave device-to-infrastructure (D2I) functionality (i.e. tablets/smartphones to the RRH) is also possible, with multi-Gbps speeds offered for the various network links by link aggregation (i.e. multiple RRH to Base Station connections, and also aggregation of the BS links, as indicated in the


Page 99 of 110


figure). This gives the flexibility of either having aggregated bandwidth or redundancy in the various D2D, D2I, and fronthaul scenarios. The findings of all these investigations will therefore help to refine the iCIRRUS fronthaul architecture as presented here in a future deliverable.


Page 100 of 110


6. Conclusions A preliminary fronthaul architecture has been proposed to meet the increasing performance requirements of 5G (and beyond) mobile networks in a cost effective manner. This intelligent architecture combines Ethernet as a transport protocol with the modification to the functional split to reduce data rates in the fronthaul while making statistical multiplexing gains possible, and thus allows a more efficient use of the network resources. The intelligence in the proposed fronthaul will assist in the provision of further services such as network-assisted D2D communications and mobile cloud networking at the network edge.

Ethernet has achieved near ubiquity in access networks, with widely deployed and understood OAM capabilities and wide multi-vendor interoperability on a variety of media and at a number of line speeds. In order to deliver an accurate synchronization over an Ethernet-based mobile fronthaul, standardised and widely adopted solutions are proposed for iCIRRUS. Solutions to the potential problems of latency and latency variations are being actively addressed by research and standardisation activities, especially by the time-sensitive networking group and the required methods have been identified to deliver an accurate synchronization.

Since the fronthaul has evolved from a hidden and semi-proprietary interface, establishing concrete KPIs becomes challenging, especially in terms of synchronization accuracy, latency and latency variations and also especially for the traffic flows resulting from the modified functional split points. Nevertheless, this is being actively addressed by research and standardisation activities as reflected in this deliverable. Further work of iCIRRUS would be the verification of such requirements. It will be further experimentally investigated, on the one hand, whether the proposed fronthaul architecture meets those requirements, and on the other hand, the range in which not yet determined requirements such as PDV should remain to guarantee the overall performance. Preliminary analyses within iCIRRUS have shown the potential feasibility of achieving the KPIs and where the challenges will reside towards the demonstration phase.

The combination of Ethernet and a modification to the functional split have significant potential to improve efficiency and reduce cost, to achieve maximum gains. However, it will be necessary to review some aspects of the wider network including the role of SLA monitoring and SON concepts or the new developments on short-range high-speed communications toward 400G. The architecture of the fronthaul network will be reviewed in iCIRRUS deliverable D3.4, while wider whole system architectural implications will be further studied in WP2. The work of WP5 will also be based on the findings of WP3 and WP4.


Page 101 of 110


References

[1] P. Chanclou, Z. Tayq, P. Turnbull, V. Jungnickel, L. Fernandez del Rosal, P. Assimakopoulos, N. Gomes, Y. Kai, H. Zhu, M. Parker, S. Walker, C. Magurawalage, K. Yang, H. Thomas, M. C. Torres, I. C. Rivera and F. J. H. Gonzales, “D2.1 iCIRRUS - Intelligent C-RAN Architecture,” 2015.

[2] P. Turnbull, H. Thomas, D. Venmani, P. Chanclou, V. Jungnickel, L. Fernandez del Rosal, M. Parker, P. Assimakopouluos, K. Kenan Al-Hares and N. Gomes, “D3.1 iCIRRUS - Verification of Ethernet as transport protocol for fronthaul / midhaul,” 2015.

[3] Metro Ethernet Forum, “MEF 22.1.1, Mobile Backhaul Phase 2, Amendment 1,” July 2014. [Online]. Available: https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_22.1.pdf. [Accessed 2016].

[4] China Mobile Research Institute, “White Paper of Next Generation Fronthaul Interface v1.0,” 2015.

[5] C.-L. I, y. Yuan, J. Huang, S. Ma, C. Cui and R. Duan, “Rethink Fronthaul for Soft RAN,” IEEE Communications Magazine, vol. 53, no. 9, pp. 82-88, 2015.

[6] U. Dötsch, M. Doll, H.-P. Mayer, F. Schaich, J. Segel and P. Sehier, “Quantitative Analysis of Split Base Station Processing and Determination of Advantegeous Architectures for LTE,” Bell Labs Technical Journal , vol. 18, no. 1, pp. 105-128, 2013.

[7] D. Wübben, P. Rost, J. Bartelt, M. Lalam, V. Savin, M. Gorgoglione, A. Dekorsy and G. Fettweis, “Benefits and impact of cloud computing on 5G signal processing,” IEEE Signal Processing Magazine, vol. 31, no. 6, pp. 35-44.

[8] P. Rost, C. Bernardos, A. D. Domenico, M. D. Girolamo, M. Lalam, A. Maeder, D. Sabella and D. Wübben, “Cloud technologies for flexible 5G radio access networks,” IEEE Communicatinos Magazine, vol. 52, no. 2, pp. 68-76.

[9] A. Maeder, M. Lalam, A. D. Domenico, E. Pateromichelakis, D. Wübben, J. Bartelt, R. Fritzsche and P. Rost, “Towards a flexible functional split for cloud-RAN networks,” in European Conference on Networks and Communications (EuCNC), 2014.

[10] T. Asai, “5G Radio Access Network and its Requirements on Mobile Optical Network,” in Internatinal Conference on Optical Network Design and Modeling, 2015.

[11] Small Cell Forum, “Small Cell Virtualization Functional Splits and Use Cases,” January 2016. [Online]. Available: http://scf.io/en/get_email.php?doc=159.

[12] V. Jungnickel, K. Manolakis, W. Zirwas, B. Panzner, V. Braun, M. Lossow, M. Sternad and R.


Page 102 of 110


Apelfröjd, “The role of small cells, coordinated multipoint, and massive MIMO in 5G,” Communications Magazine, IEEE, vol. 52, no. 5, pp. 44-51, 2014.

[13] C. Pan, Y. Kai, H. Zhu, L. Fernandez del Rosal, V. Jungnickel, S. Hadjitheophanous, P. Ritosa, G. Koczian and M. Parker, “Deliverable D4.2 - iCIRRUS UE D2D & D2I interfacing,” 2016.

[14] K. Wang, K. Yang and C. Magurawalage, “Joint Energy Minimization and Resource Allocation in C-RAN with Mobile Cloud,” in IEEE Transactions on Cloud Computing, 2016.

[15] K. Wang, K. Yang and C. Magurawalage, “Cost-Effective Resource Allocation in C-RAN with Mobile Cloud,,” in IEEE International Conference on Communications (ICC), 2016.

[16] METIS ICT-317669, “Deliverable D1.5 Updated scenarios, requirements and KPIs for 5G mobile and wireless system with recommendations for future inverstigations,” 2015.

[17] METIS II 671680, “Deliverable D1.1 Refined scenarios and requirements, consolidated use cases, and qualitative techno-economic feasibility assessment,” 2016.

[18] NGMN Alliance, “5G White Paper,” 2015. [Online]. Available: https://www.ngmn.org/uploads/media/NGMN_5G_White_Paper_V1_0.pdf.

[19] IMT-2020 (5G) Promotion Group, “White Paper on 5G Vision and Requirements,” 2014.

[20] ITU-T, Recommendation ITU-T G.8261/Y.1361 : Timing and synchronisation aspects in packet networks, 2013.

[21] 3GPP, “TS36.104: Evolved Universal Terrestrial Radio Access(E-UTRAN); Base Station (BS) radio transmission and reception,” [Online]. Available: http://www.3gpp.org/DynaReport/36104.htm. [Accessed 8 December 2015].

[22] IEEE Standards Association, “Standard for Packet-based Fronthaul Transport Networks,” [Online]. Available: http://grouper.ieee.org/groups/1914/1/. [Accessed 2016].

[23] Small Cell Forum, “Crossing the Chasm: Small Cells Industry 2015,” 2015. [Online]. Available: http://scf.io/en/get_email.php?paper=2079. [Accessed 2016].

[24] 3GPP, “TS 36.300 LTE; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Univeral Terrestrial Radio Access Network (E-UTRAN); Overall Description,” 2016.

[25] M. Goldenbaum, R. A. Akl, V. S. and S. Stanczak, “On the Efect of Feedback Delay in the Downlink of Multiuser OFDM Systems,” in 45th Conference on Information Science and Systems, Baltimore, 2011.

[26] G. Caire, N. Jindal, M. Kobayashi and N. Ravindran, “Multiuser MIMO Achievable Rates with Donwlink Training Channel State Feedback,” IEEE Transactions on Information Theory, vol. 56,


Page 103 of 110


no. 6, pp. 2845-2866, 2010.

[27] NGMN Alliance, “Fronthaul Requirements for C-RAN,” 2015.

[28] Nokia, “Evolution to centralized RAN with mobile fronthaul,” 2016. [Online]. Available: http://networks.nokia.com/file/49836/evolution-to-c-ran-with-mobile-fronthaul-pdf. [Accessed June 2016].

[29] IEEE, “802.1CM - Time-Sensitive Networking for Fronthaul,” [Online]. Available: http://www.ieee802.org/1/pages/802.1cm.html. [Accessed June 2016].

[30] CPRI, “IEEE 802.1CM Time-Sensitive Networking for Fronthaul,” May 2016. [Online]. Available: http://www.ieee802.org/1/files/public/docs2016/cm-CPRI-functional-decomposition-requirements-0516-v01.pdf. [Accessed June 2016].

[31] K. Manolakis, C. Oberli, V. Jungnickel and F. Rosas, “Anaylsis of Synchronization Impairments for Cooperative Base Stations Using OFDM,” Hindawi International Journal of Antennas and Propagation, vol. 2015, pp. 1-14, 2015.

[32] Ericsson AB, Huawei Technologies Co.Ltd, NEC Corporation, Nokia Networks, Alcatel-Lucent, “CPRI Specification V7.0 (2015-10-09): Common Public Radio Interface (CPRI); Interface Specification,” http://www.cpri.info, 2015.

[33] 3GPP, “TS 36.214 LTE; Evolved Universal Terrestrial Radio Access (E_UTRA); Physical layer; Measurements,” 2015.

[34] NGMN Alliance, “Integrated QoS Management,” 2015. [Online]. Available: https://www.ngmn.org/uploads/media/NGMN_Backhaul_Evolution_-_Integrated_QoS_Management_Part_One_v1.3.pdf. [Accessed June 2016].

[35] IEEE, “IEEE Std1588-2008: IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems,” IEEE, 2008.

[36] ITU-T, “Recommendation ITU-T G.8265.1/Y1365.1: Precision time protocol telecom profile for frequency synchronisation,” ITU-T, 2014.

[37] IEEE, “1904.3 Task Force: Standard for Radio Over Ethernet Encapsulations and Mappings,” [Online]. Available: http://www.ieee1904.org/3/tf3_home.shtml.

[38] J. Korhonen, “IEEE P1904.3 Radio over Ethernet short introduction,” 2016. [Online]. Available: http://www.ieee802.org/1/files/public/docs2016/new-roe-jik-ieee1904dot3intro-0316-v00.pdf. [Accessed June 2016].

[39] Eurecom, “Open Air Interface 5G,” [Online]. Available:


Page 104 of 110


https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/OpenAirUsage.

[40] K. Habel, L. Fernandez del Rosal, S. Weide, J. Hilt, V. Jungnickel, E. R., C. Schubert, F. Frey, J. K. Fischer and R. Freund, “5 Gb/s Real-Time Processing Using π/4-shift DQPSK for Bidirectinal Radio-OverFiber System",” in ICTON, 2015.

[41] L. Fernandez del Rosal, K. Habel, S. Weide, P. Wilke Berenguer, V. Jungnickel, P. Farkas and R. Freund, “Multi-Gigabit Real-Time Signal Processing for Future Converged Networks,” in ITG Fachtagung Breitbandversorgung in Deutschland, Berlin, 2016.

[42] J. Kornhonen, “IEEE 1904.3 Task Force,” 19 May 2015. [Online]. Available: http://www.ieee1904.org/3/meeting_archive/2015/06/tf3_1506_korhonen_8a.pdf . [Accessed April 2016].

[43] ITU-T, Recommendation ITU-T G.8260: Definitions and terminology for synchronization, 2012.

[44] ITU-T, Recommendation ITU-T G.8262/Y.1362 : Timing characteristics of synchronous Ethernet equipment slave clock.

[45] ITU-T, Recommendation ITU-T G.8264/Y.1364 : Distribution of timing information through packet networks, 2014.

[46] IEEE8021, IEEE P802.1AS-Rev Draft 2.0 Timing and Synchronization for Time-Sensitive Applications, 2015.

[47] J.-L. Ferrant, M. Gilson, S. Jobert, M. Mayer, L. Montini, M. Ouellette, S. Rodrigues and S. Ruffini, Synchronous Ethernet and IEEE 1588 in Telecoms: Next Generation Synchronization Networks, Wiley-ISTE, 2013.

[48] ITU-T, Recommendation ITU-T G.8275/Y.1369: Architecture and requirements for packet based time and phase delivery, 2013.

[49] ITU-T, Recommendation ITU-T G.8275.1/Y.1369.1: Precision time protocol telcom profile for phase / time synchronisation with full timing support from the network, 2014.

[50] M. J. Teener, A Time-Sensitive Networking Primer: Putting It All Together, 2015.

[51] IEEE8021, IEEE 802.1Q Bridges and Bridged Networks, 2014.

[52] IEEE8021, IEEE P802.1Qbv Draft 3.1 Enhancement for scheduled traffic, 2015.

[53] IEEE8021, IEEE P802.1Qch Draft 0.1 Cyclic Queuing and Forwarding (CQF), 2016.

[54] IEEE8021, IEEE P802.1Qbu Draft 3.1 Frame Preemption, 2015.


Page 105 of 110


[55] IEEE8021, IEEE P802.1Qcc Draft 1.0 Bridges and Bridged Networks Amendment: Stream Reservation Protocol (SRP) Enhancements and Performance Improvements, 2016.

[56] IEEE8021, IEEE P802.1Qci Draft 1.1 Per-Stream Filtering and Policing (PSFP), 2016.

[57] IEEE8021, IEEE P802.1CB Draft 2.1 Seamless Redundancy, 2015.

[58] IEEE8021, IEEE P802.1CM Draft 0.2 Time-Sensitive Networks for Fronthaul, 2016.

[59] Siliconlabs, SyncE and IEEE 1588 Sync Distribution for a Unified Network, 2014.

[60] TI, AN-1730 DP83640 Synchronous Ethernet Mode Achieving Sub-Nanosecond Accuracy in PTP Applications, 2013.

[61] D. Wilson, “Challenges using IEEE 1588-2008 Precision Time Protocol (PTP) for High Accuracy Time Transfer,” in 43rd Annual Precise Time and Time Interval (PTTI) Systems and Applications Meeting, 2012.

[62] G. Kalman, Time Synchronization Challenges, 2014.

[63] Y. Yang, Data Center Fabric with Nanosecond Accuracy - Use IEEE1588 PTP on Nexus 3000 Switches, 2014.

[64] S. Kumar, Synchronization In Packet Switched Networks a survey of existing techniques, 20xx.

[65] K. Veggeberg, Achieving Sub-ns Synchronization in Ethernet Networks, 2014.

[66] M. J. Teener, “Timing Performance of a Network of Low-cost IEEE 802.1AS Network Elements,” in ISPCS (International IEEE Symposium on Precision Clock Synchronization for Measurement, Control and Communication), 2007.

[67] M. J. Teener, “Overview and Timing Performance of IEEE 8021as,” in ISPCS (International IEEE Symposium on Precision Clock Synchronization for Measurement, Control and Communication), 2008.

[68] D. T. Bui, A. Dupas and M. Le Pallec, “Packet delay variation management for a better IEEE1588V2 performance,” in ISPCS (International IEEE Symposium on Precision Clock Synchronization for Measurement, Control and Communication), 2009.

[69] M. Anyaegbu, C.-X. Wang and W. Berrie, “Dealing with Packet Delay Variation in IEEE 1588 Synchronization Using a Sample-Mode Filter,” 2013.

[70] Z. Chaloupka, N. Alsindi and J. Aweya, “Clock Skew Estimation Using Kalman Filter and IEEE 1588v2 PTP for Telecom Networks,” 2015.


Page 106 of 110


[71] P. Assimakopoulos, M. K. Al-Hares, S. Hill, A. Abu-Amara and N. J. Gomes, “Statistical Distribution of Packet Inter-Arrival Rates in an Ethernet Fronthaul,” in IEEE Int. Conf. on Commun. Workshops (ICC), Kuala Lumpur, 2016.

[72] M. K. Al-Hares, P. Assimakopoulos, S. Hill and N. J. Gomes, “The Effect of Different Queuing Regimes on a Switched Ethernet Fronthaul,” in Proc. Int. Conf. on Transparent Optical Networks (ICTON), Trento, Italy, 2016.

[73] P. Assimakopoulos, M. K. Al-Hares and N. J. Gomes, “Switched Ethernet Fronthaul Architecture for Cloud-Radio Access Networks,” EEE/OSA J. Optical Commun. and Networking (JOCN), special Issue on Optical Networking for 5G Mobile and Wireless Commun., 2016 (Submitted for publication).

[74] L. Greiner and P. Gibbons, “SLA Definitions and Solutions,” 2007. [Online]. Available: http://www.cio.com/article/outsourcing/sla-definitions-and-solutions.html. [Accessed 2016].

[75] IEEE, “IEEE P802.3bg 40Gb/s Ethernet Single-mode Fibre PMD Task Force,” [Online]. Available: http://www.ieee802.org/3/bg/index.html.

[76] C. Kottke, K. Habel, C. Schmidt and V. Jungnickel, “154.9 Gb/s OFDM Transmission Using IM-DD, Electrical IQ-Mixing and Signal Combining,” in OFC, 2016.


Page 107 of 110


List of figures

Figure 1.1 iCIRRUS architecture overview ................................................................................................... 16 Figure 1.2 Point-to-point and multiple point-to-point (star) topology (aggregator) ...................................... 18 Figure 1.3 Tree topology (add and drop) ..................................................................................................... 18 Figure 1.4 Ring topology (redundancy) ....................................................................................................... 19 Figure 1.5 Ethernet-based OAM with built-in probes or pluggable probes for OAM, SLA, and SON .............. 19 Figure 1.6 Aggregation and different treatment of multiple traffic classes .................................................. 20 Figure 1.7 Possible split points in the downlink for single-input single-output (SISO), massive multiple-input

multiple-output (MIMO) and CoMP and massive MIMO scenarios ...................................................... 21 Figure 1.8 Possible split points in the uplink for SISO, massive MIMO and CoMP scenarios ......................... 23 Figure 1.9 Function block for D2D function splitting .................................................................................... 25 Figure 1.10 Mobile cloud networking architecture ...................................................................................... 25 Figure 2.1 Over-the-air and backhaul traffic vs. the number of small cell [12] .............................................. 28 Figure 2.2 End-to-end fronthaul latency requirement from CPRI cooperation [30] ...................................... 30 Figure 3.1 Different split point options and division of data among packet types and flows ........................ 37 Figure 3.2 BBU side processing. Example for 2x2 MIMO. The clock frequencies shown are examples based on

4G data rates. CDR= Clock and data recovery unit .............................................................................. 39 Figure 3.3 Primitives used for the generic IQ mapper (based on RoE definitions) ......................................... 40 Figure 3.4 RoE packet construction for generic IQ transportation. Example is for Num_MIMO=2 ................ 41 Figure 3.5 Construction of RoE packet using containers and segments based on the example for the CPRI

mapper in IEEE 1904.3 draft [37].Note that the containers should probably be interleaved i.e. cont.0, cont.1, cont.2, cont.3 etc .................................................................................................................... 41

Figure 3.6 DU side processing. Example of 2x2 MIMO ................................................................................. 43 Figure 3.7 An “event-based” buffer design for syncronising primitive and user-plane buffer “play-out” for a

MAC-PHY split ................................................................................................................................... 44 Figure 3.8 The architectural building blocks for the fronthaul with split functionality, using OAI for (a) Split I

and (b) Split II .................................................................................................................................... 45 Figure 3.9 Uplink process for resource mapper ........................................................................................... 46 Figure 3.10 Primitives used for the Split II mapper for the PUSCH (based on RoE definitions) ...................... 47 Figure 3.11 Primitives used for the Split II mapper for the PRACH (based on RoE definitions) ...................... 47 Figure 3.12 Primitives used for the Split II mapper for the PUCCH (based on RoE definitions) ...................... 48 Figure 3.13 Primitives used for the MAC-PHY mapper for the TBs (based on RoE definitions) ...................... 50 Figure 3.14 Primitives used for the MAC-PHY mapper for the MAC control primitives (based on RoE

definitions) ........................................................................................................................................ 50 Figure 3.15 Primitives used for the MAC-PHY mapper for the PRACH (based on RoE definitions). ................ 51 Figure 3.16 Primitives used for the MAC-PHY mapper for the PUCCH (based on RoE definitions) ................. 51 Figure 3.17 Real-time transceiver building blocks (reference high-speed DU) .............................................. 52 Figure 3.18 High-speed evolved DU building blocks .................................................................................... 53 Figure 3.19 Ethernet Frame structure to transport user data from the high-speed evolved DU .................... 53 Figure 3.20 Accepted baseline proposal for RoE header format for non-control packet ............................... 54 Figure 3.21 SyncE - Frequency synchronization by physical layer clock recovery .......................................... 55 Figure 3.22 IEEE 1588 -packet-based approach for time synchronization ..................................................... 56 Figure 3.23 IEEE 802.1AS -packet-based approach for time synchronization ................................................ 57 Figure 3.24 IEEE 802.1Qav credit based shaping .......................................................................................... 59 Figure 3.25 IEEE P802.1Qbv time-aware shaping –guard band .................................................................... 60


Page 108 of 110


Figure 3.26 IEEE P802.1Qbv time-aware shaping –transmission gate ........................................................... 61 Figure 3.27 IEEE P802.1Qbu frame preemption – shrinking the size of the guard band ................................ 62 Figure 3.28: IEEE P802.1Qch cyclic queuing and forwarding (CQF) ............................................................... 63 Figure 3.29 IEEE 802.1Qat stream reservation protocol ............................................................................... 63 Figure 3.30 IEEE P802.1Qci Per-Stream Filtering and Policing (PSFP) ............................................................ 65 Figure 3.31: IEEE P802.1CB seamless redundancy ....................................................................................... 65 Figure 4.1 Different split point options and division of data among packet types and flows ........................ 70 Figure 4.2 Uplink data rate for different numbers of antennas, for Split II ................................................... 70 Figure 4.3 Uplink data rate for different numbers of layers (per radio unit) for different loads for split MAC-

PHY ................................................................................................................................................... 71 Figure 4.4 Experimental setup for measuring the resulting throughput on the fronthaul interface for the

upper-PHY split .................................................................................................................................. 72 Figure 4.5 Fronthaul throughput for a latency-optimized mapping to FEC block .......................................... 72 Figure 4.6 Fronthaul throughput for a overhead-optimized mapping to FEC blocks ..................................... 73 Figure 4.7 Experimental setup for latency measurement on the fronthaul interface for the upper-PHY split 74 Figure 4.8 Processing latency at the DU for an latency-optimized mapping to FEC blocks ............................ 74 Figure 4.9 Zoom of the processing latency at the DU in the range from 0 to 30 µs for an overhead-optimized

mapping to FEC blocks ....................................................................................................................... 75 Figure 4.10 Processing latency at the DU for an overhear-optimized mapping to FEC blocks ........................ 76 Figure 4.11 Zoom of the processing latency at the DU in the range from 0 to 30 µs for an overhead-optimized

mapping to FEC blocks ....................................................................................................................... 77 Figure 4.12 Processing latency at DU depending on input buffer size .......................................................... 78 Figure 4.13 Processing latency at the DU depending on input buffer characteristics .................................... 78 Figure 4.14: Assisted Partial Timing Support (APTS). ................................................................................... 82 Figure 4.15 Testbed used for the measurement procedure. PRE=Packet Routing Engine, GbE=Gigabit

Ethernet, SFP=Small Form-factor Pluggable ........................................................................................ 84 Figure 4.16 Algorithm used for the frame inter-arrival delay measurements ............................................... 85 Figure 4.17 Comparison for mean and std of frame inter-arrival delays of the LTE traffic for different WRR

weights for A) different background traffic data rates for a frame size of 1500 bytes and B) different background traffic frame sizes at a data rate 215 Mbps. The “LTE” trace corresponds to transmitting only the LTE traffic (i.e. no background traffic) ................................................................................... 86

Figure 4.18 Mean and std of frame inter-arrival delays of the LTE traffic under SP regime for A) different Frame sizes and background traffic data rates (105 Mbps, 450Mbps). B) CCDFs of the results in A) ..... 87

Figure 4.19 Comparison for the mean of the frame inter-arrival delay of the LTE traffic for equal-weight (WRR4) and No-priority cases with different LTE traffic BWs and different background traffic data rates with frame sizes A) 500 Bytes and B) 4000 Bytes. The “LTE” trace corresponds to transmitting only the LTE traffic (i.e. no background traffic) ................................................................................................. 88

Figure 4.20 (a) A Test-bed for FDV measurements and (b) Delay asymmetry issue due to contention of PTP timing messages with in-line traffic. GbE=Gigabit Ethernet, DSP=Digital Signal Processing, RF=Radio Frequency .......................................................................................................................................... 89

Figure 4.21 (a) Flow-chart of Matlab algorithm and (b) Dealing with uncertainty of timestamping .............. 89 Figure 4.22 Delay (fronthaul latency) and FDV measurements. Note that this is a concatenation of a number

of measurement results ..................................................................................................................... 90 Figure 4.23 (a) CCDF of FDV from a measurement across the first switch. Mean=52.9, std=53 and (b) CCDF of

FDV from end-to-end measurements. Mean=55.7 ns, std=60.1 ns ...................................................... 91 Figure 4.24 A background traffic frame is inserted in the switch port queue in-between LTE-carrying frames

.......................................................................................................................................................... 91


Page 109 of 110


Figure 4.25 Effect of background traffic on HARQ re-transmissions. (a) re-transmissions versus data rate and (b) re-transmissions versus packet size ............................................................................................... 92

Figure 5.1 Existing backhaul architecture .................................................................................................... 93 Figure 5.2 Possible scenarios based on RAN evolution ................................................................................ 94 Figure 5.3 Bit rate evolution of CPRI and CPRI compressed per RRH and aggregated traffic of new functional

split at antenna site ........................................................................................................................... 95 Figure 5.4 Possible modified iCIRRUS fronthaul architecture for low-cost, low-energy, high-speed

transmission ...................................................................................................................................... 98


Page 110 of 110


List of tables

Table 2.1 Fronthaul data rate requirements depending on modified functional split ................................... 28 Table 2.2 Fronthaul latency requirements depending on the modified functional split ................................ 31 Table 2.3 Fronthaul requirements and KPIs ................................................................................................ 35 Table 3.1 List of primitives used by the mappers in RoE [37] ....................................................................... 38 Table 3.2 Parameters used for the generic IQ mapper ................................................................................. 40 Table 3.3 Parameters used for the Split II mapper ...................................................................................... 46 Table 3.4 Parameters used for the MAC-PHY mapper ................................................................................. 48 Table 4.1 Required data rates following CPRI encapsulation into Ethernet assuming RoE mapping .............. 69 Table 4.2 Uplink fronthaul data rates resulting from different functional splits per sector/cell/carrier.

Assuming 8 antennas and 100 MHz BW. For splits III & II the sample resolution is 8 bpS ..................... 71 Table 4.3 Contrasting of the physical layer based (SyncE), packet based (IEEE 1588), and packet based (IEEE

802.1AS) approaches ......................................................................................................................... 80

Documents

intelligent Converged network consolIdating Radio and ... · LC Lucent Connector . LTE Long Term Evolution . LAN Local Area Network . MAC Media Access Control . MAN Metro Area Network