3758 IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO.

12, DECEMBER 2015

SOSLite: Lightweight Sensor Observation

Service (SOS)
J. Pradilla, M. Esteve and C. Palau, Senior Member, IEEE

Abstract— Internet of Things (IoT) platforms interoperability
is a major issue in current IoT scenarios. There are different
mechanisms to achieve interoperability and Open Geospatial
Consortium (OGC) with Sensor Web Enablement (SWE) block
of standards like Sensor Observation Service (SOS) has provided
the ability to interoperate at different layers, following a
centralized approach. However, IoT nature is distributed and a
new approach is needed. At the same time, current SOS
implementations provide several services and components that
are rarely used and affect performance, and are mainly focused
for large sensor deployments. In this paper we propose a
lightweight SOS design, named SOSLite, based in the OGC
consolidated SWE standards able to be executed in low resources
devices (e.g. RaspberryPi) and allow fast interoperability and
scalability. The proposed use case in which the proposed system
has been tested is m-health and concretely ambient assisted
living.
Keywords— Sensor Observation Service (SOS), Internet of
Things (IoT), Sensors Networks, Sensor Web Enablement
(SWE).
I. INTRODUCCIÓN
E N la actualidad existen más de 8 billones de sensores
desplegados en el mundo y se estima que para el año 2020
esta cifra exceda el trillón de sensores [1]. Esta incremento
vertiginoso en la adopción de sensores hace que cada día sea
más común el tener una interacción con unos de estos
dispositivos; por ejemplo, gran cantidad de teléfonos
inteligentes cuentan con: GPS/GLONASS, giroscopio,
acelerómetro, magnetómetro, sensor de luz ambiental, sensor
de proximidad y brújula electrónica; mientras que muchos
edificios tienen sensores de: humo, temperatura y movimiento.
La interacción ha generado una relación más estrecha entre las
personas y la tecnología, haciendo que esta última sea ubicua
en el diario vivir.
Así, las tecnologías ubicuas basadas en sensores están
asociadas a una mejora de la comodidad dentro de un recinto,
por ejemplo, al mantener una temperatura agradable dentro de
él; también son útiles para apoyar el consumo eficiente de
energía eléctrica, al encender o apagar aparatos eléctricos
según la presencia o ausencia de personas en un lugar; y de
igual forma, aumentan la seguridad al detectar posibles
intrusos en una bodega comercial.
Ante tal despliegue de sensores y las redes que los
interconectan se hace necesario mantener un estándar que
J. Pradilla, Universitat Politècnica de Valencia (UPV), Valencia, Spain,
juaprace@teleco.upv.es
M. Esteve, Universitat Politècnica de Valencia (UPV), Valencia, Spain,
mesteve@upvnet.upv.es
C. Palau, Universitat Politècnica de Valencia (UPV), Valencia, Spain,
cpalau@dcom.upv.es
permita la interoperabilidad de estos, al tiempo que posibilita
el almacenamiento, procesamiento y consulta de los datos que
registran. Con este fin varios miembros del sector tecnológico
se adscriben al OGC y crean el marco de estándares SWE [2],
entre los cuales se encuentra el estándar SOS [3].
El SOS proporciona una interfaz estándar para la gestión y
recuperación de meta-datos y observaciones desde sistemas de
sensores heterogéneos [3]. Está fundamentado en tecnologías
web ampliamente aceptadas como XML y SOAP; lo que ha
permitido que este estándar sea reconocido y utilizado por
multitud de dispositivos; y además, que para el desarrollo de
clientes y servidores basados en este, se puedan contar con
herramientas y librerías que faciliten esta labor.
De esta forma, el SOS provee unas interfaces bien
conocidas, basadas en SOAP, para el intercambio de mensajes
que permitan la interconexión de dispositivos con distintas
capacidades, de diversos proveedores, desarrollados con
tecnologías diferentes y que emplean tecnologías de conexión
diversas; abstrayendo la complejidad inherente al dispositivo y
logrando redes de sensores heterogéneas funcionales.
Sumando a estas interfaces, el estándar SOS se
complementa con mensajes, basados en XML, con una
estructura flexible, ricos semánticamente y bien definidos
mediante el modelo conceptual ISO Observations and
Measurements (O&M) [4] y el Sensor Model Language
(SensorML) [5], para las observaciones y los sensores
respectivamente.
El estándar SOS responde a una inmensa cantidad de casos
de uso aprovechando su flexibilidad para adaptarse a cada uno
de ellos. A partir del estándar, se han desarrollado diferentes
soluciones de software asociados a los diversos casos de uso
en los que se puede aplicar el SOS. Esta potencialidad del
SOS conlleva que los desarrollos de software deban manejar
una alta complejidad y para ello utilizan grandes recursos
computacionales (procesadores, memoria de almacenamiento
y memoria de procesamiento). Lo que implica que se requiera
de un servidor central con una capacidad amplia de
procesamiento y almacenamiento para desplegar el SOS.
Esta aproximación de servidor central de amplias
capacidades es adecuado para algunos casos de uso; sin
embargo, se hace necesario contar con un desarrollo de
software que pueda desplegarse en dispositivos con unos
recursos muchos más limitados que los de un servidor
centralizado.
Para ello, el nuevo desarrollo disminuye su complejidad y
se centra en las situaciones más comunes que se pueden
encontrar en entornos no centralizados. La iniciativa SOSLite,
aprovecha las ventajas de estar basado en un estándar y
posibilita el despliegue en equipos de recursos de hardware
PRADILLA et al.: SOSLITE: LIGHTWEIGHT SENSOR 3759

limitados. que se puede aplicar.

El resto de este articulo está estructurado de la siguiente
forma: en la sección II se presenta el trabajo relacionado
explicando el estándar actual, los desarrollos de software
basados en este y la opción de tener un estándar ligero; la
sección III presenta el SOSLite sus funcionalidades y
desarrollo; por su parte la sección IV evalúa las prestaciones
del SOSLite en un entorno simulado; y finalmente, se
presentan las conclusiones del trabajo realizado y las posibles
líneas de trabajo futuro.
II. TRABAJO RELACIONADO
A. Sensor Observation Service (SOS)
El estándar del SOS en su versión 2.0 fue publicado en el
año 2012 en el documento “OGC® Sensor Observation
Service Interface Standard” [3]. El SOS provee un conjunto de
operaciones que permiten realizar acciones sobre sensores y
observaciones (las mediciones de los sensores); estas
operaciones se encuentran agrupadas en un núcleo y cuatro
extensiones (Tabla I) [3]. El núcleo debe ser implementado
por cualquier desarrollo de software basado en SOS, mientras
que las extensiones son opcionales y pueden ser incluidas en
el desarrollo o en el despliegue según las necesidades del
escenario en el cual se vaya a utilizar. Existen diferentes
ejemplos que muestran su flexibilidad y capacidad para
interoperar, tales como: registrar observaciones de la Tierra
desde sensores satelitales [6][7][8], seguridad industrial y
seguimiento del comportamiento de los trabajadores dentro de
las fabricas [9], y almacenamiento y procesamiento de datos
ambientales [10].
B. Sensor Observation Service (SOS) Lightweight
Las implementaciones del SOS suelen ser complejas y
requerir de unos recursos computacionales significativos para
su despliegue, debido al amplio espectro de escenarios en los
Motivados por esta situación, el OGC ha decidido dar un
paso adelante y realizar una recomendación para SOS Ligero
[11]. Esta recomendación simplifica las operaciones
principales del SOS, de forma que se adapte a escenarios de
sensores estacionarios; al tiempo que, acorta los lenguajes
para descripción de sensores (SensorML) y observaciones
(O&M) haciéndolos más sencillos de procesar; encontrando
un equilibrio entre eficiencia, facilidad de implementación y
cumplimiento del estándar.
La recomendación se enfoca en tres aspectos: (i) reducir el
número de operaciones, centrándose solo en las operaciones
core; (ii) reducir la complejidad de las operaciones, por
ejemplo limitando el tipo de filtros; y (iii) enfocándose en los
sensores estacionarios, al ser los que mayormente se utilizan
en los despliegues reales que utilizan SOS; Cabe anotar que
los sensores móviles se pueden modelarse como sensores
estacionarios dentro de un periodo tiempo determinado.
No es difícil encontrar casos de uso en los cuales aplicar
esta recomendación, por ejemplo en las redes de sensores
asociados a: la automatización del hogar (domótica), la
eSalud, el seguimiento del estado de los vehículos y la
medición de actividad física en las personas.
III. SOSLITE
A. Arquitectura
El SOSLite es una propuesta e implementación de SOS
ligero que se fundamenta en la recomendación del OGC y en
el estándar SOS 2.0 para proveer las operaciones del “core”, al
igual que de la extensión “transactional” (Tabla I); obteniendo
de esta forma la capacidad de realizar operaciones de registro,
consulta, actualización y eliminación de sensores y
observaciones.

TABLA I. OPERACIONES DEL SENSOR OBSERVATION SERVICE (SOS) – CORE Y EXTENSIONES.

Extensión Operación Descripción

GetCapabilities Pide la auto-descripción del servicio
Core GetObservation Obtiene los datos medidos por un sensor en formato O&M
DescribeSensor Adquiere los meta-datos de un sensor en formato SensorML
GetFeatureOfInterest Obtiene un feature en formato GML
Enhanced
GetObservaitonById Pide los datos medidos por un sensor en formato O&M por un identificador especifico
InsertSensor Agrega un nuevo sensor
UpdateSensorDescription Actualiza la descripción de un sensor
Transactional
DeleteSensor Elimina un sensor
InsertObservation Agrega los datos medidos por un sensor
InsertResultTemplate Inserta una plantilla que describe la estructura y la codificación que se utilizara para retornar los datos
en la operación GetResult
InsertResult Carga los datos en bruto según una estructura y una codificación definido en la operación
Result Handling InsertResultTemplate
GetResultTemplate Adquiere la estructura para los resultados y la codificación para un conjunto de parámetros
GetResult Obtiene los datos en bruto para un conjunto de parámetros específicos
3760
Debido a que las operaciones de la extensión
“transactional” no requieren de una descripción de datos
adicional a las ofrecidas en las operaciones “core”; dentro del
SOSLite se emplean los lenguajes SensorML y O&M acorde a
lo expuesto en la recomendación del perfil ligero de la OGC
[11].
De esta forma, el SOSLite se puede emplear para la gestión
de los meta-datos de sensores y los datos que los sensores
registran (observaciones) en: sensores individuales, redes de
sensores o como repositorio intermedio en una arquitectura
jerarquizada de un sistema ciber-físico [12] [13] [14].
El SOSLite se encuentra compuesto por un fichero
descriptor de las operaciones SOAP en formato WSDL y una
Figura 1. Arquitectura de alto nivel del SOSLite.
B. Implementación
Para el desarrollo de la implementación del SOSLite se
estudiaron diversas tecnologías, incluyendo el lenguaje de
programación; el tipo y gestor de base de datos; y el servidor
para desplegarlo. Las tecnologías para el desarrollo y las
pruebas de esta propuesta, fueron escogidas a partir de la
descripción de las necesidades para una implementación de
SOS ligero y la caracterización del tipo de información típica
que se transmite y almacena dentro de una red de sensores.
Como lenguaje de programación se seleccionó PHP [15] en
su versión 5.4, que permite el desarrollo de servicios web
basados en SOAP y XML de forma nativa, permitiendo una
correcta implementación del SOS.
La base de datos empleada es MongoDB [16] en su versión
IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO. 12, DECEMBER 2015
serie de operaciones SOAP que se corresponden al “core” y la
extensión “transactional” del SOS según la recomendación
“Lightweight” [11]. Los datos se almacenan en dos
repositorios: uno de ellos el sistema de ficheros, donde se
almacenan los meta-datos de sensores en formato SensorML y
los datos de las observaciones en formato O&M; y el otro es
una base de datos NoSQL, que almacenan los datos de
sensores y observaciones necesarios para atender a las
operaciones SOAP y obtener los ficheros asociados a las
respuestas de las operaciones. El SOSLite puede dar respuesta
a peticiones de: objetos inteligentes, redes de sensores u otros
SOS. La arquitectura se encuentra representada en la Fig. 1.
2.6. MongoDB es una base de datos NoSQL de código
abierto, multi-plataforma, orientada a documentos en formato
BSON (Binary JSON); la cual ha vivido una aceptación
vertiginosa en los últimos años y en la actualidad cuenta con
una comunidad muy activa. MongoDB es ideal para el registro
de eventos y para bases de datos pequeñas (inferiores a las
100GB), con pocas relaciones entre conceptos e intensivas en
operaciones de lectura. Debido a que la caracterización de los
datos que se almacenan en las redes de sensores, los cuales
son poco relacionales, con una estructura heterogénea que
puede variar en el tiempo y con un tamaño en bytes pequeño
se escogió esta base de datos por considerarla adecuada a los
escenarios para los cuales se ha diseñado esta solución.
De igual forma, se ha realizado un proceso para la
escogencia del servidor sobre el cual se realizan las pruebas
PRADILLA et al.: SOSLITE: LIGHTWEIGHT SENSOR
del desarrollo, en este caso se eligió NGINX [17] un servidor
web/proxy de código abierto, multi-plataforma y ampliamente
utilizado por los líderes de la industria tecnológica. NGINX
está especializado en el manejo de grandes volúmenes de
datos debido a su implementación basado en eventos
asíncronos; es este tipo de funcionamiento el que lo hace ideal
para atender fuentes de peticiones simultáneas y con una
tipología de tráfico orientado a eventos como la presente en
las redes de sensores.
Las dos operaciones del SOS que se emplean con mayor
frecuencia dentro de una red de sensores son GetObservation,
perteneciente al “core”, e InsertObservation, que hace parte de
la extensión “transitional”; estas dos operaciones permiten la
consulta y el registro de los datos que han sido generados por
los sensores. Su funcionamiento se describe en los diagramas
de secuencia asociadas a estas (Fig. 2 y Fig. 3).
Figura 2. Diagrama de secuencia de la operación GetObservation.
Figura 3. Diagrama de secuencia de la operación InsertObservation.
3761
IV. EVALUACIÓN
A. Caso de Uso – Agricultura de Precisión
El desarrollo de una tecnología debe ir orientada a
responder una o varias necesidades, en este caso se ha visto
como la Agricultura de Precisión (AP) se puede ver
beneficiada del uso del SOSLite y encontrar respuesta a
múltiples necesidades que se han ido presentando dentro de
este ámbito.
Las actividades vinculadas a la agricultura de precisión
incluyen: la identificación y localización de cultivos, malezas
y maquinaria; la monitorización del rendimiento; la
dosificación variable de fertilizantes, herbicidas, insecticidas y
fungicidas; la monitorización de la siembra; y la clasificación
y mapeo de suelos. Para lograr realizar con éxito estas
actividades se suelen emplear diversas unidades de medición:
una red de sensores medio ambientales, uno o varios drones y
una red de sensores en la maquinaria agrícola y los aperos.
Más en detalle, la red de sensores ambientales mide: la
temperatura, la pluviosidad, la velocidad del viento, la
humedad en el aire, la humedad del suelo, el PH del suelo,
entre otros. Se encuentran distribuidos en la propiedad como
pequeñas estaciones meteorológicas y sensores distribuidos en
el terreno.
Por su parte, los drones se encuentran equipados con
cámaras de amplio espectro las cuales permiten monitorizar
los parámetros de desarrollo del cultivo y cámaras de alta
resolución para hacer el levantamiento de la información
topográfica; también se acompañan de sensores de
posicionamiento para determinar la ubicación de los datos
obtenidos.
Así mismo, las redes de sensores montados sobre los
aperos o la maquinaria agrícola se encargan de medir
parámetros como la producción en un área determinada y de
realizar operaciones como determinar la cantidad óptima de
fertilizante a aplicar en una zona. A partir de los datos de los
sensores se calculan parámetros como la tasas de rendimiento
o la presencia de malezas.
Estas unidades de medición se puede asociar a un
despliegue de SOSLite, así: la red de sensores ambientales
registra los datos de todos los sensores dentro del SOSLite
utilizando las operación InsertObservation; por su parte, cada
dron cuenta con una instancia de SOSLite donde registra las
fotografías geo-posicionadas utilizando la misma operación;
de la misma forma, cada maquinaria lleva consigo un SOSLite
donde registra los datos de sus sensores, esta información
luego puede ser empleada por otro servicio que calcule la
cantidad de fertilizante aplicar haciendo consultas mediante
GetObservation sobre el SOSLite.
Se puede identificar que la red de sensores
medioambientales es una red con sensores y con un número de
observaciones (medidas de los sensores) bajo; por su parte un
dron tiene solo dos sensores (la cámara y el GPS) pero realiza
observaciones de forma intensiva (toma un par de imágenes
por segundo); finalmente, la maquinaria se encuentra a medio
camino entre observaciones y sensores.
3762
B. Entorno de Pruebas
Con el fin de evaluar el funcionamiento del SOSLite se ha
realizado un montaje básico de pruebas que cuenta con: un
ordenador donde se ejecuta el programa para pruebas de carga,
un equipo de intercomunicación y un dispositivo de recursos
limitados; (Fig. 4). El dispositivo limitado es una Raspberry Pi
modelo B que cuenta con: procesador ARM a 700 MHz, 512
MB de memoria SDRAM, 2 GB de memoria de
almacenamiento SD y un consumo energético de 700 mA, (3.5
W).
Figura 4. Diagrama del entorno de pruebas.
Por su parte, la generación de las pruebas de carga se ha
realizado mediante jMeter [18], el cual es un proyecto de
código abierto, escrito en JAVA, de la Fundación de Software
Apache y el cual se encuentra especializado en la generación
de carga para el análisis de desempeño de los servicios
basados en estándares web (como SOAP/XML). JMeter se
instaló en un ordenador personal con sistema operativo
GNU/Linux distribución Ubuntu 14.04 LTS y OpenJDK 8
(Fig. 5).
Figura 5. Captura del programa de simulación de prueba de carga jMeter.
C. Escenarios de Prueba
La realización de las pruebas se basó en diez potenciales
escenarios los cuales modelan entornos posibles en redes de
sensores pequeñas que pueden ser atendidas por el SOSLite
desplegado en un dispositivo de recursos limitados, como la
IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO. 12, DECEMBER 2015
Raspberry Pi B. Estos escenarios se enfocan en la consulta
(GetObservation - 5 escenarios) e inserción (InsertObservation
- 5 escenarios) de observaciones, que serán las operaciones
más frecuentemente utilizadas en estos entornos. Estos casos
de uso son (Tabla II):
TABLA II. CASOS DE USO.
Operación Escenario # Sensores # Observaciones
1 2 250
2 5 100
GetObservation 3 10 50
4 20 25
5 50 10
1 2 250
2 5 100
InsertObservatio
3 10 50
n
4 20 25
5 50 10
Los escenarios para cada una de las operaciones siguen una
progresión similar, siendo los primeros intensivos en
observaciones y los últimos casos de uso intensivos sensores.
De esta forma se abarcan escenarios con una gran precisión en
las mediciones (útiles en ambientes fuertemente variables) y
escenarios con una amplia disponibilidad de sensores (ideal
para ambientes complejos).
En cada uno de los escenarios se presenta el throughput; y
además el promedio, la mediana y la desviación estándar del
retardo. Con estas medidas se espera caracterizar el
rendimiento del SOSLite en el ambiente de pruebas y según
los escenarios de uso planteados; utilizando para ello las
operaciones GetObservation e InsertObservation con datos
generados de forma automática y que siguen la estructura y
complejidad propia de los datos que circularían en una red de
sensores real.
D. Resultados
Una vez realizadas las pruebas se han graficado los
resultados en la Fig. 6 para la operación GetObservation y en
la Fig. 7 para la operación InsertObservatión. Para mejorar la
visualización de los resultados se han eliminado las primeras
60 medidas que constituyen el periodo transitorio y que al
encontrarse muy dispersas con respecto al comportamiento
normal hacen que las gráficas pierdan detalle.
Se puede observar en las gráficas que la cantidad de
peticiones por segundo (throughput) se acerca a 6 para las dos
operaciones; esto implica que para cada una de estas
peticiones se obtiene un tiempo de respuesta inferior a los 200
ms; que es un valor aceptable en muchos entornos reales
donde se utilizan las redes de sensores.
Por su parte, se demuestra que la cantidad de operaciones que
realiza un sensor o un cliente no tiene un impacto significativo
en el retardo dado que los valores (promedio, mediana y
desviación estándar del retardo) permanecen bastantes
constantes a pesar del aumento de paquetes enviados.
PRADILLA et al.: SOSLITE: LIGHTWEIGHT SENSOR
Sin embargo, para las dos operaciones, el aumento en la
cantidad de sensores o clientes realizando consultas, conlleva
un deterioro en las prestaciones. Este hecho debe ser
profundizado dado que puede ser explicado dentro del
funcionamiento normal de la aplicación pero también se puede
Figura 6. Operación GetObservation (a) throughput, (b) promedio, (c) mediana, (d) desviación estándar
Figura 7. Operación InsertObservation (a) throughput, (b) promedio, (c) mediana, (d) desviación estándar
V. CONCLUSIONES.
El uso de un SOS ligero puede ayudar a mejorar las
prestaciones en las redes de sensores al tiempo que abarata los
costos de despliegue, en especial si se tiene en cuenta el
aumento vertiginoso que está viviendo esta tecnología a nivel
global.
Con el SOSLite se ha demostrado que se puede obtener un
repositorio de datos estándar y eficiente que responda a
múltiples escenarios reales, mejorando la interoperabilidad en
entornos heterogéneos como las redes de sensores y
propiciando nuevos casos de uso que aprovechen la
posibilidad de tener un almacenamiento distribuido.
3763
deber a que todos los generadores utilizan la misma interfaz de
red y cable para realizar las operaciones; si se considera que la
naturaleza del retardo incluye el tiempo en tránsito dentro de
la red, es necesario que posteriormente se descarte que este
tiempo sea el que afecte de forma significativa las mediciones.
Además, con el SOSLite se pueden contar con un SOS que
puede desplegarse en equipos limitados pero económicos, al
tiempo que se mantiene un desempeño suficiente para hacer
frente a entornos pequeños; lo que abre las posibilidades de
profundizar en la internet de las cosas (IoT) y la inteligencia
distribuida sin entrar en grandes costos para las empresas y los
particulares.
Finalmente, se requiere seguir profundizando en las
pruebas del SOSLite y aplicándolo a casos de uso en entornos
reales que validen su funcionalidad y que muestren su
potencialidad. Aprovechando que ha sido desarrollado como
código abierto se hace fundamental que una comunidad crezca
alrededor de el para mejorar sus prestaciones y brindar apoyo
a las personas y empresas que quieran utilizarlo.
3764 IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO. 12, DECEMBER 2015

REFERENCIAS several R&D projects at regional, national and international level. He has
collaborated extensively in the R&D of projects for the government agencies,
[1] H. Sundmaeker, P. Guillemin, P. Friess and S. Woelffle, “Vision and defence and EU-FP7 acting as chairman of the agreement between Spanish
challenges for realizing the Internet of Things”, CERP-IoT: Cluster of MoD and UPVLC. He is author and co-author of more than 100 research
European Research Projects on the Internet of Things, 2010. papers.
[2] M. Botts, G. Percivall, C. Reed and J. Davidson, “OCG® Sensor Web
Enablement: Overview And High Level Architecture”, OGC: Open Carlos E. Palau received his M.Sc. and Ph.D. (Dr.Ing.)
Geospatial Consortium Inc., 2007. degrees, both in telecommunication engineering, from the
[3] A. Bröring, C. Stasch and J. Echterhoff, “OGC® Sensor Observation Universitat Politecnica de Valencia in 1993 and 1997,
Service Interface Standard”, OGC: Open Geospatial Consortium Inc., respectively. He is Full Professor in the Escuela Tecnica
2012. Superior de Ingenieros de Telecomunicación at the
[4] S. Cox, “Observations and Measurements – XML Implementation”, Universitat Politecnica de Valencia. He has more than 18
OGC: Open Geospatial Consortium Inc., 2011. years of experience in the ICT research area in the area of
[5] M. Botts and A. Robin, “OGC® SensorML”, OGC: Open Geospatial Networking. He has collaborated extensively in the R&D of multimedia
Consortium Inc., 2012. streaming, security, networking and wireless communications for government
[6] N. Chen, Z. Chen, L. Di and J. Gong, “An efficient Method for Near- agencies, defence and European Commission. He has been the main UPVLC
Real-Time On-Demand Retrieval of Remote Sensing Observations”, in researcher in the FASYS project, which has funded this work. He is author
IEEE Journal of Selected Topics in Applied Earth Observations and and co-author of more than 120 research papers and member of the TPC of
Remote Sensing, vol. 4, no 3, pp. 615-625, 2011. several IEEE, ACM and IFIP conferences. He is Senior Member of IEEE.
[7] H. Wang, L. Di, G. Yu and B. Zhang, “Implementation of Sensor
Observation Service for Satellite Imagery Sensors”, in Proc. IEEE 17th
International Conference on Geoinformatics, pp. 1-5, 2009.
[8] B. Zhang, L. Di, G. Yu, W. Han and H. Wang, “Towards Data and
Sensor Planning Service for Coupling Earth Science Models and Earth
Observations”, in IEEE Journal of Selected Topics in Applied Earth
Observations and Remote Sensing, vol. 5, no 6, pp. 1628-1636, 2012.
[9] P. Giménez, B. Molina, J. Calvo-Gallego, M. Esteve and C. Palau,
“I3WSN: Industrial Intelligent Wireless Sensor Networks for indoor
enviroments”, in Computers in Industry, ELSEVIER SCIENCE BV,
vol. 65, no. 1, pp. 187-199, 2014.
[10] D. Hilbring, A. Moumtzidou, J. Moßgraber and S. Vrochidis,
“Semantically Enriching and Open Source Sensor Observation Service
Implementation for Accessing Heterogeneous Environmental Data
Sources”, Transactions in GIS, vol. 18, no. 4, pp. 480-495, 2014.
[11] S. Jirka, C. Stasch and A. Bröring, “OGC® Best Practice for Sensor
Web Enablement Lightweight SOS Profile for Stationary In-Situ
Sensors”, OGC: Open Geospatial Consortium Inc., 2014.
[12] I. Stojmenovic. Machine-to-machine communications with in-network
data aggregation, processing, and actuation for large-scale cyber-
physical systems. Internet of Things Journal, IEEE, 1(2):122-128
(March 2014).
[13] P. Soulier, D. Li, and J. R. Williams, A survey of language-based
approaches to cyber-physical and embedded system development.
Tsinghua Science and Technology, 20(2):130 - 141. (April 2015).
[14] R. Rajkumar,. A cyber--physical future. Proceedings of the IEEE,
100(Special Centennial Issue), 1309-1312.
doi:10.1109/JPROC.2012.218991.
[15] PHP, available at http://www.php.net, last visited October 20th 2015
[16] MongoDB, available at http://www.mongodb.org, last visited October
20th 2015.
[17] NGINX, available at http://nginx.org, last visited October 20th 2015
[18] jMeter, available at http://jmeter.apache.org, last visited October 20th
2015.

Juan V. Pradilla received the M.Sc. degree in

Communications Technologies, Systems and Networks from
the Universitat Politècnica de Valencia in 2013 and the M.Sc.
degree in Computing and Telecomunications from the ICESI
University in 2012. Currently, he is a Ph.D Student in the
Escuela Técnica Superior de Ingenieros de Telecomunicación
at the Universitat Politècnica de Valencia, Spain. His research
activities and interests cover a wide range of subjects related
to cyber-physical systems, Internet of Things and wireless communications,
particularly: sensor networks, cloud computing, quantum communications,
network security and next generation mobile networks.

Manuel Esteve Domingo received both his M.Sc. in

computer engineering and his Ph.D. in telecommunication
engineering (Dr.Ing.) from the Universitat Politecnica de
Valencia in 1989 and 1994, respectively. He is Full Professor
in the Escuela Técnica Superior de Ingenieros de
Telecomunicacion at the Universitat Politecnica de Valencia
(UPVLC), and he leads the Distributed Real-Time Systems
research group. Prof. Manuel Esteve has more than 20 years of experience in
the ICT research area in the area of Networking. Nowadays, he is managing