D6.1: FED4FIRE compliance of ORCA testbeds and initial integration of SDR platforms
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
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: 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: 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: 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: 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: 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: 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: 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: 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: 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 26D6.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 26D6.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 26D6.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 26D6.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 26D6.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 26D6.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 26D6.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 26D6.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 26D6.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 26D6.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 26D6.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 26D6.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 26D6.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 26D6.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 26D6.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
