SMART SANTANDER Information on 1St Open Call for Experiments

SMART SANTANDER

Information on 1st Open Call for Experiments Dr. Alex Gluhak, University of Surrey Dr. Luis Sanchez, University of Cantabria Open call information day th Copyright © SmartSantander Project FP7-ICT-2009-5 257992. All Rights reserved. Brussels, 14 of September 2011 Outline

• First call overview (AG) – Call procedure and guidelines for proposals – Detailed technical call objectives – Expected impact of proposals • SmartSantander infrastructure (AG, LS) – Testbed architecture – Deployment description at the 4 testbed sites • Experimentation on top of SmartSantander (AG,LS) – Available experimentation tools – Example experiments • Q&A

• Web: http://www.smartsantander.eu/index.php/open-calls • Contact e-mail: [email protected]

• Detailed open call text – Provides an overview of the technical call objectives and expected impact – Overview of the facility • Guide for applicants – Template adapted from EC how to prepare a proposal – Follows FP7 regulations • Regulations for the use of the facility – 7 articles outlining expectations and guidelines for experimentation

Copyright © SmartSantander Project FP7-ICT-2009-5 257992. All Rights reserved. Key call facts Call identifier SmartSantander-1-Open-Call Call opening 1st October 2011 Call closing 16. November 2011, 17.00 Brussels time (last received version prior deadline counts) Experimentation Jan – December 2012 Timeframe (length may vary based on nature of experiment – typical 9 month) Max funding per 200k Euros experiment Maximum funding for call Up to 600k Euros Number of expected 3+ experiments Number of partners per 1-2 partners experiment Proposal language English

• E-mail: [email protected]

• Only PDF version of proposal acceptable in English language

• Resubmission possible, last version prior deadline considered valid

• Time in our email system counts

• Acknowledgement of receipt of proposal will be email to you soon after closing date

• Any entity that can participate in FP7

• Funding is cost-shared basis and follows usual FP7 funding rules

• Current partners of SmartSantander are not eligible for funding through open calls

• Front page, abstract and table of contents • Cost and funding breakdown

• Section 1: Scientific and/or technical quality, relevant to the topics addressed by the call – 1.1 Concept and objective – 1.2 S/T methodology and associated work plan – 2 mandatory WPs • Experimentation framework with 3 deliverables providing experimentation plan (M1), initial results (M6) and final report (M9) • Promoting SmartSantander experimentation platform, 1 deliverable showing the dissemination activities

• Section 2- Implementation – 2.2 Participants – 2.4 Resources to be committed • Section 3 - Impact – 3.1 Expected impact – 3.2 Dissemination and/or exploitation of results, and management of intellectual property

• Section 4 Ethical issues

• Three key criteria – 1. Scientific and/or technological excellence (relevant to the topics addressed by the call) – 2. Quality and efficiency of the implementation and the management – 3. Potential impact through the development, dissemination and use of project results

• Minimum score to pass evaluation threshold – At least 3/5 in each and 10/15 in total

• Independent experts will be appointed after call closure • Each proposal will be reviewed by at least two independent experts • Physical consensus meeting will determine final score • Proposal with the highest score will be selected within the funding limit - but – Highest ranked proposal may not be selected, e.g. based on objective grounds – No proposal may be funded if consortium finds highest scoring proposals to be of inadequate quality – call may be reopened at a later stage

• Call help desk – Name: José Manuel Hernández-Muñoz – Email: [email protected] – Tel: +34 91 483 26 74

• Your NCPs

• IPR help desk

• Main goal: – To expand the project’s service, protocol and technology offering towards future IoT experimentation as well as the public in the context of the Smart City.

• Objectives should target at least one of 3 areas 1) Innovative applications and services for smart cities and built environment 2) Internet of Things communication protocols and technologies 3) Internet of Things middleware solutions

• Innovative IoT based services and application for city and built environment • Services must demonstrate clear benefit to stakeholders, e.g. city and citizens • Evaluation of end user acceptance & commercial viability desired • Current infrastructure targets transportation, energy and environment however extensions of infrastructure to new application domains can be proposed • Other extensions could be mechanisms to evaluate end user feedback and quality of experience

• Evaluation of new approaches and architectural paradigms for an Inter-net of Things (IoT) • Studies that provide a more detailed understanding of the properties and particularities of large scale IoT deployments leading to new design principles • Mechanisms and techniques that allow the exploitation of opportunistic availability of (mobile) IoT devices for computing and communication tasks • Key enabling building blocks of an Internet of Things such as resolution infrastructures • Mechanisms for more efficient and reliable data dissemination in large scale resource constraint environments

• Platforms and mechanisms for large scale distributed processing and querying of real world events and event streams • Mechanisms and techniques that contribute towards increased data interoperability on an emerging global Web of Things • Algorithms for real world awareness, contributing to an increased machine understanding of complex processes and system behaviour in a city and built environments • Visual analytics tools for the efficient analysis of real world events and complex relationship between real world generated data

• Submission to area 1) – Must demonstrate a clear benefit and value to the targeted service end users, such as city and citizens or the university and its employees/students • Submissions to area 2) and 3) – Must have the potential to lead to high quality scientific outcomes – Supported by evidence (expertise, dissemination strategy)

• Additional impacts (at least one of the following): – Improve / extend the existing capabilities of the SmartSantander experimental test facility – Stress-test the capabilities of the current facility

Server tier IoT gateway tier IoT node tier

Testbed observation and management plane Testbed GW observer IoT observer management & mgmt node & mgmt node servers

Application & Embedded IoT node data servers GW node

IoT experimentation plane Multi-modal sensing unit

Server tier Isb Igb GW node Igi nodesServer tier IP based GW tier IoTIoTnodetier Server tier tier nodes backbone nodes tiernodes nodes network Iii

IoT tier Ibb nodes SmartSantander site A

IP based WAN

Ibb

Server tier Isb Igi nodesServer tier Igb GW node IoT node IP based GW tier IoT tier Servernodes tier tier tier backbone nodes nodes nodes network

Iii

IoT tier nodes SmartSantander site B

Copyright © SmartSantander Project FP7-ICT-2009-5 257992. All Rights reserved. IoT experimentation plane • WASP motes – AtMega1281L (8 MHz) – 1-2 802.15.4 radios – Flash + SD card • Servers cluster – USN service platform

Application & Embedded IoT node data servers GW node

IoT experimentation plane Multi-modal sensing unit

• Meshlium Extreme • x86 based, 500Mhz • Ferromagnetic sensors for car park detection • Wifi,802.15.4 • Noise and CO2 sensors • 8GB storage

Portal Server TESTBED RUNTIME

WIRELESS SENSOR NETWORK API (IWSN)

SENSOR NETWORK AUTHENTICATION AND AUTHORIZATION (SNAA) Gateway RESERVATION SYSTEM (RS) TESTBED RUNTIME

WSN APP WSN DEVICE APP

Waspmote Waspmote Waspmote Driver Driver Driver (Device 1) (Device 2) ... (Device N)

Multiplexed Connector

XbeeSerialPortConnection (CommServer)

= Service Data = Management Data = Experimentation Data = All Data ttyUSB0 ttyUSB1

Waspmote Waspmote 802.15.4 DigiMesh Gateway Gateway

Waspmote A Waspmote B Waspmote C

• Linux based server cluster hosting • WASP Mote – Testbed management services – Same as experimentation – Databases for user management and node AAA, testbed resources, experimental – Dual transceiver for control results collection plane and service data

Testbed observation and management plane Testbed GW IoT observer management observer & node servers mgmt node

• Meshlium Extreme – Same as experimentation node

• IoT experimentation in parallel with service provision – Binary images to be loaded on IoT nodes support experiment and Smart City service – Dedicated libraries containing service and testbed management functionalities

• Santander - Phase 1 target deployment – 1400 installed on lamp posts • Temperature, Relative Humidity, Noise Levels – 375 buried in the asphalt • Presence of vehicles

Sensor node. Low-end device. Belongs to hierarchy level 2. Repeater. Low-end device. Belongs to hierarchy level 2. Internet / Intranet Gateway. Low-end device. Belongs to hierarchy level 1.

Peer-to-peer communication.

Level 1

Level 2 Copyright © SmartSantander Project FP7-ICT-2009-5 257992. All Rights reserved. Deployment architecture • Full-meshed network architecture – Topology controlled by experimenter – Reprogrammable over-the-air – Dual transceiver architecture, one dedicated for control plane and one for experimentation

Load/Unload Area

Streetlight Digimesh Link Parking sensor: Sensor node with one transceiver (Digimesh) 802.15.4 Link WiFi/GPRS, Parking sensor node. To be deployed buried in Repeater: Sensor node with two transceivers (Digimesh and 802.15.4) ethernet Link the asphalt. At the corresponding load/unload SmartSantander area, bus stop or handicapped-reserved space. Gateway: Node with communication with Backbone Repeater. To be deployed at available street sensor networks (Digimesh and 802.15.4) lights or traffic lights. and communication with external networks Gateway. Connected to Internet/Intranet. (WiFi, GPRS, ethernet) Radio link Copyright © SmartSantander Project FP7-ICT-2009-5 257992. All Rights reserved. From the lab into the city

Copyright © SmartSantander Project FP7-ICT-2009-5 257992. All Rights reserved. IoT experimentation plane • Linux server cluster hosting applications • X-Bow TelosB – MSP430 16 bit MCU – I/Os: 802.15.4 radio, USB • Sunspot – 32 bit MCU – I/Os: 802.15.4 radio USB

Application & Embedded IoT node data servers GW node

IoT experimentation plane Multi-modal sensing unit

• Guru plug • Multi-modal sensing unit – ARM5 based embedded Linux server – Energy meter, Light, Temp, PIR, – I/Os: Ethernet, Wifi, Bluetooth, 2 USB, Vibration, Sounds 802.15.4

• Auxiliary board • Linux based server cluster hosting – PIC18 based board with integrated USB hub – Testbed management services – Measurement of IoT node energy consumption – Databases for user management and – Sensor event/phenomena emulation using AAA, testbed resources, experimental DACs results collection

Testbed observation and management plane Testbed Embedded Auxiliary management GW node board servers

• Management GW node: Guruplug – ARM5 based embedded linux server – USB based out of band interaction with IoT node (Reset, reprogramming, statistics collections, debugging) – Packet sniffer

Management GW Smart display infrastructure

Sensor USB Servers unit Ethernet Wifi, Ethernet

802.15.4 Data GW Ethernet Core Network by FI platform USB

Bluetooth Wifi, Ethernet Management GW

Bluetooth User devices

1st floor 2nd floor

Multi-modal sensing unit • Light, noise, PIR, temperature

Power Consumption Monitoring Unit • Power, reactive power, current, phase, Voltage/RMS,Time operational since connection • Max frequency every 2 seconds

Sensor emulation board

Sensor node with MCU, 802.15.4 PEN Unit radio and USB

• The testbed site at Lübeck University is part of the bigger WISEBED experimental facility and offers possibilities to experiment with sensor networks.

• Advantages of the WISEBED connection: – The testbed can basically be used the same way as in the Santander site – Apart from the roughly 350 nodes in Lübeck, the whole WISEBED experimental facility can be used (1500 nodes when everything is up and running)

• Stationary sensor node deployment – 100 iSense, Pacemate, and TelosB each – Temperature, humidity, light, Passive Infrared (PIR), and accelerometer • Mobile sensor node deployment – 10 iSense and Roomba robot – 1 Lego Mindstrom NXT robot – Touch, cliff, and dirt • Outdoor sensor node deplyoment – 35 iSensor nodes with solar recharge

• Gateways – 35 Acer Aspire One Netbooks

• EcoBus system provides realism and possibilities for experimentation in the real-world environment offering evaluation and engagement of the end-user • Platform utilizes public transportation vehicles in the city of Belgrade and the city of Pancevo to monitor environmental conditions and track vehicles

• Overall 60 IoT nodes mounted on busses – 45 nodes with GPS Location and speed – 15 nodes with environmental sensors • Carbon Monoxide Sensor (CO) sensor • Nitrogen Dioxide Sensor (NO2) sensor • Carbon Dioxide Sensor (CO2) sensor • Temperature Sensor sensor • Atmospheric Humidity Sensor sensor • Nodes are not configurable but can be queried for data through Smartsantander platform

Copyright © SmartSantander Project FP7-ICT-2009-5 257992. All Rights reserved. Resource overview • All interaction in the system is REST based • Power consumption is not an issue as both resources are connected to a vehicle power source (backbone)

• WASP mote • C programming • Deployment (top of the vehicle) • Interfaces: GPS, GPRS

• TELIT module • Python programming • Deployment (inside the vehicle) • Interfaces: GPS, GPRS

Copyright © SmartSantander Project FP7-ICT-2009-5 257992. All Rights reserved. Summary (1/2) Santander Guildford (Phase 1) (Phase 1) Environment Outdoor Indoor IoT nodes 1400 Libellium motes on lamp 200 TelosB based IoT nodes and GW posts (programmable) 50 Sunspots devices 375 Libellium in parking bays (all freely programmable) ~25 Meshlium GWs 100 embedded GWs OS and Embedded C on Libellium motes TinyOS, Contiki or C on TelosB programming Java on Sunspots support Linux on GWs, C/C++/Java/Python Sensing Ferromagnetic field (cars), Presence, light, temp, noise, energy modalities temperature, noise levels, light and load switching (TelosB) intensity and CO Light, Temp, 3D accel (SunSpot)

Special MOTAP, 2nd radio on repeater Node energy monitoring, injection of features motes for out-of-band control sensing events on auxiliary board plane and continuous service provision

Copyright © SmartSantander Project FP7-ICT-2009-5 257992. All Rights reserved. Summary (2/2) Luebeck Belgrade (Phase 1) (Phase 1) Environment Indoor and Outdoor Outdoor mobile IoT nodes 300 indoor IoT nodes (100 iSense, 60 based WASP motes mounted on and GW Pacemate, and TelosB), buses, all with GPS Location and devices 35 oudoor iSense speed, 15 nodes with additional 11 mobile nodes environmental sensors

35 Acer One netbooks as GWs GPRS for connectivity OS and iSense OS and WiseLib on all Embedded C on Libellium motes programming platforms (non programmable, data only) support (all motes programmable) Sensing Temperature, humidity, light, GPS, Speed modalities Passive Infrared (PIR), and CO, NO2, CO2, Temp, Humidity accelerometer Special WISEBED federation, mobile Realistic mobility features robots, WiseLib

Specification – Resource selection – Reservation – Execution control – Configuration specs – Scheduling – Event injection – Provisioning of images – Deployment and – Monitoring – Definition of KPIs, configuration – Data collection debug & log info – Logging

Specification phase Setup phase Execution phase

• Identify clear experimentation objectives – What is the goal of your experiment? – What are the scenarios you want to evaluate and the assumptions you take? – What are the KPIs you want to collect or debugging parameters?

• Select adequate experimentation resources – Derive from above requirements for environment, scale, node capabilities, timing and topology – Know the existing testbed topology and characteristics – Consider availability of existing resources

• Configuring your experiment – Choose carefully how you want to log statistics and debug output and how to derive them – Instrument experimentation code adequately – Determine number of runs and duration of experiment interactively based on errors and desired confidence intervals

• Reserve selected resources for experiment – 3 methods of reservation supported, hidden behind the reservation API: GoogleCalendar, database or persistent memory

• Provide finalised images for upload to selected resources – An images will be mapped to each selected experimentation resource

• Initiate upload of experiment – Manual or automatic scheduling

• Experiments can be initiated and controlled during reserved time periods – Testbed environment provides functions to flash nodes, reset nodes, check if nodes are alive – A controller instance is required per experiment to interact with nodes (relay message back and forth) – Per default a controller sends data to you – Testbed provides means to send commands to a set of nodes through the controller

• Your logic in the experimentation code defines how your experiment can be controlled – Define handlers for start and stop commands, change of parameters, injection of specific events such as node failure or environmental events – Auxiliary board can provide energy measurement information or generation of external sensor stimuli

• You can decide freely the message payload of the trace messages generated by your experimentation nodes – Our implementation uses a TinyOS packet as payload

• Per default messages are sent live to your experimentation client via the controller and stored into an SQL experimentation data base – Store the binary format of the payload plus meta information (time stamp, node id, experiment id, etc.)

• You can see traces live or replay later in the testbed UI from the data base

• Beware of synchronisation of time stamps between nodes – GWs are synched via NTP and can be used to provide reference to attached nodes

• Plug-in based architecture to provide different views to trace data from the database – Raw traces from messages sent and received by nodes – Packet flow in topology view – Display metrics in line charts, e.g. end-to-end latency – Sensed values

• Traces can be exported to text file and processed outside the environment by analytical tools

• GUI or script based • Tools supporting of the entire experimentation cycle – Open APIs with appropriate documentation – Transparent and seamless – Secure

• Management and experimentation support functionalities – isNodeAlive()

IEEE 802.15.4 Node isNodeAlive TR@PS Node Node TR@PS SmartUI TR@PS TR@PS TR@PS Node Node TR@GW Node Node

Node Node

Administrators Experimenters Operations

• isNodeAlive()

Portal Server WISEBED TESTBED RUNTIME

WIRELESS SENSOR NETWORK API Experiment (IWSN) Client

SENSOR NETWORK AUTHENTICATION AND AUTHORIZATION (SNAA) Meshlium RESERVATION SYSTEM Gateway (RS) WISEBED TESTBED RUNTIME

protocoll WSN APP buffer WSN DEVICE APP messages

Device 1 Device 2 Device N Waspmote Waspmote ... Waspmote

XbeeSerialPortConnection

xbee api

ttyUSB0 ttyUSB1 = Service Data = Management Data Waspmote Waspmote = Experimentation Data 802.15.4 Digimesh = All Data Gateway Gateway Administrators Waspmote A Waspmote B Waspmote C Experimenters

• Wireless deployment of experiments and updates – flashProgram()

IEEE 802.15.4 Node flashProgram TR@PS Node Node TR@PS SmartUI TR@PS TR@PS TR@PS Node Node TR@GW Node Node

Node Node

Administrators Experimenters Operations

• flashProgram()

Portal Server WISEBED TESTBED RUNTIME

WIRELESS SENSOR NETWORK API Experiment (IWSN) Client

SENSOR NETWORK AUTHENTICATION AND AUTHORIZATION (SNAA) Meshlium RESERVATION SYSTEM Gateway (RS) WISEBED TESTBED RUNTIME

protocoll WSN APP buffer WSN DEVICE APP messages

Device 1 Device 2 Device N Waspmote Waspmote ... Waspmote

XbeeSerialPortConnection

xbee api

ttyUSB0 ttyUSB1 = Service Data = Management Data Waspmote Waspmote = Experimentation Data 802.15.4 Digimesh = All Data Gateway Gateway Administrators Waspmote A Waspmote B Waspmote C Experimenters

• Service provision – Parking Service • Parking iPhone app • GIS desktop app • Parking Panels

– Environmental Monitoring Service • Env Monitoring iPhone app • GIS desktop app

• Parking and Environmental monitoring observations and measurements

Service TR2USN HTTP post USN Client

Portal Server WISEBED TESTBED RUNTIME

WIRELESS SENSOR NETWORK API Experiment (IWSN) Client

SENSOR NETWORK AUTHENTICATION AND AUTHORIZATION (SNAA) Meshlium RESERVATION SYSTEM Gateway (RS) WISEBED TESTBED RUNTIME

protocoll WSN APP buffer WSN DEVICE APP messages

Device 1 Device 2 Device N Waspmote Waspmote ... Waspmote

XbeeSerialPortConnection

xbee api

ttyUSB0 ttyUSB1 = Service Data = Management Data Waspmote Waspmote = Experimentation Data 802.15.4 Digimesh Gateway Gateway Observations Service Customers = All Data Waspmote A Waspmote B Waspmote C

• Experimentation

Portal Server WISEBED TESTBED RUNTIME

WIRELESS SENSOR NETWORK API Experiment (IWSN) Client

SENSOR NETWORK AUTHENTICATION AND AUTHORIZATION (SNAA) Meshlium RESERVATION SYSTEM Gateway (RS) WISEBED TESTBED RUNTIME

protocoll WSN APP buffer WSN DEVICE APP messages

Device 1 Device 2 Device N Waspmote Waspmote ... Waspmote

XbeeSerialPortConnection

xbee api

ttyUSB0 ttyUSB1 = Service Data = Management Data Waspmote Waspmote = Experimentation Data 802.15.4 Digimesh = All Data Gateway Gateway

Waspmote A Waspmote B Waspmote C Experimenters