Santander on FIRE

The Santander testbed is composed currently of around 2000 IEEE 802.15.4 devices deployed in a 3-tiered architecture:

•IoT node: Responsible for sensing the corresponding parameter (temperature, CO, noise, light, car presence,etc.).

•Repeaters: These nodes placed high above ground in street lights, semaphores, information panels, etc, in order to behave as forwarding nodes to transmit all the information associated to the different measured parameters.

•Gateway: Devices that gather all the information retrieved by IoT nodes and repeaters, acting as intermediate nodes between the sensor networks and the SmartSantander backbone.

Taking into account, experimentation and service provision, prosecuted by the project, it is needed to define an infrastructure that allows executing both experimentation and user-addressed services concurrently, in order to provide flexibility to researchers for running their applications on the testbed, at the same time that a end-user service is running. To handle this execution concurrency in an efficient way, a solution based on hardware independence has been adopted for this first deployment. In this sense, all nodes (IoT nodes, repeaters and GWs) will be equipped with two IEEE 802.15.4 modules, one of them performing network management as well as service provision, and the other one handling traffic associated with experimentation.

•Service Provision: Both outdoor parking area control and monitoring of environmental parameters (temperature, CO, noise, light), are the first services developed over the deployed infrastructure.

•Experimentation: Nodes can be flashed over the air in either a one-hop way (OTAP) or a multihop fashion (MOTAP) with different programs, thus allowing the researchers to test different experiments on the deployed network.

•Network management: In order to manage both experimentation and service provision, communication between IoT Nodes/repeaters and gateway nodes, is performed through the Testbed Runtime (TR). In order to manage these new wireless devices, it is added a mux/demux functionality as well as the corresponding device drivers to the TR. Furthermore, in order to fulfill experiments support, platform management and service provision in a joint way at the node level, it is needed to load node with a default program (called golden image), at network start-up.

Hardware deployment

To handle this execution concurrency in an efficient way, a solution based on hardware independence is posed within Phase 1 of the Santander testbed deployment. This solution, provided by the Spanish company Libelium, consists of nodes implementing two different physical interfaces, as shown in the figure.

Figure 1: IoT Node deployed in Santander Phase 1 testbed

The node depicted in Figure 1 is composed of the following parts:

• Main board: This board (called Waspmote) is in charge of processing and memory issues, providing a set of interfaces for attaching different types of sensors (both analogue and digital), as well as to plug several radio modules to communicate with other nodes. The Waspmote comes with with a ATmega1281 microcontroller, and several types of memory, 8KB SRAM, 4KB EEPROM, 128KB FLASH and an extra storing SD memory with 2GB capacity. On the other hand, 7 analogue and 8 digital interfaces are available for external sensor connection, as well as 1 PWM, 2UART, 1 I2C and 1 USB interfaces for attaching different communication modules. All the development tools (libraries, API’s, etc.) provided by Libelium are based on a pseudo-wiring solution which aims to promote the simplicity of the functioning of the micro-processor based on events and loops.

• Two XBee-PRO radio modules: Both modules manufactured by Digi company, run over 2.4 GHz frequency. One of the modules implements 802.15.4 protocol in a native way, and the other one runs 802.15.4 protocol modified with a proprietary routing protocol called Digimesh. This is a proprietary peer-to-peer networking topology protocol for use in wireless end-point connectivity solutions, allowing addressing in a simple way.

IoT nodes, repeaters and GWs are equipped of the aforementioned component in order to guarantee the service provision as well as the experimentation. In the case of the gateway node, as it is intended to gather and facilitate all the information taken from the WSN, either to external networks (internet) or application level services, it needs to implement high memory/processor capacity and added communication skills. To fulfill all these requirements, another device (called Meshlium), also manufactured by Libelium, with higher capacity in terms of processor (500MHz) and memory (256MB RAM and up to 32GB hard disk) is utilized. Regarding to its communication skills, apart from the two Xbee radio modules for communication with the deployed nodes, also WiFI, GPRS, Bluetooth and Ethernet interfaces are provided.

Network management, service provision and experimentation support

IoT Nodes interact with the rest of the SmartSantander system is as follows:

1. SmartSantander experimental facility needs to be managed in a wireless way which basically involves wireless transmission/reception of commands to/from all nodes and node reflashing over the air. For this purpose, the Digimesh radio module provides the routing protocol for communication between nodes and gateway. In this sense, it will be possible to manage the IoT Nodes from the gateway by sending the appropriate commands and receiving the corresponding responses as they are issued by the IoT Nodes. On the other hand, IoT Nodes will be flashed also from the gateway as many times as required, through OTAP (over-the-air programming) or MOTAP (Multihop OTAP), for nodes more than one hop away from the gateway.

2. All the information derived from both service provider and city service use cases is retrieved by the deployed nodes to the gateway, which is the entrance towards the SmartSantander system, through WiFI, GPRS, Ethernet. In order to send all this data in a reliable and transparent way, the Digimesh-enabled network is used.

3. Regarding to experimentation use cases, researchers will flash the nodes with the corresponding programs, through (M)OTAP using the Digimesh interface. However, once the code is loaded in the node, all the data regarding to the experiment will be transmitted and received through the 802.15.4 native module.

High-level Architecture

Communication with IoT Nodes and repeaters from the gateway nodes, is performed through the Testbed Runtime (TR). The TR creates an overlay network for easy node addressing and message exchange with locally attached nodes independent from the actual underlying network connections. It performs message forwarding and offers communication primitives that are used for the control and management of experiments and the WSN itself. The TR design defines the Connection Services which handle the messages exchanged with the IoT Nodes. IoT Nodes are connected with the GW running the TR through the same network interface (either through 802.15.4 or Digimesh interface). Hence, the isolation of the connection with each of the IoT Nodes has to be provided through appropriate multiplexing and demultiplexing of the communication within the Connection Service developed for the IoT devices.

Figure 2 illustrates this mux/demux functionality deployed within the TR to support communication with Waspmote devices. The hatched boxes in the figure, namely CommServer, Multiplexed Connector and Waspmote Driver, implement the mux/demux functionality in order to support the wireless Waspmote devices. The first two modules are generically-applicable and IoT device-independent, whilst the WaspMote driver is device-specific i.e. a new driver needs to be implemented for each new device type.

Figure 2: High-level architecture for integration of Waspmote-based WSN

•CommServer: The CommServer module is responsible for directly interacting with the physical radio interfaces in charge of wirelessly interacting with the WSN and of providing a unique interface for the access to/from the rest of the system.

•Multiplexed Connector: CommServer creates one connector associated to each of the IoT Nodes. These connectors (WaspMote Driver in Figure 9) are the ones that TR actually uses for interacting with the IoT Nodes. In this sense, when a command or message is to be transmitted, TR simply sends it through the connector associated with the IoT Node that should be receiving it. The Multiplexed Connector will manage the message and forward it to the CommServer which will subsequently send it through the appropriate physical interface. When a message is received from a node, the Multiplexed Connector will forward it to the TR through the connector associated with the sender IoT Node.

•Waspmote Driver: Functionalities and message formatting that are specific for the Waspmote devices are implemented in this module. As TR assumes one connector per IoT Node in the WSN, there is one of these modules per device in the WSN.

First implemented Use case

For Phase 1 deployment, the service to be provided is an outdoor parking area control, as well as the provision of real time information related to environment conditions (e.g. temperature, CO, noise, light sensors). In Figure 3, it is presented a diagram which shows the interactions between the three constituent blocks (IoT nodes, repeaters and gateways), in order to provide the aforementioned use case.

Figure 3: Architecture instantiation for Phase 1 in the Santander deployment

Figure 3 shows the way the limited parking management use case is performed where several parking sensors (IoT nodes) provided with one transceiver (running the Digimesh protocol) send their parking state (free or occupied), to the corresponding gateway through the repeaters placed at the streetlights. At the same time, all these repeaters are equipped with temperature, CO, noise and light sensors, thus sending this information to the gateway. The received information is stored and processed in the gateway, in order to be used by different applications running over it, both in a local way or accessing from Internet through the SmartSantander backbone.

Regarding to the data associated to experimentation, this is transmitted through the 802.15.4 native interface that works in an independent way from the Digimesh interface, thus assuring no disturbance between experimentation and service provision/network management data.

Santander testbed composes of several clusters, being a cluster the set of IoT nodes and repeaters that are associated to a determined gateway. Figure 3 shows the logical architecture corresponding to the deployment whilst Figure 4 depicts node deployment at downtown.

Figure 4: Cluster deployed in Santander city centre

As it can be depicted from the figure different environmental sensors (temperature, CO, noise, light), as well as parking sensor nodes have been deployed in the city centre. All these nodes are programmed to send all the retrieved information, to the corresponding meshlium, and they are also able to be flashed with different experiments to be run on top of them.