D4.2 - Building blocks development - IS-Wireless · Figure 5 Spectrum bands configuration for the LAA application scenario, i.e. licensed LTE Band 7 and unlicensed band at 5GHz

PROPRIETARY RIGHTS STATEMENT This document contains information, which is proprietary to the SOLDER Consortium.

Specific Targeted Research Projects

SOLDER

Spectrum OverLay through aggregation of heterogeneous DispERsed Bands

FP7 Contract Number: 619687

WP4 – SOLDER system development and integration

D4.2 Building blocks development

Contractual Date of Delivery: 30 April 2015 Actual Date of Delivery: Responsible Beneficiary: Sequans Contributing Beneficiaries: ISI/ATHENA RC, EURECOM, IS-WIRELESS, KCL, SEQ,

TCS Security: Public Nature Report Version: 1.0

FP7 Contract Number: 619687 Public Report: WP4 / D4.1

Security: Public Page ii

Document Information

Document ID: D4.2 - Building blocks development.docx Version Date: 30 April 2016 Total Number of Pages: 56 Abstract This document describes the selected algorithms from WP3 and

how they will be integrated into the SOLDER system. It also includes unitary test and performance results of the developed building blocks.

Keywords Prototyping, implementation, unitary test

Authors

Name Organisation Email Florian Kaltenberger EURECOM [email protected] Cedric Roux EURECOM [email protected] Charalampos Antoniadis Athena_RC/ISI [email protected] George Floros Athena_RC/ISI [email protected] Manos Antonopoulos Athena_RC/ISI [email protected] Fotis Foukalas Athena_RC/ISI [email protected] Mateusz Buczkowski IS-Wireless [email protected] Maciej Wewior IS-Wireless [email protected] Oliver Holland KCL [email protected] Aravindh Raman KCL [email protected] Guillaume Vivier Sequans [email protected] Sylvain Traverso Thales [email protected] Claude Leménager Thales [email protected]

Document History

Revision Date Modification Authors

0.1 19.08.2015 Initial TOC, section editor assignments and editing notes Guillaume Vivier

See BSCW file log for detailed revision information 1.0 29.4.2016 Final version sent to the commission See above


Security: Public Page iii

Executive Summary

This report is the second report of work-package 4 (WP4), the work-package related to proto-typing and proof of concept in SOLDER project. While D4.1 [1] provided a baseline descrip-tion of the prototyping platforms and the plan of the development, this document provides an update of the development and integration status. SOLDER addresses Carrier aggregation (CA) at large, from standard CA as defined by 3GPP to more advanced scenarios, involving unlicensed spectrum, various radio access technologies and eventually foreseen 5G waveforms. As it was not possible to prototype all possible scenarios and solutions, respectively investigated into WP2 and WP3, we were obliged to streamline the proof of concepts (PoCs) and to limit the implementation platforms. We came to 3 main proofs of concepts as defined in the Description of Work (DoW). This report first recalls the selected proposals and prototyping platforms. The first proof of concept, PoC1, is related to the aggregation of heterogeneous systems and is derived into two demonstrations.

• The first one deals with the use of LTE in TV White Space (TVWS) as a special case of LTE in unlicensed spectrum. This proof of concept is built upon Eurecom’s Open Air Interface (OAI) framework adapted to TVWS and including specific features from KCL. In particular, to ensure service continuity and Quality of Service (QoS), it is pro-posed to aggregate the LTE in TVWS with WiFi and to consider Raptor codes as pro-posed in WP4. The implementation validated the concept of such aggregation and the benefit of adding such code at upper layer.

• The second setup deals with the Licensed Assisted Access (LAA) based application scenario and aims at demonstrating elementary functionality of the LAA: listen before talk (LBT), carrier selection (CS), discontinuous transmission (DTX) and transmit power control (TPC). This proof of concept is built upon ISI’s software defined radio (SDR) platform. Learning procedures were implemented to support carrier selection, determination of transmit power and discontinuous transmission (using artificial intel-ligence techniques) thus validating the initial steps of the integration.

The second main Proof of Concept, PoC2, is related to Energy efficient transmission, and more specifically to foreseen 5G waveforms. The platform is built upon Eurecom OAI HW connected to SW modules and HW modules developed by TCS. Implementation of FBMC from Tx and Rx side was performed and tested, as well as initial PAPR reduction techniques using digital pre-distortion approach as described in WP3. The environment setup for the PoC has been validated, opening the door for measurements campaign. The last PoC, PoC3 relates to inter-band LTE CA. It is derived into two platforms:

• The first demonstration aims at demonstrating open framework to demonstrate such capability as well as advanced scheduling strategy to benefit from such capability. It is built upon Eurecom’s open Air Interface, Sequans UE prototype and IS-Wireless scheduler. All the major building blocks are developed and tested in a unitary ap-proach, while initial integration was done and already demonstrated. Further integra-tion and test at system level have to be performed and will be reported in the last WP4 report.

• The second demonstration is built upon ISI’s SDR platform to prototype simplification of the measurements procedures in context of massive CA. The proposal made in WP3 was to reduce drastically the complexity of the calculation for CQI, PMI, RI feedback. It has been implemented and validated through experimentation on the platform.


Security: Public Page iv

The preliminary outcome of the initial integration is quite promising; validating the integration phase and paving the way to experimentation that will demonstrate and validate part of the enablers SOLDER has defined in the context of CA.


Security: Public Page v

List of Figures

Figure 1: Depiction of the Augmented Broadcast scenario within the scope of device receiving enhanced coverage in a stadium environment (e.g., pico-broadcast augmented by Wi-Fi, or vice-versa). .............................................................................................................. 10!Figure 2: Mapping of fountain-coded packets to LTE Broadcast and Wi-Fi transmissions (non-systematic coding case) for different receivers of the aggregated software download. 13!Figure 3: Representation of building blocks. .......................................................................... 14!Figure 4: Sum download file/block size against time for separate TCP Wi-Fi reliable unicast and UDP Ethernet unreliable broadcast compared with the aggregation of these links using high-layer coding. The times of completion/decoding of the 1MB file/block is also marked. . 18!Figure 5 Spectrum bands configuration for the LAA application scenario, i.e. licensed LTE Band 7 and unlicensed band at 5GHz. .................................................................................. 20!Figure 6 Unlicensed spectrum band for the LAA. .................................................................. 20!Figure 7 LBT functionality for the aggregation of the unlicensed band. ................................. 21!Figure 8 DTX functionality ...................................................................................................... 21!Figure 9 Q-Learning block functionality .................................................................................. 22!Figure 10 Integration at the eNodeB for the PoC1b ............................................................... 24!Figure 11 LAA throughput performances for different channel traffic conditions. .................. 25!Figure 12: Block diagram of the set up used to demonstrate PoC2 ....................................... 28!Figure 13: High level functional architecture of an LTE network specifying the responsibility of each partner and the corresponding interfaces. ..................................................................... 30!Figure 14: Carrier Aggregation test setup .............................................................................. 34!Figure 15: Spectrum Bands required for the PoC3b .............................................................. 36!Figure 16: Low Complexity PMI/RI Calculation functionality .................................................. 37!Figure 17: Coordinated CA through Stable Matching algorithm ............................................. 38!Figure 18: The UE functionality assuming 3 bands available for CC selection based on the M-best feedback report strategy. ............................................................................................ 39!Figure 19: Integration of the individual blocks for the PoC3b ................................................. 40!Figure 20: 20 ASN section for dedicated SCell configuration ................................................ 51!Figure 21: Add SCell configuration procedure ....................................................................... 52!Figure 22: Release SCell configuration procedure ................................................................ 53!Figure 23: Activation / deactivation of SCell procedure ......................................................... 54!

List of Tables

Table 1: List of SOLDER proof-of-concepts [1] ........................................................................ 8!Table 2: List of WP3 algorithms [9][10][19] that are implemented ........................................... 8!Table 3: Hardware status of the test platform for PoC2 ......................................................... 27!Table 4: Parameters for the Carrier Aggregation unit test ..................................................... 34!Table 5: Feedback calculation runtime .................................................................................. 40!Table 6: Feedback calculation and channel allocation for different SNR values ................... 41!Table 7: Feedback calculation and channel allocation for different target rates .................... 41!Table 8: Feedback calculation and channel allocation for SM vs RM .................................... 41!Table 9: CSCHED primitives list ............................................................................................. 47!Table 10: SCHED primitives list ............................................................................................. 48!


Security: Public Page vi

Table of Contents

Executive Summary .................................................................................................. iii!

List of Figures ............................................................................................................ v!

List of Tables .............................................................................................................. v!

Table of Contents ...................................................................................................... vi!

1.! Introduction ......................................................................................................... 8!1.1! Selected algorithms from WP3 .............................................................................. 8!

2.! PoC 1: Aggregation of heterogeneous spectrum types ................................. 9!2.1! PoC 1a: Aggregation of TVWS and WiFi for augmented broadcast .................. 9!

2.1.1! Introduction ........................................................................................................... 9!2.1.2! Requirements from WP2 .................................................................................... 10!2.1.3! Selected Algorithms from WP3 ........................................................................... 12!2.1.4! Building blocks .................................................................................................... 13!2.1.5! Status of Integration ........................................................................................... 16!2.1.6! Unit test and results ............................................................................................ 17!2.1.7! Outlook and Conclusions .................................................................................... 18!

2.2! PoC 1b: Aggregation of LTE in licensed and unlicensed bands ..................... 18!2.2.1! Introduction ......................................................................................................... 18!2.2.2! Requirements from WP2 .................................................................................... 19!2.2.3! Selected Algorithms from WP3 ........................................................................... 19!2.2.4! Building blocks .................................................................................................... 19!2.2.5! Status of Integration ........................................................................................... 22!2.2.6! Unit test and results ............................................................................................ 24!2.2.7! Outlook and Conclusions .................................................................................... 25!

3.! PoC 2: Energy efficient transmission technologies ...................................... 26!3.1! 5G candidate waveform and PA predistorsion .................................................. 26!

3.1.1! Introduction ......................................................................................................... 26!3.1.2! Requirements from WP2 .................................................................................... 26!3.1.3! Selected Algorithms from WP3 ........................................................................... 26!3.1.4! Building blocks .................................................................................................... 27!3.1.5! Status of Integration ........................................................................................... 27!3.1.6! Unit test and results ............................................................................................ 27!3.1.7! Outlook and Conclusions .................................................................................... 28!

4.! PoC 3: LTE inter-band carrier aggregation .................................................... 30!4.1! PoC 3a: LTE-A inter-band carrier aggregation in homogeneous networks .... 30!

4.1.1! Introduction ......................................................................................................... 30!4.1.2! Requirements from WP2 .................................................................................... 30!4.1.3! Selected Algorithms from WP3 ........................................................................... 31!4.1.4! Building blocks .................................................................................................... 32!4.1.5! Status of Integration ........................................................................................... 33!4.1.6! Unit test and results ............................................................................................ 34!4.1.7! Conclusions and Outlook .................................................................................... 35!

4.2! PoC 3b: Dynamic Cognitive CA in HetNets: LTE-A and beyond ...................... 35!


Security: Public Page vii

4.2.1! Introduction ......................................................................................................... 35!4.2.2! Requirements from WP2 .................................................................................... 35!4.2.3! Selected Algorithms from WP3 ........................................................................... 36!4.2.4! Building blocks .................................................................................................... 36!4.2.5! Status of Integration ........................................................................................... 38!4.2.6! Unit test and results ............................................................................................ 40!4.2.7! Outlook and Conclusions .................................................................................... 42!

5.! Conclusions ...................................................................................................... 42!

References ................................................................................................................ 43!

List of Acronyms and Abbreviations ..................................................................... 44!

Appendix ................................................................................................................... 47!A1.! Scheduler API Integration status ........................................................................ 47!A2.! Example of test plan and test result for UE system integration ...................... 51!

A2.1 Test Environment ................................................................................................... 51!A2.2 Secondary Cell addition / release .......................................................................... 51!A2.3 Secondary cell activation/deactivation ................................................................... 53!A2.4 Rel 10 – HARQ Feedback ..................................................................................... 54!

A3.! Updated Scheduler API specifications ............................................................... 56!


Security: Public Page 8

1. Introduction

SOLDER work-package 4 (WP4) is dedicated to the demonstration of some of the key mechanisms developed in work-package 3 (WP3) in real systems based on the scenarios developed in work-package 2 (WP2). In the first report of WP4, D4.1 [1], we down-selected the possible demonstration use cases (inherited from WP2 and WP3) to define 3 main scenarios and 4 prototyping platforms, as recalled in the Table 1.

Table 1: List of SOLDER proof-of-concepts [1] PoC # PoC name Scenario Platform PoC 1a Aggregation of TVWS and

WiFi for augmented broad-cast

Aggregation of hetero-geneous spectrum types

KCL-Eurecom TVWS devices

PoC 1b Aggregation of LTE in li-censed and unlicensed

bands

ISI Cognitive Radio In-terface

PoC 2

Energy efficient transmis-sion technologies

5G Waveform Eurecom ExpressMI-MO2 platform

PoC 3a LTE-A inter-band carrier aggregation in homogene-

ous networks

LTE Carrier Aggregation

Eurecom OpenAirInter-face eNB with ISW

scheduling algorithm + Sequans UE

PoC 3b Dynamic Cognitive CA in HetNets: LTE-A and beyond

ISI Cognitive Radio In-terface

The D4.1 report provided a high level view of the platform and of the interfaces to allow inte-gration of various platform components, especially when they are provided by different part-ners. For instance, PoC3a includes components from EUR, ISW and SEQ that needs to be integrated together. This report explores further these components and testifies of the development of these indi-vidual components. Description of unitary testing and environment put in place to allow au-tomated regression (at least for the main components) is given too.

1.1 Selected algorithms from WP3 The goal of WP4 is to show some of the algorithms developed in WP3 in action. Table 2 gives an overview of the chosen algorithms and in which PoC they are integrated. More de-tails on the algorithms is given in the subsections of each PoC.

Table 2: List of WP3 algorithms [9][10][19] that are implemented

Algorithm PoC name

Rateless RaptorQ code PoC 1a

Listen before talk (LBT)

PoC 1b Discontinuous transmission (DTX) Transmit power control (TPC)

Carrier Selection (CS)



RF impairments compensation [10]

PoC2 PAPR reduction for contiguous and non-contiguous

Filter Bank MultiCarrier (FBMC) signals [10] Digital PreDistortion (DPD) for contiguous and non-

contiguous FBMC signals [19] MAC-scheduler API PoC3a Advanced scheduler for carrier aggregation

Low complexity PMI/RI calculation PoC3b Low-feedback rate channel assignment/allocation

2. PoC 1: Aggregation of heterogeneous spectrum types

2.1 PoC 1a: Aggregation of TVWS and WiFi for augmented broadcast 2.1.1 Introduction This PoC aims to aggregate LTE eMBMS TVWS transmission with unlicensed WiFi trans-missions. It has been given the tag “Augmented broadcast”, due to the possibility of this ap-proach augmenting the capacity and capabilities achievable through such a broadcasting system in TVWS. The PoC was built noting the strong work of KCL and Eurecom within the Ofcom TV White Spaces Pilot, and the opportunity to aggregate TVWS with other spectrum opportunities to maximize the benefit of TVWS). It has also been noted that aggregating LTE Licensed with LTE in TVWS bears some similarities to the aggregation of LTE Licensed with LTE Unlicensed (although also a number of differences—e.g., not being required to be polite to Wi-Fi in the LTE in TVWS case). This is because the use of TVWS is license-exempt. In fact, TVWS frameworks are essentially a way of specifying locally available unlicensed spec-trum, and exactly the same frameworks and methodologies might be used in other spectrum outside of TV bands in the future. TVWS technology is, in essence, seen as simply an initial test case for such a geolocation database-based “automated” regulatory framework specify-ing the local availability of spectrum for license-exempt access. Given this, the investigation of LTE Licensed with LTE TVWS aggregation is seen as of little added value (at least in a research sense—it has very significant added value in a deployment sense) compared with the aggregation of LTE-Licensed with LTE-Unlicensed spectrum usage. This is one reason why we see it is being of more interest to investigate Wi-Fi in unlicensed spectrum aggregat-ed with LTE in TVWS. There are very specific reasons for the choice of the downlink (DL) only for TVWS transmis-sion, especially in cases where the uplink (UL) receiver is at height, e.g., above roof level, as is the case for base station deployments. These are clear, e.g., from observations in [2]. Moreover, further refinements are necessary to TVWS frameworks, at least in the UK and EU based on Ofcom’s rules taken to ETSI EN 301 598 [3], given the initial rendezvous of slave devices (e.g., user terminals) with master devices (e.g., base stations) in order for the slave device to obtain their operational parameters for usage of TVWS, being often extreme-ly challenging as the initial “generic” allowed EIRP parameters for slave devices must com-monly be extremely low. It is therefore, currently, preferable for white space devices to all have internet connections and operate as master devices, except in some (e.g., low power) usage scenarios. In mobile communications-like scenarios, this translates to the use of TVWS for downlink only. Given the above, the scenario has aimed to maximize impact through TVWS experience of KCL and Eurecom, deliberately being built into the Ofcom TV White Spaces Pilot from the start as a collaborative effort demonstrating the benefits of aggregation involving TVWS, while being realistic within the range of technical capabilities and radio transmission licensing



options available to SOLDER (i.e., LTE transmission through OAI and ExpressMIMO2 hard-ware, covering TV band frequencies, twinned with unlicensed access though COTS Wi-Fi hardware). Figure 1 depicts this scenario. The LTE TVWS transmission might be hosted on the top of a tall building providing wide-area coverage; it could alternatively be hosted in a venue such as a stadium, where viewers of an event would wish for localised broadcast of content (e.g., the close-up view of the action, replays of the action, etc.—essentially, augmented spectating of an event). This would be very challenging to provide purely over conventional (e.g., Wi-Fi, mobile) access—due to the exceptionally-high capacity densities that would be required. It is intended for this to be a means for achieving localized broadcast to mobile devices, without having to obtain a license as would be the case for eMBMS transmission conventionally. It is noted that there is some commercial interest for such “pico”-broadcast systems (see, e.g., [4]). Although this is in the context of local DTT broadcast in TVWS, there is no reason why this couldn’t be LTE eMBMS broadcast using TVWS. Moreover, the aggregation with the local Wi-Fi access, where that Wi-Fi access is sufficiently available, could augment the con-tent, e.g., providing extra layers of video improving video broadcast quality, or reducing the time that a large-scale software download would take. Regarding the latter, there are many challenging cases where very large software downloads might need to be urgently provided to devices, e.g., software updates due to security flaws, or due to an extremely high demand for a current popular content. Conventional (unicast) download of such content, in these cas-es, would be highly inefficient for the operator and could overload the network; broadcast could offer greatly improved efficiency.

Figure 1: Depiction of the Augmented Broadcast scenario within the scope of device receiving enhanced coverage in a stadium environment (e.g., pico-broadcast augmented by Wi-Fi, or vice-versa).

2.1.2 Requirements from WP2 A subset of the key requirements from WP2 for this scenario is paraphrased/summarized from Deliverables 2.1 [12] and 2.2 [14] as follows. 2.1.2.1 Component-Level Requirements

1. Devices and radio network components must be able to concurrently transmit and re-ceive on TVWS and “conventional” unlicensed (e.g., ISM) resources, respectively with LTE and Wi-Fi waveforms. This will generally mean the implementation of sepa-rate LTE and Wi-Fi radios on the devices. It is noted, however, that for the specific



case of this PoC 1a and augmented broadcast, the TVWS radios only need to trans-mit at the BS, and receive at the UE.

2. Devices and radio network components must meet spectrum mask requirements in the TVWS and “conventional” unlicensed bands, for their LTE and Wi-Fi waveforms respectively. In the TVWS case, there is a selection of spectrum masks to choose from, which effectively trade off against the allowed EIRPs in channels.

3. Devices on the TVWS LTE side must be generally compliant with TVWS regulations [5], [3].

2.1.2.2 System-Level Requirements

1. Given that the LTE system is operating in TVWS in this case, it must have Internet connectivity to access a geolocation database.

2. The Wi-Fi access point should also generally have Internet connectivity. 3. The LTE broadcast covers a wide area and is fixed, and the Wi-Fi is fixed and spo-

radic, covering relatively small areas within the wide-area coverage of the LTE broad-cast.

2.1.2.3 System-Level Architectural Requirements

1. A geolocation database that assesses TVWS availability dependent on location must be present.

a. The LTE BS that must directly access this through the Internet, and not a net-work management entity within the LTE standard. This may not be fully in line with LTE architecture. However, it is anticipated that there will be flexibility in white space rules if system reliability/security in the implementation is demon-strated, such as through a standard (e.g., LTE/LTE-A). In this case, it may be possible for the system to query the database on behalf of the LTE base sta-tion itself.

2.1.2.4 System-Level Functional Requirements The following system-level functional requirements are assessed:

1. Coding/decoding at the application layer (e.g., layered video, or application-level cod-ing of a software-download) must apply at the server a client, e.g., the two ends of the end-to-end transfer. This is to allow the combining of the streams. This is necessary for the foreseeable future as it is anticipated that the aggregation will occur at the IP layer or higher, with coded packets being combined that are transported over the dif-ferent systems (LTE and Wi-Fi) in different streams.

a. Such coding can be alternatively be implemented at an intermediary in the network (a common point on the route) of the two flows.

2. There must be a multi-stream functionality, or alternatively the application controlling

the transfer must invoke two different unicast streams. This might again be imple-mented at an intermediary in the network (a common point on the route).

2.1.2.5 System-Level QoS Requirements and KPI Expectations The following capacity and QoS requirements are assessed for this context:

1. First considering one application, that of layered video, delay requirements are highly flexible although must typically be able to satisfy a given pre-decided bound. To achieve sufficient end-user satisfaction, the maximum delay bound in accounting for



delay variability (hence, the duration of buffering before video playback, in the case of layered video application for example) can range from one to a small number of se-conds. Regarding other QoS requirements, it is noted that the rate of the LTE system must be sufficient to provide the base layer of the layered video, and the rate of the Wi-Fi system being aggregated should ideally be sufficient to provide one of more of the additional layers. In the case of background software downloads, such constraints need not apply. Finally, requirements such as packet loss are flexible depending on aspects such as the coding rate that is applied to the video layers, or alternatively the number of packets that can be additionally dropped. For the software download case, as the separate packets are coded, there is no particular requirement on packet loss rate. In the Wi-Fi case, of course, packet loss is automatically addressed by the sys-tem.

a. The QoS requirements of the aggregated traffic are already implied by the re-quirements on the separate LTE and Wi-Fi provisioning described above.

2. Concerning KPI expectations, a key expectation is that the aggregation will be able to support at least one additional layer of video. This is very much open to interpretation, however, it is anticipated that an additional 2-3 Mbps throughput through aggregating with Wi-Fi should be sufficient to achieve this purpose, noting that HD video typically only requires 5Mbps (e.g., Netflix streaming [6]). This can be considered as the abso-lute baseline requirement. It is further noted that the 5MHz LTE bandwidth, which we are currently using to best match to the 8 MHz TV channel width, will likely just be able to achieve even a 5 Mbps throughput requirement [7]. We may investigate high-er bandwidth video, or smaller LTE bandwidths, to address this issue. If we choose a higher bandwidth 4k video, this represents a throughput of around 15-16 Mbps (or a most-challenging case of 25 Mbps, using Netflix as an example [6]). The choice of KPI expectation for the software download case is again somewhat arbitrary, howev-er, it is expected that through at least a doubling of the theoretical maximum of 5MHz LTE is a good aim to aim at.

2.1.3 Selected Algorithms from WP3 Selected algorithms are paraphrased from Deliverable 3.1 [9] and 3.2 [10] content as follows. The primary solution for this aggregation scenario is based on higher layers, as aggregation at lower layers in many such cases implies fundamental changes such that the standards that are being aggregated are no longer compliant, and is anyway either not possible or ex-tremely challenging in such cases where the transmission bands are significantly spaced in this way and the MAC structures/solutions are so different thereby making aggregation diffi-cult at the MAC layer. The key solution is a fountain coding scheme coding the information set at the source, and decoding at the receiver. RaptorQ codes are chosen for this and are particularly applicable to the case of, e.g., a large-scale software download as the application—the efficiency of which could be greatly improved through the use of broadcasting. These coding schemes may also assist in layered or other multi-rate video cases. From Deliverable 2.3 [8], Figure 2 shows how such a rate-less coding scheme can be applied in terms of mapping of the coded pack-ets to the download. This is for the case of a single block serving the download, which is possible with RaptorQ codes.



Figure 2: Mapping of fountain-coded packets to LTE Broadcast and Wi-Fi transmissions (non-systematic coding case) for different receivers of the aggregated software download.

A key aspect for this scenario is the development of a controller application. This application must have counterparts in the server and client, and also at a mid-point if such a mid-point is used for the coding and splitting of the content among multiple streams, and will manage the distribution of the media (e.g., download file, video) among the sockets or multiple connec-tions/streams in the case of use of a protocols that support that. Importantly, this controller application is also necessary to handle the interaction with the geolocation database and implement responses from such a database correctly, in such a TVWS case as well as any other future such database-driven sharing solution.

2.1.4 Building blocks Work and experimentation with various potential forms and methods of implementation of this idea has been undertaken, however, the core implementation for the purpose of this work is based on Python 2.7. The key elements involved in the PoC are the controller entity, the coding and decoding im-plementation, transport control, and the radio hardware comprising the lower layers of white space access and Wi-Fi access, and computational entities, in this case comprising high processing capability (but nevertheless, energy efficient) PCs used to host the Express-MIMO2 software radios and Wi-Fi radios, and run the controller application/coding and of course other layers of the communication (transport, and associated). They are, including their interactions, illustrated in Figure 3.



Figure 3: Representation of building blocks.

The hardware aspects towards the upper-right of this figure have already been illustrated in Deliverable 4.1 [1], including details such as the waveform generation, filtering, frequency adaptation, and control thereof. Here we provide more detail on the software aspects of the building blocks. Perhaps a good way to introduce the coding and transport control building blocks is to detail the coding and communication aspects as configured by a JSON input file. An example of this JSON input file is as follows.

{ "coding_scheme":"rcoder", "subsymbol":4, "symbol_size":2000, "symbol_block":1800, "send_file":"./words.txt", "mediums":{ "pre_data":{ "name":"eth0", "type":"wifi", "protocol":"tcp", "sender_ip":"127.0.0.3", "receiver_ip":"127.0.0.3", "port":8889, "buflen":1000 }, "thread1":{ "name":"wlan0", "type":"wifi", "protocol":"udp", "send_percent":[ "11-50" ], "sender_ip":"127.0.0.1", "receiver_ip":"127.0.0.1",

Controller(application

TV#white#space#periodic#Ofcom weblisting of#database#checks

RaptorQcoder/decoder#and#coded#or#received#

packet#set

TV#white#space#periodic#chosen#geolocationdatabase#queries

TV#white#space#periodic#geolocation information#polling#from#GPS#module

Control#of#white#space#radio#based#on#responses#from#

geolocationdatabase

Termination#of#white#space#radio#if#operation#fails#or#database#access#

is#not#available

Transport#control:#transport#protocols,#interfaces#control;#distrib.#of#coded#packets#among#interfaces

OpenAirInterface over(ExpressMIMO2(providing(TVWS(interface

(hardware(example(from(D4.1(as(follows)

COTS(WiFFi(radio(providing(WiFFi(interface

Uplink#RF(UE#only)

Downlink#RF#(BS#only)

GPS#passNband#filter

Mixing High#backNoff#amplification

Variable#LO#(R&S#SMB100A)

EurecomExpressMIMO2

OpenAirInterfacewaveform#generation

AntennaLow#power#amplifier



"port":8888, "buflen":1024 }, "thread2":{ "name":"tvws", "type":"lte_mbms_over_tvws", "protocol":"udp", "send_percent":[ "1-10", "51-100" ], "sender_ip":"127.0.0.2", "receiver_ip":"127.0.0.2", "port":8898, "buflen":1000, "rate":"100K" } } }

This file allows the type of coding scheme to be configured (in the example shown, the scheme “rcoder” specifies the RaptorQ coding), the parameters of the coding scheme, and a number of “mediums”, noting that the first one, “pre-data” is a special case which sends con-figuration information to the destination such as on the transport protocol, and information on the coding characteristics, among other aspects. It is noted that this information must be re-ceived by or known to the receiver in some form, so it is sent by a reliable transport in our implementation here, however, in the case where a reliable transport could not be guaran-teed (e.g., if only the broadcast were present), such information could be assumed to be al-ready known either in a hardware configuration (e.g., as set by the manufacturer—comparable the implementation of digital broadcast receivers, such as set-top boxes), or perhaps downloaded prior to the participation/reception of the session if a prior opportunity existed. The mediums “thread1” and “thread2” specify the configurations of the interfaces that the information is actually sent over, allowing the specification of which percentages (potentially also, at a later implementation, which exact packets) of the coded data set are sent over which interfaces. It is noted that for the purpose of the implementation here, we only use two such interfaces. However, our transport implementation here is not limited to two interfaces, being able to open up and divide the coded data set among any number of such interfaces. It essentially creates a new thread for each communication streams and initiate any number of such communication streams/threads over different interfaces (or, even, over the same inter-face), only being limited by the computational capabilities of the host computer. The implementation proceeds in the following order, noting that the same software imple-mentation can be used at the sender or receiver side and used for both server and client depending on an internally configurable parameter as the abovementioned JSON file. First, it assesses whether it is acting as a sender or receiver (server or client). If acting as a sender, it first runs a routine to code the data set and provide the pre-configuration data for sending upfront to the receiver. This same routine provides these two elements as a list of two objects returned from the same function. It then initiates the sending of the preconfiguration data to the receiver. Then it loops through each communication in-stance/instance as specified in the “threads” of the JSON file, setting up a thread for each and initiating the communication.



At the receiver side, the receiver listens for the preconfiguration data and configures the de-coder and other elements with the preconfiguration data it receives, then listens for the data over the different interfaces preconfigured. It puts all of the received data from each of the interfaces in the same receive queue, and then tries to decode the file from the receive queue once it has received an amount of coded data that is equivalent to a certain proportion of the original file size. It is reminded here that if the receiver attempts to decode after receiv-ing the same number of symbols equivalent to the amount of data in the original data, then there is only one in a hundred chance of failure. If only 2 symbols more than the number of symbols equivalent to the original data set is received, then there is only one in a million chance of decoding failure. The more coded symbols received, the lower the chance of de-coding failure. At the sender side, the reliable transport implementation (e.g., TCP over Wi-Fi) can be con-figured to continue until the file is received, whereas the unreliable transport implementation (e.g., UDP over LTE MBMS broadcast) can be configured to continually loop through trans-mission of its available coded data as long as is necessary dependent on the receiver set. The following are the key elements of the implementation:

• Encoding class o Function to handle encoding in general o Function to configure RaptorQ parameters o Function to handle RaptorQ encoding

• Decoding class o Functions to handle decoding in general o Functions to configure RaptorQ decoding parameters o Functions to handle RaptorQ decoding

• RaptorQ coding/decoding functions definition o Defining the actual operations for RaptorQ coding and decoding, as triggered

by the above encoding and decoding classes • UDP handling class

o Class initiation function o Function initiating socket and returning handle to the socket o Data sending function o Data receiving function

• TCP handling class o Class initiation function o Function initiating socket and returning handle to the socket o Data sending function o Data receiving function

• State machine file and functions o Specifies the order/flow of operations as discussed in the text above

2.1.5 Status of Integration All lower layer aspects have been implemented – completed long before Deliverable 4.1 [1] was delivered in April 2015, and referred to in Section 2.1 of Deliverable 4.1 [1]. This in-cludes the radio/RF aspects of the white space devices, the LTE baseband generation for TVWS through the OAI software, and Wi-Fi in the host devices. The controller aspects re-garding the operation of the LTE devices as white space devices—e.g., dealing with the communication with the white space databases and implementation of responses, informing the database on resource choice, checking with the web-listing of databases, and all the oth-



er requirements as specified in ETSI EN 301 598, have also been completed long before the completion of Deliverable 4.1. Regarding the coding/decoding and transport control, our Python implementation is fully achieved currently, and is capable of both UDP and TCP transport over interfaces. The only aspects that remain to be considered for the Python version if the implementation of signal-ing for termination of the UDP broadcast once receivers have all received the content, the maintaining of receiver status information on a per-receiver basis, and implementation of advanced coding ordering aspects such as covered in Deliverable 3.2 Section 9.3 [10]. Hence, the Python implementation is fully functional, only with the more advanced aspects to be added based on future consideration. Our implementation is currently from the viewpoint of implementing large downloads (e.g., devices software upgrades) aggregated over the links. Other media types, such as augment-ed streaming video, require some further work to implement—although we see them as achievable.

2.1.6 Unit test and results The white space implementation aspects of the devices have been tested by three Ofcom engineers visiting KCL in November 2014. It was confirmed that their interactions with the white space database performed as expected and the devices were performing correctly. It was even noted that the KCL-Eurecom devices surpassed the other professional white space devices in the Ofcom Pilot in the sense that the professional devices failed to implement the “kill switch” properly, and also didn’t inform the database properly on their resource choices and wait for acknowledgement before transmitting. The KCL-Eurecom devices implemented all such aspects correctly. Correct operation of these aspects can also be verified by the re-sults that are reported elsewhere in SOLDER deliverables concerning data obtained and post-processed from the geolocation databases through our developed signaling procedures, interactions with the geolocation databases, and tools developed to assess white space availability and aggregation performance in white space (see, e.g., [8], [10], [1]). Regarding the higher-layer coding and transport control aspects, it is noted that they can be effectively tested over any interface as long as the interface can be bound to a socket. Hence, we have tested both such implementations through aggregating a broadcast over the Ethernet network at King’s College with a reliable transfer over the Wi-Fi network, as well as aggregating both over the Ethernet network. They will equally be implementable, through simple parameter changes, over the OpenAirInterface interface using ExpressMIMO2 hard-ware that is controlled by our TV white space controller application, as referred to in the above. Regarding such testing, our Python implementation is operating exactly as expected, being able to reconstruct the download once the preconfigured amount of data is received, and verifiably distributing the data correctly (and collecting the data correctly at the receiver) among the interfaces/threads. Testing thus far has concentrated only on the large file down-load case; testing of other applications such as augmented/enhanced video streaming re-quires further work. Nevertheless, Figure 4 depicts the cumulative received data and comple-tion/decoding times of a 1 MB file or block, under the concept, for the separate TCP Wi-Fi reliable unicast and UDP Ethernet unreliable broadcast, compared with the aggregation of these links using the high-layer coding. In this case, the UDP Ethernet was transmitting at a rate of 1.5 Mbps, over an engineered lossy link with an extremely high packet error rate av-eraging 40%. This 1.5 Mbps value was chosen as it represents an achievable rate in LTE MBMS with MCS 7, under the assumption that 22 out of the 25 resource blocks are used for



the broadcast with the remaining resource blocks being available for other user data trans-missions. MCS 7 is a relatively robust choice able to cope with a low SINR, noting that we nevertheless still experiment with an extremely challenging scenario through the engineering of the highly lossy link. Results show that the TCP Wi-Fi reliable unicast connection alone was able to complete and decode the file/block download in t_TCP = 5.4 seconds, whereas the UDP Ethernet unrelia-ble broadcast connection completed and decoded the file/block download in t_UDP = 6.9 seconds. The aggregation approach completed and decoded the file/block download in t_comb = 3.5 seconds. Hence, there was a reduction of 49% of the file/block download time for the aggregation approach compared with the TCP Wi-Fi reliable unicast, and 35% of the file/block download time for the aggregation approach compared with the UDP Ethernet un-reliable broadcast.

Figure 4: Sum download file/block size against time for separate TCP Wi-Fi reliable unicast and UDP Ethernet unreliable broadcast compared with the aggregation of these links using high-layer coding. The times of completion/decoding of the 1MB file/block is also marked.

2.1.7 Outlook and Conclusions The outlook for implementation of this PoC is looking positive. A first version has been im-plemented, and remaining aspects are simply some of the more aspirational or advanced features. Such remaining aspects including the implementation for other traffic types aside from large file downloads, and aspirational aspects such as optimization of the coded pack-ets distribution among the broadcast and Wi-Fi links to receivers given feedback on the pre-cise situation at receivers.

2.2 PoC 1b: Aggregation of LTE in licensed and unlicensed bands 2.2.1 Introduction The PoC 1b is related to the LAA concept of 3GPP Rel.13 [11], which is the most advanced licensed and unlicensed spectrum aggregation paradigm today. At the beginning for the pro-ject, the LAA was not yet announced from the 3GPP; the concept was first introduced as LTE-U from Qualcomm that later was adopted within 3GPP as LAA, where the LTE system

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4 5 6 7

Data$Received$(M

B)

Time$(s)

TCP.Wi1Fi.(Reliable.Unicast)

UDP.Ethernet.(Unreliable.Broadcast)

Aggregated.Through.High1Layer.Coding

t_comb t_UDPt_TCP

File/block$(1$MB)completed anddecoded



accommodates the unlicensed spectrum aggregation. The 3GPP LAA concept is fully com-patible with the spectrum overlay concept that was proposed by the team members and to this end, our contribution gives additional functionality to this topic. In particular, the PoC1b provides one on hand the LAA functionality based on 3GPP Rel.13 and on the other hand addresses the challenge of carrier selection (CS) scheme that can efficiently utilize the unli-censed carrier. Notably, CS feature has not been addressed within the Working Item (WI) of 3GPP Rel.13 [11] and our solution could be considered as a proposed solution given the fact that the PoC1b relies on an LTE testbed. In particular, using advanced LBT, DTX and TPC functionalities and employing artificial intelligence (AI) algorithms for machine learning, our solution provides an efficient coexistence between LTE and WiFi under the LAA concept.

2.2.2 Requirements from WP2 The particular requirements for the platform to accommodate the PoC1b are described below and are related to the RF boards required for the PoC1b implementation and demonstration:

• One requirement is to have RF boards available to transmit and receive signals in the unlicensed frequency range of 5150-5350 MHz.

• The RF boards should be capable to transmit and receive in the LTE band 7 and the baseband to provide the necessary functionality for aggregation of both streams, i.e. licensed and unlicensed.

• The baseband should be able to accommodate the new LTE building blocks required for the LAA application.

2.2.3 Selected Algorithms from WP3 The PoC1b relies on our LAA study that was reported in the D3.2 [10] with details. In particu-lar, the selected algorithms are the followings:

• Listen Before Talk (LBT) that requires the application of a Clear Channel Assessment (CCA) check before using the channel. Carrier sensing is a fair way of sharing spec-trum in unlicensed bands where other systems operate along with LTE.

• Discontinuous transmission (DTX) provided on a carrier with limited maximum trans-mission duration.

• Carrier selection (CS), so that LAA nodes can use carriers with low activi-ty/interference.

• Transmit Power Control (TPC) as a regulatory requirement in some regions by which the transmitting device should be able to reduce the transmit power in some propor-tion to the maximum allowed.

2.2.4 Building blocks In order to meet the RF requirement for both the transmission and the reception of the sig-nals, four chains are built up by LMS6002D transceiver [15], to form the Tx/Rx chains for the licensed spectrum bands with a range of frequencies from 300 MHz to 3800 MHz. The aforementioned chipset has a tunable bandwidth of up to 28 MHz, which is adequate to sup-port the CA scenarios, which will be implemented in this platform. The fifth Tx/Rx chain dedi-cated in the unlicensed spectrum uses the AD9361 chipset [16], which is a second-generation transceiver with MIMO capabilities and is capable of supporting a wider range of frequencies from 70 MHz to 6GHz. This chipset has a tunable bandwidth of up to 56 MHz, supports both FDD and TDD operation modes and has a superior receiver sensitivity with a noise figure < 2.5 dB. The AD9361 are also available to the AD-FMCOMMS5-EBZ evaluation board [16], which can be also used for the PoC1b demonstration since the spectrum range of AD9631 provides LTE bands too.



Figure 5 Spectrum bands configuration for the LAA application scenario, i.e. licensed LTE Band 7 and unlicensed band at 5GHz.

The ISM band has a range between 5150 and 5825 MHz (Figure 6). The SDR platform is capable of transmitting and receiving signals in the first two portions of the ISM band, which can be seen above, using cc where each cc can have a bandwidth of up to 20MHz.

Band Frequency Range Bandwidth U-NII Low / U-NII-1 / U-NII In-

door 5.150-5.250 GHz 100 MHz

U-NII Mid / U-NII-2 / Power 5.250–5.350 GHz 100 MHz

U-NII WorldWide / U-NII-2e 5.470-5.725 GHz 255 MHz

U-NII Upper / U-NII-3 5.725-5.825 GHz 100 MHz

Figure 6 Unlicensed spectrum band for the LAA.

The algorithmic features presented above were implemented as building blocks in SDR plat-form found in D4.1. We give below the details of how the building blocks were developed:

• Listen before talk (LBT): The LBT block is employed exactly before the beginning of each LTE frame. It requests the current !!! availability from the power detector and if the result is that the selected !!! is clear from other signals it enables the utilization of !!! in the following way. It informs the RF switch to enable the usage of the unli-censed carrier. Next, it utilizes the !"#! (Channel Occupancy Time) value or the Q-learning action received from the Carrier Selection block to enable the required Dis-continuous Transmission (DTX). This function is used to fill only a portion of the frame with symbols. This portion is decided by the remaining percentage of time that the channel is not utilized by WiFi users i.e. (1-!"#!)*10 subframes. Figure 7 below pro-vides the details of LBT functionality.



. . .

Figure 7 LBT functionality for the aggregation of the unlicensed band.

• Discontinuous transmission (DTX): The !"#! value or the action from the Q-

learning algorithm received from the CS module, is used to enable Discontinuous Transmission (DTX) and thus alerting1 the Layer Mapper to not fully fill the entire frame with information signals. After the subframes that were allowed to transmit, the DTX procedure stops using the channel, and the Wi-Fi users have now the channel available to transmit their own data. Figure 8 below provides the DTX functionality.

Frame i Frame i+1

Figure 8 DTX functionality

• Carrier Selection (CS): For the purpose of the Carrier Selection (CS) two techniques

have been implemented in the platform so far. The first one is the Channel Occupan-cy Time (COT). The energy detector scans a channel and measures a power level. This measurement is compared to a predefined threshold and if it exceeds this threshold, the detector decides the presence of a signal in the channel, i.e. a busy channel. In the other case it decides an idle channel. The energy detector is enabled several times during this sensing period and the COT of channel i is calculated as a simple percentage of the busy samples of the energy detector versus the total sam-ples taken:

!"#$ = !!!"#$!

!!"!#$

1 In case of a MAC layer implementation, the DTX notifies the scheduler in order to adapt the transmission on the unlicensed band. Keep note that the CRI platform has been built with PHY layer functionality only.

Frame 1 Frame 2 Frame 3 Frame K

SubFrame DTX LBT idle period



where !!"#$! denotes the number of detections on channel i that resulted in the deci-sion that the channel was busy and !!"!#$ the total number of detections on each channel.

Alternatively, a Q-learning algorithm technique was implemented to provide enhanced CS technique. The CS module initializes a Q-function based on the input from the spectrum sensing (SpSe) module. Afterwards, when the eNodeB wants to transmit two CCs, the first one is sent through LTE band 7 and the second one is sent through ISM band. After the transmission is over the SpSe module is going to update the information about the traffic in the unlicensed band. Finally, with this information the module computes the next states and action and provides the action to the DTX block in order to properly fill a portion of the LTE frame. Below a flowchart of the particular implementation is provided. Figure 9 below pro-vides the functionality of Q-learning.

Figure 9 Q-Learning block functionality

• Transmit Power Control (TPC): Regarding TPC, for the PoC1b, the Q-learning algo-

rithm has been implemented on the platform that does not incorporate interference-power aware TPC. This feature is provided by the double Q-learning solution that is proposed and tested in an open source simulation environment as described in D3.2. The TPC for the PoC1b is used as provided in the LTE-A context.

2.2.5 Status of Integration In D4.1 [1], we provided the sequence diagram of the PoC1b functionality. In the text below, we provide a diagram that give details about the integration of the new blocks into the exist-



ing LTE platform. The main integration issues are related to the control of resource block mapper at the level of scheduling, trigger mechanism for the synchronization of the DTX and the new channel-sensing unit including the required LBT triggering. Figure 10 provides an overview of the changes in the current LTE system. In particular, Figure 13 below explains the integration as follows:

• The SpSe block is used to sense the unlicensed band in order to provide traffic and interference statistics for the available unlicensed CCs of 20MHz at 5GHz unlicensed band. Voltage samples are taken using the Power Detector and are forwarded to the TPC and CS modules of the Learning procedure. In order to opportunistically exploit the spectrum, non-cooperative SpSe has been implemented via Energy Detection. More particularly, RF power detectors are used in order to sense the spectrum and exploit it in the absence of other Unlicensed Band users. Four LT5538 chipset [16], for the Licensed Spectrum and One LTC5533 chipset [17], for the Unlicensed Spec-trum have been used for the needs of SpSe. The LT5538 which are used for the li-censed spectrum have a frequency range between 40MHz and 3800 MHz and are capable of measuring RF signals over a wide dynamic range, from –75dBm to 10dBm. On the other hand, the LTC5533 is capable in operating in a very wide range of frequencies, which makes it ideal in order to be used for the ISM band in the 5GHz region. More specifically, the aforementioned RF power detector can operate in fre-quencies from 300MHz up to 11GHz and is capable of measuring RF signals from –32dBm to 12dBm.

• The Learning procedure initializes the involved Q-functions and determines transmit power, CC Selection and DTX duration, as explained above.

• Prior to the beginning of the LTE frame, the CC Selection signal is forwarded to the RF Switching module to set the RF at the selected center frequency of the selected CC. At the same time the signal is received from the LBT module, which receives voltage samples of the selected CC from the Power Detector in order to determine if a LAA transmission, can occur. If it can, the Layer Mapper is notified through the Tx Trigger signal, in order to forward a number of transport blocks to the physical layer, defined by the DTX signal produced by the Learning procedure.

• The LBT module notifies SpSe to begin collecting samples from the unlicensed band for the next frame. These samples are voltage values detected in each candidate CC, provided by the power detector. This happens either immediately, if no LAA transmis-sion is to take place (SpSe receives the Tx Trigger signal produced by the LBT mod-ule), or after the LAA transmission has ended, i.e. DTX subframes.

The figure below (Figure 10) depicts with green boxes the new building blocks and how they are integrated in the LTE PHY baseband platform including the features of the RF boards, where for the latter the AD-FMCOMMS5-EBZ provides them too [15]. With red lines, the trig-gering messages are depicted between the existing and new blocks.



Figure 10 Integration at the eNodeB for the PoC1b

2.2.6 Unit test and results We tested the performance of the LAA scenario by measuring the throughput obtained in the baseband platform for different SNR values and comparing the results between COT estima-tion and Q-Learning techniques. Notably, within the D4.2 timeline, we implemented the new building blocks and integrated into our reference SW design of LTE PHY layer. The results are obtained assuming the capabilities of the RF boards providing thereby the CS procedure. Simulation environment was provided for the WiFi traffic with a random way, i.e. a vector of Bernoulli random variables with parameter equal to the desired COT is generated for the duration of the experiment and represents the existence of a WiFi signal. Assuming perfect detection by the energy detector, we gain accurate estimation of the COT for each COT val-ue, without providing however realistic WiFi operation. The same procedure is followed for the Q-Learning algorithm in order to be able to compare both schemes under the same WiFi traffic conditions. The results are displayed in Figure 11. The results were obtained using two 20MHz CCs, one in the licensed spectrum and one in the unlicensed spectrum. In Figure 11, the evaluation of the two algorithms concerning three different Wi-Fi traffic scenarios is presented. Comparing the Q-learning and COT learning techniques, it can be observed that with low traffic in unli-censed band the COT provides more aggregated throughput, but as the traffic load increases Q-learning seems to perform better. This is due to the better adaptation to channel conditions provided by the Q-Learning technique, which leads to more transmission opportunities in high load conditions compared to COT estimation. In addition, the throughput of the licensed 20 MHz CC is provided in the figure in order to give an insight about the gains of LAA under different COT conditions. The gain of utilizing CA with an unlicensed CC is considerable,



especially under low WiFi traffic where the throughput performance is increased by 90 % for 20 dB SNR.

Figure 11 LAA throughput performances for different channel traffic conditions.

2.2.7 Outlook and Conclusions We have developed and evaluated the algorithms designed and developed in the D3.2 [10] for the efficient CS within the LAA framework. This is actually our work on efficient coexist-ence of LTE with WiFi through unlicensed spectrum aggregation submitted to the IEEE TCCN. The integration of the new algorithms was being carried out within the timeline of the D4.2 and presented above. Unitary test on the baseband PHY layer SW were being carried out in order to validate the integration process, to test the interfaces between the different building blocks and to evaluate the performance at system level. Next step, within the D4.3 timeline is to integrate the design to the Xilinx FPGA platforms driving the RF for the PoC1b testbed results that we will be also able to demonstrate.



3. PoC 2: Energy efficient transmission technologies

3.1 5G candidate waveform and PA predistorsion 3.1.1 Introduction The “energy efficient transmission technologies” PoC is addressed by the scenario “Toward 5G scenario” described in SOLDER deliverable D2.1 [12]. The aim of this scenario is de-scribed in SOLDER deliverable D4.1 [1] and consists to minimizing the Out of Band (OOB) power and increasing Power Amplifier (PA) efficiency. The OOB power is mainly due to the non-linearity of the UC (Up Converter) and PA. The in-band signal quality (expressed in terms of Error Vector Magnitude (EVM) and/or Bit Error Rate (BER) is also a collateral bene-fit of the linearization technique employed to improve OOB and PA efficiency.

3.1.2 Requirements from WP2 It is expected that the CA through a 5G waveform will mainly result in improving the usage of the available spectrum, which is considered to be a more and more scarce resource. More specifically, we expect that the side-emissions (considered as interferences) are much lower than in the 4G scenarios. It is also expected that the stringent time and frequency synchronizations in the neighboring cells be much more relaxed since there is no need for time synchronicity between cells. In the deliverable D2.3 [8], the following KPI have been identified through the usage of FBMC as an alternative PHY layer:

- Improvement of the area power-spectra-efficiency (Watt/bits/s/Hz/km²) by causing less interference,

- Improvement of the cell-edge throughput thanks to the relaxed synchronicity constraints between cells.

Since it is not realistic to demonstrate in SOLDER an improvement of the area power spectra-efficient and the cell-edge throughput, we propose to assess alternative performance indicators which are closely related to these KPI:

- Improvement of the transmitter linearity: the OOB is expected to be lower than -50 dBc, (-60 dBc is the target objective). The linearity improvement in this case is comprised between 10 to 20 dB with respect to a transmitter that does not use any linearization technique,

- Improvement of the transmitter power consumption: we expect to be able to decrease the transmitter power consumption by 5% with respect to a transmitter that does not use any linearization technique.

3.1.3 Selected Algorithms from WP3 The PoC2 relies on algorithms already described in deliverable D3.2 [10], but also on algo-rithms, which are currently in development and further described in deliverable D3.3 [19]:

- RF impairments compensation - PAPR reduction for contiguous and non-contiguous Filter Bank MultiCarrier (FBMC)

signals - Digital PreDistortion (DPD) for contiguous and non-contiguous FBMC signals



3.1.4 Building blocks The following building blocks have been developed:

- FBMC modulation o Basic FBMC Transmitter o Basic FBMC Receiver

- RF impairments compensations - PAPR reduction for FBMC signals

o Contiguous case o Non-contiguous case

The following building blocks will be developed according to the on-going WP3 work (related to the D3.3) on DPD:

- DPD for contiguous case - DPD for non-contiguous case

These blocks are written in Matlab and will be adapted in Octave when modifications will be required.

3.1.5 Status of Integration The hardware and software status of the test platform are respectively provided in Table 3. The hardware platform is fully available and the functional tests must be performed.

Table 3: Hardware status of the test platform for PoC2

Piece Status Remarks PC Installed Functional ExpressMIMO2 Installed Need tests for functionality 10Gb Ethernet board

Installed Need test for functionality

Heterodyne Receiv-er (USRP X310)

Available Can be replaced with N210 if neces-sary

Small Form-factor Pluggable (SFP)+ cable

Available Required for wide band acquisition through X310

Power Amplifier Available At least one PA is required Need tests for functionality

Attenuator Set

3.1.6 Unit test and results For this PoC, the results shall be analyzed at different points:

- At the signal In Space (antenna or around) - At the return path used for calibration (inversion of the impairments)

The following demonstration (see Figure 12) is set up to demonstrate the minimization of the OOB emission and the linearity of the transmitted signal (which results in a more difficult ex-ploitation at the receiver level or loss of efficiency). Note that the measurements should be performed at the air interface but, for practical reasons, the antenna is not in the scope of the demonstration. Thus, the measurements will be done at the Tx antenna interface. Two measurement paths are used for each scenario:



• Calibration path based on a direct down conversion architecture. This path is known as the calibration path and the resulting signal is used for the calibration through the use of a test signal, or to evaluate the effect of the DPD. Note that this path is usually perturbed by the TX and RX impairments, which have to be pre and post digitally compensated.

• The second path is used to evaluate the quality (in terms of linearity) of the transmit-ted signal at the antenna. It bears only TX impairments, as the receiver architecture is super-heterodyne. The goal is to have a signal that is a clean copy of the PA output in order to assess the spectral occupancy. Note that this second path is used for per-formance measurements only, not for DPD.

Figure 12: Block diagram of the set up used to demonstrate PoC2

The tests procedure will be as follows:

1) Training sequence emission and recording 2) Calibration parameters computation (Offline processing) 3) Signal Example DPD computation (Offline processing) 4) Signal emission with record at the amplifier output (with super heterodyne receiver

and larger bandwidth) and on the expressMIMO feedback channel 5) Analysis of

a. OOB emission, b. Transmitted signal quality

3.1.7 Outlook and Conclusions The software managing the platform and the experiments has still to be developed, and the remaining key points to be addressed are:

- The synchronization of the TX and RX (Pulse or clock driven). Note that the synchro-nization does not have to be very precise but should be on the order of a few hundred µs.

- The command of the radio chains o ExpressMimo radio chain o X310 radio chain o Superheterodyne radio chain

- Compatibility (wrappers) between data files for TX, algorithmic and RX.

Calibration Path

Dri- ver

Boo

ster

Attenua-tor

superheterodyne Receiver

ADC+DDC

Express MIMO2

10GbEthernet

1) Tx/Rx Calibration signal

2) Compute Calibration parameters

3) DPD usefull signal 4) Tx/Rx distorded

signal 5) Analysis of perfor-

mances

T3dB

Instrumentation

Measure Path�



Finally, OOB performance and power consumption measurements have to be performed, and will be described in deliverable D4.3.



4. PoC 3: LTE inter-band carrier aggregation

4.1 PoC 3a: LTE-A inter-band carrier aggregation in homogeneous networks 4.1.1 Introduction This PoC platform aims at demonstrating the “standard” CA as defined by the standardiza-tion together with some more advanced RRM functions. The PoC platform is made of three parts:

• the OpenAirInterface (provided by Eurecom) for the network equipment side, • a prototype of terminal equipment (provided by Sequans), and • RRM algorithms (provided by ISW)

The architecture of the PoC follows the standard LTE architecture. A high level figure of this architecture is given in Figure 13. It shows the UE (left) the eNB (middle), with a close-up of the MAC, and the EPC (right) components of an LTE network. Each component is clearly attributed to a partner and the interfaces between the relevant components are highlighted.

MAC$(EURECOM)

UE#(Sequans) eNB#(Eurecom)

MAC

RLC

RRC S1.MME

SCTP

X2AP

IP

Ethernet

UDPPDCP

S1.URRC

NAS

MAC

RLC

Linux$IP$stack

PDCP

PHYPHY

Ethernet

IP

SCTP

S1.MME

NAS

MME$Application

S11 S1.U

S+P.GW$Application

GTP.U

EPC#(Eurecom#or#third#party)

eNB$Application$and$RRM

IP$packets AT$commands

UDP

S6a/Diameter

HSS

Linux$stack3GPP$layers Control$PlaneData$Plane

Management$(OSS)

SGi

LTE$Uu$interface

Scheduler(IS.Wireless)

Control

SubframeSCHED$SAP

CSCHED$SAP

MAC$SAPCMAC$SAP

PHY$SAP Figure 13: High level functional architecture of an LTE network specifying the responsibility of each part-ner and the corresponding interfaces.

4.1.2 Requirements from WP2 In the following, we recap the system and component level requirements relevant for this PoC from the deliverables D2.2 [14] and D2.3 [8].

4.1.2.1 System Level Requirements • 2 DL Component Carrier, one in low band (e.g. B13), one in High band (e.g; Band 4) • 1 UL Component Carrier • Colocated base station and overlaid coverage • Modification of the PHY, MAC, RLC and RRC layers to support CA operation



• MAC sublayer shall be responsible for Activation and Deactivation of SCells. RRC sublayer is responsible of configuration/Deconfiguration of CCs

• Separate HARQ processes shall be run for each CC. • CC assignment shall not be fixed for the entire transmission time. Contrarily, periodi-

cal reallocation of CC subsets should be feasible.

4.1.2.2 Component Level Requirements High-level Requirements with respect to Radio Resource Management (RRM):

• An effective method of conveying increased volume of control/feedback information must be found. Each CC requires its own ACK/NACK confirmations as well as CQI and such information cannot be omitted. As a result, PUCCH for Primary CC is over-loaded with additional control data.

• Additional carriers configuration should be completed in 8 ms (8 subframes) - accord-ing to 3GPP. Current implementation requires RRC Reconfiguration procedure in or-der to establish SCC. Perhaps it can be already involved in RRC Connection Setup if it is known a priori supplementary frequency resources would be necessary.

• SCC should be deactivated by “sCellDeactivationTimer-r10” timer expiry. A carefully chosen value must be assigned to this timer in order to avoid excessive signaling due to RRC Reconfiguration messages related to Cell activation and deactivation.

• Frequency measurements need to be collected periodically in order to support the concept of dynamic resource assignment. Such measurements should be sent over X2 interface (between base stations) or with the participation of Core Network (via S1 interface)

• User mobility should be tracked and MAC layer is expected to take such information into account while choosing a relevant scheduling approach. One of the ways to mon-itor mobility is to observe the tendency of RSRP on a certain carrier measured by the UE.

Detailed Requirements with respect to RRM:

• RRM mechanism should be able to ensure load balancing and efficient scheduling across multiple carriers (i.e. PCC + 1-4 SCCs)

• RRM should handle intra-band and inter-band Carrier Aggregation • A central RRM unit (in most cases: located within a eNB) shall take into account vari-

ous input data before making resource assignment decisions. Among the context in-formation which should be evaluated prior to resource allocation are: load on CCs, SNIR values, achievable throughput, QoS requirements, UE capabilities, Core Net-work/operators policies, etc.

• Dynamic RRM approach is highly desirable. A set of Component Carriers should not be fixed and given once per RRC Connection. Conversely, it has to be revised fre-quently and reallocated if necessary.

4.1.3 Selected Algorithms from WP3 Most of the blocks in this PoC are specified by the LTE standard and do not allow much freedom for innovative ideas. The only block of this PoC that allows for innovative new algo-rithms is the MAC scheduler. This block contains the RRM algorithm that was developed in WP3 and is described in D3.2 [10]. The used algorithm is able to work in LTE (licensed) + LTE (licensed) Heterogeneous Deployment. The scheduling algorithm takes into account different components, namely, historical throughput, current channel status, packet delay, packet queue size, QoS requirements (guaranteed bit rate) while assigning resources. Cal-culating priority for different UEs is just a part of scheduling. The final implementation takes



also into account 3GPP restrictions and requirements like specific allocation types, buffer size limits, transport block sizes and retransmissions, which are not described in [10].

4.1.4 Building blocks The three main building blocks of this PoC are the eNB, the eNB scheduler and the UE.

4.1.4.1 eNB: OpenAirInterface The eNB is based on the OAI platform and mainly developed by Eurecom [22]. The exten-sions of OAI developed in SOLDER are twofold. Firstly, OAI has been extended with LTE Rel10. carrier aggregation functionality as defined in Section 4.1.2.1. Secondly, OAI has been extended with the scheduler API that was specified in D4.1 [1]. This work has been carried out in close collaboration with IS-Wireless. During the implementation, some bugs were also corrected in the specification and an updated specification can be found in Appendix A3. Here we briefly describe how the interface was implemented and we show in Table 9 and Table 10 the implementation status of each of the primitives. The MAC-SCHEDULER interface is implemented using function calls in one direction and callbacks in the other. The MAC directly calls the _REQ primitives (see Table 9 and Table 10). The _CNF and _IND primitives are callbacks registered when the MAC instanti-ates the SCHEDULER at startup time. On the MAC side the _CNF and _IND are also functions. They are called to wait for the cor-responding callback to be called by the SCHEDULER. Those functions are called right after the MAC calls the corresponding _REQ function. The only exception is for CSCHED_UE_CONFIG_UPDATE_IND and CSCHED_CELL_CONFIG_UPDATE_IND. Those primitives don’t have a corresponding _REQ primitive. They are not used in the cur-rent implementation. All the synchronization for the MAC side is done in the _CNF and _IND local functions. A mutex and a cond variables are used to wait for the callback to be called by the scheduler. Callbacks copy the data they receive from the SCHEDULER and then wake up the MAC side which takes this data and serves it to the caller of the function. A typical flow of events is as follows. Take for example the downlink scheduling.

1. MAC calls SCHED_DL_TRIGGER_REQ. That triggers the SCHEDULER to start a DL scheduling.

2. MAC calls local function SCHED_DL_CONFIG_IND where it waits for the callback from SCHEDULER.

3. SCHEDULER is done and calls the callback for SCHED_DL_CONFIG_IND, which copies the data and wakes up MAC.

4. MAC is woken up by the callback and returns from local function SCHED_DL_CONFIG_IND, passing the data it received from SCHEDULER.

4.1.4.2 eNB: scheduler Implementation of the LTE eNB Scheduler is divided into two parts. First step of implementa-tion covers FAPI interface and basic scheduling algorithm (Round Robin). Second step is extension of basic scheduling algorithm towards advanced scheduling algorithm designed in WP3. Such approach allows earlier integration with OAI stack using FAPI interface, as the interface implementation in both versions of scheduling algorithm is common code.



Current status of LTE eNB Scheduler implementation: • Phase 1: Basic scheduling algorithm (Round Robin) with FAPI interface

o Downlink – implemented and verified with basic functional tests o Uplink – implemented and verified with basic functional tests

• Phase 2: Advanced scheduling algorithm o Downlink – implemented and verified with basic functional tests o Uplink – framework implemented and additional functions implementation is

ongoing Section 4.1.2.2 of this document describes component level requirements. Algorithm match-es the requirements. In particular it is able to balance load across different component carri-ers either by activating or deactivating these carriers for particular users or by adjusting number of assigned resources on carriers. Moreover scheduler takes into account various input data before making resource assignment decisions, as listed in the component level requirements, namely: load on CCs, SNIR values, achievable throughput, QoS requirements and UE capabilities.

4.1.4.3 UE The UE is developed around a reference board described in section 4.1 of [1]. The platform was tested first from HW standpoint and specific SW was developed to enable carrier aggre-gation support. The first development consisted in providing the support of FDD+FDD aggregation, for band 4 and 13 as expressed by WP2 in the early requirements and scenarios. For that purpose several levels of tests were conducted, at unitary level, system integration level, and eventually on the air. As a continuation, a second development is currently on-going to support aggregation of TDD bands to enrich the capability of the UE. An example of test plan and test results for unit validation of the UE at system level is pro-vided in Appendix A2.

4.1.5 Status of Integration The integration between the nodeB and the UE has reached a level of maturity at the end of 2015, where we were able to demonstrate a call using carrier aggregation between involving the UE and the nodeB. Interoperability type of tests are regularly performed in order to check if any regression was introduced. Regarding the integration of the scheduler into OpenAirInterface using the FAPI interface, at this stage of the project (M30), we have integrated and tested the simple scheduler into the OpenAirInterface system level simulator. Using this tool we can verify the basic operation, for example the successful establishment of a connection between the eNB and the UE. The detailed integration status of the LTE eNB Scheduler with OpenAirInterface is docu-mented in Table 9 and Table 10 in Appendix A1. In this table we list all of the CSCHED and SCHED primitives along with their implementation status on the side of OAI and on the side of the scheduler. In the last column we indicate if this feature has been tested successfully using the oaisim tool. It can be seen that at this stage of the project (M30) there are still a few functions that have not been validated, meaning that there is a slight delay in the project. Moreover, the current tests do not yet test the real-time behavior of the code. However, we are confident that we will catch up with the development and start the first real-time tests during the 10 quarter of the project (M30-M33).



4.1.6 Unit test and results 4.1.6.1 Carrier Aggregation

The OAI carrier aggregation features have been tested together with the Sequans UE. The test setup is depicted in Figure 14 and the basic parameters of the setup are given in Table 4. The test consisted of the following steps

1. Startup of EPC and eNB. Only one primary carrier is activated at this time. 2. Startup of UE. The successful connection procedure can be observed. 3. Launch of a speedtest on the eNB. The DL throughput is about 10Mbps. 4. Activate the second DL component carrier at the eNB. 5. Launch of another speedtest on the eNB. The DL throughput now is about 22Mbps,

which is even more than double. These tests show that the requirements defined in Section 4.1.2.1 have been met. A first demonstration of these new functionalities has been given at the second year review meeting. They are also documented in this short video: https://youtu.be/xoDMZ5Vy1Ew.

Internet

EPC(3rd)party)

S11

S+P2GW

SGi

eNB(OpenAirInterface)

S12U

HSS MME

S12C

UE(Sequans)

Figure 14: Carrier Aggregation test setup

Table 4: Parameters for the Carrier Aggregation unit test

Parameter Value

Carrier aggregation configuration Inter'band,!band!4+13!(CA_4A_13A)

Bandwidth configuration 2 x 5MHz

Transmission mode 1 (SISO)

RF setup Cabled with variable attenuator

4.1.6.2 Scheduler API The scheduler API has been tested using the oaisim tool of OpenAirInterface [22]. This tool allows to simulate a full LTE network comprising one eNB and one or several UEs. The test consists mainly of analyzing the logs, checking if the connection procedure passes as ex-pected and launching some traffic between eNB and UE. As already discussed in Section 2.2.5, at this stage of the project (M30) we have validated approximately half of the connec-tion procedure. The remaining tests will be completed in Q10 (M31-M33) of the project.



4.1.7 Conclusions and Outlook We have described the current status of the implementation and integration of PoC 3a deal-ing with LTE-A inter-band carrier aggregation. The unitary tests of the building blocks have all been completed successfully and the integration is already very advanced. A few steps still have to be validated before the main trials can start. In the trials that will be carried out between M31 and M36, we will finalize the lasts tests and carry out over-the-air tests with at least two UEs. We will test the automatic activation and de/activation of the second component carrier in the case that one UE requests a high DL traffic. Further we will test the load-balancing algorithm by putting the two users in different propagation conditions and request a high DL traffic. This will test the load-balancing capabil-ities of the scheduler.

4.2 PoC 3b: Dynamic Cognitive CA in HetNets: LTE-A and beyond 4.2.1 Introduction The PoC3b demonstrates the dynamic CA (DyCA) mechanism that was described in D3.2 [10]. A low-complexity and low-feedback rate channel allocation was proposed that could specify the CCs to be aggregated for a particular UE in a dynamic and efficient way. The DyCA is implemented using the stable matching (SM) algorithm, which is coordinated by the coordinator, i.e., the macro cell in our HetNet deployment. The development of the coordi-nated functionality is described below and how it is integrated to our testbed platform.

4.2.2 Requirements from WP2 Requirements for the PoC3b are described as follows:

• The DyCA scenario requires carriers from LTE band 7 and LTE band 20. More specif-ically, 2 carriers were aggregated where each one had a bandwidth of 10 MHz and a total of 20 MHz was achieved.

• The feedback measurement reports of the LTE-A system are required to implement the DyCA. PHY LTE layer implementation is used to this end.

• The switching functionality is required to select the corresponding CCs. Through the right switching the signals after the amplification and filtering should be driven to the combiners in order to be aggregated and ready to be sent to the antennas for trans-mission.

By using the SM algorithm the best CC of each band was selected in order to be used in the CA scenarios. The aforementioned algorithm sends feedback to the LMS6002D or AD9631 transceivers regarding the centre frequency of the selected CC. This feedback is used from the transceivers in order to achieve the desirable up conversion of the carrier and is dynami-cally updated every time a new CC is selected.



Figure 15: Spectrum Bands required for the PoC3b

4.2.3 Selected Algorithms from WP3 The PoC3b relies on the low complexity feedback report calculations and the low feedback rate channel allocation scheme presented in the D3.2 in details. In particular, the following two algorithms are chosen from WP3 for the PoC3b:

• Low complexity PMI/RI calculation enhancing the computation complexity for multiple CCs.

• Low-feedback rate stable matching channel assignment/allocation to multiple users for CA in HetNets.

4.2.4 Building blocks

4.2.4.1 Low Complexity PMI/RI Calculation In Figure 16, we provide a flow chart of the implemented Low Complexity PMI/RI algorithm. Initially we aggregate the subcarriers’ channel covariance matrices that constitute a sub-band into matrix R. Then we apply Singular Value Decomposition (SVD) on matrix R, to get the matrix S that holds the eigenvalues of R and eventually find the RI by counting the values is S that are greater than a threshold SNR in dB. Then if RI is one or zero we repeat the fol-lowing step for Codebook Index CbIdx = 1, 2, 3. Firstly we get the precoding matrix W1(CbIdx), for one transmission stream defined in [26], and calculate the norm of the differ-ence between W1*W1T and the V1:RI * VT1:RI, where matrix V1:RI holds the eigenvectors of R that correspond to non-zero eigenvalues. If the norm is below a threshold we update the optimum CbIdx (CbIdxopt) and the threshold. On the other hand, if R2 is two we follow the same steps but instead of getting the precoding matrix W1 we get the precoding matrix W2, which corresponds to two transmission streams and is defined in [20] as well.



START

%%%%%%%sn%!%10(+SNR/10)

dist%!%inf

R%!%[0%0]

m%!%0

n%!%1

m%<=%SBsize+1

R%!%%R%+%H(SCn+m)T%*%H(SCn+m)

m++

Yes

R%!%R/SBsize

[U%S%V]%!%SVD(R)

RI%!%sum(S>10*sn)

No

RI%=%0 RI%!1Yes

RI%=%2

No

W%!W1(CbIdx)

temp%!0.5*norm(W*WT%–%V1:RI*V

T

1:RI)

temp%<%distdist%!%temp

CbIdxopt%!%CbIdxYes

CbIdx++

No

CbIdx<=3

Yes

W%!W2(CbIdx)

temp%!0.5*norm(W*WT%–%V1:RI*V

T

1:RI)

temp%<%distdist%!%temp

CbIdxopt%!%CbIdx

CbIdx++

CbIdx<=4

Yes

No

Yes

No

No

CbIdx%!1

No

Yes

n+=SBsize

n<=NC

Yes

ENDNo

Figure 16: Low Complexity PMI/RI Calculation functionality

4.2.4.2 Low Complexity and Low-Feedback-Rate Channel Allocation

In Figure 17, we provide a flow chart presenting a low complexity algorithm, distributed be-tween a UE, a Coordinator Base Station (BS) and a Small Cell BS, that achieves the target-ed system throughput while computing the minimum feedback 2. Beginning from UE ! side, the algorithm calculates the throughput for each available CC n and M-best feedback report strategy and we pick CC n* with the maximum throughput. If UE ! cannot achieve the target throughput, it sends a request for that CC to either the Coordinator BS or the Macro Cell BS. The Coordinator BS receives the request and assigns CC n* to UE !, either if CC n* is not assigned to another UE !!or the throughput of ! is greater than the one of !!. Now if CC n* belongs to the Coordinator BS UE ! is scheduled on n* . On the other hand, if the throughput of UE !! is greater than the one of UE ! and CC n* belongs to the Coordinator BS a nega-tive reply about the availability of CC n* is sent to UE !. In case Coordinator doesn’t possess CC n* a reply message with the decision about the availability of CC n* is sent to the Small Cell. The Small Cell BS in the sequel forwards the request, it receives to the Coordinator BS

2 Due to platform limitations, we constrain the integration of the channel allocation within one macro BS and one smaller BS that are actually considered in the same HW platform. One UE is able to aggregate the channels allo-cated from the decision made by the two BSs.



and waits its reply. If the reply is positive it schedules UE ! on CC n* and if the reply is nega-tive it sends a negative reply about the availability of CC n* to UE !.

Figure 17: Coordinated CA through Stable Matching algorithm

4.2.5 Status of Integration Regarding the channel allocation scheme, the implementation is distributed to the considered DyCA across the HetNet with the macro and the smaller cells. In particular, the functionality is split into the UE and each of the cellular nodes. Thus, User Equipment:

• The UE receives the training sequence form all available CCs belonging to different Base Stations, calculates the achievable data rate in the SNR estimation module and generates the relative feedback in the Feedback calculation module for each possible M value.



• Given the UE’s target rate, the M Selection module determines M for each CC as well as the resulted achievable throughput per CC.

• The CC selection module picks the UE’s best CC in terms of throughput, if the target rate has not been achieved, and sends a request to the BS that controls this CC con-taining the index of the CC as well as the achievable data rate.

Coordinator:

• The Coordinator receives CC requests either from UEs or from the Small cell through the X2 interface3.

• The CC Allocation module determines if the requested CC is to be assigned to the requesting UE.

• If the requested CC belongs to the coordinator and is assigned to the requesting UE, the coordinator schedules the UE on the requested CC.

• If the requested CC does not belong to the coordinator, a reply message containing the CC Allocation decision is forwarded to the Small cell via the X2 interface.

Small cell:

• The small cell receives requests from UEs and forwards them to the coordinator through the X2 interface to determine allocation.

• Upon reception of the coordinator’s reply, if the CC allocation decision is positive, the small cell BS schedules the UE on the requested CC.

Figure 18: The UE functionality assuming 3 bands available for CC selection based on the M-best feed-back report strategy.

3 X2 interface communication is an assumption, since that features is not implemented in our platform.



Figure 19: Integration of the individual blocks for the PoC3b

4.2.6 Unit test and results Low complexity PMI/RI calculation runtime measurements were made on the baseband LTE reference design (i.e. using our SW LTE PHY layer design) for different sub-band sizes. The sub-bands are formed in groups of physical resource blocks (PRBs) and the results are pro-vided in the Table 5. What is evident from the Table 5 below is that the complexity of feed-back calculation decreases with the increase of the sub-band (SB). Furthermore, comparing the low complexity PMI/RI calculation algorithm found in the D3.2 [10] with the standard PMI/RI calculation method developed in the standard LTE design [20], we conclude that for the wideband case of 100 PRBs per SB the PMI/RI calculation runtime is 1136 ms, which is approximately 9 times higher than the proposed low complexity technique.

Table 5: Feedback calculation runtime

Sub-Band size (PRBs) PMI/RI Calculation runtime (ms) 1 501

25 192 50 181

100 179

Next we demonstrate the performance of the low complexity and low feedback rate channel allocation for one UE with target rate of 500 Mbps and 3 available 20 MHz CCs. We test the channel allocation results for 3 different SNR cases, as the channel conditions clearly affect



the number of CCs the UE requires in order to achieve its target rate. The results are pre-sented in Table 6.

Table 6: Feedback calculation and channel allocation for different SNR values

10 dB SNR 20 dB SNR 30 dB SNR CC index Sub-band

size (PRBs) CC index Sub-band


size (PRBs) 0 1 0 1 0 100 1 1 1 1 1 100 2 1 2 1 - -

We can conclude that for the low and medium SNR cases (10, 20 dB) 3 out of 4 CCs were required and the feedback granularity selected was per PRB to combat channel conditions with more detailed feedback information. On the other hand, with high SNR (30 dB) the UE not only requires only 2 CCs to achieve the data rate constraint, but also repots wideband feedback to reduce communication overhead. Table 3 demonstrates the effect of target rate on the channel allocation decisions for a medium SNR (20 dB).

Table 7: Feedback calculation and channel allocation for different target rates

Target rate = 500 Mbps Target rate = 250 Mbps Target rate = 100 Mbps CC index Sub-band



size (PRBs) 0 1 0 100 0 100 1 1 1 100 - - 2 1 - - - -

We observe that as the UE target rate decreases, it requires less CCs with wider sub-band size resulting in lower feedback overhead. Finally we compare the Stable Matching (SM) channel assignment employed in low complexity channel allocation to a Random Matching (RM) approach, where the UE randomly both requests a CC and selects its sub-band size until a target rate of 680 Mbps is achieved. The UE experiences 4 different SNR levels in the available CCs: 10, 20, 30 and 40 dB for CC0, CC1, CC2 and CC3 respectively. The results are displayed in Table 8.

Table 8: Feedback calculation and channel allocation for SM vs RM

Stable Matching Random Matching CC index Sub-band size

(PRBs) CC index Sub-band size

(PRBs) 3 100 0 50 2 100 2 50 1 100 1 100

Although in both SM and RM 3 CCs were requested by the UE, the selected sub-band sizes result in larger feedback in RM case due to the random fashion by which the sub-band size is selected.



4.2.7 Outlook and Conclusions Within the timeline of D4.2, we developed, integrated and tested two algorithms provided in the D3.2 [10], namely the low complexity and low feedback rate channel allocation in the HetNet application scenario presented in WP2. The fact is that limitations were observed due to our testbed platform, e.g. we cannot provide a use case with multiple users and channels as we did for the original investigation within the WP3 carried out using an open source simu-lator. However, we tested a use case where 3 CCs and one UE showing indicative results about the performance of the proposed algorithms in terms of feedback report calculation and CC selection. Next step (within the D4.3) is to test and demonstrate the solution using our testbed SW/HW platform by integrating the SW design to the Xilinx FPGA platforms driv-ing the RF boards for the CC selection.

5. Conclusions

This report provided an update of the development of the building blocks of SOLDER demonstration. On the different platforms that were defined to represent a large set of CA scenarios, the progress are significant, already providing interesting experimental results. However, the coming period will be devoted to pursue the integration between the building blocks, in order to further validate at system level the concept developed in SOLDER and under prototyping in WP4. The deliverable D4.3 will report the outcome of this final integra-tion phase.



References

[1] SOLDER D4.1, “PoC Scenarios and system interfaces”, http://ict-solder.eu. [2] O. Holland, et al., “To White Space Or Not To White Space: That Is the Trial Within the

Ofcom TV White Spaces Pilot,” IEEE DySPAN 2015, Stockholm, Sweden, Sept.-Oct. 2015.

[3] ETSI, “White Space Devices (WSD); Wireless Access Systems operating in the 470 MHz to 790 MHz frequency band; Harmonized EN covering the essential requirements of article 3.2 of the R&TTE Directive,” v1.1.1, April 2014.

[4] Peerless-AV Pico-Broadcasting, http://www.peerless-av.com/en-us/professional/pico-av-broadcaster, accessed April 2016.

[5] Ofcom, “Implementing TV White Spaces,” statement, February 2015, accessible at http://stakeholders.ofcom.org.uk/consultations/white-space-coexistence/statement, ac-cessed May 2015.

[6] Netflix, “Internet Connection Speed Recommendations”, accessible at https://help.netflix.com/en/node/306, accessed March 2015.

[7] N.-D. Nguyen, R. Knopp, N. Nikaein, C. Bonnet, “Implementation and Validation of Mul-timedia Broadcast Multicast Service for LTE/LTE-Advanced in OpenAirInterface Plat-form,” IEEE LCN 2013 Workshops, Sydney, Australia, Oct. 2013.

[8] SOLDER D2.3 “System-level requirements for scenarios and use cases”, http://ict-solder.eu.

[9] SOLDER D3.1, “Initial report of Heterogeneous Carrier aggregation in LTE-A and be-yond”, http://ict-solder.eu.

[10] SOLDER D3.2, “Innovative solution for Carrier aggregation in h-RATs, LTE-A and be-yond”, http://ict-solder.eu.

[11] 3GPP TR 36.889 TSG RAN, “Study on Licensed-Assisted Access to Unlicensed Spec-trum”, Rel.13, v13.0.0, July 2015.

[12] SOLDER D2.1 “Application scenarios and use cases”, http://ict-solder.eu/. [13] O. Holland et al., “Development of a radio enabler for reconfiguration management with-

in the IEEE P1900.4 working group,” IEEE DySPAN 2007, Dublin, Ireland, April 2007. [14] SOLDER D2.2 “Component-level requirements for scenarios and use cases”, http://ict-

solder.eu/. [15] Lime Microsystem, http://www.limemicro.com/products/field-programmable-rf-ics-

lms6002d/Analog Devices, http://www.analog.com/en/design-center/landing-pages/001/ad9361-ad9364-integ-rf-agile-transceiver-design-res.html.

[16] Analog Devices, http://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/eval-ad-fmcomms5-ebz.html#eb-overview. Linear Technology, http://www.linear.com/product/LT5538.

[17] Linear Technology, http://www.linear.com/product/LTC5533. [18] 3GPP RP-142286, New WI proposal: LTE Carrier Aggregation Enhancement Beyond 5

Carriers, Rel.13, Dec. 2014. [19] SOLDER D3.3, “Final report, Carrier aggregation in h-RATs: PHY, and system results”,

http://ict-solder.eu. [20] Houman Zarrinkoub, “Understanding LTE with MATLAB: From Mathematical Modeling

to Simulation and Prototyping”, http://eu.wiley.com/WileyCDA/WileyTitle/productCd-1118443411.html.

[21] 3GPP (2011) Evolved Universal Terrestrial Radio Access (E-UTRA), Physical Channels and Modulation, Version 10.0.0 TS 36.211, Jan. 2011.

[22] OpenAirInterface, http://www.openairinterface.org, accessed March 2015. [23] Femto Forum, “LTE MAC Scheduler Interface Specification”, FF_Tech_001_v1.11, 12-

10-2010.



List of Acronyms and Abbreviations

Acronym/Abbreviation Meaning 3GPP 3rd Generation Partnership Project 4G 4th Generation 5G 5th Generation ABS Almost Blank Subframes ADC Analog to Digital Conversion AP Access Point BER Bit Error Rate BS Base Station BSC Base Station Controller CA Carrier Aggregation CC Component Carrier CIF Carrier Indicator Field CoMP Coordinated MultiPoint CPC Cognitive Pilot Channel CQI Channel Quality Indicator CR Cognitive Radio CRS Cell-specific Reference Signal CSI Channel State Information D2D Device-to-Device DAC Digital to Analog Converter DDC Digital Down Conversion DFT Discrete Fourier Transform DL Downlink DPD Digital PreDistortion DRS Demodulation Reference Signal DSM Dynamic Spectrum Management DSS Dynamic Spectrum Sharing DTT Digital Terrestrial Television DUT Device Under Test EAP-SIM Extensible Authentication Protocol Subscriber Identity Module eICIC Evolved Intercell Interference Coordination EIRP Equivalent Isotropic Radiated Power EPC Evolved Packet Core eNB evolved NodeB eMBMS evolved MBMS E-UTRA Evolved UMTS Terrestrial Radio Access EVM Error Vector Magnitude FAPI FemtoForum Application Programming Interface FBMC Filter Bank Multi-Carrier FCC Federal Communications Commission FDD Frequency-Division Duplex FMC FPGA Mezzanine Card FFT Fast Fourier Transform FPGA Field Programmable Gate Array GFDM Generalized Frequency-Division Multiplexing HARQ Hybrid Automatic Repeat Request HetNet Heterogeneous Network



h-RAT heterogeneous RAT HSPA High Speed Packet Access IFFT Inverse FFT ILW Integrated LTE and WiFi IP Internet Protocol ISM Industrial Scientific and Medical LA Link Adaptation LAA Licensed-Assisted Access LPN Low Power Node LQM Link Quality Metrics LTE Long Term Evolution LTE-A Long Term Evolution Advanced LTE-U LTE in Unlicensed spectrum MAC Medium Access Control MAI Multiple Access Interference MBB Mobile BroadBand MBMS Multimedia Broadcast/Multicast Service MFCN Mobile/Fixed Communications Networks MIH Media-Independent Handover MIHF Media-Independent Handover Function MIMO Multiple-Input Multiple-Output MSS Mobile Satellite Services MT Mobile Terminal MU Multi-User NAS Non-Access Stratum NC Non-Contiguous NC-OFDM Non-Contiguous Orthogonal Frequency-Division Multiplexing NE Network Element OAI OpenAirInterface OFDM Orthogonal Frequency-Division multiplexing OFDMA Orthogonal Frequency-Division Multiple Access OOB Out Of Band OSI Open-Systems Interconnection PA Power Amplifier PAPR Peak-to-Average Power Ratio PCC Primary Component Carrier PCell Primary Cell PDCCH Physical Downlink Control Channel PDSCH Physical Downlink Shared Channel PHY Physical Layer PMI Precoding Matrix Indicator PMSE Programme Making and Special Events PoC Proof of Concept PRB Physical Resource Block PU Primary User PUCCH Physical Uplink Control Channel PUSCH Physical Uplink Shared Channel QoE Quality of Experience QoS Quality of Service RAN Radio Access Network RAT Radio Access Technology RF Radio-Frequency



RFFE RadioFrequency Front-End RI Rank Indicator RM Random Matching RRC Radio-Resource Control RRH Remote Radio Head RRM Radio-Resource Management RSRP Reference Signal Received Power SAP Service Access Point SAW Surface Acoustic Wave SCC Secondary Component Carrier SCell Secondary Cell SC-FDMA Single-Carrier FDMA SDR Software Defined Radio SFP Small Form-factor Pluggable SINR Signal-to-Interference- Plus-Noise Ratio SM Stable Matching SME Spectrum Management Entity SOTA State-Of-The-Art SRS Sounding Reference Signal SU Secondary User SS Spectrum Selection TA Timing Advance TAIC Terminal Aggregation Information Controller TDD Time-Division Duplex TDM Time-Division Multiplexing TPC Transmit Power Control TVWS TV White Space UCI User Control Information UE User Equipment UFMC Universal Filtered Multi-Carrier UL Uplink U-NII Unlicensed National Information Infrastructure WiMAX Worldwide Interoperability for Microwave Access WLAN Wireless Local-Area Network WWAN Wireless Wide-Area Network



Appendix

A1. Scheduler API Integration status Table 9: CSCHED primitives list Primitive name Refer-

ence Description Notes Implemented

OAI Implemented Scheduler

Tested in oaisim

CSCHED_CELL_CONFIG_REQ 4.1.1 (re-)configure MAC scheduler with cell config-uration and scheduler configuration. The cell configuration will also setup the BCH, BCCH, PCCH and CCCH LC configuration.

Called once at startup to configure a cell.

yes Yes yes

CSCHED_CELL_CONFIG_CNF 4.1.2 Cell configuration and scheduler configuration applied

Called after CSCHED_CELL_CONFIG_REQ to wait for completion.

Yes Yes yes

CSCHED_UE_CONFIG_REQ 4.1.3 (re-)configure MAC scheduler with UE specific parameters. A UE can only be configured when a cell configuration has been received.

Called when a new UE is added to the MAC layer (in the function add_new_ue).

Yes Yes Yes, but still needs to be called to process UE capabil-ities.

CSCHED_UE_CONFIG_CNF 4.1.4 UE specific configuration applied

Called after CSCHED_UE_CONFIG_REQ to wait for completion.

Yes Yes Yes

CSCHED_LC_CONFIG_REQ 4.1.5 (re-)configure MAC scheduler with logical channel configuration. A logical channel can only be configured when a UE configuration has been received.

Called to configure SRB1 and SRB2 for a new UE. Called when the RRC layer receives RRCConnection-Request.

Yes Yes Yes

CSCHED_LC_CONFIG_CNF 4.1.6 Logical channel configura-tion applied

Called after CSCHED_LC_CONFIG_RE

Yes Yes Yes



Q to wait for completion. CSCHED_LC_RELEASE_REQ 4.1.7 release a logical channel

in the MAC scheduler. A logical channel can only be released if it has been configured previously.

Not planned to be imple-mented in the scheduler.

Not yet. Yes

CSCHED_LC_RELEASE_CNF 4.1.8 Logical Channel specific configuration removed


Not yet. Yes

CSCHED_UE_RELEASE_REQ 4.1.9 release a UE in the MAC scheduler. The release of the UE configuration im-plies the release of LCs, which are still active. A UE can only be released if it has been configured previously.

Not yet. Yes To be done

CSCHED_UE_RELEASE_CNF 4.1.10 UE specific configuration removed


CSCHED_UE_CONFIG_UPDATE_IND

4.1.11 update of UE specific parameters from MAC scheduler to RRC


No No

CSCHED_CELL_CONFIG_UPDATE_IND

4.1.12 update of ctrl channel configuration


No No

Table 10: SCHED primitives list Primitive name Refer-

ence Description Notes Implement-

ed OAI Implemented Scheduler

Tested

SCHED_DL_RLC_BUFFER_REQ 4.2.1 update buffer status of logical channel data in RLC. The update rate with which the buffer status is updated in the scheduler is outside of the scope of the document.

Called to update buffer status of CCCH, DCCH (SRB1 and SRB2) and DTCH. Only “logicalChan-nelIdentity” and “rlcTrans-missionQueueSize” are set for the moment. Called by eNB_dlsch_ulsch_scheduler at each TTI.

Yes Yes Yes

SCHED_DL_PAGING_BUFFER_R 4.2.2 update buffer status of Not used. No Yes



EQ paging messages. SCHED_DL_MAC_BUFFER_REQ 4.2.3 update buffer status of

MAC control elements. The update rate with which the buffer status is updated in the scheduler is outside of the scope of the document.

Called to schedule Conten-tion Resolution. Called right after add_new_ue.

Yes Yes Yes

SCHED_DL_TRIGGER_REQ 4.2.4 Starts the DL MAC scheduler for this sub-frame

Yes, required a rewrite of the function eNB_dlsch_ulsch_scheduler.

Yes Yes

SCHED_DL_RACH_INFO_REQ 4.2.5 Provides RACH reception information to the sched-uler

Yes, required a rewrite of the function initi-ate_ra_proc.

Yes Yes

SCHED_DL_CQI_INFO_REQ 4.2.6 Provides CQI measure-ment report information to the scheduler

Not yet Yes To be done

SCHED_DL_CONFIG_IND 4.2.5 triggers building of DL MAC PDUs and Subframe Configuration in MAC

Called after SCHED_DL_TRIGGER_REQ to wait for completion.

Yes Yes Yes

SCHED_UL_TRIGGER_REQ 4.2.8 Starts the UL MAC scheduler for this sub-frame

Not yet. Yes Yes

SCHED_UL_NOISE_INTERFERENCE_REQ

4.2.9 Provides Noise and inter-ference measurement information to the sched-uler

Not used. No Primitive sup-ported, but data not utilized

No

SCHED_UL_SR_INFO_REQ 4.2.10 Provides scheduling re-quest reception infor-mation to the scheduler

Yes, required a rewrite of the function SR_indication.

Yes Yes

SCHED_UL_MAC_CTRL_INFO_REQ

4.2.11 Provides mac control information (power head-room, ul buffer status) to

Not yet. Yes Yes



the scheduler SCHED_UL_CQI_INFO_REQ 4.2.12 Provides UL CQI meas-

urement information to the scheduler


SCHED_UL_CONFIG_IND 4.2.9 passes the UL scheduling decision (Format 0 DCIs) to MAC

Not yet. Yes Yes



A2. Example of test plan and test result for UE system integration Carrier aggregation requires at minima the following basic Release 10 features to be availa-ble:

• Secondary Cell addition/release • Secondary Cell activation/deactivation • Rel 10 HARQ feedback

A2.1 Test Environment 2 carriers must be emulated in the test lab. As a result, the lab setup must include test equipment able to mimic such scenario as for instance a CMW500 with two cells.

A2.2 Secondary Cell addition / release Add/release Secondary cell action is performed by mean of RRC connection reconfiguration message, refer to 5.3.10.3a/b in [36.331]. Specific release 10 section describes dedicated Scell physical configuration for the secondary cell to add/modify.

Figure 20: 20 ASN section for dedicated SCell configuration

The procedure for the test of Scell addition is the following:

1. Perform attach procedure on primary cell 2. Wait for attach complete 3. Transmit Re-configuration message to add Scell 4. Wait for Reconfiguration complete message



Figure 21: Add SCell configuration procedure

Pass/Fail criteria:

• Check L1 detects Secondary cell as configured by RRC • Check secondary cell is on track • Check RSRP/CINR levels measured by Secondary cell • Check Reconfiguration complete transmit by UE

Test results

Test Case Primary Cell RSRP (dBm) Secondary Cell RSRP (dBm) Result Add-Sc-1 -70 -70 Pass Add-Sc-2 -70 -90 Pass Add-Sc-3 -70 -110 Pass Add-Sc-4 -90 -70 Pass Add-Sc-5 -90 -90 Pass Add-Sc-6 -90 -110 Pass Add-Sc-7 -110 -70 Pass Add-Sc-8 -110 -90 Pass Add-Sc-9 -110 -110 Pass

The procedure for the Scell release is the following:

1. Perform attach procedure on primary cell 2. Wait for attach complete 3. Transmit Re-configuration message to add Scell 4. Wait for Reconfiguration complete message 5. Transmit Re-configuration message to release Scell 6. Wait for Reconfiguration complete message

UE E nB

R R C 'R econfiguration'DC C H/DL 6S C H/PDS C H

Add'S cell

R R C 'R econfiguration'complete'DC C H/UL 6S C H/PUS C H



Figure 22: Release SCell configuration procedure

A2.3 Secondary cell activation/deactivation The network activates and deactivates a configured SCell(s) by sending the Activa-tion/Deactivation MAC control element. The Activation/Deactivation MAC control element is identified by a MAC PDU subheader with LCID equals to 11011 as defined in [36.321]. On reception of an Activation/Deactivation MAC control element activating the SCell, the UE shall in the timing defined in [3]:

• Activate the SCell; i.e. apply normal SCell operation • Report CQI/PMI/RI/PTI for the Scel • Monitor PDCCH for the Scell • Start or restart the sCellDeactivationTimer associated with the Scell;

On reception of an Activation/Deactivation MAC control element deactivating the Scell or on expiration of sCellDeactivationTimer, the UE shall in the timing defined in [36.213]:

• Deactivate the Scell • Flush all HARQ buffers associated with the SCell • Stop sending CQI/PMI/RI/PTI reports for the Scell • Stop monitoring PDCCH for the Scell

Test procedure:

1. Perform attach procedure on primary cell 2. Wait for attach complete 3. Transmit Re-configuration message to add Scell 4. Wait for Reconfiguration complete message 5. Activation MAC message send to UE 6. Start UDP DL Traffic on Scell or on both (Scell+Pcell) 7. Deactivation message send to UE

UE E nB


R elease'S cell

R R C 'R econfiguration'complete'DC C H/UL 6S C H/PUS C H



Figure 23: Activation / deactivation of SCell procedure

Pass/Fail criteria:

• Check PDCCH received on secondary scell 8 SF after activation of Scell • Check PDSCH received on secondary scell 8 SF after activation of Scell • Check Scell stops monitoring PDCCH 8 SF after deactivation of Scell • Check Scell stops decoding PDSCH 8 SF after deactivation of Scell

A2.4 Rel 10 – HARQ Feedback In order to provide HARQ feedback (ACK/NACK) for simultaneous PDSCH transmissions, new ACK/NACK PUCCH formats are defined in Release 10 in support of carrier aggregation:

• PUCCH format 3 support large ACK/NACK payloads up to 48 coded bits. • PUCCH format 1b with PUCCH ‘channel selection’, where ACK/NACK information to

be conveyed is indicated by selecting one correct PUCCH resources. Test procedure:

• Start Pcell and Scell at -80 dBm RSRP • Perform attach procedure on primary cell • Wait for attach complete • Transmit Re-configuration message to add Scell • Wait for Reconfiguration complete message • Activation MAC message send to UE • Start Max UDP DLonly Traffic on both (Scell+Pcell) To test PUCCH HARQ feedback

UE E nB


Add'S cell

R R C 'R econfiguration'complete'DC C H/UL 6S C H/PUS C H'

S cell'ActivationMAC 'PDU'subheader''LC ID '='11011R R C '

S tart'UDP 'DL'Tput

'

S cell'DeactivationMAC 'PDU'subheader''LC ID '='11011R R C '



• Lower RSRP Scell level by 5 dBm • Scell Back to -80 dBm RSRP • Lower RSRP Pcell level by 5 dBm • Pcell Back to -80 dBm RSRP • Start UDP UL in addition of UDP DL • Perform again stages 8 to 11

Pass/Fail criteria:

• Check PUCCH feedback during UDP DL only o Check CRC OK triggers new Transmission on corresponding HARQ process o Check CRC KO triggers Re-Transmission on corresponding HARQ process

• Check PUSCH feedback during UDP UL+DL o Check CRC OK triggers new Transmission on corresponding HARQ process o Check CRC KO triggers Re-Transmission on corresponding HARQ process



A3. Updated Scheduler API specifications The following pages contain an updated version of the MAC scheduler API specification from [1], which itself is based on the original specification in [23]. Due to the numerous changes, it has been decided to provide a complete updated description. This description has been gen-erated automatically from the header files that implement this interface. The header files are also available in the branch feature-31-ff-scheduler-api of OpenAirInterface [22].

Documents

D4.2 - Building blocks development - IS-Wireless · Figure 5 Spectrum bands configuration for the LAA application scenario, i.e. licensed LTE Band 7 and unlicensed band at 5GHz