Recent Changes - Search:

SmartSantander Testbeds

Experimentation.Testbeds History

Hide minor edits - Show changes to output

Changed lines 97-99 from:
An overview of the EkoBus architecture

Attach:ahr.png
to:
An overview of the EkoBus architecture is given in the following picture.

Attach:ahr.png | EkoBus system architecture %% %center%
Changed line 99 from:
Attach:arh.png
to:
Attach:ahr.png
Changed lines 98-99 from:
Attach: arh.png
to:

Attach:arh.png
Added line 98:
Attach: arh.png
Changed line 3 from:
!! [[Experimentation/TestbedSantander | Santander]]
to:
Added line 14:
!! [[Experimentation/TestbedSantander | Santander]]
Changed lines 94-109 from:
!! [[Experimentation/TestbedBelgrade | Belgrade]]
to:
!! [[Experimentation/TestbedBelgrade | Belgrade]]
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

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:

* Web interface – A 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. The application interacts with the backend system using a set of web services. 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 – end-user can query the system using 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 Pancevo to optimize the public transport system.
Changed lines 56-61 from:
This WISEBED compatible testbed consists of 162 stationary nodes of three different kinds (iSense, TelosB and Pacemate) which are deployed indoors in 15 rooms.\\
To make sure that new applications do not harm the main test bed and running experiments
, a sandbox test bed comprising 18 nodes is deployed in an isolated room.\\
\\
The primary use case
of the Lübeck testbed is research and experimentation. Most of the sensor nodes are wired via an USB backbone which allows easy maintenance and failure recovery.\\
The testbed is maintained with the Testbed Runtime software,
which bases on the APIs defined during the WISEBED project.\\
Experimenters, which require a certain topology for their experiment, can create a logical topology independent of the physical one using ''Virtual Links''
.
to:
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
.

%center%Attach:Testbeds./cluster.jpg

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

%center%Attach:Testbeds./outdoornode.jpg

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.
Changed lines 81-91 from:
* A REST server for accessing the last readings from the different sensors when running some
specific collection application;
* A JAVA based GUI called TMON (Testbed MONitor) for exploring the topology by browsing
nodes using a semantic description of them and visualizing relation between them such as
links and presence of sources of interference (i.e., nearby WiFI access point). After selecting
the adequate resource for an experiment, through the TMON GUI the user can also reserve
nodes, configure them and automatically run experiments and collect results by providing a
first analysis/visualization of them or by storing them in an Experiment Repository;
* An Experiment Repository for experiment results storage/load accessible through a REST
interface and working in both modalities as standalone component accessible from custom
application or as component already integrated within the TMON GUI
to:
* A REST server for accessing the last readings from the different sensors when running some specific collection application;
* A JAVA based GUI called TMON (Testbed MONitor) for exploring the topology by browsing nodes using a semantic description of them and visualizing relation between them such as links and presence of sources of interference (i.e., nearby WiFI access point). After selecting the adequate resource for an experiment, through the TMON GUI the user can also reserve nodes, configure them and automatically run experiments and collect results by providing a first analysis/visualization of them or by storing them in an Experiment Repository;
* An Experiment Repository for experiment results storage/load accessible through a REST interface and working in both modalities as standalone component accessible from custom application or as component already integrated within the TMON GUI
Changed lines 64-65 from:
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.\\
to:
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.


%center%Attach:Testbeds./overview.jpg

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.

%center%Attach:Testbeds./hight.jpg

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:

* A REST server for accessing the last readings from the different sensors when running some
specific collection application;
* A JAVA based GUI called TMON (Testbed MONitor) for exploring the topology by browsing
nodes using a semantic description of them and visualizing relation between them such as
links and presence of sources of interference (i.e., nearby WiFI access point). After selecting
the adequate resource for an experiment, through the TMON GUI the user can also reserve
nodes, configure them and automatically run experiments and collect results by providing a
first analysis/visualization of them or by storing them in an Experiment Repository;
* An Experiment Repository for experiment results storage/load accessible through a REST
interface and working in both modalities as standalone component accessible from custom
application or as component already integrated within the TMON GUI
Changed lines 64-65 from:
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.
to:
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.\\
Changed lines 64-67 from:
The SmartSantander deployment at Guildford consists of 250 stationary nodes of heterogenous type (170 TelosB, 80 XM1000) which are deployed indoors in 50 rooms over a three floors building.\\
The primary use case of the Guildford testbed is research and experimentation. However, due to the nature of the provided sensing capabilities, some services can also be
deployed on top of the testbed. Such services comprise of energy monitoring at work desk, possibiliy to remotely turning off desk devices left on, monitoring of room lights left on.\\
All the sensor
nodes are wired via an USB backbone which allows easy maintenance and failure recovery.\\
The testbed is maintained with the Testbed Runtime software, which bases on
the APIs defined during the WISEBED project.\\
to:
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.
Added lines 46-53:

* Experimentation at service level: Some of the deployed nodes, due to battery constraint or
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.
Added lines 44-45:

%center%Attach:Testbeds./native.jpg
Changed lines 38-39 from:

.
to:
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:

* Native experimentation: Most of the deployed IoT Nodes (those with fewer constraints in terms of battery) can be flashed, as many times as required with different experiments, through OTAP(overthe-air programming) or MOTAP (Multihop OTAP), for nodes more than one hop away from the gateway. In this sense, researchers can test their own experiments, such as routing protocols, data mining techniques or network coding schemes. This experimentation is made available by using an additional IEEE 802.15.4 transceiver, thus isolating data traffic associated to experimentation from the generated by the service provision. Figure 4 shows a screenshot about the experimentation skills offered by the platform
.
Changed lines 34-48 from:
* Participatory Sensing: In this scenario users utilize their mobile phones to send physical sensing information, e.g. GPS coordinates, compass, environmental data such as noise, temperature, etc. This information feeds the SmartSantander platform. Users can also subscribe to services such as

All the devices shown in Figure 1 have been deployed associated to determined use cases developed within the project:
*'''Static environmental Monitoring'''
*'''Outdoor parking area management'''
*'''Parks and gardens irrigation'''
*'''Mobile Environmental Monitoring'''
*'''Traffic Intensity Monitoring'''
*'''Guidance to free parking lots'''
*'''Augmented Reality'''
*'''Participatory Sensing'''

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,both at node level and at service level
.

Apart from experimentation and service provision, network management is implemented in order to access deployed nodes to send/receive commands from them, update the firmware running on them, or load experiments. if allowed, through OTAP (Over The Air Programming).
to:
* Participatory Sensing: In this scenario users utilize their mobile phones to send physical sensing information, e.g. GPS coordinates, compass, environmental data such as noise, temperature, etc. This information feeds the SmartSantander platform. Users can also subscribe to services such as “the pace of the city”, where they can get alerts for specific types of events currently occurring in the city. Users can themselves also report the occurrence of such events, which will subsequently be propagated to other users that are subscribed to the respective type of events, etc.

%center%Attach:Testbeds./Details.jpg


.
Added line 25:
Added line 30:
Added line 32:
Changed lines 19-20 from:
* Outdoor parking area management. Almost 400 parking sensors (based on ferromagnetic technology), buried under the asphalt have been installed at the main parking areas of the city centre, in order to detect parking sites availability in these zones.
Deployment for environmental monitoring and outdoor parking area management is shown in the next figure:
to:
* Outdoor parking area management. Almost 400 parking sensors (based on ferromagnetic technology), buried under the asphalt have been installed at the main parking areas of the city centre, in order to detect parking sites availability in these zones. Deployment for environmental monitoring and outdoor parking area management is shown in the next figure:
Added line 5:
Added line 7:
Changed lines 9-11 from:
Facilities Description
to:

'''
Facilities Description'''
Added line 13:
Added line 15:
Added line 17:
Changed line 4 from:
Introduction
to:
'''Introduction'''
Changed line 9 from:
Santander summary
to:
'''Santander summary'''
Changed lines 11-12 from:
- Environmental Monitoring. Around 2000 IoT devices installed (mainly at the city centre), at streetlights, facades provide measurements on different environmental parameters, such as temperature, CO, noise, light and car presence).
- Outdoor parking area management. Almost 400 parking sensors (based on ferromagnetic technology), buried under the asphalt have been installed at the main parking areas of the city centre, in order to detect parking sites availability in these zones.
to:
* Environmental Monitoring. Around 2000 IoT devices installed (mainly at the city centre), at streetlights, facades provide measurements on different environmental parameters, such as temperature, CO, noise, light and car presence).
* Outdoor parking area management. Almost 400 parking sensors (based on ferromagnetic technology), buried under the asphalt have been installed at the main parking areas of the city centre, in order to detect parking sites availability in these zones.
Changed lines 19-22 from:
- Mobile Environmental Monitoring: In order to extend the aforementioned environmental monitoring use case, apart from measuring parameters at static points, devices located at vehicles retrieve environmental parameters associated to determined parts of the city. Sensors are installed in 150 public vehicles, including buses, taxis and police cars.
- Traffic Intensity Monitoring: Around 60 devices located at the main entrances of the city of Santander have been deployed to measure main traffic parameters, such as traffic volumes, road occupancy, vehicle speed or queue length.
- Guidance to free parking lots: Taking information retrieved by the deployed parking sensors, 10 panels located at the main streets’ intersections have been installed in order to guide drivers towards the available free parking lots.
- Parks and gardens irrigation: Around 50 devices have been deployed in two green zones of the city, to monitor irrigation-related parameters, such as moisture temperature and humidity, pluviometer, anemometer, in order to make irrigation as efficient as possible.
to:
* Mobile Environmental Monitoring: In order to extend the aforementioned environmental monitoring use case, apart from measuring parameters at static points, devices located at vehicles retrieve environmental parameters associated to determined parts of the city. Sensors are installed in 150 public vehicles, including buses, taxis and police cars.
* Traffic Intensity Monitoring: Around 60 devices located at the main entrances of the city of Santander have been deployed to measure main traffic parameters, such as traffic volumes, road occupancy, vehicle speed or queue length.
* Guidance to free parking lots: Taking information retrieved by the deployed parking sensors, 10 panels located at the main streets’ intersections have been installed in order to guide drivers towards the available free parking lots.
* Parks and gardens irrigation: Around 50 devices have been deployed in two green zones of the city, to monitor irrigation-related parameters, such as moisture temperature and humidity, pluviometer, anemometer, in order to make irrigation as efficient as possible.
Changed lines 24-25 from:
- Augmented Reality: Around 2000 RFID tag/QR code labels have been deployed, offering the possibility of “tagging” points of interest in the city, for instance a touristic point of interest, shops and public places such as parks, squares, etc. In a small scale, the service provides the opportunity to distribute information in the urban environment as location based information.
- Participatory Sensing: In this scenario users utilize their mobile phones to send physical sensing information, e.g. GPS coordinates, compass, environmental data such as noise, temperature, etc. This information feeds the SmartSantander platform. Users can also subscribe to services such as
to:
* Augmented Reality: Around 2000 RFID tag/QR code labels have been deployed, offering the possibility of “tagging” points of interest in the city, for instance a touristic point of interest, shops and public places such as parks, squares, etc. In a small scale, the service provides the opportunity to distribute information in the urban environment as location based information.
* Participatory Sensing: In this scenario users utilize their mobile phones to send physical sensing information, e.g. GPS coordinates, compass, environmental data such as noise, temperature, etc. This information feeds the SmartSantander platform. Users can also subscribe to services such as
Added lines 17-25:

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].
- Mobile Environmental Monitoring: In order to extend the aforementioned environmental monitoring use case, apart from measuring parameters at static points, devices located at vehicles retrieve environmental parameters associated to determined parts of the city. Sensors are installed in 150 public vehicles, including buses, taxis and police cars.
- Traffic Intensity Monitoring: Around 60 devices located at the main entrances of the city of Santander have been deployed to measure main traffic parameters, such as traffic volumes, road occupancy, vehicle speed or queue length.
- Guidance to free parking lots: Taking information retrieved by the deployed parking sensors, 10 panels located at the main streets’ intersections have been installed in order to guide drivers towards the available free parking lots.
- Parks and gardens irrigation: Around 50 devices have been deployed in two green zones of the city, to monitor irrigation-related parameters, such as moisture temperature and humidity, pluviometer, anemometer, in order to make irrigation as efficient as possible.
Description of hardware deployed, software architecture and integration within SmartSantander platform are discussed in detail in the ANNEX I.
- Augmented Reality: Around 2000 RFID tag/QR code labels have been deployed, offering the possibility of “tagging” points of interest in the city, for instance a touristic point of interest, shops and public places such as parks, squares, etc. In a small scale, the service provides the opportunity to distribute information in the urban environment as location based information.
- Participatory Sensing: In this scenario users utilize their mobile phones to send physical sensing information, e.g. GPS coordinates, compass, environmental data such as noise, temperature, etc. This information feeds the SmartSantander platform. Users can also subscribe to services such as
Changed line 15 from:
%center%Attach:Testbeds./Outdoor.jpg
to:
%center%Attach:Testbeds./Outdoors.jpg
Changed line 15 from:
%center%Attach:Testbeds./sdr_deployment.jpg
to:
%center%Attach:Testbeds./Outdoor.jpg
Changed line 16 from:
%center%'-Figure1: Santander deployment (constantly updated)-'
to:
%center%'-Figure1: Outdoor parking and Environmental Monitoring deployed architecture-'
Changed lines 4-13 from:
The Santander testbed is composed of around 3000 IEEE 802.15.4 devices, 200 devices (mainly mobile) with GPRS communication capabilities 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). Current deployment is shown in the next figure (mainly in the centre of the city), being this map continuously updating with new/replaced devices.
to:
Introduction
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:
- Environmental Monitoring. Around 2000 IoT devices installed (mainly at the city centre), at streetlights, facades provide measurements on different environmental parameters, such as temperature, CO, noise, light and car presence).
- Outdoor parking area management. Almost 400 parking sensors (based on ferromagnetic technology), buried under the asphalt have been installed at the main parking areas of the city centre, in order to detect parking sites availability in these zones.
Deployment for environmental monitoring and outdoor parking area management is shown in the next figure:
Deleted lines 1-2:
TODO: In the sub sections describe the key features of the test beds according to a common scheme. Description should contain
available node types, location of nodes, endpoints for accessing the testbed.
December 14, 2012, at 11:03 AM by 193.144.201.34 -
Added lines 6-24:
The Santander testbed is composed of around 3000 IEEE 802.15.4 devices, 200 devices (mainly mobile) with GPRS communication capabilities 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). Current deployment is shown in the next figure (mainly in the centre of the city), being this map continuously updating with new/replaced devices.

%center%Attach:Testbeds./sdr_deployment.jpg
%center%'-Figure1: Santander deployment (constantly updated)-'

All the devices shown in Figure 1 have been deployed associated to determined use cases developed within the project:
*'''Static environmental Monitoring'''
*'''Outdoor parking area management'''
*'''Parks and gardens irrigation'''
*'''Mobile Environmental Monitoring'''
*'''Traffic Intensity Monitoring'''
*'''Guidance to free parking lots'''
*'''Augmented Reality'''
*'''Participatory Sensing'''

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,both at node level and at service level.

Apart from experimentation and service provision, network management is implemented in order to access deployed nodes to send/receive commands from them, update the firmware running on them, or load experiments. if allowed, through OTAP (Over The Air Programming).
December 05, 2012, at 01:42 PM by 90.209.177.33 -
Changed lines 5-6 from:
!! [[Experimentation/TestbedSantander]]
!! [[Experimentation.TestbedLübeck]]
to:
!! [[Experimentation/TestbedSantander | Santander]]
!! [[Experimentation/TestbedLübeck | Lübeck]]
Changed line 14 from:
!! [[Experimentation/TestbedGuildford]]
to:
!! [[Experimentation/TestbedGuildford | Guildford ]]
Changed line 20 from:
!! [[Experimentation/TestbedBelgrade]]
to:
!! [[Experimentation/TestbedBelgrade | Belgrade]]
December 05, 2012, at 01:41 PM by 90.209.177.33 -
Added lines 1-20:
(:Title SmartSantander Testbeds:)
TODO: In the sub sections describe the key features of the test beds according to a common scheme. Description should contain
available node types, location of nodes, endpoints for accessing the testbed.

!! [[Experimentation/TestbedSantander]]
!! [[Experimentation.TestbedLübeck]]
This WISEBED compatible testbed consists of 162 stationary nodes of three different kinds (iSense, TelosB and Pacemate) which are deployed indoors in 15 rooms.\\
To make sure that new applications do not harm the main test bed and running experiments, a sandbox test bed comprising 18 nodes is deployed in an isolated room.\\
\\
The primary use case of the Lübeck testbed is research and experimentation. Most of the sensor nodes are wired via an USB backbone which allows easy maintenance and failure recovery.\\
The testbed is maintained with the Testbed Runtime software, which bases on the APIs defined during the WISEBED project.\\
Experimenters, which require a certain topology for their experiment, can create a logical topology independent of the physical one using ''Virtual Links''.

!! [[Experimentation/TestbedGuildford]]
The SmartSantander deployment at Guildford consists of 250 stationary nodes of heterogenous type (170 TelosB, 80 XM1000) which are deployed indoors in 50 rooms over a three floors building.\\
The primary use case of the Guildford testbed is research and experimentation. However, due to the nature of the provided sensing capabilities, some services can also be deployed on top of the testbed. Such services comprise of energy monitoring at work desk, possibiliy to remotely turning off desk devices left on, monitoring of room lights left on.\\
All the sensor nodes are wired via an USB backbone which allows easy maintenance and failure recovery.\\
The testbed is maintained with the Testbed Runtime software, which bases on the APIs defined during the WISEBED project.\\

!! [[Experimentation/TestbedBelgrade]]
Edit - History - Print - Recent Changes - Search
Page last modified on July 18, 2013, at 11:38 AM