FIREBALL establishes a coordination mechanism through which a network of Smart Cities across Europe engages in long term collaboration for adopting User Driven Open Innovation to explore the opportunities of the Future Internet. The coordination process will be grounded in exchange, dialogue and learning between Smart Cities, who are considered as key demand-side drivers of Future Internet innovation. It also will be grounded in bringing together the Future Internet, Living Labs and Smart Cities constituencies. Now that Future Internet driven network infrastructures and applications are in the pipeline, and which potentially might bring economic and social benefits not only to research communities but also to Cities, it becomes all the more urgent to strengthen the role of Cities to elicit their future needs and requirements from the perspective of user driven open innovation. Identifying these needs and requirements elicitation also informs ongoing research, experimentation and deployment activities related to Future Internet and testbeds, and helps to establish a dialogue between the different communities to help form partnerships, and to assess social and economic benefits and discovery of migration paths at early stages.

EWSN 2012, the European Conference on Wireless Sensor Networks, is the ninth of a series of annual meetings focusing on the latest research in the area of wireless sensor networks. EWSN 2012 will be held at the University of Trento, Italy, on February 15-17, 2012.

8th International ICST Conference on Testbeds and Research Infrastructures for the Development of Networks and Communities

The 8th International ICST Conference on Testbeds and Research Infrastructures for the Development of Networks and Communities will be held in Thessaloniki, Greece, 11-13 of June 2012, with the vision to bring together technical experts and researchers from academia, industry and government all around the world to discuss experimental research infrastructures of the Future Internet.

The EkoBus system deployed in the cities of Belgrade and Pancevo is made available for experimentation on IoT data level. The system utilizes public transportation vehicles in the city of Belgrade and 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.

An overview of the EkoBus architecture

Every IoT node (sensor) in the system is described by its set of capabilities (characteristics, parameters, availability...), which are published and stored in the Resource Directory (RD). 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 certainline to a certain bus stop via SMS or USSD and to receive that information via SMS. The SMS module is responsible for this feature. Analysis of the stored data is used for various traffic calculation and prediction. Accordingly, additional information is available from the MYSQL database: Static data: geo locations and names of the stations, geo locations of curves and semaphores on the bus route, bus timetables, IMEI of the GPRS modules which are mounted on the buses, 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:

• Web interface – Web application is responsible for displaying bus locations, bus arrival time information and data received from environment and gas sensors in a web browser, and can be extended in order to provide public survey i.e. feedback from the end user; or additional services Application is calling methods exposed by Data control centre (bus information web service). The data is obtained in XML format.

• Mobile application is similar to the web application, providing the visualization of the current location of all vehicles in the system as well as the measurements for the end-user with mobile phone.

• SMS/USSD – end-user can query the system using USSD or SMS

• Database and offline analyzer – database data that can be used for new offline traffic analysis procedures. Module for offline data analysis is responsible for updating the data in database with statistics obtained during previous measurement period. This information is used by the Traffic management agency of the City of Belgrade and Pancevo to optimize the public transport system.

The following is offered to the experimenters:

• Access to historical data stored in the database. It is made available via dedicated Resource End Points utilizing simple REST interface that allows extraction of the measurements for a given period.

• Direct access to IoT nodes is not available. It is also not possible to change the code or configuration of the IoT nodes.

• In Belgrade and Pancevo, 5 and 60 devices are deployed respectively.

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 1. 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 2) 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 3). It features 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 4).

The first phase of the Guildford deployment is the creation of a Smart environment based on an indoor deployment of the testbed in the Centre for Communication Systems Research. It will serve as initial core and experimental micro-cosmos of the envisioned Smart Campus facility.

The IoT node tier will consist 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 will consist of 200 TelosB based platforms and about 50 SunSpots. The deployment of the nodes currently stretching over two floors of the building. Figure 1 shows the current deployment snapshot as an example of the deployment topology. As the Phase 1 deployment is not yet finalized the final layout will vary.

Figure 1: An overview of the current IoT node deployment snapshot on two floors of CCSR.

100 embedded Linux servers (GuruPlug Servers), directly connected to an Ethernet backbone, are deployed collocated to the sensor node for their management while offering the possibility to act at the same time as data GW. A server cloud hosts the testbed management servers and allows the on-demand creation of other application servers and data management tools.

Figure 2 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 back bone network were application servers and testbed management servers reside. The data plane of the testbed is realised 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, and Ethernet of from the GW towards the servers in the backbone network. An out-of band testbed management and control plane is realised 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.

Figure 2: High level network diagram for Guildford Phase 1 deployment

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.

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.

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

SmartSantander refered in site cefims.eu, on August 2011 ceFIMS newsletter. This new publication will bring you updates on the Future Internet Forum (FIF) of Member States, as well as information on new initiatives and achievements in the European Future Internet.

BonFIRE will support experiments exploring the interactions between novel service and network infrastructures. Three initial scenarios have been defined to highlight the general classes of experiment that can be supported by the facility. The scenarios include Extended cloud scenario: the extension of current cloud offerings towards a federated facility with heterogeneous virtualized resources and best-effort Internet interconnectivity. Cloud with emulated network implications: a controlled network environment by providing an experimental network emulation platform to service developers, where topology configuration and resource usage is under full control of the experimental researcher. Extended cloud with complex physical network implications: investigates federation mechanisms for an experimental cloud system that interconnects individual BonFIRE sites with Federica, Open Cirrus and Panlab.