System & Network Architecture¶

w-iLab.1 Architecture¶

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 : 110 testbed nodes installed on three floors in the iGent building.

w-iLab.1 shares almost all system and network architecture features of w-iLab.2. Please check the chapter below for more info.

Officelab¶

In the iGent building, three floors of the building are 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.

w-iLab.2 Architecture¶

Permanent storage¶

Some permanent storage is available for experimenters. This storage is only accessible from the testbed nodes. So in order to access it, you need to activate an experiment (using jFed) with at least one node.

Some notes about the permanent storage:

It is located at: /groups/wall2-ilabt-iminds-be/<YOUR PROJECT NAME>
This folder will be mounted on all nodes in your experiment.
This folder is SHARED between all members of your project.
Permanent storage is not synced over multiple testbeds (w-iLab.1/w-iLab.2/wall1/wall2). If your experiment involves nodes on w-iLab.1 and w-iLab.2, the content of your /groups folder will be different.
/share/: a directory accessible to all users, where testbed providers can store files that are useful for all experimenters.
Your home directory (/users/<YOUR USER NAME>) will NOT be saved. Creating an image of the node will ERASE this folder ! If you want to save files on your image, please put them in the /root folder.
You can easily transfer files to (and from) this storage by right-clicking a node in jFed.

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

Warning

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

Network¶

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).

Software¶

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.imec.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.imec.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.

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.

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.imec.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.