ICT - Information and Communication Technologies · General for Communications Networks, Content &...

ICT - Information and Communication Technologies

Project Acronym: FLEX-LSA

Project Full Title: FIRE LTE testbeds for open experimentation

Grant Agreement: 612050

Project Duration: 12 months (April 2016 – March 2017)

D5.45 - Final experiment results and validation of LSA protocols

Deliverable Status: Final

File Name: D5.45

Due Date: 31 March 2017 (M12)

Submission Date: 31 March 2017 (M12)

Dissemination Level: Public

Task Leader: RED TECHNOLOGIES

Author: Pierre-Jean Muller (RED Technologies), Paul Lerebourg (RED Technologies) Luis Pereira (Allbesmart Lda), Fernando Silva (Allbesmart Lda), Tiago Alves (Allbesmart Lda)

FLEX FP7 Project Grant Agreement 612050

Title February 2016

7th Framework Programme Collaborative project

FP7-ICT-2013-10 Thematic area Future Internet Research Experimentation

of 24

Copyright

© Copyright 2014-2015 The FLEX Consortium

Consisting of:

Organisation Name Short Name Country

University of Thessaly UTH Greece

iMinds iMinds Belgium

SiRRAN SiRRAN United Kingdom

EURECOM EURECOM France

ip.access Limited ip.access United Kingdom

COSMOTE KINITES TILEPIKOINONIES AE. COSMOTE Greece

Rutgers University RUTGERS USA

National ICT Australia Limited NICTA Australia

University of Malaga UMA Spain

Fraunhofer FOKUS FOKUS Germany

TECHNISCHE UNIVERSITAET BERLIN TUB Germany

University of Nis UNIS Serbia

Intracom S.A. Telecom Solutions INTRACOM Greece

Fundació i2CAT Internet i Innovació Digital a Catalunya I2CAT Spain

Université Pierre and Marie Curie UPMC France

Ubiwhere UBIWHERE Portugal

Simula Research Laboratory AS SIMULA Norway

CELERWAY Communication AS CELERWAY Norway

University of Piraeus Research Center UPRC Greece

Feron Technologies FERON Greece

INTRASOFT International SA INTRASOFT Luxemburg

The University of Edinburgh UEDIN United Kingdom

National Center for scientific research "DEMOKRITOS" DEMO Greece

Software Radio Systems LIMITED SRS Ireland

ORION Innovations ORION Greece

Universitaet Bern UBERN Switzerland

Red Technologies RED France

ALLBESMART LDA ALLBESMART Portugal

TELEVIC RAIL NV TELEVIC Belgium

Disclaimer

All intellectual property rights are owned by the FLEX consortium members and are protected by the applicable laws. Except where otherwise

specified, all document contents are: “© FLEX Project - All rights reserved”. Reproduction is not authorised without prior written agreement.

All FLEX consortium members have agreed to full publication of this document. The commercial use of any information contained in this

document may require a license from the owner of that information.

All FLEX consortium members are also committed to publish accurate and up to date information and take the greatest care to do so. However,

the FLEX consortium members cannot accept liability for any inaccuracies or omissions nor do they accept liability for any direct, indirect,

special, consequential or other losses or damages of any kind arising out of the use of this information.


Title February 2016



of 24

History

Version Author Date Status

1.0 Pierre-Jean Muller 31/03/2017 Final


Title February 2016



of 24

Executive summary

The present document is a deliverable of the FLEX project, funded by the European Commission’s Directorate General for Communications Networks, Content & Technology (DG CONNECT), under its 7th EU Framework Programme for Research and Technological Development (FP7).

This is the third deliverable of the FLEX-LSA experiment (FLEX for experimentation and standardization of Licensed Shared Access in LTE networks) funded under FLEX Open Call 2.

This document describes the FLEX-LSA experiment results using LTE equipment from two FLEX’s testbeds: EURECOM and NITOS. The main objective of this experiment is to validate the latest ETSI specifications of the Licensed Shared Access (LSA) protocol and associated interfaces for different configuration scenarios.


Title February 2016



of 24

Table of Contents

INTRODUCTION ................................................................................................................................................ 8

1. SOFTWARE MODULES ............................................................................................................................. 9 1.1 THE LSA PLATFORM ........................................................................................................................................... 9

1.1.1 LSA Repository .................................................................................................................................................. 9 1.1.2 LSA Controller .................................................................................................................................................10 1.1.3 LSA-1 interface ...............................................................................................................................................11 1.1.4 Radio Environment Maps ..........................................................................................................................11

1.2 LSA-OAI PROXY ................................................................................................................................................ 12 1.2.1 eNB Handler .....................................................................................................................................................13 1.2.2 eNB Handler Management Entity ..........................................................................................................13 1.2.3 LSA-OAI Proxy web interface ...................................................................................................................14

1.2.3.1 FLEX-LSA presentation page.................................................................................................................................................. 14 1.2.3.2 Login page ....................................................................................................................................................................................... 15 1.2.3.3 Home page ...................................................................................................................................................................................... 16 1.2.3.4 Creating eNB Handlers .............................................................................................................................................................. 17

2. INTEGRATION WITH THE EURECOM TESTBED .......................................................................... 18 2.1 INTRODUCTION ................................................................................................................................................... 18

2.1.1 Nodes ...................................................................................................................................................................18 2.2 REQUIREMENTS .................................................................................................................................................. 18 2.3 EXPERIMENT WITH EURECOM ...................................................................................................................... 18

3. INTEGRATION WITH THE NITOS TESTBED ................................................................................. 21 3.1 INTRODUCTION ................................................................................................................................................... 21

3.1.1 Nodes ...................................................................................................................................................................21 3.2 REQUIREMENTS .................................................................................................................................................. 21 3.3 EXPERIMENT WITH NITOS .............................................................................................................................. 21

4. CONCLUSIONS ......................................................................................................................................... 24


Title February 2016



of 24

List of Acronyms and Abbreviations

CEPT Conference of European Postal & Telecommunications

CR Cognitive Radio

ECC European Communication Committee

EIRP Equivalent Isotropically Radiated Power

EPC Evolved Packet Core

ETSI European Telecommunications Standards Institute

EU European Union

FCC Federal Communications Commission

FDD Frequency Division Duplex

FIRE Future Internet Research and Experimentation

FLEX FIRE LTE Testbeds for Open Experimentation

IP Internet Protocol

LC LSA Controller

LSA Licensed Shared Access

LSRAI LSA Spectrum Resource Availability Information

LTE Long Term Evolution

MAC Medium Access Control

MNO Mobile Network Operator

NRA National Regulatory Authority

LNA Low-Noise Amplifier

LSA Licensed Shared Access

OFDM Orthogonal Frequency Division Multiplexing

OAI OpenAirInterface

OAM Operation, Administration and Maintenance system

QoE Quality of Experience

QoS Quality of Service

RF Radio Frequency


Title February 2016



of 24

RRS Reconfigurable Radio Systems

RTAI Real-Time Application Interface

SA Service and System Aspects

SDR Software Defined Radio

SIM Subscriber Identity Module

SON Self-Organizing Network

SRdoc System Reference Document

TCP Transmission Control Protocol

TDD Time Division Duplex

UE User Equipment

USRP Universal Software Radio Peripheral


Title February 2016



of 24

Introduction

The main objective of the FLEX-LSA experiment is to test the latest ETSI specifications of LSA using new software modules and existing LTE equipment provided by two FLEX testbeds (EURECOM and NITOS). Moreover, the experiment contributes towards a benchmarking of LSA technology in two different EU countries: France and Greece.

The experiment uses tools adopted by FLEX consortium for the FIRE+ control and monitoring, in particular, the OMF, NITOS Scheduler and the LTErf service. The OMF control and management framework is used to facilitate the testbeds resources control and administration, as well as orchestrating the whole experiment lifecycle. The NITOS scheduler is used to reserve time slots, nodes and channels. The LTErf service is used for the configuration of the underlying LTE equipment.

This document describes the main FLEX-LSA experiment results and is organized as follows: Section 1 describes the software tools used for the integration with FLEX LTE testbeds (EURECOM and NITOS). Section 2 describes the LSA tests performed using the EURECOM testbed and Section 3 describes the LSA tests performed using the NITOS testbed. Finally, Section 4 presents the main conclusions of the FLEX-LSA experiment.


Title February 2016



of 24

1. Software Modules

This section describes the software modules developed for the integration with the two FLEX testbeds (EURECOM and NITOS). It also updates some minor requirements and functionalities specified in the previous deliverables of FLEX-LSA experiment.

1.1 The LSA Platform

This section provides the final description of the LSA Platform that was introduced in previous FLEX-LSA deliverables.

1.1.1 LSA Repository

The LSA Repository (LR) contains the relevant information on LSA spectrum that must be protected together with the level of protection required to protect the incumbent(s). It supports the entry and storage of information describing incumbents’ usage and protection requirements such as restriction/exclusion zones and protection zones. It can convey the related availability information to authorized LSA Controllers (LC), and is also able to receive and store acknowledgement information received from the LCs.

Figure 1: RED Technologies system architecture

Additionally, the concerned administration/National Regulatory Agency (NRA) provides information on sharing rules to the repository and obtains notification reports from it. Finally, the LR ensures that the LSA system operates in conformance with the Sharing Framework, as described in Section 1.1.3, and the licensing regime.

More in general, the RED Technologies LSA live Repository® used in the experiment implements the contractual terms and orchestrates the usage of LSA shared spectrum, updates sharing agreements, the policy or add new conditions dynamically. It provides real-time, interactive, multi-licensee radio environment maps, supports on-demand preemptions by incumbents and on-demand authorizations for LSA licensees using embedded collaborative workflows, provides dashboards, reporting tools and embedded collaborative workflows for incumbent(s), administrations and LSA licensees and includes plug and play policy and radio propagation models. The RED Technologies LSA Live Repository functional architecture is described by Figure 2.


Title February 2016



of 24

Figure 2: LSA Repository Functional architecture

1.1.2 LSA Controller

The LSA Controller (LC) provides the mobile network run by a LSA Licensee, with means to access the LSA spectrum, to react on incumbent activity, and to optimize the usage of LSA spectrum resources within the mobile network domain. These capabilities are implemented by obtaining LSA Spectrum Resource Availability Information (LSRAI) from the LR, providing acknowledgments to it, interacting with the mobile network receiving confirmations from the mobile network, and planning optimal radio configuration. The RED Technologies LSA Live Controller functional architecture is described by Figure 3.

Figure 3: LSA Controller Functional architecture


Title February 2016



of 24

1.1.3 LSA-1 interface

In this experiment, the LSA1 interface between the LR and the LC use XML and TCP sockets. The exchange of data between the LR and the LC is supported by a procedure at LSA1 interface as shown in Figure 4, where the LSA Controller is the client and the LSA Repository is the server.

1. The LR sends a LSRAI notification message to the LC, comprising new or updated LSRAI message; 2. Upon reception of the LSRAI notification message the LC will check the consistency of the information

provided; 3. If consistency check is successful, the LC will respond with a LSRAI notification Ack message to confirm

the reception of new LSRAI; 4. Upon successful LSA resource optimization and corresponded LTE configuration, the LC sends a LSRAI

Confirmation message to the LR to confirm execution of changes in the mobile network; 5. Upon reception of the LRAI Confirmation Request message, LR acknowledges the reception of the

confirmation by sending a LSA Spectrum Resource Confirmation Request Response message to the LC.

Figure 4: LSRAI notification and confirmation messages flow

1.1.4 Radio Environment Maps

Both LR and LC include RED’s in house REM (Radio Environment Map) technology illustrated in Figure 5. REM is as a key enabler for the European’s Licensed Shared Access and the United States’ Spectrum Access System (SA). The main features of REM are:

REM is made from geolocalized radio environment information such as user configuration data, network topology, RF propagation modeling, and live measurements.

The radio environment is mapped in time, space & frequency and is continuously updated.

The REM can be centralized or distributed.

The REM embeds an in-house automated propagation model selection engine.

The User Interface is powered by a Geographical Information System

The REM supports very large amount of data (nationwide maps) and embeds BI open source analytic and reporting tools.


Title February 2016



of 24

Figure 5: Radio Environment Map principles

The REM supports different zone types such protection and exclusion zones, the FLEX-LSA experiment makes use of protection zones which are geographical areas within victim receivers will not be subject to harmful interference caused by interferer transmissions. A protection zone is normally applicable for a defined frequency range and time period.

National Regulatory Agencies impose that the electromagnetic field (𝐸) emitted by all interferer transmitters operating in co-channel and/or adjacent channels of the victim receivers does not exceed a level 𝑑𝐵𝜇𝑉/𝑚/𝑀𝐻𝑧 within the defined protection zones i.e. a mean field strength that does not exceed a defined value in 𝑑𝐵𝜇𝑉/𝑚/𝑀𝐻𝑧 at a defined receiver antenna height above ground level.

The victim receiver sensitivity is converted from receiver’s received power level in 𝑑𝐵𝑚 to field strength 𝐸 (in 𝑑𝐵𝜇𝑉/𝑚) using the following equation:

𝐸(𝑑𝐵𝜇𝑉/𝑚) = (𝐼𝐶 − 𝐺𝑟 + 𝑃𝑓𝑟 ) + 20 log10 (𝑓𝑟𝑒𝑞(𝑀𝐻𝑧)) + 77.21

where:

𝐼𝐶 is the Interference Criteria at the receiver (𝑑𝐵𝑚);

𝐺𝑟 is receiver antenna gain in the direction of the interfering site;

𝑃𝑓𝑟 is cable and feeder loss at receiver (dB);

𝐸(𝑑𝐵𝜇𝑉/𝑚) above is given for co-channel situation. For 1st adjacent channel situation, a computed correction factor should be added.

1.2 LSA-OAI Proxy

The FLEX-OAI Proxy is the software module that handles the communications between the OAI eNB’s and the LSA Controller. The application is developed in JAVA programming language and it is a JAVA Enterprise/Web Application. This application needs to run in a JAVA Application Server. The GlassFish Server Open Source Edition is the server adopted to run the application.


Title February 2016



of 24

This section updates and provides the final description of the LSA-OAI Proxy, introduced in the previous FLEX-LSA experiment deliverables. Figure 6 presents an updated version of the LSA-OAI Proxy system architecture.

LSA Repository

LSA Controller

LSA Contoller/LSA Repository

eNB Handler Management Entity

eNB 1

eNB 2

eNB 3

eNB n

eNB Handler 1

eNB Handler 2

eNB Handler 3

eNB Handler n

HTML Web Interface

LSA-OAI Proxy

... ...

Figure 6: LSA-OAI Proxy system architecture

The three main components of the LSA-OAI Proxy are:

eNB Handler: is the responsible for the communications between the eNB and the LSA Controller;

eNB Handler Management Entity: is the entity responsible for the management of all the eNB Handlers. This module is also responsible to enforce in the eNB Handlers the policies and configurations provided in the web interface;

HTML Web Interface: is the web interface to manage remotely the eNB Handlers.

1.2.1 eNB Handler

This module is the interface between the eNB and the LSA Controller. Each eNB will have a single instance of an eNB Handler. The two main roles of an eNB Handler are:

To enforce the LSA Platform policies in the eNB;

To be responsible for the communications between the eNBs and the LSA Controller. The eNB Handlers are entities responsible for the communications between the eNBs and the LSA Controller.

1.2.2 eNB Handler Management Entity

The eNB Management Entity is the software module responsible to manage all the eNB handlers created for each eNB. Only one eNB Management Entity is used to manage all the eNB Handler instances. This module is also the module that enforces the configurations provided by the user in the web interface for each eNB. This module does not care neither handles any communication between the eNB and the LSA Controller. This is a function of each eNB Handler.


Title February 2016



of 24

1.2.3 LSA-OAI Proxy web interface

The LSA-OAI Proxy also provides a web interface for management and configurations. This web interface is also available in a platform which is technology agnostics. This allows for the configuration and access from any platform, the only requirement is a web browser compatible with HTML5.

The LSA-OAI web interface is organized in several web pages, the main ones are the following:

FLEX-LSA presentation

Login

Home

eNB configurations

OpenAirInterface and LTErf connection status

1.2.3.1 FLEX-LSA presentation page

The “FLEX-LSA presentation page” provides a summary and a short presentation of the FLEX-LSA project. Figure 7 shows this initial page (the page is publicly available at http://213.16.85.177/FlexLsa).

Figure 7: LSA-OAI Proxy web interface (presentation page)

http://213.16.85.177/FlexLsa


Title February 2016



of 24

1.2.3.2 Login page

When the application is publicly available through the internet, a username and password is required before the user be able to manage and perform any configuration. This feature prevents that unauthorized users make changes and misconfigurations on the testbeds. Figure 8 shows the login page.

Figure 8: LSA-OAI Proxy web interface (login page)


Title February 2016



of 24

1.2.3.3 Home page

After a successful login, the user will be welcomed to the “Home page”. In this page, the user will be able to manage all the eNBs handled by the LSA-OAI Proxy. Figure 9 shows an example where five eNBs are managed by the application.

Figure 9: LSA-OAI Proxy web interface (home page)

Description of the fields:

Cell ID: is a unique identifier for each cell, this is the parameter used by the LSA Controller to identify each cell managed by the LSA Platform;

Status: is the current status of the eNB Handler with two possible values: “running” and ”stopped”. Note that this field does not correspond to the status of a specific eNB but it only corresponds to the status of the eNB Handler associated with that eNB;

Description: is a textual description that allows the user to identify in an easier way the eNB Handler for a specific Cell Id;

Transmit power: is the eNB transmit power measured in Watt;

Action: Depending on the current status of the eNB Handler, the possible actions are the following:

o Start: the eNB Handler Management Entity sends a start signal for the corresponding eNB Handler. This action will Register the eNB on the LSA Controller. After a successful registration, the eNB becomes to be managed by the LSA Platform.

o Stop: the eNB Handler Management Entity sends a stop signal for the corresponding eNB Handler. This action will request the eNB Handler to Deregister the eNB from the LSA Platform. After a successful deregistration the eNB is configured with its default configurations and this eNB is no longer managed by the LSA Platform.

o Delete: first, the eNB Handler Management Entity sends a stop signal to the corresponding eNB Handler, after a successful deregistration the eNB Handler is destroyed.


Title February 2016



of 24

1.2.3.4 Creating eNB Handlers

Each eNB is associated to an eNB Handler. An eNB Handler instance must be created for each eNB in order to be managed by the LSA Platform. This module is responsible for the handling of the communication between the LSA Controller and the corresponding eNB. Figure 10 shows the form to configure the eNB parameters. Some parameters are retrieved directly from the eNB whenever possible.

Figure 10: LSA-OAI Proxy web interface (create eNB Handler page)


Title February 2016



of 24

2. Integration with the EURECOM testbed

This section describes the tests performed with the EURECOM testbed. The description is provided step-by-step with screenshots to illustrate the software modules that were developed by FLEX-LSA.

2.1 Introduction

The main objective of using the EURECOM testbed is to evaluate the performance of the LSA Platform with a single eNB and validate the standardized LSA protocol between the eNB and the LSA Controller.

2.1.1 Nodes

For this experiment, we use the following nodes available on the EURECOM testbed:

Node grosjean: UE

Node massa: HSS

Node alonso: MME+SP-GW1

Node vettel: OAI eNB

It should be noted that during the experiments we were not able to retrieve the transmit power from the OAI eNBs, so we have used the static value of “40” only for reference.

2.2 Requirements

List of requirements for this experiment:

The UEs configured in the HSS

HSS compiled and running

EPC compiled and running

eNB compiled and ready to run

2.3 Experiment with EURECOM

When the experiment starts, the eNB has a default configuration. Figure 11 shows the eNB status in the black terminal window on the top right corner, this process is named “lte-softmodem”. The LSA-OAI Proxy has no eNB Handler running neither the LSA Platform has any eNB registered, as shown in Figure 11.


Title February 2016



of 24

Figure 11: EURECOM testbed - initial state

After starting the eNB Handler, the eNB will be registered on the LSA Platform. All the modules are now synchronized and the LSA Platform is able to manage the eNB (see Figure 12). Figure 12 also shows the eNB coverage area.

Figure 12: EURECOM testbed – all modules synchronized

In the next step, an incumbent system (for example a PMSE link) needs to transmit in the same geographical area. The LSA Platform computes the radio environment maps and based on that calculations gets the new configuration parameters for the LTE network, in order to avoid interference with the incumbent system. A protection zone is delimited and the LSA Platform enforces a configuration of the eNB to avoid harmful interference with the incumbent system (Figure 13).


Title February 2016



of 24

Figure 13: EURECOM testbed – protection zone appears under the eNB coverage area

When the protection zone appears under the eNB coverage zone, the LSA Platform enforces the eNB to stop transmitting, because the incumbent is transmitting in the same band. In this case, the LSA Controller sends a heartbeatSonResponse towards the eNB Handler with 𝑡𝑟𝑎𝑛𝑠𝑚𝑖𝑡 𝑝𝑜𝑤𝑒𝑟 = −128 𝑑𝐵𝑚 and the eNB stop transmitting.

After the incumbent system stops transmitting, the LSA Platform sends a new heartbeatSonResponse message towards the eNB Handler with the new configuration, including a new value for the transmit power. Figure 14 shows the status of each element after the LSA Platform decides that the eNB can restart the transmission.

Finally, when the eNB Handler receives the new heartbeatSonResponse it will send a message to the eNB to restart the transmission. Figure 14 shows that the protection zoned disappeared from the map, and through the radio environment map is possible to see that the eNB is already transmitting.

Figure 14: EURECOM testbed – eNB restart transmitting


Title February 2016



of 24

3. Integration with the NITOS testbed

This section describes the tests performed with the EURECOM testbed. The description is provided step-by-step with screenshots to illustrate the software modules that were developed by FLEX-LSA.

3.1 Introduction

The main objective of using the NITOS testbed is to evaluate the performance of the LSA Platform with three eNBs and validate the standardized LSA protocols.

3.1.1 Nodes

For this experiment, we use the following nodes available on the NITOS testbed:

node059: OAI eNB 1

node060: OAI eNB 2

node068: UE

node069: EPC+HSS

node070: OAI eNB 3

It should be noted that during the experiment we were not able to retrieve the transmit power from the OAI eNBs, therefore we have used the static value of “40” only for reference.

3.2 Requirements

List of requirements for this experiment:

The UEs configured in the HSS

HSS compiled and running

EPC compiled and running

OAI eNB1 compiled and running



3.3 Experiment with NITOS

Figure 15 shows on the right side the terminals associated to each node. From top to bottom we have node059, node060 and node070. The process responsible to run the OAI eNB is named as “lte-softmodem.R”.

The initial setup is the following:

The three eNBs are running (all the three terminal windows have the “lte-softmodem.R” process running);

LSA-OAI Proxy with the eNB Handlers running;

The three eNBs are registered on the LSA Platform.

Figure 15 shows the initial setup with the REM for the three eNBs, the OAI-LSA Proxy web interface at Home Page, and three terminal windows (one for each OAI eNB node).


Title February 2016



of 24

Figure 15: NITOS testbed – initial setup

In the example shown in Figure 16, an incumbent system (e.g. PMSE link) starts transmitting, the LSA Platform computes the radio environment map and accordingly with the results the LSA Platform decides to shut down eNB3 in order to avoid harmful interference with the incumbent system.

The LSA Platform decides that cell 208-10-365062 should not transmit while the license for the incumbent system is still valid. The LSA Platform sends a heartbeat son message to that cell with 𝑡𝑟𝑎𝑛𝑠𝑚𝑖𝑡 𝑝𝑜𝑤𝑒𝑟 = −128𝑑𝐵𝑚. Figure 16 shows that the cell where the incumbent system was transmitting is disabled, while the other two eNBs are transmitting normally, without any change. Note that for node070, the “lte-softmodem.R” process is no longer running and the corresponding eNB is disabled.

Figure 16: NITOS testbed – incumbent 1


Title February 2016



of 24

Figure 17 shows the exclusion zone on the map and the status of each module after the LSA Platform performs all the required actions. When the LSA Platform realizes that an eNB can be activated without the risk of harmful interference, it sends a heartbeatSonResponse to the eNB enforcing its normal power.

Figure 17: NITOS testbed – exclusion zone


Title February 2016



of 24

4. Conclusions

The Licensed Shared Access (LSA) regulatory regime offers the potential for Mobile Network Operators to gain access to new spectrum bands under conditions that resemble exclusive licensing while guaranteeing the incumbent spectrum users’ rights. The new LSA approach has attracted great interest as a means for licensed sharing for MNOs with recent standardization and regulatory developments in Europe. In Europe, the LSA work is currently focused on the 2.3–2.4 GHz band as the first application. In this band, the incumbent systems vary in different countries.

The FLEX-LSA experiment was able to combine a LSA platform brought by RED Technologies with existing LTE equipment from EURECOM and NITOS, using a variety of FLEX resources (OAI and commercial equipment). This experiment was the first time that the LSA functional architecture was demonstrated operating simultaneously in two countries (France and Greece).

The FLEX-LSA experiment has successfully tested and validated the ETSI specifications of the LSA standard, including the LSA architecture and associated protocols. Thanks to this project, the FLEX federation was extended with new LSA modules remotely accessible (LSA Repository, LSA controllers) and standardized interfaces that together with EURECOM and NITOS testbeds allow end-to-end experimentation of LSA spectrum sharing technology.

The project has provided two contributions to ETSI RRS (Reconfigurable Radio Systems) standardisation technical committee and was demonstrated during an industry driven workshop organized by ETSI, Orange and Intel with very good feedback.

Moreover, this project was able to speed up the development process of the LSA interfaces, with different implementations being tested on the field. Indeed experimentations "under real-life conditions" give an undeniable advantage to RED Technologies and ALLBESMART for future commercial deployments in Europe and abroad and constitutes a competitive advantage over its competitors.

ICT - Information and Communication Technologies · General for Communications Networks, Content &...

Documents

Transcript of ICT - Information and Communication Technologies · General for Communications Networks, Content &...