intelligent converged network consolidating radio and ... · this deliverable report is the first...

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

of 47

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

intelligent Converged network consolIdating Radio and optical access aRound USer equipment

DELIVERABLE: D5.1 Methods, material and platforms for testing of high bandwidth mobile

wireless solutions

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: D5.1

Type: Report

Dissemination level Public

Date submitted: 13-03-2017

Editors: Patrik Ritoša (TS)

Authors / contributors (contributing partners)

Christoph Juchems (IAF), Huiling Zhu, Philippos Asimakopoulos (UKent), Luz Fernandez del Rosal, Malte Hinrichs (HHI), Patrik Riioša (TS), Daniel Münch (ADVA), Howard Thomas (VIAVI), Chathura Magurawalage, Kezhi Wang (UEssex), Sabine Delaitre, Silvia Blasco Vadillo (WT)

Internal reviewers Nathan Gomes (UKent), Mike Parker (UEssex)

Ref. Ares(2017)1287613 - 13/03/2017


of 47


Document history

Version 0.0 Document creation (TS) 03/08/2016 Version 0.1 Structure reorganization (TS) 27/10/2016 Version 0.2 WT contribution 11/11/2016 Version 0.25 IAF contribution update 01/11/2017 Version 0.26 UKENT section 1 contribution 01/11/2017 Version 0.3 Abstract and Executive

Summary editing (TS) 01/13/2017

Version 0.33 Mobile cloud clone update (UESSEX)

01/16/2017

Version 0.35 IAF Input: 2.1, 2.3, Appendix 01/17/2017 Version 0.38 UKENT input: 1.2 01/18/2017 Version 0.4 HHI update section 1.1, 2.4, 2.5

and 3 01/23/2017

Version 0.5 Removed section 2.5 02/02/2017 Version 0.55 Updated 1.2, 2.2 and 2.3

(UKENT) 06/02/2017

Version 0.7 Ready for internal review 07/02/2017 Version 0.8 Post internal review 15/02/2017 Version 1.0 Final 10/03/2017


of 47


Abstract This deliverable report is the first of a series of documents related to the iCIRRUS work package WP5: Integration and validation. This particular report sets out to identify the test platforms and describe the module developments that are based on the research outputs from WP2, WP3 and WP4, where different test environment potential scenarios are envisioned. The first part of this report describes the main envisioned areas and potential challenges of the iCIRRUS project investigations into the data and control planes. In the following sections, seven main standalone test environments are presented:

• Legacy network transparent CPRI-to-ETH conversion, for the verification of vendor independent mapping of fronthaul traffic to Ethernet;

• Open air interface (OAI) emulator for new fronthaul traffic mapping concepts tests; • High-speed fronthaul with functional split and 60-GHz radio access technology for testing

the achievable performance of a new data transport scheme; • High capacity (100G ETH) fronthaul network for traffic aggregation tests in fronthaul

segment; • Virtual RAN functional split, for test and verification of the RAN element virtualization

performance and possibilities; • Mobile cloud clone environment for testing the network efficiency improvement of user

equipment (UE) task offloading to the cloud on the network side; • Device-to-device (D2D) communications environment for evaluation of mobile network

operation, radio spectrum use efficiency, and user throughput performance, when the D2D communications scheme (coordinated by the network) is introduced.

The interconnected showcase demonstration is presented in the last chapter, consisting of multiple standalone scenarios interconnected together on the same high capacity fronthaul network, offering the possibility to investigate the mutual effects between different services. In this way, quantified results for the individual technology and multi-service fronthaul network efficiencies can be evaluated.


of 47


Executive Summary

The mobile network architecture consists of concatenated building blocks from the core to radio access elements, which have to be compliant with each other for proper network operation. System evolution is a complex process, where any improvement (e.g. allocation of more resources, reconfiguration for different operation etc.) has to be undertaken in a consistent manner on multiple elements across the entire system.

For the emerging 5G mobile network, multiple interest groups are driving this evolution process: society, industry, standardisation, research and market. In this global process the different groups will also tend to have contradictory demands (e.g. cost, performance, and technological possibilities). For all these reasons, research and development needs to be carried out simultaneously across different areas in the field, with a final goal to integrate all achieved findings into a final solution.

As a part of this 5G research process, the iCIRRUS project is focused on the radio access network (RAN) segment, investigating the possibilities to achieve better network performance (e.g. as based upon capacity, and use efficiency). The main topics distributed across the work packages WP2, WP3 and WP4 consist of: cloud or virtualized RAN (C-RAN, vRAN), high data rate fronthaul transport, cloud computing to support user equipment (UE), and device-to-device (D2D) communication.

Due to the variety of 5G network segments covered in the investigation, various test platforms and modules are envisioned as potential new generation candidates. From the work carried out in WP2, WP3 and WP4, the definition of the standalone scenarios was initially undertaken, followed by interconnection between the multiple scenarios (platforms), which have been investigated within WP5 in the latter stages of the project.

Finally, the results and analysis of the tests run on the standalone and/or integrated scenarios, allows validation of the research and development output work from the iCIRRUS project.


of 47


Index of terms

10G Base KR 10 G Ethernet interface standard 3GPP 3rd Generation partnership project ADC Analog-to-digital converter API Application programming interface APP (Mobile) Application software AWG Arbitrary waveform generator BBU Baseband unit BS Base station C-RAN Cloud radio access network C2C Clone-to-clone CAUI 100 G electrical interface specification CFP4 C form-factor pluggable interface COM Computer-on-module COMExpress Computer-on-module express CoMP Coordinated multi point CoS Class of service CPRI Common public radio interface CPU Central processing unit CSI Channel state information D2D Device to device communication D2I Device to infrastructure communication DAC Digital-to-analog converter DC Direct current DCI Downlink control information DDR4 DDR4 memory DL Downlink DHCP Dynamic host configuration protocol DNS Domain name system DMT Discrete multitone modulation DSP Digital signal processor DQPSK Differential quadrature phase shift keying DSQPSK Differential shifted QPSK modulation DU Digital unit EMS Element management system eNodeB Evolved Node B (4G base station terminology) EPC Evolved packet core ETH Ethernet EVM Error vector magnitude F-PU FPGA based processing unit FDV Frame delay variation FE Frontend FEC Forward error correction FMC FPGA mezzanine card FPGA Field-programmable gate array G-PON Gigabit passive optical network


of 47


GoS Grade of service GPS Global positioning system HARQ Hybrid automatic repeat request HPC High performance computing HW Hardware I/O Input/output IaaS Infrastructure as a service ID Identity IP core Intellectual property core IQ Inline-quadrature iRRH Intelligent remote radio head KPI Key performance indicator LAN Local area network LTE Long term evolution MAC Medium access control MCN Mobile cloud network MEC Mobile edge computing MIMO Multiple in multiple out MOS Mean opinion score mSATA Mini serial AT attachment MRP Metric results packets OAI Open air interface OAM Operation and maintenance OFDM Orthogonal frequency division multiplex OLT Optical line termination ONU Optical network unit OS Operating system OTA Over-the-air OVS Open vSwitch P2P Peer to peer PC Personal computer PCB Printed circuit board PCIe Peripheral component interconnect express PDCP Packet data convergence protocol PHY Physical PIN P–N diode with intrinsic semiconductor region PON Passive optical network PRE Packet routing engine PtMP Point-to-multipoint PtP Point-to-point PTP Precision timing protocol QoE Quality of experience QoS Quality of service QPSK Quadrature phase shift keying QSFP28 Quad small form-factor pluggable RAM Random-access memory RAN Radio access network RF Radio frequency


of 47


RH Radio head RLC Radio link control RRH Remote radio head RRU Remote radio unit RTP Real-time transport protocol RU Radio unit S-RF Software defined radio frontend SaaS Software as a service SAN Storage area network SATA serial AT attachment SDN Software defined networking SDR Software defined radio SDU Service data unit SFP Small form-factor pluggable SIP Session initiation protocol SLA Service level agreement SMF Single mode fibre SO-DIMM DDR memory type SON Self-optimising networking SP Strict priority SPI Serial peripheral interface SW Software SyncE Synchronous Ethernet TIA Trans-impedance amplifier ToR Top-of-rack TSN Time sensitive network UART Universal asynchronous receiver/transmitter UC Unified communications UCaaS Unified communications as a service UCI Uplink control information UE User equipment UL Uplink URL Uniform resource locator USB Universal serial bus USE Utilization, saturation and errors USRP Universal software radio peripheral VLAN Virtual local area network VM Virtual machines VoIP Voice over Internet protocol VPI VPI Transmission maker VPN Virtual private network WAN Wide area network WebRTC Web real-time communication WFQ Weighted fair queuing WRR Weighted round-robin


of 47


Content

Document history ................................................................................................................................... 2

Abstract ................................................................................................................................................... 3

Executive Summary ................................................................................................................................. 4

Index of terms ......................................................................................................................................... 5

1 Introduction .................................................................................................................................... 9

1.1 Data/transport plane .............................................................................................................. 9

1.2 Control plane......................................................................................................................... 11

2 Testbed platforms and setup identification ................................................................................. 15

2.1 FPGA processing unit ............................................................................................................ 15

2.2 COMExpress Modules ........................................................................................................... 19

3 CPRI-over-Ethernet ....................................................................................................................... 20

4 Open Air Interface (OAI) based Radio-over-Ethernet ................................................................... 22

4.1 OAI-based Non-Functional Split and Functional Split Implementations .............................. 22

4.2 Testbed integration with sync-enabled aggregator/switch .................................................. 23

5 High-speed fronthaul with functional split and 60-GHz radio access technology ........................ 26

6 100G Ethernet fronthaul connectivity aggregation ...................................................................... 29

7 Virtual RAN functional split ........................................................................................................... 31

8 Mobile cloud communication ....................................................................................................... 32

8.1 Mobile cloud clone resources control .................................................................................. 33

8.2 Clone as Mobile Cloud Component and Clone Management............................................... 34

8.3 Unified Communications (Use Case ...................................................................................... 36

8.4 Unified Communications in iCIRRUS ..................................................................................... 37

8 Device-to-device (D2D) mobile communications ......................................................................... 41

9 Interconnected showcase demonstration .................................................................................... 43

10 Conclusions and future work ........................................................................................................ 45

11 References .................................................................................................................................... 46

12 List of figures ................................................................................................................................. 47


of 47


1 Introduction

5G networks are having to meet the demanding requirements of high capacity throughputs, increased user densification and bandwidth-hungry applications, while at the same time offering reduced latency and energy consumption, such that simple extensions of today’s 4G/LTE technical solutions and concepts are insufficient. Different approaches have to be adopted, requiring a redefinition of our understandings of the data/transport plane and the control plane. This chapter presents the investigation areas taken into consideration by the iCIRRUS project and reports on the corresponding test environments.

The following two subsections describe the data plane and control plane functionalities respectively, that will form part of the different testbeds (and, correspondingly, of the final demonstrator). The integration of these functionalities will take place either directly (within a testbed) or through multiple integration steps when a number of partners are involved.

Each integration step is used to verify proper operation of the newly integrated control and/or data plane functionality. All functionalities described here are expected to be at the core of 5G radio access networks (RANs) and have already been thoroughly described in past deliverables (see [7], [10], [11], [13]).

1.1 Data/transport plane

The data/transport plane functionalities focus on the different functional split implementations, the Ethernet transport, and the SLA and OAM generated flows.

• DU-RU transport networks and network emulators

A number of testbeds are being developed with the aim of integrating and testing different functionalities that will form part of the next-generation fronthaul interface for 4G and 5G mobile networks.

A “legacy” fronthaul testbed, being built by IAF (Section 3), will showcase a centralised split (3GPP Option 8), with Common Public Radio Interface (CPRI) encapsulation by Ethernet. The aim is to integrate the CPRI-to-Ethernet transparent mapping functions in the end stations, and demonstrate synchronous operation that can meet the frequency and timing accuracy requirements for CPRI. This testbed will also be used for initial testing/verification of a number of hardware and software modules that will form part of the other testbeds.

A MAC/PHY split testbed (3GPP option 6), being built by UniKent (Section 4), will be based on the OpenAirInterface (OAI) emulation software environment [1] and will include the full LTE protocol stack (also including the evolved packet core (EPC) functionality). The testbed will be used to


of 47


characterise the performance of the generated traffic flows and the effect of impairments arising from the Ethernet transport. It will be integrated with the time-sensitive networking (TSN) and software-defined networking (SDN)-capable aggregation nodes. The latter, will allow enhanced coupling to the control plane of the transport network.

An upper-PHY split testbed, being built by HHI (Section 5), will be used to test modules and features that are expected to form an integral part of 5G networks. The split is not based on LTE, but on a custom system for high-speed data transmission, with the RF frontend operating in the mm-wave band (60 GHz). The aim of this testbed is to verify the operation/performance of a number of 5G candidate building blocks and a functional split that can accommodate a number of potential 5G requirements (e.g. throughput, latency, cell coordination).

Aggregation of the traffic flows produced by the aforementioned testbeds will take place through a 100G fronthaul connectivity testbed (Section 6), which will demonstrate high-speed Ethernet switching capabilities and synchronous operation. Both of these aspects are of fundamental importance for the future Ethernet-based fronthaul, and for seamless migration towards 5G networks.

Finally, a testbed being built by Orange (Section 7) will employ a split at the PDCP/RLC interface (3GPP option 2). It will be used to demonstrate co-existence of the future virtualised radio access network (vRAN) with passive optical networks (in a point-to-multipoint configuration) and to carry out performance comparisons with point-to-point Ethernet connectivity. Virtualisation of RAN functionalities will take place on general-purpose processing equipment (a server).

• Fronthaul monitoring probes, emulation for SLA and OAM over Ethernet in fronthaul

The Viavi HW-based probing system, employing in-line “smart small form factor pluggable (SFP)” probes, will be used to filter the MAC/PHY generated flows [2], [3] . The resulting filter results in the form of filter result packets (FRPs) and metric results packets (MRPs) will be sent to the packet routing engine (PRE) residing in the fronthaul intelligence unit for further processing of the collected metadata. The filtered results usually contain only filtered Ethernet frame headers (although the option to filter whole Ethernet frames is available) and therefore constitute only a small part of the total fronthaul traffic.

SLA on the fronthaul and its relation to radio optimisation possibilities may be investigated by using an impairment injection box to inject impairments on a per flow/ virtual-local area network (VLAN) basis. Impairment possibilities include, delay, jitter, loss, packet order and background traffic. Methods for taking measurements to verify SLA include standardised Ethernet approaches as already set out in the previous deliverable D3.3 [10], and approaches based on analysis of user traffic using packet colouring.

• Uniform ETH transport technology


of 47


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

1.2 Control plane The control plane functionalities focus on the top level RAN control and the control of the different RAN functional domains, which include the fronthaul/x-haul, device-to-device (D2D) communications and mobile cloud.

• Radio access network top level control capabilities

The engine for self-optimising networking (SON) in iCIRRUS terminology is the Intelligent Processing Unit. The architecture used for the SON may exploit distributed processing, centralised processing or a hybrid mixture. As a consequence, there are trade-offs between the location or locations in which data is processed, the volume of data that is exchanged across the network, the speed of response, and the scope of data from multiple RAN and transport network elements in the network.

Deliverable D3.3 introduced three families of SON functions: self-configuring, self-optimising and self-healing [10]; with respective “levers” to effect change in system performance and measurements to determine the performance level. The impact of SON processing architecture on exchanged data volume and SON response speed for these respective SON functionality families will be investigated, and where possible appropriate tests carried out.

Spectrum/radio resource management will be evaluated in the SON context, where radio block allocations across multiple cells and radio activation/deactivation (or downlink only use) will be tested. CoMP mode selection, or determination of a particular fronthaul configuration to support a certain CoMP mode, for example, bandwidth and alignment of delay and frame delay variation (FDV) between multiple points, will also all be tested.

• Control capabilities in fronthaul/x-haul

Split generated traffic streams are logically separated into VLAN ID (per 802.1Q), with layer-2 class-of-service (CoS) used to schedule the traffic streams accordingly. MAC primitives, DCI allocations and MAC control elements are given the highest priority. A number of scheduling algorithms will be implemented including strict priority (SP), which also forms part of IEEE802.1CM, weighted round-robin (WRR) and weighted fair queuing (WFQ). The last two are interesting as they can be combined


of 47


with a time-aware shaper implementation (based on IEEE802.1Qbv) for streams that contend within the same window.

The network is monitored through the HW probes which are continually filtering the fronthaul traffic streams. The collected FRP and MRP are sent to the PRE, residing in the intelligence unit, which additionally includes the key performance indicator (KPI) extraction, SDN controller, PacketPortal Python application-programming interface (API) and OAI API modules. From the PRE, the FRP and MRP metadata are passed on to the KPI extraction module, which runs all the algorithms for generating KPI statistics (which are updated dynamically) [4], [5]. KPIs include latency, latency variation, throughput and frame inter-arrival delays. Additional KPIs are generated through the API of the DU/RU software and these will include over-the-air (OTA) measures such as hybrid automatic repeat request (HARQ) retransmissions and signal-to-noise ratios.

The generated KPI statistics will inform the SDN scheduler on its steering and load balancing decisions. Specifically, traffic steering is applied between trunks in the fronthaul as a means of improving KPI statistics for certain streams and for load balancing purposes. Additionally, inter-CoS (and optionally, inter-VLAN) steering can be used for re-assigning traffic streams to a different CoS.

Note that inter-CoS (and inter-VLAN) steering can also be achieved with the Viavi 10G probes which have the capability of appending Ethernet frame headers “on the fly”. A potential approach is configuration of a virtual switch to allow mirroring of data packets, with or without filtering, of packets to a device capable of HW time stamping.

• Mobile cloud communication

The mobile devices are assigned to a mobile clone in a respective clone pool which is co-located with the DU pool. Resource heavy computational tasks can be offloaded to the corresponding clone to reduce battery consumption in UEs (i.e. device-to-clone, D2C). A clone is able to communicate with any other clone (clone-to-clone, C2C), no matter whether it resides in the same mobile cloud or not. This operation may improve resource utilisation, especially in cases where large amounts of data have to be transported to the mobile cloud and when the offloading tasks require a significant amount of computing resources to execute while meeting the task deadlines.

In order to perform the D2C and C2C operations, specialised resource control and allocation algorithms are required. This operation is of a distributed nature, and the algorithms are placed in various components of the system, which require a control plane utilizing the information made available by the Intelligent Processing Unit. For instance, compute-offloading algorithms are placed in the UEs, whereas the C2C operations are controlled by the mobile cloud. Furthermore, while a user is connected to its clone, the monitoring, control and resource management functions between clones and DUs are handled by the mobile cloud controller, as depicted in Figure 1.


of 47


Figure 1: Control signalling for mobile cloud

• Device-to-device (D2D) communication

As cellular-assisted D2D communication requires two devices close to each other to achieve high quality and reliable communication, this form of D2D communication requires assistance from the base station (BS) to be able to use licensed spectrum for the data transmission between the two, paired devices. Therefore, the design of signaling for D2D communication becomes one of its most important aspects, as already investigated in iCIRRUS D4.2 [13].

The main function performed by the control plane for D2D communications is that of resource allocation. With traditional resource allocation in D2D communications, central control of the resource allocation is performed at the Radio Link Control (RLC) and MAC protocol layers, and is normally located at the BS. There are three steps in resource allocation signaling for traditional cellular assisted D2D communication:

1. Channel State Information (CSI) measurement: Receiver user equipment UE measures the channel quality based on a measurement signal sent from the transmitter UE;

2. CSI report: Receiver UE reports the measured CSI to the BS; 3. Resource allocation result feedback: The resource allocation is performed at the BS based on

the CSI and the result is fed back to both transmitter UE and receiver UE;

Under the C-RAN network structure in iCIRRUS, central control of the resource allocation can be either performed at the DU or the RU, depending on the function splitting. Since the DU pool and RU are connected via fronthaul links, if central control of the D2D resource allocation is run at the DU pool, extra fronthaul transmission delay will be introduced into the total control signaling latency compared to the traditional case. Since the control signaling latency has a significant impact on the performance of D2D communications, with the iCIRRUS architecture, a new signaling protocol for D2D communications is investigated to reduce the setup latency, as shown in Figure 2; this new signaling also benefitting from the functional splitting.


of 47


Figure 2: Control signaling for D2D resource allocation

Shifting parts of the RLC and MAC layer functions from the DU to the RU, allows the resource allocation to be divided into two parts: 1) at the DU, for each RU, allocating part of the whole spectrum to its coverage area to serve all D2D pairs in the RU’s coverage area; 2) at each RU, performing local resource allocation for D2D pairs within the RU coverage area. This allows the total spectrum division/assignment to be performed at the DU pool, while the local resource allocation is located at the RUs. It is noted that the spectrum assignment for each RU’s coverage area is undertaken much less often than the local resource allocation performed at the RUs. Therefore, the fronthaul delay can be eliminated from the total signaling latency.


of 47


2 Testbed platforms and setup identification

Based on the investigation areas briefly presented in section 1 and the activities that have been undertaken in WP2, WP3 and WP4, various hardware platforms and software environments have been envisioned and developed as a basis for the testing and verification of the iCIRRUS concepts.

Due to the wide range of 5G network segments considered in the project, multiple test scenarios are identified and presented. In the following sections, individual integrated testing setups for verification/validation are first described, followed by an interconnected setup useful for the final demonstration of concepts covering the breadth of the project.

A standalone description is dedicated to the FPGA components (sections 2.1 and 2.2) because they are the main building block used in multiple tests. Other components specific for individual tests are described within each scenario case:

• CPRI-over-Ethernet (section 3) • Open Air Interface (OAI) based Radio-over-Ethernet (section 4) • High-speed fronthaul with functional split and 60 GHz radio access technology (section 5) • 100G Ethernet fronthaul connectivity aggregation (section 6) • Virtual RAN functional split (section 7) • Mobile cloud communication (section 8) • Device-to-device (D2D) mobile communications (section 9)

2.1 FPGA processing unit

A common integration building block, used in the following test scenarios is a configurable high speed logic circuit, i.e. a FPGA (field-programmable gate array). With its custom configuration possibility, and high speed logic operation, it allows the implementation of a wide range of prototype functionalities studied in the project.

The developed FPGA hardware platform combines a Xilinx Virtex Ultrascale FPGA with embedded COMExpress processor boards and 100G Ethernet connectivity. The entire platform (processing unit and I/O peripherals) has been designed and optimized for the prototype implementation of the main 5G technologies, taking into consideration the following technical aspects:

• Cloud RAN • Ethernet fronthaul • 100Gb Sync Ethernet • Software Defined Base Station Development


of 47


The final architecture of the FPGA processing unit (F-PU) is shown in the block diagram of Figure 3. The FPGA printed circuit board (PCB) layout is shown in Figure 4.

Figure 3: F-PU Block diagram

The central unit of the F-PU is the Xilinx Virtex Ultrascale FPGA, which is connected to all peripheral functional units and interfaces. Two embedded computer modules can be plugged into the on-board COMExpress slots. For the iCIRRUS testbed implementations the Kontron COMe-bBD6 Intel Xeon 1500 with 8 cores will be used. The interface between FPGA and computer module is an 8-lane PCIexpress 3.0 with data throughput of up to 64 Gbit/s.

Furthermore, two FMC HPC slots (FMC - FPGA Mezzanine Card, HPC - High Pin Count) are integrated on board to connect several types of hardware interfaces directly to the FPGA.

Two 100 Gbit/s Interfaces are integrated on the F-PU hardware platform. The QSFP28 transceivers are connected to the FPGA via 4 x 25 Gbit/s lanes.

F-PU: FPGA based Digital Processing Unit

FPGAXilinx

Virtex UltrascaleXCVU080-2 / XCKU115-2

(Housing A2104)

DDR4 Memory8 GB

100G Eth(only XCVU version)

4 x 25 Gbps

DSPLL SI5345

Ref CLK48 MHz

COMExpress #1 Type 6 Connector

PCIe x 8

4 x 25 Gbps

1Gb Eth.

UART, SPI

DC/DC Power Generation

8 x 16 Gbps µBlazeEmbedded µC

Flashmemory DDR RAM

REF_IN

1 Gb Eth.

FMC HPC #2FPGA Mezzanine Card Slot

8 x 16 Gbps

FMC HPC #1FPGA Mezzanine Card Slot

COMExpress #2 Type 6 Connector

UART / SPI

2 x USB 3.0

Plug in modules:Xeon D-1500 8 core

‚KontronCOMe-bBD6'

PCIe x 8Plug in modules:Xeon D-1500 8 core

‚KontronCOMe-bBD6'

SFP+

100G Eth(only XCVU version)

mSATA slot

PCIe x 8 slot

SFP+

SFP+(10GE)

1 Gb Eth.

PCIe x 8 slot

SFP+(10GE)

SATA conn.

2 x USB 3.0

SATA conn.

Plug in modules:• 8 x SFP+• 2 x 2 RF module

Plug in modules:• 8 x SFP+• 2 x 2 RF module

UART

SPIFlash

SPIFlash

REF_OUT


of 47


Figure 4: F-PU Top view (Board dimensions: 280 x 310 mm)

The F-PU consists of the following main units:

• FPGA: Xilinx Virtex Ultrascale (XCVU080, XCVU095, XCVU125) or Kintex Ultrascale (XCKU115) • 8 GByte DDR4 RAM • Clock generation and clock recovery based on DSPLL SI5345 • DC/DC power generation • 2 x COMExpress sockets • 2 x FMC / HPC sockets compliant to Vita 57.1

The following interfaces are provided:

• 2 x 100 G Ethernet, QSFP28, CAUI 4: 4 x 25 Gbit/s (Virtex Ultrascale version only) • 2 x SFP+ interface connected to FPGA • 1 Gb Ethernet connected to FPGA (board Control and Management interface) • UART, SPI connected to FPGA • External Reference I/O

Additional interfaces related to the COMExpress modules are: • SFP+ interface (10 G Ethernet) • 1 GB Ethernet • 2 x USB 3.0 • UART, SPI • PCIe x 8 slot connector • mSATA slot connector (only applied on COMExpress #1 • SATA connector


of 47


To cope with the different hardware requirements related to the testbed setups (high speed communication via 100G Ethernet on the one hand, and the number of available programmable gates for high speed real time signal processing on the other hand) two board versions have been created:

• Virtex Ultrascale Version: FPGA device XCVU080, XCVU095, XCVU125 Application: high speed serial interfaces (2 x 100 G Ethernet)

• Kintex Ultrascale Version: FPGA device XCKU115 Application: digital signal processing

Both FPGA version specifications are summarized in Figure 5 (where the key parameters are highlighted). A third version using the Virtex Ultrascale+ (VU5P, VU7P, VU9P) can be used in the future.

Figure 5: Comparison of FPGA Resources of different F-PU board versions (XCVU080 / XCKU115)


of 47


2.2 COMExpress Modules

The F-PU functionalities can be extended with two COMExpress processor modules, where the COMExpress module allows standard processor unit integration on the FPGA board. With the combination of FPGA and standard processor units the platform functionality can be maximised. The F-PU is used for hardware optimised processing tasks (e.g. time sensitive, computationally extensive), and the standard PU is used for software processing task (e.g. dynamic reconfiguration). The F-PU with the COMExpress processor modules shown in Figure 6 will be used in the testbed setup presented in section 4.

Due to the high performance requirements, the following processor module will be used:

• Kontron COMExpress Module COMe-bBD6 D-1548 (68002-0000-48-8),

• COM Express® for Communication based on Type6 basic, Computer-on-Module with Intel® Xeon® processor D-1548 (8 cores, 2 GHz), dual 10GbE (KR), dual Gbe, 2x DDR4 SO-DIMM.

Figure 6: COMExpress module example


of 47


3 CPRI-over-Ethernet

The first approach in a series of 5G testbed set up considerations, consists of legacy (CPRI) traffic conversion and transport over the Ethernet fronthaul network. Independent of the actual final 5G transport technology, the expected results will be valuable for the evolution of the existing networks.

The CPRI-over-Ethernet testbed setup includes implementation and testing of synchronized CPRI to Ethernet conversion, and vice versa, and final demonstration in a real mobile network environment. The main focus is the implementation and verification of the core functionality which can meet the frequency and timing accuracy requirements for CPRI transmission.

The validation setup is depicted in the block diagram in Figure 7. It is based on existing 4G (LTE) infrastructure (BBU – Base Band Unit, RRU – Remote Radio Unit and UE – User Equipment terminals), on an isolated part of the real network. The main challenge for iCIRRUS here is the implementation of synchronous Ethernet transmission with PTP enhancement between the BBU and the RRU.

The main feature of the planned testbed is to provide fully transparent and synchronous CPRI-over-Ethernet conversion; in this transparent mode, there being no need to read and interpret CPRI content for Ethernet remapping. (Such content could be vendor specific).

Rather, in the transparent mode, the challenge is to convert CPRI bits into synchronous Ethernet packets, and then back to CPRI bits again in the de-mapping. Attention must be paid to Ethernet transmission capacity and Ethernet synchronisation, to ensure that all CPRI traffic is transmitted with low latency and with a synchronized clock frequency for correct CPRI timing recovery.

The proposed scheme is expected to lead to a ‘Radio-over-Ethernet’ demonstration in a real mobile network environment, showing independence from the equipment manufacturer.

The hardware platform 'F-PU - FPGA based Processing Unit' will be the basis for the implementation of the 'CPRI-over-Ethernet' core functionality. Development, implementation and testing will be performed in several steps.

The first step includes the development of CPRI and 10G Ethernet core functionality on the Virtex Ultrascale FPGA, with clock recovery and synchronisation based on the CPRI master clock implemented and tested in this phase. Timing accuracy and jitter of the clock synchronisation has to be compared to the general CPRI requirements for stable operation of the radio network, such that the differential delay should be below +/- 8 ns.

Furthermore, the latency requirements for a CPRI link have to be considered, with the end-to-end delay not exceeding 100 µs. In particular, the processing delay of CPRI/Ethernet conversion should be made as low and as stable as possible to avoid latency imbalances.


of 47


F-PU

CPRIBBU

Demonstration of ‚CPRI to Ethernet Conversion‘ embedded between BBU and RRH

LTEmobile

LTEmobile

LTEmobile

FPGA

10G EthCPRI / Eth

10G Sync Ethernet

F-PU

CPRI RRH

FPGA

10G Eth Eth /CPRI

Features:- CPRI / Ethernet conversion- connection to existing BBU, RRH- I/Q transmission, no ‚functional split‘- showcase: Radio over 10G Sync Ethernet in ‚real environment‘

Figure 7: Testbed Setup ‘CPRI-over-Ethernet’

A PTP-based time synchronisation at the RRH end of the link is required to recover an aligned time base for all data streams within a network. Latency imbalance between data streams can be removed by buffering, but the buffer size has to be held as low as possible, because buffering inserts additional latency.

The second step includes the integration of all signal processing units on the F-PU platform, and test and verification of the complete signal processing chain. This work will be performed in IAF’s laboratory with additional test devices from VIAVI to emulate the real environment, verify the functionality and measure the overall system performance. Specifically, a CPRI test signal generator and signal analyser MTS-5800 [15] will be used as signal source and for analysis of the recovered CPRI signal parameters passing through the Ethernet link (clock jitter and latency).

The final implementation, test and verification of the CPRI-over-Ethernet setup will be performed in TS’s laboratories with real network components, consisting of: base station, remote radio heads and test mobiles, in the final showcase demonstration. Downlink transmission of user traffic via a 10 Gb Ethernet fronthaul will also be demonstrated.

This testbed setup also provides a basis for the setups with enhanced functionality presented in the following sections.


of 47


4 Open Air Interface (OAI) based Radio-over-Ethernet

The mobile network architecture consists of a complex chain stretching from the core to radio access elements, which have to be compliant with each other. Due to the system complexity and strict compliance requirement for the end-to-end elements, we therefore also choose to test aspects of the new 5G concepts on the existing (e.g. 4G) system architecture. For this purpose we have set up an Open Air Interface (OAI) environment [1], representing an emulator compliant with the 4G 3GPP standard and which can be reconfigured for custom operation. However, the limits of the basic OAI architecture on a PC can be seen most obviously in its computation capacity and transport throughput. Therefore in the following testbeds description the OAI is combined with a FPGA processing unit.

4.1 OAI-based Non-Functional Split and Functional Split Implementations

The OAI-based Radio-over-Ethernet testbed set-up will be used for two integration tests: i) non-functional split implementation; and ii) functional split implementation, with some modifications of the setup for the latter. The DU and RU are based on the F-PU hardware platform, which is equipped with the Xilinx Virtex Ultrascale FPGA (section 2.1) and an embedded Computer module COMExpress (section 2.2).

The hardware platform offers high processing power on COMExpress modules for OAI software implementation combined with a large amount of FPGA resources and high speed interfaces. The OAI software is ported into the COMM Express modules, while the interface between the DU and the USRP is Ethernet (either 1GbE or 10GbE). The physical interface between processor system and FPGA is an eight lane PCIexpress interface with up to 40 Gbit/s throughput.

For the non-functional split implementation, the interface between the COMExpress and FPGA modules in the F-PU carries In-phase and Quadrature (IQ) radio samples. For the functional spit functionality implementation, the COMExpress modules in the DU and RU will run a MAC/PHY split, as shown in Figure 8; that is, in the downlink direction the DU will produce and encapsulate LTE MAC SDUs while the RU will extract them and pass them to the LTE PHY layer processing. Therefore in this case, the interface between the COMExpress and FPGA modules in the F-PU carries LTE MAC SDUs. Additional flows in the downlink include encapsulated downlink control information (DCI) and MAC/PHY primitives (the uplink flows equivalently include uplink control information (UCI)). Note that the EPC will also be running on a separate workstation connected to the digital unit (DU) through an Ethernet link (not shown in Figure 8).

For the RF frontend, USRP X300 software defined radio (SDR) platforms are used [6]. These are based on the open source software architecture, compatible with the presented development frameworks. The testbed also includes the integration of the fronthaul intelligence unit and the probing system, while the implementation of 10G synchronised Ethernet (SyncE) with PTP is based


of 47


upon the architecture described in Section 3, but with the system clock generated internally by the DU instead of being recovered from the CPRI input signal. The testbed set-ups for the two integration tests are shown in the block diagrams of Figure 8.

Using the FPGA boards will allow for higher data rates and processing capacity (as compared to a pure software implementation running on a PC/Linux environment).

Figure 8: Testbed Setup, OAI based Radio-over-Ethernet without functional split/with functional split

4.2 Testbed integration with sync-enabled aggregator/switch

This integration step will allow testing of the functionality of the fronthaul intelligence unit with the new 10G probes with proper latency and latency variation measurements. These measurements are meaningful when a switching/aggregation element is included in the set-up. Furthermore, the PTP and SyncE-enabled aggregator/switch will allow testing for higher quality KPI statistics from the probing system as the 10G probes support both SyncE and PTP. A different testbed implementation will replace the 10G aggregator/switch unit with a 10G SDN-capable Ethernet switch that will be used to test the traffic steering/load balancing algorithms. The functional view for the testbed is shown in Figure 9, while more detail of the functions of the fronthaul intelligence unit is shown in Figure 10.

The intelligence unit comes in the form of a general-purpose server and contains the necessary modules for extracting and manipulating data from the different application-programming interfaces (APIs). The PacketPortal python API is used to extract filtered packet metadata from packets


of 47


captured using the HW probes, which are then sent to the KPI extraction module. The latter generates real-time KPI statistics, including latency and latency variation, inter-frame delays and link utilization.

For the testbed implementation that includes the SDN-capable switch, the POX SDN controller uses the produced KPI statistics as inputs to its traffic steering and load-balancing algorithm. Finally, the OAI API is used to obtain real-time statistics of various over-the-air KPIs such as HARQ retransmissions and signal-to-noise ratios.

Figure 9: Testbed Setup integration with sync-enabled 10G aggregator/switch or SDN-enabled switch


of 47


Figure 10: Modules that make up the intelligence unit

PacketPortal Python API

Amarisoft/OAI API

POX SDN controller

KPI extraction

Server (Intelligence unit)

PacketPortal Python API

OAI API

Openflow messages to SDN switch

HW probes captures

OAI over-the-air statistics

Packet-routing engine


of 47


5 High-speed fronthaul with functional split and 60-GHz radio access technology

Compared to the previous scenario, the following scenario, for purposes of simplicity, does not adopt traffic mapping according to the 3GPP standards. Rather, the main purpose of the test bed here is to verify a 5G candidate building blocks functional split, optimized for transport efficiency, e.g. throughput, latency, and cell coordination.

Figure 11 shows the target setup for the validation of a functional split for high-speed applications. The main features of this setup are the implementation of a modified functional split at the upper PHY, which means, as described in [7], splitting the functions immediately after the FEC in the downlink and immediately before the FEC in the uplink. By doing so, there is a significant reduction in the data rate transported over the fronthaul as compared to current fronthaul realizations.

Figure 11: Test platform for high-speed functional split with millimetre-wave as radio access technology

The implementation of this functional split is not based on LTE, but on a custom system for high-speed data transmission, with features described in [8] and [9]. The required bandwidth for the wireless transmission can only be realized with millimetre waves, which is why 60 GHz is selected as the technology for use in this validation setup.

The test scenario described above consists of several hardware components as depicted in Figure 11:

• The digital signal processing (DSP) for the Digital Unit (DU) and the remote Unit will be implemented in the FPGA processing unit (F-PU) developed by IAF.

• Digital to analogue (DAC) and analogue to digital (ADC) converter boards in the RU for the integration of the 60-GHz Frontends (FE).

• 60-GHz frontends for the wireless transmission of the high-speed signals from the RU to the user equipment. Although the system originally supported two IQ channels in each direction (up and downlink), hardware availability might impose some restrictions for the final demonstration (available FMC connectors in the F-PU for the RU and/or available 60-GHz frontends will limit the actual wireless links).


of 47


• A custom FPGA-platform available at HHI for the implementation of the DSP of user equipment. This platform is a prototype for laboratory use, and thus presents larger dimensions than a real-life handset (and is therefore not mobile).

Additional to the hardware components listed above, the following firmware components are also required:

• Digital Unit firmware which consists of the digital signal processor (DSP) for the MAC functions, the FEC coder and decoder, for the downlink and uplink respectively, and the Ethernet mapping and demapping also for the downlink and uplink respectively, as shown in Figure 12.

Figure 12: Firmware for Evolved Digital Unit

• Remote Unit firmware, as shown in Figure 13, consisting of the Ethernet mapping and

demapping, for the uplink and downlink respectively, and the remaining physical layer functionalities for implementing the custom π/4-DSQPSK single-carrier scheme system.

• The firmware required for the implementation of 10G synchronous Ethernet (SyncE) and other synchronization algorithms such as IEEE 1588 PTP, that are especially important for the final showcase demonstration integration, and that will be developed by IAF for the CPRI over Ethernet application.

• User Equipment firmware consisting of the custom π/4-DSQPSK unit from HHI without functional split. It also presents firmware for external monitoring of over-the-air performance parameters, such as error vector magnitude (EVM). The user equipment hardware must be connected to a computer for enabling such a capability.


of 47


Figure 13: Firmware for Evolved Remote Unit


of 47


6 100G Ethernet fronthaul connectivity aggregation

Besides the high fronthaul capacity presented in the previous scenario, one of the target features of 5G, which has been taken into the consideration in the iCIRRUS project, is the possibility of aggregation. With the migration to Ethernet, aggregation (switching) is already in principle a well known approach. However, challenges in the fronthaul network arise, due to high transport demands, e.g. synchronization. In this case, the aim of the presented test bed is to verify aggregation possibilities using a custom FPGA processing unit.

Figure 14 summarizes the planned testbed configuration based on 100G Ethernet fronthaul connectivity, as a result of the investigations in WP3 [7],[10]. The testbed setups from Section 3, Section 4 and Section 0 based on 10G Ethernet are part of the 100G testbed setup.

Figure 14: Overview Testbed Setup based on 100G Ethernet Fronthaul Connectivity

Features:

The special features of the 100G Ethernet fronthaul connectivity aggregation are to demonstrate a 100G Ethernet-based fronthaul running several applications in parallel. In this case, the presented set up is designed for following applications:

• legacy CPRI-based base station integrated by a CPRI-over-Ethernet mapper • Open Air Interface based software defined base station • Technologically disruptive 60 GHz-based communication systems


of 47


Additional Hardware:

These applications are interconnected via 10G Ethernet interfaces to a 10G / 100G aggregator unit. The aggregator unit provides three to ten 10G Ethernet interfaces, and one to two 100G Ethernet interfaces. The 10G interfaces are SFP+ interfaces, whereas the 100G interfaces are QSFP28 or CFP4 interfaces.

The 10G / 100G aggregator unit or time-sensitive switch is based on the IAF F-PU FPGA platform. For backup reasons due to potential unforeseen issues etc., a Xilinx Ultrascale Virtex FPGA evaluation board is considered as a fall back option (albeit with a more limited functionality).

Software/Firmware components (FPGA):

Due to the stringent latency and performance requirements, the relevant functional parts of the 10G / 100G aggregator unit are implemented in the FPGA. The foundations are Xilinx IP cores for 10G Eth and 100G Eth. In a first step, the default configuration is used, and then in a further step, different configuration possibilities can be set via a serial RS-232 or dedicated control Ethernet interface.

Dedicated measurement equipment:

The ONT-100G [16] is proposed for short-term loan from VIAVI in the design and integration phases of the 100G trunk part of the project. The equipment can validate 100G Ethernet layers 1-2-3, assessing signal quality and service deployment.


of 47


7 Virtual RAN functional split

For a new RAN functional split (virtual RAN), this test (led by Orange) focuses on the functional split at the Packet Data Convergence Protocol (PDCP) level, and the investigation in real time of the previously exposed concerns about the transported data traffic and the impact of impairments on the new fronthaul interface. Transmission is done over a Point-to-Point (PtP) and Point-to-MultiPoint (PtMP) optical access network.

As shown in Figure 15, we will experimentally investigate two solutions for the transport of the new fronthaul interface: Ethernet PtP and PtMP with a G-PON (Gigabit-capable PON) system.

Figure 15: Experimental setup for ETH transport lab tests of new functional split fronthaul (not CPRI)

At the transmitter side, generic servers running on OpenStack host a virtual EMS (Element Management System), a virtual EPC (Evolved Packet Core) where the Mobile Edge Computing (MEC) is located, and a virtual BBU (vBBU). A 10G Top-of-Rack Ethernet switch will be used to connect these nodes. At the receiver side, an intelligent RRH will be connected to a User Equipment (a computer, in this case) via a mobile dongle. We will use a mobile signal based on LTE with 15-MHz bandwidth and 2x2 MIMO.

For PtP fronthaul, we will use common 1 Gbit/s Ethernet switches at both ends. Packet loss and latency will be then inserted with a dedicated test device, in order to evaluate its impact on the mobile throughput.

For the PtMP fronthaul, an optical line termination (OLT) will be implemented after the Top-of-Rack (ToR) switch and an Optical Network Unit (ONU) will be associated to each iRRH. We will allocate fixed bandwidths for the upstream to the ONUs, 200 Mb/s for ONU-1 connected to the iRRH-2 and 600 Mb/s for ONU-2 used for overloading the G-PON system. With this configuration, we will evaluate the LTE throughput for different lengths of optical fibre.


of 47


8 Mobile cloud communication

To complement the previously presented scenarios, where the focus is on transport capacity increase, the following parts are oriented towards techniques to increase the efficiency of network resources utilization.

In the following section, a setup is presented, which introduces a cloud infrastructure at the network side, dedicated to support user equipment (UE). In this architecture, local tasks started on a UE can be offloaded onto the cloud in the network, with the goal to reduce UE processing resources and power consumption, and achieve better QoE and/or network utilization.

The platform for the mobile cloud communication demonstration and verification arises from the detailed investigations being performed in WP4 [11]. In this case, the testbed is being set up, as shown in Figure 16. In particular, the remote radio unit (RRU) is realized by software-defined radio USRP devices (X300), which are connected to the cloud pool via a Gigabit Ethernet switch. Openstack is applied as the cloud framework that hosts both the mobile cloud and the DU. The Android operating system will be installed on the mobile cloud, whereas the Amarisoft LTE or Open Air Interface (OAI)-based DU will be deployed in the cloud as a communication computing unit. Also, a mobile phone will be installed with the Android operating system, with the mobile phone sending some of the computationally intensive tasks to the mobile clone, which will perform those tasks on the mobile phone’s behalf.

Figure 16: Mobile cloud clone testbed setup


of 47


8.1 Mobile cloud clone resources control In order to control the communications resource as well as the computation resource, a mobile cloud controller situated between the DU and the Mobile Cloud is proposed, as shown in Figure 17. The mobile cloud controller includes the resource allocation algorithm, which can perform joint resource allocation optimisation. The allocation calculation shown in Figure 18 is based on the communication resource and computing resources. There is also the communication manager that can instruct the DU pool to allocate the communication resource; and finally the compute manager, which can allocate the computing resource to the mobile user.

Figure 17: Overall picture

Figure 18: Mobile cloud controller


of 47


The monitoring system includes the communication monitoring and computing monitoring systems, with the overall process described in detail in the deliverable D5.2 [12]. The main tasks are as follows:

• The user first offloads the task, as long as the Quality of Service (QoS) requirement is satisfied by the mobile cloud controller.

• The mobile controller monitors the current available communication and computing resource, including the available number of resource blocks, and the available number of physical machines and virtual machines.

• The joint resource allocation algorithm calculates the resource allocation by considering the current available resource and QoS requirements of the user. At this stage, if the current resource is not enough to support this user, the offloading maybe rejected or delayed to the next time frame.

• The algorithm instructs the resource allocation via the communication and computing manager to the DU and mobile cloud. Scaling techniques, including horizontal scaling and vertical scaling will be used in the computing side.

8.2 Clone as Mobile Cloud Component and Clone Management Wellness Telecom (WT), as a cloud provider, owns a cloud infrastructure, offering their clients Infrastructure-as-a-Service (IaaS), such as Virtual Machines, RAM memory resources, storage resources, etc., and Software-as-a-Service (SaaS): e.g. Cloud Storage, Virtual Switchboard.

Thus, prior to the integration into the iCIRRUS Mobile Cloud Network for the collaborative/integrated tests and the final showcase demonstration, WT´s cloud deployed using VMware (as explained in the following paragraphs) will host the clones as IaaS, so enabling clone management, and aiming at performing individual/unit tests.

The infrastructure on which IaaS is provided, and on top of which the SaaS servers are offered, is based on the Cisco Unified Computing System, which is a next-generation data centre platform unifying computation, network, storage access and virtualization in a comprehensive system, which is designed with the goal of improving company agility. The system integrates features providing minimum delay for access to information, with no losses and at rates of 10 Gigabit Ethernet, leveraging the x64 servers’ architectures. The system makes use of blade servers that can be configured in racks, providing scalability. All resources are part of a unique unified management domain.

The SQUADA cloud platform is part of a Cisco Unified Computing System solution, so that the following elements that integrate it belong to this brand:

• UCS 5108 racks • Blade servers UCS B200 • Fabric Extender UCS2104 elements (which play the role of access switches and transform the

virtual interfaces into physical ones) • Fabric Interconnect UCS 6120 elements, which play the role of distribution switches, main


of 47


managers of blade servers, and of the main connection interface between LAN and SAN networks.

The platform integrates two Hitachi storage arrays: AMS 2100 on the one hand, and HUS 2100 on the other. Both arrays have two controllers, in order to guarantee access should a failure take place.

The Data Processing Centre core network is composed of Cisco L3 stacked switches, so as to ensure redundancy from the point of view of a single logic unit. The model, to which these elements correspond, Catalyst 3750 X, is connected (together with other elements) to several VPN concentrator switches, Cisco 2921, in order to manage the access to the Data Processing Centre.

Security is offered by means of two Fortigate 200B firewalls, configured for high availability, as well as a FortiAnalyzer 100C to capture, analyse and generate firewall reports, as well as other devices which are compatible with syslogs.

The platform, devoted to virtualization, is based on a technology highly respected in the market: VMWare vSphere 5 as shown in Figure 19. This solution brings features which are transparent to the client, such as load balancing, and high availability of the underlying hardware, etc.

The SQUADA Cloud architecture presented here is chosen because of its scalability, flexibility and agility in adapting to new applications or scenarios.

Figure 19: SQUADA Cloud Architecture

WT’s cloud is therefore deployed by using a VMWare architecture that favours a smooth transition towards the final scenario, and the implementation of the iCIRRUS Mobile Cloud Network into the TS facilities that also uses VMWare technology. In Figure 20 the main VMs involved in the deployment of the MCN are listed, including the resources initially allocated as a starting point, in order to evaluate resource consumption in the cloud side.


of 47


Figure 20: WT system description for clone management

8.3 Unified Communications (Use Case)

Unified communications (UC) can be defined as a platform to provide enterprise communications integrated in only one service. This service encompasses audio and video calls between two users (end-to-end or peer-to-peer calls) or among a group of users (audio/video conference call), user presence detection, instant message service (chat) and message delivery service (delayed message service).

In iCIRRUS, this use case is aimed at showing how the transfer of computationally demanding tasks from UEs to the cloud is a feasible, sustainable approach. Thus, attention is focused on videoconferencing as service, due to the intensity of the computational tasks traditionally performed in users´ devices.

Wellness Telecom´s UC videoconference is aimed at reducing consumption of bandwidth, and saving the battery in user equipment, thanks to significant reduction in the local processing load. In this way, it is possible to take advantage of the processing resources in the Mobile Cloud Network when they are available, according to the intelligent resource allocation, while reducing the consumption of resources in the portable device; this being one of the iCIRRUS objectives.

UC infrastructure is based on the previously described MCN architecture, SQUADA, which in turn is based on VMware vSphere, with ESXi hypervisor.

In addition, this network is protected by a firewall with VPN access, thereby increasing system security. Hence, a virtual machine is used to provide a layer of security at the network and application levels, and at VPN access.


of 47


Figure 21: WT Architecture based in 3 VMs for Clone and UC.

One of the main characteristics of UC is that it is based on Docker for the creation and deployment of containers.

Figure 22: Unified Communications VM.

8.4 Unified Communications in iCIRRUS In iCIRRUS, the Unified Communications (UC) use case focuses on the optimization of resource consumption in mobile cloud applications. Thus, we will define a simplified scenario (Figure 23) relating to two of the objectives of WP4: resource consumption and energy saving. It includes the basic architecture, at VM level, able to provide videoconferencing service, thanks to the components described next:


of 47


• SIP (Session Initiation Protocol) proxy + RTP (Real-time Transport Protocol) proxy machine containing:

o SIP proxy: controlling signaling (SIP). o RTPProxy: The mean flow supported by the RTP protocol, both audio and video, is

routed through the RTPProxy. • DDBB: Database is used to store registered users calls and other data required for system

configuration. • Video mixer: This provides the capability to create video conferencing rooms, and is used for

shaping various streams at conferences. This type of service shows high resource consumption in the cloud; but is able to decrease the computational intensity in the UEs, so saving processing resources, battery and bandwidth.

• DNS (Domain Name System) + DHCP (Dynamic Host Configuration Protocol): Location system for UC services.

• Softphone: Software that acts as a SIP phone.

Video Mixer

Secure connection

SIP Proxy+

RTPProxy

LAN

Softphone

VMWare Cloud

DDBB

DNS+

DHCP

Figure 23: UC Testing scenario.


of 47


In Table 1, the resources initially allocated for these components are presented, as a starting point for the evaluation of consumption in the cloud side of the system, vs. the UE side:

Table 1: Resource allocation in the MCN for the UC use case.

SIP Proxy + RTPproxy Video Mixer DDBB DNS + DHCP

CPU 2 CPU Intel Xeon E5649 2.53 GHZ

8 CPU Intel Xeon E5649 2.53 GHZ



RAM 4 GB 8 GB 1 GB 512 MB

Disk 10 GB 10 GB 15 GB 10 GB

Videoconference call use case

Using this cloud processing infrastructure, it is possible to perform videoconferencing with a reduced consumption of bandwidth, and saving of battery power in the user equipment, due to an important reduction in the local processing load. In this way, it is possible to take advantage of the processing resources in the Mobile Cloud Network when they are available, according to intelligent resource allocation, while reducing the consumption of resources in the portable device, thus meeting one of the main objectives of iCIRRUS. The testing process is described in detail in the deliverable D5.2.

Figure 24: Testbed – videoconferencing service.


of 47


VoIP and Video call peer-to-peer use case

In this use case, we show how the network can be adapted according to the need for resources; in the case of peer-to-peer communications, it is not necessary to make use of a video mixer to optimize resource consumption. A comparison with the videoconferencing use case will be made during the testing process, described in detail in D5.2.

Video Mixer

SIP Proxy+

RTPProxy

LAN

VMWare Cloud

Softphone

Secure connection

Softphone

DDBB

2

1

3

3DNS+

DHCP

Figure 25: Testbed – peer-to-peer communications

Regarding metrics, it is possible to measure different parameters regarding Unified Communications, in accordance with different measurement levels, such as container level and application level. Also QoS metrics can be measured, in order to guarantee proper performance.


of 47


8 Device-to-device (D2D) mobile communications

In addition to the scenarios presented above, the following also provides network resource use efficiency optimization. It is based on device-to-device (D2D) communication with the goal to relax demands on the access network radio spectrum and with this increase overall network throughput.

A testbed set up for validation of centrally-controlled D2D communications is the result of the investigations performed in WP4 [13]. In the presented testbed, shown in Figure 26, the RU (RRH) is set up by a PC with OAI [1] and a USRP [6], while the DU (BBU) is set up also by using a PC with OAI. Additional details of the OAI have previously been explained in Section 4. Two Android smart-phones are used to represent the D2D UEs. The main purposes for setting up the testbed are:

• To set up the direct data communications link between the two UEs via the WiFi Direct channels under the control of the resource management in the DU (BBU), when there is no MAC layer function in the RU (RRH) after functional splitting. In this case, the D2D UEs can measure the channel condition of all the available WiFi channels and send the channel state information (CSI) for all WiFi channels to the DU (BBU). The resource management function block in the DU selects the best channel and informs the two D2D UEs to use the selected channel for their data transmission.

• To illustrate the benefit of functional splitting, if the MAC layer functions for resource management can be performed in the RU, then channel allocation can be performed there instead of in the DU. Benefits can be demonstrated accrued through the reduced delay experienced in the setup of the D2D link. This is a second-stage test dependent on progress beyond the MAC-PHY split implementation.

Allocated RB and Power D2D UE1

D2D UE2

CSI measurementsAllocated spectrum for RRH ID OAI

L3

OAM

x2

s1

L2 at BBU hotel

PDCP

RLC

MAC

L2 at RRH

L1 at RRH

RFMAC

RLC

FEC

QAM

FFT

Resource mapping Eth Eth+ +

Eth Eth

BBU (OAI in a PC) (PC+OAI)

Back

haul

RRH(USRP)

Figure 26: D2D, D2I testbed setup


of 47


The steps for the two demonstrations corresponding to the two main purposes of setting up the testbed are described in the following:

1) Demonstrate D2D communications: • Via an APP (WiFi Analyser), UE1 measures the WiFi channels between UE1 and UE2 and gets

the best channel according to the measurement; • UE1 reports the selected WiFi channel by sending a packet via an APP to the DU via RH; • DU sends the feedback to UE1 to initialise the data transmission; • Change the distance between D2D UEs to observe the connection switch from D2D mode to

cellular mode; 2) Demonstrate how D2D communications can benefit from functional splitting:

• Compare the setup delay between the two cases: one with the feedback sent from the DU, and the other with the feedback sent from the RU;

3) Setup delay comparison for the two cases: • If the mobile UE can receive the feedback packet from RU, the UE can use its own time

stamp to compare the delay difference; • If not, the RU compares the time difference between receiving the request packet from UE1

and sending the feedback packet back to UE1.


of 47


9 Interconnected showcase demonstration

Based on the previously presented test platforms, as a final interconnected iCIRRUS showcase demonstrator, we are aiming to demonstrate the coexistence of different services and fronthaul transport technology on the same Ethernet transport network and to evaluate mutual influences. The interconnection of multiple test cases is schematically depicted in Figure 27. The previously presented data/control traffic and fronthaul technology (CPRI, functional split) have different transport demands for their operation; in the presented demonstration of Figure 27 it is possible to simultaneously verify the performance of the multiple service operation concepts as proposed in iCIRRUS.

Figure 27: Final integrated scenario testbed setup

The interconnected showcase demonstration is planned to take place in Telekom Slovenije’s testing laboratory, due to the ready availability of a “real network” test section, with adaptation of the existing 4G (LTE) infrastructure and elements. The interconnected demonstration consists mainly of six integrated segments:

• CPRI/Ethernet conversion on legacy 4G network. This will demonstrate transparent CPRI to Ethernet data conversion for legacy 4G BBU to RU links. From the technical and efficiency point of view it is not the optimal conversion strategy, but it enables the first step in the investigation of packet transport effects on CPRI traffic, including the influence of transport


of 47


network congestion on the mobile signal QoS. Expected results are valuable from the 4G to 5G migration perspective, where the proposed solutions can be used in the intermediate network upgrade phase.

• Functional split emulation using OAI. This demonstrates the relocation of functionality (compared to legacy DU/RU). Using the OAI software base station emulator, it is more convenient to set different configurations, verify small-scale operational performance and evaluate technical demands. Expected results are valuable in setting guidelines for practical 5G DU/RU realisation. While the LTE base station is emulated, a real fronthaul profile, which transports real data generated within the full LTE stack and functional split in the MAC/PHY interface will be demonstrated for the first time. Priority-based scheduling will be implemented for the different streams that will be generated and will require different CoS definitions. Traffic steering and load balancing at the Ethernet transport level will be demonstrated using SDN techniques. HW probing will be used to obtain KPI statistics that will be updated dynamically in the fronthaul intelligence unit. In turn, the intelligence unit will adapt the fronthaul operation dynamically based on the extracted statistics.

• Functional split for high data-rate applications (60 GHz). This will demonstrate an evolved fronthaul with a functional split at the upper PHY for high-speed applications, together with state-of-the-art high-speed wireless access technology. It consists of a chain of building blocks from the UE wireless access point to the fronthaul aggregation point. The aim is to demonstrate an efficient technique to process and transport the high speed wireless data and map it into Ethernet (for the Ethernet aggregation network). This prototype enables the demonstration of the viability of the proposed concepts for next-generation mobile networks under 5G conditions. This means that although the system is a custom solution, it presents key features similar to those expected for 5G, such as data rates and signal bandwidth.

• Different service types aggregated over single fronthaul transport (100 GbE). This will demonstrate the aggregation of different fronthaul service types/profiles (with different transport demands) on the same Ethernet transport network. Expected results are valuable for the investigation of mutual influences on the QoS for specific services, and the evaluation of the potential of different transport/network sharing (optimization) mechanisms. It is important for 5G network convergence.

• Mobile cloud clone. This demonstrates task offloading from UE to the network edge computational/storage capacity over a fronthaul network in a multiple service scenario.


of 47


10 Conclusions and future work

This deliverable report has presented the modules and platforms, which will form the basis for the iCIRRUS integrated test validation setups, and for the iCIRRUS showcase demonstration. In parallel with this document, the accompanying deliverable D5.2 “Tools, scenarios and results analysis methods for validation test” describes the entire test procedures planned on the presented platforms.

After the first phase of standalone, test environment setups and initial functional proof of concepts, there will be an integration phase where multiple test case scenarios will be interconnected to verify proper, simultaneous operation, and to exploit interconnection benefits (i.e. additional test possibilities). These will be the presented in the future deliverable D5.3 “Validation test setup and execution report”, where the challenges and results on the module integration will be presented.

In the last phase of the iCIRRUS work package WP5, based on all the performed tests, the results relating to all the recognised benefits and potential issues will be collected, analysed and published in the final deliverable D5.4 “Validation test results and analysis evaluation”.


of 47


11 References

[1] Open Air Interface home page, http://www.openairinterface.org/ [2] Viavi, Smart SFPs Now SyncE Synchronization/Timing Compatible [Online]. Available:

http://www.viavisolutions.com/en-us/products/packetportal#literature [3] Viavi, PacketPortal Intelligent Visibility with 10GE smart SFPs [Online]. Available:

http://www.viavisolutions.com/en-us/products/packetportal#literature [4] P. Assimakopoulos, M. K. Al-Hares, S. Hill, A. Abu-Amara and N. J. Gomes, “Statistical

distribution of packet interarrival rates in an Ethernet fronthaul,” in IEEE Int. Conf. on Communication Workshops (ICC), Kuala Lumpur, Malaysia, 2016, pp. 140–144.

[5] 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, pp. 1–4.

[6] Ettus research, USRP X300/X310 specification sheet [Online]. Available: https://www.ettus.com/product/details/X310-KIT

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

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

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

[10] H. Thomas, L. Fernandez del Rosal, P. Asimakopoulos, Y. Kai, K. Wang, P. Chanclou, D. Muench, "D3.3 SLA and SON Concept for iCIRRU", 2016

[11] S. Delaitre, M. C. Torres, C. Magurawalage, K. Wang, P. Ritosa, P. Michael, M. Georgiades, “D4.3 Mobile Cloud Networking and Virtual Mobile”, 2016

[12] P. Asimakopoulos, L. Fernandez del Rosal, M. Hinrichs (HHI), P. Ritoša, D. Münch, C. Magurawalage, K. Wang, S. Delaitre, M. Castaño Torres, S. Blasco, P. Chanclou, “Tools, scenarios and results for testing analysis methods for validation test”, 2017

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

[14] Amarisoft LTE documentation home page, http://www.amarisoft.com/ [15] VIAVI MTS-5800 instrument specification

http://www.viavisolutions.com/sites/default/files/technical-library-items/5800-pb-tfs-tm-ae.pdf

[16] VIAVI ONT-100G instrument specification http://www.viavisolutions.com/en-us/products/ont-100g-test-solution-supporting-40ge-100ge-otu4

http://www.openairinterface.org/

http://www.viavisolutions.com/en-us/products/packetportal#literature

http://www.viavisolutions.com/en-us/products/packetportal#literature

https://www.ettus.com/product/details/X310-KIT



http://www.viavisolutions.com/en-us/products/ont-100g-test-solution-supporting-40ge-100ge-otu4

http://www.viavisolutions.com/en-us/products/ont-100g-test-solution-supporting-40ge-100ge-otu4


of 47


12 List of figures Figure 1: Control signalling for mobile cloud .................................................................................................. 13 Figure 2: Control signaling for D2D resource allocation.................................................................................. 14 Figure 3: F-PU Block diagram ......................................................................................................................... 16 Figure 4: F-PU Top view (Board dimensions: 280 x 310 mm) .......................................................................... 17 Figure 5: Comparison of FPGA Resources of different F-PU board versions (XCVU080 / XCKU115) ................ 18 Figure 6: COMExpress module example ......................................................................................................... 19 Figure 7: Testbed Setup ‘CPRI-over-Ethernet’ ................................................................................................ 21 Figure 8: Testbed Setup, OAI based Radio-over-Ethernet without functional split/with functional split ........ 23 Figure 9: Testbed Setup integration with sync-enabled 10G aggregator/switch or SDN-enabled switch ........ 24 Figure 10: Modules that make up the intelligence unit .................................................................................. 25 Figure 11: Test platform for high-speed functional split with millimetre-wave as radio access technology ... 26 Figure 12: Firmware for Evolved Digital Unit .................................................................................................. 27 Figure 13: Firmware for Evolved Remote Unit ............................................................................................... 28 Figure 14: Overview Testbed Setup based on 100G Ethernet Fronthaul Connectivity .................................... 29 Figure 15: Experimental setup for ETH transport lab tests of new functional split fronthaul (not CPRI) ......... 31 Figure 16: Mobile cloud clone testbed setup ................................................................................................. 32 Figure 17: Overall picture ............................................................................................................................... 33 Figure 18: Mobile cloud controller ................................................................................................................. 33 Figure 19: SQUADA Cloud Architecture .......................................................................................................... 35 Figure 20: WT system description for clone management .............................................................................. 36 Figure 21: WT Architecture based in 3 VMs for Clone and UC. ....................................................................... 37 Figure 22: Unified Communications VM. ........................................................................................................ 37 Figure 23: UC Testing scenario. ...................................................................................................................... 38 Figure 24: Testbed – videoconferencing service. ............................................................................................ 39 Figure 25: Testbed – peer-to-peer communications ....................................................................................... 40 Figure 26: D2D, D2I testbed setup.................................................................................................................. 41 Figure 27: Final integrated scenario testbed setup......................................................................................... 43

intelligent converged network consolidating radio and ... · this deliverable report is the first...

Documents