SmartSantander Experimental Test Facilities

SmartSantander project aims at the creation of an experimental test facility for the research and experimentation of architectures, key enabling technologies, services and applications for the Internet of Things in the context of a city. The envisioned facility is conceived as an essential instrument to achieve European leadership on key enabling technologies for IoT, and to provide the European research a unique platform, suitable for large scale experimentation and evaluation of IoT concepts under real-life conditions.

SmartSantander project provides a twofold exploitation opportunity. On the one hand, the research community gets benefit from deploying such a unique infrastructure which allows true field experiments, while on the other hand, different applications serving citizens’ needs will be deployed.

Facilities Description

The project envisions the deployment of 20,000 sensors in Belgrade, Guildford, Lübeck and Santander (12,000), exploiting a large variety of technologies. Additional information about the operational facilities is available bellow as well as in Deliverable[D1.1].

An overview of SmartSantander Architecture

Aiming at achieving a massive deployment of an Internet of Things infrastructure in a city scenario, requires careful planning in order to cope with the requirements imposed by the different FIRE stakeholders as well as to minimize interruption on the currently established city services and the citizens. Hence, SmartSantander has conceived a 3-tiered architecture, as defined next:

1.IoT nodes: Responsible for sensing the corresponding parameter (temperature, CO, noise, light, car presence,etc.). The majority of them are integrated in the repeaters, whilst the others stand alone communicating wirelessly with the corresponding repeaters (eg. parking sensor buried under the asphalt). Stand alone devices, due to lack of permanent power supply, they must be fed with batteries.

2.Repeaters: These nodes are placed high above ground in street lights, semaphores, information panels, etc, in order to behave as forwarding nodes. The communication between repeaters and IoT nodes performs through 802.15.4 protocol.

3.Gateways: Both IoT nodes and repeaters, are configured to send all the information (through 802.15.4 protocol), experiment-driven as well as service provision and network management to the gateway. Once information is received by gateways, it can be either stored in them locally, or sent to other machines (central servers), through the different interfaces provided by it (WiFi, GPRS/UMTS or ethernet). Taking into account, experimentation and service provision, prosecuted by the project, there is need to define an infrastructure that allows executing both experiments and user-addressed services concurrently, thus providing flexibility for researchers to try their applications on the testbed, at the same time that an end user service is running.

The SmartSantander testbed consists of four subsystems, which operate across a set of different devices (IoT,Gateway and Testbed server nodes) providing different characteristics and capabilities:

•Authentication, Authorization and Accounting (AAA) subsystem

•Testbed management subsystem

•Experimental support subsystem

•Application support subsystem

Figure 1: SmartSantander Architecture

Authentication, Authorization and Accounting (AAA): Access control is meant to ensure that only authorized actions are performed on WSN testbeds. Individuals accessing the testbed must be identified and authenticated, and their role must be identified. Authentication should be possible also in case of federated testbeds, where an experimenter/user belonging to a different research organization will have the possibility to carry out experiments in any testbed belonging to the federation.

Experimental support (ESS): It provides the required functions for reserving nodes, configuring and deploying experiments, running them and collects and analyzes the produced results. The Configuration Management module addresses the issue of configuring resources and experiments.

Management support (MSS): It provides the needed functionalities for adding/removing and configuring the resources composing the testbed and monitoring their status. The resource and testbed monitoring modules are also in charge of monitoring resources availability and type.

Application support (ASS): It is intended to provide the basic functionalities that can facilitate the development of services either for experimentation or final service provisioning. The Application subsystem should also to provide the possibility for lookup for specific resource or observation and measurement sorted in the corresponding databases (such as Resource DB and O&M DB) maintained by this subsystem.

SmartSantander architecture summarized above, is materialized with a careful integration of components coming from different existing projects (namely WISEBED, SENSEI and TELCO 2.0) in order to fulfil the described requirements. A graphical representation of the provided integration and the involved components is shown in Figure 2.

Figure 2: Components Integration

There are three main entities composing the SmartSantander architecture (Portal Server, GW node and IoT nodes) which can be identified in Figure 2. The Portal Server represents the access point to the SmartSantander facility for Administrators, Services and Experiment Users. It hosts an adapted version of the WISEBED Testbed Runtime , including Sensor Network Authentication and Authorization SNAA), Reservation System (RS) and iWSN API/WSN APP implementation.

The SNAA component offers the basic functions for access control through Shibboleth-based authentication and authorization. Therefore, at this stage, no account-based access control and other accounting functions are provided. The Resource Reservation system (RS API from Testbed Runtime) is instead used for making, querying and editing reservations of IoT nodes and supports a number of solutions for the persistence of these reservations, such as in-memory persistence, Google Calendar persistence and database persistence.

The iWSN API represents the back-end implementation of the set of functionalities required for interacting with the IoT nodes with commands such as reset, reprogramming, checking if a node is alive, adding/removing virtual links and many others.The iWSN API exposes also functionality for exchanging debug and control message between the Portal Server and the GW/IoT nodes. The iWSN API implementation on the GW is supported by a novel component, named WSN Device App, that allows for a [1:N] message exchanges between the IoT node directly connected to the GW (wired by USB/serial connection or not).