D6.1: FED4FIRE compliance of ORCA testbeds and initial integration of SDR platforms

 
D6.1: FED4FIRE compliance of ORCA testbeds and initial integration of SDR platforms
Grant Agreement No.: 732174
                                      Call: H2020-ICT-2016-2017
                                      Topic: ICT-13-2016
                                      Type of action: RIA

          Orchestration and Reconfiguration Control Architecture

       D6.1: FED4FIRE compliance of
          ORCA testbeds and initial
        integration of SDR platforms
                                  Revision: v.1.0

Work package             WP 6
Task                     T6.1, T6.2, T6.3
Due date                 31/12/2017
Submission date          22/12/2017
Deliverable lead         IMEC
Version                  1.0
Authors                  Pieter Becue (IMEC), Wei Liu (IMEC), Xianjun Jiao (IMEC),
                         Ingrid Moerman (IMEC), Ivan Seskar (RUTGERS), Prasanthi
                         Maddala (RUTGERS), Diarmuid Collins (TCD), Luiz Da Silva
                         (TCD), Seyed Ali Hassani (KUL), Andrea Guevara (KUL), Jona
D6.1: FED4FIRE compliance of ORCA testbeds and initial integration of SDR platforms
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

                                          Beysens (KUL), Ana-Belen Martinez (TUD), Zhitao Lin (TUD) and
                                          Martin Danneberg (TUD)
 Reviewers                                Clemens Felber (NI), Francisco Paisana (TCD)

 Abstract                                 This deliverable reports on the status of FED4FIRE compliance of
                                          ORCA testbeds. It also describes the actions taken towards the initial
                                          integration of SDR platforms into the ORCA facility.
 Keywords                                 FED4FIRE, testbeds, SDR

                   Project co-funded by the European Commission in the H2020 Programme

                Nature of the deliverable*:                                           R
                                                    Dissemination Level
 PU          Public, fully open, e.g. web                                                                   ü
 CI          Classified, information as referred to in Commission Decision 2001/844/EC
 CO          Confidential to ORCA project and Commission Services

Disclaimer
The information, documentation and figures available in this deliverable, is written by the ORCA
(Orchestration and Reconfiguration Control Architecture) – project consortium under EC grant
agreement 732174 and does not necessarily reflect the views of the European Commission. The
European Commission is not liable for any use that may be made of the information contained herein.
Confidential - The information contained in this document and any attachments are confidential. It is
governed according to the terms of the project consortium agreement

Copyright notice
© 2017 - 2020 ORCA Consortium

* R: Document, report (excluding the periodic and final reports)
DEM: Demonstrator, pilot, prototype, plan designs
DEC: Websites, patents filing, press & media actions, videos, etc.
OTHER: Software, technical diagram, etc

© ORCA Consortium 2017-2020                         Page 2 of 26
D6.1: FED4FIRE compliance of ORCA testbeds and initial integration of SDR platforms
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

EXECUTIVE SUMMARY
This deliverable reports on the efforts of testbed development in the first year of the ORCA project. The
ORCA facility consists of 5 testbeds: (i) w-iLab.t testbed from IMEC, (ii) KUL testbed, (iii) ORBIT
testbed from RUTGERS, (iv) IRIS testbed from TCD and (v) OWL testbed from TUD. Among the five
testbeds, there are three testbeds (w-iLab.t, IRIS, ORBIT) already FED4FIRE compliant before the
ORCA project. The advantage for a testbed to be FED4FIRE compliant enables users to access different
testbeds via a unified interface and a single user account. Making all ORCA testbeds FED4FIRE
compliant is needed to have a common portal for ORCA facilities. KUL and TUD have taken the
necessary steps to make their testbeds also compliant to the FED4FIRE standards. In addition, each of
the partners has brought in new functionalities for SDR related experimentations, ranges from
deployment of new hardware, and or support for new experimentation tools on the existing SDR
platforms.

© ORCA Consortium 2017-2020                 Page 3 of 26
D6.1: FED4FIRE compliance of ORCA testbeds and initial integration of SDR platforms
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

TABLE OF CONTENTS
EXECUTIVE SUMMARY ................................................................................................................... 3
TABLE OF CONTENTS ...................................................................................................................... 4
LIST OF FIGURES ............................................................................................................................... 5
LIST OF TABLES ................................................................................................................................. 6
ABBREVIATIONS ................................................................................................................................ 7
1            INTRODUCTION .................................................................................................................. 8
2            FED4FIRE COMPLIANCE OF ORCA TESTBEDS ......................................................... 9
2.1          Overview .................................................................................................................................. 9
2.2          Steps towards full FED4FIRE compliance ............................................................................ 10
2.2.1        Online Wireless Lab ............................................................................................................... 10
2.2.2        KUL testbeds .......................................................................................................................... 12
3            SDR PLATFORM INTEGRATION INTO ORCA TESTBEDS..................................... 14
3.1          Overview of supported SDR platforms .................................................................................. 14
3.2          SDR platform integration into testbeds .................................................................................. 15
3.2.1        W-iLab.t ................................................................................................................................. 15
3.2.2        ORBIT .................................................................................................................................... 16
3.2.3        IRIS ........................................................................................................................................ 17
3.2.4        OWL ....................................................................................................................................... 19
3.2.5        KUL testbed ........................................................................................................................... 20
4            CONCLUSIONS ................................................................................................................... 25
REFERENCES ..................................................................................................................................... 26

© ORCA Consortium 2017-2020                                     Page 4 of 26
D6.1: FED4FIRE compliance of ORCA testbeds and initial integration of SDR platforms
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

LIST OF FIGURES
Figure 1: FED4FIRE federation tools .................................................................................................. 9
Figure 2 OWL Architecture ................................................................................................................ 10
Figure 3 KUL testbed FED4FIRE connection architecture ............................................................ 12
Figure 4 USRP X310 with programmable topology in w-iLab.t ..................................................... 15
Figure 5 USRP mini rack in ORBIT .................................................................................................. 17
Figure 6 KUL Full-Duplex Testbed ................................................................................................... 20
Figure 7 Full-Duplex capable SDR ..................................................................................................... 20
Figure 8 Full-Duplex SDR, hardware architecture .......................................................................... 21
Figure 9 Host interface for KUL Full-Duplex testbed ...................................................................... 21
Figure 10. BS controller and master octoclock connections ............................................................ 22
Figure 11. USRP subsystem connections ........................................................................................... 23
Figure 12. 32 antennas array .............................................................................................................. 23
Figure 13. Mobile user setup ............................................................................................................... 24

© ORCA Consortium 2017-2020                                Page 5 of 26
D6.1: FED4FIRE compliance of ORCA testbeds and initial integration of SDR platforms
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

 LIST OF TABLES
Table 1 Overview of supported SDR platforms ................................................................................ 14

© ORCA Consortium 2017-2020                         Page 6 of 26
D6.1: FED4FIRE compliance of ORCA testbeds and initial integration of SDR platforms
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

ABBREVIATIONS
AM               Aggregate Manager
API              Application Programming Interface
BS               Base Station
CPS              Cabled Port Switch
CSMA             Carrier Sense Multiple Access
EBD              Electrical Balance Duplexer
FPGA             Field-programmable gate array
GFDM             Generalized Frequency Division Multiplexing
GPU              Graphics Processing Unit
HTTPS            Hypertext Transfer Protocol Secure
IP               Internet Protocol
JTAG             Joint Test Action Group
GPS              Global Positioning System
MIMO             Multiple Input Multiple Output
OCLKM            Octoclock
OMF              cOntrol and Management Framework
OS               Operating System
PPS              Primary Synchronization Sequence
PC               Personal Computer
SDR              Software Defined Radio
SFA              Slice Federation Architecture
SSH              Secure Shell
TCP              Transmission Control Protocol
UE               Users Equipment
USRP             Universal Software Radio Peripheral
RFNoC            RF Network on a Chip
XML-RPC          Extensible Markup Language Remote Procedure Call
BLE              Bluetooth Low Energy

© ORCA Consortium 2017-2020                 Page 7 of 26
D6.1: FED4FIRE compliance of ORCA testbeds and initial integration of SDR platforms
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

1                 INTRODUCTION
This deliverable reports the effort of testbed development in the first year of ORCA project. The ORCA
facility consists of 5 testbeds: (i) w-iLab.t testbed from IMEC, (ii) KUL testbed, (iii) Orbit testbed from
RUTGERS, (iv) IRIS testbed from TCD and (v) OWL testbed from TUD. Among the five testbeds,
there are three testbeds (w-iLab.t, IRIS, ORBIT) already FED4FIRE compliant before the ORCA
project. FED4FIRE compliancy refers to offering access to all users associated to the federation, as well
as supporting the Slice Federation Architecture (SFA) interface. Through the SFA interface it is possible
to browse, reserve and provision resources in many testbeds worldwide. This significantly simplifies the
testbed access for experimenters because it enables them to access many different testbeds with a single
account and through a unified interface, namely the jFed tool1. Hence it is meaningful to make all ORCA
testbeds FED4FIRE compliant. In this year, KUL and TUD have taken necessary steps to reach this
goal; details are described in Section 2.
In addition, each of the partners has brought in new functionalities for SDR related experimentations,
ranges from deployment of new hardware, and or support for new experimentation tools on the existing
SDR platforms. In Section 3, first an overview of the supported SDR tools in ORCA facility, and then
a more detailed description of each of the partner’s SDR integration is followed.

1
    https://www.fed4fire.eu/tools/jfed/

© ORCA Consortium 2017-2020                 Page 8 of 26
D6.1: FED4FIRE compliance of ORCA testbeds and initial integration of SDR platforms
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

2            FED4FIRE COMPLIANCE OF ORCA TESTBEDS

    2.1 Overview
This chapter reports on the FED4FIRE compliancy of all ORCA testbeds. While some of the testbeds
were already FED4FIRE compliant prior to the start of ORCA (w-iLab.t, ORBIT, IRIS), other testbeds
still had to implement the federation architecture (KUL testbed, OWL testbed).

                                    Figure 1: FED4FIRE federation tools
In Figure 1, the FED4FIRE federation tools are shown, where SFI stands for Slice Federation Interface,
which is an interface that can be implemented to interface with SFA, other than for example jFed. The
SFA defines the minimal set of interfaces and data types that permits a federation of slice-based network
components to inter operate. Component owners declare policies for resource allocation and usage on
the network under their control. Users allocate and access resources across the entire network1.
In ORCA, the current support for tools is limited to tools for accessing the federation, as well as for
reserving, discovering and provisioning testbed resources. Tools for experiment control, as well as tools
for measurement and monitoring are very testbed specific and are currently not enforced by ORCA or
FED4FIRE. It will be investigated as a result of the feedback from the open call experiments if it is
feasible to include support for these tools in the future.
The ORCA testbeds are considered FED4FIRE compliant if:
    •    all users of the federation are able to access all testbeds with a single user account in the form
         of an X.509 certificate. The X509 certificate is automatically generated when you register an
         account, and can be downloaded on https://authority.ilabt.iminds.be/.
    •    With this certificate users can make reservations, provision nodes and login to them on any
         testbed in the federation.
    •    at least one SFA-enabled tool is available to discover, reserve and provision resources on the
         testbeds. All but one testbed make use of the jFed experimenter tool, while ORBIT makes use
         of the OMF tool.

© ORCA Consortium 2017-2020                 Page 9 of 26
D6.1: FED4FIRE compliance of ORCA testbeds and initial integration of SDR platforms
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

    •     at least one experiment is fully documented from start to end. This should help new users of the
          federation to quickly bootstrap their experiment.

   2.2 Steps towards full FED4FIRE compliance
The following testbeds are already fully FED4FIRE compliant prior to the start of the ORCA project:
the w-iLab.t testbed (IMEC), ORBIT (RUTGERS), IRIS (TCD) and are thus not described in this
section.
In the following sub sections, the federation efforts of the two remaining testbeds are described: the
Online Wireless Lab at TUD and the SDR testbeds at KUL.

2.2.1      Online Wireless Lab

The “Online Wireless Lab (OWL)” testbed of the TU Dresden Vodafone Chair, formerly known as the
‘macro scale testbed’, supports the experimental investigation of technologies for next generations of
wireless communications systems.
We provide Software Defined Reconfigurable Radio Devices such as USRP, which includes a powerful
FPGA and can be used for prototyping wireless communication systems. The development tool
LabVIEW/LabVIEW Communication System Design Suite in combination with USRPs supports
experimenting with existing protocols such as LTE and 802.11, but it also enables fast proof-of-concept
for innovative communication technologies such as Generalized Frequency Division Multiplexing
(GFDM).

2.2.1.1    Architecture

Figure 2 presents the structure of the testbed OWL.

                                        Figure 2 OWL Architecture

OWL supports the jFed experimentation tool. On our reservation webpage, users can check the
availabilities of the resources and reserve them for their experiments. The experiment server will prepare
the remote access basing on the reservation information and the jFed commands from the user side.
Upon scheduled start time, the users can remotely access the testbed and control the setups via Secure
Shell (SSH). OWL will create a separate gateway for each experimentation group. The operating system
image on each resource PC is saved for each group and can be reloaded and updated when used the next
time.

© ORCA Consortium 2017-2020                 Page 10 of 26
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

Currently we offer the following Software Defined Radio (SDR) Platform as Experiment Resources:
    •     1 Laptop with LabVIEW Communication System Design Suite 2.0 + NI USRP 2953 40MHz
    •     2 PC with LabVIEW Communication System Design Suite 2.0
    •     1 PC connected to 2 PXI units for the mmWave setup

2.2.1.2    FED4FIRE Compliance

In order to follow the FED4FIRE interoperability standards, we implemented an Aggregate Manager
(AM) basing on the GENI Aggregate Manager Application Programming Interface (API) [ ] and the
Bootstrap Code for AM [ ]. As required by this API, our AM is able to authenticate and authorize
FED4FIRE experimenters by use of FED4FIRE X.509 certificates. The jFed experimentation tool can
be used by users to interact with the OWL testbed.
The user’s requests are sent by jFed in the form of Extensible Markup Language Remote Procedure Call
(XML-RPC) over Hypertext Transfer Protocol Secure (HTTPS). The AM listens to the HTTPS port,
gets the request, authenticates and authorizes the user to execute the experiment workflow. We
employed the root certificate from the FED4FIRE authority as the trusted root for the authentication and
authorization. Thus, the OWL is federated with the FED4FIRE user and slice authority. It accepts SSL
connections from FED4FIRE experimenters (authentication) and performs the actions, that are allowed
by the slice credentials (authorization).
The following functions are implemented in our AM, as required by the AM API:
“ListResources” returns a detailed list of the resources, which the user has reserved on the reservation
webpage.
“Allocate” satisfies the slice credential as well as the experimenter’s resource request, and reserves the
resources for the experimenter.
“Provision”: If the reservation request has been accepted, the reserved resources would be set up by this
function. The AM would use the Operating System Image (OSI) management tool, Clonezilla , to load
the OS image onto each PC. Therefore, the AM checks the OS image pool to find out the image for the
current experiment group. In case the experiment group has not saved its image yet, the AM will restore
the default OS image onto the resource PC.
“Renew”: In our implementation, all reservations are totally independent from each other for security
reasons. The AM reserves resource basing on the information from the reservation webpage. As such,
the experiment duration is not extendable by default. The “renew” function just checks the reserved
expiration time again.
“Delete”: When the experiment is finished, the reservation will be ended by calling “Delete”. The AM
will save the OS image using Clonezilla for the experiment group and frees the resources to be used by
other experimenters.

© ORCA Consortium 2017-2020                 Page 11 of 26
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

2.2.1.3       Setting up an Experiment

The FED4FIRE users can check the availability of the resources on the reservation webpage2, contact
us and reserve the required experimentation resources when they are available. This will allow the
Aggregate Manager to get the information of the reservation. After this reservation, the users can setup
an experiment using jFed. The request from jFed will be accepted and executed by the AM to allocate,
initiate and start the experimentation units. Then the user can try out their experiment on top of our
hardware using SSH or via Remote Desktop. After the reserved time expires, the AM will save the OS
Image for the current user group and free the experimentation resources.

2.2.2         KUL testbeds

There are two KUL testbeds which are made FED4FIRE compliant: Testbed00 and Testbed01. These
are Windows servers and can be accessed through the Remote Desktop application. The former can be
used for Massive MIMO applications with a large antenna array and multiple UE's while the latter
provides USRP development on 4 devices with in-band full duplex capabilities. We have LabVIEW
Communication Design installed on both set-ups enabling experimenters to extend/modify the host
interfaces according to their experiment requirements.

2.2.2.1       Architecture

As it is shown in the figure below, one can safely access our testbeds remotely. Such access can be seen
in three layers; a) the remote user layer including jFed and the Internet, b) the KUL gateway layer, which
provides user authorisation via the HTTPS protocol, and finally c) our hardware resources, including
the full-duplex and Massive MIMO testbeds. The next section describes these layers and explains how
they enable to connect an external user to KUL’s internal network.

                                Figure 3 KUL testbed FED4FIRE connection architecture

2.2.2.2       FED4Fire Compliance

To offer FED4FIRE interoperability, we have deployed and configured the Aggregate Manager (AM)
software, provided by [2], on the testbed gateway server. The AM supports authentication and
authorization of FED4FIRE experimenters by the FED4FIRE X.509 certificate. The jFed
experimentation tool can be used by the users to access the KUL testbeds from the internet.
When a user wants to connect to a specific testbed in jFed by selecting it, an Extensible Markup
Language Remote Procedure Call (XML-RPC) request is sent from jFed to the AM over the Hypertext

2
    https://www.orca-project.eu/testbeds/

© ORCA Consortium 2017-2020                      Page 12 of 26
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

Transfer Protocol Secure (HTTPS) protocol. The AM then authenticates and authorizes the user and if
successful, runs the experiment workflow. A docker instance with Ubuntu OS on the AM is started to
provide a secure SSH tunnel to the testbed. A predefined set of ports is configured to allow more than
one simultaneous active connection to the testbeds. Similarly to the OWL testbed, ours are federated
with the FED4FIRE user and slice authority.
When the users clicks on the testbed icon in jFed, it automatically starts the Remote Desktop application
to provide access to the testbed. These facilities enable the experimenter to run a test, recode the
measurements and transfer the results to a desirable memory for more analysis. Furthermore, the user
has direct access to the docker instance itself via SSH for higher flexibility. For example, the user can
control the testbed from the AM instead of directly connecting to the USRPs in LabVIEW via Remote
Desktop.

2.2.2.3       Setting up an experiment

To reserve a testbed, a request is made by sending an email to the reservation manager
telemicreservations@esat.kuleuven.be with detailed information about the duration and motivation of
the experiment. Once a reservation is approved for a testbed, an account is made for the testbed and the
credentials are given to the user. After this, the user can access the testbed through jFed. The following
steps explain how an external user can make the connection to the testbeds.
       1-   Get a new account for FED4FIRE by registering here3.
       2-   Download and install the jFed experimentation toolkit.
       3-   Login to jFed.
       4-   Create and run a new experiment according to the test scenario.
       5-   Connect to the testbed via Remote Desktop.
       6-   Terminate the experiment to release the resources.
In addition, an illustrative tutorial is available here4 to facilitate experiment establishment with the jFed
toolkit.

3
    https://authority.ilabt.iminds.be/signup.php
4
    https://redmine.esat.kuleuven.be/redmine/projects/fed4fire/wiki/External_usage

© ORCA Consortium 2017-2020                         Page 13 of 26
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

3            SDR PLATFORM INTEGRATION INTO ORCA TESTBEDS

    3.1 Overview of supported SDR platforms
The table below gives an overview of the SDR platforms supported in ORCA facilities.

                               Table 1 Overview of supported SDR platforms

         Testbed           w-iLab.t       ORBIT             IRIS      TUD        KUL       Portable
                           (IMEC)         (RUTGERS)         (TCD)     Testbed    Testbed   Testbed
    Nutaq ZeptoSDR                              X
    Nutaq picoSDR                               X
    PicoZed Xilinx                              X                                   X
    ZYNQ®-7000 SoC
    USRP B200-mini              X               X                         X                   X
    USRP E310                                   X
    USRP N210                   X               X             X           X
    USRP X310                   X               X             X
    USRP 2920                                                             X
    USRP 2921                                                                       X
    USRP RIO 2942R                                                                  X
    USRP RIO 2943R              X                                                   X
    USRP RIO 2952R                                                                  X
    (+ GPS)
    USRP RIO 2953R                                                        X
    (+ GPS)
    WARPv2                      X               X
    Xilinx ZC706                X                                                             X
    Evaluation Kit -
    ZYNQ® 7000 SoC
    + AD FMCOMM
    radio frontend
    ZedBoard Xilinx                             X                                             X
    ZYNQ®-7000 SoC
    ZedBoard Xilinx             X                                                             X
    ZYNQ®-7000 SoC
    + AD FMCOMM
    radio frontend
    BB – NI PXI 7975                                                      X
    Module
    BB – NI PXI 7965                                                      X
    Module
    FE - NI PXI 5644                                                      X
    FE – NI PXI 7976R                                                               X
    PXIe 8135                                                             X

© ORCA Consortium 2017-2020                 Page 14 of 26
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

     PXIe 8880                                                                        X
     NI PXI based                                                                     X
     mmWave base
     band + Sibeam V-
     band transceiver

*Legend: BB (baseband motherboard), FE (Frontend, RF daughterboard)

      3.2 SDR platform integration into testbeds

3.2.1        W-iLab.t

In the first year of ORCA, the following additional hardware is deployed into the w-iLab.t testbed:
4xUSRP X310 and 2x ZYNQ SDR nodes.
The USRP’s are deployed in a special way so that its RF environment, path loss from one USRP to
another, is programmable. This is achieved by putting each USRP into a Qosmotec box5. Within the
box, each of the USRP’s transmission and reception antenna ports is connected to a fixed 10 dB
attenuator, and then a 4 port combiner. The combiner’s output is sent to outside of the Qosmotec, and
connected to the output of other USRP’s Qosmotec box via programmable attenuators.

                             Figure 4 USRP X310 with programmable topology in w-iLab.t

5
    RF shielding box, https://www.qosmotec.com/products/test-accessories/rf-shield-box/

© ORCA Consortium 2017-2020                         Page 15 of 26
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

The fixed attenuators are necessary to emulate the isolation between the antenna ports of the same USRP,
i.e. 20 dB in this case. While the programmable attenuators are used to emulate the pathloss between
different USRPs, in this way the topology of the USRPs becomes configurable. The attenuation is
programmable via a web portal.
The X310 USRP has 10 Gbps network interfaces; these are connected to a 10Gbps switch. The USRPs
are accessible via jFed. Users can discover the USRP as individual nodes and map them with appropriate
host computer and desired OS images.
The ZYNQ SDRs are statically connected to certain nodes in the testbed. This is because they rely on
JTEG interface to be programmed. After the Field Programmable Gate Array (FPGA) is programmed,
the ZYNQ SDR can be connected to the host via 1 Gbps network interface. The exact IP address in fact
depends on the FPGA and firmware. Hence it is not possible to dynamically map ZYNQ SDR as an
independent node in the testbed. Users must reserve the SDR via its specific host node. Xilinx Vivado
2015.4, 2016.2 are installed on the OS images, which are the necessary versions for RF Network On a
Chip (RFNoC) and Radio hardware virtualization development.

3.2.2        ORBIT

ORBIT testbed has a 20x20 grid of programmable radio nodes, each equipped with various radio
resources such as WiFi 802.11a/b/g 802.11n 802.11ac, Bluetooth (BLE) and ZigBee. A number of SDR
platforms such as USRP, WARP, RTL-SDR, USRP N210, USRP X310, USRP B210, Nutaq
PicoSDR2x2-E and Nutaq ZeptoSDR are also hosted on the grid. During the first year of ORCA, the
following additional resources have been deployed in ORBIT
       •   In order to improve facilities for Massive MIMO experiments, 3 more Massive MIMO mini-
           racks have been added to the testbed. A mini-rack holds 8 USRP X310s, each with 2 UBX-160
           daughter cards. Each USRP is connected via 10G Ethernet to the rest of the Grid domain and
           appears as a node that responds to standard OMF (ORBIT Management Framework) power
           commands and can be accessed on the network by any other node on the grid domain. PPS and
           10MHz synchronization signals are distributed among the USRPs in each rack via an Octoclock
           6
             based timing distribution system. Equal length cables are used to ensure minimum timing
           deviation within and between the racks allowing for all USRPs across the four racks to be
           synchronized.

6
    https://www.ettus.com/product/details/OctoClock-G

© ORCA Consortium 2017-2020                       Page 16 of 26
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

                                              Figure 5 USRP mini rack in ORBIT

       •    7 specialized nodes with NVIDIA CUDA 7capable Graphics Processing Units (GPUs) (GeForce
            GTX 750 Ti, GeForce GT 640 GDDR5, Quadro K5000, Quadro K2000D, 2x Tesla K40, Tesla
            K80, 2x Tesla C2050) have been added to the grid and sandboxes. These nodes currently do not
            have any wireless radios, and are meant to offload computation via Ethernet network.
            Experiments are being conducted where huge amounts of data from massive MIMO racks are
            sent to the CUDA machines on the grid to leverage the acceleration provided by GPUs.
       •    A CloudLab rack with 24 NVIDIA Tesla P100 GPU accelerators is being deployed. This will
            provide an excellent computation platform for processing the huge amounts of data flowing in
            from massive MIMO experiments.

Tools and tutorials to use the newly deployed hardware have been provided [2] and more examples /
experiments are being added. RFNoC framework is supported on USRP X310s, and new RFNoC
modules are being developed to enable low latency applications. Experiments with RFNoC modules
on ORBIT include channel sounding on the MIMO racks, and ultra-wide band (2 GHz) spectrum
sensing using all the USRPs on a MIMO rack. Massive MIMO channel estimation experiments are
also being done using the newly deployed GPU accelerators.

3.2.3        IRIS

IRIS, the reconfigurable radio testbed at Trinity College Dublin, provides virtualized radio hardware to
support the experimental investigation of the interplay between radio capabilities and future networks.
Our facility pairs underlying flexible radio and computations resources with various hypervisors in the
form of software radio frameworks to realize advanced research and testing configurations. The
following hardware elements, which support the investigation of a combination of various physical layer
approaches into coexisting or coherent networks, have been added to the IRIS testbed in Year 1 of the
ORCA project. These include:
       •    6 x ceiling mounted USRP N210s equipped with SBX daughterboards reaching frequencies
            between 40 MHz and 4 GHz. The total N210 USRPs available at the Iris testbed is now 18.

7
    https://developer.nvidia.com/about-cuda

© ORCA Consortium 2017-2020                         Page 17 of 26
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

       •     2 x USRP X310s with CBX-120 USRP daughterboards (1.2GHz - 6 GHz, 120 MHz BW) and
             SBX-120 USRP Daughterboard (400MHz - 4.4 GHz, 120 MHz BW);
       •     2 x USRP N210 Beam forming nodes with SBX daughterboards reaching frequencies between
             40 MHz and 4 GHz;
To expose the functionality of this equipment for a variety of applications, we employ several different
types of radio hypervisors, each with different capabilities. These include GNU Radio8, IRIS SDR, and
srsLTE9 3GPP, which have been added previously as part of H2020 projects including WiSHFUL10 and
FED4FIRE, and updated during ORCA. All SDR virtual machines are equipped with 4CPU cores and
4GB of RAM.
We also added the following IRIS cloud processing capabilities in 2017:
       •     Support for 40 plain virtual machine instances, which are VMs hosted on IRIS’s cloud
             infrastructure provisioned with 1 CPU and 4GB RAM.
All resources are connected to a private computational cloud, allowing users to deploy an array of
computational environments. The following virtual machine images have been added since the
beginning of ORCA11:
       •     Spectrum visualization using Fosphor GNU Radio Block.
       •     The WiSHFUL framework for IRIS and GNU Radio SDR Frameworks.
       •     The OpenAir CN Evolved Packet Core Networks (HSS, MME, SPGW).
       •     Support for Docker and LXC container technology (including container migration support):
                 a. Open Air Interface Evolved Packer Core
                 b. Full stack srsLTE eNB.
       •     Plain Ubuntu 14.04.
       •     Plain Ubuntu 16.04.
       •     Open vSwitch.
       •     Future Internet Named Data Networking framework: NDN C++ library with eXperimental
             eXtensions, Named Data Networking forwarding daemon (NFD), and NDN Repo-Ng (Data
             Store).
Virtual machine instances can be deployed to complement radio hardware resources, acting as network
controller elements, evolved packet core (EPC) services, or supporting Future Internet content
distribution such as Named Data Networking (NDN). These components simplify, automate and
virtualize the delivery of a very diverse set of services over mobile heterogeneous networks towards
supporting 5G network configurations. All these resources are federated and available for reservation
via Fed4FIRE+.
Other hardware equipment purchased since the beginning of the ORCA project, but waiting integration
with FED4FIRE+, include:
       -     4 x B200 Mini’s
       -     Dell Networking Openflow S4048T-ON 100M/1G/10G/40GbE top-of-rack open networking
             switch

8
    https://www.gnuradio.org/
9
    https://github.com/srsLTE/srsLTE
10
     http://www.wishful-project.eu/
11
     https://iris-testbed.connectcentre.ie

© ORCA Consortium 2017-2020                  Page 18 of 26
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

All virtual machine images connected to N210s and X310 equipment are preinstalled with the relevant
Ettus USRP Hardware Drivers (UHDs). Depending on the needs of the experimenter, OS images for
SDR, network control and management, and evolved packer core, are available via jFed. A full set of
IRIS jFed tutorials are available12. Users have the freedom to install drivers, tools, and libraries based
on their experiment requirements. Finally, by accessing the IRIS TCD Testbed via the jFed platform
provided by the CONNECT Centre Trinity College Dublin the user declares legally its acceptance of
the terms and conditions of this User Agreement13.

3.2.4         OWL

In the OWL testbed, we employ the NI LabVIEW Communications System Design Suite and the NI
Software Defined Radio Reconfigurable Device USRP 2953R to build the reconfigurable SDR platform.
It also includes to PXI systems for the mmWave setup working in real time. This setup consists of one
transmitter and one receiver, each one is equipped with a PXI Chassis with real-time controller,
containing NI-7975 FlexRIO FPGA modules.
LVC is a development environment using a graphical programming language. It allows the users’
designs to be easily deployed in both host processors and FPGAs. Together with the NI software defined
radio hardware, it simplifies the prototyping of advanced wireless communication systems. The LVC
2.0 in our testbed includes LTE and 802.11 Application Frameworks, which can be used as a reference
design of PHY and lower MAC layer.
USRP 2953 RIO is built on the LabVIEW reconfigurable I/O (RIO) and USRP architectures. It includes
a powerful FPGA for advanced (digital) signal processing that is programmable with the LabVIEW
FPGA Module. It offers center frequencies from 1.2GHz to 6 GHz, with the Bandwidth of 40MHz per
channel, and it includes 2x2 MIMO RF transceivers with an on-board Kintex 7 FPGA.
The OWL testbed is extendable. Currently we offer three kinds of experiment units:
       •    2 * PC with LVC 2.0
            Available Software:
                o NI LabVIEW Communications System Design Suite 2.0
                o 802.11 Application Framework
                o LTE Application Framework
                o Matlab R2016a
                o NS-3

       •    1 * Laptop with USRP 2953 RIO
            Available Software:
                o NI LabVIEW Communications System Design Suite 2.0
                o 802.11 Application Framework
                o LTE Application Framework
                o Matlab R2016a
                o NS-3
            Capabilities:
                o Up to 40 MHz of Bandwidth per Channel
                o Center frequencies from 1.2GHz to 6GHz

12
     Experiment Tutorial, https://iris-testbed.connectcentre.ie/experiment_tutorial/
13
     IRIS Testbed Terms and Conditions, https://iris-testbed.connectcentre.ie/terms-of-use/

© ORCA Consortium 2017-2020                            Page 19 of 26
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

    •     mmWave setup with
             o Transmitter PXI unit
             o Receiver PXI unit
             o Sibeam V-band transceiver attached to PXIs with phased array antennas
          Capabilities:
             o Selection of different codebooks
             o Beam steering
             o Transmission at V-band 57-66 GHz

3.2.5      KUL testbed

The KUL ORCA testbed consists of 44 NI USPR RIOs that can be configured as (a) a distributed
Massive MIMO testbed with 64 antennas (32 URSP) and 12 users (6 USRPs). The remaining 6 USRPs
can be used as a full duplex network. Below, we detail both aspects of the testbed.

3.2.5.1    Full Duplex Network

Our testbed (Figure 6) offers an IEEE 802.15.4 network including four full-duplex capable SDRs and
one additional radio as the source of interference.

                                 Figure 6 KUL Full-Duplex Testbed
As shown in Figure 7, each node in this testbed is equipped with an Electrical Balance Duplexer (EBD)
and uses Particle Swarm optimizer to tune its coefficients. The EBD provides 50-60 dB Tx-Rx isolation
at 1.7GHz within 6MHz.

                                     Figure 7 Full-Duplex capable SDR

© ORCA Consortium 2017-2020                 Page 20 of 26
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

As shown in Figure 8, the FPGA design is based on a cross-layer architecture including Collision
Detection, PHY and MAC layers. There are two MicroBlaze softcores which are considered for EBD
tuning and deploying MAC protocol. The USRP controls the EBD through and interface board
connected to USRP’s AUX port.

                               Figure 8 Full-Duplex SDR, hardware architecture
Using the host interface in Figure 9, an experimenter can establish two types of test scenarios;
-   Two-node IEEE 802.15.4 network for wired Collisions Detection tests.
- Four-node IEEE 802.15.4 wireless network with unslotted CSMA, as a baseline for full-duplex
networking such as Full-Duplex CSMA with Collision Detection.
This testbed offers various facilities to the experimenters as follows.
         -   Managing the test scenario by an open source LabVIEW host code.
         -   Various measurements namely packet delivery rate and collision probability.
         -   Open source CSMA MAC protocol.
         -   Generating different interfering waveforms in the host interface.

                              Figure 9 Host interface for KUL Full-Duplex testbed

© ORCA Consortium 2017-2020                  Page 21 of 26
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

3.2.5.2   Distributed Massive MIMO

The Massive MIMO testbed has two main hardware components: Base Station (BS) and User Equipment
(UE), both are based on SDR controllers using USRP RIO from National Instruments.
For the BS one PC-based platform (PXI) acts as the controller, besides to process all the information it
provides the master trigger, a reference source (clock) and primary synchronization sequence (PSS)
source to the whole system. Reference source and PSS connects the controller to a master octoclock
(OCLKM1) via coaxial cables. OCLKM1 amplifies and splits a 10MHz reference signal to 4 USRP
subsystems.

                          Figure 10. BS controller and master octoclock connections
Each USRP subsystem has eight USRP RIO devices, each subsystem receives the clock and
synchronization signals from the OCLKM1 in a subsystem octoclock (OCLK), which distributes those
signals to the USRP RIO. In the case of data signal, it is connected between the PXI and one CPS device
[3] per subsystem with MXI x8 cables, the CPS splits the signal to the eight USRP RIO, as shown in the
figure above.

© ORCA Consortium 2017-2020                 Page 22 of 26
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

                                  Figure 11. USRP subsystem connections

Each USRP manages planar patch antennas (64 for the whole system), grouped in two arrays of 32
antennas each.

                                        Figure 12. 32 antennas array

© ORCA Consortium 2017-2020                 Page 23 of 26
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

One USRP RIO with internal GPS as reference signal is connected to a PC, and capable to handle two
UEs. The physical layer is placed in the FPGA of the USRP RIO, while the media access control layer
functionality is split between the FPGA and the host.14

                                             Figure 13. Mobile user setup

14
     MIMO Prototyping System, National Instruments 2015.

© ORCA Consortium 2017-2020                      Page 24 of 26
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

4            CONCLUSIONS
In conclusion, this deliverable reports the effort of testbed development in the first year of ORCA
project. The ORCA facility consists of 5 testbeds: (i) w-iLab.t testbed from IMEC, (ii) KUL testbed,
(iii) ORBIT testbed from RUTGERS, (iv) IRIS testbed from TCD and (v) OWL testbed from TUD. The
main part of the work is located in the FED4FIRE integration work of TUD and KUL. By implementing
an Aggregate Manager, both testbeds now support the SFA standard, which enables the usage of the
jFed experimenter tool. All users of the federation can now also gain access to these testbeds by making
use of a single user account (X.509 certificate). IMEC has provided extensive support for these
integration actions. More details are specified in Section 2.
In addition, each of the partners has brought in new functionalities for SDR related experimentations,
including the deployment of new hardware, and or support for new experimentation tools on the existing
SDR platforms. In Section 3, an overview is given for the supported SDR tools in the ORCA facility,
followed by a more detailed description of each of the partner’s new SDR facilities, in particular:
IMEC has brought in 4x USRP X310 hardware, with programmable topology support, and 2x ZYNQ
SDR devices into the w-ilab.t testbed. The USRP X310 and ZYNQ SDR are essential for the open call
experiment and extensions in the coming period of ORCA.
TCD has integrated 2 new USRP X310 front-ends, 6 USRP N210, and extended 2 existing USRP N210
with 2x2 MIMO capabilities. On the cloud processing side, IRIS testbed is now able to support 40 plain
virtual machine instances. TCD also extended its number of offered virtual machine images, including
now an Open vSwitch, fosphor spectrum visualization, WiSHFUL framework integration, docker
containers and container migration facilities, and support for LTE core components.
ORBIT testbed deployed additional massive MIMO mini-racks, with 32 USRP X310s in total, thus
improving its massive MIMO facilities. GPU acceleration for computation is provided via 7 new
NVIDIA CUDA capable GPUs. Cloud computation with NVIDIA P100s is being provided to further
aid in massive MIMO experiments.
TUD has brought in sub-6 GHz USRP 2953 RIO, allowing experiments with different waveforms. In
addition, TUD also offers a setup for beamforming operating at V-band, i.e., 57-66 GHz, utilizing 2 NI
PXI units.
KUL has developed a Full Duplex testbed including four nodes each equipped with an EBD. One extra
USRP is also considered to play the role of interferer. The whole testbed is configurable by a host
interface implemented in LabVIEW Communication Design Suite 2.0 and is available to experimenters.
Besides, an open source CSMA/CD MAC is offered as well as a systematic compilation guidance to
enable experimenters to develop new MAC protocols and program it on the testbed.
Massive MIMO testbed from KUL allows simultaneous transmissions UL and DL between 64
synchronized antennas at the Base Station and 12 single antenna users, different configurations for each
UE and BS also data collection could be applied through an open code developed in LabVIEW
Communication Design Suite 2.0.

© ORCA Consortium 2017-2020                 Page 25 of 26
D6.1: F4F compliance of ORCA testbeds and initial integration of SDR platforms
(V1.0)

REFERENCES

[1] PlanetLab Europe Management-Level Documentation Set. http://doc.planet-
lab.eu/html/x3129.html, last accessed on 12/21/2017
[2] ORBIT wiki, http://www.orbit-lab.org/, last accessed on 12/21/2017
[ 3 ] PCI express cabled switch device, http://www.ni.com/de-de/support/model.cps-8910.html, last
accessed on 12/21/2017

© ORCA Consortium 2017-2020                 Page 26 of 26
You can also read
Next slide ... Cancel