From PmWiki

Experimentation: SmartSantander Testbeds


The 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 city of Santander located in the north of Spain). The envisioned facility is conceived as an essential instrument to achieve the European leadership on key enabling technologies for IoT, and to provide the European research community with a one-and-only platform of its characteristics, 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. Researcher will be allowed to reserve the required resources within the whole network and for a determined time period in order to run their experiments. On the other hand, different services fitting citizens’ requirements will be deployed. Different from the experiment applications, it will be either the authorities or the service manager/responsible, the ones in charge of determining the cluster of nodes running each service, as well as, the time duration of the aforementioned service.

Facilities Description

The project considers the deployment of 20,000 sensors in Belgrade, Guildford, Lübeck and Santander (12,000). Bellow we provide the details of the facilities which will be available for this second open call. Additional information about the operational facilities is available in the annex of this document as well as in [D1.1] and [D1.2].


Santander summary

The Santander testbed is composed of around 3000 IEEE 802.15.4 devices, 200 GPRS modules and 2000 joint RFID tag/QR code labels deployed both at static locations (streetlights, facades, bus stops) as well as on-board of mobile vehicles (buses, taxis). Over the deployed testbed, several use cases have been implemented:

Figure1: Outdoor parking and Environmental Monitoring deployed architecture

Figure 1 shows a screenshot of the deployment in Santander city centre, where parking, temperature, luminosity, CO and noise sensors can be observed. Whole deployment can be accessed in [MAP_SDR].

Description of hardware deployed, software architecture and integration within SmartSantander platform are discussed in detail in the ANNEX I.

Figure 2 and Figure 3 show some screenshots of the applications developed on Android and IOS for Augmented Reality and Participatory Sensing use cases, respectively.

Apart from service offered by the aforementioned use cases, and in order to cover the twofold approach, experimentation and service provision, pursued by the project; within these use cases researchers are also provided with the possibility of experimenting with the deployed nodes. In this sense, two types of experimentation can be carried out over the facility:

memory capacity issues, are not provided with an additional 802.15.4 transceiver and cannot be flashed over the air to load different experiments. For these cases, data generated by the different services (described in next section) provided by the project, is offered to the researchers for developing new services on top of it. In this sense, development of new added value services, as well as, correlation between information retrieved by different services, could be examples of this type of experimentation.

Apart from experimentation and service provision, network management is needed in order to access deployed nodes to send/receive commands from them, update the firmware running on them, or load experiments if allowed (OTAP). All these functionalities are performed through the Testbed Runtime (TR) module, which in order to manage these new wireless devices, implements a mux/demux functionality as well as the corresponding device drivers. Furthermore, in order to fulfill experiments support, platform management and service provision in a joint way at the node level, it is needed to flash node with a default program (called golden image), at network start-up.

Considering the aforementioned hardware and software architecture, Santander testbed allows the service provision and the experimentation in a simultaneous way, as well as network management, i.e. sending commands or flashing nodes. Detailed information about Santander testbed architecture at physical and logical level is included in ANNEX I.


Lübeck offers a number of different testbeds, all accessible through the already mentioned WISEBED experimental facility features such as the testbed runtime, portal servers, etc.

UZL’s major testbed consists of three sensor node hardware types: iSense, TelosB, and Pacemate. The nodes are arranged in clusters. Each cluster has one sensor node of each node type as shown in Figure 7. This testbed consists of roughly 300 stationary sensor nodes organized into 100 clusters. There are two different cluster layouts which differ in the sensor module connected to the iSense node. Half of the iSense sensor nodes are equipped with temperature and light sensors while the remaining nodes are equipped with a passive infrared sensor and accelerometer sensors.

All clusters are connected to a total of 35 Acer Aspire One netbooks forming the backbone of the testbed connected to the Internet. The sensor nodes are connected to the netbooks via USB. The netbooks are connected to the Internet over 802.11g Wi-Fi using a testbed-private ESSID and enterprise WPA2 encryption. This backbone enables the user to program or reset the sensor nodes without the need of an additional OTAP (Over-the-Air-Programming) protocol. The fixed network can be extended by mobile nodes(Roomba cleaner robots (see Figure 8) with attached iSense sensor nodes and with Lego Mindstorms).

In addition to the indoor and mobile nodes, UZL has deployed a number of outdoor, solar-powered iSense sensor nodes (see Figure 9). They feature a 6000mAh rechargeable battery pack, an iSense Solar Power Harvesting System which recharges the battery during sunlight times and provides energy from the battery otherwise. It also features an infrared sensor capable of detecting movement.Currently, approximately 35 nodes are deployed in the garden of the University of Lübeck’s manor house (see Figure 10). Please note that, due to the wireless and solar-powered nature of the outdoor testbed, sustaining operation at all times is very time-consuming and expensive. Therefore, the testbed is not constantly available for experimentation.


Currently the Guildford testbed provides a Smart environment, based on an indoor sensor nodes deployment located in the Centre for Communication Systems Research (CCSR). It serves as initial core and experimental micro-cosmos for the envisioned Smart Campus facility.

The IoT node tier consists of 250 freely programmable sensor nodes deployed across all offices of CCSR with various sensing modalities (temperature, light, noise, motion, electricity consumption of attached devices, vibration). The availability of these sensing modalities may vary across some of the nodes. The IoT nodes consist of 200 TelosB based platforms and 50 SunSpots. Other sensor node platforms will be deployed soon in order to achieve additional hardware heterogeneity in the testbed. The nodes’ deployment currently stretches over three floors of the building. Figure 5 provides an example of the final sensors deployment at floor 1 and 2 of the CCSR building. Ground floor deployment is still ongoing and the final layout could vary, however the aim to cover all the desks used by CCSR employees will be maintained. Due to the reduced number of spaces assigned to CCSR the ground floor deployment will result as the sparsest among the three floors.

100 embedded Linux servers (GuruPlug Servers), directly connected to an Ethernet backbone, have been deployed and connected to the sensor nodes for their management. By carefully selecting and configuring sensor nodes to act as sinks at experimentation time, the deployed GWs can offer also the possibility to act at the same time as data GWs realizing a data plane for interconnection of the testbed to the Internet. A server cloud hosts the testbed management servers and allows the on-demand creation of other application servers and data management tools.

Figure 6 provides an overview of the network architecture of the Phase 1 deployment. All devices of the IoT tier are connected through a gateway tier to a backbone network were application servers and testbed management servers reside. The data plane of the testbed is realized via wireless links (highlighted in Blue) based on 802.15.4 which can be single/multi-hop between the IoT nodes towards the GW devices. The GWscan act as data GWs, relaying data back to the server using the Ethernet connection provided by the backbone network. An out-of band testbed management and control plane is also realized via USB infrastructure from the IoT nodes to the GW devices, which in turn are connected through an Ethernet backbone towards the testbed management servers. In addition the testbed allows the connection of Smart Displays and end user terminals (laptops, desktops or mobiles) via WiFi and Ethernet towards the internal network, or directly via Bluetooth to the GW devices.

The ratio of GW nodes to IoT nodes is between 1:1 to 1:4, depending on the number of IoT nodes that are deployed in a room and availability of Ethernet ports in the office space for the connection of GWs.

In order to access the testbed and configure and run an experiment a set of tools fully integrated with the Guilford testbed are provided. Examples of these tools are:


The EkoBus system deployed in the city of Pancevo is made available for experimentation on IoT data level. The system utilizes public transportation vehicles in the city of Pancevo to monitor a set of environmental parameters (CO, CO2, NO2, temperature, humidity) over a large area as well as to provide additional information for the end-user like the location of the buses and estimated arrival times to bus stops. As the system is in commercial use, a replica of the system is made available for experimentation. The replica is connected to the live system and is being updated continuously. All data generated by the live system is immediately made available to the experimenters.

An overview of the EkoBus architecture is given in the following picture.

EkoBus system architecture

Every IoT node (sensor) in the system is described by its set of capabilities (characteristics, parameters, availability, etc), which are published and stored in the Resource Directory (RD). The Resource Directory stores dynamic information about all available resources in the system at a given time, so that they are available to the end users (applications). Resources make measurements and periodically send the results to the server application for further analysis and database storage. Web and Android application collect information from the resources and perform their visualization (location of the vehicles and atmospheric measurements). It is also possible to request information about the arrival time of the next bus on a certain line to a certain bus stop via SMS.

Analysis of the stored data is used for various traffic calculation and prediction. Accordingly, additional information is available: Static data: geo locations and names of the stations, geo locations of curves and semaphores on the bus route, bus timetables, average time that bus spends at the specific station, initial average time of bus travel between two consecutive stations; Dynamic data: calculated average time of bus travel between two consecutive stations for the different part of day and week.

Therefore methods and tools for experimentations are:

Retrieved from
Page last modified on July 18, 2013, at 11:38 AM