w-iLab.t

w-iLab.t is hosted and operated by IMEC iLab.t and is part of the IDLab Research group.

_static/wilab/overview.png

Introduction

The w-iLab.t (short name: wilab) is an experimental, generic, heterogeneous wireless testbed deployed in the iMinds building and at a second, remote location. w-iLab.t provides a permanent testbed for development and testing of wireless applications via an intuitive web-based interface. w-iLab.t hosts different types of wireless nodes: sensor nodes, Wi-Fi based nodes, sensing platforms, and cognitive radio platforms (that are limited to operating in the ISM bands due to license restrictions.) The wireless nodes are also connected over a wired interface for management purposes. Each of the devices can be fully configured by the experimenters. As the Ethernet interfaces that are put in place for management reasons can also be used during experiments as a wired interface, heterogeneous wireless/wired experiments are possible. As such, a very large number of (wireless) network experiments may be executed. Please click on the thumbnail below to get an overview picture of the hardware available in w-iLab.t.

_images/wilab-Hardwareoverview.png

The two locations that are currently available in the w-iLab.t are:

  • The original “Office” deployment; Nodes (both sensor nodes and embedded PCs with Wi-Fi interfaces) are installed at 200 spots over three floors of an office environment.
  • A new deployment located in Zwijnaarde, nearby Gent, Belgium. All nodes at this location are more powerful in terms of processing power, memory and storage. Nodes are located at 60 spots throughout a utility room.

This documentation is fully aimed at the newer Zwijnaarde testbed, commonly known as Wilab2. At Wilab2, there is almost no external radio interference. Every node-spot is equipped with:

  • 1 embedded PC with 2 Wi-Fi a/b/g/n interfaces and 1 IEEE 802.15.1 (Bluetooth) interface
  • a custom iMinds-Rmoni sensor node with an IEEE 802.15.4 interface
  • an “environment emulator” board (enabling unique features of the testbed including the triggering of repeatable digital or analog I/O events at the sensor nodes, real-time monitoring of the power consumption, and battery usage.

There are two additional possibilities:

  • A number of cognitive radio platforms (including USRPs) as well as specialized spectrum scanning engines are available at this location. This enables state-of-the art research in the field of cognitive radio.
  • 16 mobile robots

The map of the nodes can be found at http://inventory.wilab2.ilabt.iminds.be/.

_images/wilabt.jpg

A short introduction to different possible experiments is presented below.

Sensor node experiments

Registered users can create their own executables, upload these executables, associate those executables with a selection of sensor nodes (this process is called “creating a job”), and schedule the job to be run on wilab. During the job, measurements and management data is logged to a database. This info is presented to the user upon job completion and may then be used for processing and visualization. In addition, real-time visualization tools are provided which make it possible to follow the state of the testbed and the experiment, while a job is still running. As such, w-iLab.t facilitates research in sensor network programming environments, communication protocols, system design, and applications.

Wi-Fi experiments + embedded PC’s

Experimenters can also fully control the embedded PC’s that are available. The embedded PCs run a Linux distribution and are equipped with two Atheros based Wi-Fi interfaces. These Wi-Fi interfaces may or may not be used during experiments. It is up to the user to define the behavior of the embedded PCs by installing software and/or scripts on the nodes. As such, the embedded PCs can be used for a very broad set of experiments. Just to give a few examples, it is possible to:

  • enable a single wireless interface; configure it as an access point -> use of the embedded PC as an access point
  • enable two wireless interfaces in ad-hoc mode -> use of the embedded PC als a two-interfaced Wi-Fi ad-hoc node
  • install any type of software on the node: e.g. a webserver, a spectrum database, an aggregator node, ...

An experimenter can access the embedded PCs individually via SSH, or distribute software/drivers/kernels/scripts/... to multiple nodes at once, by using the web-based testbed interface. During the experiments, a directory on a w-iLab.t storage server is mounted automatically for logging purposes. Alternatively, experimenters may log information to their own storage servers, or store information to a database.

The default image of the embedded PCs in the office environment comes with the Madwifi wireless driver preinstalled. Experimenters may install their own drivers and protocols to the embedded PCs. As a general rule: everything you are able to do with an embedded PC with Atheros Wi-Fi cards on your own desktop, can also be implemented on a large scale in the testbed.

At the Zwijnaarde location, USB Bluetooth interfaces are also plugged in to the embedded PCs. Please check the hardware overview picture above to know what is connected to the embedded PCs at which location.

Cognitive networking platforms

At the Zwijnaarde location, a set of cognitive networking platforms are available. They can be remotely accessed over the internet. For information on which cognitive devices are available, please check the hardware overview image on top of this page. Again, it is up to the experimenters to decide how to use the hardware that is made available. Signals may only be transmitted in the 2.4 GHz and 5 GHz ISM band due to license restrictions.

System & Network Architecture

The w-iLab.2 network is split in two parts: the control network and the experiment network:

  • Control network: takes care of DHCP, PXE, TFTP, Frisbee (image loading), NFS (mounting of user home dirs) and SSH (IPv4 over VPN connection or public IPv6).
  • Experiment network: lets the experimenter configure its own network composed of servers, DSS-nodes or cognitive radio equipment (any device where no OS is loaded by Emulab, but has an Ethernet interface).

The w-iLab.t testbed is managed by a combination of frameworks & libraries:

  • Emulab : This is the core testbed management software. Emulab implements DHCP, PXE network booting, loading of OS images, user accounts (incl. keys, certificates), NFS mounted home directories, experiment topology design, ... See Emulab.net for more information.
  • OMF : This framework takes care of controlling the experiment flow (start applications, bring up WiFi interfaces, run scripts at pre-defined time stamps). See the OMF home page for more information.
  • OML : Uniform way of collecting measurement data. See the OML home page for more information.

The Emulab deployment at w-iLab.2 consist of two servers:

  • BOSS : The ‘master’ server that hosts the webinterface (http://wilab2.ilabt.iminds.be) and takes care of critical testbed functionality like DHCP, PXE, image loading, user accounting, experiment design, ....
  • OPS : The file server (NFS). Every user can SSH to this server: ops.wilab2.ilabt.iminds.be . The home directory of every user is mounted on the testbed nodes when an experiment is started. Other testbed users cannot access your files, unless they are in the same project as you.
_images/emulabWilab.jpg

On some devices, it is not needed to reload an operating system after every experiment run. These devices are typically non-linux type of devices like the USRP’s, WARP’s or LTE femto cells. They cannot be accessed directly over the control network, but have to be used in an experiment. Since some devices have more than one network interface, like the DSS nodes and the servers, experimenters can use this interface to connect with devices over the experiment network. This is done by drawing a link between e.g. a server and a USRP in the experiment design tool.

_images/emulabWilabExpNetwork.jpg

Some extra servers are needed to support the OMF/OML framework/library:

  • Aggregate Manager: this server functionality has been replaced by the Emulab framework in the w-iLab.2 setup.
  • XMPP/AMQP server: ensures the transportation of the OMF control messages (e.g. start application X now on resource Y).
  • Experiment Controller: the experiment can SSH to this server (ec.wilab2.ilabt.iminds.be). The home directory is also mounted on this machine. This server is used to start the OMF experiments.
  • Resource controller (daemon on the testbed resource): Takes orders from the Experiment Controller to control the resource (e.g. bring up the WiFi interface).
  • OML server: database server where the OML client library can dump its data to. It is also possible to deploy your own OML server if your measurements are confidential.
_images/emulabOMF.jpg

w-iLab.1 Setup

This testbed is currently under development, so check back here regularly for updates.

The w-iLab.1 testbed is split into two entities:

  • 44 testbed nodes are mounted to the ceiling of the datacenter of the iGent building (in Ghent): a 30m by 10m room in a grid configuration with dx = 2.5 meter and dy = 2 meter. The 44 installed nodes can be seen on the inventory.
  • IoT Officelab (Coming Soon): 120 testbed nodes installed on three floors in the iGent building.

Inventory

The inventory is located at http://boss.wilab1.ilabt.iminds.be/inventory . This tool can help you find out the exact location of the nodes and their configuration.

You can use the filter function to look for nodes with specific extensions (e.g. with webcams, with WiSpy, with a certain WiFi mac address).

_images/inventory_webcams.png

Node configuration

The w-iLab.1 testbed has currently only one node type where the experimenter can deploy an operating system of choice:

  • NUC : 44 wireless nodes (nucX-Y)

X = floor of iGent building, Y = nuc numbering per floor

Feature NUC D54250WYKH
CPU type Intel Atom D525 (2cores, 1.8GHz)
RAM (GB) 8GB DDR3 1600MHz
Hard disk 320GB (2.5", SATA 6Gb/s, 7200RPM, 16MB)
WiFi 1x802.11abgn+BT, 1x802.11ac
Sensor node Yepkit USB hub + Zolertia Re-Mote
Bluetooth Bluetooth 4.0 LE/3.0 HS/2.1 EDR (on 802.11n WiFi card)
  • Details on the 802.11abgn+BT interfaces:
  • Details on the 802.11ac Wifi interfaces (second WiFi card):
    • Compex WLE900VX / 802.11ac/n/b/g 3x3 MIMO / PCI-Express Full-Size MiniCard: Qualcomm Atheros QCA9880
    • To each Wi-Fi card, three antennas are connected (3x3 MIMO is supported).
    • Recommended driver: ath10k
  • Power control of the NUC nodes is done using Power-Over-Ethernet.

Some nodes have extra USB extensions, like sensor nodes. Use the inventory to look for specific devices.

_static/wilab/wilab1nuc.png

Zolertia Re-Mote Sensor

_static/wilab/remote-nuc.png

Some nodes are equipped with one or more Zolertia Re-Mote sensor nodes. The RE-Mote is based on the CC2538 ARM Cortex-M3 with a robust 2.4Ghz IEEE 802.15.4 radio, running up to 32MHz with 512KB of programable flash and 32KB of RAM, bundled with a CC1200 868/915Mhz RF transceiver. The RE-mote features a built-in TMP102 temperature sensor, microSD over SPI, battery charger and management (BQ24075) with an input range of 2 to 26VDC.

More info can be found here: http://zolertia.io/product/hardware/re-mote

Officelab

_static/wilab/igent.png

In the iGent building, three floors of the building will be transformed into a real-life office lab environment (floor 9-10-11). Wireless and wired sensor technology will be deployed to demonstrate tomorrow’s smart office applications optimizing work spaces, visitor’s experiences, workers’ comfort, etc. In total, 120 nodes will be deployed.

Example floor plan for floor 10. Red dots represent node locations. Detailed node configuration.

_static/wilab/floor10.png

Getting started

As opposed to the w-iLab.2 testbed, no reservation is required at this moment to use nodes in the w-iLab.1 testbed. Please swap-out experiments as soon as you don’t need the hardware anymore.

Follow these steps to run an experiment on w-iLab.1 :

  • Request an account at https://authority.ilabt.iminds.be/signup.php and download your certificate as PEM file.
  • Install jFed <http://jfed.iminds.be/downloads>
  • Start up jFed and login through the iLab.t Authority
  • Activate all proxies in the jFed preferences.
  • Click New, drag some Wireless nodes onto the canvas and right click them to select the Wilab1 testbed.
  • Click Run and give your experiment a name.
  • Double click the nodes and you should have SSH access on the nodes.

See the other w-iLab.t tutorials for more info on using the wireless interfaces.

w-iLab.2 Setup

User of the new jFed GUI :

(DEPRECATED!!) Users of the OLD Emulab interface :

Map

The nodes in the testbed are mounted in 66m by 20.5m open room in a grid configuration with dx = 6 meter and dy=3.6 meter. The 60 installed nodes are represented by the blue locations on the picture. The green and orange location are used to connect the mobile nodes, the SDRs (USRP, WARP,...), the LTE femto cells and the IP cameras.

_images/map.jpg

Inventory

The inventory is located at http://inventory.wilab2.ilabt.iminds.be . This tool can help you find out the exact location of the nodes and their configuration. The page also offers some filters to make it easier to search for suitable nodes for your experiment.

Different colors represent different node types.

_images/inventory.png

You can use the filter function to look for nodes with specific extensions (e.g. with webcams, with WiSpy, with a certain WiFi mac address).

_images/inventory_webcams.png

Zoom in to get a better view on nodes that are close together.

Node configuration

The w-iLab.2 testbed has 7 different node types where the experimenter can deploy an operating system of choice:

  • ZOTAC : 48 wireless nodes (zotacXY)
  • APU : 40 wireless nodes with 2 Gigabit experimental network interfaces (apuXY)
  • DSS : 10 wireless nodes (dssXY)
  • MOBILE : 15 mobile wireless nodes (mobile1 to mobile15)
  • SERVER5P : 6 servers with 5 experimental network interfaces (server1 to server6)
  • SERVER1P : 2 servers with 1 experimental network interface (server7 and server8)
  • SERVER1G2X : 7 servers with 2 10G experimental network interfaces (server9 to server15)

X = column letter, Y = row number

Feature ZOTAC (specs) APU 1d4 (specs) DSS/MOBILE (specs) SERVER1P/SERVER5P (specs) SERVER1G2X (specs)
CPU type Intel Atom D525 (2cores, 1.8GHz) AMD G series T40E APU (2cores, 1GHz) Intel core i5 8x dual Intel Xeon Processor 5600 Series Intel Xeon Processor D-1541 (2.1GHz, 8 cores, 16 threads)
RAM (GB) 4GB DDR2 800MHz PC2-6400 CL6 4GB DDR3 1066MHz 4GB DDR2 800MHz PC2-6400 CL6 12GB DDR2 800MHz PC2-6400 CL6 16GB DDR4 2133MHz
Hard disk 160GB (2.5", SATA, 7200RPM, 16MB) 32GB (SSD,mSATA) 60GB (2.5", SATA, SSD) 160GB (2.5", SATA, 7200RPM, 16MB) 500GB (3.5", SATA, 7200RPM, 64MB)
WiFi 2x802.11abgn 2x802.11ac 1x802.11abgn, 1x802.11ac No WiFi cards/dongles No WiFi cards/dongles
Sensor node EE + RM090 Coming soon... EE + RM090 No EE/sensor node No EE/sensor node
Bluetooth USB 2.0 Bluetooth (Micro CI2-v3.0 EDR) No Bluetooth USB 2.0 Bluetooth (Micro CI2-v3.0 EDR) No Bluetooth No Bluetooth
  • Details on the 802.11abgn Wifi interfaces:
    • Sparklan WPEA-110N/E/11n mini PCIe 2T2R chipset: AR9280

    • To each Wi-Fi card, two antennas are connected (2x2 MIMO is supported).

    • 2 x 2 Attenuator 20 dB (one attenuator between each Wi-Fi output and each antenna):
      • Telegärtner J01156R0041; R-SMA (m-f) 0-6GHz 50Ohm 2W
    • Recommended driver: ath9k

  • Details on the 802.11ac Wifi interfaces (second WiFi card on DSS and MOBILE nodes):
    • Compex WLE900VX / 802.11ac/n/b/g 3x3 MIMO / PCI-Express Full-Size MiniCard: Qualcomm Atheros QCA9880
    • To each Wi-Fi card, three antennas are connected (3x3 MIMO is supported).
    • Recommended driver: ath10k
  • Power control of the ZOTAC and DSS nodes is done using Power Distribution Units (PDU).

Some nodes have extra USB extensions, like cognitive radio devices. Use the inventory to look for specific devices.

Other devices are only accessible over the experiment network and can thus only be accessed by swapping in a device with an experiment network interface (SERVER1P, SERVER5P, DSS). These devices are:

  • USRP devices (see chapter below)
  • WARP devices (see chapter below)
  • ALIX devices (devices with 500MHz CPU, 256MB RAM, 4G compact flash card, Broadcom wireless chipset, see the tutorial below)

RM090 Sensor node specs

The RM090 sensor node is a joint design by Rmoni and iMinds. The major reason for iMinds to create a new sensor node was of the lack of sufficient resources on the TMote Sky (see table). Especially the 48k of flash on the TMote was the enabler to upgrade the testbed.

Feature Imote (2003) Mica2 (2003) MicaZ (2004) Telos (2005)

IBBT-Rmoni RM090 (2010)

CPU type @[MHz] 32bit ARM @12 8bit Atmel @8 8bit Atmel @8 16bit TI @8 16bit TI @18MHz
SRAM [kB] 64 4 4 10 16
FLASH [kB] 512 128 + 512 128 + 512 48 KB / 1024 KB 256 KB/128 KB + 16KB eeprom
Radio BT 300-900MHz 802.15.4 802.15.4 802.15.4 2.4GHz band
Bandwidth [kb/s] 720 15 250 250 250
Carrier Sense/ Rx/Tx Current [mA] 15 / 24 / 24 08/10/27 08/20/18 01/20/18 18.5 /18.5 / 33.6@4dBm 25.8@0dBm
sleep current
[uA]
01/01/50 19 27 6 2
OS support TinyOS TinyOS TinyOS TinyOS TinyOS or IDRA

We tried to be as compliant as possible with the TMote Sky with the second generation chips of TI the msp430f5437 and the CC2520. The IDC headers, the 3 leds, the USB interface are as much compliant as possible.

Here you can find a block diagram of the RM090:

_images/rm090block.png

Environment emulator description

The Environment Emulator (EnvEmu, or EE) is located in between the embedded PC and the RM090 (or Zolertia) sensor nodes. It opens up a lot of real-life test cases, of which the major ones are described below:

  • The EE can disconnect the USB power from the DUT, and power it with its own regulating voltage source. This enables the EE to emulate the real behavior of a battery depleting, energy harvesting power sources, failing of the mote, ...
  • The current used by the DUT can be measured with a sample frequency of 10kHz. Using this approach, it is very easy to determine the exact power consumption when it is running the current application, protocol, ...
  • The EE has some General Purpose digital Input / Output pins connected to the DUT. This allows for real-life, real- time digital sensor / actuator emulation. These pins can also be used to tag specific states generated by the DUT to ease the analysis and classification of the power consumption.
  • Some analogue input/output pins are also connected to the DUT, making the emulation of real-life, real-time analogue sensors/actuators possible.
  • Audio input/output signals can be injected and extracted from the embedded PC to the DUT making all sorts of audio over sensor network experiments very easy to conduct.
  • The EE can be used as an energy harvester.The EE can disconnect the USB power of the device under test (DUT) and can alternatively power the DUT via its battery interface with a variable voltage supply. By measuring the current at a high sample rate and use this information to control the voltage supply we can build a controlled loop feedback mechanism. To emulate the real behavior of an energy harvester we implemented the law of Coulomb as a feedback mechanism. Furthermore as we are at all times aware of the consumed current by the DUT (sample rate of 4 kHz) and the tuned voltage we can determine the exact power consumption (more details below).

All of this can be prepared before running an experiment or can be adjusted real time during the experiment by using an OMF experiment description.

If you take a closer look to the block diagram of the EnvEmu you will notice that is based on TMote Sky. We stripped down the TMote Sky by removing the sensors, leds, buttons, radio, I2C msp flash lock circuit and also flash. So basically we stripped it down to ftdi, msp430, IDC header and radio interface. We added a 3ports USB hub, 2 USB switches that are connected to slave female USB connectors, 7 segment display, battery emulator and audio jacks. See the block diagram below.

_images/blockDiagramEE.jpg

Both the front an the back view of the board can be found here:

_images/EE_back.gif _images/EE_front.gif

Here you can find the detailed electronic circuit of the battery emulator.

_images/EE_BE.png

The electronic diagram can be downloaded here.

A new sensor board was created, which is basically a stripped version of the TMote Sky and we called it the Environment Emulator (EE). On the EE we connected VDD (schematic) to the USB power of the board. The ADC and DAC lines (schematic) are connected to DAC1 and ADC4 of an MSP430. The DUT lines are then interfaced to the battery interface of the device under test. Implementing just the schematics as it is and connect it to an existing tmote or telosb gives the same functionality. The main component in the schematic is U1 which is a rail-to-rail, high output current amplifier. U1a is used to implement a voltage follower and maps the 2.5 V coming from the DAC (maximum output of DAC1 of the MSP430) to 3.5V (the maximum supply voltage of the DUT). Standard op amp schematics are not able to drive high capacitive loads . C1 and R10 were added in the second version of the EE and are used as inner and outer loop compensations for a better response when driving high capacitive loads. 10uF is a typical input capacitor of an sensor node and is much higher than what an opamp (typical 200pF) can drive without compensations. U1b is used to implement a differential amplifier and maps a current of 70mA trough R4 and R5 to 2.5V on the input of the ADC (the maximum input voltage of ADC4 of the MSP430). To implement the law of Coulomb a tinyos application was developed where we implemented an user event ‘stream’ with these parameters; start value which is the DAC value at t0, virtual capacitor and the harvester itself. When executed a continuous sampler will start on ADC4 with a sample rate of 250us. On every sampler buffer done event the next Dac value will be calculated as follows (sampler buffer size is 50):

DacValue(t+1) = DacValue(t) + SUM ( harvester - samplerBuffer(t)[i] ) / virtualCapacitor.

The unit of the virtualCapacitor is 5uF and is derived from the interSampleDelay/numberOfSamplesPerBuffer. For example; for a battery emulation of 2.4V/3000mAh, we could define a full battery with initial voltage of 2824 (2.400 V) and a harvester which is equal to zero and a capacitor of 4500 F or the virtualCapacitor equal to 1.25 x 60 (min) x 60 (s) x 200k. For solar cell emulation, we could define a capacitor with initial voltage of 0 V and a harvester which is equal to 1mA (59) and a capacitor of 1F. On the DUT the first thing to do is to check if there is enough energy and if there is the radio can be enabled. The other way around would put the sensornode in an endless reboot sequence. For now with a interSampleDelay of 250uS will get a reaction time of 50 samples x 250 us which makes 12,5 ms. We will speed this up in the near future.

_images/EEs.jpg

Some EE related publications:

    1. Moerman B. Jooris P. De Mil T. Allemeersch L. Tytgat P. Demeester, “WiLab: a large-scale real-life wireless test environment at IBBT”, published in Proceedings of DSP Valley seminar “Sensor driven state-of-the-art Mechatronics”, Anderlecht, Belgium, 20 February 2008
    1. Tytgat B. Jooris P. De Mil B. Latre I. Moerman P. Demeester, “Demo abstract: WiLab, a real-life wireless sensor testbed with environment emulation”, published in European conference on Wireless Sensor Networks, EWSN adjunct poster proceedings (EWSN), Cork, Ireland, 11-13 February 2009
    1. De Mil, B. Jooris, L. Tytgat, et al., “Design and Implementation of a Generic Energy-Harvesting Framework Applied to the Evaluation of a Large-Scale Electronic Shelf-Labeling Wireless Sensor Network,” EURASIP Journal on Wireless Communications and Networking, vol. 2010, Article ID 343690, 12 pages, 2010. doi:10.1155/2010/343690

Cognitive components & spectrum scanning

A number of cognitive radio hardware devices are available in the w-iLab.2 testbed. Some of the devices are available via a remote connection to w-iLab.2.

As with the other hardware and tools in w-iLab.2, it is up to the experimenters to decide how to use the hardware that is made available. Signals may only be transmitted in the 2.4 GHz and 5 GHz ISM band due to license restrictions.

Check out the inventory to see which devices are installed where.

Also check out spectro, a web page that continuously visualises the spectrum in the testlab.

USRP family

!!!! ALL USRPs are now statically wired to powerful servers. Do NOT draw any links in jFed for the USRPs. (Reserving and selecting in jFed is still needed) !!!!

There are 6 USRP N210 devices installed in the w-iLab.2 testbed, which can respectively be controlled by server9, 10, 11, 13, 15 and 16. There is a one-to-one mapping of USRP to SERVER. All nodes (zotac, server, DSS) are connected over the control network to the OMF Experiment Controller where you can control your experiment via the OMF framework and collect results.

The USRP N210 devices are currently configured with the UHD_003.009.002 image and an XCVR2450 daughter board. If needed, other daughter boards can be installed. The IP addresses of the USRP’s are listed on http://inventory.wilab2.ilabt.iminds.be . The USRP devices can also be rebooted on the inventory page.

The default image for the servers has GNURadio version 3.7.9 installed.

The USRP devices have to be reserved on the reservation page before they can be used in an experiment.

_images/usrp2.png

WARP family

Details on the WARP MIMO Kit v2 can be found here. The setup in w-iLab.2 consists of:

  • WARP FPGA Board v2.2
  • WARP Clock Board v1.1
  • One WARP Radio Board v1.4

There are 3 WARP devices installed in w-iLab.2. They are connected over USB to zotacF3, zotacG3 and zotacH3 (verify on the inventory).

Next to the USB connection, the warp devices also have an Ethernet interface that is patched to the experiment switch and therefore can be connected to an experiment interface on one of the servers. The WARP devices have to be reserved on the reservation page before they can be used in an experiment.

_images/warp.jpg _images/warp_deployment.jpg

imec SE

The imec sensing engine is a prototype implementation of a sensing engine for mobile communication devices. The prototype consists of two main blocks: an analog RF front-end including analog to digital conversion and a DIgital Front-end For Sensing (DIFFS). For permanent deployment in the w-iLab.2 testbed a WARP board is selected as analog RF front-end, covering the 2.4 and 5 GHz ISM bands. An in house developed flexibele SCAlable raDIO (SCALDIO) is also tested in a lab environment, covering an RF input range from 0.1 up to 6 GHz and a channel bandwidth up to 40 MHz. The digital front-end is an ASIP specifically designed for sensing operations, signal conditioning and synchronization. The chip contains a flexible filter block, including re-sampling and a SIMD core, extended with multiple accelerator cores. Multiple sensing algorithms are implemented on the system, ranging from straight-forward energy detection schemes, over more complex feature detection (for e.g. DVB-T) to multiband energy detection after FFT leakage removal for OFDMA LTE signals.

The imec sensing engines in w-iLab.2 are connected as USB devices to some of the wireless nodes. Four nodes have an imec SE attached with WARP_FE (zotacC2, zotacF4, zotacJ2 and dssJ5), two nodes have an imec SE attached with SCALDIO_FE (zotacJ3 and zotacJ4).

The imec SE devices cannot be reserved or swapped in through the webinterface. If you want to use these devices, it is sufficient to reserve the wireless nodes where the SE’s are connected to.

_images/imecSE.png _images/imecSE_deployment.jpg

Wi-Spy

The Wi-Spy is a commercially available USB dongle that allows you to do spectrum scanning on 2.4 and 5GHz. Check out the Wi-Spy home page for more details.

There are currently 3 Wi-Spy devices deployed in w-iLab.2 as USB extensions to some of the wireless nodes: zotacC3, zotacF4 and dssJ5. Please verify on the inventory that these locations are still accurate. The Wi-Spy devices cannot be reserved or swapped in through the webinterface. If you want to use these devices, it is sufficient to reserve the wireless nodes where the Wi-Spy’s are connected to.

_images/wispy.jpg

Mobility extension

Some nodes in w-iLab.2 are of type MOBILE. These nodes can be used in the same way as the other testbed nodes, while having the extra capability of moving across the testbed floor during the experiment.

The figure below shows the different components of the real life mobility toolkit. The left side of the figure depicts the simplified architecture of an existing testbed, whereas the right side of the figure shows the blocks which are needed to enable mobility in the testbed. The goal of the mobility extension is to enable the use of mobile nodes in the testbed. Therefore, the components that are needed to control the mobility extension are shown as transparent, and are also transparent for the experimenter.

_images/genericmobility.png

The figure below shows the architecture of the mobility toolkit specific for the iMinds w-iLab.t deployment, with focus on the management side:

  • The users connect to the framework via a REST-service (made userfriendly through a webgui: RobotDashboard).
  • The REST-service (RobotControl) is a central entity through which every command is validated and that distributes the commands among the RobotAP’s, so the LPE (Localisation and Positioning Engine) on the robot knows what to do.
  • RobotControl can also be approched via OMF-scripts and talks to Emulab to enable authentication.
_images/imindsmobility.png

The next scheme details the framework on the robot end:

  • When the robot is docked, an ethernet connection to the mobile node is provided.
  • When the robot is driving, it has no connection to the management network by default. Docking re-enables the ethernet interface automatically.
_images/detailedmobility.png

Qosmotec platform

The qosmotec boxes are useful for doing wireless experiments in a controlled environment (i.e.: no outside interference, controllable attenuation, controllable topology).

LTE equipment

Overview

The W-iLab.t testbed offers various ways of LTE experimentation. Currently, the testbed provides two (2) different fully operational LTE networks. The one has been deployed in the IBCN’s premices in Zwijnaarde (W.iLab.t LTE testbed deployment) and the other has been deployed in fully shielded (RF-isolated) boxes (Qosmotec LTE deployment).

SiRRAN EPC

The SiRRAN EPC is available as a preconfigured image. The name of the image is SIRRAN_EPC_v1_7_50 and can be reached via the following public urn:
This image can be loaded in one of the available servers of the testbed (SERVER5P 1-6 and SERVER1P 7-8).

Important notes:

  • Only one instance of the EPC server can run each time, as only one licence can be enabled at any given time.
  • To enable the license, the eth1 interface of the server hosting the EPC image must be up and configured. In case that more than one experiment interfaces are available (e.g. the SERVER5P servers offer 5 experiment interfaces) the one that will be used is randomly selected.
  • If the eth1 interface is not the one which is randomly selected, then it should be brought up. Use the ifconfig command to verify the selected interface. Assuming that the eth3 is randomly selected, then the following commands should be issued:
sudo su
ifconfig eth3 192.168.1.X // X must be an unused address different that 1. The eth3 must remain up due to compatibility issues with JFED
ifconfig eth1 192.168.1.1 up
sudo /etc/init.d/ltenet restart
  • Alternatively, a “temporary server” can be used to create links with all the available experiment interfaces of the EPC node.
  • In JFED, multiple links between the EPC server and the temporary server can be drawn. The rspec example bellow creates 5 links between the 5 available interfaces of server4 (to be used as EPC server) and server5 (to be used as temporary server). As can be seen the eth1 interface of server4 has been set to the desirable IPv4 (192.168.1.1) for the EPC. Different IPs can be assigned to all the other interfaces of server4 and the temporary server.
<?xml version='1.0'?>
<rspec xmlns="http://www.geni.net/resources/rspec/3" type="request" generated_by="jFed RSpec Editor" generated="2016-06-27T10:46:14.193+02:00" xmlns:emulab="http://www.protogeni.net/resources/rspec/ext/emulab/1" xmlns:jfedBonfire="http://jfed.iminds.be/rspec/ext/jfed-bonfire/1" xmlns:delay="http://www.protogeni.net/resources/rspec/ext/delay/1" xmlns:jfed-command="http://jfed.iminds.be/rspec/ext/jfed-command/1" xmlns:client="http://www.protogeni.net/resources/rspec/ext/client/1" xmlns:jfed-ssh-keys="http://jfed.iminds.be/rspec/ext/jfed-ssh-keys/1" xmlns:jfed="http://jfed.iminds.be/rspec/ext/jfed/1" xmlns:sharedvlan="http://www.protogeni.net/resources/rspec/ext/shared-vlan/1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.geni.net/resources/rspec/3 http://www.geni.net/resources/rspec/3/request.xsd ">
  <node client_id="Server4" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+server4">
    <sliver_type name="raw-pc"/>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="117.0" y="195.5"/>
    <interface client_id="Server4:if0">
      <ip address="192.168.1.1" netmask="255.255.255.0" type="ipv4"/>
    </interface>
    <interface client_id="Server4:if1">
      <ip address="192.168.2.2" netmask="255.255.255.0" type="ipv4"/>
    </interface>
    <interface client_id="Server4:if2">
      <ip address="192.168.3.3" netmask="255.255.255.0" type="ipv4"/>
    </interface>
    <interface client_id="Server4:if3">
      <ip address="192.168.4.4" netmask="255.255.255.0" type="ipv4"/>
    </interface>
    <interface client_id="Server4:if4">
      <ip address="192.168.5.5" netmask="255.255.255.0" type="ipv4"/>
    </interface>
  </node>
  <node client_id="Server5" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+server5">
    <sliver_type name="raw-pc"/>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="379.5" y="191.5"/>
    <interface client_id="Server5:if0">
      <ip address="192.168.14.2" netmask="255.255.255.0" type="ipv4"/>
    </interface>
    <interface client_id="Server5:if1">
      <ip address="192.168.15.2" netmask="255.255.255.0" type="ipv4"/>
    </interface>
    <interface client_id="Server5:if2">
      <ip address="192.168.16.2" netmask="255.255.255.0" type="ipv4"/>
    </interface>
    <interface client_id="Server5:if3">
      <ip address="192.168.17.2" netmask="255.255.255.0" type="ipv4"/>
    </interface>
    <interface client_id="Server5:if4">
      <ip address="192.168.18.2" netmask="255.255.255.0" type="ipv4"/>
    </interface>
  </node>
  <link client_id="link0">
    <component_manager name="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm"/>
    <interface_ref client_id="Server4:if0"/>
    <interface_ref client_id="Server5:if0"/>
    <link_type name="lan"/>
  </link>
  <link client_id="link1">
    <component_manager name="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm"/>
    <interface_ref client_id="Server4:if1"/>
    <interface_ref client_id="Server5:if1"/>
    <link_type name="lan"/>
  </link>
  <link client_id="link2">
    <component_manager name="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm"/>
    <interface_ref client_id="Server4:if2"/>
    <interface_ref client_id="Server5:if2"/>
    <link_type name="lan"/>
  </link>
  <link client_id="link3">
    <component_manager name="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm"/>
    <interface_ref client_id="Server4:if3"/>
    <interface_ref client_id="Server5:if3"/>
    <link_type name="lan"/>
  </link>
  <link client_id="link4">
    <component_manager name="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm"/>
    <interface_ref client_id="Server4:if4"/>
    <interface_ref client_id="Server5:if4"/>
    <link_type name="lan"/>
  </link>
</rspec>

  • In Emulab, the following model NS file that can be used when a SERVER5P is selected to host the EPC image. In this example, server4 hosts the SiRRAN EPC, while server5 is used as a “temporary server” to create links with all the available experiment interfaces of server4.
# Generated by NetlabClient
set ns [new Simulator]
source tb_compat.tcl

# Nodes

# Femtocell 1
set lte1 [$ns node]
$lte1 add-desire LTE-FEMTOCELL 1.0

tb-fix-node $lte1 ltefemtocell1

# Femtocell 2
set lte2 [$ns node]
$lte2 add-desire LTE-FEMTOCELL 1.0
tb-fix-node $lte2 ltefemtocell2

# Node 4 - SiRRAN EPC
set serv4 [$ns node]
$serv4 add-desire SERVER1P 1.0
tb-fix-node $serv4 server4
tb-set-node-os $serv4 #urn_of_the_EPC_image_goes_here

# Temporary server to set link with the eth1 interface of server 6
 set tempserv [$ns node]
 $tempserv add-desire SERVER5P 1.0
 tb-fix-node $tempserv server5

# Lans
set lan0 [$ns make-lan "$serv4 $tempserv" 1000000.0kb 0.0ms]
set lan1 [$ns make-lan "$serv4 $tempserv" 1000000.0kb 0.0ms]
set lan2 [$ns make-lan "$serv4 $tempserv" 1000000.0kb 0.0ms]
set lan3 [$ns make-lan "$serv4 $tempserv" 1000000.0kb 0.0ms]
set lan4 [$ns make-lan "$serv4 $tempserv" 1000000.0kb 0.0ms]

set lan0 [$ns make-lan "$lte1 $lte2 $serv4" 1000000.0kb 0.0ms]

tb-set-ip-lan $serv6 $lan0 192.168.1.1
tb-set-ip-lan $serv6 $lan1 192.168.2.2
tb-set-ip-lan $serv6 $lan2 192.168.3.3
tb-set-ip-lan $serv6 $lan3 192.168.4.4
tb-set-ip-lan $serv6 $lan4 192.168.5.5

$ns rtproto Static
$ns run

# NetlabClient generated file ends here.
# Finished at: 3/18/14 4:08 PM
SiRRAN EPC comes together with a web GUI that offers an easy way to configure the EPC parameters.
The web interface of SiRRAN EPC can be accessed from a web browser using the control IP of the server.
To login you can use the following credentials:
  • Username: operator
  • Password: 0Perato$

The next figure depitcs the SiRRAN EPC web GUI.

_images/epc_web_gui.jpg

ip.access femtocell

IBCN provides a commercial LTE Access Network, which comprises of four (4) femtocells (LTE 245F) provided by ip.access. These femtocells can be configured in two LTE spectrum bands (7 and 13). Test frequencies in the licensed LTE band 7, are assigned by the Belgian Institute for Postal services and Telecommunications (BIPT), to be used for experimental purposes. Hence, the femtocells are configured to operate in that band.

1st femtocell

  • eth0 IP: 192.168.2.10
  • eth1 IP: 192.168.1.10
  • eth0 Bcast: 192.168.2.255
  • eth1 Bcast: 192.168.1.255
  • Mask: 255.255.255.0
  • Cell Identity: 2055

2nd femtocell

  • eth0 IP: 192.168.2.11
  • eth1 IP: 192.168.1.11
  • eth0 Bcast: 192.168.2.255
  • eth1 Bcast: 192.168.1.255
  • Mask: 255.255.255.0
  • Cell Identity: 2056

3th femtocell

  • eth0 IP: 192.168.2.12
  • eth1 IP: 192.168.1.12
  • eth0 Bcast: 192.168.2.255
  • eth1 Bcast: 192.168.1.255
  • Mask: 255.255.255.0
  • Cell Identity: 2057

4th femtocell

  • eth0 IP: 192.168.2.13
  • eth1 IP: 192.168.1.13
  • eth0 Bcast: 192.168.2.255
  • eth1 Bcast: 192.168.1.255
  • Mask: 255.255.255.0
  • Cell Identity: 2058

Huawei E398u1 LTE USB Dongle UE

W-iLab.t has been equipped with 25 commercial LTE dongles by Huawei to be used as LTE UE (User Equipment). Some of these dongles are mounted on each mobile Zotac node, which is attached on a Roomba robot, in order to provide the required controlled mobility experimentation. In addition, some extra dongles are mounted on static Zotac nodes. All the UEs are 100% unlocked for worldwide use and can be fully configured via AT commands (see section 2.3.2). The dongles are compatible with the LTE FDD band 7 and are interoperable with the deployed LTE network. The obtained dongles are the Huawei E398u-1 4G LTE USB Modems. Huawei E398u-1 modem is a fast speed (Download up to 100 Mbps - Upload up to 50 Mbps) LTE card. It is a triple-mode LTE modem that enables seamlessly switching between 2G GSM/GPRS/EDGE (850/900/1800/1900 MHz), 3G UMTS (900/2100 MHz) and 4G LTE FDD (900/1800/2100/2600 MHz).

_images/dongle.jpg

The following table summarizes the specifications of the LTE dongles.

Huawei E398u-1 LTE USB Modem specifications
LTE Dongle Available Dongles Technical Specifications
Huawei E398u-1 25 Dongle
    4G Frequency: LTE FDD 900 / 1800 / 2100 / 2600 MHz
    3G Frequency: UMTS 900 / 2100 Mhz
    2G Frequency: GSM / GPRS / EDGE - 850 / 900 / 1800 / 1900 Mhz
    LTE download Speed up to 100 Mbit/s
    LTE upload Speed up to 50 Mbit/s
    LTE 2x2 MIMO
    Antenna: Integral antenna. 2X External antenna interface
    Memory: Micro SD card slot up to 32GB
    Display: LED Indicator
    Size: 90 x 25 x 15mm
    Weight: 40g

The table below presents the USIM card’s IMSI number and the corresponding UE’s IMEI for each node equipped with an LTE dongle.

USIM card’s IMSI on each node
ID IMSI Node UE type IMEI
1 223451234567880 Node 38 (Zotac G4) Dongle Huawei E398u1 N/A
2 223451234567881 Robot 2 Dongle Huawei E398u1 N/A
3 223451234567882 Node 42 (Zotac K4) Dongle Huawei E398u1 N/A
4 223451234567883 Robot 4 Dongle Huawei E398u1 N/A
5 223451234567884 Node 33 (Zotac B4) Dongle Huawei E398u1 N/A
6 223451234567885 Robot 6 Dongle Huawei E398u1 N/A
7 223451234567886 Node 57 (Zotac H6) Dongle Huawei E398u1 N/A
8 223451234567887 Robot 8 Dongle Huawei E398u1 N/A
9 223451234567888 Node 5 (Zotac F1) Dongle Huawei E398u1 N/A
10 223451234567889 Robot 10 Dongle Huawei E398u1 N/A
11 223451234567890 Node 27 (Zotac G3) Dongle Huawei E398u1 N/A
12 223451234567891 Robot 12 Dongle Huawei E398u1 N/A
13 223451234567892 Node 55 (Zotac F6) Dongle Huawei E398u1 N/A
14 223451234567893 Robot 14 Dongle Huawei E398u1 N/A
15 223451234567894 Node 29 (Zotac I3) Dongle Huawei E398u1 N/A
16 223451234567895 Node 7 (Zotac H1) Dongle Huawei E398u1 N/A
17 223451234567896 Node 25 (Zotac E3) Dongle Huawei E398u1 N/A
18 223451234567897 Node 2 (Zotac C1) Dongle Huawei E398u1 N/A
19 223451234567898 Node 54 (Zotac D6) Dongle Huawei E398u1 N/A
20 223451234567899 Node 34 (Zotac C4) Dongle Huawei E398u1 N/A
21 223451234567900 Node 19 (Zotac J2) Dongle Huawei E398u1 N/A
22 223451234567901 Node 22 (Zotac B3) Dongle Huawei E398u1 N/A
23 223451234567902 Node 30 (Zotac J3) Dongle Huawei E398u1 N/A
24 223451234567903 Qosmotec Shielded Box 2 (Zotac SB3) Dongle Huawei E398u1 N/A
25 223451234567904 Qosmotec Shielded Box 4 (Zotac SB4) Dongle Huawei E398u1 N/A

Android Nexus 6P Smartphone

W-iLab.t has been equipped with 15 Android Nexus 6P smartphones to be used as LTE UE (User Equipment). These smartphones are mounted on each mobile Zotac node, which is attached on a Roomba robot, in order to provide the required controlled mobility experimentation. The smartphones are compatible with the LTE FDD band 7 and are interoperable with the deployed LTE network.

_images/Nexus_6P.jpg

The following photos show the way that the smartphone are mounted on the mobile nodes.

_images/Android_1.jpg _images/Android_2.jpg _images/Android_3.jpg

The following table summarizes the specifications of the Android Nexus 6P smartphones.

Android Nexus 6P smartphone specifications
Smartphone Available devices Technical Specifications
Android Nexus 6P 15 Smartphone
    LTE / HSPA / CDMA / GSM
    Android OS, v6.0 (Marshmallow)
    Qualcomm MSM8994 Snapdragon 810
    3GB RAM
    Memory: 64GB
    Camera: Primary 12.3 MP - Secondary 8 MP
    Wi-Fi 802.11 a/b/g/n/ac, dual-band, Wi-Fi Direct, DLNA, hotspot
    Bluetooth v4.2, A2DP, LE
    Display: AMOLED capacitive touchscreen, 16M colors, 5.7 inches
    Resolution: 1440 x 2560 pixels
    Size: 159.3 x 77.8 x 7.3 mm
    Weight: 178g

The table below presents the USIM card’s IMSI number and the corresponding UE’s IMEI for each node equipped with an Android Nexus 6P Smartphone.

USIM card’s IMSI on each node
ID IMSI Node UE type IMEI
26 223451234567905 Robot 1 Android Nexus 6P 867981021914430
27 223451234567906 Robot 2 Android Nexus 6P 867981021915148
28 223451234567907 Robot 3 Android Nexus 6P 867981021910966
29 223451234567908 Robot 4 Android Nexus 6P 867981021917169
30 223451234567909 Robot 5 Android Nexus 6P 867981021915015
31 223451234567910 Robot 6 Android Nexus 6P 867981021916203
32 223451234567911 Robot 7 Android Nexus 6P 867981021912038
33 223451234567912 Robot 8 Android Nexus 6P 867981021912350
34 223451234567913 Robot 9 Android Nexus 6P 867981021913820
35 223451234567914 Robot 10 Android Nexus 6P 867981021917698
36 223451234567915 Robot 11 Android Nexus 6P 867981021917748
37 223451234567916 Robot 12 Android Nexus 6P 867981021914380
38 223451234567917 Robot 13 Android Nexus 6P 867981021915866
39 223451234567918 Robot 14 Android Nexus 6P 867981021917367
40 223451234567919 Robot 15 Android Nexus 6P 867981021917649

Huawei E3372h-153 LTE USB Dongle UE

W-iLab.t has been equipped with 10 Huawei E3372h Category 4 USB dongles to be used as LTE UE (User Equipment).

The dongles are configured in HiLink mode. This means that the dongle functions as router performing NAT. For this reason, HiLink mode cannot be used for remote access applications (e.g. Remote Desktop, VNC, web servers, etc.) where “inbound” connections are initiated by computers on the Internet. To use HiLink mode, your application must require only “outbound” initiated connections (e.g. web browsing, email, etc.), or you must implement a VPN connection to another device which is initiated by the router which has the HiLink mode modem installed.

For LTE experimentation using the Huawei E3372h-153 dongles please refer to the tutorial in the related section.

_images/E3372h.jpg

The following table summarizes the specifications of the LTE dongles.

Huawei E398u-1 LTE USB Modem specifications
LTE Dongle Available Dongles Technical Specifications
Huawei E3372h-153 10 Dongle
    4G Frequency: FDD DD800/900/1800/2100/2600
    3G Frequency: UMTS 900 / 2100 Mhz
    2G Frequency: GSM / GPRS / EDGE - 850 / 900 / 1800 / 1900 Mhz
    LTE download Speed up to 150 Mbit/s
    LTE upload Speed up to 50 Mbit/s
    LTE 2x2 MIMO
    Antenna: Integral antenna. 2X External antenna interface
    Memory: Micro SD card slot
    Display: LED Indicator
    Size: 88 x 28 x 11.5mm
    Weight: <35g

The table below presents the USIM card’s IMSI number and the corresponding UE’s IMEI for each node equipped with an LTE dongle.

USIM card’s IMSI on each node
ID IMSI Node UE type IMEI
41 223451234567920
Huawei E3372h-153 861821034190675
42 223451234567921
Huawei E3372h-153 861821034190824
43 223451234567922
Huawei E3372h-153 861821034190832
44 223451234567923
Huawei E3372h-153 861821034190857
45 223451234567924
Huawei E3372h-153 861821034190964
46 223451234567925
Huawei E3372h-153 861821034190261
47 223451234567926
Huawei E3372h-153 861821034190865
48 223451234567927
Huawei E3372h-153 861821034190717
49 223451234567928
Huawei E3372h-153 861821034190287
50 223451234567929
Huawei E3372h-153 861821034190022

LTE SIM cards

IBCN has purchased 50 USIM cards from Smartjac. The SIM cards are LTE compatible and they are preconfigured by Smartjac according to the IBCN desirable parameters. The cards are shipped as Mini-SIM or Nano-SIM size (2FF) to be compatible with the available LTE UEs.

The following table summarizes the specifications of the USIM cards of the W-iLab.t testbed.

USIM cards’ specifications
SIM Card model Quantity Technical Specifications
Smartjac 3G cards with 4G support 40 USIM cards
    Authentication algorithm: Milenage
    K code: 0x00112233445566778899AABBCCDDEEFF
    OP code : 0x01020304050607080910111213141516
    OPc: 0x0ED47545168EAFE2C39C075829A7B61F
    IMSI ranges: 223451234567880 – 223451234567904
    SPN: iMinds Network

The table below presents the USIM card’s IMSI number and the corresponding UE’s IMEI for each node equipped with an LTE dongle or an Android Smartphone.

USIM card’s IMSI on each node
ID IMSI Node UE type IMEI
1 223451234567880 Node 38 (Zotac G4) Dongle Huawei E398u1 N/A
2 223451234567881 Mobile 2 Dongle Huawei E398u1 N/A
3 223451234567882 Node 42 (Zotac K4) Dongle Huawei E398u1 N/A
4 223451234567883 Mobile 4 Dongle Huawei E398u1 N/A
5 223451234567884 Node 33 (Zotac B4) Dongle Huawei E398u1 N/A
6 223451234567885 Mobile 6 Dongle Huawei E398u1 N/A
7 223451234567886 Node 57 (Zotac H6) Dongle Huawei E398u1 N/A
8 223451234567887 Mobile 8 Dongle Huawei E398u1 N/A
9 223451234567888 Node 5 (Zotac F1) Dongle Huawei E398u1 N/A
10 223451234567889 Mobile 10 Dongle Huawei E398u1 N/A
11 223451234567890 Node 27 (Zotac G3) Dongle Huawei E398u1 N/A
12 223451234567891 Mobile 12 Dongle Huawei E398u1 N/A
13 223451234567892 Node 55 (Zotac F6) Dongle Huawei E398u1 N/A
14 223451234567893 Mobile 14 Dongle Huawei E398u1 N/A
15 223451234567894 Node 29 (Zotac I3) Dongle Huawei E398u1 N/A
16 223451234567895 Node 7 (Zotac H1) Dongle Huawei E398u1 N/A
17 223451234567896 Node 25 (Zotac E3) Dongle Huawei E398u1 N/A
18 223451234567897 Node 2 (Zotac C1) Dongle Huawei E398u1 N/A
19 223451234567898 Node 54 (Zotac D6) Dongle Huawei E398u1 N/A
20 223451234567899 Node 34 (Zotac C4) Dongle Huawei E398u1 N/A
21 223451234567900 Node 19 (Zotac J2) Dongle Huawei E398u1 N/A
22 223451234567901 Node 22 (Zotac B3) Dongle Huawei E398u1 N/A
23 223451234567902 Node 30 (Zotac J3) Dongle Huawei E398u1 N/A
24 223451234567903 Qosmotec Shielded Box 2 (Zotac SB3) Dongle Huawei E398u1 N/A
25 223451234567904 Qosmotec Shielded Box 4 (Zotac SB4) Dongle Huawei E398u1 N/A
26 223451234567905 Mobile 1 Android Nexus 6P 867981021914430
27 223451234567906 Mobile 2 Android Nexus 6P 867981021915148
28 223451234567907 Mobile 3 Android Nexus 6P 867981021910966
29 223451234567908 Mobile 4 Android Nexus 6P 867981021917169
30 223451234567909 Mobile 5 Android Nexus 6P 867981021915015
31 223451234567910 Mobile 6 Android Nexus 6P 867981021916203
32 223451234567911 Mobile 7 Android Nexus 6P 867981021912038
33 223451234567912 Mobile 8 Android Nexus 6P 867981021912350
34 223451234567913 Mobile 9 Android Nexus 6P 867981021913820
35 223451234567914 Mobile 10 Android Nexus 6P 867981021917698
36 223451234567915 Mobile 11 Android Nexus 6P 867981021917748
37 223451234567916 Mobile 12 Android Nexus 6P 867981021914380
38 223451234567917 Mobile 13 Android Nexus 6P 867981021915866
39 223451234567918 Mobile 14 Android Nexus 6P 867981021917367
40 223451234567919 Mobile 15 Android Nexus 6P 867981021917649
41 223451234567920
Huawei E3372h-153 861821034190675
42 223451234567921
Huawei E3372h-153 861821034190824
43 223451234567922
Huawei E3372h-153 861821034190832
44 223451234567923
Huawei E3372h-153 861821034190857
45 223451234567924
Huawei E3372h-153 861821034190964
46 223451234567925
Huawei E3372h-153 861821034190261
47 223451234567926
Huawei E3372h-153 861821034190865
48 223451234567927
Huawei E3372h-153 861821034190717
49 223451234567928
Huawei E3372h-153 861821034190287
50 223451234567929
Huawei E3372h-153 861821034190022

LTErf OMF service

LTErf is an OMF Aggregate Manager service that enables controlling of the ip.access LTE 245F femtocells and of SiRRAN’s EPC Network.

OMF stands for cOntrol and Management Framework and is a generic tool that allows an experimenter to configure the resources of a testbed, as well as to manage and execute his/her experiment using a domain-specific language, named OEDL. According to the OMF’s architecture, the user provides to the framework his/her Experiment’s Description (ED) written in OEDL. Then the Experiment Controller (EC) interprets the ED, and sends requests to the Aggregate Manager (AM) of the testbed to ask for the initialization and configuration of the experimenter’s required resources. The multiple services of the AM initialize and configure these resources. When the resources are ready, the EC sends commands to the Resource Controllers (RCs), which run on each of these resources. Then, the RCs interpret these commands and execute the actions.

Currently, LTErf can be used to get and set values from the APs as well as to get values from SiRRAN’s EPC. The values that can be changed/reported are the ones that are visible to the testbed Operator and can be used for setting up an experiment.

The service is included in the LTErf-v2, which can be loaded in a dedicated server.
The image can be found in the following public url:

The AP IDs are given based on the sequence of the IP addresses given in the configuration file. According to the IBCN configuration file the correspondence between the femtocell’s IDs, the femtocells’ IP and the femtocell’s location is the following:

Correspondence between femtocell’s ID, femtocell’s IP address and femtocell’s location for the LTErf service
Femtocell ID Femtocell IP Femtocell location
Node 1 192.168.1.10 W-iLab.t testbed
Node 2 192.168.1.11 W-iLab.t testbed
Node 3 192.168.1.12 Qosmotec
Node 4 192.168.1.13 Qosmotec
In order to configure the LTE equipment with the LTErf, the AM service should run. To start the service execute the following command:
sudo /etc/init.d/omf-aggmgr-5.4 restart
By sending the appropriate commands to the LTE AM service, you can change parameters on the database. For instance, in order to list all available services you have to issue the following command:
wget -qO- “http://localhost:5054/lterf/” | xml_pp
The command should return all the available parameters that can be changed through this service. In order to query about a specific value of an LTE AP, you will have a command similar to the following one (for example the Downlink MCS profile that is currently in use from the AP with id = 1).
The service replies with an XML formed reply. Similar to this, if the experimenter needs to change the current operating band, the command should look like
For every change to take effect, a reboot is required! The reboot command is:

Useful LTErf commands

GET the MCS Downlink and Uplink profiles from node 1:

SET the Downlink and Uplink MCS profiles to node 1:

GET/SET the Downlink Reference Signal Transmit Power from/to node 1 (Setup the Downlink Reference Signal Transmit Power in dBm. Default is -15 = 13dBm, range from -15 (13dBm) to -26 (0dBm)):

GET the CQI reportings from node 1:

SET the CQI reportings to node 1:

Reboot the eNBs:

For more information click on the following url: http://nitlab.inf.uth.gr/NITlab/45-testbed/lte/454-lterf-omf-am-service

W.iLab.t LTE testbed deployment

The IBCN LTE Network has been deployed as an indoor setup in the W-iLab.t testbed at Zwijnaarde.
This setup comprises of two femtocells (LTE 245F) provided by ip.access and the SiRRAN EPC software.

The following picture depicts the LTE network’s architecture

_images/w-ilab.t_LTE_architecture.jpg

Test frequencies in the licensed LTE band 7, are assigned by the Belgian Institute for Postal services and Telecommunications (BIPT), to be used for experimental purposes. Hence, both femtocells are configured to operate in that band.

position, ID and IP address of each femtocell
Possition Femtocell ID IP Address
A Node 1 192.168.1.10
B Node 2 192.168.1.11

The following figure depicts the current femtocells deployment in the W.iLab.t testbed at Zwijnaarde.

_images/femtocells_deployment.jpg
All the 20 mobile nodes of the testbed are equipped with a Huawei e398 LTE USB modem. Moreover, 8 static nodes, which are distributed in the testbed, are equipped with the same dongles. More information about the LTE enabled nodes can be found in the “Huawei E398u1 LTE USB Dongle UE” section.
The ip.access femtocells are connected through the EPC server via a 1Gbit experiment switch. Via the same switch the LTErf server can communicate with the EPC server as well as with the

femtocells in order to acknowledge their parameters and configure them respectively. The experiment interfaces have been configured by default to use the following IP addresses.

  • SiRRAN EPC: 192.168.1.1
  • LTErf: 192.168.1.2
  • Femtocell 1: 192.168.1.10
  • Femtocell 2: 192.168.1.11

Through the 1Gbit Control Switch the Emulab server, the nodes (static and mobile), the SiRRAN EPC server, the LTErf server as well as the OMF EC (Experiment Controller) can communicate between each other, using the control interfaces (eth0).

During the experiment definition for each Femtocell the “A Fake OSDI for a fake node representing a device” image must be used.

Qosmotec LTE deployment

The Qosmotec LTE Network has been deployed in the Mobility Emulation Framework of IBCN
This framework consists of 4 shielded boxes that are interconnected over coax cables to RF splitters and combiners, as well as compputer controlled variable attenuators.
This setup comprises of two femtocells (LTE 245F) provided by ip.access, two nodes equipped with Huawei E398u1 LTE USB dongles and the SiRRAN EPC software.

The following picture depicts the LTE network’s architecture

_images/qos.png

The experiment interfaces have been configured by default to use the following IP addresses.

  • SiRRAN EPC: 192.168.1.1
  • LTErf: 192.168.1.2
  • Femtocell 3: 192.168.1.12
  • Femtocell 4: 192.168.1.13

The SiRRAN EPC must be used with a dedicated server on the Wall1 that has the required license. The name of the server is n073-23a.

The following picture illustrates the ID of each shielded box.

_images/Qosmotec_numbered.jpg

The table below shows the location of each LTE equipment, their mapping on physical resources and the IPs of their experiment interface.

type, mapping, location and IP of the Qosmotec LTE equipment
Type of Equipment Resource mapping Location IP Address
Femtocell 3 switch1-13-46 Shielded Box 3 192.168.1.12
Femtocell 4 switch1-13-47 Shielded Box 4 192.168.1.13
UE 1 Zotac SB3 Shielded Box 1 Specified by the user
UE 2 Zotac SB4 Shielded Box 2 Specified by the user
EPC n073-23a Wall 1 192.168.1.1

During the experiment definition for each Femtocell the “A Fake OSDI for a fake node representing a device” image must be used.

Qosmotec via webgui
You can control the attenuation of the ports on the attenuator via this url:
Make sure you do not touch any port unless they are part of your setup and you know what you are doing!
Qosmotec via OMF

An OMF5.4 resource controller is available for configuring the Qosmotec attenuators directly. It runs on the VMWare cluster:

  • qosmotec-rc.test
  • ip: 10.10.10.135
  • OS: Ubuntu 14.04 LTS
The resource controller script can be found under /opt/qosmotecrc/.
It is written in Python
  • maincomm.py: the class that connects to the Qosmotec attenuators
  • qosmotec_att.py: the main program

To run the script type: python /opt/qosmotecrc/qosmotec_att.py

To run an OMF experiment that controls the Qosmotec attenuators, the Qosmotec resource controller should be used. An example ruby experiment file is the following:

######### VARIABLES ############

qosmotec_scripts_dir = '/opt/qosmotecrc/'


defApplication('qosmotec:communicator:app','Control the Qosmotec attenuators') do |app|
        app.description = 'Control the Qosmotec attenuators'
        app.path = qosmotec_scripts_dir + '/qosmotec_att.py'
        app.defProperty('nodeid', "OML node id", "--omlnodeid", {:type => :string, :dynamic => false})
        app.defProperty('exp', "OML node id", "--omlexp", {:type => :string, :dynamic => false})
end

defGroup('qosmotec:communicator:group',"qosmotec-rc.test") do |node|
        node.addApplication('qosmotec:communicator:app', { :id => 'qc'}) do |app|
        app.setProperty('exp', Experiment.ID)
        end
end


onEvent(:ALL_UP_AND_INSTALLED) do |event|
  allGroups.startApplications

  wait 1
  info ""
  info "Connecting to attenuator"
  info ""

  group('qosmotec:communicator:group').sendMessage('qc',
    'connect'
  )

  wait 5

  info ""
  info "Set attenuation on port 1 to 20"
  info ""

  group('qosmotec:communicator:group').sendMessage('qc',
    'attenuate 1 20'
  )
  wait 5

  info ""
  info "Set attenuation on port 1 to 30"
  info ""

  group('qosmotec:communicator:group').sendMessage('qc',
    'attenuate 1 30'
  )
  wait 5

  info ""
  info "Set attenuation on port 1 to 40"
  info ""

  group('qosmotec:communicator:group').sendMessage('qc',
    'attenuate 1 40'
  )

  wait 5
  info ""
  info "Disconnecting and resetting attenuators"
  info ""

  group('qosmotec:communicator:group').sendMessage('qc',
    'disconnect'
  )

  allGroups.stopApplications
  Experiment.done
end

Permanent storage

Every experimenter who signed up for an account on the w-iLab.2 home page , automatically has a user account on ops.wilab2.ilabt.iminds.be. Use putty (Windows) or any other SSH client to login to this machine using your web credentials. If you upload your SSH key to your profile (webinterface), you can login without being prompted for your password.

Every user has several directories (user/project/group), which are all automatically mounted on every node in your experiment if you use one of the OS images provided by the testbed:

  • /users/username/: a personal home directory that is only accessible to the user.
  • /proj/projectname/: a directory shared with all users in the same project.
  • /groups/groupname/: a directory shared with all users in the same group (subdivision of a project).
  • /share/: a directory accessible to all users, where testbed providers can store files that are useful for all experimenters.

Emulab projects are like UNIX groups. Confidential data should be downloaded to your own storage and removed from the file server.

Although backups are taken every night, we recommend that you backup your important data to your own storage.

Tutorials and howto’s

Make a reservation

To be able to reserve nodes in the w-iLab.t testbed, you first need to import your certificate (in pkcs12 format) into your browser. The following subsections describe how to obtain your certificate in this format for users who got an account through the iLab.t authority and users of the GENI portal.

If you do not have an account, request one at `iLab.t authority <https://authority.ilabt.iminds.be>`.

Once you succesfully imported your certificate, browse to the w-iLab.t reservation page. If the previous step was successful, you should now be prompted to select your certificate. Once the page has loaded, please verify that the last part of the User URN matches your own user name.

_images/reservation1.png

Modify the start and end time if necessary and click on Get Free Nodes. Select your nodes out of the list and click Reserve!. Refresh your page to see your reservation in the table. If everything worked out fine, you should see the following:

_images/reservation2.png

iLab.t authority

Login to the iLab.t authority and click Download PKCS12 version of your certificate. Also click Download your certificate to store it in pem format. You will need it to start up the jFed tool later.

Now import the certificate into your OS/Browser:

  • For Windows users using Chrome or Internet Explorer : double click the p12 file and install it on your OS.
  • For MAC users using Safari : double click the p12 file and install it on your OS.
  • For Firefox users (Windows, Linux, MAC) : in Firefox, go to Options > Advanced > Certificates and click on View Certificates. Now click Import and browse to the location of your p12 certificate and import it.

GENI authority

Join the ipv6proxy project

This step is needed to be able to connect to the iMinds testbed nodes, as they are fully IPv6 enabled.
Login to the GENI portal, click on Use GENI and browse down to My Projects. Now click Join a Project and type ipv6 in the search box. Click the Join button next to the ipv6project, browse down and click Send join request.
Once you get approved, your My projects page should look like this:
_images/myprojects.png

Download your GENI certificate

Login to the GENI portal and browse to the profile page. Now go to the SSL tab and click on Download your SSL certificate and key.

_images/sslcert1.png

Click Download Your Portal Generated Certificate and Private Key on the next page. Store the resulting .pem-file somewhere on your hard drive, you will need it in the next steps.

_images/sslcert2.png

Generate a pkcs12 file and import it into your browser

This step is needed to be able to reserve nodes at the iMinds w-iLab.t testbed and access the Robot Control Dashboard.

Fire up jFed by browsing to the GENI portal and click on Use GENI. Browse down to the tools and click jFed. Or start jFed from the jFed website.

_images/genitools.png

If all goes well, you should be prompted to provide your User certificate and Password. Browse to the location where you stored the .pem-file (see previous step), provide your password and click Login.

Once jFed is started, click on Preferences, select User details and save your login as PKCS12. Store the resulting .p12-file somewhere on your hard drive.

_images/jfedpkcs.png

Now import the certificate into your OS/Browser:

  • For Windows users using Chrome or Internet Explorer : double click the p12 file and install it on your OS.
  • For MAC users using Safari : double click the p12 file and install it on your OS.
  • For Firefox users (Windows, Linux, MAC) : in Firefox, go to Options > Advanced > Certificates and click on View Certificates. Now click Import and browse to the location of your p12 certificate and import it.

First experiment

1. Create & Activate your experiment using jFed

Follow these steps to activate your nodes using jFed:

  • Fire up jFed by browsing to the jFed website, browse down and click Quickstart Experimenter GUI. If all goes well, you should be prompted to provide your User certificate and Password. Browse to the location where you stored the .pem-file (see previous section on how to make a reservation), provide your password and click Login.
  • If this is the first time you are using jFed to activate nodes in the iMinds w-iLab.t testbed, you have to enable the proxy first. Click on Preferences, select the Proxy tab and click Run Proxy Test. Select the Always option for both Proxy for jFed and Proxy for SSH connections.
_images/jfedproxy.png
  • Click on New
  • Drag in 3 wireless nodes
  • Right click, Configure Node to change the properties (name/testbed/disk image/specific node). For now, uncheck the “Show only available nodes”-checkbox, as the reservation system is not synched with jFed fully
  • Name the two fixed nodes: ap and rcomm. Choose one mobile node (mobile1 .. mobile15) and call it robot.
  • By default, the iMinds w-iLab.2 testbed should be selected (because we picked wireless nodes)
_images/jfedrobot.png
  • Click Run to start your slice (Green arrow on the top left) and fill in a unique name for your slice.
_images/jfedrun.png

When all nodes turn green, your experiment is succesfully activated.

_images/jfedok.png

2. Configuration of Access Point

SSH to your AP node (double click it in jFed). Become root:

$ sudo su

Create a config file for the hostapd program:

$ nano /root/hostapd.conf

Add the following content to the config file:

interface=wlan0
driver=nl80211
country_code=BE
ssid=demoX
hw_mode=Z
channel=Y

Replace X with a random number. Replace Y with your channel(1-11 for g, 36/40/44 for a) and Z with the WiFi mode (a or g). Start hostapd. The above config will setup an AP on wlan0 using 802.11a or g, channel Y, with SSID demoX:

$ hostapd /root/hostapd.conf

Open a second ssh terminal and give an IP address to the wlan0 interface so we can test the connection to the clients (in the next steps). Be sure to replace X with your number:

$ sudo su; ifconfig wlan0 192.168.X.1/24

Running the ifconfig command should show a wlan0 and mon.wlan0 interface:

_images/ifconfigap.png

3. Configuration of client (robot)

Become root:

$ sudo su

Put the wireless interface into managed mode and specify the SSID so it knows to which AP it should connect

$ iwconfig wlan0 mode managed
$ iwconfig wlan0 essid demoX

Specify an IP address and bring up the interface:

$ ifconfig wlan0 192.168.X.10/24 up

Running iwconfig should show that wlan0 is connected to an access point with your ESSID:

_images/iwconfigrobot.png

Check if you can ping the AP:

$ ping 192.168.X.1

4. Start the iPerf throughput measurements

Start an iPerf server instance (UDP in this case) on the AP:

$ iperf -s -u -i 1

Configure the iPerf client (on the robot):

$ iperf -u -c 192.168.X.1 -b 30M -i 1 -t 6000 &

On the server, you should see some output like below:

_images/iperfserver.png

By tweaking the transmit power (values of 0 to 17dBm) of the access point, you should be able to see a difference in throughput of the iPerf stream (open up a new SSH session to your AP to play with the TX power):

$ iwconfig wlan0 txpower <0-17>

For this tutorial, leave the txpower set to default (17 or 20dBm) for the first experiment runs. If the effect of moving the mobile node is too limited, you can try lowering the txpower. Note that each antenna at the w-iLab.t is equipped with a 10dB attenuator (so 20dB attenuation per link).

5. Operate the mobile nodes

Once everything works fine, you can start driving the mobile node and check the impact on the iPerf throutput. Note that you will lose your SSH connection to the robot when it is no longer in its docking station.

The Robot Dashboard can be accessed here. Be sure to use a recent Chrome or Safari browser. If you imported your p12 certificate into your browser, you can login by clicking the red key (top right of the dashboard). Select the Fed4FIRE SFA tab and click Login. If you now hover over the key (hopefully not red anymore), it should show your login name. You will only be able to move robots which are reserved by you.

_images/robotlogin.png
Now start drawing a path for your robot by selecting the robot ID on the top left of the Robot Dashboard. On the top left, you can also choose between straight paths and bezier curves.
Always start your path by clicking on its Safe zone (the circle below the charging station with the ID of the robot in it) and dragging towards a location of your choice. Be sure that you don’t cross any obstacles (marked in yellow or blue). If you do cross obstacles, the Robot Dashboard will tell you (and you will not be allowed to start driving that path). Add some more segments to your path and make sure that your robots returns somewhere near its safe zone (circle with ID of the robot) at the end of your scenario.
_images/robotpath.png

If you are satisfied with your path, click the Live button, followed by Action. Go to the User tab, select Auto Undock and hit the Send button. Alternatively, you can right click on a robot and select Auto Undock.

VERY IMPORTANT : You will only be able to SSH to the mobile node while it is docked. (If you want an SSH connection during your experiment, you will have to set up a wireless connection to a fixed node and SSH over the wireless.)

_images/robotactions.png

Click on Initialize to taxi the robots to their starting position (check the top right of the robot dashboard for errors). If no errors occured, hit the Play button. You should now see the status of your robot changing to Active and see it moving around.

_images/robotactive.png

At the end of your experiment, click on Actions again, go to the User tab, select Auto dock and hit Send to park the robot in its docking station. If the robot is too far away from its docking station, you should use the Safe Return option, which will automatically search for the shortest path towards its docking station.

6. Use labwiki to run your experiment and operate the nodes

In this part, you will learn how to run experiments using the Labwiki tool. This tool uses the OMF framework in combination with the OML measurement library. For more info on OMF, OML, Labwiki, please visit :

Revert to OMF6 version 6.1.3

To be compatible with the labwiki install, we need an older version of the OMF RC. Use the Instant Command functionality in jFed (under Timeline Viewer) to execute the following command on all the nodes in your experiment:

/share/upload/omf6/downgradeRC.sh

Prepare your mobile scenario

Go to the Robot Dashboard and start drawing a scenario for your mobile node. If you are done, click the Save button and copy the list of coordinates.

_images/savecsv.png

SSH to your robot communicator (rcomm) node, create a file in the root directory and paste the csv coordinates in the file.

$ sudo su
$ nano /root/path.csv

Prepare your experiment

Go to the Labwiki install at iMinds, click the prepare text field and type gec21Wilab. You should see a drop down list with some files. Select the gec21WilabMobile.oedl file.

_images/labwikiprepare.png

Since this version of labwiki only has one user account at the moment, you should copy the contents of this experiment file and create a file with your name added to the file name. Click CTRL-A, followed by CTRL-C and then click the wheel icon. Choose a name for your file (without the .oedl extension), select OEDL and click Create.

_images/labwikiNew.png
Now paste (CTRL-V) the contents of the experiment in the field below and click the Save button.
The presentation at the beginning of the session should have given enough explanation to understand this experiment description file.
Be sure to issue the following command (on all 3 nodes(ap,rcomm,robot)) before running any labwiki experiment. This will start the OMF6 resource controller on your nodes, so labwiki can control them.
You can easily use jFed for this: go to the Timeline Viewer and click on Instant. Select all 3 nodes and type the following command:
$ sudo /share/robots/startOMF.sh
_images/jfedtimeline.png

Drag & drop the page-icon (with the crayon) over to the Execute field. Now change the properties with as value REPLACE ME so they reflect your setup. It is very important that the names of your slice and your nodes are exact matches to the names you chose in jFed. Be sure you type them in lower case !!

_images/labwikiexec.png

Hit the Start Experiment button if you are finished. After some time, you should see some output like below:

_images/labwikigraph.png

Copy files from the testbed to your local Windows machine

Create a ppk (Putty Private Key) version of your certificate :

  • Download and install PuttyGen
  • Download your certificate (and save it as .pem) from the iLab.t authority website
  • Open PuTTYgen, select Type of key to generate as: SSH-2 RSA
  • Click “Load” on the right side
  • Set the file type to .
  • Browse to, and Open your .pem file
  • PuTTY will auto-detect everything it needs, and you just need to click “Save private key” and you can save your ppk key for use with PuTTY or WinSCP

Install WinSCP from this page.

Follow these instructions to connect to one of the nodes in your experiment:

  • On the Session page, fill in the hostname (of a node in your experiment) and user name for the final destination host. Leave the password blank.
  • Load your private key file by selecting the ppk file created in the previous step. For newer versions of WinSCP: Click Advanced , then click Authentication under the SSH menu and provide your private key file there.
  • Check the “Advanced options” box in the login dialog.
  • Select the Connection –> Tunnel page.
  • Check the “Connect through SSH tunnel” box.
  • Fill in the Host name (bastion.test.iminds.be) and user name (your own user name). The Port number should remain 22. Leave the password blank. Also be sure to provide your private key file in this step.
  • Click Login and you should now see the contents of your home directory.

Don’t forget to save your session, so you don’t have to fill in these details every time. The only thing you will probably need to change is the host name of the node where you want to copy things to/from.

Remember that only the files stored in your NFS directory at /data/groups/wall2-ilabt-iminds-be/<PROJECT_NAME> will be available the next time you run an experiment

Create custom disk images

We highly recommend to use the default image, or one of the other images that are provided on the w-iLab.2 webinterface.

If your OS of choice is not in there, and you have specific needs for another OS, please inform us through e-mail : pieter.becue AT intec.ugent.be. In addition to the images listed on the webinterface, these images should be fairly easy to install : http://www.emulab.net/downloads/images-STD/. Please inform the admins if you want to use one of these images.

If you have a lot of software to install on one of the supported images, it might be useful to create your own disk image (starting from one of the supported images). This tutorial will show you how:

  • First, create an experiment with one (or more) nodes (as shown in the tutorial named ‘First Experiment’) and install all the needed software.
  • Go to the experiment list (Experimentation > Experiment List), click on your Experiment and scroll down to the list of nodes. Click on the correct node (where you installed the software) and click on ‘Create Disk Image’ at the top left of the page.
_images/nodeProp.png

You will be asked if you want to overwrite the current image : only do this if you are already working on your own custom image. If you started from the testbed baseline image, select Create a new Image descriptor.

Most of the options on the ‘Create a New Image Descriptor’ page should already be filled in automatically. Just fill in a ‘Descriptor Name’ and a short ‘Description’.

Some short info on the other options:

  • Partition : should be 2 for most images. For FBSD images, use 1.
  • OS : select one from the dropdown list.
  • OS Version : not used by Emulab, so just put your own version number.
  • Filename : should be auto completed. Do NOT change this field.
  • OS Features : If you modified the kernel, you should probably disable most of the ‘OS Features’. Just leave ping and ssh enabled.
  • Operational mode : do NOT change.
  • Node types: select all.
  • Whole disk image: only do this for openWRT images (and maybe Windows images, ask the admins first).
  • Maximum concurrent loads : leave blank.
  • MBR Version: 2 for most images. 1 for Debian images. 3 for newer images like UBUNTU14 or DEBIAN 7.
  • Shared : tick if you want to share the image with your group members.
  • Reboot wait time : leave blank.

More information on the different options when creating a new image descriptor can be found at the bottom of this page : https://www.wilab2.ilabt.iminds.be/newimageid_ez.php3.

Click Submit to start the image creation process. You will be notified through e-mail when it has finished.

To keep all installed system users (e.g. mysql) when saving an image, run the following command before starting the image creation process:

/usr/local/etc/emulab/prepare -M

To see how you can create a custom image from scratch, check out this tutorial: Create image from scratch.

OMF & OML Tutorials for w-iLab.2

The tutorials below are derived from the OMF6 home page. This documentation is focussed on the installation and usage of OMF6 in w-iLab.2 .

For documentation on older versions, see the OMF home page.

Install OMF6 Resource controller

IF YOU ARE USING THE DEFAULT UBUNTU14.04 IMAGE ON w-iLab.2 THEN THE OMF RC IS PRE-INSTALLED !! ** JUST UPDATE IT AS SHOWN BELOW: **

gem install omf_rc -v 6.2.3 --no-ri --no-rdoc

**The instructions below only apply if you are not using the default image on w-iLab.2 **

Check the original install instructions here.

This tutorial was tested on a UBUNTU14.04 system.

Follow these steps to install an OMF6 RC (as root):

sudo apt-get update
sudo apt-get install software-properties-common
sudo apt-add-repository ppa:brightbox/ruby-ng
sudo apt-get update
sudo apt-get install ruby2.3 ruby2.3-dev build-essential libssl-dev
#both of the following commands should result in versions 2.3
#if not, check here how to solve it: https://www.brightbox.com/docs/ruby/ubuntu/
ruby -v ; gem -v
gem install omf_rc -v 6.2.3 --no-ri --no-rdoc
install_omf_rc -i -c
nano /etc/omf_rc/config.yml
Change the amqp server to amqp://labwiki.test.atlantis.ugent.be
start omf_rc
Check if the RC is running: ps -eaf | grep omf

Install OMF6 Experiment controller

Check the original install instructions here.

This tutorial was tested on a UBUNTU14.04 system.

Because of high CPU usage, it is recommended to use one of the servers to run the EC. (server1-server8)

Follow these steps to install an OMF6 EC. The -v 6.2.1 option install a specific version to be compatible with the RC pre-installed on the testbed nodes. If you will also install the RC’s, then you can leave out this option and just install the latest version.

sudo apt-get update
sudo apt-get install software-properties-common
sudo apt-get install python-software-properties # only on UBUNTU 12 (SERVER NODES)
sudo apt-add-repository ppa:brightbox/ruby-ng
sudo apt-get update
sudo apt-get install ruby1.9.1 ruby1.9.1-dev build-essential libssl-dev
# run the update-alternatives commands first to make sure you are not using ruby2.X (this will result in very high CPU load):
sudo update-alternatives --config ruby #and then select option 0 (or the option that corresponds to a ruby2.X version)
sudo update-alternatives --config gem #and then select option 0 (or the option that corresponds to a gem2.X version)
ruby -v ; gem -v
gem install omf_ec -v 6.2.3 --no-ri --no-rdoc

Run your experiment by executing this command:

omf_ec -u amqp://labwiki.test.atlantis.ugent.be <PATH_TO_YOUR_OEDL_FILE>

Install AMQP server

We recommend to use the AMQP server at amqp://labwiki.test.atlantis.ugent.be

If you need to install one yourself, check out this page: http://mytestbed.net/doc/omf/file.set_up_communication_server.html.

Brief install instructions for RabbitMQ:

  • Uninstall any other AMQP servers first
  • Make sure port TCP 5672 is open in your firewall (if needed)
  • Install RabbitMQ on Ubuntu / Debian:
sudo apt-get install rabbitmq-server

If you encounter any issues, see http://mytestbed.net/doc/omf/file.set_up_communication_server.html.

Install OML Server

Check if you have the right sources to download OML

ls -la /etc/apt/sources.list.d/oml2.list

If this file doesn’t exist, create it and add the following content

deb http://download.opensuse.org/repositories/devel:/tools:/mytestbed:/stable/xUbuntu_14.04/ /

Then run the following commands to install the OML-server

wget http://download.opensuse.org/repositories/devel:/tools:/mytestbed:/stable/xUbuntu_14.04/Release.key
sudo apt-key add - < Release.key
sudo apt-get update
sudo apt-get install oml2-server sqlite3

Check that the OML server is running correctly with

ps aux|grep oml2-server
netstat -an|grep 3003

If not, start it with

/etc/init.d/oml2-server start

And check the log file

tail -f /var/log/oml2-server.log

By default, the OML server will log its databases in this directory

/var/lib/oml2

If you want to have this data available after your experiment has ended, copy it to your local machine or to your NFS mounted directory

/groups/wall2-ilabt-iminds-be/<PROJECT_NAME>

If you want to save your current image so you don’t have to reinstall it every time, please run the following command just before saving the image

sudo su
/usr/testbed/lib/prepare -M

Running an OMF-OML Experiment

If you are using the w-iLab.2 testbed, then you don’t have to install the OMF Resource Controllers as they are pre-installed for you.

However, you do need to install the OMF Experiment Controller and the OML Server on 1 node in your experiment (the type of the node doesn’t matter). Follow the steps in the topics above to install these components.

On your EC node, download the application definition (iperf.rb) and the experiment definition (iperfTutorial.rb):

cp /share/upload/omf6/iperf.rb .
cp /share/upload/iperf/iperfTutorial.rb

In case you cannot access the /share directory:

wget http://ec.wilab2.ilabt.iminds.be/upload/iperf/iperf.rb
wget http://ec.wilab2.ilabt.iminds.be/upload/iperf/iperfTutorial.rb

Modify the following lines in iperfTutorial.rb:

defProperty('theSender','client.testsetup.testbed.wilab2.ilabt.iminds.be',"ID of sender node")
defProperty('theReceiver','ap.testsetup.testbed.wilab2.ilabt.iminds.be',"ID of receiver node")

Fetch the DNS name of the sender and the receiver by running hostname in an SSH terminal on the client.

Run the experiment with

omf_ec -u amqp://labwiki.test.atlantis.ugent.be exec --oml_uri tcp:`hostname`:3003 iperfTutorial.rb

In this example the OML server stores its data in a local SQLite backend. Every run will create a database in /var/lib/oml2/ on the EC node. You can access your data as follows:

sqlite3 /var/lib/oml2/<DB NAME>.sq3
.tables
select * from _senders ;
select * from iperf_transfer ;
.schema iperf_transfer
.quit

Using the OML Proxy Server

In mobile and/or wireless experiments, we cannot assume that there is a permanent connection between the client that makes the measurements and the OML server. Furthermore, in some other experiments this measurement channel could also be the experiment channel and therefore the experimenter would like to postpone the collection of measurement until the channel is available again. In order to solve these two problems, OML provides a proxy-server that acts as a buffer that can be paused and resumed. See the OML website for more info on the proxy server.

The proxy-server can be in either of the following three states:

  • Paused: in this state the proxy stores both in a file and in memory the measurements form the different clients connected to it.
  • Resumed: in this state the proxy transfers the measurements to the server.
  • Stopped: in this state the proxy finishes transferring the measurements to the serve and closed all its incoming and outdoing connections.

When you start the proxy, it is in the paused state. In order to change between the states three commands are available:

  • OMLPROXY-PAUSE: change from Resumed to Paused
  • OMLPROXY-RESUME: change from Paused to Resumed
  • OMLPROXY-STOP: set to Stopped definitely

Install the oml2-proxy-server (not needed on w-iLab.2 nodes with the default image):

sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/tools:/mytestbed:/stable/xUbuntu_14.04/ /' >> /etc/apt/sources.list.d/oml2.list"
sudo apt-get update
sudo apt-get install oml2-proxy-server

Add the following application definition to your OEDL:

defApplication("omlproxy") do |app|
        app.binary_path = "/usr/bin/oml2-proxy-server"
        app.description = "Proxy server to buffer measurements in disconnected experiments"

        app.defProperty('listen', 'Service to listen for TCP based clients', '-l', {:dynamic => false, :type => :integer})
        app.defProperty('control', 'Service to listen for commands', '-c', {:dynamic => false, :type => :integer})
        app.defProperty('debug-level', 'Debug level error:1 .. debug:4', '-d', {:dynamic => false, :type => :integer})
        app.defProperty('resultfile', 'File name for storing received data', '-r', {:dynamic => false, :type => :string})
        app.defProperty('size', 'Page size for buffering measurements', '-s', {:dynamic => false, :type => :integer})
        app.defProperty('dstport', 'Downstream OML server port', '-p', {:dynamic => false, :type => :integer})
        app.defProperty('dstaddress', 'Downstream OML server address', '-a', {:dynamic => false, :type => :string})
end

The control port of the proxy server listens for commands to change its state. To be able to send these commands from your OEDL to the proxy server, a helper script named write_to_socket.rb is provided.

/share/upload/omf6/omlproxy/write_to_socket.rb

Also add the application definition for the helper script to your OEDL:

defApplication("writesocket") do |app|
        app.binary_path = "/share/upload/omf6/omlproxy/write_to_socket.rb"
        app.description = "Helper program to send STDIN input to socket"

        app.defProperty('host', 'Host to send the data to', '-h', {:type => :string, :dynamic => false})
        app.defProperty('port', 'Port to send the data to', '-p', {:dynamic => false, :type => :integer})
        app.defProperty('data', 'STDIN data to forward to socket', '-d', {:dynamic => true, :type => :string})
end

When defining your groups, add the above applications to all groups.

defProperty('proxystate','empty',"OMLPROXY-PAUSE (default),OMLPROXY-RESUME, OMLPROXY-STOP")

defGroup("AccessPoint","ap.testslice.wall2-ilabt-iminds-be.wilab2.ilabt.iminds.be") do |node|
        node.addApplication("omlproxy") do |app|
                app.setProperty('listen',3003)
                app.setProperty('control',3333)
                app.setProperty('dstaddress','am.wilab2.ilabt.iminds.be')
                app.setProperty('dstport',3004)
        end
        node.addApplication("writesocket") do |app|
                app.setProperty('host','localhost')
                app.setProperty('port',3333) #should be the same as the control port of the omlproxy
                app.setProperty('data',property.proxystate)
        end
end

At start of your experiment, the measurements will be logged to a file. If you want to change the state of the proxy server, just change the proxystate property:

onEvent(:ALL_UP_AND_INSTALLED) do |event|
        after 5 do
                allGroups.startApplications
                info "All my Applications are started now..."
        end

        after 10 do
                info "Resuming OML PROXY..."
                property.proxystate = 'OMLPROXY-RESUME'
        end

        after 20 do
                Experiment.leave_memberships
                info "Free up the resources"
        end

        after 25 do
                info "Experiment is finished"
                Experiment.done
        end
end

Start your experiment with the following options:

omf_ec -u amqp://labwiki.test.atlantis.ugent.be --oml_uri tcp:localhost:3003 <OEDL_FILE>

Note that the oml_uri is now specified as localhost:3003. This should reflect the configuration of the oml proxy server. Because the OMF Experiment Controller will also try to send its log messages to this OML server, we also have to start an OML proxy server on the EC:

/usr/bin/oml2-proxy-server -l 3003 -c 3333 -a am.wilab2.ilabt.iminds.be -p 3004

Don’t forget to type ‘OMLPROXY-RESUME’ to the STDIN of the above process, so that the logs are dumped instantly to the actual OML server.

Using the mobile nodes (mobility toolkit)

This is a hands on tutorial, please make sure you’ve quickly went over the mobility-extension architecture and you know how to make-a-reservation.

  • Reserve a node, make sure your NS file looks similar (ONLY for NATIVE EMULAB users, when using jFed just map a Wireless node to one of the MOBILE[1-16] ones):
set bot [$ns node]
tb-fix-node $bot mobile7

If you want to automate driving (not driving yourself by clicking ‘play’ on RobotDashboard, see later...): * Remember to swap in one additional node (doesn’t really matter which one) to act as communicator/proxy between the Experiment Controller and RobotControl.

When you’ve swapped in the experiment, you can ssh to the robot:

_images/ssh-to-bot.png

Keep in mind that:

  • ssh’ing to a robot is only possible when docked (as the robot is then physically connected with ethernet).
  • Set up your own WiFi accesspoints using one of the 2 wlan interfaces on the bot if you want to keep connectivity (see wlan-connectivity)
  • The device under test has to be powered, notice second tilde in the substate has changed to ‘z’ (or ‘p’)

Setting up paths

Navigate with a webkit-enabled browser (preferably Chrome) to the RobotControl Server, where you’ll be redirected to the RobotDashboard, a GUI which you can use to draw paths in the Zwijnaarde testbed. Please refer to the help-menu of the RobotDashboard for more information on what the different actions are. Remeber to use the ID of the mobile node you reserved as ID of a robot.

_images/draw-path.png

If you’ve made a nice choreography, don’t forget to click ‘save’ and copy paste the CSV-data to a file. This file can be reloaded using the load-menu.

Driving your paths

If you’ve drawn your path you can use the simulator in RobotDashboard to see where robots will be at a certain time, in reference to the start of the scene. It’s possible to drive the robot without OMF, by using the ‘Initialize, Play and Play all’-buttons. But first, you need to login:

  • click the red key next to the RobotDashboard logo
_images/login-robotcontrol.png

once logged in, you can click the User-icon to see your token:

_images/login-token.png

After loggin in, the system will verify if you have a reservation. Keep in mind that this username+date+key combo has to be secret, and everyone who can access it can use it to drive robots under your authority. Tokens are generally valid for a week.

Final steps:

  • Via the action-menu or right mouse on a robot, you can choose ‘Auto Dock’ and ‘Auto Undock’, which will put the robots from their safezone in their docking station and vice versa. Do an Auto Undock.
  • You can use the Initialize button to set a robot(s) ready at the start of the scene automatically.
  • Use the Play*-button to let the robot(s) drive the paths you’ve created in the current scene.
  • Use the Play-all-button to to let the robot(s) drive the paths you’ve created in the current scene and every scene that follows and that has the autostart-function enabled.
  • If you didn’t instruct the robot to return to the safezone at the end of your scene, you can use the Safe-Return function to do this for you.

Automated Robot Driving with OMF

The CSV file containing the coordinates can be passed to RobotControlComm.rb script (latest version) This script basically calls the REST-API of RobotControl and makes it possible to:

  • Automate driving inside an OMF-experiment
  • Log the positions of the robots in a separate table in de experiment-database
  • Facilitate automatic actions (undocking, docking, eyes, ...)

The proxy node mentionned in the beginning will run this script. Try run the script via ssh first to see all dependencies are installed, if that works, run it with OMF. (Generally only ruby dependencies are required, install them with the command ‘gem1.9.3 install json’ or ‘gem install json’).

Run the script with:

ruby1.9.3 RobotCTRLComm.rb robot_coordinates.csv vsercu@intec.ugent.be 03-04-2014@10:35:20.106217 a46902cff6e6...

Make sure this file is executable if you wish to run it via omf (chmod a+x RobotCTRLComm.rb)!

_images/test-rccomm-first_0_0.png

Example output when running the script on the proxy node

Subsequently, create an OEDL that uses this script as an application. It should look something like:

When executing this OMF script, the robot will automatically undock, drive its path, and automatically dock in the end.

_images/rccomm-in-action1.png

Robot undocking.

_images/rccomm-in-action2.png

You can use the IP-cams to have a visual feed of what the robot is doing. Use options –> cams or press the ‘c’ hotkey

Troubleshooting:

OMF: check the resource-controller log for detailed info (located on /var/log/omf-resctl-5.4.log, in OMF5.4, on the node you run RobotCTRLComm.rb on).

WLAN connectivity:

Intro

By default, once a robot is undocked, you have no longer connectivity to its eth0-wired interface.

A workaround would be, if the experimenter still requires access to the mobile node, to use a wifi-bridge. (Needless to say that such a bridge can alter your experiment results if you’re doing wifi-related experiments...)

This tutorial describes how such a bridge is set up. If you do not care about the nodes being reachable over the wireless network when they are undocked, you should skip this tutorial.

One node has to be configured as wireless access point where all the mobile nodes will connect to (use the proxy-node). After connecting, the mobile nodes will be able to access the rest of the wilab2 network (over the wlan0 device).

(all scripts are located on the ops.wilab2.ilabt.iminds.be server)

Select a node as AP

Select one node in the testbed to function as access point for the robots. In your ns-file, add the following line for the selected node :

tb-set-node-startcmd $ap "/share/upload/robots/startAP.sh"

This will configure everything on node $ap and set the IP address of the wlan0 interface to 172.16.0.1/16.

Configure the mobile nodes

The mobile nodes connect to the AP, modify their default gateway and restart the OMF RC so it uses the wlan0 instead of the eth0. Be aware that the eth0 interface will be disabled when running the following script :

tb-set-node-startcmd $robot "/share/upload/robots/startRobot.sh"

The IP-address of the mobile node will be set to 172.16.0.70+robotID. So 172.16.0.77 for mobile7.

If you want to ssh to your mobile nodes, you will have to ssh to the AP first and then use the 172.16.0.X address to ssh to your mobile node. Note that the OMF experiment should only be started AFTER all the mobile nodes have been swapped in (and the RCs have been restarted by the script), else the RCs will not receive the XMPP messages sent by the EC.

Re-enable the eth0 connection

After docking, if you want your eth0 connection back : ssh to the AP, then ssh to your mobile node. After that, run :

ifconfig eth0 up ; route del default gw 172.16.0.1 ; route add default gw 10.11.31.254

Check out the ruby script /share/upload/robots/robot.rb if you want to run the OMF RC over the eth0 again (change config file + restart RC).

Using the sensor nodes

How to program the RM090 sensor node and capture its serial output

The most important step is to check if there is a /dev/rm090 device:

/dev/rm090

If the above command doesn’t return anything, enable the USB port on the EE:

/usr/local/bin/sensor_powerctrl/sensor_powerctrl.rb ENABLE

If you want to cut the power to the RM090 again, replace ENABLE by DISABLE.

The scripts for using the RM090 sensor node are located in this directory on the file server (ops):

/share/upload/sensor/

Some applications are located in:

/share/upload/sensor/apps/rm090/

The recommended way to use the sensor nodes in the w-iLab.t testbed is using the OMF framework. Check out the OMF website for some basic tutorials.

An example OMF Experiment description is located here:

/share/upload/omf6/sensor/rm090_test.rb

This script uses the helper script rm090_start.rb to program the sensor node (example RadioPerf code) and start the (TinyOS-specific) SerialForwarder to capture the serial output of the sensor node. Copy the file above to your own user directory and modify the slice and project name before running the experiment. Also make sure that the node names reflect the actual hostname of the nodes in use. For jFed users, the project name will be wall2-ilabt-iminds-be or ch-geni-net, depending on the authority you use. The slice name is the name you chose when starting your jFed experiment.

Run the experiment (on an Experiment Controller) with:

omf_ec -u amqp://labwiki.test.atlantis.ugent.be --oml_uri tcp:am.wilab2.ilabt.iminds.be:3004 rm090_test.rb

After the experiment, the results should be logged in a database that can be queried through the PostgreSQL webinterface. The database should be named the same as your experiment ID (unless you specified the experiment ID yourself). Login credentials are wilabuser/wilabuser .

How to use the Environment Emulator

An example OMF Experiment description to do power measurements on the EE is located here:

/share/upload/omf6/sensor/ee_test.rb

Copy the file above to your own user directory and modify the slice and project name before running the experiment. Also make sure that the node names reflect the actual hostname of the nodes in use.

Run it with:

omf_ec -u amqp://labwiki.test.atlantis.ugent.be --oml_uri tcp:am.wilab2.ilabt.iminds.be:3004 ee_test.rb

After the experiment, the results should be logged in a database that can be queried through the PostgreSQL webinterface. The database should be named the same as your experiment ID (unless you specified the experiment ID yourself). Login credentials are wilabuser/wilabuser .

Howto re-route iPerf traffic over Zigbee nodes

The following tutorial will explain how to set up a bridge over two Zigbee RM090 nodes in the w-iLab.t testbed, over which any UDP traffic can be sent. This tutorial will use a simple iPerf stream to demonstrate.

First off, the architecture of the setup looks like:

_images/architecture.png

Flashing the wsnbridge.ihex to the sensornode is done by (also see REF_HOWTO_SENSORNODE):

/share/upload/sensor/ibcn-f5x-tos-bsl --invert-reset --swap-reset-test -c /dev/rm090 -r -e -I -5 -p /share/upload/sensor/apps/rm090/wsnbridge/wsnbridge.ihex

The config of the wsnbridge-app is as follows (for more details, check manpage by executing ./wsnbridge -h):

  • Serverside WSN-bridge:
wsnbridge dev=/dev/rm090 fixedChannel=15 dumpFrames2Log=no

(implicitly act as a server and opens up a UDP socket on localhost:2010)

  • Clientside WSN-bridge:
wsnbridge dev=/dev/rm090 server=localhost:2010 fixedChannel=15 confLocalPanID=2010 confLocalShortAddr=301 dumpFrames2Log=no

(explicitly act as client, and connect to a serving entity on localhost:2010 to get packets)

This sets up a Zigbee link over the two sensor nodes, and provides an UDP port on both the server and the client side.

To run communication over the channel, use the iPerf-tool:

  • Serverside iPerf (run on Clientside WSN-bridge node):
iperf -C -u -s -p 2010 -i 1

(Act as server and listen on port 2010 for connection, the wsnbrige client will dump his packets on this port 2010)

  • Clientside iPerf (run on Serviceside WSN-bridge node):

Here we can play with bandwidth settings et cetera. An example is:

iperf -C -u -c localhost -b 135k -l 116B -t 10 -i 1 -p 2010

(start iperf as client and connect to wsnbridge server that listens on localhost:2010)

Overview of the two entities:

_images/architecture_cmds.png

Playing with iPerf parameters, you need to follow followling rules:

  • Bitrate >= 12B * 8 * 2 = 192: iperf -C -u -c localhost -b 192 -l 12B -t 10 -i 1 -p 2010
  • Max MTU is 116B, larger frames will be dropped: keep iPerfs -l flag below 116B

How to setup openwsn development environment for use with Zolertia Z1 and Remote nodes

First install all openwsn development environment requirements:

sudo apt-get update
sudo apt-get install -y git
mkdir openwsn
cd ./openwsn/
git clone https://github.com/openwsn-berkeley/openwsn-fw.git
git clone https://github.com/openwsn-berkeley/openwsn-sw.git
git clone https://github.com/openwsn-berkeley/coap.git
cd ./openwsn-fw/
sudo apt-get install -y python-dev
sudo apt-get install -y scons
cd ../openwsn-sw/software/openvisualizer
sudo apt-get install -y python-pip
sudo apt-get install -y python-tk
sudo pip install bottle
sudo pip install PyDispatcher
sudo pip install intelhex
sudo pip install Sphinx
sudo pip install netifaces
sudo pip install yappi
sudo pip install pyzmq
sudo pip install openwsn-coap
sudo pip install PySerial
sudo apt-get install -y gcc-arm-none-eabi
sudo apt-get install -y gcc-msp430

The above commands should have setup the development environment of openwsn. In order to test if all is ok we shall try to compile the node firmware for opensim (the simulator of openwsn) and execute a simple simulation. Firstly we need to compile the node firmware for opensim by defining the platform as python. Follow these steps to setup a simulation:

cd openwsn/openwsn-fw
scons board=python toolchain=gcc oos_openwsn
cd ..

If all is ok the ouput of the build operation should exist in the build/python directory created. And finally start the simulation:

cd openwsn-sw/software/openvisualizer
sudo scons runweb --sim

Once the simulator is booted, a browser can be launched to open 127.0.0.1:8080 , where you can see the openWSN web interface. Inside the ssh terminal you can launch a browser by simple executing “firefox” . If it is not installed,. install it with “sudo apt_get install firefox” first. If you are able to see the openwsn web interface then your environment is sane and you can continue on using openwsn for other platforms like Z1 or Zolertia according to the official openwsn HowTo’s and tutorials.

Using the ALIX devices

Use the inventory to locate the ALIX devices.

Create an experiment (see first tutorial) and drag in some servers and some ALIX devices. Now draw some links between the SERVER and ALIX. If you want to connect more than one ALIX device to the server, drag in a switch and connect all devices (SERVER + ALIX’s) to it.

Configure the IP address of ethX of the server (X: value between 1 and 5) to the following:

  • address 172.16.0.100
  • netmask 255.255.255.0

Set up NAT forwarding on the server to get internet access from the ALIX nodes (this assumes eth1 to be chosen as experiment interface on the server):

  • iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
  • iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
  • iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

The ALIX devices are configured with the following IP addresses:

  • alix1: 172.16.0.1
  • alix2: 172.16.0.2
  • alix3: 172.16.0.3
  • alix4: 172.16.0.4

... etc

If the connections & IP addresses are set up OK, you should now be able to log into the ALIX devices from the server by using the following credentials:

  • username: root
  • password: 123456

Using multiple ALIX devices with jFed

Instead of dragging in a switch (as would be done in the native interface) drag in an ALIX, a server and create a link between the two. Then drag in another ALIX and drag a link between the most recent ALIX and the already created link.

_images/using_multiple_alixes.png

Using the USRP devices

(original tutorial by lwei@intec.ugent.be, modified by vsercu@intec.ugent.be)

!!!! usrp1,2,3,4,5,6 are now statically wired to server9,10,11,13,15,16 respectively. The USRPs are connected to the second ethernet interface (eno2 in UBUNTU16.04), on which you need to manually define an IP address (see the inventory to know the exact IP). Do NOT draw any links in jFed for the USRPs. (Reserving and selecting in jFed is still needed) !!!! Check the inventory page for more details.

The NS file you need to swap in the appropriate resources:

# Generated by NetlabClient
set ns [new Simulator]
source tb_compat.tcl

##define serv5 (a server with 5 ethernet ports), usrp5 and link5 (experiment backplane link between server and usrp)
set serv9 [$ns node]
tb-fix-node $serv9 server9

set u1 [$ns node]
tb-fix-node $u1 usrp1
$u5 add-desire USRP 1.0

#$ns rtproto Static
$ns run

It is possible to extend the NS file in order to make use of more URSP’s.

Checking USRP connectivity

After swapping in, try to ping USRP from the serv5 node. As assigned in the NS file, its IP is 192.168.50.2.

If the ping succeeds, run uhd_usrp_probe to confirm the USRP connectivity;

(If you cannot ping an URSP or the connectivity confirmation fails: It is a known issue that URSP’s sometimes have difficulty with the VLAN-setup of Emulab. Try to reset the interface via the inventory page: http://inventory.wilab2.ilabt.iminds.be. Log in by clicking the red key, then click on the URSP that has difficulties and (1) POWEROFF, wait 10 seconds, (2) RESET INTERFACE, wait 10 seconds, and HARD REBOOT. The USRP should be up and running after 10 seconds. Try pinging again. Repeat above steps in the unlikely event that the USRP is still not answering.)

After you can ping USRP, run the following command to ensure the buffer size is large enough, and USRP sensing engine can run at its optimum:

  • sudo sysctl -w net.core.wmem_max=1048576
  • sudo sysctl -w net.core.rmem_max=50000000

The default image of the host server has UHD 003.005.003, feel free to install your own updated USRP software (and save your own Emulab image).

Theoretically you should be able to load firmware on the USRP, but on wilab2 loading firmware and FPGA image on the USRP is strictly forbidden. Please inform the testbed support team if programming the USRP is deemed necessary.

Using the USRP

In /share/cognitive-radio/usrpse on OPS, there are several example scripts:

  • README: which describes briefly how to run the sensing engine
  • teminologylog.txt: not important, just a file generated when the sensing engine binary is properly ended
  • usrpse_wrap.rb: the ruby wrapper that makes the running of the sensing engine slightly more user friendly, it calls one of the usrpse_xxx binary and the sensing result is printed to the the standard output.
  • usrpse_nonesweeping, usrpse_sweeping: the two binaries called by the usrpse_wrap.rb

The USRP sensing engine can do two types of measurement, either measure the signal strength of a particular sets of channels in dBm, or measure the duty cycle of a channel in %.

  • For the measurement in dBm, there is again 3 sub modes, maxhold, minhold or average, by default the detector does averaging. To change detector mode, you need to use the detector_mode option. The measurement of signal strength always covers all channels in the 2.4 GHz ISM band.
  • For selecting the dutycycle mode, you need to assign 0 to the detector_mode option. You also need to specify a range of channels you want to measure. This is done via the first_channel option. When the first channel is selected, the sensing engine automatically measures all channels covered within 25 MHz, as this is the maximum sample rate allowed by USRP. In this mode, the sensing engine reports how much percent of the time the measured energy is above -70 dBm.
  • You always need to specify what kind of channel, eg Wi-Fi or Zigbee, that you want to measure, this is specified via the se_mode option.

A few examples are listed below. The IP of USRP in the examples is written as “192.168.X0.2”, you need to replace the IP.

./usrpse_wrap.rb --se_mode WLAN_G --args 192.168.X0.2 Executes the sensing engine to measure RSSI of all channels in 802.11g standard in averaging mode, the unit is “dBm”.

./usrpse_wrap.rb --se_mode WLAN_G --args 192.168.X0.2 --detector_mode 2 Executes the sensing engine to measure the RSSI of all channels in 802.11g standard in maxhold mode, the unit is “dBm”.

./usrpse_wrap.rb --se_mode WLAN_G --args 192.168.X0.2 --detector_mode 0 --first_channel 2 Executes the sensing engine to measure the duty cycle of channel 2 in 802.11g standard, unit is “%”.

./usrpse_wrap.rb --se_mode ZIGBEE --args 192.168.X0.2 --detector_mode 0 --first_channel 13 Executes the sensing engine to measure the duty cycle of channel 13, 14, 15,16 in Zigbee standard, the unit is “%”.

Spectrum sensing at w-iLab.2

There are several ways to do spectrum sensing at w-iLab.2.

Using the WiFi cards

Scanning for access points

The simplest form of spectrum scanning involves searching for other wireless access points. Log into a WiFi node (ZOTAC/DSS/APU) and run the following commands:

ifconfig wlan0 down
iwconfig wlan0 mode managed
ifconfig wlan0 up
iwlist wlan0 scan

If everything went well, then you should now see all the access points which are in range of the sniffing WiFi node. The Signal strength of the access points is expressed in dBm and will vary somewhere between -40dBm (signal is strong) to -90dBm (signal is very weak).

If you prefer a fancier representation of the info, you can use the following commands:

apt-get install wavemon
ifconfig wlan0 down
iwconfig wlan0 mode managed
ifconfig wlan0 up
wavemon -i wlan0
# type 's' to start scanning , type 'q' to quit

Energy detection using the ath9k wireless driver

The ath9k driver can be used to do energy detection with the WiFi cards installed in ZOTAC nodes (both phy0 and phy1), DSS nodes (only phy1) and MOBILE nodes (only phy1). More information on the spectral scan functionality of ath9k.

If you are not running your experiment on w-iLab.2, then you first need to compile the source code:

apt-get install libnl-genl-3-dev
git clone https://github.com/WirelessTestbedsAcademy/BasicSensing.git
cd BasicSensing/wilabt/ath9k_spectral_scan
make

To start the scanning:

sudo iw phy phy0 interface add mon0 type monitor
sudo ifconfig mon0 up
sudo iw dev mon0 set channel 11
sudo /share/upload/omf6/wifitests/ath_spec_scan -p phy0 -t -70

You should now see the Channel Occupancy Ratio (COR) of channel 11 (2462MHz). Try setting up an iPerf stream between 2 wireless nodes near the sniffer node and see what the impact is on the COR.

The output looks like this: current_time sniffer_mac frequency COR previous_dur
  • current_time: Starting unix epoch timestamp (milliseconds)
  • sniffer_mac: sniffer node mac address
  • frequency: sniffing frequency
  • COR: Channel Occupancy Ratio
  • previous_dur: measurement duration (milliseconds)

To show all options of the spectral scan tool:

./ath_spec_scan -h

There is also a more advanced version that is capable of displaying RSSI values of WiFi and ZigBee. This version is compatible with OML and can thus easily store its data in an OML server (or just a local file if no OML server is available).

apt-get install libnl-genl-3-dev
git clone https://github.com/WirelessTestbedsAcademy/BasicSensing.git
cd BasicSensing/wilabt/ath9k_spectral_scan/oml
make
sudo iw phy phy0 interface add mon0 type monitor
sudo ifconfig mon0 up
sudo iw dev mon0 set channel 11
sudo ./ath_spec_scan -p phy0 -t -70 --oml-id test1 --oml-domain ath_spec_scan --oml-collect file:test1.log

Update the ath9k wireless driver

The steps below can be followed to update the ath9k to the latest backports driver. The example is given for version 3.18.1, but the steps can be repeated for any version.

After updating the ath9k driver, please make sure everything still works as desired. For example, v3.17.1 is known to cause issues when using click modular router to inject packets.

sudo -s
wget https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.18.1/backports-3.18.1-1.tar.xz
tar -xJf backports-3.18.1-1.tar.xz
cd backports-3.18.1-1/
cd drivers/net/wireless/ath/
#the steps below will make sure the ath9k driver uses the correct regulatory restrictions for your country
wget --no-check-certificate https://dev.openwrt.org/export/32952/trunk/package/mac80211/patches/403-ath_regd_optional.patch
patch -Np5 -i 403-ath_regd_optional.patch
echo "#define ATH_USER_REGD 1" | cat - regd.c > /tmp/out && mv /tmp/out regd.c
cd -
make defconfig-ath9k
make
make install
reboot

After reboot, check if your new driver is correctly installed by issuing the command below, which should result in showing you the correct backports version on the first output line.

modinfo ath9k

Test wireless connectivity using click modular router software

Click is a software architecture for building flexible and configurable routers. More info can be found on the Click home page.

In this tutorial, we will use click to inject packets in the wireless interface and extract RSSI values at the receiving side.

To start, swap in some nodes with the default UBUNTU14-64-wilab image (this image will be auto-selected if you don’t specify an OS yourself). Make sure these nodes can reach eachother over the wireless.

Execute the following commands on both nodes :

# setup a monitor interface called wlan0mon
iw dev wlan0 interface add wlan0mon type monitor
# bring up the interface
ifconfig wlan0mon up
# choose a channel
iw dev wlan0mon set channel 40

Log in to the sender node and create a file called generatepackets.click containing the following lines :

AddressInfo(myether eth0:eth)

packetgenerator :: FlexiSource(\<aabbccddeeff>, 10, 9000, DATASIZE 100);
packetgenerator
        -> EtherEncap(0x0900, myether, FF:FF:FF:FF:FF:FF)
        -> WifiEncap(0x00, 0:0:0:0:0:0)
        -> Queue(10)
        -> rate :: SetTXRate(2)
        -> seq :: WifiSeq()
        -> encap :: RadiotapEncap()
        -> Print("Sending This",92)
        -> to_dev :: ToDevice (wlan0mon);

This script will send broadcast packets at 1Mbit/sec over the wlan0mon interface. Run the following command to start the sender:

click generatepackets.click

Log in to the receiver node and create a file called printinfo.click containing the following lines :

FromDevice(wlan0mon)
        -> RadiotapDecap()
        -> txfilter :: FilterTX()
        -> WifiDecap()
        -> filterTestPackets :: Classifier(12/0900,-)
        -> PhyInfoPrint()
        -> Discard ();

txfilter[1] -> Print("Feedack Packet")
        -> Discard ();

// Interfering packets from other setup
filterTestPackets[1]->Discard();

Execute the following commands on the receiver node :

click printinfo.click

You should now see some output on the receiving node, in the following CSV format:

Timestamp;Sequence number;SenderMAC;Rate;Signal

Set up a 802.11ac access point and client

All nodes of type DSS and MOBILE are equipped with one 802.11a/b/g/n WiFi card (mostly wlan0) and one 802.11ac WiFi card (mostly wlan1).

Reserve two nodes of type DSS or MOBILE to run this tutorial, preferably right next to eachother to achieve high throughput. The default image on these nodes should have all necessary drivers, firmware and config files in place.

To setup an 802.11ac AP, log into a node and execute the following the following script:

/usr/local/bin/start80211acAP.sh

Take a look at the script to see which configuration options need to be passed to hostapd in order to succesfully set up an AP using 802.11ac. The script will assign an IP address to wlan1 in the 172.22.22.0/24 range. The last octet is taken from the IP address of the wired control interface (mostly eth0). For example node 43 (see the inventory) will have IP address 172.22.22.43 . It will also start a UDP iPerf server instance on wlan1.

Check for errors by running the following command:

screen -r hostapd

Now log into the second node and execute the following script to connect to the AP:

/usr/local/bin/start80211acStation.sh

This script will associate with the AP and set an IP address on wlan1 as shown in the previous section (prefix 172.22.22.X with X as the last octet from the control IP).

Check for errors by running the following command:

screen -r wpas

If all went fine, you can now try to ping the AP (172.22.22.43 in this example) from the client (172.22.22.44 in this example). If that succeeds, it is time to do some througput tests with iPerf:

/usr/bin/iperf -c 172.22.22.43 -i 1 -t 10000 -b 650M

In the above example, we could reach a throughput of about 400Mbits/sec. This is because 10dB attenuators are attached to every antenna (so 20dB attenuation per link). The AC cards on the MOBILE nodes have no attenuators, which means that if the mobile node is very near to the AP, throughput of more that 550Mbits/sec can be reached!

If the above tutorial does not work for you, please do the following troubleshooting steps and see if it can be fixed:

# verify the version of the ath10k_pci driver (this tutorial was tested using backports version 3.18).
# Check previous tutorials on how to update the driver.
modinfo ath10k_pci

# this tutorial is known to cause troubles with some firmware versions.
# If dmesg is complaining about not finding firmware-2.bin, you probably don't have the correct firmware files.
dmesg | grep ath10k
# Try the commands below to fix it, or try to find a solution on https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/firmware
rm /lib/firmware/ath10k/QCA988X/hw2.0/*
cp /share/80211ac/firmware/* /lib/firmware/ath10k/QCA988X/hw2.0/
reboot

# This tutorial uses a custom compiled hostapd version located at /usr/local/bin/hostapd.
# If for some reason the file is not there, or hostapd gives errors at startup, try the following:
wget http://w1.fi/releases/hostapd-2.4.tar.gz
tar xzvf hostapd-2.4.tar.gz
cd hostapd-2.4/hostapd
cp defconfig .config
nano .config
# Check if the following variables are all set to 'y' (more info can be found on https://wireless.wiki.kernel.org/en/users/documentation/hostapd)
CONFIG_WPS=y
CONFIG_DRIVER_NL80211=y
CONFIG_IEEE80211N=y
CONFIG_IEEE80211AC=y
CONFIG_ACS=y
# Now recompile hostapd and copy the resulting binary
make
cp hostapd /usr/local/bin/

# If some of the config files or scripts are missing, copy them from the share:
cp /share/80211ac/scripts/* /usr/local/bin/
mkdir -p /usr/share/11ac/
cp /share/80211ac/conf/* /usr/share/11ac/

Using the LTE equipment

Transmit LTE traffic (ping - iperf)

Setup

The following picture depicts the LTE network’s architecture

_images/w-ilab.t_LTE_architecture.jpg

Requirements

  • A server node to host the SiRRAN EPC image
  • One or more femtocells
  • One or more LTE compatible nodes
  • Optional - A node to host the LTErf image (for OMF enabled experimentation)

OS Images

The following table shows the name of each respective OS image, the type of the OS and their public urls.

Functionality, name, type and public url of the respective LTE OS images
Functionality Name Type Public urn or url
SiRRAN EPC SIRRAN_EPC_v1_7_50 Centos urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:SIRRAN_EPC_v1_7_50
LTErf LTErf-v2 Ubuntu 12.04 64bit https://www.wall1.ilabt.iminds.be/image_metadata.php?uuid=37d19e2c-ca91-11e5-a2c8-003048d1cfa6
LTE UE LTE_UE_Ubuntu_14_04_64bit_v2 Ubuntu 14.04 64bit urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:LTE_UE_Ubuntu_14_04_64bit_v2

Experiment Descirption in W-iLab.2 using JFED

You can use the following rspec file for LTE experimentation using JFED in W-iLab.2. The file describes the topology, which is depicted in the picture bellow and contains the EPC, the LTErf, the 2 femtocells and all the enabled LTE nodes (fixed and mobile). The experimenter can modify the file regarding his/her needs.

_images/w-ilab.2_rspec.png
<?xml version='1.0'?>
<rspec xmlns="http://www.geni.net/resources/rspec/3" type="request" generated_by="jFed RSpec Editor" generated="2016-10-20T14:55:14.178+02:00" xmlns:emulab="http://www.protogeni.net/resources/rspec/ext/emulab/1" xmlns:jfedBonfire="http://jfed.iminds.be/rspec/ext/jfed-bonfire/1" xmlns:delay="http://www.protogeni.net/resources/rspec/ext/delay/1" xmlns:jfed-command="http://jfed.iminds.be/rspec/ext/jfed-command/1" xmlns:client="http://www.protogeni.net/resources/rspec/ext/client/1" xmlns:jfed-ssh-keys="http://jfed.iminds.be/rspec/ext/jfed-ssh-keys/1" xmlns:jfed="http://jfed.iminds.be/rspec/ext/jfed/1" xmlns:sharedvlan="http://www.protogeni.net/resources/rspec/ext/shared-vlan/1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.geni.net/resources/rspec/3 http://www.geni.net/resources/rspec/3/request.xsd ">
  <node client_id="EPC" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+server8">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:SIRRAN_EPC_v1_7_50"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="230.0" y="32.5"/>
    <interface client_id="EPC:if0">
      <ip address="192.168.1.1" netmask="255.255.255.0" type="ipv4"/>
    </interface>
  </node>
  <node client_id="LTErf" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+server7">
    <sliver_type name="raw-pc">
      <disk_image name="https://www.wall1.ilabt.iminds.be/image_metadata.php?uuid=37d19e2c-ca91-11e5-a2c8-003048d1cfa6"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="229.0" y="244.5"/>
    <interface client_id="LTErf:if0">
      <ip address="192.168.1.2" netmask="255.255.255.0" type="ipv4"/>
    </interface>
  </node>
  <node client_id="Femto1" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+ltefemtocell1">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+emulab-ops:GENERICDEV"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="53.5" y="138.5"/>
    <interface client_id="Femto1:if0">
      <ip address="192.168.1.10" netmask="255.255.255.0" type="ipv4"/>
    </interface>
  </node>
  <node client_id="Femto2" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+ltefemtocell2">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+emulab-ops:GENERICDEV"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="401.5" y="140.5"/>
    <interface client_id="Femto2:if0">
      <ip address="192.168.1.11" netmask="255.255.255.0" type="ipv4"/>
    </interface>
  </node>
  <node client_id="Mobile1" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+mobile1">
    <sliver_type name="raw-pc">
      <disk_image name="https://www.wilab2.ilabt.iminds.be/image_metadata.php?uuid=a16c037d-0ebc-11e5-a185-000c293cff7f"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="600.0" y="16.5"/>
  </node>
  <node client_id="Mobile2" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+mobile2">
    <sliver_type name="raw-pc">
      <disk_image name="https://www.wilab2.ilabt.iminds.be/image_metadata.php?uuid=a16c037d-0ebc-11e5-a185-000c293cff7f"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="600.0" y="56.5"/>
  </node>
  <node client_id="Mobile3" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+mobile3">
    <sliver_type name="raw-pc">
      <disk_image name="https://www.wilab2.ilabt.iminds.be/image_metadata.php?uuid=a16c037d-0ebc-11e5-a185-000c293cff7f"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="600.0" y="96.5"/>
  </node>
  <node client_id="Mobile4" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+mobile4">
    <sliver_type name="raw-pc">
      <disk_image name="https://www.wilab2.ilabt.iminds.be/image_metadata.php?uuid=a16c037d-0ebc-11e5-a185-000c293cff7f"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="599.0" y="136.5"/>
  </node>
  <node client_id="Mobile5" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+mobile5">
    <sliver_type name="raw-pc">
      <disk_image name="https://www.wilab2.ilabt.iminds.be/image_metadata.php?uuid=a16c037d-0ebc-11e5-a185-000c293cff7f"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="599.0" y="176.5"/>
  </node>
  <node client_id="Mobile6" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+mobile6">
    <sliver_type name="raw-pc">
      <disk_image name="https://www.wilab2.ilabt.iminds.be/image_metadata.php?uuid=a16c037d-0ebc-11e5-a185-000c293cff7f"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="730.5" y="16.5"/>
  </node>
  <node client_id="Mobile7" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+mobile7">
    <sliver_type name="raw-pc">
      <disk_image name="https://www.wilab2.ilabt.iminds.be/image_metadata.php?uuid=a16c037d-0ebc-11e5-a185-000c293cff7f"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="729.5" y="56.5"/>
  </node>
  <node client_id="Mobile8" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+mobile8">
    <sliver_type name="raw-pc">
      <disk_image name="https://www.wilab2.ilabt.iminds.be/image_metadata.php?uuid=a16c037d-0ebc-11e5-a185-000c293cff7f"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="729.0" y="96.5"/>
  </node>
  <node client_id="Mobile9" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+mobile9">
    <sliver_type name="raw-pc">
      <disk_image name="https://www.wilab2.ilabt.iminds.be/image_metadata.php?uuid=a16c037d-0ebc-11e5-a185-000c293cff7f"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="729.0" y="136.5"/>
  </node>
  <node client_id="Mobile10" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+mobile10">
    <sliver_type name="raw-pc">
      <disk_image name="https://www.wilab2.ilabt.iminds.be/image_metadata.php?uuid=a16c037d-0ebc-11e5-a185-000c293cff7f"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="729.5" y="177.5"/>
  </node>
  <node client_id="Mobile11" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+mobile11">
    <sliver_type name="raw-pc">
      <disk_image name="https://www.wilab2.ilabt.iminds.be/image_metadata.php?uuid=a16c037d-0ebc-11e5-a185-000c293cff7f"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="867.5" y="19.5"/>
  </node>
  <node client_id="Mobile12" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+mobile12">
    <sliver_type name="raw-pc">
      <disk_image name="https://www.wilab2.ilabt.iminds.be/image_metadata.php?uuid=a16c037d-0ebc-11e5-a185-000c293cff7f"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="869.0" y="57.5"/>
  </node>
  <node client_id="Mobile13" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+mobile13">
    <sliver_type name="raw-pc">
      <disk_image name="https://www.wilab2.ilabt.iminds.be/image_metadata.php?uuid=a16c037d-0ebc-11e5-a185-000c293cff7f"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="869.5" y="97.5"/>
  </node>
  <node client_id="Mobile14" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+mobile14">
    <sliver_type name="raw-pc">
      <disk_image name="https://www.wilab2.ilabt.iminds.be/image_metadata.php?uuid=a16c037d-0ebc-11e5-a185-000c293cff7f"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="869.5" y="137.5"/>
  </node>
  <node client_id="Mobile15" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+mobile15">
    <sliver_type name="raw-pc">
      <disk_image name="https://www.wilab2.ilabt.iminds.be/image_metadata.php?uuid=a16c037d-0ebc-11e5-a185-000c293cff7f"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="868.5" y="175.5"/>
  </node>
  <node client_id="zotacB3" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+zotacB3">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:LTE_UE_Ubuntu_14_04_64bit_v2"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="9.0" y="316.5"/>
  </node>
  <node client_id="zotacB4" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+zotacB4">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:LTE_UE_Ubuntu_14_04_64bit_v2"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="8.5" y="356.5"/>
  </node>
  <node client_id="zotacC1" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+zotacC1">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:LTE_UE_Ubuntu_14_04_64bit_v2"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="9.5" y="397.5"/>
  </node>
  <node client_id="zotacC4" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+zotacC4">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:LTE_UE_Ubuntu_14_04_64bit_v2"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="7.5" y="436.5"/>
  </node>
  <node client_id="zotacD6" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+zotacD6">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:LTE_UE_Ubuntu_14_04_64bit_v2"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="139.5" y="317.5"/>
  </node>
  <node client_id="zotacE3" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+zotacE3">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:LTE_UE_Ubuntu_14_04_64bit_v2"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="140.5" y="358.5"/>
  </node>
  <node client_id="zotacF1" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+zotacF1">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:LTE_UE_Ubuntu_14_04_64bit_v2"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="139.5" y="398.5"/>
  </node>
  <node client_id="zotacF6" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+zotacF6">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:LTE_UE_Ubuntu_14_04_64bit_v2"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="138.5" y="437.5"/>
  </node>
  <node client_id="zotacG3" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+zotacG3">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:LTE_UE_Ubuntu_14_04_64bit_v2"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="268.5" y="318.5"/>
  </node>
  <node client_id="zotacG4" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+zotacG4">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:LTE_UE_Ubuntu_14_04_64bit_v2"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="268.5" y="359.5"/>
  </node>
  <node client_id="zotacH1" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+zotacH1">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:LTE_UE_Ubuntu_14_04_64bit_v2"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="267.5" y="397.5"/>
  </node>
  <node client_id="zotacH6" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+zotacH6">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:LTE_UE_Ubuntu_14_04_64bit_v2"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="268.5" y="438.5"/>
  </node>
  <node client_id="zotacI3" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+zotacI3">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:LTE_UE_Ubuntu_14_04_64bit_v2"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="397.5" y="317.5"/>
  </node>
  <node client_id="zotacJ2" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+zotacJ2">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:LTE_UE_Ubuntu_14_04_64bit_v2"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="398.0" y="359.5"/>
  </node>
  <node client_id="zotacJ3" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+zotacJ3">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:LTE_UE_Ubuntu_14_04_64bit_v2"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="398.5" y="398.5"/>
  </node>
  <node client_id="zotacK4" exclusive="true" component_manager_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wilab2.ilabt.iminds.be+node+zotacK4">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:LTE_UE_Ubuntu_14_04_64bit_v2"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="398.0" y="438.5"/>
  </node>
  <link client_id="link0">
    <component_manager name="urn:publicid:IDN+wilab2.ilabt.iminds.be+authority+cm"/>
    <interface_ref client_id="EPC:if0"/>
    <interface_ref client_id="LTErf:if0"/>
    <interface_ref client_id="Femto1:if0"/>
    <interface_ref client_id="Femto2:if0"/>
    <link_type name="lan"/>
  </link>
</rspec>

Experiment Descirption using Emulab

The following experiment uses:

  • Server 8 to load the SiRRAN EPC image
  • Server 7 to load the LTErf image
  • Robot 10 to load the LTE UE image
  • Node E3 (25) to load the LTE UE image
  • 2 femtocells
# Generated by NetlabClient
set ns [new Simulator]
source tb_compat.tcl
# Nodes
# Femtocell 1
set lte1 [$ns node]
$lte1 add-desire LTE-FEMTOCELL 1.0
tb-fix-node $lte1 ltefemtocell1

# Femtocell 2
set lte2 [$ns node]
$lte2 add-desire LTE-FEMTOCELL 1.0
tb-fix-node $lte2 ltefemtocell2

# zotacE3 (static node 25) - dongle
set zotac1 [$ns node]
#$zotacE3 add-desire ZOTAC
tb-fix-node $zotac1 zotacE3
tb-set-node-os $zotac1 #url_of_the_UE_image_goes_here

# mobile10 (robot 10) - dongle
set robot1 [$ns node]
tb-fix-node $robot1 mobile10
tb-set-node-os $robot1 #url_of_the_UE_image_goes_here

# Node 8 - SiRRAN EPC
set serv8 [$ns node]
tb-set-node-os $serv8 #urn_of_the_EPC_image_goes_here

set serv7 [$ns node] - LTErf
tb-fix-node $serv7 server7
tb-set-node-os $serv7 #url_of_the_LTErf_image_goes_here

# Lans
set lan0 [$ns make-lan "$lte1 $lte2 $serv8 $serv7" 1000000.0kb 0.0ms]
tb-set-ip-lan $serv8 $lan0 192.168.1.1
tb-set-ip-lan $serv7 $lan0 192.168.1.2

$ns rtproto Static
$ns run

# NetlabClient generated file ends here.
# Finished at: 3/18/14 4:08 PM

Experiment Description using Qosmotec framework

You can use the following rspec file for LTE experimentation using JFED in the Qosmotec framework. The file describes the topology, which is depicted in the picture bellow and contains the EPC, the LTErf, the 2 femtocells and the two enabled LTE nodes zotacSB3 and zotacSB4. The experimenter can modify the file regarding his/her needs.

_images/qosmotec_rspec.png
<?xml version='1.0'?>
<rspec xmlns="http://www.geni.net/resources/rspec/3" type="request" generated_by="jFed RSpec Editor" generated="2016-06-27T15:59:40.234+02:00" xmlns:emulab="http://www.protogeni.net/resources/rspec/ext/emulab/1" xmlns:jfedBonfire="http://jfed.iminds.be/rspec/ext/jfed-bonfire/1" xmlns:delay="http://www.protogeni.net/resources/rspec/ext/delay/1" xmlns:jfed-command="http://jfed.iminds.be/rspec/ext/jfed-command/1" xmlns:client="http://www.protogeni.net/resources/rspec/ext/client/1" xmlns:jfed-ssh-keys="http://jfed.iminds.be/rspec/ext/jfed-ssh-keys/1" xmlns:jfed="http://jfed.iminds.be/rspec/ext/jfed/1" xmlns:sharedvlan="http://www.protogeni.net/resources/rspec/ext/shared-vlan/1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.geni.net/resources/rspec/3 http://www.geni.net/resources/rspec/3/request.xsd ">
  <node client_id="EPC" exclusive="true" component_manager_id="urn:publicid:IDN+wall1.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wall1.ilabt.iminds.be+node+n073-23a">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:SIRRAN_EPC_v1_7_50"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="247.0" y="261.5"/>
    <interface client_id="EPC:if0">
      <ip address="192.168.1.1" netmask="255.255.255.0" type="ipv4"/>
    </interface>
  </node>
  <node client_id="Femto1" exclusive="true" component_manager_id="urn:publicid:IDN+wall1.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wall1.ilabt.iminds.be+node+switch1-13-46">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wall1.ilabt.iminds.be+image+emulab-ops:GENERICDEV"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="91.5" y="162.5"/>
    <interface client_id="Femto1:if0">
      <ip address="192.168.1.12" netmask="255.255.255.0" type="ipv4"/>
    </interface>
  </node>
  <node client_id="Femto2" exclusive="true" component_manager_id="urn:publicid:IDN+wall1.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wall1.ilabt.iminds.be+node+switch1-13-47">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wall1.ilabt.iminds.be+image+emulab-ops:GENERICDEV"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="389.5" y="161.5"/>
    <interface client_id="Femto2:if0">
      <ip address="192.168.1.13" netmask="255.255.255.0" type="ipv4"/>
    </interface>
  </node>
  <node client_id="LTErf" exclusive="true" component_manager_id="urn:publicid:IDN+wall1.ilabt.iminds.be+authority+cm">
    <sliver_type name="raw-pc">
      <disk_image name="https://www.wall1.ilabt.iminds.be/image_metadata.php?uuid=37d19e2c-ca91-11e5-a2c8-003048d1cfa6"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="247.0" y="55.5"/>
    <interface client_id="LTErf:if0">
      <ip address="192.168.1.2" netmask="255.255.255.0" type="ipv4"/>
    </interface>
  </node>
  <node client_id="UE1" exclusive="true" component_manager_id="urn:publicid:IDN+wall1.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wall1.ilabt.iminds.be+node+zotacSB3">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:LTE_UE_Ubuntu_14_04_64bit_v2"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="560.0" y="97.5"/>
  </node>
  <node client_id="UE2" exclusive="true" component_manager_id="urn:publicid:IDN+wall1.ilabt.iminds.be+authority+cm" component_id="urn:publicid:IDN+wall1.ilabt.iminds.be+node+zotacSB4">
    <sliver_type name="raw-pc">
      <disk_image name="urn:publicid:IDN+wilab2.ilabt.iminds.be+image+wall2-ilabt-iminds-be:LTE_UE_Ubuntu_14_04_64bit_v2"/>
    </sliver_type>
    <location xmlns="http://jfed.iminds.be/rspec/ext/jfed/1" x="559.0" y="229.5"/>
  </node>
  <link client_id="link0">
    <component_manager name="urn:publicid:IDN+wall1.ilabt.iminds.be+authority+cm"/>
    <interface_ref client_id="EPC:if0"/>
    <interface_ref client_id="Femto1:if0"/>
    <interface_ref client_id="Femto2:if0"/>
    <interface_ref client_id="LTErf:if0"/>
    <link_type name="lan"/>
  </link>
</rspec>

LTE node preparation (UEs)

Scripted way

The LTE UE OS image comes with a script that automates the attachment and configuration procedure.
To run the script go to the /share/upload/LTE/bash_script folder and run:
sudo bash configure_lte_dongle -c

To reset the dongle run:

sudo bash configure_lte_dongle -r

For check all the availalbe functionalities run:

sudo bash configure_lte_dongle -h

Manually

Alternativelly, the same procedure can be done manually.
To attach the dongle to the EPC and obtain an IP address type the next AT commands using a serial communication software like minicom:
AT+COPS=? # to search for the available networks
AT+COPS=1,2,"22345" # to register to a network with PLMN code "22345" which is the iMinds PLMN code
AT+CGATT=1 # to attach to the registered network
AT+CGDCONT=1,"IP","default" # where "default" is the iMinds APN
AT^NDISDUP=1,1 # to initialize the NDIS connection
AT^DHCP? # to obtain an IP address

The AT^DHCP? command returns the IP in the following HEX form: 203000a,fcffffff,103000a,103000a,8080808,4040808,100000000,50000000 In order to convert the IP to decimal type run the following command with the returned IP as parameter.

perl -e 'print join(",",map { join(".", unpack("C4", pack("L", hex))) } split /,/, shift),"\n"' 203000a,fcffffff,103000a,103000a,8080808,4040808

Afterwards, you have to enable the wwan0 interface and assign the obtained IP address

As an additional step, you have to perform an SSH connection to the node (from an other separate node) using its control interface IP address. This is necessary as we need to change the default gateway in order the node to be able to communicate using the wwan0 interface.

Finally, you have to delete the default gateway and replace it with the EPC’s address.

sudo route del default gw 10.11.31.254
sudo route add default gw 10.0.3.1 dev wwan0

Experimentation

To ping the wwan0 interface on each LTE node from the EPC and vice versa

ping 10.0.3.1 # tap0 interface of EPC
ping 10.0.3.2 # wwan0 interface of LTE node 1
ping 10.0.3.3 # wwan0 interface of LTE node 2

In order to send an iperf traffic between the two LTE nodes or between a node and the EPC run the following commands for the server and the client respectively

iperf -s -u -i 1 # For the server
iperf -u -c [ip of the server] -b 100M -i 1 -t 40 # For the client

Using the Huawei E3372h-153 dongles

The Huawei E3372h USB LTE dongles are configured in HiLink mode. This means that the dongle functions as router performing NAT. For this reason, HiLink mode cannot be used for remote access applications (e.g. Remote Desktop, VNC, web servers, etc.) where “inbound” connections are initiated by computers on the Internet. To use HiLink mode, your application must require only “outbound” initiated connections (e.g. web browsing, email, etc.), or you must implement a VPN connection to another device which is initiated by the router which has the HiLink mode modem installed.

Switch mode Some times the OS recognizes the dongle as CD (12d1:1f01) or HiLink modem (12d1:14dc). In order to check the mode of the attached dongle run:

lsusb

You should see something like:

Bus 001 Device 004: ID 12d1:1f01 Huawei Technologies Co., Ltd.
or
Bus 001 Device 006: ID 12d1:14dc Huawei Technologies Co., Ltd.

If the dongle is in CD (12d1:1f01) mode then you should switch it to HiLink (12d1:14dc) mode. Normally you have to do this procedure once and the modem stays in HiLink mode until it is switched manually to another mode. To do so you have to create in your home folder two files named:

  • sw_project_mode.sh
  • sw_project_mode.xml

Then for the sw_project_mode.sh paste the following code:

curl -X POST -d @sw_project_mode.xml http://192.168.8.1/CGI
read -p "prompt"

and for the sw_project_mode.xml paste the following code:

<?xml version="1.0" encoding="UTF-8"?>
<api version="1.0">
<header>
        <function>switchMode</function>
</header>
<body>
        <request>
                <switchType>0</switchType>
        </request>
</body>
</api>

In order to switch to HiLink (12d1:14dc) mode run in the folder where you created the files the following command:

sudo bash sw_project_mode.sh

If the script does not exit press Ctrl+C to kill it. Verify that the dongle has switched to HiLink (12d1:14dc) mode by running:

lsusb

When the dongle is in HiLink (12d1:14dc) mode, creates an eth1 interface. You can verify this by running:

ifconfig

Connect to the LTE network

The dongles are preconfigured to attach to the LTE network. This can be verifies by checking the desired IMSI in the “Active subscribers” list of the EPC.

To change the network settings of the dongle in HiLink (12d1:14dc) mode you have to access the Web GUI of the dongle. This can be found in the following url:

192.168.8.1

To be able to access the url first you have to configure the dongle’s interface (normally eth1) to an address in the same range. To do so you can either run the dhclient command:

dhclient eth1

or assign an (unused) IP address manually. For instance:

sudo ifconfig eth1 192.168.8.4 up

The from the command line (install and) run firefox using X-forwarding. By accessing the 192.168.8.1 address and going to Settings -> Profile Management tab you can configure the APN of the desired LTE network.

  • Profile name: default
  • username: leave it empty
  • password: leave it empty
  • APN: default

At the Settings -> Mobile Connection tab activate the roaming option.

Then, you must be able to see your dongle in the “Active subscribers” list of the EPC.

Ping the EPC

To ping the EPC from a node using a Huawei E3372h-153 dongle you have to add the following ip route:

ip route add 10.0.3.0/24 via 192.168.8.1 dev eth1

Control an Android smarphone via ADB

For experimentation with an Android smartphone load the following image to the node on which the smartphone is attached to.

Functionality, name, type and public url of the respective LTE OS images
Functionality Name Type Public url
Android Smartphone LTE_Android_Ubuntu_14_04_v1 Ubuntu 14.04 64bit https://www.wall1.ilabt.iminds.be/image_metadata.php?uuid=d0f16795-95ce-11e6-961b-003048d1cfa6

This image offers pre-installed the ADB tool to control the Android smartphone via USB. The ADB tool can be found under:

/android/android-sdk-linux/platform-tools

Initial steps

The first time you login into the node execute the following commands:

cd /android/android-sdk-linux/platform-tools
sudo ./adb devices
sudo ./adb kill-server
sudo cp /share/upload/LTE/android/keys/adbkey ~/.android/
sudo cp /share/upload/LTE/android/keys/adbkey.pub ~/.android/
sudo ./adb devices

This way you will replace the keys that are used for authentication between the node and the smartphone with the predefined ones.

Shell access

To gain shell access to the Android device run:

cd /android/android-sdk-linux/platform-tools
sudo ./adb shell

In the Android shell you can type su in order to gain root access.

Remote Android screen access

The afforementioned image comes with androidscreencast pre-installed. This tool allows the experimenter to get remote access of the smartphone’s screen.

cd /android/android-sdk-linux/platform-tools
javaws androidscreencast.jnlp

Press “Run” or “Yes” in all the pop-up windows that appear to gain access to the smartphone’s screen.

Manage APNs

W-iLab.2 has the following APN details:
name: default
mmc: 223
mnc: 45
username: “”
password: “”
Open an adb shell
cd /android/android-sdk-linux/platform-tools
./adb shell
su

Check if your carrier is listed in the default list of carriers. Origins in [] are optional

content query --uri content://telephony/carriers [--where "name=''"]

If your carrier is not listed, you have to add it to the list.

content insert --uri content://telephony/carriers --bind name:s:"default" --bind numeric:s:"22345" --bind type:s:"" --bind mcc:i:223 --bind mnc:s:45 --bind apn:s:default  --bind user:s:"" --bind password:s:""

To delete the carrier run:

content delete --uri content://telephony/carriers --where "numeric='22345'"

Exit the shell

exit
To see the APN in tge access points screen in the settings of the smartphone you have to add the following xml file with name com.android.settings_preferences.xml under the /data/data/com.android.settings/shared_prefs/ folder of the Android smartphone.
<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
    <set name="bearer_multi">
        <string>0</string>
    </set>
    <string name="apn_http_proxy"></string>
    <string name="select_usb_configuration">mtp</string>
    <boolean name="wait_for_debugger" value="false" />
    <boolean name="show_cpu_usage" value="false" />
    <boolean name="force_hw_ui" value="false" />
    <boolean name="bugreport_in_power" value="false" />
    <string name="apn_type"></string>
    <string name="apn_mnc">45</string>
    <boolean name="pointer_location" value="false" />
    <boolean name="keep_screen_on" value="false" />
    <boolean name="mobile_data_always_on" value="false" />
    <string name="apn_mms_proxy"></string>
    <boolean name="legacy_dhcp_client" value="false" />
    <boolean name="enable_adb" value="true" />
    <string name="mvno_match_data"></string>
    <string name="apn_protocol">IP</string>
    <boolean name="bt_hci_snoop_log" value="false" />
    <boolean name="debug_layout" value="false" />
    <boolean name="wifi_aggressive_handover" value="false" />
    <string name="apn_apn">default</string>
    <boolean name="show_hw_screen_udpates" value="false" />
    <string name="apn_http_port"></string>
    <boolean name="strict_mode" value="false" />
    <boolean name="wifi_display_certification" value="false" />
    <boolean name="show_hw_layers_udpates" value="false" />
    <boolean name="usb_audio" value="false" />
    <boolean name="wifi_allow_scan_with_traffic" value="false" />
    <string name="apn_user"></string>
    <boolean name="show_screen_updates" value="false" />
    <string name="mvno_type"></string>
    <boolean name="show_touches" value="false" />
    <boolean name="debug_view_attributes" value="false" />
    <string name="apn_roaming_protocol">IP</string>
    <boolean name="wifi_verbose_logging" value="false" />
    <boolean name="immediately_destroy_activities" value="false" />
    <boolean name="oem_unlock_enable" value="true" />
    <string name="apn_mcc">223</string>
    <boolean name="verify_apps_over_usb" value="true" />
    <boolean name="show_all_anrs" value="false" />
    <boolean name="force_msaa" value="false" />
    <string name="apn_name">default</string>
    <string name="apn_password"></string>
    <boolean name="carrier_enabled" value="true" />
    <string name="apn_mms_port"></string>
    <boolean name="disable_overlays" value="false" />
    <string name="apn_mmsc"></string>
    <string name="apn_server"></string>
    <boolean name="force_rtl_layout_all_locales" value="false" />
    <string name="select_logd_size">262144</string>
</map>

This file is located under /share/upload/LTE/android/apn/ folder. To copy it in the afforementioned folder of the Android smartphone run:

cd /android/android-sdk-linux/platform-tools
adb push /share/upload/LTE/android/apn/com.android.settings_preferences.xml /sdcard
./adb shell
su
cp /sdcard/com.android.settings_preferences.xml /data/data/com.android.settings/shared_prefs/com.android.settings_preferences.xml
rm /sdcard/com.android.settings_preferences.xml
exit
exit

Toggle Data

cd /android/android-sdk-linux/platform-tools
./adb shell svc data enable
./adb shell svc data disable

Toggle Wi-Fi

cd /android/android-sdk-linux/platform-tools
./adb shell su -c 'svc wifi enable'
./adb shell su -c 'svc wifi disable'

Using the WiSHFUL framework

Install all required software. These commands should be executed on your nodes before downloading the WiSHFUL software.

You can also chose to use a custom image which has all the WiSHFUL software (incl. patched ath9k driver) pre-installed. In this image, the WiSHFUL sofware is installed in /root/wishful

urn:publicid:IDN+wilab2.ilabt.iminds.be+image+testbed:UBUNTU14-64-wishful

If you are using the default image (UBUNTU14-64-WILAB), then run these commands:

sudo apt-get update
sudo apt-get install -y wget git python python-virtualenv python-dev python3-dev python3-pip
sudo pip3 install --force-reinstall --upgrade pip

Install the WiSHFUL framework on a shared NFS directory. You only have to run this once.

cd /groups/wall2-ilabt-iminds-be/<your-project-name>/
mkdir wishful
cd wishful
#configure your git credentials
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
#download git-repo
wget https://storage.googleapis.com/git-repo-downloads/repo
chmod a+x ./repo
#get manifest files
./repo init -u https://github.com/wishful-project/manifests.git
#configure user-only manifest file
./repo init -m user.xml
# get all repositories
./repo sync
# to create master branch on all
./repo start master --all
# to check status of all repositories
./repo status
# create a virtual python environment
virtualenv -p /usr/bin/python3 ./dev
# activate virtual python environment
source ./dev/bin/activate
# install all dependencies
# *******WARNING*******
# DO NOT EXECUTE pip3 install as sudo, unless you run all your scripts with the root user.
pip3 install -U -r ./.repo/manifests/requirements.txt

For future experiments, you can now just activate your virtual environment:

sudo apt-get update
sudo apt-get install -y wget git python python-virtualenv python-dev python3-dev python3-pip
cd /groups/wall2-ilabt-iminds-be/<your-project-name>/wishful
source ./dev/bin/activate

WiFi QoS Management

In this experiment, four nodes are used as devices under test, while the fifth node is used as a WiSHFUL controller. The four nodes are split into two AP - client setups sharing the same channel and are running the iPerf application to measure network bandwidth. The WiFi QoS manager implemented as WiSHFUL controller will modify EDCA parameters of one of the flows changeing the bandwith allocation.

Create an experiment in jFed containing 7 nodes, named as follows:

  • ec
  • oml
  • controller
  • ap1
  • ap2
  • client1
  • client2

An example OMF experiment description can be found in the shared directory:

/share/upload/omf6/wishful/wishful_edca.rb
/share/upload/omf6/wishful/iperf.rb

Copy the files to your group directory and modify them:

  • replace all occurences of <YOUR-PROJECT-NAME>
  • replace all occurences of <YOUR-SLICE-NAME>
  • replace <IP-ADDRESS-OF-YOUR-CONTROLLER> with the actual IP address of your controller
  • make sure that you named your nodes as listed above, otherwise you also have to change those in your OMF experiment description

Run it with:

omf_ec -u amqp://labwiki.test.atlantis.ugent.be exec --oml_uri tcp:<NAME-OF-YOUR-OML-SERVER>:3003 wishful_edca.rb

To patch the ath9k driver (UNTESTED!!):

sudo -s
wget https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v4.4.2/backports-4.4.2-1.tar.xz
tar -xJf backports-4.4.2-1.tar.xz
cd backports-4.4.2-1/
cd drivers/net/wireless/ath/
#the steps below will make sure the ath9k driver uses the correct regulatory restrictions for your country
wget --no-check-certificate https://dev.openwrt.org/export/32952/trunk/package/mac80211/patches/403-ath_regd_optional.patch
patch -Np5 -i 403-ath_regd_optional.patch
echo "#define ATH_USER_REGD 1" | cat - regd.c > /tmp/out && mv /tmp/out regd.c
cp /share/upload/ath9k/edca_tpc_patch.patch .
patch -Np5 -i edca_tpc_patch.patch
cd -
make defconfig-ath9k menuconfig
#enable debugging in ath9k as described here: https://wireless.wiki.kernel.org/en/users/drivers/ath9k/debug
make
make install
reboot

Retrieve statistics of connected stations

Create an experiment in jFed containing 7 nodes, named as follows:

  • ec
  • oml
  • controller
  • ap1
  • ap2
  • client1
  • client2

Use this image:

urn:publicid:IDN+wilab2.ilabt.iminds.be+image+testbed:UBUNTU14-64-wishful

An example OMF experiment description can be found in the shared directory:

/share/upload/omf6/wishful/wishful_rssi.rb
/share/upload/omf6/wishful/iperf.rb

Copy the files to your group directory and modify them:

  • replace all occurences of <YOUR-SLICE-NAME>
  • replace <IP-ADDRESS-OF-YOUR-CONTROLLER> with the actual IP address of your controller
  • make sure that you named your nodes as listed above, otherwise you also have to change those in your OMF experiment description

Modify your global control program on your controller :

nano /root/wishful/examples/wilab/rssi/wishful_simple_controller

And put your own experiment details in:

omlDB=OMLBase("station_info", "<EXP_NAME>","controller","tcp:<OML-SERVER>:3003")

Run it with (replace <EXP_NAME> with a UNIQUE name for your experiment (same as the one above in the control program). If you run the same experiment multiple times, change the name of the experiment EVERY time):

omf_ec --name <EXP_NAME> -u amqp://labwiki.test.atlantis.ugent.be exec --oml_uri tcp:<NAME-OF-YOUR-OML-SERVER>:3003 wishful_edca.rb

Make a reservation (users of OLD emulab interface)

_images/login.png
  • Once you are succesfully logged in, click on New reservation on the top right of the Reservations tab.
  • Fill in the time slot details and click Update free nodes to see which nodes are still available during the given time slot.
  • Choose the project for which you want to insert a reservation. Since nodes are reserved on a project basis, this implies that all members of that project will be able to use the nodes. During a reserved time slot, you can swap in & out as many experiments as you want.
  • Click the green bar for the desired node type and select some of the nodes. If no green bar is shown for a given type, this means that no nodes are available during that time slot.
_images/newres.png
  • If you have extra requirements (e.g. if you want a clean 2.4 or 5GHz spectrum during your experiment), just mention them in the Comments field.
_images/comments.png
  • Browse to the Reservations tab to see your reservations. Note that on the top right of that page, you can chose to see only Your reservations or All reservations.
  • There is also a more user friendly view of the calendar available here: w-iLab.2 Reservation calendar.
_images/yourres.png
  • If you want to edit (change time slot, nodes, project) your reservation, click on Details first.
  • Next, click on Edit , make your modifications and click change when you are done.
  • If you want to delete your reservation, go to the reservation details first, and then click Delete.
_images/details.png
  • To get an overview of all reserved nodes, click on the Nodes Overview tab.
  • On the right, you can select both the Current State Overview and the Reserved Nodes Overview. Fill in a time and date on the Reserved Nodes Overview page to see which nodes are reserved by whom.
_images/nodeoverview.png

Run your first experiment (users of OLD emulab interface)

Run your first experiment on w-iLab.t Zwijnaarde The w-iLab.t Zwijnaarde testbed is managed by the Emulab framework in combination with the OMF experiment control tool. This tutorial will show you how to apply for an account and create your very first experiment. The goal of this experiment is to reserve some wireless nodes in the w-iLab.t Zwijnaarde, select an operating system and bring them up so we can SSH to them.

1. Request OpenVPN account The w-iLab.t Zwijnaarde nodes and servers are available over IPv6 without the need for a VPN connection. However, if you do not have IPv6 enabled at your office, please apply for an OpenVPN account.

2. Request an account on w-iLab.t Zwijnaarde Browse to the w-iLab.t Zwijnaarde home page and click “Request account”. If you were invited to join an existing project, please click the correct link. If this is not the case, just Start a new project and fill in all the fields of the form. Please pick an appropriate name for your project and add a meaningful description. Make sure the “Home Page URL” is an existing web site, or your request will not go through.

_images/requestaccount.png

3. Create a new experiment Once your project has been approved, you will be able to log in. Create a new experiment by pointing at the Experimentation menu and clicking Begin an Experiment. Now click on New GUI Editor to start the graphical experiment editor.

_images/createNewExp.png

Click and drag some nodes into the white field.

_images/dragNode.png

Select a node and give it a name. This name will be used as part of the DNS name of your node (which you will need for your OMF experiment description in the advanced tutorials). This name should be different from the physical node ID ( e.g. zotacB2, zotacK6). Do NOT draw any links between the nodes ! Links define wired experiment interfaces (which the zotac don’t have). The experiment interfaces of the zotacs are the wireless interfaces, but you should not define these in the Emulab experiment.

_images/nameNode.png

Select an Operating System (Click on ‘...’ to get a list). The default OS is UBUNTU12-64-OMF54. This image is based on Ubuntu12.04 64-bit and has both an OMF5.4 and OMF6 Resource Controller pre-installed. If you use the default OS (recommended!), then you can leave the OS field blank.

_images/osSelect.png

Fill in the Fix to Node field if you want to use a specific node. Leave the field blank if you want Emulab to choose a random node for you. See the topology map for the physical node ID’s (e.g. zotacH4).

_images/fixToNode.png

We are done! Just click File > Create new experiment. Select your Project, pick a name for the experiment and fill in a short description.

_images/createNewExp.png

You can now see your experiment details (including the ns file) by pointing to the Experimentation menu and selecting Experiment List.

_images/ExpList.png

4. Reserve your experiment Now that we have created an experiment, we should reserve a time slot where we can run our experiment. Browse to link http://wilab2.ilabt.iminds.be/reservation http://wilab2.ilabt.iminds.be/reservation and log in with the same credentials as the w-iLab.t Zwijnaarde home page. Check the reservations table (in combination with the Nodes Overview page) for a free slot and click “New reservation”.

Fill in start date, end date and select the correct experiment from the drop down list. When you require a free wireless spectrum on a certain band, please specify it in the comments (e.g. : 5GHz free required) so other users can take it into account when reserving their experiment.

_images/newReservation.png

When some nodes in your experiment are not available during the requested time slot, an error will appear listing the occupied nodes.

5. Activate your experiment When you enter a reservation, the system will automatically try to activate your experiment at the specified starting date and time. If you want to activate your experiment yourself, just browse to the home page (link wilab2.ilabt.iminds.be http://wilab2.ilabt.iminds.be), log in, select Experiment List from the Experimentation menu and click on your experiment. You can now click Swap Experiment in and check the Activity Logfile.

_images/ExpList.png
_images/activeExp.png
_images/ActLogLink.png

If everything goes well, you should get the message Swap Success at the end of the log file.

_images/ActLog.png

6. Log in to your nodes In the experiment details, you can retrieve the DNS name of the nodes in your experiment. You can use this DNS name in combination with your SSH client of choice to log in to the nodes. Please be aware that if you do not have IPv6 connectivity, you will first need to activate your OpenVPN connection before logging in to the nodes.

_images/expDetails.png

You can use the same credentials from the home page to log into your nodes.

If you want to set up a first experiment with an access point and a client, please check out this tutorial : http://fed4fire-testbeds.ilabt.iminds.be/ilabt-documentation/tutorials.html .

7. Finish your experiment Select your experiment and click Swap experiment out. Be aware that this will re-load the baseline operating system and thus will undo all your changes and delete all your files. This reload usually takes 15 minutes.

Page contents

Previous page

← Virtual Wall

This Page