Resources

IoT-LAB testbed provides users with a set of resources for experimentation. This page describes these resources and their properties and how to book them to be able to run an experiment according to your needs.

Nodes properties

The basic resource of the testbed is the node: a specific board deployed at a specific position on a specific site. It is on such resources that the user’s experimentation takes place. All the resources are stored into the resource manager database with a set of properties described in the table below:

Property	Type	Description
network_address	string	Network hostname of the node, composed as follows: `<node_id>.<site>.iot-lab.info`. Example: the first M3 node of Grenoble site is `m3-1.grenoble.iot-lab.info`.
archi	string	Information about the hardware of the node, composed as follows: `<board_id>:<radio_chipset>`. Example: the value for an IoT-LAB M3 is `m3:at86rf231` (node_name = m3 and radio_chipset = at86rf231).
site	string	Name of the IoT-LAB site where the node is located. All sites are described in the Deployment section.
state	string	The state allows to know if the node is free (Alive) or already in use (Busy). In some cases the node may have some issues (Suspected or Dead) and is not available for booking.
uid	string	Unique identifier of the board (16 bits). This value is calculated with microcontroller CPU architecture. Example: an IoT-LAB M3 node uses the STM32 unique device identifier, a 96 bit register
x, y, z	integer	Coordinates of the node (in meters) in a 3D cartesian coordinate system.

Browse nodes

The different tools of the testbed allow to browse them.

From the webportal, the Testbed Status page displays a list in a table that can be filtered by site, architecture and status.

The view on site map link allows to show them also in an interactive 3D view, helping a lot in understanding or choosing a physical topology.

A second tab allows to show a Gantt chart representation of selected resources, helping to show experimentation scheduled and resources mobilized.

Using the CLI tools, the iotlab-status command lists resources and their properties, with options to apply filters.

$ iotlab-status --nodes
{
    "items": [
        {
            "archi": "m3:at86rf231",
            "camera": 0,
            "mobile": 0,
            "mobility_type": " ",
            "network_address": "m3-1.grenoble.iot-lab.info",
            "site": "grenoble",
            "state": "Alive",
            "uid": "2354",
            "x": "20.10",
            "y": "26.76",
            "z": "-0.04"
        },
        ...
    ]
}

Booking

Once you chose the board(s) and the site(s) you want to involve in your experiment, you have to express it at the submission step so that the resources are booked for you.

At that point, there are two alternatives available to you to select nodes:

by properties, specifying a set of properties (eg. archi, site) that nodes have to match and their number;
by ids, specifying the site and board name with a list of resources ids.

The first case is the simplest if you just want a number of nodes, since you just have to express your need and the scheduler will choose the right nodes for you. Here is an example using CLI tools:

iotlab-experiment submit -d 20 -l 10,archi=m3:at86rf231+site=grenoble

The second case is typically used when you want to have a specific physical topology (aligned, grids, clusters, multi-hop, etc.). You saw in the nodes description that the nodes coordinates are stored. The Deployment section should help you in understanding how the nodes are spread among a site and, so, in picking the right ones to setup your topology. The 3D view of the webportal is also very helpfull for that. Here is an example using CLI tools:

iotlab-experiment submit -d 20 -l grenoble,m3,1-9+23

About radio proximity

As IoT-LAB M3 and A8-M3 are deployed at a large-scale, you could have 2 nodes too far from each other to be able to communicate.

In the submission by properties case, the scheduler will make sure that the assigned nodes are in the same radio neighborhood.
In the submission by ids case, the constraint on radio proximity is not checked by the scheduler. You have to make sure that the nodes are able to communicate together.

Other boards are deployed in a smaller scale, next to each others, and do not involve this additional mechanism.

Scheduling

For both booking mode you can ask the scheduler to start your experience as soon as possible (i.e. ASAP) or make a reservation for a specific date and time.

With the asap mode the scheduler will accept your reservation, but the experiment may not start right away if some of the nodes you asked for are already in use. In that case, the experiment will have a status of Waiting, and will be start as soon as they are free again.

Making a reservation amounts to precise a start date. Regarding the specified duration, the scheduler will check if the nodes requested will be available on that time slot. If not, the experiment submission will be rejected.

To help you to select available nodes or available time slot, the Testbed Status page of the webportal displays the current state of nodes in the list. Moreover, on the same page, the ‘Tesbed Activity’ tab gives access to a gantt diagram that allows to see past, current and future experiments over time.