• 1
  • 2
  • 3
  • 4

Activities

  • NITOS Outdoor deployment consists of powerful nodes that feature multiple wireless interfaces and allow for experimentation with heterogeneous (Wi-Fi, WiMAX,

    Read More
  • The setup NITOS testbed is currently using is a fixed setup (employing no mobility between BSs) that does not require

    Read More
  • Towards the development of a remote accessible LTE testbed, where experimenters from all the word will be able to run

    Read More
  • NITOS facility provides remote access to OpenFlow switches (2 x Pronto 3290 , 2 x HP 3800 ), enabling the user to create

    Read More
  • NITlab developed a software defined radio (SDR) testbed that consists of 18 Universal Software Radio Peripheral (USRP) devices attached to

    Read More
  • NITOS is an Intelligent Transport System (ITS) compatible facility thanks to the implementation of the key components of the ITS

    Read More
  • NITOS cloud infrastructure is based on HP GEN8 blade servers and one HP DL380p GEN8 server. Cloud Infrastructure UTH Each blade server has

    Read More

NITOS

The Future Internet Facility

  • Outdoor Testbed

    Experiments under real world environment Read More
  • Indoor Testbed

    Experiments in RF isolated environment Read More
  • Office testbed

    Experiments in an office environment Read More
  • 1
  • 2
  • 3

Integration of IRIS in OMF

OMF IRIS Architecture

 

The NITOS  team has developed the appropriate extensions for supporting the IRIS (Implementing Radio in Software) platform with OMF.

More information about IRIS platform and guidelines of installing it to your testbed can be found here.

Our extensions have been bundled in .deb packages available in NITLab's repository. Target platforms are only debian based. For any other platform you can overwrite the default OMF files with the source files found in NITLab's git repository. You can clone the files with the following command, if you have an account in the NITLab server:

 git clone This email address is being protected from spambots. You need JavaScript enabled to view it.:/home/git/repos/iris.git

In order to install our package, you need to initially setup the official OMF version (our extensions currently support version 5.4).

Instructions on how to install OMF-5.4 in your testbed are available here.

In order to install our extensions, add the following repository in your your target machines (server and nodes), in the respective "/etc/apt/sources.list" file.

 deb http://nitlab.inf.uth.gr/ubuntu precise/ 

You can now install our extensions for the Experiment Controller (EC) at the server with the following command:

apt-get update && apt-get install omf-expctl-iris

The EC contains some more configuration lines in the configuration file included in /etc/omf-expctl-5.4/omf-expctl.yaml 

Depending on your setup, you need to configure a folder which will be used for transferring the IRIS configuration files to the RCs of the nodes, and the default network interface that communicates with the node network.

If any errors occur during an experiment execution (regarding the FTP service used), you might consider reinstalling the "ftpd" gem. This is included in the .deb file but errors might occur in a different machine.

In order to install the OMF RC for IRIS on the nodes you will have to issue the following commands:

 apt-get update && apt-get install omf-resctl-iris 

Installing this package on a node will unpack a Launcher.cpp file at the root directory of the node. (/root/Launcher.cpp). This file needs to replace the default launcher used by IRIS in the iris_core package. The file can be found at "iris_core/src/Launcher.cpp". The custom launcher is used to receive commands via socket messages from the RC, making interoperable with OMF. You will have to compile/recompile the IRIS framework with the new Launcher file.

If the nodes are up and running, you can now use a simple OMF Experiment Definition (ED) to configure the IRIS components running on multiple nodes.

Here is an example script that highlights the syntax adopted for configuring IRIS through OMF.

# Configure a group of the nodes which we will be used for the experiment
defGroup("Usrp","omf.nitos.node045"){ |node|

        # Set the full path were the configuration file can be found in the server.
        # This file will be transfered to the node before the experiment begins.
        node.net.u0.path_file="/root/omf_iris/ofdm_rx_usrp_to_file.xml"
}

onEvent(:ALL_UP_AND_INSTALLED){ |event|

        info "Starting an experiment with IRIS components"
        wait 6        
        
        info ("Trying to execute a Quit function for IRIS without it having started. It should raise an exception") 
        group("Usrp").usrpQuit()
        wait 15

        info ("Starting IRIS...") 
        group("Usrp").usrpStart()
        wait 15
        
        info ("Reconfiguring IRIS with a new configuration file..")         
        group("Usrp").usrpReconf("/root/omf_iris/ofdm_rx_usrp_to_file_reconf.xml")
        wait 15
        
        info ("Finally we stop IRIS execution..")
        group("Usrp").usrpQuit()
        wait 15 

        info "End of the Experiment."
        Experiment.done
}

The experiment lifecycle from an administrator's view is:

1. Experiment submitted to the OMF EC. If a device noted as "uX" (eg. u0, u1, etc) is included in the OMF ED, start an FTP service which will serve to the node included in the specific group the IRIS configuration file.

2. The specified resource (omf.nitos.node045 in our example), downloads the file from the FTP server in the /tmp directory. It setups the "eth1" port with an IP address able to communicate with the USRP device.

3. When the GROUP_NAME.usrpStart() command is issued, IRIS will be executed on the node with the following aruments:

 /usr/local/bin/iris -p /usr/local/lib/iris_modules/components/gpp/phy/ -t /usr/local/lib/iris_modules/components/gpp/stack/ -c /usr/local/lib/iris_modules/controllers/ /tmp/iris.xml

where iris.xml is the sample configuration file for IRIS transfered to the node.

4.When the GROUP_NAME.usrpReconf("conf file") command is issued, the node downloads a new configuration file, rewrites the old and sends the Reconfigure command to the IRIS platform.

5. When the  GROUP_NAME.usrpQuit() command is issued, IRIS is terminated.

The experiment illustrated is just a sample experiment that involves only one resource with a USRP.

You can save it in a file (eg. iris.rb) and execute the script from the testbed server with the command:

 omf exec iris.rb 

You can enhance this example by combining multiple IRIS resources and including traffic generators which are already OMF compatible such as iperf.

Software Defined Radio testbed

NITlab developed a software defined radio (SDR) testbed that consists of 18 Universal Software Radio Peripheral (USRP) devices attached to the NITOS wireless nodes. USRPs allow the researcher to program a number of physical layer features (e.g. modulation), thereby enabling dedicated PHY layer or cross-layer research.

sdr arch

More specifically, USRPs connect to a host computer through a high-speed USB or Gigabit Ethernet link, which the host-based software uses to control the USRP hardware and transmit/receive data. Some USRP models also integrate the general functionality of a host computer with an embedded processor that allows the USRP Embedded Series to operate in a standalone fashion.

USRPs are commonly used with the GNU Radio software suite to create complex software-defined radio systems. The USRP product family includes a variety of models that use a similar architecture. A motherboard provides the following subsystems: clock generation and synchronization, FPGA, ADCs, DACs, host processor interface, and power regulation. These are the basic components that are required for baseband processing of signals. A modular front-end, called a daughterboard, is used for analog operations such as up/down-conversion, filtering, and other signal conditioning. This modularity permits the USRP to serve applications that operate between DC and 6 GHz.

In stock configuration the FPGA performs several DSP operations, which ultimately provide translation from real signals in the analog domain to lower-rate, complex, baseband signals in the digital domain. In most use-cases, these complex samples are transferred to/from applications running on a host processor, which perform DSP operations. 

USRP Devices

NITlab has equipped the SDR testbed with 6 USRP1, 4 USRP N210 and 4 USRP B210 devices, placed in such way to cover as much area as possible of the wireless testbed. Details for each device are stated below.

usrp1

USRP1

The USRP1 is the original USRP product and consists of:

  • Four high-speed analog-to-digital converters, each capable of 64 MS/s at a resolution of 12-bit, 85 dB SFDR (AD9862).
  • Four high-speed digital-to-analog converters, each capable of 128 MS/s at a resolution of 14-bit, 83 dB SFDR (AD9862).
  • An Altera Cyclone EP1C12Q240C8 FPGA.
  • A Cypress EZ-USB FX2 High-speed USB 2.0 controller.
  • Four extension sockets (2 TX, 2 RX) in order to connect 2–4 daughterboards.
  • 64 GPIO pins available through four BasicTX/BasicRX daughterboard modules (16 pins each).
  • Up to 8 MHz of RF bandwidth in the receive
usrpn210

USRP N210

USRP N210 is part of the networked series and one of the highest performing class of hardware of Ettus Research. The USRP N210 consists of:

  • A Xilinx Spartan-3A DSP 3400 FPGA
  • Gigabit Ethernet interface
  • Dual 100 MS/s, 14-bit, analog-to-digital converter
  • Dual 400 MS/s, 16-bit, digital-to-analog converter
  • Up to 50 MHz of RF bandwidth in the receive
  • External Inputs for 10 MHz and 1 PPS signals (SMA)
  • Optional GPS Disciplined Oscillator
  • Ettus Research MIMO Cable that can be used to synchronize two USRP devices (sold separately)
  • Support for timed commands and LO alignment with the SBX daughterboard
usrpb210

USRP B210

USRP B210 is part of the bus series and provides a fully integrated, single-board, Universal Software Radio Peripheral (USRP™) platform with continuous frequency coverage from 70 MHz – 6 GHz. The USRP B210 consists of:

  • A Xilinx Spartan-6 XC6SLX150 FPGA
  • USB 3.0 SuperSpeed Interface
  • 61.44 MS/s, 12-bit, analog-to-digital converter
  • 61.44 MS/s, 12-bit, digital-to-analog converter
  • Up to 56 MHz of RF bandwidth in 1x1
  • Up to 30.72 MHz of RF bandwidth in 2x2
  • Frequency range 70 MHz to 6 GHz
  • 2 TX & 2 RX Half or Full Duplex

 

 

RF Daughterboards

NITlab has equipped the USRPs with 2 different daughterboards, the XCVR2450 and the SBX which are the most appropriate for the multiple areas of the research taken place in NITOS testbed (802.11a/b/g/n, LTE, WiMAX, ZigBee). Descriptions for both daughterboards are stated below.

xcvr

XCVR2450 2.4 GHz-2.5 GHz

The XCVR2450 is a high-performance transceiver intended for operation 2.4 GHz and 5.9 GHz range. Filtering on the XCVR2450 provides exceptional selectivity and dynamic range in the intended bands of operation. The typical power output of the XCVR2450 is 100 mW. Example applications include public safety, UNII, ISM, Japanese wireless and UWB development platforms. The XCVR2450 is a half-duplex transceiver.

sbx

SBX 400-4400 MHz Rx/Tx

The SBX is a wide bandwidth transceiver that provides up to 100 mW of output power, and a typical noise figure of 5 dB. The local oscillators for the receive and transmit chains operate independently, which allows dual-band operation. The SBX is MIMO capable, and provides 40 MHz of bandwidth. The SBX is ideal for applications requiring access to a variety of bands in the 400 MHz-4400 MHz range. Example application areas include Wi-Fi, WiMax, S-band transceivers and 2.4 GHz ISM band transceivers.

You can proceed to NITOS Portal for experimentation on SDR resources.

What Our Experimenters Say

  • NITOS is a very reliable and well managed platform. The offered infrastructure and features are great. The management team is very supportive.

    Mustafa Al-Bado
    Postdoctoral researcher
    Insight centre, University College Cork (UCC)
  • 1
  • 2
 
uth
image
image
image
 
 

Login Form