intelligent Converged network consolIdating Radio and...

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 (iCIRRUS)

intelligent Converged network consolIdating Radio and optical access aRound USer equipment

DELIVERABLE: D3.3

SLA and SON Concept for iCIRRUS

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.3

Type: Report

Dissemination level Public

Date submitted: 20-12-2016

Editors: Howard Thomas (Viavi Solutions)

Authors / contributors (contributing partners)

Howard Thomas (VIAVI Solutions), Luz Fernandez del Rosal (HHI), Philippos Asimakopoulos, Yuan Kai (UKent), Kezhi Wang (UEssex), Philippe Chanclou (Orange), Daniel Muench (ADVA)

Internal reviewers Anthony Magee (ADVA), Michael Georgiades (PrimeTel)

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

Page 1 of 79

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

Document history

Version 0.1 First draft including table of content

01/05/2016

Version 0.2 Second draft circulated with first contributions from partners

9/11/2016

Version 0.3 First review from Kent, HHI, TS, Orange and request for updates

21/11/2016

Version 0.4 Final draft of deliverable completed

22/11/2016

Version 0.6 Internal review 23/11/2016 Version 0.7 Suggested corrections

after internal review 6/12/2016

Version 0.8 Corrections made 13/12/2016 Version 0.9 Review of corrections 14/12/2016 Version 1.0 Final version 16/12/2016


Page 2 of 79


Abstract This deliverable D3.3 “SLA and SON Concept for iCIRRUS,” reports on the definition of a service level agreement (SLA) concept for the iCIRRUS architecture, including an analysis of relevant key performance indicators (KPIs) with associated measurement methodologies, as well as on the definition of a self-organising /self-optimising network (SON) conceptual framework that seeks to configure, optimise and repair an iCIRRUS based network to autonomously assure delivery of the SLA. The deliverable takes inputs from the activities in Work Package 3 (WP3) and Work Package 4 (WP4) in the first two thirds of the project (i.e. first 24 months). Together with the encompassment of the SON solution-space, which considers joint optimisation of fronthaul and RAN, the proposed framework also addresses the dependency on fronthaul/RAN resource limitations of both network controlled device-to-device (D2) operation and Mobile Cloud Network - User Equipment (UE) operation and associated performance optimisation.


Page 3 of 79


Executive Summary

Mobile fronthaul is being redesigned to support the needs of future radio access networks and Ethernet is being used as the underlying transport mechanism. Fronthaul exchanges signals between the centralised digital unit (DU) and the remote unit (RU).

Typically, Centralized RAN has been associated with higher resource demands in the fronthaul than distributed RAN. The variable fronthaul split associated with NGFI allows variation between these two architectures. Thus, the adjustment of the split of functionality between Central Unit (CU) and RU and the resource made available for fronthaul become parameters for configuration and optimisation. Together these parameters allow trade-off, on the one hand, between the efficiency of shared processing at a central location that facilitates easy exchange of data for co-ordinated transmission/reception between radios with, on the other hand, a more decentralised system with lower fronthaul resource requirements and a greater potential for statistical multiplexing gains and path switching on the transport.

The component data streams carried on the iCIRRUS fronthaul depend on the details of the functional split in both downlink and the uplink and may include the IEEE 1588 precision time protocol (PTP), samples of RF waveforms, evolved fronthaul user data, inter-cell exchange of channel state information (CSI) and radio resource allocation (e.g. if co-ordinated multipoint (CoMP) is implemented), and potentially backhaul traffic.

Self-optimising/self-organising SON features are deployed in RAN networks to simplify engineering tasks related to network planning, deployment, operations maintenance and optimisation. Fronthaul configuration and management adds an extra dimension to the network configuration solution space creating a need for a new SON concept. To realize this several elements are needed.

Methodologies for characterisation of the performance of the functional elements of the new fronthaul are presented that address Ethernet performance tests, evaluation of the PTP performance, evaluation of time sensitive networking (TSN) performance and standardised test suites and analytic methodologies.

Further requirements for extending service level agreement (SLA) definitions arising from the introduction of evolved fronthaul/midhaul are also reported.

Considering both these factors, namely the performance measurement methodologies and the extended SLA definition, the possible ways in which (self-optimising network) SON configuration, optimisation and self-healing are affected are investigated. The potential interaction of the joint fronthaul and RAN optimisation of D2D and Mobile Cloud Network performance is also addressed.

Finally, in conclusion a selection of the SON modalities is singled out as potential targets for further development and investigation in future tasks of the work package and as part of WP5.


Page 4 of 79


Index of terms

ANR Autonomous Neighbour Relations API Application Programming Interface BBU Baseband Unit BER Bit Error Rate BTS Base Station CAPEX Capital Expense CBR Constant Bit Rate CCDF Complementary cumulative distribution function CFM Connectivity and Fault Management CFO Carrier Frequency Offset CINR Carrier to Interference and Noise Ratio CIR Committed Information Rate CoMP Coordinated MultiPoint CoS Class of Service COTS Commodity Off The Shelf (IT infrastructure) CPRI Common Public Radio Interface CPU Central Processing Unit CQI Channel Quality Index C-RAN Cloud Radio Access Network CRC Cyclic Redundancy Check CSI Channel State Information C-SON Centralised SON CTR Call Trace Record CU Central Unit (abstraction of BBU pool for alternative functional splits) D2D Device-to-Device DU Digital Unit EPC Evolved Packet core EVM Error Vector Magnitude FDV Frame Delay Variation FEC Forward Error Correction FH Fronthaul GMC Grand Master Clock GPS Global Positioning System HARQ Hybrid Automatic Repeat Request H-SON Hybrid SON ICIC Inter-Cell Interference Co-ordination ID Identifier ID/s Identity IETF Internet Engineering Task Force IFDV Inter Frame Delay Variation


Page 5 of 79


IFFT Inverse Fast Fourier Transform IPDV Inter Packet Delay Variation IPFPM IP Flow Performance Management IPv4 IP version 4 IQ In-phase / Quadrature ITU International Telecommunication Union ITU-T ITU-Telecommunication Standardisation Sector KPI Key Performance Indicator LAN Local Area Network LTE Long Term Evolution LTE-A LTE-Advanced MAC Media Access Control MCN Mobile Cloud Network MCS Modulation and Coding Scheme MEC Mobile Edge Computing / Multiple access Edge Computing MEF Metro Ethernet Forum MIMO Multiple-Input Multiple-Output MME Mobility Management Entity MTBF Mean Time Before Failure MTTR Mean Time To Repair NAICS Network Assisted Interference Cancellation System NFV Network Function Virtualisation NGFI Next-Generation Fronthaul Interface NGMN Next Generation Mobile Network NID Network Interface Device NMWG Network Measurement Working Group NOC Network Operations Centre OAI Open Air Interface OAM Operations, Administration and Management OFDM Orthogonal Frequency Division Multiplexing OMC Operations and Maintenance Centre OPEX Operating Expense OSS Operation Support System OWAMP One Way Active Measurement Protocol OWD One Way Delay PCI Physical Channel Identity PCRF Policy Charging Rules Function PDCP Packet Data Convergence Protocol PGW Packet Gateway PDV Packet Delay Variation PGW Packet Gateway PHY Physical (Layer) PM Performance Management


Page 6 of 79


PNF Physical Network Function PRE Packet Routing Engine PTP Precision Time Protocol QoE Quality of Experience QoS Quality of Service RAN Radio Access Network RAT Radio Access Technology RE Radio Equipment RF Radio Frequency RFC Request For Comment (IETF) RLC Radio Link Control RRC Radio Resource Control RRH Remote Radio Head RRS Radio Remote System RRU Remote Radio Unit RTD Round Trip Delay RTT Round Trip Time RU Radio Unit (abstraction of RRH for alternative functional splits) RU Remote Unit SDN Software Defined Network SFO Sampling Frequency Offset SFP Small Form-factor Pluggable SINR Signal to Interference and Noise Ratio SLA Service Level Agreement SM System Manager SOAM Service OAM SOF Start of Frame SON Self-Optimising Network SyncE Synchronous Ethernet TA Timing Advance TaaS Test as a Service TDD Time Division Duplex ToD Time of Day TSN Time-Sensitive Networking TWAMP Two Way Active Measurement Protocol TX Transmitter UDP User Datagram Protocol UE User Equipment UL Uplink UMTS Universal Mobile Telecommunication System vBBU Virtual Baseband Unit VIP Very Important Person VLAN Virtual Local Area Network


Page 7 of 79


vMME Virtual MME VNF Virtualised Network Function vPGW-C/D Virtual Packet GateWay vSGW Virtual Serving GateWay

Glossary

G.8265.1 Telecom Profile for IEEE 1588 IEEE 1588 Ethernet timing protocol ITU Y.1564 ITU-T standard for turn-up, install, trouble shooting of Ethernet installations ITU Y.1731 ITU-T standard for performance monitoring of Ethernet installations L1 Layer 1 (physical layer) L2 Layer 2 (data link) L3 Layer 3 (MAC/RLC layer) OpenFlow An open-source switch description including messages and architecture [1] RFC 2544 Benchmarking methodology for Ethernet RFC 2679 Methodology for OWD RFC 2681 Methodology for RTD RFC 3393 Packet delay variation metric for IP RFC 5481 Packet Delay Variation Applicability Statement S1 Interface from eNB to MME X2 Interface between eNB


Page 8 of 79


Contents Document history _________________________________________________________________ 1

Abstract _________________________________________________________________________ 2

Executive Summary ________________________________________________________________ 3

Index of terms ____________________________________________________________________ 4

Glossary _________________________________________________________________________ 7

Introduction ____________________________________________________________________ 10

1.1 Elements of Service Level Agreements (SLA) for Telecommunications Service _________ 10

1.1.1 Example SLA for Telecommunication Service _______________________________ 10

1.1.2 Measurements to demonstrate performance of an SLA ______________________ 11

1.1.3 SLA Monitoring for next generation fronthaul ______________________________ 12

1.2 Overview of self-organising network approaches in Telecommunications Networks ____ 12

____________________________________________________________________________ 13

1.3 SON in the RAN __________________________________________________________ 17

2 Measurement techniques ______________________________________________________ 21

2.1 Measurements for performance evaluation of transport _________________________ 21

2.1.1 Ethernet performance tests ____________________________________________ 22

2.1.2 PTP evaluation_______________________________________________________ 29

2.1.3 TSN evaluation ______________________________________________________ 32

2.1.4 Test suites __________________________________________________________ 36

2.1.5 Analytics and management approaches ___________________________________ 39

2.2 Measurements for performance evaluation in RAN/radio domain) _________________ 42

3 Opportunities for SLA definition and or enhancement arising due to evolved fronthaul / midhaul 45

3.1 Availability/Downtime ____________________________________________________ 47

3.2 Delay __________________________________________________________________ 47

3.3 Jitter (Delay Variation) ____________________________________________________ 48

3.4 Loss ___________________________________________________________________ 50

3.5 Throughput _____________________________________________________________ 51

What might 5G bring for Latency and throughput requirements? ________________________ 51

3.6 Which parameters should be monitored ______________________________________ 54

4 Opportunities for SON reconfiguration ___________________________________________ 55

4.1 Combined RAN/Radio and transport reconfiguration ____________________________ 56


Page 9 of 79


4.1.1 Choice of co-operative mode of operation _________________________________ 56

4.1.2 Dynamic path changes ________________________________________________ 59

4.2 Combined D2D and transport reconfiguration _____________________________________ 63

4.3 Combined Cloud Computing and transport reconfiguration _______________________ 65

4.4 Concepts for SON control and operation ______________________________________ 67

5 SLA and SON concept for iCIRRUS ________________________________________________ 72

References _____________________________________________________________________ 75

List of figures ____________________________________________________________________ 78

List of tables ______________________________________________ Error! Bookmark not defined.


Page 10 of 79


Introduction iCIRRUS D3.2 [2] set out the preliminary architecture proposal for fronthaul in iCIRRUS that introduces an Ethernet based fronthaul with facility to support different split of the radio processing functionality between the central location and the remote radio location. There are several different terminologies for the network elements that emerge because of this split, and this is partly because the pre-split terms are no-longer accurate due to the movement of functionality. In this document, no special distinction is made between the different terms for the centralised functionality and those used for the remote radio functionality; they are used interchangeably. Thus, the pre-split term BBU or (BBU hotel) is used interchangeably with CU (central unit), DU (digital unit), and the pre-split term RRH is used interchangeably with RU (radio unit), RRU (remote radio unit), RRS (remote radio system) and RE (radio equipment).

This document defines the concept for assessing the performance of the new fronthaul and the interrelation between that and the attainable radio performance and possible radio operating modes; such performance is defined in terms of a service level agreement (SLA) that specifies a level of service that should be maintained. The document then defines a self-configuring/self-organising network (SON) concept which is a mechanism operative to achieve and maintain such.

The principal focus of the document is on the interaction between the fronthaul and the radio performance as there is a strong dependence between the two. However, the document also addresses two other potential “solution domains” for SON namely the interaction between network controlled device-to-device (D2D) operation and fronthaul performance, and that between mobile cloud network (MCN) operation and fronthaul performance.

1.1 Elements of Service Level Agreements (SLA) for Telecommunications Service 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,” [3], as such, it is a very general construct applicable to many domains. The SLA may have different constraints during different time periods, e.g., just during working hours 8/5, or continuous availability, e.g. 24/7.

1.1.1 Example SLA for Telecommunication Service By way of example, we provide a short description of an SLA for provision of “service availability.” Availability refers to a system’s ability to accomplish the function requested by those accessing the system. Further details of this and other SLA metrics are provided in Section 3. Interval availability gives the percentage of time over a contractual measurement period when the operational performance is met. The table below compares the availability and the corresponding downtime expressed per year, month, or week.


Page 11 of 79


Table 1-1 Availability mapping to downtime [4]

However, our primary concern in task T3.3 is with defining that part of the SLA that is concerned with appropriate technical performance metrics and associated measurement methodologies for the fronthaul considering the impact of any new fronthaul configuration, reconfiguration or failure modes and the associated limitation or facilitation of other system features1, which arise from the architectural modifications under investigation within iCIRRUS. Namely,

• Introduction of an Ethernet-based fronthaul with a modified functional split that supports traffic aggregation at the fronthaul level

• Introduction of mobile cloud based components for supporting applications such as application offload

• Introduction of network controlled D2D offload

Conceptually, the performance metric measurements associated with these architectural modifications 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 by an Operations and Maintenance Centre or Operations Support Subsystem OMC / OSS) and the network management element controlling the access network (typically by a Software Defined Network (SDN) controller).

1.1.2 Measurements to demonstrate performance of an SLA Adherence to the SLAs can be usually measured using one or more Key Performance Indicators (KPI). KPIs can be of different types and reported using different statistics over defined periods, typical quantities for a communication link include,

• Minimum value (e.g.: for availability, for packet loss) • Maximum value (e.g.: for jitter) • Average value (e.g.: maximum expected average value for delay)

1 The dependence of system features on fronthaul performance, for example, ‘mobile cloud offload’ or ‘network controlled D2D offload’ creates fronthaul performance requirements, which requirements may be time-varying.


Page 12 of 79


• Percentage (e.g.: maximum acceptable for packet loss percentage value)

The SLA should provide detailed information about the KPI including,

• The precise definition of the KPI used and the and an unambiguous description of the methodology to be used to measure it2

• A mean value must be defined over a proscribed averaging time • A maximum value is also defined for a proscribed measurement time • The number of threshold crossings (or percentage of time below a threshold) will indicate

the gravity of the event

1.1.3 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 on means to measure them. In contrast to CPRI, the fronthaul data is no-longer monolithic but comprises data streams with different performance requirements. 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 Precision Time Protocol (PTP) synchronisation 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. Additionally, different SLAs may be defined per class of service (CoS). They will depend on the Quality of Service (QoS) classes in which a flow can be classified. They will be stricter for the Real-Time class than for the Best-Effort class

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 2.1.

Measurements will include packet loss, packet delay and packet delay variation. Measurement methodologies based on synthetic traffic and 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 [5], ITU-T Y.1564 [6] and ITU-T Y.1731 [7] will be reviewed for suitability / applicability and possible need for extension / enhancement.

1.2 Overview of self-organising network approaches in Telecommunications Networks The term SON encompasses both “Self-Organising” and “Self-Optimising” Network, where the “Network” referred to may include the entirety of a telecommunication network or one or more segment. Components that may be managed by SON thus include the network equipment nodes of the RAN, the Evolved Packet Core (EPC) and the transport network. An additional function for SON to

2 Example measurement methodologies are presented in Section 2.


Page 13 of 79


manage is the measurement infrastructure devices and OAM functions necessary to determine system performance. Example network elements for 4G include eNB3, Mobility Management Entity (MME), Packet Gateway (PGW), the OSS and potentially probes to measure transport performance.

The objective of introducing SON into a telecommunication network is three-fold,

• To efficiently manage networks that are growing increasingly complex including such challenges as addition of new Radio Access technologies (2G, 3G, 4G, 4.5G, 5G), new cell topologies such as C-RAN, NGFI and small cells, and new operational modalities such as network function virtualisation NFV and network slicing. Automation addresses this complexity and allows teams to concentrate on other key operational domains.

• To enhance end user Quality of Service (QoS) and Quality of Experience (QoE). Always-on monitoring and reactive optimisation of RAN networks helps in improving the customer perceived QoS. Also, enhanced optimisation per cell will ease operations which are difficult to do manually today.

• To minimize deployment, operational costs and delays. A consistent theme is to facilitate automation of manual tasks and move towards the use of Commercial Off The Shelf (COTS) hardware to support Network Function Virtualisation (NFV).

Figure 1-1 View of end to end SON in a Telecommunication Network

Figure 1-1 illustrates a conceptual telecommunications network with network slicing4 [8], illustrated by slice 1...n, together with performance and measurement and display capability. A network slice is 3 For 5G the NR (new radio) is the counterpart to the eNB 4 Network slicing is designed to facilitate flexibility to address different business needs with diverse performance, scalability and availability requirements within a single mobile network. It consists of 3 layers, 1. Service instance layer 2. Network slice layer and 3. Resource layer.


Page 14 of 79


a set of network functions, and resources to run these network functions, forming a complete instantiated logical network to meet certain network characteristics required by one or more service instance [9]. For example, separate network slices might be used to provide service for emergency services, Internet of Things (IoT) and for conventional cellular services. A network slice instance may be fully or partly, logically and/or physically, isolated from another network [9]. Typically, isolation is possible in the core and transport allowing separate management of resources. At the radio scheduler and air interface the resource is shared but slice awareness may allow the network slice to be considered when determining the optimum network configuration.

The Figure illustrates measurements on one of the slices of packet loss, packet latency, packet delay variation (jitter), and measurements to determine if throughput QoS parameters, Committed Information Rate (CIR) and Committed Bit Rate (CBR), are met. Where resources on the slices are isolated, separate measurements would be required for each slice. At the bottom of the Figure are example 4G network functions that may be instantiated as Virtual Network Functions (VNF) or Physical Network Functions (PNF) in each slice; the functions vBBU, vMME, vSGW, vPGW-C/D, MME, PCRF and PGW are shown. The Figure shows probes connected to the various interfaces of the PNF and VNF that allow respectively measurement of the slice service performance, the slice transport performance and the slice and shared RAN performance. The Figure also shows assessment of service QoE using direct monitoring in UEs, which may be achieved with a specific application. The Figure shows the test and measurement capability as consisting of Test as a Service (TaaS) agents that can be dynamically orchestrated and flexibly deployed. The fronthaul cloud is shown as having probes that may be dynamically activated, with current deployed technology these would require hardware support to meet real-time performance requirements and would use pre-deployed hardware, however a future virtualisation infrastructure may support hardware acceleration to allow TaaS for fronthaul probes as well allowing the same dynamic orchestration and flexible deployment. The measurement capabilities are shown associated with display capabilities that allow performance analysis and fault finding.

Figure 1-2 shows how the measurement data collected from the elements of the telecommunications network may be fed in to a SON and NFV self-configuration process. The collected data is sent to an analytics engine that processes the measurements to generate information about the service performance and network status. This is then fed, together with inventory information5 [10], into an optimisation engine that determines potential configurations that are then fed to an orchestration engine that generates the required commands to update the system configuration, for example, messages to configure Software Defined Network (SDN) elements, or to change parameters of the RAN.

5 Active inventory contains information about the respective elements, their capabilities and their connectivity. And, as an active process, it comprises functions to detect “live” devices on the network, discover the device description and discover the network physical and logical topology. An Active Inventory Management system becomes a dynamical changing system presenting current, past and future states of the network and services. Inventory management is essential for enabling automation as that requires a consistent approach to end-to-end management of inventory data.


Page 15 of 79


Figure 1-2 Conceptual view SON and NFV Self Configuration

Figure 1-3 Overview of SON architecture including hybrid approach and MEC support

Figure 1-3 illustrates different architectural approaches that may be adopted for SON; the Figure uses SON in the RAN as an example the radio unit functionality is represented by the abstracted function RU, similarly, the remaining centralised baseband functionality is represented by the abstracted CU. The Figure illustrates the scenario where the CU elements may be co-located and exchange information over an ideal backhaul, indicated in the Figure as via the X2 switch6. Additionally, the

6 The X2 interface in LTE is a logical interface between eNB. In a conventional architecture, this is carried by over the backhaul with the S1 to the EPC and results in a so-called non-ideal backhaul with latency in the > 5ms

RU CU

RU CU

RU CU

S1 Switch

X2 Switch

Backhaul X2 over backhaul

Hybrid SON solution (H-SON)

Distributed SON (closed NEM domain)

Centralised SON solution (C-SON)

MEC (open D-SON)

MEC (open D-SON)

Centralised SON controls parameters for distributed SON


Page 16 of 79


Figure and includes the case where the CU elements may be geographically separated and exchange information over a non-ideal backhaul via an X2 interface mediated by the EPC through the S1 switch. The Figure also illustrates a fronthaul-cloud that indicates the network path from CU to RU may not be point-to-point and may be dynamically switched. Centralised SON (C-SON) collects all performance and configuration data to a central location and makes decisions at a single point. The approach has the best chance to achieve a global optimum configuration but centralisation of data imposes a signalling overhead and chance of a single point of failure. Additionally, if the SON makes frequent or rapid configuration changes, placement of the SON functionality distant from the CU location may lead to sub-optimal performance if the latency between CU and SON compromises the time budget for data collection, configuration determination and configuration actuation. Distributed SON (D-SON) makes decisions in a distributed manner which avoids overhead issues and is more robust to failure mechanisms. However, as decisions are not tightly coordinated there is less chance to achieve a global optimum configuration. Additionally, as decisions in D-SON are made at the level of the network elements there is little requirement for interoperation and these solutions tend to be a closed Network Equipment Manufacturer (NEM) domain. An alternative approach is to form a Hybrid SON (H-SON) solution that combines elements of both architectural strategies. For example, this allows centralised management and control of the parameterisation of the D-SON algorithms. Also, illustrated in the Figure is the use of Mobile Edge Computing (MEC) resources to perform D-SON activities, such an approach allows potentially intensive computing activities, e.g. performing operations on raw data rather than on aggregated and averaged data, that potentially allows faster and more accurate SON responses.

The mobile cloud can enable UEs with computing intensive tasks to send them to mobile cloud network (MCN), which will execute them on UEs behalf and then return the results to the user. In this case, substantial energy consumption reduction can be made in mobile user’s side and user experience can be improved significantly. Remote processing may be accomplished faster in the MCN as more resources may be available than in the UE. However, latency will be introduced due to exchange of information between the MCN and UE. Consequentially, depending on the inter-play between these factors, there may be a trade-off between energy consumption of processing locally and user-experience degradation due to latency introduced by remote processing.

There is a dependence between the operation of the Mobile Cloud Network (MCN) and the performance of the RAN. For example, the MCN must make decisions about what services to host in the cloud and this will impact the demands placed on the RAN. Conversely decisions made in the RAN configuration can impact the ability of the MCN to deliver its services. Thus, there is a potential gain from making decisions about the configuration of these entities in concert to achieve acceptable application performance and optimized network performance KPIs, consequently, joint optimisation of the MCN functionality and the telecommunication network may be considered as falling into the scope of SON.

range. In a C-RAN architecture the eNB may be co-located resulting in negligible latency. Enhancements to X2 to reduce latency between non-collocated eNB with an X2+ have been proposed


Page 17 of 79


To allocate the computing resource in the mobile cloud and communication resource in BBU/CU, we propose to have a mobile local controller sited between mobile cloud and BBU/CU, to allocate the computing resource and the communication resource.

The local controller can:

• Report the local monitoring information to SON • Receive the instruction from the SON • Allocate the computing resource to the mobile user • Allocate the communication resource to the mobile user

There is a dependence between the operation of network controlled D2D operation and the performance of the RAN. For example, the network will make decisions about what mobiles to place into D2D mode which may reduce traffic load carried by the RAN. Conversely, network controlled D2D requires sending of D2D CQI data and control and performance information from the UEs to the network. Additionally, information to support discovery of D2D candidates may also need to be sent to the network. Thus, there is a potential gain from making decisions about the configuration of these entities in concert to achieve acceptable application performance and optimized network performance KPIs, consequently, joint optimisation of the D2D functionality and the telecommunication network may be considered as falling into the scope of SON

1.3 SON in the RAN The first SON features are deployed in the RAN networks to simplify engineering tasks related to network planning, deployment, operations and maintenance and optimisation. SON features can be classified in three main families:

• Self-configuring: automate many of the manual steps required for planning and deploying a wireless radio network. These self-configuring features encompass Plug and Play configuration of sites, creation and optimisation of neighbour lists (ANR - Automatic Neighbour Relationship), allocation and correction of re-use identifiers (e.g. PCI in LTE, Scrambling Code in 3G).

• Self-optimizing: optimize automatically and continuously the network. These self-optimizing features are focused on the modification of mobility, power or antenna parameters to find optimized usages of network layers (balancing of traffic, interference and optimisation of coverage and energy usage).

• Self-management & Self-healing: reduce the engineering tasks necessary for managing and operating a network. Those features take actions to counteract network element failures based on alarms.

Additionally, it must be noted that the performance of the network is dependent on the subscriber traffic distribution in time and space, which subscriber traffic may be of varying importance and have diverse QoE requirements.


Page 18 of 79


Figure 1-4 Data consumption by proportion of area (Data from Viavi 2015 study)

Figure 1-4 illustrates the typical degree of geographic concentration of subscriber traffic demand that illustrates that over 90% of data is consumed within 5% of the network area and over 50% of the data is consumed by less than 1% of the area. The graphic represents analysis of geolocated call segment data across a whole country’s network.

Figure 1-5 Service offered at cell edge (Data from NGMN Vodafone study)

Figure 1-5 illustrates the variation of attainable subscriber throughput from cell centre to cell edge for a typical cellular deployment7, which, for an assumption of uniform subscriber density across the cell, illustrates that only subscribers in 1% of the cell area can experience peak data rate and that 50% of subscribers in the cell area will experience the cell edge rate8.

7 Without edge coverage amelioration techniques. 8 10% cell radius = 1% of area, 70% radius = 49% of area

90% of the data is consumed by less than 5% of the area

Over 50% of the data is consumed by less than 1% of the area!


Page 19 of 79


There are two physical factors that drive the concentration of traffic in limited geographies of the network irrespective of the geographic distribution of subscribers and subscriber traffic demand. Firstly, the subscriber traffic may be driven by the availability of high throughput rates associated with better Carrier to Interference and Noise Ratio (CINR) near to cell sites and secondly MNOs locate sites, to the best of their ability with information available at the planning stage, aligned with expected concentrations of traffic demand.

Figure 1-6 Real-world example of traffic hotspots vs cell site deployment in a cluster of cell sites. Cell site locations shown in black, hotspot locations with coloured contours, geographic bin-size 500m

Figure 1-6 shows a plot of an example of an actual subscriber traffic distribution vs cell site location9 that shows that while there is a correlation between the location of the traffic hotspots and the density of deployed cells, as would expected from the cell planning efforts of the MNO, the correlation is by no means perfect even to the coarse 500m granularity of the Figure. This suggests, therefore, that an optimum network configuration cannot be determined independent of knowledge of the actual geographic and temporal distribution of the subscriber’s service usage. Moreover, although not actually shown in the Figure, the location and intensity of the traffic hotspots are time varying. Consequently, SON will be able to produce better decisions if it is a driven by a subscriber centric approach that makes information about the subscriber’s geographic and temporal distribution of services available to the algorithm. Such an approach, that supports dynamic reconfiguration of resources, has the potential to reduce network CAPEX by avoiding designing a fixed configuration to meet the peak hour traffic demand. Figure 1-7 shows a practical example where a network optimisation is determined based on subscriber geolocation distribution.

9 It should be noted that all features on the Figure are represented on a 500m grid, thus the site locations are only an approximation to the actual positions, which results in an artefact where all sites are grid aligned.


Page 20 of 79


Figure 1-7 Practical example of subscriber geolocation determined network optimisation

The used subscriber application(s) may be determined either by a link to the application layer, potentially incorporating aspects of the application layer into the SON concept, or by Deep Packet Inspection (DPI) to determine the applications or class of applications that a subscriber is using.

Figure 1-8 Illustrating objectives of self-optimisation

Figure 1-8 summarises the objectives of SON in the RAN showing the over-arching objectives with respect to automated configuration and autonomous self-healing and the specific objectives related to optimisation of the air interface are listed. The optimisation process requires information about the radio channel experienced by the subscribers, the subscribers’ geographic and temporal distribution and, particularly for optimisation of quality of experience (QoE), information about the application and the subscriber profile. Additionally, the knowledge is required about the configuration

RU CU

RU CU

RU CU

S1 S

witc

h

X2 Switch

Backhaul Maximise air interface

capacity/ spectral efficiency

Minimise blocks/drops

Optimise QoE

Minimise cost of operations, through automated configuration

Minimise cost of maintenance, through autonomous self-healing

2°tilt change

Substantial improvement

in location quality

High drop area for vehicles

travelling along road

Before


Page 21 of 79


parameters whose values may be changed to effect optimisation, including the current state and allowed range of setting. These configuration parameters are referred to as “levers.”

2 Measurement techniques This section considers the measurements that are required to assess the performance of the transport (fronthaul/backhaul) SLA and the additional measurements that are required to support a joint SON process involving transport and the RAN/radio domain.

2.1 Measurements for performance evaluation of transport The transport monitoring tools which can be applied strongly depend on the transport technologies used in the backhaul & fronthaul and transport equipment capabilities. Using OAM mechanisms allows detection of network failures and launch of resiliency mechanisms (if necessary). Each segment of backhaul & fronthaul network should be monitored.

Additionally, the resolution and accuracy of the performance monitoring needs to reflect the class of service (CoS) of the flows carried on the transport. A major factor to consider here is the wide range of packet delay and packet delay variation requirements that are associated with the different functional splits. For example, the low splits carrying IQ samples, have a one-way delay requirement < ~75µS and delay variation <16nS [2], whereas high-level splits at the PDCP level have one-way delay requirement of ~30ms. Consequently, the reference clock and time stamping strategy and capability of the protocols will need to be considered for the different functional splits as the requirements get progressively stricter for the lower level splits.

An alternative to injection of OAM packets is to monitor performance directly using the user traffic carried by the network. Techniques for doing this at the IP layer have been discussed in the IETF in IETF draft IP Flow Performance Measurement (IPFPM) [11] (most recent draft just expired). Below we consider extending this approach to monitoring the transport layer at L2.

Several OAM standards have been released for the monitoring of network performance: ITU-T Y.1731 [7] provides in band tools and methodologies to measure performance parameters for the Ethernet layer, and the OWAMP [12], TWAMP [13] standards define metrics and methodologies for the IP protocol. Monitoring KPIs can look to these standards for the Ethernet and IP levels. However, these standards may require extension to deal with the new application fronthaul over Ethernet.

Hybrid approaches are also possible where OAM packets interested into the system for OWAMP or TWAMP may be tracked at intermediate nodes providing a finer granularity view of transport performance facilitating fault localisation.

At a high level the life-cycle phases of a network element (and its associated interfaces) are design, field deployment, operation and ultimately retirement. Each phase, except the last, has distinct measurement requirements, which creates a set of measurement equipment use-cases that are typically addressed by different physical equipment. These can be broadly characterised as,


Page 22 of 79


Measurement use-case Lab/Design Verification: The key problem to solve is verification of element design in a lab environment which requires device test and system test. Example tests are functional conformance (e.g. for TSN [14] shaping, pre-emption, scheduling) and performance tests (e.g. multi-port load simulation).

Measurement use-case Field: The key problem to solve is verification of equipment function during a field or cell-site visit which requires network performance test, turn-up testing and, if required, trouble shooting. Example tests are, latency/delay, frame loss, frame delay variation, shaping queuing, layer-2 Y.1564 [6], and BBU emulation to test RRH connection.

Measurement use-case Assurance: The key problem to solve is remote or centralized verification of network operation which requires turn-up testing, SLA/performance monitoring potentially on a per network slice basis, trouble shooting and providing of KPI performance information to SON. Example tests are latency/delay and Y.1731.

Considering the three families of SON functionality, self-configuration, self-optimisation, self-healing,

• The self-configuration family is supported by the assurance measurement use-case in scenarios where site visits are not required and by the field equipment use-case where site visits are required

• The self-optimisation family is supported by the assurance measurement use-case. The outputs will feed into dynamic network control and combined fronthaul/ RAN optimisation.

• The self-healing family is supported by the assurance measurement use-case in scenarios where site visits are not required and by the field equipment use-case where site visits are required (e.g., in some service recovery scenarios). The outputs will feed into dynamic network control and combined fronthaul/ RAN optimisation

The measurement use-case Lab/Design Verification relates to the development of the above families of SON functionality in a constrained lab type environment.

As networks become increasingly software defined one of the technologies being adopted to this end is deployment of software defined network (SDN) switches. However, “pure” SDN switches perform “stateless” packet lookup and forwarding, while Ethernet OAM mechanisms, as summarised above, are “stateful.” The 5G-Crosshaul project is investigating solutions to the problem, including managing the state information in the control-plane with an SDN controller or in the data-plane necessitating local storage of stateful information [15].

Furthermore, as an increasing number of components are becoming programmable the complexity arising from the multitude of changeable parts is likely to create a necessity to verify aspects of SON functionality off-line.

2.1.1 Ethernet performance tests To characterize and measure the impact and performance of the concepts under investigation in iCIRRUS, such as the implementation of a modified functional split, Ethernet performance should be measured. Relevant KPIs such as data throughput, latency, latency variation or packets errors can be theoretically easily measured with a protocol analyser if available.


Page 23 of 79


Performance may be measured on an end to end basis using, for example, a network analyser, or using in-line probing measuring the characteristics of the signal as it traverses the transport network. We first consider end to end testing and then present an example using in-line probing.

Figure 2-1 shows the elements of a basic radio access network, namely the baseband unit (BBU), the remote radio head (RRH) and the user equipment (UE). The figure also shows where Ethernet interfaces are present.

Figure 2-1 Setup for measurement of Ethernet performance with a protocol analyser.

With the help of a protocol analyser to generate traffic in the downlink (from protocol analyser to BBU) several KPIs can be measured such as the throughput in the backhaul interface for both the downlink and the uplink. Errors are also detected including CRC errors, oversized or undersized packets. Depending on whether a higher protocol such as IPv4 is transmitted, also IPv4 payload errors can be detected. Additionally, in a configuration as the one depicted in the figure where a loopback is made at the UE and the downlink traffic is sent back on the uplink, further end-to-end measurements can be performed by the protocol analyser. Such is the case of end-to-end latency tests (how long a packet needs to go to the UE and come back) or latency variation tests (how this end to end latency varies between two packets in the transmission flow). Since the number of sent and received packets is also counted and recorded, lost frame ratios can also be calculated. Additionally, a protocol analyser also enables the capture of packets in its reception ports and this can be used to compute other interesting parameters such as packet inter arrival time (the time difference between the arrivals of two consecutive packets).

Besides the aforementioned, limitations arise when it comes to measuring the performance of Ethernet in the Fronthaul. Figure 2-2 shows a possible setup to also monitor the fronthaul with the help of the protocol analyser.

Figure 2-2 Setup for end-to-end and fronthaul Ethernet performance monitoring with a protocol analyser.


Page 24 of 79


The main difference compared to the first setup is the introduction of a switch in the fronthaul. The switch is introduced to facilitate measurements in the experimental testbed. In case of a real deployment introduction of a switch solely for testing would not be justified from a CAPEX or OPEX viewpoint or considering the increase in latency and reliability reduction. However, if a switch were required to provide increased fanout from BBU estate to different RRH it might also be exploited for measurement purposes. This switch should perform packet mirroring so that all fronthaul traffic, e.g. in the downlink, is duplicated in the port connected to the protocol analyser. In such a configuration, we can measure the data throughput in the fronthaul as well as packet errors. Since the Ethernet packets in the fronthaul have a custom structure as described in [2] we cannot perform any latency analysis with the protocol analyser since timestamps and other identifiers are used and expected at certain packet fields. These fields are not considered for test purpose when creating the fronthaul Ethernet packets. Nevertheless, as in the previous setup, the received packets from the fronthaul can be captured and further processed offline to measure the inter arrival time. Another drawback might derive from the available number of ports in the protocol analyser. For a two 10G Ethernet port analyser, the Ethernet performance in the fronthaul cannot be monitored in parallel for the downlink and the uplink. With these limitations, the use of pluggable probes in the fronthaul becomes very interesting. Figure 2-3 shows a setup to monitor Ethernet performance in the fronthaul with pluggable probes.

Figure 2-3 Setup for end-to-end and fronthaul Ethernet performance monitoring with a protocol analyser and pluggable probes.

The introduction of pluggable probes in the fronthaul as depicted in Figure 2-3, could not only make Ethernet performance monitoring easier but it could also extend the monitoring capabilities to further measurements, for example, that may relate to new radio frame structures adopted by NGFI.

Historically, many BBU/RRH vendors have resisted use of 3rd party probes in favour of “own-brand” optics but, increasingly, operators are requesting on a more open approach that allows use of 3rd party optics. However, probes have their own failure modes so some care in their use as points of demarcation in the network is required. A demarcation point marks the point where communications facilities owned by one organisation interface with that of another [16]. A typical link geometry may involve a remote host that is connected to the network by one or more access segments under the operator’s control and one or more access segments under control of 3rd party providers; problems may arise at the host or in any of the link segments. If a probe is found to have


Page 25 of 79


detected a problem the operator needs to determine with a degree of certainty that it is not an issue with the probe itself.

Furthermore, the operator should achieve this without visiting the site to test the probe. For example, if a probe “disappears” this may be due to a power-down by the host or to a problem with the probe.

A combination of “slow OAM10” and “last gasp alarm11” back to the EMS allow for demarcation of probe loss due to environmental conditions, e.g. local power failure or host power off, and presence of 3rd party access segments. Slow OAM provides periodic messages between peer entities that allow the adjacent segment to detect the outage, but does not propagate to the operator in case of a 3rd party access segment. A “last gasp alarm” sends a message to the operator’s EMS that there is a power outage giving an unequivocal indication of power outage.

NEMs are building probing capability into network elements which is beneficial, however, the capability is not always sufficient to timestamp at the point of packet collection independent of network element loading and may be subject to restriction on availability across the network and interoperability between the necessary locations in the network. Consequently, independent interoperation of pluggable probes facilitates immediate operation and is a useful tool in the armoury of the network operator.

The move towards virtualisation of network functionality for increasingly high performance functions with the provisioning of bare metal as a Service, for example [17], may provide the ability to dynamically orchestrate and provision performance equivalent to that of a hardware probe at some future point. The following paragraphs consider the application of in-line probes. Contention in “trunks” that are formed within the fronthaul/midhaul architecture where different classes of service (CoS) are sharing the same medium can be characterized by the latency imposed on a traffic stream due to queueing.

10 OAM is a slow protocol with very limited bandwidth requirements. The OAMPDU terminates at the MAC layer so does not propagate end-to-end across the network. The absence of an expected OAMPDU indicates a failure. 11 A “dying gasp” is a message or signal a piece of equipment is programmed to send when a power outage occurs.


Page 26 of 79


Figure 2-4 Measurement set up for frame inter-arrival delays

Figure 2-4 shows a set up for characterizing contention in the trunk between the two Ethernet switches [1, 2]. The LTE software base station encapsulates the quantised In-phase and Quadrature (IQ) radio samples into UDP packets while a hardware-based traffic generator is used to generate background Ethernet traffic. The two traffic streams are logically separated by VLAN IDs. In this example, the LTE traffic is assigned a higher priority while background traffic represents a lower priority traffic stream. The trunk between the Ethernet switches allows both VLAN IDs to pass through and thus the two traffic streams will contend for access to the trunk. The radio slice duration Ts, in LTE is given by 1/15000 (≈ 66.7 µs). That is, the LTE radio slices are separated in time by an amount given by Ts. This means that the separation in time between received radio slices in each antenna port in the RU must be within the fundamental slice duration Ts, of the transported LTE signals. That is the inter-slice delay between received radio slices should be smaller than Ts. If this requirement is not met, then the subframe timings of the transmitted LTE signals will be violated. Therefore, background traffic frames that are inserted in-between LTE-carrying frames (due to contention) can bring the inter-slice duration close to this limit or cause it to be exceeded, depending on the frame size of the contended traffic. This situation is shown in Figure 2-5. Note that the inter-slice delay requirement can also be expressed as an inter-frame (Ethernet) requirement since the IQ quantised samples that

Measurement results (from Wireshark)

Ignore pairwise missing injection numbers

Calculate inter-frame delays

Ignore -ve values due to timestamp modulo

operation

Update inter-frame delay statistics

(a) (b)

(c)(d)

(e)


Page 27 of 79


form the radio slice can be encapsulated into several Ethernet frames. This is shown in Figure 2-5 where the radio slice requires two Ethernet frames to be transported.

One way to relax this inter-slice (or inter-frame) requirement, is using buffering at the RU. Buffering at the RU can allow for this requirement to be temporarily exceeded if on average it is not exceeded, with the averaging window size dependent on the size of the buffer in the RU. For example, if a whole LTE subframe is buffered at the RU then the averaging window will be equal to the subframe duration. Note however, that increased buffering in the end stations of the fronthaul can lead to higher end-to-end latencies which must be constrained for proper HARQ operation. In general, for CPRI-like traffic, such as that transported in the testbed of Figure 2-4, larger LTE-carrying Ethernet frame sizes are beneficial, due to improved overhead efficiency and reduced processing (leading to reduced delay and delay variation incurred by the packetisation process). But on the other hand, a large LTE-carrying frame size can have detrimental effects on the traffic flows generated by split functionality (MAC/PHY, low PHY split etc.) in an evolved fronthaul with mixed traffic. A certain amount of inter-frame delay for split traffic means that the buffer sizes will need to be large enough to be able to accommodate it. Therefore, the statistics obtained through the set-up of Figure 2-4 can be used for buffer management. Proper management will be important as excessive buffering can lead to longer round-trip delays.

Figure 2-5 The insertion of a background traffic frame in between LTE-carrying frames


Page 28 of 79


Figure 2-6 Testbed for measuring fronthaul latency and frame-delay variation.

Latency and frame delay variation measurements can be carried out using the testbed of Figure 2-6. Latency is an important KPI for the future fronthaul/midhaul. For a split within the PHY where the HARQ processing is centrally located, end-to-end latency should be constrained so that HARQ timings are not violated. The processing in the DU (from reception of uplink transmission to generation of ACK) is generally assumed to be complete after 2.75 ms (a typical vendor specification [18]). The HARQ ACK message, corresponding to an uplink (UL) transmission, needs to be received after three subframes following the subframe in which that uplink transmission occurred. Therefore, the additional round-trip time (RTT) allowed for the fronthaul will be in the order of 250 µs. This RTT allowance will need to include the air-transit and transport delays. For co-operative techniques, end-to-end latency is important due to channel state information (CSI) aging. Frame delay variation (FDV) measurements on the other hand are important fundamentally for PTP performance. Note that FDV can also be used for buffer management, however it would not offer any advantage over the inter-frame delay variation KPI. FDV monitoring (at least as carried out here) is independent of the end node transmission scheme (e.g. bursty or constant packet rate) which may be important for buffer management.

Measurement results (from Wireshark)

Normalise injection numbers

Separate timestamps based on FRP length (for port-based VLAN) or SFP

probe id otherwise

Ignore pairwise missing injection numbers

Calculate transit delays

Calculate FDVUpdate FDV and latency statistics

(a) (b)

(c)(d)

(e) (f)

(g)

Ignore -ve values due to timestamp modulo

operation

(h)


Page 29 of 79


2.1.2 PTP evaluation As outlined D3.2 [2] an RU will always have a requirement for frequency synchronisation to meet radio transmission requirements. Since CPRI is constant bit rate and locked to a reference then frequency synchronisation can inherently be transmitted in the CPRI link. Additionally, the RU is likely to have a requirement for time alignment between radio bursts transmitted from multiple sites, which can be achieved by aligning Time of Day. Time/Phase requirements will need to make use of CPRI timing channel, or if CPRI is being transported over Ethernet, as per the above discussion, then a packet transport solution for distributing Time of Day Phase will be needed, one such candidate is IEEE Std. 1588-2008. As CPRI may be embedded into an Ethernet stream, the CPRI reference clock might be used to manipulate the Ethernet reference, so that the Ethernet channel can be frequency locked to a selected CPRI feed if needed. For example, due to the timing needs of radio burst alignment between multiple cell-sites, which can be achieved by aligning Time of Day.

The goal of Precision Time Protocol (PTP) is to align the slave clock to the Master clock, and a by-product of this is delay estimation. PTP, also known as IEEE Std 1588-2008, operates by exchanging frequent12 [19] [20] messages between master and slave that facilitates clock synchronisation between them. PTP assumes that the delay is symmetrical in the uplink and the downlink due to the divide by 2 calculations performed by the slave. So, in some scenarios measurement of OWD may be required along with link assignment to minimise asymmetry.

The probing system allows for monitoring of the PTP estimation quality. As shown in Figure 2-7, the timing messages from the master clock (in this case the PRE-server) content with the in-line traffic. If scheduling is not used (for example by taking advantage of bursting or in-general using a time-aware scheduler), then the result would be an erroneous latency estimate.

Figure 2-7 Contention of timing messages with traffic.

The start of frame SOF IEEE 1588 [21] field is detected and the Event message is time stamped as it transitions between PHY and MAC, the use of hardware-assisted time stamping removes operating system and stack processing delays. Four time stamps are developed to compute the clock offset and round trip delay for a client relative to a server, illustrated in Figure 2-8. The components of a PTP

12 Typical synch rate 16 per second

GbESwitch

1 GbE

1 GbE

1 G

bE

Trunk

PRE

GbE

Switc

h

1 GbE

1 GbE

Timing message from PRE to probe

Timing message response from probe to PRE

SFP probeLTE trafficLTE traffic 1 G

bE

LTE

Points of contention


Page 30 of 79


system are, a GrandMaster Clock (GMC) and a slave clock in the client that is being synchronized, a boundary clock that regenerates the PTP message removing earlier path delays13, a transparent clock that adjusts the correction field in the synch and delay_req event messages14, and a management node for configuration/monitoring. Any offset in the clock frequency between the master and slaves will result in an additional timing error dependent on the propagation and transit times, such error may be minimized by using a mechanism to maintain frequency synch between master and slave, and it is assumed here that Synchronous Ethernet (SyncE), the combination of ITU-T G.8261 [22], G.8265 [19], G.8275 [20], is used for the purpose.

Figure 2-8 PTP ladder diagram for timing measurements

The testing environment for PTP evaluation needs to support Master and Slave emulation and time stamp monitoring and evaluation. Specific tests verify basic protocol functionality and connectivity, time stamp correction performance, packet delay variance measurement and SyncE performance testing. Additionally, the dependence of the test performance on background traffic load variation to perform stress testing is required. Figure 2-9 illustrates how PTP performance may be evaluated in a device test scenario.

13 Boundary clock has functionality of a switch with a built-in clock 14 Transparent clock has functionality of a switch with ability to measure packet residence time. If IPSec is used and the 1588 protocol is based on IP then transparent clock is limited to non-encrypted networks. Alternatively, if PTP is used directly over Ethernet, IPSec may be used to encrypt the user traffic but leave PTP exposed. However, it may be desirable to encrypt the PTP traffic to avoid an attack on the timing functions within the network.


Page 31 of 79


Figure 2-9 Testing PTP Performance in a device test scenario

To monitor an SLA in a live network deployment the same kind of test would need to be conducted without local access to the both sides of the DUT with test equipment. This can be accomplished by using time stamping with sufficient time accuracy and resolution at both ends of the link. The time stamps, and potentially sampled packets, would need to be exchanged over the link under test to allow collation for analysis.

Figure 2-10 Testing PTP performance in a field scenario

Figure 2-10 illustrates how PTP performance may be evaluated in a field scenario where OWD may be measured using two accurate clocks to allow comparison of PTP performance with a reference clock. As shown in the Figure, direct evaluation of the PTP accuracy is requires comparison of the PTP delivered time with an independent high accuracy clock source, shown as referenced to GPS in the Figure. This kind of direct measurement approach would be suitable for network configuration and problem investigation related to service restoration but would likely be costly for on-going performance monitoring.

Potentially, indirect mechanisms may be developed that looked at the variation of the exchanged PTP messages to provide some metric associated with time quality or stability. Alternatively, mechanisms that exploit differential time offset measurements by mobiles might possibly be investigated for feasibility albeit a lot of signal processing would be required to eliminate noise from such measurements.

DUT

Dual Port 10/100G

e.g. Transparent Clock function (TC)

Port 2 Slave Port 1

Master SyncE with PTP Traffic

SyncE with PTP Traffic


Page 32 of 79


2.1.3 TSN evaluation As already discussed in [2], one approach addressing the requirements for 5G networks and in particular to integrate CPRI-based legacy equipment in the future mobile fronthaul network is to apply time-sensitive networking (TSN) means.

The current understanding is that the minimum required TSN means are the TSN parts for synchronization and for queuing and forwarding. Since the synchronization is based on IEEE 1588 [13] or derivatives, this part can be addressed correspondingly to the procedure already described in Section 2.1.2.

For queuing and forwarding -regardless which subpart is considered (any scheduling mechanism or frame pre-emption) - the starting point for measuring and monitoring are latency and latency variation.

Any excess latency or latency variation introduced by the fronthaul, either due to contention or due to the scheduling delay introduced by a time-aware scheduler will tend to increase HARQ retransmissions if the inter-slice requirement is not met. But it is important to note that these retransmissions will be a result of exceeding the allowed inter-slice delay and not a result of exceeding the RTT HARQ budgets. As the LTE subframe timings need to be maintained over-the-air, the RU will need to schedule and transmit radio frame slices even if due to increased latency in the fronthaul, it has not yet received all the radio slice samples through the Ethernet interface. How the RRH does this will be implementation dependent but one example is through the insertion of dummy data (e.g. nulls) in the place of the missing samples. The number of retransmissions then becomes a useful KPI for monitoring the occurrence of excess delays. How much delay can be tolerated is implementation dependent but generally will depend on the amount and time duration of the buffering in the end stations as was previously discussed. For example, timestamps can be used in the evolved fronthaul that inform the RU when the buffer “play out” should take place. Once this happens, the processing in the RU will continue and a radio slice will be transmitted even if data that forms part of this slice has not yet been received through the fronthaul interface.

The measurement results of Figure 2-11 show the onset and establishment of HARQ retransmissions when the average inter-slice delay (or inter-frame delay) requirement is exceeded [3]. Although this result is for IQ transportation, a similar analysis can be applied in the case of the evolved fronthaul. For these results, two different LTE-carrying frame sizes are used (2000 and 4000 octets). The y-axis is normalised to the LTE-carrying Ethernet frame length. Therefore, the expected inter-frame delay at the onset of HARQ retransmissions (i.e. due to exceeding the inter-slice delay limit) due to contention with background traffic would occur at around a value of 2 (normalised). However, these results show that the onset of HARQ retransmissions occur at different values depending on the background traffic frame size. This behaviour can be explained as follows: The specific switch scheduler used in these experiments will attempt to balance the traffic load over the trunk port. However, the scheduler decisions are based on whole frames: For certain background frame sizes, there is no smooth transition into delays that are longer than that allowed by analysis (these would be approximately equal to 2 for the normalised results of the y-axis) and the reason behind this is the non-fractional relation between the LTE-carrying frame and the background traffic frame sizes. This is also the reason that the traces do not seem to follow a clearer trend.


Page 33 of 79


These results show the onset of HARQ retransmissions, but as the data rate of the background traffic increases, the occurrence of these events will be more frequent. This situation is shown in Fig. 4. The HARQ retransmission KPI can be analysed in unison with other KPI statistics, such as the inter-frame delay. Figure 2-13 shows complementary cumulative distribution functions (CCDFs) for the results of [23], [24], [25].

Considering these Figures, it is important to note that smaller frame sizes with a non-fractional relation to the LTE-carrying frame size can lead to longer delays. As was discussed for the results in Figure 2-11, the scheduler will attempt to balance the traffic load but this is problematic for non-fractional frame size ratios. For example, the 1500 octet trace will lead to larger delays than the 2000 octet trace when the scheduler inserts two background traffic frames for each LTE-carrying frame (which for these results is 2000 octets long). But fundamentally, these longer delays do not occur as often to induce more retransmissions (as shown in the results of Fig. 4). This fact is indicated by the circle annotation in the Figure around the 30 μs value, that shows the values in the delay statistics that are responsible for the increased re-transmissions with increased background traffic frame size. These results depend on the scheduler operation. For example, a packet-based round-robin scheduler with equal weight queues (like the one presented in [15, 16]), will result on a similar amount of retransmission for the 2000 octet frame size case but smaller number of retransmissions for the non-fractional frame sizes of 1500, 1700 and 1850 octets.

It is also important to note that these results indicate that when monitoring the KPI performance of the fronthaul, a moving average filter with a window size set properly (to take into account the amount of buffering in the RU) should be used. Otherwise the statistics obtained will not provide an accurate estimate regarding the onset and amount of HARQ retransmissions.

It can be concluded that the Ethernet switch scheduler operation would be a key component of the fronthaul and should be considered when making capacity predictions. Furthermore, the accuracy of performance predictions that are based on the statistics of the fronthaul KPIs will depend on whether the scheduler operation and the amount of buffering at the end nodes are properly considered.


Page 34 of 79


Figure 2-11 Comparison of measured and theoretical results for the inter-frame delay on the onset of HARQ retransmissions, for different LTE-carrying and background traffic Ethernet frame lengths. The plotted results here are

normalized to the LTE-carrying Ethernet frame length.

Figure 2-12 Transport block retransmissions versus background traffic Ethernet frame size for the same burst size and a bit rate of 50 Mb/s. The LTE-carrying frame size is 2000 octets


Page 35 of 79


Figure 2-13 CCDF plots of inter-frame delays and corresponding HARQ retransmissions. The circle annotation indicates the group of values that are responsible for the increased retransmissions with larger background traffic frame size.

Retx=retransmissions.

Figure 2-14 Illustration of the pre-emption element of TSN

Figure 2-14 illustrates the pre-emption as an example of an element of TSN. Figure 2-15 illustrates how TSN performance may be evaluated in a device test scenario. The Figure shows the generation of two streams of traffic to allow the elements of TSN to be evaluated.


Page 36 of 79


Figure 2-15 Turn-up and trouble shoot frame pre-emption, queuing and scheduling

The test environment requires traffic sources with variations in packet size and packet delay and analysis of resultant delay and packet delay variation, frame loss and integrity. Example tests are, investigations of pre-emption addressing data integrity/frame loss under varying frame size of the input streams, investigation of queuing addressing routing of packets based on priority or Virtual LAN (VLAN), investigation of scheduling addressing correct timeslot assignment based on SyncE/PTP synchronisation and assessment of packet delay variation. Additionally, the test set-up allows evaluation of performance under load variation (background traffic) and impairments (timing).

As discussed above about PTP performance assessment monitoring of a TSN SLA in a live network deployment would require the same kind of test as for the laboratory test of TSN in Figure 2-14, similarly, this may be accomplished by using time stamping with sufficient time accuracy and resolution at both ends of the link. The time stamps, and potentially sampled packets, would need to be exchanged over the link under test to allow collation for analysis.

In-life testing is expected that a variety of measure would be used including of live traffic measures and synthetic traffic injection in combination with time stamping. Live traffic measures allow validation of the actual performance experienced by subscriber traffic, whereas, synthetic traffic allows for sampled validation of the SLA and other performance metrics of the network independent of the presence or absence of live traffic.

2.1.4 Test suites At a high level, any test of a transport performance indicator requires that data packets are traversing the system and that the effect of the transmission through the system on those packets is determined and that performance is reported back to a management server.

The methods used to determine system performance also depend on the test scenario. For example, the capability of the network may need to be verified before it is used to carry live traffic, which is referred to as “out-of-service testing,” alternatively, the capability and performance of the network may need to be evaluated when the network is carrying live traffic, which is referred to as “in-service testing.”

DUT

Dual Port 10/100G Port 2 Traffic

Port 1a Traffic

Port 1b Traffic


Page 37 of 79


This gives rise to two modalities of test; active test where synthetic traffic is added to the network for the sole purpose of measuring network performance, which is the only solution for out-of-service testing but can also be used for in-service testing, and passive test where live user traffic flow is exploited to measure network performance, which can only be used for in-service testing.

Figure 2-16 Illustration of collecting performance data using an SFP probe

Figure 2-16 illustrates the use of an SFP probe to collect performance data following the data collection architecture, which is a proposed architecture for data collection. The network traffic passes through the probe and packets that meet a specific profile may be timestamped and are copied to a one or more network analysis software functions.

The IETF and the MEF have defined several test suites to assess Ethernet network capability. One of the initial standards was IETF RFC 2544, this provides an exhaustive set of tests for a single service type at a time and is suited to laboratory test and benchmarking. This was superseded by ITU Y.1564 that is designed to provide testing of a family of services that are operating simultaneously again focusing on out-of-service testing but able to provide a measurement of the network’s ability to deliver a given SLA.


Page 38 of 79


The ITU has specified ITU Y.1731 this has functions to perform Connectivity and Fault Management (CFM), which is the same functionality as IEEE 802.1ag, and Performance Management measurements of frame loss, frame delay and frame delay variation using an active test methodology.

ITU Y.1731 defines a structure for OAM frames that can be used to conduct measurements and exchange information about test results between points. For in-service test, more care should be taken to minimize disruption to the user data, consequently, measurements are made using injected data but are conducted on a periodic basis to minimize disruption. In Y.1731 test methodology a mechanism to test throughput is not defined as injecting packets to determine throughput would be disruptive to user traffic.

As mentioned above the alternative is to use passive test that leverages live traffic being carried in the network. A mechanism called IP Flow Performance Measurement15 (IPFPM) has been developed that addresses the challenge of identifying one or more packets at different points in the network by “colouring” IP frames using the ‘unused’ bits in the DSCP part of the frame header to allow measurement including loss and delay to be made.

Figure 2-17 Active test using an IPFPM based data collection mechanism

As indicated in Figure 2-17 the approach is to count and modify the selected packets en route from point A to Z using the currently unused three most significant bits of the Differentiated Services Code Point (DSCP) field. This creates a tag that allows specific frames and frame-groups to be tracked and monitored as they transit the network. The packets transitioning a probe are compared with a filter signature, the first N matches are tagged ‘A’ (e.g., 001) the next are N tagged ‘B’ (e.g. 010) and so on in alternating fashion. Additionally, if a packet is to be used for latency measurements or random traffic sampling they are tagged with ‘C’ (e.g., 100). Equivalent counters and filters are set up at point Z corresponding with those set as A. Consequently, differences in count between the ‘A’ or ‘B’ frames at point A and point Z indicates loss, and analysis of time stamps of packets tagged ‘C’ allows calculation of packet delay and delay variance. Subsequently, the bits of the DSCP field are returned to valid values to avoid other network elements behaving in unspecified ways.

15 The current IETF draft on IPFPM has expired at the time of writing but may be revived in future, however, products are already available in the market including from Huawei and Viavi


Page 39 of 79


Reports may be sent from the probes at defined intervals (i.e. 1 second, 60 seconds, etc.) and provide measurements of latency, delay variation, loss (by traffic class) as well as utilisation and packet counts.

2.1.5 Analytics and management approaches

Figure 2-18 service OAM life-cycle (MEF Forum) [26]

Figure 2-18, reproduced from the MEF-30 Service OAM Fault Management Implementation Agreement, splits the life-cycle of communications circuit into three main phases, 1. provisioning and turn-up of the circuit to verify performance to the SLA, 2. Performance management, is the circuit meeting the SLA and is the customer happy and 3. Fault management, sectionalise the problem, escalate to the responsible entity, and to identify and correct the problem. Over-arching these phases are analytics and presentation functions that provides applications such as flexible reporting with high-level summary and detailed QoS drill-down, trend analysis, and capacity planning.

These phases in Figure 2-18 exist independent of the OAM techniques and processes used to manage the Ethernet. However, standards exist to address most of the issues, but these may need to be extended or supplemented by other approaches to address the challenges presented by support of fronthaul. The existing standard’s framework is briefly summarised below and application to mobile backhaul/fronthaul is presented.


Page 40 of 79


Figure 2-19 Overview of Ethernet OAM [27]

Ethernet has a layered structure consisting of point-to-point links at the access layer, which are connected to form paths in the connectivity layer on top of which the service layer is hosted. Standardised Ethernet OAM functions are defined to address these layers and corresponding link segments summarised in Figure 2-19.

Figure 2-20 illustrates the iCIRRUS evolved fronthaul architecture as an example of a future radio network architecture. Considering the layers in Figure 2-19, working down from the top of the Figure 2-22, the access layer consists of one or more fronthaul segments from BBU pool to Ethernet switch and on to legacy RRH conveying encapsulated CPRI over Ethernet, fronthaul access segments from RRC pool to Ethernet switch and on to the RAU conveying NGFI over Ethernet, midhaul segments conveying PDCP type data from RRC pool to the Ethernet switch and on to a micro BTS over Ethernet, and segments conveying S1 type data from the core to the Ethernet switch and on to the respective RRC or BBU pools. As illustrated, some of the link segments may employ a common transport conveying both fronthaul, midhaul and backhaul. The connectivity layer would span the respective sets of link segments and the service layer would sit on top of those links.


Page 41 of 79


Figure 2-20 evolved iCIRRUS fronthaul architecture

As illustrated in Figure 2-19, each of the layers and segments would require demarcation if fault management and performance information is required from it.

Figure 2-21 Example demarcation in mobile backhaul network

Figure 2-21 illustrates example demarcation points in a mobile backhaul network that could be adapted for the evolved fronthaul of Figure 2-20, including Service OAM (SOAM) devices in at the cell sites, loop back at cell sites, and NID at cell sites as well as a SOAM device at the RAN/Core location. These are fed back data to a network operations centre (NOC)


Page 42 of 79


Figure 2-22 Analytics and management approaches

Figure 2-22 illustrates an alternative arrangement using Ethernet probes to collect measurement data. The probes demark key links where performance information is required. The probes are configured using a System Manager (SM) through the SM API and the filtered packets and the delivery of the configuration information is achieved via the Packet Routing Engine (PRE). The filtered packets are analysed in various analysis applications.

2.2 Measurements for performance evaluation in RAN/radio domain)

Figure 2-23 Measurements for performance evaluation in RAN/radio domain

RU CU

RU CU

RU CU

S1 Switch

X2 Switch

Backhaul RF performance

Subscriber geolocation

RF signal level RF signal quality

Throughput

MCS/CQI


Page 43 of 79


Figure 2-23 lists parameters that it is interesting to measure to determine the radio performance, namely, RF signal strength in uplink and downlink (indicative of path loss), RF signal quality in uplink and downlink (indicative of interference), the Channel Quality Information (CQI) (indicative of channel quality and used radio mode), the Modulation and Coding Scheme (MCS), and the throughput. Additionally, as described in Section 1.3, the subscriber geolocation is also important for generating optimal solutions with SON.

Figure 2-24 Measurement data collection

Figure 2-24 illustrates how such data is typically obtained in a current RAN. The radio performance data is obtained from a typical RAN, the internal measurements in the RAN that provide signal quality, strength, etc. are aggregated and reported to the OMC. The measurements include mobile neighbour measurements of signal strength and of the serving cell signal strength and quality. These are available for analysis either as statistical representations on a cell or subscriber basis or in the form of Call Trace Records (CTR). Similarly, internal information related to power control (PC), Timing Advance (TA), and MAC/RLC state information may be aggregated and reported to the OSS on a periodic basis. Typically, therefore, data for radio performance analysis and optimisation is obtained by analysing the data that can be obtained from the OMC. To be able to analyse such data on a per subscriber resolution and relate segments of call data from different cells or different radio connections to a subscriber or subscriber group it is necessary to correlate the RAN data with the subscriber identity, this may be provided by attaching probes to the core network. Similarly, such core network probes may also provide data about subscriber applications, awareness of congestion in the RAN, of network slicing layer. Specific information about application performance in the mobile is generally not directly accessible unless the mobile operates a specific application to collect and report such data. Consequentially, application performance in the mobile is typically inferred from analysis of measurement reports and MAC/RLC information on the base station side.

Within the testbeds based on the Open-Air-Interface (OAI) the data listed in the previous paragraphs will be available by the OAI performance and state reporting functionality.

RU CU

RU CU

RU CU

S1 Switch

X2 Switch

Vendor feeds

Core probes

ID Users and Applications…for RAN congestion Awareness (EPC)

MME

OMC


Page 44 of 79


Within 60 GHz high data rate testbed most of the performance parameters in the physical layer that are relevant for SLA monitoring or decision making regarding network reconfiguration can be measured at the receiver. These parameters can be, for example, RF signal strength, channel state, and the internal performance characteristics of the radio such as carrier frequency offset, error vector magnitude, etc. In the fronthaul investigated in iCIRRUS a modification in the distribution of functionalities between the BBU and the RRH is proposed. On the one hand, that which does not affect the downlink since the physical layer performance can still be first evaluated at the end user. On the other hand, a modification in the functional split does affect where the performance for the uplink is available.

Figure 2-25 Availability of radio performance parameters depending on the functional split.

Figure 2-25 illustrates this dependency, where a simple RAN architecture with one BBU, one RRH and one UE is depicted. Below each network element the available performance parameters are listed. For the downlink, on the right side at the UE, the same parameters can always be measured independently of the implemented functional split in the fronthaul. For the uplink, the available parameters depend on the location of the respective DSP. For example, a lower PHY split as described in [2] would realise the IFFT and CP insertion in the RRH, thus the RF signal strength could be evaluated at the RRH whereas the EVM that is estimated after channel estimation and equalisation could be first computed at the BBU. As the functional split is shifted higher in the DSP chain and a greater amount of signal processing is moved to the RRH more performance parameters will be available at the RRH.

Figure 2-25 also shows a logical connection from every single element to the SON controller. The speed of response of one or more elements of the SON functionality to measured or predicted changes in network performance needs to be taken into consideration when determining the physical location of those SON functions, hence location of the SON function or functions is a parameter in the optimisation. The physical connection to the SON controller may be rather centralized and not


Page 45 of 79


physically close to the BBU pool16. This implies that all relevant performance parameters must be transported to the BBU-pool and from there to the SON controller, to be considered in the SON decisions. That means on the one hand, that the downlink performance measurement evaluated at the UE must be sent back first over the air and then over the fronthaul. Dedicated wireless resources are required for the transport over the air and then, a high reliable transport over the fronthaul from the RRH to the BBU. The data throughput and requirements generated by this kind of traffic will not vary with the functional split. On the other hand, the uplink performance parameters will generate a variable data throughput depending on the functional split. Thus, shifting the split point higher in the DSP chain or to higher layers will increase the data rate of such feedback traffic because more L1 performance parameters will be now available at the RRH where more DSP is being implemented. Nevertheless, compared to the normal data traffic, the traffic carrying performance parameter will be negligible.

3 Opportunities for SLA definition and or enhancement arising due to evolved fronthaul / midhaul There are several ways in which the performance of the fronthaul will impact the radio performance. For example, the BER and/or packet loss in the fronthaul will impact on over-the-air BER (in LTE also on HARQ performance), the packet delay, packet delay variation in the fronthaul will directly impact on end-to-end latency (in LTE also on HARQ performance, retransmission), the frequency accuracy in the fronthaul will have an impact on the recovered clock accuracy and this on CFO and SFO (on over the air EVM) and the packet delay and packet delay variations will impact on time synchronisation accuracy and this on CSI (or other exchanged information) aging and CoMP performance.

Figure 3-1 Objectives of a radio SLA

16 Alternative SON architectures are possible that have a distributed architecture or a hybrid architecture combining aspects of centralised and distributed architectures but are not the primary focus for iCIRRUS.

RU CU

RU CU

RU CU

S1 Switch

X2 Switch

Backhaul

Maximize air interface capacity/ spectral efficiency

Minimise blocks/drops

Optimise QoE

Optimize QOE/QOS Across the Network Slice


Page 46 of 79


Figure 3-2 Objectives of a transport SLA

Figure 3-2 summarises the objective of the fronthaul SLA, that is, to avoid congestion on the respective transport segments, to achieve the respective SLA for each network slice, to achieve sufficient synchronisation to meet radio requirements and to support co-operative modes on the radio. A set of key performance indicators (KPI) should be monitored to determine if these objectives are being met.

Depending on offers, contracts and services etc., different KPIs are needed to evaluate or monitor the related SLAs. Additionally, the same KPI can have different objectives in relation with the associated Class of Service. For example, this is seen in the specifications of premium offers compared with best effort offers.

Figure 3-3 Reference scenario for KPI measurement

Hereafter, the main KPIs that can be found in a typical mobile radio service offer descriptions, with or without SLAs, are reviewed and presented with some illustrative values as mentioned in the specifications. Figure 3-3 provides a reference scenario for describing the respective fronthaul KPI and associated SLA.

RU CU

RU CU

RU CU

S1 Switch

X2 Switch

Backhaul

Avoid fronthaul congestion

Achieve sufficient synchronisation

Achieve SLAs for network slices

Avoid backhaul congestion

Avoid X2+ congestion

BBU RRH UE

Fronthaul over the air “Backhaul” End-to-end

Ethernet equipment

Ethernet equipment


Page 47 of 79


3.1 Availability/Downtime Availability refers to a system’s ability to accomplish the function requested by those accessing the system. Instantaneous Availability corresponds to the probability that a system can carry out the requested task at any given time, in any given state, without considering the background history. In the same way, interval availability gives the percentage of time over a contractual measurement period when the operational performance is met.

If a user cannot access the system, it is said to be unavailable or down. Downtime is generally used to refer to periods when a system is unavailable. Uptime and availability are not synonymous, as a system can be up, but not available, as in the case of a network outage.

Network or service availability is typically included in SLAs. It is linked to the confidence that a customer can have in the proper running of a network or service. SLAs formalize the availability objectives and requirements. Availability can be improved by optimized architecture, network topology, redundancy, high availability functions embedded in equipment etc.

Availability and downtime are usually key measures of an. Table 1-1 sets out the availability and the corresponding downtime expressed per year, month, or week.

Related to availability or downtime, is the recovery (restoration for a service) time that corresponds to the time required to fully recover from a failure. The average recovery time or repair time is referenced as MTTR (Mean Time To Repair or Recovery) in literature. This KPI results from the maintenance policy of the operator. In the service guarantees, the corresponding SLA is the Guaranteed Fault Repair Time (with different levels from 10 to 2 hours for instance).

In the same way, but related to production policy, the provisioning time corresponding to the time needed for the creation of a service requested by a customer and the modification time corresponding to the time needed for the evolution of an existing one can be committed KPIs.

If the Mean Time Between Failure (MTBF) is defined as the average time before the failure of the system, the relationship between the previous KPIs can be obtained:

𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴 = 1 − 𝑈𝑈𝑈𝑈𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴 = 1 −𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀

3.2 Delay Another important parameter in transmission is the delay or latency. There are two methods for packet delay measurements:

• One-Way Delay (OWD) that is the time it takes for a packet to travel from source to destination.

• Round-Trip Delay (RTD) that is the time to travel from the source to destination and back. The processing time needed at the destination system to respond is not counted, but the queuing and processing delays at the different nodes along the path contribute to the latency. RTD is more commonly used than OWD since only one observation point and clock are needed and


Page 48 of 79


easily done using the ubiquitous ping tool, for instance. This is also referred to as round-trip time (RTT) delay.

However, approaches based on ping or ICMP are limited to the order of ms accuracy, which may not be sufficient for the high-level splits and is not suitable for the low-level splits where latencies of the order of 75µS may need to me assured. Use of high accuracy high resolution timestamping is essential to achieve sufficient accuracy in such cases.

RFC2681 defines a precise measurement methodology for RTD, whereas OWD is treated in RFC2679. The importance of clock accuracy and synchronisation is discussed as well. OWD measurements assume that the clocks at both ends are closely synchronized. OWD is important for connections that use asymmetric paths or that have different quality of service in the two directions or asymmetric queuing. An application may be more sensitive to performance in one direction and RTD will not help much in that case.

For instance, in relation to the mobile backhaul offer in France, the maximum indicative KPI value for RTD, between a radio site and the central operator site for backhaul and aggregation segments, is 10ms for voice and data17 service. The delay is not a strict requirement the SLA just provides a typical value for information.

In principle, delays can be considered as additive metrics when the measurements are made in the appropriate conditions.

If a measurement times-out, the packet should be ignored as far as delay is concerned and counted as lost with undefined delay. This is accomplished by conditioning the delay distribution on arrival within a reasonable waiting time (the loss threshold) in coherence with the path or service under test. The time duration of evaluation is critical. As for all KPIs, the measurement sample is a key factor in the validity of the observations. Using quantiles is in general preferred to describe the distribution.

However, considering the fronthaul delay is now a strict requirement of the SLA with a low layer split having a strict RTT requirement of the order of 400 µs [2] whereas, for a high layer split, the requirement is of the order of 2 ms.

5G brings the potential for many new applications with tighter requirements and these are briefly reviewed in below Section 0.

3.3 Jitter (Delay Variation) The variation in the OWD of packets is sometimes called “Jitter” (or Delay Variation). This term is used in different ways by different groups, causing confusion, as described in RFC3393. Jitter commonly has two meanings:

17 Excluding best-effort data service.


Page 49 of 79


• The first one refers the variation of a signal with respect to a reference clock signal. In this case, the term “wander” can also be used and is more useful when measuring the quality of circuit emulation,

• The second definition is about the variation of a metric (delay) with respect to some reference value (average value or minimum value). This meaning refers to variation in delay where a single reference is chosen. This is the definition of the Packet Delay Variation (PDV) used for the 2-point Ethernet frame delay variation described in ITU-T Y.1563. When the reference packet is the one with the minimum OWD, the PDV is positive (or zero). The shape of the PDV distribution is identical to the delay distribution, but shifted by the reference delay.

The IP community (MEF, IETF) defines the term Inter-Packet Delay Variation (IPDV) (17) (or IFDV for Inter-Frame Delay Variation for Ethernet) as the difference between the OWD of selected pairs of packets inside a stream of packets belonging to the same CoS instance. IPDV represents the network’s ability to preserve the spacing between packets. IPDV can take positive and negative values and the mean value should be zero, unless some long-term delay trend is present. A slow delay change over the life of the stream or a frequency error between the clocks can give a non-zero mean. IPDV is sensitive to the sequence of delays, the packet reordering and the packet-loss distribution.

Both definitions (PDV and IPDV) are compliant with RFC3393, because different packet selection will produce either form. RFC5481 analyses the two metrics to determine the most appropriate applications for each form.

As mentioned in the previous Section on PTP, approaches based on ping or ICMP for assessing jitter are limited to the order of ms accuracy, which may not be sufficient for the high-level splits and is not suitable for the low-level splits where jitter of the order of nS may need to me assured for CPRI type traffic. In such cases, use of high accuracy high resolution timestamping is essential.

IPDV is easy to extract from a stream of delay measurements and clocks do not require careful synchronisation. PDV measurement is more demanding than IPDV, as it is more sensitive to skew (clock-frequency error). The accuracy can be preserved by reducing the measurement time interval. The packet size is a parameter of the measurement.

Jitter is important for sizing buffers for applications requiring regular delivery of packets as for real-time services as voice and video. Changes in the delay variation can be linked to changes in the queue length process at a hop or a combination of hops. PDV is more reliable for buffer size and queuing time estimations.

Values of PDV may be zero or positive, and quantiles of the PDV distribution are direct indications of delay variation. RFC5481 proposes that an SLA of the form "no more than x% of packets in a measurement interval shall have PDV >= y ms, for no less than z% of time" is relatively straightforward to specify and implement. The ITU recommendation Y.1541 introduced the notion of a pseudo-range when setting an objective for the 99.9th percentile of PDV. The conventional range (max-min) was avoided for several reasons, including stability of the maximum delay. The 99.9th percentile of PDV is helpful to performance planners and in design of de-jitter buffer sizes, even those with adaptive capabilities.


Page 50 of 79


IPDV is not easy to summarize. The mean value is typically zero and the range does not match the needed de-jitter buffer size. Some prefer taking the absolute value of IPDV, but this approach is sufficient only with a symmetric distribution around a mean of zero. IPDV does not have any single summary statistic that relates to a physical quantity. Thus, it may be difficult to specify an objective for IPDV, except for a comforting SLA without clear guarantee on the service, contrary to PDV.

For instance, in the mobile backhaul wholesale offer in France, maximum jitter for voice services is indicated at 3 ms between a radio site and the central operator site. However, some service requirements for 5G are expected to be far more stringent, where tactile internet and mission critical services require delays of 1ms or less and consequentially, jitter values which are yet unspecified but which will also be much lower.

For a low layer split there is a strict delay variation requirement, which flows from CPRI, of +/- 16 ns, [2] whereas, for a high layer split the requirement is like backhaul.

5G brings the potential for many new applications with tighter requirements and these are briefly reviewed in below Section 0.

3.4 Loss A loss occurs when a packet is not received by its destination. The sensitivity to loss of individual packets, as well as to frequency or bursts of loss among longer sequences depends on the application itself. Therefore, the statistical properties of the loss events (average, loss burstiness patterns, loss free seconds, loss probability, etc.) are interesting for evaluating the effect on the application performance. Loss can be evaluated at different levels: physical layer (bit error at level 1), data link level (frame loss at Layer 2), network level (packet loss at Layer 3), etc. Loss properties should be evaluated for each relevant protocol separately since routers may forward packets differently per their protocol.

One-way loss and round-trip loss are defined. One-way loss (RFC2680) is the most useful characteristic because the network load is rarely symmetric and when paths between source and destination are different or asymmetric. Nevertheless, both one way and round-trip loss measurements can be important depending on the application.

For instance, in the mobile backhaul wholesale offer in France, maximum frame loss ratio for voice and priority data services is indicated at 10-5 and 10-3 for no priority data service between a radio site and the central operator site for each direction. If we assume statistical independence of packet loss in both directions, round-trip loss can be derived from the one-way loss measurements in both directions, mixing the properties of both paths.

For a low layer split the there is a strict requirement, which flows from CPRI, for a BER of the order of 10-12, whereas, for the high layer split the requirement is like backhaul at a frame loss rate of around 10-5.


Page 51 of 79


3.5 Throughput Bandwidth (or bitrate) defines an amount of data per time unit. Related to it, different terms can be defined to avoid confusions, following the Network Monitoring Working Group (NMWG) terminology:

• Capacity: the maximum amount of data per time unit that a hop can carry • Utilisation: the aggregate traffic currently passing on that hop • Available bandwidth: the maximum amount of data per time unit that a hop can provide given

the current utilisation • Achievable bandwidth: the maximum amount of data per time unit that a hop can provide to

an application, given the current utilisation, the protocol used, and the system capability including the host hardware. It corresponds to the throughput a real user application can achieve and differs from what a network engineer can obtain.

The network layer at which bandwidth is measured is an attribute of the measurement because framings and overheads affect the results. The selection of the observation time interval for a bandwidth measurement is important due to the burstiness behaviour of the traffic. The sampling interval and measurement accuracy is critical and requires a good knowledge of the applications. One of the principal specifications of a network service is the associated bandwidth. Nevertheless, the way it is specified or guaranteed can vary greatly.

The introduction of NGFI, while not changing the SLA expected by the service user, potentially changes the way the underlying KPIs are measured and potentially offers scope for new mechanisms for supporting SLAs, for example link redundancy.

Table 3-1 Example latency and bandwidths for example functional splits based on 2x2 MIMO LTE [28]

What might 5G bring for Latency and throughput requirements? 5G is still in its development stage and, while the specifications for the air interface for the 1st phase of 5G is more or less agreed, experience with 3G and 4G has always brought new waves of performance enhancement, for example, HSPA for 3G and LTE-A for 4G. So, in this Section we consider some of the visions that have been set out for where the requirements may ultimately lead.

The GSMA, the association of GSM mobile network operators and allied parties, has investigated applications that might drive radio network requirements for 5G and their findings are summarized in Figure 3-4, which indicates that tactile internet may be one of the most demanding applications with latency of the order of 1ms and throughput requirements more than 1Gpbs.


Page 52 of 79


Figure 3-4 Bandwidth and latency requirements of potential 5G use cases [29]

However, it might be the case that applications, yet not envisaged, may demand higher bandwidths. For example, Figure 3-5 indicates how the maximum theoretical downlink speed has been extended in the recent 3G and 4G generations to attain bandwidths not envisaged at the outset and proposes “a minimum theoretical upper limit” for 5G of 10Gps per user. However, even this limit is not seen as the limit in Samsung’s vision for 5G that envisages a limit of 50Gbps, Figure 3-6.


Page 53 of 79


Figure 3-5 Maximum theoretical downlink speed by technology generation, Mb/s (*10 Gb/s is the minimum theoretical upper limit speed specified for 5G) [29]

Figure 3-6 Ultra-fast data transmission [30]


Page 54 of 79


Huawei has considered what such bandwidths as those introduced in the previous Figures in this Section may mean for the 5G access network and summarised this in Figure 3-7, that envisages delivery to the end user of 10Gb/s, backhauls to clusters of microcells at 100Gb/s, to macro cells at 50-80Gb/s and aggregated in trunks at up to 100Tb/s. If a CPRI style fronthaul split were imposed in such scenarios, fronthaul throughput requirements of the order of 100Gb/s would result.

Figure 3-7 Overview of a potential 5G radio access architecture [31]

3.6 Which parameters should be monitored The following QoS KPIs, including latency, jitter and packet loss ratio should be monitored end-to-end between the BBU and Radio Controller (or first core network element in case of LTE) for backhaul and between each RRH and BBU pool for fronthaul.

There might be disproportions in traffic volume of different operators or mobile technology due to different bandwidth needs. That's why it is important to measure the throughput.

If backhaul & fronthaul provided by 3rd party, then this operator should also monitor the parameters which were defined in SLA (e.g. connection bandwidth provided) to be able to quickly solve the issues (if any) and avoid potential penalties. Also, the load of the backhaul and fronthaul links must be monitored to know whether capacity upgrades are needed.

Several parameters should be monitored at RAN level (by RAN operator) per each mobile operator such as: throughput, latency, jitter, packet loss ratio. If transport provided by 3rd party, then this backhaul operator should monitor KPIs defined in SLA at the backhaul network level.

In the context of the iCIRRUS backhaul & fronthaul study, Quality of Service refers to the performance of the connectivity for all user, manage and control plane traffic, which may include (but is not limited to) the following:


Page 55 of 79


• The Round-Trip Delay • The Jitter (Delay Variation) • The Frame/Packet Loss Ratio • The Availability • The Throughput

4 Opportunities for SON reconfiguration In the iCIRRUS architecture the adjustment of the split of functionality between CU and DU and the resource made available for fronthaul become parameters for configuration and optimisation. Thus, the SON features that are deployed in the RAN to simplify network planning, deployment, operation, maintenance and optimisation must be extended to consider the expansion of the SON reconfiguration solution space due to this configurability.

As set out in Section 1.3, SON features may be categorized into three main families, these are reconsidered in a new fronthaul-coloured light,

• Self-configuring: automate many of the manual steps required for planning and deploying a wireless radio network. These self-configuring features encompass in addition to the indicative list indicated in Section 1.3. For example, plug and play configuration of fronthaul including, fronthaul path, fronthaul redundancy/protection, fronthaul buffer/latency trade-off, flow bandwidth latency constraint and priority allocations to fronthaul allocations within a transport fabric, where such configuration is responsive to functional split between the centralised baseband functions and the radio unit, the expected set of macro cells and small cells to be activated, and the radio transmission/reception modes to be supported in a region.

• Self-optimizing: automatically and continuously optimize the network. These self-optimising features encompass in addition to the indicative list indicated in Section 1.3. For example, dynamic optimisation of the fronthaul configuration including the options indicated in the self-configuring bullet point above, where such dynamic reconfiguration is responsive to factors including actual or predicted changes in cell loading arising for example from network traffic trends as well as from changes to mobility parameters, transmission power and antenna pointing, the balance of traffic between network layers, interference management, cell activation and deactivation, and may also include changes in the functional split between the central baseband unit and the remote radio unit.

• Self-management and self-healing: reduce the engineering tasks necessary for managing and operating a network where possible automate many of the manual steps required for the restoration of service. Self-managing features encompass, autonomous fault discovery based on alarm interpretation and fault diagnosis and autonomous solution determination and deployment, including fronthaul path switching, fronthaul link reconfiguration/repurposing and radio activation/deactivation.


Page 56 of 79


4.1 Combined RAN/Radio and transport reconfiguration There are several drivers for dynamic joint RAN/Radio and x-haul reconfiguration.

• Fronthaul is no-longer fixed data rate as CPRI compression may be applied, different functional splits between the central baseband unit and the remote radio units may be applied with NGFI, and different co-operative modes for radio transmission/reception may be applied requiring potentially delivery/collection of user data to multiple points and exchange of resource allocation and CSI information. Thus, fronthaul rate becomes a function of subscriber traffic volume and geographical/temporal distribution.

• Statistical multiplexing is made possible; however, this leads to an increased potential for non-deterministic latency and packet delay variation.

• Radio co-ordination mode drives the fronthaul requirement. As scheme complexity and real-time intensity moves from Inter-Cell Interference Coordination (ICIC) through to joint processing CoMP the fronthaul demand gets increasingly intense in terms of bandwidth, 1-way delay for user data delivery, time of day alignment between transmission points, latency asymmetry, and 1-way delay for inter-scheduler information exchange.

For a distribution of subscriber traffic demand there will be several options in the SON configuration solution space. For example, a solution may exist that services the demand solely using macro cells potentially with the assistance of a CoMP transmission/reception mode, alternatively, the traffic may be situated such that a solution activating a set of small cells provides equivalent or better service. The SON process would then determine the optimal solution considering the trade-off between energy consumption, x-haul usage, robustness/protection and other KPI of interest.

4.1.1 Choice of co-operative mode of operation Figure 4-1 summarises the different categories of co-ordinated multipoint transmission schemes and application scope. For example, schemes may be intra-site, requiring only local co-ordination of data and information, inter-site requiring sharing of data between remote sites – which is facilitated by C-RAN, or hetnet requiring sharing of data between macro cells and their nearby small cells. The ease with which data, CSI and resource allocation is co-ordinated is facilitated by the RAN architecture and the type of backhaul/fronthaul/x-haul deployed. The co-ordination may be targeted to benefit single users or multiple users. Further, there are disparate techniques in uplink and downlink. Considering uplink, joint reception with joint equalisation is the most demanding on fronthaul, the requirement is eased by combining soft decisions rather than raw data. Fronthaul demand is reduced further by using dynamic point switching so that at any one-time user data received from a single point and further still by co-ordinated scheduling that just requires exchange of resource allocation and CSI. Similarly, for downlink, joint transmission with coherent transmission is the most demanding requiring very tight inter-point latency control. Fronthaul demand is reduced by using dynamic point switching so that at any one-time user data transmitted from a single point and further still by co-ordinated scheduling/co-ordinated beamforming that just requires exchange of resource allocation and CSI.


Page 57 of 79


Figure 4-1 family of co-operative multi-point schemes (NGMN CoMP Evaluation and Enhancement)

Figure 4-2 map of co-ordination architecture to backhaul (fronthaul) requirement

Figure 4-2 shows a mapping of the backhaul (fronthaul) requirement with the bottom of the chart showing high latency (relaxed latency requirements) and low bandwidth and the top low latency (strict latency requirements) and high bandwidth, where the bottom axis shows the degree of co-ordination required, which can be mapped directly to the level of the functional split in an NGFI based system. Figure 4-3 illustrates possible RAN architecture configurations, on the left a “classic” C-RAN configuration with a central baseband pool facilitating ideal co-ordination, where on the right is a distributed architecture D-RAN with a central-coordinator that relies on exchange of CSI and allocation information been discrete entities.


Page 58 of 79


Figure 4-3 Exemplary RAN architectures (NGMN CoMP Evaluation and Enhancement)

The introduction of one of the co-operative multi-point techniques shown in Figure 4-1 can significantly improve the throughput of UEs at the cell edge in interference-limited scenarios. The decision whether to implement CoMP or which kind of co-operative technique should be performed, can be dynamically and optimally made in a flexible C-RAN architecture as that proposed in iCIRRUS. Additionally, the consequence of such decision for the overall architecture must be considered, i.e. how does CoMP change the functional split in the signal processing chain and thus the fronthaul requirements e.g. in terms of latency and data rate.

Taking joint transmission (JT) CoMP as a reference, the decision of switching to this co-operative mode of operation will be based on several KPIs. Since CoMP aims to maximize throughput at the cell edge by minimizing inter-cell interference (ICI), the signal to interference noise ratio (SINR) will be one of the parameter to consider, better using the geometry factor. Additionally, the mobility class must also be considered since co-operative techniques are only used in slow moving UEs, to avoid CSI aging. In JT CoMP a cluster of DUs performs joint signal processing to cancel the mutual interferences between adjacent cells. The information exchange between these DUs depends on the cluster size and this can dynamically change depending on the interference situation at the UEs, which depends itself on the antenna down-tilt and UEs speed. In [32] it is shown how a larger antenna down-tilt limits the interference spread into adjacent cells and thus the average cluster size. That is due to main beam direction hitting the ground at shorter distances, eventually not overpassing the geographical cell boundary. So, a decision regarding the use or not of CoMP and the size of the co-operative cluster should be made based on at least, the level of interference measured at UEs, the antenna down-tilt, and the UE speed.

The decision of switching to CoMP will change the distribution of the signal processing between DU and RU as described in D3.2 iCIRRUS - Preliminary Fronthaul Architecture Proposal [2]. In that deliverable, the iCIRRUS project proposed to set the split point right after the FEC in the downlink for the non-cooperative scenario and for the co-operative one, in which case, the co-operative processing would be performed at the RU in a partly distributed manner. For the uplink, the split would be set right before the FEC for the non-cooperative scenario and would be shifted lower in the chain in case of cooperation is needed, to shift the joint processing into the DU. Thus, this decision will have a direct impact on the required fronthaul throughput. In the downlink, switching to CoMP will increase the required data rate compared to the non-cooperative case since, e.g. for JT CoMP, the scheduled data from other cells, and the channel state information (CSI) of the UEs are made available to be processed jointly with the desired data. That has been traditionally part of the X2 interface which is now


Page 59 of 79


transmitted over the fronthaul. In the uplink, the impact will be even greater since setting the split point at the lower PHY for CoMP will only slightly reduce the data rate compared to the transmission of digitized samples while resulting in a constant data rate. Additionally, here the data from other cells are also made available to be processed jointly at the DU. A change in the cluster size will change proportionally the required fronthaul bandwidth. Apart from the data rate, latency and synchronisation must also be guarantee in the fronthaul for a successful CoMP. First, low latency in the fronthaul paths of co-operative RUs avoids CSI aging. The fronthaul paths under this constraint might change as the cluster size changes. Additionally, delay asymmetries between DU and co-operative RUs should be avoided or otherwise compensated for a synchronized transmission of data and not incur CSI aging. The importance of synchronisation in CoMP scenarios has been extensively analysed in the literature [33], [34], [35] with the conclusion that the local oscillator used to derived all required clocks, e.g. for sampling and up-conversion, and the reference clock it is usually locked to need to be precise in order to avoid carrier frequency offset (CFO) and sampling frequency offset (SFO). Moreover, all co-operative RUs should be locked to the same reference clock. The NGMN Alliance has summarized in [36] different requirements for different CoMP schemes. The conclusions for the backhaul can be translated to the evolved fronthaul in the C-RAN architecture considered in iCIRRUS.

Nevertheless, the most challenging requirement might be to meet the overall reconfiguration time, including the decision making and execution changes in a coordinated manner. Different timescale can be identified depending on the access network deployments and of course on the UE speed. In that way, on the one hand deployments such as UMTS or LTE where cells are rather large and antenna down-tilts are small, a more relaxed reconfiguration time constraint in the order of one second could be assumed. On the other hand, access deployments for LTE-A or future 5G system will count with smaller cells and stronger antenna down-tilt yielding to a more dynamic CoMP scenario that might require changes in the cooperation mode in the order of hundreds of ms.

4.1.2 Dynamic path changes The ability to dynamically change the fronthaul or backhaul path as part of joint RAN/fronthaul optimisation adds an extra dimension to the potential configuration/reconfiguration space. In this Section, several reconfiguration scenarios are examined. One aspect considered is the dynamic switching of small cells between active and low power/sleep modes as another “lever” to help optimise provision of service considering energy consumption, fronthaul resource consumption and subscriber location. Such operation would probably require KPIs related to energy consumption and consideration of the time to transition between active and sleep states.

The routing of the physical transport infrastructure is chosen to highlight the potential choices that may be made and, to some extent, serves to highlight that knowledge of the configuration of the physical transport links becomes a key input into determining possible configurations and so to SON. In the Figures the allocated resources (bandwidth, latency constraint) for fronthaul on the transport network is indicated by the width of the purple lines, links that exist but carry no traffic are shown as dotted lines, radio units (RU) that are active are shown in green and inactive in yellow, and switches are shown as white crosses on blue background. For illustrative purposes a single mobile is shown


Page 60 of 79


either with multiple radio connections, indicating CoMP operation, or single radio connection indicating conventional operation.

Figure 4-4 Transport network with unbalanced routing of fronthaul links

Figure 4-4 shows a scenario ‘A’ where the fronthaul traffic for all cells is routed via the single link at the top and branches out from there to the rest of the active cells. In this scenario, the cells supporting one or mobile operating in a macro cell CoMP18 mode will have a more challenging resource constraint and this constraint is met by (dynamic) configuration of prioritisation and or resource partitioning.

Figure 4-5 Transport network with balanced routing of fronthaul links

Figure 4-5 shows scenario ‘B’ where the (dynamic) route balancing is used obtain the objective of meeting the different fronthaul resource constraints that were presented in scenario ‘A.’

18 The exact constraint will depend on which of the family of co-operative modes is deployed in up and/or downlink and may constrain, time aligned delivery of user data to/from multiple points, time of day alignment between multiple sites, latency constrained exchange of scheduling and channel state information.

BU RU A.

BU RU B.


Page 61 of 79


Figure 4-6 Transport network with macro cell CoMP deactivated to provide fronthaul resource for small cells

Figure 4-6 shows scenario ‘C’ where the geolocated subscriber traffic “vector” is best met by using a combination of macro cells and small cells, the transport resources to supply fronthaul for small cells (fronthaul highlighted in green) are obtained by freeing-up resources by deactivating macro cell CoMP and re-rooting the traffic.

Also, implicit in the actions taken in the scenarios above is (dynamic) re-routing of the fronthaul through the transport network to restore service caused by network outage or network element outage, or pre-emptive re-routing to modify the degree of redundancy/protection for one or more parts of the network. Moreover, such a change may be made in accord with a (dynamic) change in the functional split to reduce or, conversely, to exploit available resources.

Consequentially, the SON process requires access to additional data to perform configuration, optimisation and healing actions. This includes,

• Latency budget and contribution of network components, co-ordination tightness requirements (e.g., CoMP, ICIC, NAICS) for sets of wanted and interfering data and for sets of wanted and interfering radio units, and the bandwidth budget and element network element requirements for each split.

• A description of the physical topology of the fronthaul network as this delimits the possible configuration space for the fronthaul, correspondingly methods for topology discovery and description are required.

These requirements also dictate that new data collection points or interfaces are required that collect data at the new architectural split points, maintain availability of existing radio data and allow monitoring of possible extensions of X2-like functionality towards the radio units.

BU RU C.


Page 62 of 79


Figure 4-7 How many fronthaul links fit into a transport trunk?

Figure 4-7 illustrates the conceptual problem of mapping the dynamically varying fronthaul requirements onto a set of fronthaul resources that are mapped to an X-haul transport resource that shows that a mechanism to determine how many fronthaul links with bandwidth requirement Xi and latency constraint Yi will fit onto a given transport trunk.

The SON scheduler can work in unison with the probing and software defined networking (SDN) entities in the fronthaul as shown in Figure 4-8. The SON part can instruct the SDN controller to implement longer-term adaptations in the fronthaul while the probing system can allow for fast adaptation based on monitored KPIs over short time periods. One example is the implementation of dynamic traffic steering and there are a few use-cases for this:

• When LTE and other Ethernet background traffic interact in a fronthaul link. If a KPI exceeds some threshold value, then the system will “steer” the background traffic (or part of it) into a second trunk link so that the threshold value (for example latency) is not exceeded anymore.

• Switching protection • For load balancing based on statistical multiplexing gains. • Inter-VLAN steering, for inter-RAT or intra-RAT over-the-air load balancing (assuming VLAN

IDs are used to address different RUs or sectors within RUs). • Inter-trunk load balancing (i.e. destination RU does not change but requires more capacity

due to temporal variation in the cell load).

The steering is carried out in SDN fashion, with an SDN controller exchanging OpenFlow messages with the Ethernet switch(s). KPI extraction from the probing system and the SDN controller are co-located in the fronthaul “intelligence unit” which can be a general-purpose server.

Vlans for fronthaul Xi MHz BW, Yi ms Latencies…

10/100G Ethernet


Page 63 of 79


Figure 4-8 A fronthaul “intelligence unit” where KPI monitoring is combined with SDN techniques for fast fronthaul adaptations.

4.2 Combined D2D and transport reconfiguration The Device to Device (D2D) communication is vital in future communication networks by establishing direct communication link between two devices. It is necessary to have central control of D2D communication to be able to provide reliable and secure services as well as to optimize the global system performance (including spectrum efficiency, energy efficiency, etc.). Therefore, the design of control signalling between devices and central office is important and will affect the performance of D2D communication crucially, even though the network can benefit from traffic offloading from the central network to D2D, [37], [2].

It is noticed that many of current applications have critical delay requirements for both setup period and in-communication period. Compared to the communication delay for two devices in traditional cellular networks, the delay of in-communication period of D2D communication can be much short since the data traffic can be transported directly from source to destination. However, the set-up delay


Page 64 of 79


of D2D communication, which should be shorter than the maximum tolerant delay for different application, depends on the round-trip delay of the network as well as the processing delay for running control protocols of D2D communication. The setup delay of D2D communication is unneglectable in practical systems and thus becomes one of the bottlenecks of the D2D communication.

The setup delay of D2D communication, denoted by δD2D, can be estimated as the product of round trip delay, denoted by δround, of the system from a device to central office multiply by the times of handshake (Ths) needed in D2D setup procedure, which can be shown as:

δ𝐷𝐷2𝐷𝐷 = δ𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 × 𝑀𝑀ℎ𝑠𝑠

where 𝑀𝑀ℎ𝑠𝑠 can be estimated to 3 [38], [39]. The round-trip delay of control signalling consists of the BBU hotel processing delay, δ𝐵𝐵𝐵𝐵𝐵𝐵~1 𝑚𝑚𝑚𝑚; the wireless transmission delay δ𝑡𝑡𝑟𝑟~1 𝑚𝑚𝑚𝑚; the device processing delay δ𝐷𝐷~1 𝑚𝑚𝑚𝑚 and the fronthaul transmission delay δ𝑓𝑓𝑟𝑟𝑟𝑟𝑟𝑟𝑡𝑡ℎ𝑎𝑎𝑟𝑟𝑎𝑎 in iCIRRUS structure. Therefore, the fronthaul delay threshold can be expressed as

δfronthaul = [δD2D

Ths− (2 × δtr) − δD − δBBU]/2

Based on the acceptable D2D setup delay of different applications, threshold for the fronthaul delay can be calculated to determine whether it is suitable to run an application via D2D communication. For instance, the possible fronthaul threshold values vs D2D setup delay requirements are listed in Table 4-1 These delays relate to applications current at the time of writing. It is expected that applications associated with 5G will have a range of delay requirements some of them considerable tighter than indicated in the figure, for example, applications associated with “tactile-internet” are expected to have RTT of the order of 1ms. The information can be used to notify the devices by SON whether its application is suitable for using D2D link to reduce the inefficient D2D request signalling, even though two communicating devices are in proximity.

Acceptable D2D set-up Delay requirement

Fronthaul Delay (Threshold)

δD2D<100ms 10.66 ms

δD2D=300ms 44.00 ms

δD2D=500ms 77.33 ms

Table 4-1 Example of Fronthaul delay threshold vs D2D set-up delay

The network structure in iCIRRUS architecture considers different function splitting points between RRH and BBU hotel. For instance, a part of the physical functions is shifted from BBU pool to RRHs to be able to achieve better system performance. For D2D communication underlay iCIRRUS


Page 65 of 79


architecture, the fronthaul transmission delay requirements would be like the conventional C-RAN systems. Therefore, it is important to have SON to prevent massive unnecessary signalling overhead by limiting the D2D set-up under different application scenario. However, the fronthaul delay requirements could be fixed to a minimum threshold to support D2D set-up under different application scenarios if part of the L2 functions could be shifted from BBU hotel to the RRH as well. That is, the RRHs can collect the signalling information related with D2D set-up, manage the collected information locally per the instructions from BBU hotel and feed back to the D2D users directly. Since the instructions between BBU hotel to RRHs are affected by the fronthaul delay, it can be arranged in much longer time scale compare to D2D set-up delay requirement. Thus, the effect of the fronthaul delay to D2D set-up process could be diminished greatly.

4.3 Combined Cloud Computing and transport reconfiguration 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 base components to investigate these concepts, in T4.3, potential use cases 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 and hence a driver to optimisation by SON specifically for Mobile Cloud Networks are being defined in T4.3. However, in as much as there is a dependence on fronthaul performance to achieve such QoE/QoS there is a requirement within T3.3 to explore the implications on fronthaul performance requirements. Within this context, application layer latency, jitter and application processing / offloading are under consideration.

Figure 4-9 Structure of mobile local controller

In the project, we propose to have the mobile cloud sitting next to BBU pool, which can provide cloud computing service to the mobile device, as shown in Figure 4-9. Each mobile user will be assigned the dedicated mobile clone, which is realized by cloud based virtual machine. The user with a


Page 66 of 79


computational intensive task can offload the task to its mobile clone, which will execute that task for them and return the calculation result to them. In this case, significant battery saving can be made in mobile user side. Also, the quality of experience of mobile user will be enhanced.

Our whole system will guarantee the SLA for each user. To this end, SON has been applied in this structure to respond dynamically to user and networks’ needs. To better control the mobile cloud, mobile cloud controller has been proposed, as shown in Figure 4-9. Mobile cloud controller has been designed to allocate the computing resource in mobile cloud. Also, the mobile local controller oversees communication with SON.

Mobile controller is composed of the following components

• Resource monitor • Resource allocation algorithm calculation component • Communication manager • Compute manager

The mobile controller resource monitor can monitor the following information

• CPU frequency • CPU utilisation • Memory utilisation • Available physical machines • Available virtual machines • Power consumption

The mobile controller will periodicity report the above status of computing resource to the SON. In this case, SON can have knowledge of the status of the computing resource.

Per the change of the network, SON can instruct the mobile controller to do the following actions through communication manage and compute manager.

• Allocating more/less computing resource to each user. • Executing scaling operations for the virtue machines, including horizontal scaling and vertical

scaling. • Load balancing between physical machines.

Figure 4-10 Structure of Fronthaul by adding Cloud


Page 67 of 79


Moreover, the fronthaul is served as the key part of transmission link between mobile cloud and UE, as shown in Figure 4-10 above. However, the capacity of fronthaul is limited. If the capacity of fronthaul is N, then the maximum number of mobile users which can offload their tasks to mobile cloud at this time is N. If more than N users offload tasks at the same time, the errors or failure of offloading will happen. The limitation may occur in uplink or downlink direction. Therefore, SON is responsible for monitoring the current capacity of fronthaul and then decide how many users can be accepted to offload their task to mobile cloud.

4.4 Concepts for SON control and operation The concept for SON control and operation is split into sections corresponding to the families of SON functions introduced previously, namely self-configuring, self-optimising and self-healing. Common input data for any of the SON families is,

• The objective to be attained expressed as a set of measurable KPIs o An information model that includes such information as the geographic location,

performance capabilities, physical connectivity, and configuration requirements/configurability of both network elements and the transport infrastructure. Including for example, in case of LTE, MME, eNodeB, and their capability for virtualisation and varying functional split, the location of the cell site antennas and their elevation, beamwidth, tilt etc., and regarding transport the performance and configurability etc.

• A set of “levers” the values of which may be changed to effect change to the measured KPIs o Considering the RAN/radio domain, examples of continuously variable levers include

transmit power, antenna tilt, handover/reselection parameters, allocation retention parameters, admission control parameters for classes of users or services, percentage of users allowed to access a certain co-operative radio mode, allowed power for D2D mode. Discrete parameters include cell activation/deactivation, variation of functional split, allowable co-operative radio mode19, network-slice, UL/DL split for TDD.

o Considering the transport/fronthaul domain, examples of continuously variable levers (or at least semi-continuous) include bandwidth, QoS parameters CIR and CBR, and buffer length. Discrete parameters include link path and redundancy/protection. In both RAN and transport domains distribution of data to a set of active points in a CoMP set is a discrete variable.

• Network performance including, radio infrastructure and air interface performance, transport performance,

o For the RAN/radio domain this includes received signal strength and signal quality, handover success rate, frame erasure rate, subscriber throughput, traffic volume, dropped call rate, and blocked call rate, voice/video Mean Opinion Score (MOS).

o For the transport/fronthaul domain this includes frame loss, frame delay, frame delay variation, latency asymmetry, also including alignment of delay between cells of a CoMP set

19 For example, carrier aggregation, ICIC, JT CoMP, etc


Page 68 of 79


o In case of self-configuration an estimate of the expected performance may be obtained from prediction or educated guess-work else from actual network data

• Information about the geographic and temporal distribution of subscriber traffic. o In case of self-configuration this may be obtained from prediction or educated guess-

work else from geolocated information obtained from actual subscriber traffic. • An algorithm or strategy for generating new values for the lever parameter values to cause

the desired change in KPI o At one extreme the strategy may simply make a small change in one or more of the

lever values in a random fashion and based on the measured performance accept or reject the change. However, as the search space defined by the number of levers and all combination of possible values may be extremely large, such approach is likely not have sufficient time to achieve an optimum solution.

o The alternative is to model the system performance as a function of the value of the lever settings, which allows many system states to be investigated before implementing a preferred set of lever values which allows the solution space to be explored faster increasing the likelihood of approaching an optimal solution. Such predictive approach requires information about the geographic/temporal distribution of subscriber traffic.

• A mechanism for effecting change to the configuration of the network to reflect the choice of new values for the one or more chosen levers. For example, this may be achieved using SDN control principles about the transport domain and most probably some interaction with the OSS/OMC for the RAN/radio domain; in Figure 1-2 this functionality is represented by the “orchestration engine” and the “infrastructure manager/controller.”

The actions of SON take place on a time scale that varies over a huge range and it is useful to provide a brief categorisation for reference in this document albeit there is no definitive definition Table 4-2,

Category Time scale Real-time 1-100ms Near real time 100ms-60s Fast 1-60 min Slow 1-24hr Semi-static 1-30 day

Table 4-2 Categorisation of SON timescales

Similarly, SON may take place on a scope that varies over a huge range and it is useful to provide a brief categorisation for reference in this document albeit there is no definitive definition Table 4-3,


Page 69 of 79


Category Comment Specific subscriber E.g., a specific test mobile Chosen group of subscribers E.g., set of VIP subscribers Statistical selected group of subscribers E.g., every nth subscriber in a cell Cell level Subscribers attached to a cell Antenna port level Subscribers associated with a specific antenna Site level Subscribers attached to any of the different

frequency or RAT carriers at a single site RAT level/network level Subscribers attached to a specific RAT Subscription level E.g., subscribers of a specific PLMN Cell cluster level E.g., subscribers in a geographic polygon

associated with a set of cells Table 4-3 Categorisation of SON scope

The following tables summarise potential SON use-cases/experiments that may be performed considering the analysis that has been presented in the document thus far. A table is presented for each SON family, self-configuring Table 4-4, self-optimising Table 4-5, and self-healing Table 4-6. Example use-cases are listed with associated “lever/s,” required measurements and associated KPI objective trade-off. Typically, there is contention between different KPI. For example, maximum spectrum efficiency is achieved if only users at the cell centre are served as maximal throughput may be delivered with minimal resources, although in this scenario many users receive no service. More often and following the same principal, there is a trade-off between throughput and dropped call rate, or, between throughput and coverage. The number of use-cases and trade-offs is potentially very large therefore the tables are indicative rather than exhaustive. Where a “lever” may be used for more than one objective it is listed for just one to avoid or reduce repetition. Where levers may be used in a co-operative fashion they are grouped together but such grouping is not exclusive.

Outline use-case description

Lever/s Measurements Objective trade-off

Configure cell site address parameters, establish connectivity20

N/A N/A N/A

Configure functional split

Functional split N/A Radio performance v fronthaul bandwidth requirement (and cost)

Configure cell site radio parameters

Specific configuration parameters, per Section 1.3 e.g., TX power, diversity/MIMO, HO/reselection parameters

Use inference from measurements on other RATs or planning tool

Time to bring to site into service v customisation for local environment

20 These actions are associated with management of the life cycle stage of the network elements including cell deployment, software update, inventory management, retirement.


Page 70 of 79


Configure fronthaul path/s

Diversity of paths to choose

Y.1564 tests connectivity

Amount of diverse fronthaul routes available v robustness

Configure fronthaul buffering

Fronthaul buffer depth

N/A Packet delay v packet delay variation

Configure fronthaul bandwidth, etc. to align with chosen functional split

Fronthaul QoS parameters

Y.1564 tests service activation tests

Resource allocation v need Resource allocation v frequency offset etc.

Configure fronthaul measurement/data collection capability

Which deployed probes to activate. Which virtual probes to orchestrate

N/A Granularity of measurement v complexity Depends on use of h/w probes or availability to deploy infrastructure as a service IaaS

Configure RAN measurement/data collection capability

Granularity of measurement v complexity

Table 4-4 Self-configuring SON use-cases

Description Lever/s Measurements Example objective trade-offs Align offered radio capacity to subscriber demand21

Dynamic cell activation/ deactivation22 Available/ repurposed fronthaul capability for cell activation or CoMP CoMP activation/ mode selection HO/reselection parameters

Geolocated subscriber traffic distribution – e.g. number of cell edge UE Geographic distribution of signal strength/ quality Fronthaul KPI, loss, delay, delay variation, throughput etc. on each path Y.1731 Radio ToD alignment for CoMP Mobiles suitable/ requiring to use CoMP – cell location, UE speed, data needs

Throughput v subscriber QoE/QoS (e.g. DCR, FER) Fronthaul resource v subscriber QoE/QoS Energy usage v subscriber battery consumption TDD inter-cell interference v match to cell UL/DL ratio Spectrum efficiency v latency Improved traffic balance between cells (due to HO/reselection parameters) v dropped calls due to coverage issues Improved performance for 1 class of users v degraded quality for other classes

21 Operator may have specific KPI such as accessibility, retention, time on a specific RAT, 22 Also included is co-ordination of multiple levers, eg, Macro cell CoMP activation/ deactivation + small cell activation/ deactivation to stay within a transport limitation on fronthaul


Page 71 of 79


Radio performance, FER, scheduler queue length etc.

Optimise fronthaul for efficiency and resilience

Functional split (fronthaul latency constraint ranges) Fronthaul bandwidth Fronthaul path selection Fronthaul buffer CoMP activation/ mode selection

Fronthaul KPI Availability of alternate fronthaul Service interruption on path switching Radio performance Number of mobiles suitable for each CoMP mode Fronthaul latency asymmetry Fronthaul link loading with respect to capacity

Fronthaul resource consumed v cell edge performance (CoMP) Latency budget v CoMP performance within a split (e.g. MAC interleaving), CSI aging Fronthaul resource consumed v architectural options, redundancy, small cells, CoMP Latency alignment between transmission/reception points and traffic balance in the network Fronthaul link load sharing v service impairment on switching

Offload traffic to D2D mode

D2D mode activation Fronthaul resource for D2D

Number of mobiles suitable for D2D mode Fronthaul resource consumption D2D call set-up delay

Energy/resource saving v service interruption due to switching Offloaded traffic v fronthaul resource consumption Fronthaul resource consumption v D2D call setup delay Fronthaul resource consumption v infrastructure energy saving (architectural options, redundancy, small cells, CoMP)

Offload applications to MCN

MCN activation Fronthaul resource for MCN

Number of mobiles suitable for MCN operation

Fronthaul traffic v mobile battery saving from application offload


Page 72 of 79


Fronthaul resource consumption

Fronthaul resource consumption v MCN latency

Table 4-5 Self-optimising SON use-cases

Description Lever/s Measurements Objective trade-off Detect service outage, diagnose fault, determine resolution

Fronthaul performance Y.1564 + throughput

Implement service restoration solution

Dynamic path change for recovery/ protection

Number of unused fronthaul paths Change of CoMP mode to free-up resources for new fronthaul paths Number of active cells to free-up resources for new paths

Speed and effectiveness of resolution v redundant infrastructure

Coverage and capacity boost to take-up excess from failed sites, tilt

Mobiles in poor coverage due to n/w element failure addressable by cell coverage change

Table 4-6 Self-healing SON use-cases

5 SLA and SON concept for iCIRRUS This Section seeks to outline, in a non-prescriptive way, preferred SON use-case scenarios to address in further detail in the Work Package 5 of the project.

Figure 5-1 shows a high-level summary of the testbeds, illustrating the CPRI encapsulation over Ethernet (top), varying functional split per NGFI using the Open-Air-Interface (middle), and wide-band 60GHz point-to-point (bottom).

The OAM functional block manages the state of the various “levers” listed in in Table 4-4, Table 4-5, and Table 4-6 above. Data is collected from fronthaul probes, pluggable or built-in, and from the network elements, which corresponds to that listed in the Tables.

The data and lever state is passed to an SON functional block that assesses system performance and determines new parameter value updates for the one or more of the levers listed in Tables to move system configuration and performance to a more optimal state.


Page 73 of 79


Figure 5-1 SLA and SON concept for iCIRRUS

The Figure 5-1 below lists exemplary use-case experiments from those summarised in Section 4.4.

Use-case experiment

Levers Measurements Objective trade-off

Discussion

Align offered radio capacity to subscriber demand

Available/ repurposed fronthaul capability for cell activation or CoMP

Fronthaul KPI Radio ToD alignment for CoMP

Fronthaul resource v subscriber QoE/QoS

The scenario explores the ability to align ToD between multiple radios to exploit CoMP gains. The alignment depends on the chosen CoMP mode

Optimise fronthaul for efficiency and resilience

Fronthaul path selection

Fronthaul link loading with respect to capacity

Fronthaul link load sharing v service impairment on switching

The scenario explores the ability to balance load between fronthaul links on the transport network and the service impact caused by path switching

Offload traffic to D2D mode

Fronthaul resource for

D2D

D2D call set-up delay

Fronthaul resource consumption v D2D call setup delay

The scenario explores the interaction between the fronthaul resources assigned to D2D and the D2D call set-up delay

Offload applications to MCN

Fronthaul resource for

MCN

Fronthaul resource consumption

Fronthaul resource consumption v MCN latency

The scenario explores the interaction between the fronthaul resources assigned to MCN and the MCN application set-up delay

BBU Hotel

Aggregator / TSN switch

Aggregator /TSN switch

10G 10G 10G

100G 100G 10G 10G 10G

Operation Administration and Maintenance (OAM)

Self-Optimizing Network (SON)

CPRIoEth CPRIoEth Legacy CPRI

OAI (UKent)

60 GHz (HHI)

Pluggable Probes

built-in probes

BBU= Base Band Processing Unit CPRI= Common Public Radio Interface Eth= Ethernet OAI= Open Air Interface

Focus on measurements to drive end to end (re)configuration for SON


Page 74 of 79



Page 75 of 79


References

[1] Open Network Foundation, “OpenFlow Switch Specification, Version 1.5.0 (protocol version 0x06),” 2014.

[2] L. Fernandez del Rosal, V. Jungnickel, D. Muench, H. Griesser, P. Assimakopoulos, N. Gomes, Y. Kai, H. Thomas, M. Parker, C. Magurawalage, K. Wang, P. Chanclou and V. D, “D3.2 iCirrus - Preliminary Fronthaul Architecture Proposal,” 2016.

[3] L. Greiner and P. Gibbons, “SLA Definitions and Solutions,” On-line, 2007.

[4] EventHelix, “Reliability and availability basics”.

[5] IETF, “Benchmarking Methodology for Network Interconnect Devices,” 1999.

[6] ITU, “Y.1564 Ethernet service activation test methodology,” 2016.

[7] ITU, “Y.1731 OAM functions and mechanisms for Ethernet based networks,” ITU, 2015.

[8] NGMN, “5G Project Requirements and Architecture, Version 1.0,” 2016.

[9] NGMN, “5G P1 Description of Network Slicing Concept,” Requirements & Architecture, Work Stream End-to-End Architecture, 2016.

[10] TmForum, “NGCOR Inventory Management Requirements Response V0.11 Standard,” 2013.

[11] Chen, “IP Flow Performance Management Framework,” IETF, 2016.

[12] ITU, “OWAMP One-way active measurement protocol,” 2006.

[13] ITU, “TWAMP Two-way active measurement protocol,” 2008.

[14] IEEE, “TSN Time-Sensitive Networking Task Group IEEE 802.1”.

[15] L. Cominardi, “Ethernet OAM and SDN: a matching opportunity,” in EuCNC’16, Athens, 2016.

[16] SearchNetworking, “Network Administration:demarc (demarcation point),” [Online]. Available: http://searchnetworking.techtarget.com/definition/demarc. [Accessed 12 12 2016].

[17] OpenStack, “Bare Metal,” [Online]. Available: http://docs.openstack.org/admin-guide/baremetal.html. [Accessed 12 12 2016].

[18] S. Harrison and S. Shin, “Fronthaul size: calculation of macimum distance between RRH and BBU (online),” 2014.


Page 76 of 79


[19] ITU, “G.8265 Architecture and requirements for packet-based frequency delivery,” 2010.

[20] ITU, “H.8275 Architecture and requirements for packet-based time and phase distribution,” 2013.

[21] IEEE, “1588 V2 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems,” 2008.

[22] ITU-T, “G.8261 Timing and synchronization aspects in packet networks,” 2016.

[23] 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 EEE Int. Conf. on Commun. Workshops (ICC), Kuala Lumpur, Malaysia, 2016.

[24] 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.

[25] P. Assimakopoulos, M. K. Al-Hares and N. J. Gomes, “Switched Ethernet fronthaul architecture for cloud-radio access networks,” accepted by OSA/IEEE J Optical Communications and Networking.

[26] F. Ellefson, “MEF 30 - Service OAM (SOAM) Fault Management Implementation Agreement ,” 2011. [Online]. Available: https://www.mef.net/Assets/Technical.../PPT/Overview-of-MEF-30-FINAL.ppt. [Accessed 13 12 2016].

[27] R. Vaez-Ghaemi, “Rthernet OAM Test Applications,” JDSU, 2008.

[28] Small Cell Forum, “159.07.02 Small cell virtualisation functional splits and use cases,” 2016.

[29] GSMA Intelligence, “Understanding 5G: Perspectives on future technological advancements in mobile,” 2014.

[30] B. Lewis, “5G Mobile Communications for 2020 and Beyond - Vision and Key Enabling Technologies – UK Spectrum Policy Forum – Cluster 1,” Samsumg, 2014.

[31] Huawei, “5G A Technology Vision,” 2013.

[32] V. Jungnickel, S. Jaeckel, K. Börner, M. Schlosser and L. Thiele, “Estimating the Mobile Backhaul Traffic in Distributed coorinated Multi-point Systems,” in Mobile Workshop on Hybrid Optical Wireless Access Networks, 2012.

[33] V. Jungnickel, T. Wirth, M. Schellman, T. Haustein and W. Zirwas, “Synchronization of cooperative base stations,” in International Symposium on Wireless Communication Systems, 2008.


Page 77 of 79


[34] K. Manolakis, C. Oberli, V. Jungnickel and F. Rosas, “Analysis of Synchronization Impairments for Cooperative Base Stations using OFDM,” International Journal of Antennas and Propagation, 2015.

[35] K. Manolakis, V. Jungnickel, C. Oberli, T. Wild, V. Braun, H. Vucic and M. Castaneda, “Cooperative Cellular Networks Overcoming the Effects of Real-World Impairments,” IEEE Vehicular Technology Magazine, 2015.

[36] NGMN, “CoMP Evaluation and Enhancement, Version 2.0,” 2015.

[37] C. Pan, Y. Kai, H. Zhu, L. Fernandez del Rosal, J. Jungnickel, S. Hadjitheophanous, P. Ritoša, G. Koczian and M. Parker, “D4.2 iCIRRUS - UE D2D and D2I Interfacing,” 2016.

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

[39] M. Georgiades, M. Polyvios, P. Chanclou, P. Ritosa, H. Thomas, S. Delaitre, N. Gomes, H. Zhu, P. Asimakopoulos, L. Fernandez del Rosal and K. Wang, “D2.2 “Refined iCIRRUS architecture definitions and specifications”,” iCIRRUS, 2016.

[40] J. Kramer and J. Chen, “Use of measurements,” Commun. letters, vol. 5, no. 7, pp. 113-115, 2013.


Page 78 of 79


List of figures

Figure 1-1 View of end to end SON in a Telecommunication Network ........................................................... 13 Figure 1-2 Conceptual view SON and NFV Self Configuration ......................................................................... 15 Figure 1-3 Overview of SON architecture including hybrid approach and MEC support ................................. 15 Figure 1-4 Data consumption by proportion of area (Data from Viavi 2015 study) ........................................ 18 Figure 1-5 Service offered at cell edge (Data from NGMN Vodafone study) ................................................... 18 Figure 1-6 Real-world example of traffic hotspots vs cell site deployment in a cluster of cell sites. Cell site

locations shown in black, hotspot locations with coloured contours, geographic bin-size 500m ........... 19 Figure 1-7 Practical example of subscriber geolocation determined network optimisation ........................... 20 Figure 1-8 Illustrating objectives of self-optimisation .................................................................................... 20 Figure 2-1 Setup for measurement of Ethernet performance with a protocol analyser. ................................. 23 Figure 2-2 Setup for end-to-end and fronthaul Ethernet performance monitoring with a protocol analyser. 23 Figure 2-3 Setup for end-to-end and fronthaul Ethernet performance monitoring with a protocol analyser

and pluggable probes. ........................................................................................................................... 24 Figure 2-4 Measurement set up for frame inter-arrival delays ....................................................................... 26 Figure 2-5 The insertion of a background traffic frame in between LTE-carrying frames ................................ 27 Figure 2-6 Testbed for measuring fronthaul latency and frame-delay variation. ............................................ 28 Figure 2-7 Contention of timing messages with traffic. .................................................................................. 29 Figure 2-8 PTP ladder diagram for timing measurements .............................................................................. 30 Figure 2-9 Testing PTP Performance in a device test scenario ........................................................................ 31 Figure 2-10 Testing PTP performance in a field scenario ................................................................................ 31 Figure 2-11 Comparison of measured and theoretical results for the inter-frame delay on the onset of HARQ

retransmissions, for different LTE-carrying and background traffic Ethernet frame lengths. The plotted results here are normalized to the LTE-carrying Ethernet frame length. ................................................ 34

Figure 2-12 Transport block retransmissions versus background traffic Ethernet frame size for the same burst size and a bit rate of 50 Mb/s. The LTE-carrying frame size is 2000 octets .................................................................................................................................... 34

Figure 2-13 CCDF plots of inter-frame delays and corresponding HARQ retransmissions. The circle annotation indicates the group of values that are responsible for the increased retransmissions with larger background traffic frame size. Retx=retransmissions. ........................................................................... 35

Figure 2-14 Illustration of the pre-emption element of TSN ........................................................................... 35 Figure 2-15 Turn-up and trouble shoot frame pre-emption, queuing and scheduling .................................... 36 Figure 2-16 Illustration of collecting performance data using an SFP probe ................................................... 37 Figure 2-17 Active test using an IPFPM based data collection mechanism ..................................................... 38 Figure 2-18 service OAM life-cycle (MEF Forum) [26] ..................................................................................... 39 Figure 2-19 Overview of Ethernet OAM [27] .................................................................................................. 40 Figure 2-20 evolved iCIRRUS fronthaul architecture ...................................................................................... 41 Figure 2-21 Example demarcation in mobile backhaul network ..................................................................... 41 Figure 2-22 Analytics and management approaches ...................................................................................... 42 Figure 2-23 Measurements for performance evaluation in RAN/radio domain ............................................. 42 Figure 2-24 Measurement data collection ...................................................................................................... 43 Figure 2-25 Availability of radio performance parameters depending on the functional split. ....................... 44 Figure 3-1 Objectives of a radio SLA ............................................................................................................... 45 Figure 3-2 Objectives of a transport SLA ........................................................................................................ 46 Figure 3-3 Reference scenario for KPI measurement ...................................................................................... 46


Page 79 of 79


Figure 3-4 Bandwidth and latency requirements of potential 5G use cases [29] ........................................... 52 Figure 3-5 Maximum theoretical downlink speed by technology generation, Mb/s (*10 Gb/s is the minimum

theoretical upper limit speed specified for 5G) [29] .............................................................................. 53 Figure 3-6 Ultra-fast data transmission [30] ................................................................................................... 53 Figure 3-7 Overview of a potential 5G radio access architecture [31] ............................................................ 54 Figure 4-1 family of co-operative multi-point schemes (NGMN CoMP Evaluation and Enhancement) ........... 57 Figure 4-2 map of co-ordination architecture to backhaul (fronthaul) requirement....................................... 57 Figure 4-3 Exemplary RAN architectures (NGMN CoMP Evaluation and Enhancement) ................................. 58 Figure 4-4 Transport network with unbalanced routing of fronthaul links ..................................................... 60 Figure 4-5 Transport network with balanced routing of fronthaul links ......................................................... 60 Figure 4-6 Transport network with macro cell CoMP deactivated to provide fronthaul resource for small cells

.............................................................................................................................................................. 61 Figure 4-7 How many fronthaul links fit into a transport trunk? .................................................................... 62 Figure 4-8 A fronthaul “intelligence unit” where KPI monitoring is combined with SDN techniques for fast

fronthaul adaptations. .......................................................................................................................... 63 Figure 4-9 Structure of mobile local controller ............................................................................................... 65 Figure 4-10 Structure of Fronthaul by adding Cloud ....................................................................................... 66 Figure 5-1 SLA and SON concept for iCIRRUS.................................................................................................. 73

Date post:	13-Jun-2021
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

intelligent Converged network consolIdating Radio and...

Documents