1501 07135 en Es

Este documento ha sido aceptado en el estándar IEEE Network Magazine y aparecerá en mayo / junio el año 2015 Emisión.
El contenido es definitivo, pero no ha sido leer la prueba. contenido final puede cambiar. Esta es una copia autor subido en
la página web personal. los derechos de autor respectivos están con IEEE
Wireless Sensor de virtualización de redes: la arquitectura de principios e Investigación

perspectivas ±
Imran Khan + ¥, Fatna Belqasmi #, Roch Glitho *, Noel + Crespi, Monique Morrow ++, Paul Polakos ++
+
Institut Mines-Télécom, SudParis Télécom, Evry, Francia
#
Universidad Zayed, Abu Dabi, Emiratos Árabes Unidos
*
Concordia University, Montreal, Canadá
++
CISCO Systems
¥ imran@ieee.org
Abstracto
redes de sensores inalámbricos (WSNs) se han convertido en omnipresente y se utilizan en muchas aplicaciones y servicios. Por lo general, los despliegues de
redes inalámbricas de sensores están orientados de tareas y dominio específico; impidiendo de ese modo volver a utilizar cuando se contemplan otras
aplicaciones y servicios. Esto conduce inevitablemente a la proliferación de las implementaciones de WSN redundantes. La virtualización es una tecnología que
puede ayudar en la lucha contra este problema, ya que permite el intercambio de recursos / infraestructuras de múltiples entidades independientes. En este
trabajo se revisan críticamente el estado de la técnica y proponer una nueva arquitectura para la virtualización WSN. La arquitectura propuesta tiene cuatro
capas (capa física, la capa de sensor virtual, la capa de acceso sensor virtual y la capa de revestimiento) y se basa en el protocolo de aplicación restringida
(COAP). Nos ilustran su potencial mediante su uso en un escenario en el que un solo WSN es compartida por múltiples aplicaciones; uno de los cuales es una
aplicación de monitoreo de incendios. Se presenta el prototipo proofof-concepto que hemos construido junto con las mediciones de rendimiento, y se discuten
las futuras líneas de investigación.
Palabras clave
Red de sensores inalámbricos (WSN), virtualización a nivel de nodo de red de virtualización, a nivel de virtualización, redes superpuestas
Introducción
En los últimos años, las redes de sensores inalámbricos (WSNs) han vuelto omnipresentes y están siendo utilizados en una amplia variedad de
dominios de aplicación, incluyendo la salud, la agricultura, la vigilancia y la seguridad. Estos WSNs se componen de nodos a pequeña escala que tienen
la capacidad de detectar, calcular y comunicar [1]. Mientras que los nodos sensores primeros estaban con capacidades limitadas con recursos
limitados, los recientes avances en la tecnología de hardware del sensor han hecho posible la producción de nodos sensores que tienen mayor
capacidad de procesamiento, memoria y una mayor autonomía.
La virtualización es una técnica clave para la realización de la Internet del futuro, y de hecho es muy pertinente para explorarlo en el contexto de
redes inalámbricas de sensores. La virtualización hace que sea posible presentar recursos informáticos físicos mediante la abstracción de ellos
en unidades lógicas, lo que permite su uso eficiente de múltiples usuarios independientes, incluyendo múltiples aplicaciones simultáneas [2].
Además, incluso permite el despliegue de aplicaciones que ni siquiera se prevé durante el despliegue inicial de una infraestructura.
Hasta la fecha, las realizaciones de redes inalámbricas de sensores han sido de dominio específico y orientado a la tarea. Las solicitudes se lían con
una WSN en el momento del despliegue, y es casi imposible utilizar el mismo WSN durante otras aplicaciones. Esto conduce a implementaciones
redundantes, y la infrautilización de estos recursos. Hay dos enfoques para permitir que varias aplicaciones accedan a los recursos desplegados
WSN. Una de ellas es para permitir que varias aplicaciones compartan los datos recogidos a partir de una WSN. En este enfoque, un nodo receptor /
pasarela recoge todos los datos de la WSN y lo comparte entre varios usuarios. Por ejemplo, en [3], WSNs se fusionan en el
± Este artículo es una versión extendida de un breve documento presentado en " 6 de IFIP inalámbrica conjunta y la Conferencia de redes
móviles (WMNC'13), Abril 23-25, 2013, Dubai, EAU, bajo el título de “Una Arquitectura Multi-Capa de Red Wireless Sensor de
virtualización".
la nube mediante el envío de los datos del sensor observados a través de un gestor de host que se encuentra fuera de la WSN. El anfitrión de gestión
simplemente recoge los datos del sensor, perfiles / agregados y luego permite que varias aplicaciones utilizan para sus propios fines.
El segundo enfoque es utilizar las capacidades de los nodos de sensores individuales para ejecutar varias tareas de la aplicación simultánea, y
permitir que las aplicaciones grupo estos nodos sensores juntos de acuerdo a sus requisitos. La diferencia clave entre los dos enfoques es que el
primer enfoque permite el intercambio de datos entre múltiples usuarios WSN, mientras que el segundo permite el intercambio de nodos WSN por
múltiples aplicaciones. Este artículo se centra en el segundo enfoque, ya que hace posible el diseño de las aplicaciones más innovadoras en los
WSNs desplegados, incluso las aplicaciones que no se previeron a priori. Esto mejorará en gran medida la eficiencia de las redes inalámbricas de
sensores desplegados y también animará a nuevos modelos de negocio.
En este trabajo se introduce el concepto de virtualización WSN, críticamente revisa el estado de la técnica en la virtualización WSN y propone una
nueva arquitectura de principios que se centra en redes inalámbricas de sensores fijos. Nos ilustran el potencial de la arquitectura instanciándola
para un escenario de vigilancia de incendios [4] en el que múltiples aplicaciones comparten la misma WSN. Hemos construido un prototipo para
demostrar su viabilidad y medir su rendimiento. También identificamos nuevas direcciones de investigación.
La siguiente sección presenta una visión crítica del estado de la técnica. La arquitectura propuesta se presenta en la tercera sección. La
cuarta sección se analizan las alternativas de implementación con el prototipo de prueba de concepto y las medidas de rendimiento. Las
líneas de investigación se discuten en la sección quinta. Llegamos a la conclusión en la última sección discutiendo las lecciones aprendidas.
2. Una visión crítica del estado-of-the-Art
Hay dos categorías de virtualización WSN: nivel de nodo y de red. La figura 1 muestra una vista de alto nivel de virtualización de WSN. WSN-nivel
de nodo de virtualización permite que múltiples aplicaciones se ejecuten sus tareas simultáneamente en un único nodo WSN [5] (Fig. 1-a). Esta
ejecución puede ser secuencial (por ejemplo round-robin) o puede ser simultáneo, con el cambio de contexto entre las tareas de aplicación.
Figura 1: WSN virtualización Categorías
En WSN virtualización a nivel de red, un subconjunto de nodos de sensores que pertenecen a una WSN desplegado formar una red de
sensor virtual (VSN) para ejecutar tareas de la aplicación dada en un momento dado [6], mientras que los otros nodos de sensores
permanecen disponibles para otras tareas de la aplicación. WSN a nivel de red de virtualización se puede lograr de dos maneras.
Diferentes VSNS se pueden crear sobre la misma infraestructura WSN subyacente (Fig. 1-b), o nodos sensores pueden formar una sola
VSN sobre múltiples WSNs en diferentes dominios administrativos (Fig. 1-c). Esta última situación es posible siempre que los nodos
sensores pueden apoyar la ejecución concurrente de tareas de la aplicación. Es el caso en estos días debido a que muchos sistemas
operativos populares de sensores (por ejemplo Contiki) que se ejecutan en dispositivos con recursos limitados,
2.1. Ejemplo y Requisitos motivador
En esta sección presentamos en primer lugar un ejemplo motivador y luego dibujar los requisitos de la misma.
2.1.1. Ejemplo motivador
Una implementación real de un WSN se presenta en [7], en la que una WSN se utiliza para controlar el impacto de la construcción de un túnel de
carretera bajo una antigua torre en Italia, ya que se temía que la torre podría perder su capacidad de permanecer por su propia cuenta y que se
produzca una ruptura durante la construcción. Ahora consideran que hay tres usuarios interesados en el destino de la torre. La primera es la empresa
constructora, ya que necesita asegurarse de que la torre no pierde su capacidad de valerse por sí misma, de lo contrario tendrá que pagar una fuerte
multa. El segundo usuario es la junta de conservación que supervisa rutinariamente todos los lugares históricos de la ciudad, y la tercera usuario es el
municipio local que tendrá que planificar las acciones correctivas / de rescate de emergencia en caso de que la torre se cae durante la construcción.
Es muy posible que la junta de conservación ya ha desplegado su propia WSN para controlar la salud de los sitios antiguos, incluyendo esta
torre. En este caso, la empresa de construcción y la municipalidad local pueden reutilizar los nodos sensores existentes durante el período de
construcción. En ausencia de virtualización WSN, sólo hay dos soluciones posibles. Una de ellas es que confiar en la información
proporcionada por la aplicación cartón de conservación. Sin embargo, esta información puede no estar en el nivel de granularidad requerida.
Peor aún, parte de la información que se necesita simplemente no podría estar disponible porque no se consideraron los requisitos de la
empresa de construcción y de la municipalidad local cuando la aplicación cartón de conservación fue diseñado e implementado. La segunda
solución es que cada usuario despliega nodos WSN redundantes.
2.1.2. requisitos
los primero requisito es el soporte de virtualización a nivel de nodo para permitir la ejecución de múltiples tareas de la aplicación en el mismo nodo
sensor. los segundo requisito es la capacidad de los nodos de sensores para formar dinámicamente grupos para ejecutar tareas aislado y
transparente de aplicación concurrente (es decir, soporte para WSN virtualización a nivel de red). los tercero requisito es el apoyo de solicitud de
prioridad. En algunos escenarios de aplicaciones críticas tales como la vigilancia de incendios, es importante que otras tareas tienen menor
prioridad que la que informa del suceso fuego.
los cuarto requisito es que la solución propuesta debe ser aplicable a una amplia gama de aplicaciones y no debe ser adaptado para un escenario o
dominio particular, que es el caso habitual con la mayoría de las soluciones. los quinto requisito es que la solución propuesta debe ser independiente
de la plataforma y no debe depender de los sistemas operativos específicos o interfaces personalizadas / adaptados. los sexto y requisito final es que
la solución debe abordar la heterogeneidad, es decir, hacer frente a los nodos de sensores que tienen diferentes capacidades (por ejemplo, potencia
de procesamiento, memoria).
2.2. El Estado-of-the-Art y sus deficiencias
Dividimos el trabajo relacionado en tres clases: a nivel de nodo, a nivel de red y soluciones de virtualización híbridos. Las soluciones híbridas
combinan tanto la virtualización nódulo-y a nivel de red.
2.2.1. La virtualización de nivel de nodo
Con el fin de lograr la virtualización a nivel de nodo, los mecanismos deben estar en su lugar para permitir que los nodos WSN desplegados para ejecutar
nuevas tareas de la aplicación, así como los ya existentes de actualización. Una solución es volver a programar los nodos WSN individualmente, pero que no
es factible ni eficaz. reprogramación inalámbrica, por otro lado, permite gran número de nodos WSN a ser actualizado con nuevas tareas de la aplicación con
el mínimo esfuerzo. Ahora es el
mecanismo principal utilizado para virtualización a nivel de nodo. Dos ejemplos de virtualización a nivel de nodo sobre la base de reprogramación inalámbrica se
discuten a continuación. Su principal inconveniente es la dependencia de la plataforma.
Maté [5] es un trabajo pionero que proporciona ejecución secuencial de tareas de la aplicación en, los nodos de sensores de generación temprana de recursos
limitados. Se trata de una pequeña máquina virtual que consiste en un intérprete de código binario basado en la pila y trabaja en la parte superior de TinyOS.
tareas de aplicación se dividen en cápsula (s) código de hasta 24 instrucciones y se ejecutan de una en una. Un esquema de distribución de código viral se
utiliza para propagar código y para reprogramar los nodos sensores. Como no es apretado acoplamiento entre el código de la aplicación y TinyOS, la
instalación de un nuevo código requiere la sustitución de todo el sistema operativo. No hay soporte para la prioridad de la aplicación, y sólo se admite un
conjunto limitado de aplicaciones. Además, el enfoque no es independiente de la plataforma, ya que sólo funciona en TinyOS, pero lo hace frente a la
heterogeneidad.
MANTIS [8] es un sistema operativo embebido a base de hilo. Los programas se crean como hilos a nivel de usuario con el espacio de memoria dedicada y
datos estáticos unidos a ellos en tiempo de compilación. hilos de larga duración se puede interrumpir por hilos de ejecución breve. El trabajo sobre la
reprogramación inalámbrica está en curso, según los autores. Las técnicas que se utilizan son la re-destellan sin hilos del sistema operativo y la
re-programación de hilos individuales. A diferencia del compañero, Mantis proporciona prioridad de la aplicación. Sin embargo, no es independiente de la
plataforma.
2.2.2. La virtualización a nivel de red
En [6], los nodos sensores forman grupos para soportar aplicaciones que monitorizan fenómenos dinámicos. Los nodos de sensores dentro de cada
grupo ejecuta aplicación (es) tareas, lo que significa un nodo sensor puede formar parte de varios clústeres. Con cada grupo dedicado a una aplicación,
un WSN puede ser utilizado por múltiples aplicaciones de forma simultánea, por lo tanto, la realización de virtualización a nivel de red. Dos aplicaciones
ilustrativas se presentan como la motivación. Por desgracia, el trabajo es pobre en cuanto a los detalles técnicos (por ejemplo, cómo los nodos
individuales ejecutar tareas de la aplicación). Por otra parte, no hay discusión de cómo se abordan prioridad de la aplicación, la heterogeneidad y la
independencia de la plataforma. Este trabajo ha sido extendida en la referencia [9] con el fin de facilitar la creación, operación y mantenimiento de grupos
dinámicos para lograr la virtualización a nivel de red. Una vez que se detecta un evento, nodos sensores se agrupan como un árbol clúster dinámico
mediante el intercambio de mensajes de formación de VSN. Sin embargo, en términos de nuestra requisitos ninguno de los inconvenientes de la
referencia [6] se abordan.
Los autores en [10] presentan el problema de la asignación de misión en redes inalámbricas de sensores. El trabajo puede estar
relacionado con la virtualización a nivel de red, ya que la WSN es capaz de soportar múltiples misiones al mismo tiempo. Cada misión
utiliza un subconjunto específico de nodos sensores que no se comparten con otras misiones. Un problema de asignación misión se
modela como un gráfico bipartito ponderado para asignar de forma óptima los nodos sensores para misiones. El logro de una misión
produce un beneficio, por lo que el objetivo es maximizar los beneficios mediante la consecución eficiente tanto las misiones como sea
posible. Se presentan dos soluciones centralizados y distribuidos, utilizando pruebas y algoritmos, incluyendo una solución consciente de
la energía. Esta solución no tiene en cuenta cualquier dominio de aplicación específica. La heterogeneidad se dirige junto con
independencia de la plataforma. Sin embargo,
2.2.3. Soluciones híbridas
Los autores en [11] discutir la plataforma SenShare, que apoya tanto WSN-nodo y virtualización a nivel de red. Consideran aplicaciones TinyOS con
una capa de abstracción de hardware incorporado (HAL). Los recursos de nodo sensor subyacentes son luego accedidos usando una capa de tiempo
de ejecución en la parte superior de TinyOS. Desde TinyOS soporta múltiples tareas al mismo tiempo, se consigue de este modo virtualización a nivel
de nodo. Para la virtualización networklevel, una red superpuesta usando el protocolo de árbol de la colección (CTP) se crea para los nodos de
sensores grupo ejecutor de la misma aplicación. Los nodos de sensores dispersos físicamente de ejecución de la misma aplicación se pueden agrupar
en una sola red de superposición. SenShare es la primera solución integral de virtualización de orientación WSN. Es compatible con
nódulo-y-virtualización a nivel de red, prioridad de la aplicación y la heterogeneidad,
y es independiente de cualquier dominio de aplicación. Sin embargo, no es independiente de la plataforma, ya que sólo las aplicaciones TinyOS son
compatibles.
Melete [12] es una extensión de yerba mate y soporta tanto la virtualización nódulo-y a nivel de red. ejecución concurrente de tareas de la aplicación
se consigue haciendo las siguientes mejoras para aparearse: almacenamiento dedicado y el espacio de ejecución de aplicaciones para permitir la
simultaneidad, y un protocolo de difusión de código para permitir la (re) programación selectiva y reactiva de nodos sensores. Para la virtualización
de nivel de red que utiliza una técnica de agrupación dinámica de nodos sensores. Un nodo sensor puede ser parte de más de un grupo lógico al
mismo tiempo. La topología de red soportado es un gráfico conectado. Melete no soporta prioridad de la aplicación, y no es independiente de la
plataforma. Sólo es compatible con un conjunto limitado de aplicaciones, pero lo hace frente a la heterogeneidad.
3. arquitectura propuesta
En esta sección, presentamos en primer lugar los principios de la arquitectura. a continuación presentamos nuestra arquitectura multi-capa a base de
superposiciones, seguido por una discusión de las interfaces y el procedimiento de creación de superposición.
3.1 Principios de arquitectura
El primer principio de arquitectura es que las nuevas aplicaciones / servicios se implementan como nuevas plantillas en la parte superior de la WSN física.
Superposiciones tienen varias ventajas: se distribuyen, control central falta y permiten el intercambio de recursos [13]. El segundo principio es que cualquier
nodo sensor físico dado puede ejecutar (localmente) una tarea para una aplicación dada desplegado en la superposición. Cualquier nodo sensor determinado
puede ejecutar varias tareas de aplicación de este tipo en un momento dado.
El tercer principio es que no todos los nodos WSN realizar las operaciones relacionadas con la superposición de, ya que pueden no tener
suficientes capacidades para apoyar el middleware de superposición. Cuando ese es el caso, se delegan las operaciones a sensores más
potentes e incluso a otros nodos. Este principio, en efecto, hace que sea posible abordar el requisito de la heterogeneidad y permite la
virtualización a nivel de red para los recursos limitados nodos sensores generación actual.
El cuarto principio es que dentro de la arquitectura hay datos separados y rutas de control. Los datos de los sensores (por ejemplo, valores de temperatura) se
transmite desde los nodos sensores para la aplicación de superposición usando la ruta de datos. Los datos de control (por ejemplo, el cambio de prioridad de la
aplicación y la gestión de superposición) se envían por la vía de control. Esta separación de caminos hace que sea fácil de trabajar en nuevos protocolos para
cada ruta de forma independiente.
El último principio es el uso de los estándares emergentes, dirigidos a dispositivos con recursos limitados, para afrontar el reto independencia de la
plataforma. Estas normas incluyen protocolos tales como el protocolo de aplicaciones con restricciones (COAP) [14], de DNS-descubrimiento de
servicios (DNS-SD) [15] y estándares como sensor de Modelo de Lenguaje (SensorML) [16], observaciones y mediciones (O & M) [ 17] y el sensor
de lenguaje de marcado (SenML) [18]. Este principio, por supuesto, implica la necesidad de convertidores / creadores de mapas para dispositivos
que no soportan los estándares.
Coap es un protocolo de transferencia de capa de aplicación, como HTTP, diseñado para funcionar con dispositivos de recursos limitados. Tiene menos
requisitos de arriba, de memoria y procesamiento de http. DNS-SD ofrece el descubrimiento de servicios en redes con recursos limitados y permite la
perfecta integración de este tipo de arquitecturas de las redes IP existentes. SensorML proporciona modelos estándar y codificación basada en XML
para describir mediciones y procesos de sensores. Es capaz de proporcionar interoperabilidad, el descubrimiento automático, la utilización y el
intercambio de sensor. O & M es un estándar que define esquemas de codificación para las observaciones realizadas por los sensores. SenML
proporciona un modelo de datos para las mediciones del sensor y los metadatos simple sobre sensores en JSON, XML y formatos EXI.
3.2 Arquitectura general
La Figura 2 muestra nuestra arquitectura de múltiples capas propuesto, y la Tabla I proporciona la lista de los componentes utilizados. Hay cuatro capas (,
sensor físico virtual, de acceso sensor virtual y de superposición), dos caminos (de datos y de control), cinco interfaces (datos ( Di), D patentada yo ( PD yo), de
control ( Ci), propietaria C yo ( ordenador personal yo) y la puerta de enlace ( Soldado americano)) y un servidor de registro.
TABLA I. do OMPONENTES DE LA UN RCHITECTURE
Abreviatura Componente observaciones
- Sensor de tipo A Legacy / sensor de recursos limitados
- Tipo B Sensor Nueva generación nodo sensor inteligente IP
GTO nodo Gates-a-Overlay Nodo de Pasarela / fregadero susceptible de aplicación unirse

Nodo superposiciones en nombre de los sensores de tipo A
- Agente de sensor entidad funcional que proporciona una interfaz unificada para
proporcionar independencia de la plataforma
- Registro repositorio de sensor

Servidor
di Interfaz de datos Interfaz para enviar los datos del sensor a la aplicación de superposición
PDi Los datos patentada interfaz propietaria para enviar datos de los sensores virtuales a
Interfaz agente de sensor
ci Interfaz de control Interfaz para enviar / recibir datos de control de usuario final
solicitud
PC _ Propiedad interfaz propietaria para enviar / recibir datos de control de
Interfaz de control sensor virtual para agente de sensor
Gates-a-Overlay
Soldado americano Interfaz para enviar / recibir los datos de control entre el tipo de
Interfaz A sensores y de tipo B sensores / nodos GTO
En la capa física tenemos WSNs independientes que constan de dos tipos de nodos de sensores, es decir, recursos limitados (tipo A) y sensores capaces
(tipo B). Cada WSN también se ha especializado nodos, llamados nodos GTO. Su función es ayudar a los sensores de tipo A se unen a las
superposiciones de aplicaciones y proporcionan heterogeneidad. Gateways, se hunden los nodos o de un tipo de sensores B pueden actuar como nodos
GTO cuando sea necesario. Por ejemplo, en el ejemplo de motivación en la sección 2.1.1, si los sensores existentes son de tipo A, entonces o bien los
sensores de nodo de pasarela o de tipo B existentes, desplegados por la empresa de construcción, pueden ayudar a aquellos sensores que se convierten
en parte de la empresa constructora cubrir. Esto podría aumentar la complejidad de los nodos de sensores de tipo B pero permite flexibilidad.
La capa de sensor virtual consiste en la representación lógica de cada sensor de la ejecución de múltiples tareas de la aplicación al mismo tiempo.
Cada representación lógica se llama un sensor virtual en nuestra arquitectura, que es una abstracción de una tarea de aplicación dirigida por un sensor.
Aplicación de
Aplicación de
usuario final
usuario final
superposición de aplicaciones
superposición de aplicaciones
ci
di ci
di
Hice capa superpuesta
di ci
di
di di
di
superposiciones)
Acceso sensor virtual

Agente de sensor Agente de sensor Agente de sensor
ci
Capa
Internet
di
(Entidades funcionales que proporcionan
interfaces unificados para apoyar nodos

Registro sensores heterogéneos)
Servidor PDi
PDi
PDi
PDi PDi PC _
PDi PDi
PDi sensor virtual
PDi
lógica de cada
Sensor Sensor Sensor Sensor
sensor múltiple ejecución
Sensor virtual 2 virtual 1 virtual 2 virtual 3
tareas) (independiente
virtual 1
Capa física Capa de
Sensor de
tipo A
segundo (sensores heterogéneos,
UN
UN
GTO nodo & GTO Nodes) (representación
Sensor de tipo A
AB Soldado americano UN
segundo Soldado americano UN
Tipo B
Soldado americano Sensor UN
club británico
Automóvil
segundo UN segundo GTO nodo
licenciado en Letras
segundo
UN
segundo segundo UN licenciado
Automóvil club británico UN segundo UN segundo en Letras
y desayuno
cama UN segundo UN
UN UN
club británico
Automóvil UN segundo UN segundo segundo
en Letras
licenciado club británico
Automóvil UN segundo
Una red de sensores inalámbricos Wireless Sensor de la red B Wireless Sensor Red C
Figura 2: Multi-capa WSN virtualización Arquitectura
La capa de acceso sensor virtual consiste en agentes de sensores que aseguran la independencia de plataforma. Esto se consigue proporcionando
interfaces estandarizadas ( di y ci) para interactuar con las aplicaciones de usuario final, y se asignan a las interfaces específicas de la plataforma
(patentados) ( PDi y ICP) para los nodos sensores físicos subyacentes. agentes de sensor pueden ser implementadas ya sea en sensores capaces (tipo
B) o en los nodos GTO.
La capa de recubrimiento se compone de superposiciones independientes específicos de la aplicación (se muestran dos en la figura 2, pero podría haber
muchos más). Cada capa de aplicación es creada por la aplicación del usuario final y consta de sensores virtuales que se ejecutan las tareas de aplicación de
superposición. Un protocolo de superposición se utiliza para el intercambio de mensajes dentro de una superposición. Un servidor de registro, que contiene los
detalles de los nodos sensores desplegados, es utilizado por aplicaciones de usuario final para encontrar nodos sensores.
3.3 Interfaces
El camino de datos utiliza la interfaz de datos ( di) soportado por todos los agentes de sensores para enviar los datos recibidos de los sensores virtuales que
ejecutan la tarea de aplicación del usuario final a las superposiciones de aplicación. La vía de control utiliza el interfaz de control ( ci) soportado por todos
los agentes de sensores para enviar / recibir datos de control. Ejemplos de datos de control incluyen el envío de solicitudes para cambiar prioridad de la
aplicación y la frecuencia de muestreo. Las interfaces, PDi y PC _ son interfaces propietarios y son utilizados por el agente de sensor para comunicarse con
WSNs. Figura 3 muestra ejemplos de alto nivel de cuando los datos de sensor se envía a través PDi y di las interfaces (3a) (cuando se detecta fuego) y
cuando una solicitud de cambio de solicitud de prioridad tarea se envía a través de ci y PC _
las interfaces (3b). En este caso, es la prioridad de la tarea que se ejecuta en el sensor 02. Las Puertas-a-capa de interfaz ( Soldado americano) es
proporcionada por todos los sensores, así como los nodos GTO. Toda comunicación de B o GTO nodos de tipo con sensores de tipo A se realiza mediante
esta interfaz.
3.4 Procedimiento de creación de superposición
En esta sección se describe el procedimiento de creación de superposición. La creación de la superposición es un procedimiento de tres etapas, iniciado por la
aplicación de usuario final. El primer paso es el descubrimiento de recursos dinámica y superposición pre-
configuración, lo que permite el descubrimiento de los sensores y nodos GTO sobre la marcha de acuerdo con los requisitos de la aplicación de
usuario final. El segundo paso es la activación de la superposición. El sensor seleccionado (tipo B) y los nodos GTO reciben una superposición
unirse a petición (o anuncio) sobre el ci interfaz. Después de unirse a la superposición, los sensores de tipo B y los nodos GTO (para sensores tipo
A) pueden recibir la tarea de aplicación, con su nivel de prioridad deseado. El paso final es la ejecución de la aplicación de usuario final, que
comienza cuando cada sensor comienza a ejecutar la tarea de aplicación del usuario final. Dependiendo de los requisitos de la aplicación, los
sensores pueden intercambiar mensajes entre sí en la superposición antes de enviar los datos a la aplicación de usuario final sobre el di interfaz.
Sensor virtual de GTO Nodo [Agente Aplicación del
Sensor01 [Tipo A] del sensor] Usuario Final
incendio detectado
PDi Interfaz
di Interfaz
RadiogramConnection. enviar
(sensor01, 1376020076, Content-Type = application / json
20.1, Cel)
{"mi":[
{ "V": 20.1}], "bn":
"Sensor01", "bt":
1376020076, "bu":
"Cel"}
201 Creado
a) Envío de datos de los sensores durante PDi y di las interfaces
Sensor virtual de
Aplicación del GTO Nodo [Agente
Sensor02 [Tipo
Usuario Final del sensor]
B]
ci Interfaz
Content-Type = application / json
{"mi":[
{ "N": "task02"}, { "SV": "aumentar la prioridad
de la tarea"}], "bn": "Sensor02"}
PC _ Interfaz
RadiogramConnection. enviar
(task02, aumento)
getInstance (tasks02Thread);
setPriority (DEFAULT + 1)
retorno (verdadera)
200 OK
b) Cambio de prioridad de la tarea de aplicación sobre PC _ y ci las interfaces
F igura 3: Ejemplo de comunicación a través de datos e interfaces de control

4 Alternativas aplicación, Prueba de concepto Prototipos y Medidas
4.1 Alternativas de implementación
Nuestra arquitectura propuesta consiste en el plano de datos, el plano de control y varias interfaces que les pertenece. los di interfaz, perteneciente
al plano de datos, lleva a los datos reales. los ci y Soldado americano interfaces de llevar mensajes de control y son parte del plano de control.
Hay varias opciones para implementar una interfaz de plano de datos. Tanto HTTP y coap se puede utilizar como protocolos de capa de aplicación, pero
que elegimos coap ya que permitirá a los nodos de tipo A para apoyar el mismo protocolo para di y Soldado americano interfaces. Utilizamos especificaciones
SenML para codificar los datos de los sensores en el formato estándar de JSON. La combinación de SensorML y O & M es otra opción, pero selecciona
SenML ya que es menos compleja.
Para el plano de control, un protocolo candidato es JXTA [19], una especificación de protocolo peer-to-peer de código abierto que permite la
creación de redes superpuestas independientes, robustos y eficaces. ScatterPastry [20] es otra opción. Para nuestro trabajo se optó por utilizar
JXTA desde sus implementaciones están fácilmente disponibles.
4.2 Prototipo
Hemos implementado un simple escenario de incendio forestal se discute en [4] como un prototipo. En este escenario, la administración de la ciudad está
interesado en la detección temprana de la erupción de incendio forestal y en su evolución, utilizando una WSN y un fuego de contorno Algoritmo (FCA).
Algunas casas de la zona ya tienen sus propios sensores para detectar incendios. Para acelerar el despliegue de su aplicación y de evitar la redundancia, la
administración de la ciudad ha optado por desplegar sensores en las zonas bajo su jurisdicción (es decir, calles y parques) e incorporar los nodos sensores ya
desplegados en casas particulares. Los propietarios de viviendas reciben incentivos como la devolución de impuestos para permitir el uso de sus sensores de
administración de la ciudad. Las pasarelas de presentación actúa como nodos GTO. Todos los sensores de propiedad privada ejecutar dos tareas de
aplicación - una para el dueño de la casa y otro para la administración de la ciudad. La figura 4a muestra el mapeo del escenario en nuestra arquitectura.
Hacemos las siguientes suposiciones. En primer lugar se supone que la administración de la ciudad ya ha descubierto y enviado
su tarea de aplicación a cada uno de estos sensores. La segunda suposición es que todos los sensores en el prototipo son
sensores de un tipo que necesitan un nodo GTO para tareas relacionadas con superposición. En tercer lugar, ya que no era
posible generar un incendio en un entorno de laboratorio, la tarea de aplicación administración de la ciudad mide periódicamente el
valor de la temperatura en un sensor y se envía al nodo GTO. Utilizamos seis sensores SunSpots Java, cada ejecución de tres
tareas de la aplicación al mismo tiempo. Las tareas de la aplicación y la FCA se codificaron en la plataforma Java 2 Micro Edition
(J2ME). J2ME es una plataforma Java robusta y flexible que permite el desarrollo de aplicaciones para dispositivos móviles y
embebidos.
Un servicio web REST es utilizado por el nodo de administración de la ciudad para recibir alertas de incendios. Cada nodo GTO, al recibir la
notificación fuego de su sensor, envía un mensaje HTTP POST a un URI
( http: // ... / FireContourService / eventos / fuego /) para crear un evento de fuego. El tipo de contenido del mensaje HTTP POST se establece en application /
senml + JSON y los datos de los eventos recibidos desde Java SunSpot se asigna a formato JSON acuerdo con las especificaciones SenML. Una vez creado
el evento, el nodo de administración de la ciudad envía un mensaje de notificación fuego a los pares de la superposición.
La superposición es creado por el nodo de administración de la ciudad, actuando como pares cita, por la publicidad de su grupo de referencia ( servicio de
contorno de fuego) el uso de anuncios de tubería JXTA antes del evento fuego. Los nodos GTO se unen al servicio de contorno de fuego como pares borde
respondiendo a la tubería anuncio recibido. El nodo de la ciudad administrador envía el mensaje de notificación de fuego con la toma de multidifusión JXTA, que
proporciona el intercambio de mensajes eficiente entre
miembros del mismo grupo de pares. Después de la ejecución del algoritmo de contorno de fuego, el mensaje de respuesta se envía directamente al nodo de
administración de la ciudad en vez de ser de multidifusión.
El prototipo utiliza un algoritmo simple contorno de fuego probabilística, teniendo en cuenta que una casa distante enviará notificaciones de fuego con menos
frecuencia que una casa cercana porque el fuego está lejos de ella. Las administraciones de la ciudad aplicación se crea utilizando JavaFX, y recibe los
mensajes de alerta de incendios, así como las respuestas de los compañeros y muestra la salida en el mapa de la zona. JavaFX es un conjunto de bibliotecas
de Java que permiten a los desarrolladores diseñar rápidamente, crear y desplegar aplicaciones de cliente que operan a través de diversas plataformas.
La configuración prototipo se ilustra en la Fig. 4b. La aplicación de administración de la ciudad y su servicio web contorno de fuego corrieron en un ordenador
portátil con una CPU Intel Core i5 velocidad de reloj de 2,67 GHz y una memoria RAM de 4 GB con 32 bits de Windows 7 Enterprise. Los otros dos ordenadores
portátiles actuaron como nodos GTO para SunSpots Java y corrieron tres pares JXTA cada uno. Sus configuraciones eran una CPU Intel Core i7 velocidad de
reloj de 2,70 GHz con 8 GB de RAM, 64 bits de Windows 7 Professional y una CPU Intel Core i5 velocidad de reloj de 2,60 GHz y una memoria RAM de 4 GB
con Windows 7 Enterprise. Los tres ordenadores portátiles utilizan JVM versión 1.7.0_21 y estaban conectados a una LAN privada.
ciudad de administración
Nodo
Ciudad de Administrador
Aplicación de Visualización del mapa
administración de la ciudad
REST Ciudad de administración
Servicio web
Ciudad de
administración de superposición
mensaje HTTP POST Peer
En formato JSON Ciudad de
di
JXTA
administración
ci Peer B
JXTA JXTA
ci
di Peer Un
ci
Ciudad de administración de
di JXTA
superposición (JXTA Peer Group)
Peer C JXTA
Agente de Agente de
Peer E
sensor sensor
JXTA
PDi Peer D
JXTA
Peer F
PDi
Tarea para ciudad de administración
la casa Tarea 1
Ciudad de ciudad de administración
Tarea para ciudad de administración Agente de sensor Agente de sensor
administración Control de tareas Tarea 1
la casa Tarea 1
Soldado americano
GTO
Soldado americano
nodo
GTO
nodo
GTO nodo GTO nodo
UN segundo
USB USB
Una casa Casa B
sensor B Un sensor sensor E

sensor F
sensor C
sensor D
a) La instanciación de la arquitectura b) Configuración Prototype
Figura 4: La instanciación de la arquitectura y la configuración Prototype

4.3 Las mediciones de desempeño
Métricas de rendimiento - El rendimiento del prototipo se evaluó en términos de los siguientes retrasos:
Retraso HTTP POST ( HPD), Retraso Creación de superposición ( OCD) y Notificación de fuego Delay ( FND).
HPD es la diferencia de tiempo entre el momento en el nodo GTO envía una solicitud HTTP POST y cuando recibe el código de éxito correspondiente (201
creado). HPD se calcula para cada sensor. El TOC es el tiempo que se necesita para configurar la superposición de administración de la ciudad de un estado
inexistente a un estado preparado, cuando se anuncia su servicio de contorno de fuego y está listo para aceptar unirse a las solicitudes. Medimos este
retraso en el código Java para asegurar que el TOC no incluye la JVM retardo de puesta en marcha. FND se mide como el tiempo necesario para que el nodo
de administración de la ciudad a los mensajes de notificación de incendios de multidifusión a los compañeros JXTA y recibir sus respuestas después de
ejecutar el algoritmo de contorno fuego. Para cada experimento se reinició la JVM y despejó el anterior caché de configuración JXTA. Todos los retrasos se
miden en milisegundos y se calculan en el lado del remitente.
a) retardo del mensaje HTTP POST b) retraso creación Overlay
c) el retraso mensaje de notificación de incendios
Figura 5: Resultados
resultados de rendimiento - Las mediciones de HPD se muestran en la figura 5 (a) (para mayor claridad, sólo se muestran 15 mediciones).. La línea
horizontal azul oscuro muestra el retardo promedio para el 50 mediciones, 18.96ms. Se observa que la demora para el primer mensaje POST es mucho
mayor que para los mensajes posteriores. Este largo retraso se debe al enlace de tres vías de conexión TCP que tiene lugar durante el primer mensaje
POST, mientras que para las solicitudes posteriores de una conexión HTTP persistente (también conocido como HTTP keep-alive) reduce
considerablemente retraso. La Figura 5 (b) muestra el TOC de una ciudad administrador JXTA por pares con un valor medio de 1983ms
de 50 iteraciones indicados por la línea azul horizontal. El retardo incluye el núcleo JXTA puesta en marcha, la creación de un servicio de
contorno de fuego, relacionado tubería anuncio, una toma de multidifusión JXTA y el hilo de
aceptar unirse a las peticiones de otros compañeros JXTA. Para cada iteración una nueva caché JXTA se generó en lugar de utilizar el antiguo. La
Figura 5 (c) muestra la FND promedio de cinco sensores que ejecutan un algoritmo de contorno fuego en respuesta al mensaje de notificación enviado
por una ciudad administrador JXTA pares. En este caso, el sensor E informó al fuego. El FND promedio de cinco sensores es 19.58ms.
Con el fin de determinar la sobrecarga de virtualización WSN, consideramos que el escenario en el que los sensores no son compatibles con la
virtualización a nivel de nodo y sólo se ejecutan tareas de administración de la ciudad. Tampoco hay virtualización a nivel de red y sin red superpuesta para
el intercambio de mensajes. En este caso, el algoritmo contra el fuego será ejecutado por los nodos GTO después de recibir un mensaje HTTP POST
desde el nodo de administración de la ciudad. Para una comparación simple, si tenemos en cuenta que la FND y sin virtualización WSN es similar a HPD,
es decir, 18.96ms, y FND con la virtualización es WSN 19.58ms, a continuación, con la virtualización WSN tenemos aproximadamente 3,27%
gastos generales. Esta sobrecarga se debe al procesamiento de mensajes JXTA basados en XML. Nuestra aplicación demuestra que la
virtualización WSN es de hecho factible y no incurrir en muchos gastos. virtualización a nivel de nodo se logra con las manchas solares Java con
muy poco esfuerzo. virtualización a nivel de red se consigue utilizando JXTA, y una vez JXTA está operativo, los retrasos son mínimos. TOC es
inevitable, pero en el largo plazo, usando JXTA es beneficioso, ya que proporciona una solución sólida, altamente escalable y eficiente.
En general, los resultados muestran los retrasos típicos experimentados en un entorno LAN privada. La misma tubería JXTA anuncio del servicio de
contorno de fuego se utiliza para enviar y recibir los mensajes de notificación de fuego más de socket de multidifusión JXTA, lo que mejora en gran
medida el rendimiento general.
5 Direcciones de investigación
virtualización WSN es un área de investigación muy rica y nuestra arquitectura propuesta preliminar ha planteado varias cuestiones interesantes. Esta
sección proporciona una muestra no exhaustiva. Una primera cuestión es una publicación y descubrimiento marco dinámico para nodos sensores y GTO.
En este trabajo, se asumió un proceso de publicación estática donde los propietarios de los sensores y GTO publican sus nodos a un repositorio central.
Para automatizar el proceso de la virtualización de WSN, se requeriría una publicación y descubrimiento mecanismo sobre la marcha. Un marco basado en
coap podría ser utilizado como punto de partida. Para una solución centralizada, un mecanismo de Directorio de Recursos coap (RD) se puede utilizar,
mientras que un mecanismo de descubrimiento de recursos coap sería más apropiado para una solución distribuida. Del mismo modo, un mecanismo de
DNS-SD se puede utilizar en combinación con coap proporcionar nuevos, soluciones de gran alcance.
La elección de los formatos de datos para los diferentes interfaces es otro tema. La corriente de OGC - O & M y SensorML especificaciones utilizan el
formato XML, que es ineficaz en entornos con recursos limitados. SenML soluciona este problema mediante el uso de formatos JSON y EXI, y funciona
tanto con HTTP y COAP, pero también tiene algunos problemas abiertos. Por ejemplo, se puede utilizar para especificar los metadatos simple sobre
mediciones, pero no existe un mecanismo para proporcionar tales datos para la descripción de los sensores, sus capacidades y sus recursos (memoria,
espacio, y la batería de la vida) en un momento en particular. La posibilidad de un ligero mecanismo para informar sobre el estado de tiempo de
ejecución unos sensores es muy atractiva. Del mismo modo, un formato semánticamente-enriquecido sería de uso particular para la creación de
sistemas basados en sensores inteligentes en el contexto de la IO, que actualmente no es posible con SenML.
Una cuestión importante es la asignación de tareas óptima de sensores. El problema es esencialmente el mapeo de los requisitos de las
aplicaciones de usuario final a los recursos disponibles, lo cual es muy difícil en un entorno virtualizado. La referencia [10] propone una
solución, pero se supone que cada sensor se ejecuta una sola tarea, que no es el caso en un entorno virtualizado. Sin embargo, podría ser
utilizado como punto de partida para futuras investigaciones. WSN-middleware orientado superposición otro es tema a investigar. Necesitamos
una solución eficiente que evita superposiciones de interactuar de una manera perjudicial cuando compiten por los recursos subyacente. JXTA
y protocolos similares funcionan bien, pero no en entornos con recursos limitados. Existen algunos intentos tempranos como [20], pero deben
ser combinados con el concepto de virtualización WSN.
Un marco de señalización para soportar Calidad de Servicio (QoS) y gestión de sesiones también se necesita. Temas como el manejo de solicitudes de
aplicación para el establecimiento de prioridades de tareas / cambio serán abordados por un marco de calidad de servicio general de este tipo. Hay varios
marcos de señalización, tales como SIP / RSVP, pero pueden no ser adecuados para sensores. Una vez más, un protocolo de señalización basado en coap es
una solución potencial. La virtualización como se aplica a redes inalámbricas de sensores móviles es también una cuestión clave, ya que WSNs móviles se están
volviendo más y más popular. redes vehiculares ad hoc, redes sociales y detección basado en la multitud pueden proporcionar escenarios de aplicación
concretos para motivar a la virtualización de redes inalámbricas de sensores móviles.
6 Lecciones aprendidas
En este trabajo se ha propuesto una nueva arquitectura preliminar de múltiples capas para la virtualización WSN y hemos identificado varias líneas de
investigación.
Hemos aprendido varias lecciones. La primera es que WSN-nivel de nodo de virtualización está todavía en su infancia y muy pocos kits WSN nodo de
soporte de virtualización de nivel están fácilmente disponibles. Esto se debe sin duda a los retos de diseño de hipervisores en entornos con recursos
limitados. Una segunda lección es que la mayoría de las especificaciones estándar WSN existentes pertinentes a nuestro trabajo están todavía en
estado embrionario. SenML, por ejemplo, es muy prometedor. Sin embargo, en su forma actual, no es adecuado para funciones de control. Por otro
lado, SensorML es compleja y viene con funcionalidades adicionales que no son adecuados para un uso general y una solución eficiente. Una tercera
lección es que la mayoría de superposición middleware existentes son inadecuados para WSN porque normalmente no están diseñados para
dispositivos con recursos limitados. Utilizamos JXSE, que es una de las mejores opciones disponibles. Sin embargo, su actual implementación de
código abierto es bastante viejo y el futuro de la iniciativa es incierto.
Reconocimiento
Este trabajo es apoyado en parte por los sistemas CISCO través de subvención CG-576719, y por el de Ciencias Naturales e Ingeniería de
Investigación de Canadá (NSERC) a través de la Cátedra de Investigación en Ingeniería de Servicios de Usuario Final para Redes de
Comunicaciones.
referencias
[1] - Akyildiz, Ian F., et al. "Las redes de sensores inalámbricas: una encuesta," Red de computadoras, 38.4 (2002): pp 393-422..
[2] - S. Loveland et.al, "La mejora de la virtualización para optimizar las configuraciones de sistemas de alta disponibilidad," IBM Systems
Diario, vol. 47, no. 4, 2008, pp. 591-604
[3] - Fazio, M .; Paone, et al., "Cantidad enorme de datos detectados heterogéneos necesita la nube", en Actas de la novena
IEEE Multi-Conferencia Internacional sobre Sistemas, Señales y Dispositivos (SSD), Chemnitz, 20-23 de de marzo de 2012
[4] -. Khan, Imran, et al, "una arquitectura multi-capa para Wireless Sensor Network virtualización" en Proceedings
Conjunto de la sexta IFIP Wireless y Mobile Networking Conference (WMNC'13), Abril 23-25, 2013, Dubai, UAE, pp. 1-4
[5] - P. Levis y D. Culler: "Maté: Una máquina virtual pequeña para redes de sensores," En ASPLOSX: Actas de la
10ª Conferencia Internacional sobre el soporte arquitectónico para lenguajes de programación y sistemas operativos,
San Jose, CA, 2002, pp. 85-95.
[6] -. AP Jayasumana, et al, "redes de sensores virtuales un enfoque eficiente de los recursos para aplicaciones simultáneas," En
Proc. Tecnología de la Información, 2007. ITNG'07. Cuarta Conferencia Internacional sobre, Las Vegas, 2007, pp. 111115
[7] -.Ceriotti, Matteo, et al. "Supervisión de edificios patrimoniales con las redes de sensores inalámbricos: La Torre Aquila
despliegue." en Actas de la Conferencia Internacional 2009 sobre el procesamiento de información en redes de sensores., IEEE Computer
Society, 2009.
[8] - S. Bhatti, J. et al, "MANTIS OS: un sistema operativo multiproceso embebido para sensor micro inalámbrico
plataformas" Multitud. Netw. Appl., 10 (4), 2005, pp.563-579
[9] -. HMN Dilum Bandara, et al, "Racimo del árbol basado en la auto-organización de redes de sensores virtuales" En Proc.
taller Globecom IEEE sobre malla inalámbrica y redes de sensores, Nueva Orleans, noviembre de 2008
[10] - Rowaihy, Hosam, et al. "Asignación de sensores para misiones en las redes de sensores inalámbricos." ACM Transactions on Sensor
(Redes), TOSN 6,4, (2010): 36
[11] - Leontiadis, Ilias, et al. "SenShare: la transformación de las redes de sensores en las infraestructuras de detección multi-aplicación,"
Sensor de redes inalámbricas, Springer Berlin Heidelberg, 2012, pp. 65-81.
[12] -. Y. Yu et al, "Soporte de aplicaciones concurrentes en redes de sensores inalámbricos," En los procedimientos de la cuarta
Conferencia Internacional sobre Sistemas integrados en red de sensores, SenSys'06, Boulder, Colorado, 2006, pp.139-152
[13] - Lua, Eng Keong, et al. "Un estudio y comparación de los planes de redes overlay peer-to-peer" IEEE
Las encuestas de comunicación y tutoriales, 7.2 (2005): 72-93.
[14] - Shelby, Z., "los servicios Web incorporado" Las comunicaciones inalámbricas, IEEE, vol.17, no.6, Dic de 2010, pp.52-57
[15] - Jara, AJ, et al, "Light-Weight Multicast DNS y DNS-SD (lmDNS-SD):. Servicio de Recursos IPv6-basada y
Descubrimiento de la Web de las Cosas" Servicios Móviles y de Internet innovadoras en la computación ubicua (IMIS), 2012 Sexta Conferencia
Internacional de , vol., núm., pp.731,738, 4-6 de julio de 2012
[16] - Botts, M., Robin, A., "Sensor Modelo de Lenguaje (SensorML)," Open Geospatial Consortium documento (OGC)
Número: 07 a 000, Wayland, Massachusetts, EE.UU..
[17] - Cox, S. (Ed.), "Observaciones y mediciones de la Parte 1-Observación Schema," Open Geospatial Consortium
(OGC) Número de documento: 07-002r1, Wayland, Massachusetts, EE.UU.
[18] -. Jennings, et al, "Proyecto de Jennings-senml-10", Proyecto de Internet, IETF, 22 de octubre de 2012 expira el 25 de de abril de, 2013
(trabajo en progreso)
[19] - Gong, Li. "JXTA: Un entorno de programación de la red." Internet Computación, IEEE 5.3 (2001): 88-95.
[20] - Al-Mamou, AA-B, y Houda Labiod.. "ScatterPastry: Una superposición de enrutamiento utilizando un DHT sobre sensores inalámbricos
redes ". Pervasive Computing inteligente, 2007. IPC. La Conferencia Internacional de 2007 sobre. IEEE, 2007. 274-279
biografías
Imran Khan (imran@ieee.org) recibió su título de BCS en Informática por el Instituto COMSATS de TI, Pakistán en 2005 y el grado de MS en Multimedia y
Comunicación de la Universidad de MA Jinnah, Pakistán en 2009. Desde mayo de 2011 es un Ph.D . estudiante de investigación en el CNRS Laboratorio
UMR5157 en el Institut Mines-Télécom, Télécom SudParis conjuntamente con Paris VI (UPMC). Actualmente es investigador colaborando en Concordia
University, Montreal trabajando en un proyecto de CISCO. En el pasado trabajó en proyectos financiados por la ISOC y ITEA2. Es miembro del IEEE
estudiante. Sus áreas de investigación son la virtualización, las redes inalámbricas de sensores, Internet de cosas (IoT) y M2M Comunicaciones.
FATNA BELQASMI (fatna.belqasmi@zu.ac.ae) tiene un Ph.D. y un M.Sc. título en ingeniería eléctrica e informática de la Universidad de Concordia,
Canadá. Ella es de trabajo actual como profesor asistente en la Universidad Zayed de Abu Dhabi, EAU. En el pasado, trabajó como investigador asociado
en la Universidad de Concordia, Canadá y como investigador en Ericsson Canadá. Ella era parte del proyecto IST ambiente de red (un proyecto de
investigación patrocinado por la Comisión Europea dentro del sexto programa marco -FP6-). Ella trabajó como ingeniero de I + D para Maroc Telecom en
Marruecos. Sus intereses de investigación incluyen las redes de próxima generación, la ingeniería de servicios, sistemas distribuidos y tecnologías de red
para las economías emergentes.
ROCH Glitho [SM] (http://users.encs.concordia.ca/~glitho/) tiene un doctorado (Tekn. Dr.) en tele-informática (Instituto Real de Tecnología de Estocolmo, Suecia) y M.Sc. grados en economía de la
empresa (Universidad de Grenoble, Francia), las matemáticas puras (Universidad de Ginebra, Suiza), y la informática (Universidad de Ginebra). Él trabaja en Montreal, Canadá, como profesor
asociado de redes y telecomunicaciones en el Instituto Concordia de Sistemas de Información Ingeniería (CIISE) donde dirige el laboratorio de investigación en ingeniería de servicios de
telecomunicaciones (TSE) (.http: //users.encs.concordia. ca / ~ tse /). En el pasado ha trabajado en la industria durante casi un cuarto de siglo y ha ocupado varios puestos de alto nivel técnico en
LM Ericsson en Suecia y Canadá (por ejemplo experto, ingeniero principal, especialista principal). Su experiencia industrial incluye la investigación, el establecimiento de normas internacionales
(por ejemplo, contribuciones a la UIT-T, ETSI, TMF, ANSI, TIA, y 3GPP), la gestión de productos, gestión de proyectos, ingeniería de sistemas y diseño de software / firmware. En el pasado se ha
desempeñado como IEEE Communications Society distinguido conferenciante, EditorIn jefe de la revista IEEE Communications y EditorIn jefe de encuestas y tutoriales IEEE Communications. Sus
áreas de investigación son: la virtualización y la computación en la nube; comunicaciones máquina a máquina (M2M) y de Internet de los objetos; Los sistemas distribuidos (por ejemplo jabón a
base - Servicios Web, Servicios Web REST); comunicaciones rurales y tecnologías de red para las economías emergentes. ingeniería de sistemas y diseño de software / firmware. En el pasado se
ha desempeñado como IEEE Communications Society distinguido conferenciante, EditorIn jefe de la revista IEEE Communications y EditorIn jefe de encuestas y tutoriales IEEE Communications.
Sus áreas de investigación son: la virtualización y la computación en la nube; comunicaciones máquina a máquina (M2M) y de Internet de los objetos; Los sistemas distribuidos (por ejemplo jabón a
base - Servicios Web, Servicios Web REST); comunicaciones rurales y tecnologías de red para las economías emergentes. ingeniería de sistemas y diseño de software / firmware. En el pasado se
ha desempeñado como IEEE Communications Society distinguido conferenciante, EditorIn jefe de la revista IEEE Communications y EditorIn jefe de encuestas y tutoriales IEEE Communications.
Sus áreas de investigación son: la virtualización y la computación en la nube; comunicaciones máquina a máquina (M2M) y de Internet de los objetos; Los sistemas distribuidos (por ejemplo jabón a base - Servicios Web, Servic
NOEL CRESPI (noel.crespi@mines-telecom.fr) tiene una maestría de las universidades de Orsay y Kent, un diploma de ingeniero de Telecom
ParisTech, y un Ph.D. y una habilitación de la Universidad de París VI. Trabajó desde 1993 en el CLIP, Bouygues Telecom, France Telecom I + D
en 1995, y Nortel Networks en 1999. Se unió Institut MinesTélécom en 2002 y actualmente es profesor y director del programa, lo que lleva el
Laboratorio de Arquitectura de Servicio. Es designado como coordinador de las actividades de normalización en el ETSI y 3GPP. Él es también
profesor visitante en el Instituto de Tecnología de Asia y está en el cuatro personas Scientific Advisory Board de FTW, Austria. Sus líneas de
investigación actuales están en arquitecturas de servicios, superposiciones de servicios P2P, Internet del futuro, y la convergencia Web-NGN.
MONIQUE Morrow (mmorrow@cisco.com) ostenta el título de la CTO servicios de Cisco. El enfoque de la Sra Morrow está en la tecnología de desarrollo estratégico y arquitecturas de negocio
para los clientes y partners de Cisco. Con más de 13 años en Cisco, Monique ha hecho contribuciones significativas en una amplia gama de funciones, desde la defensa de los clientes a Corporate
Consulting Ingeniería. Con especial énfasis en el segmento de proveedor de servicios, su experiencia incluye papeles en el campo (Asia-Pacífico) donde se llevó a cabo el objetivo de construir un
equipo fuerte de la tecnología, así como identificar y preparar a un sucesor para asegurar una transición suave y continua excelencia. Monique ha demostrado consistentemente su talento para el
pensamiento hacia delante y toma de riesgos en la exploración de oportunidades de mercado para Cisco. Ella era un visionario temprano en el terreno de MPLS como un facilitador de servicios de
tecnología, y ella era uno de los líderes en el desarrollo de nuevas oportunidades de negocio para Cisco en el segmento de proveedor de servicios, SP NGN. Monique ejerce en 3 patentes, y tiene
un adicional de nueve presentaciones de patentes presentadas en la Oficina de Patentes de Estados Unidos. Sra. Morrow es el co-autor de varios libros y es autor de numerosos artículos. Ella
también mantiene varios blogs de tecnología, y es un importante contribuyente a Radar Tecnología de Cisco, después de haber alcanzado Medalla de Oro del Salón de la Fama del estado por sus
contribuciones. Monique es también muy activa en asociaciones de la industria. Ella es un nuevo miembro del Consejo Asesor Estratégico de la Facultad de Ciencias de la Computación de la
Universidad Estatal de Carolina del Norte. Monique es particularmente apasionado niñas en las TIC y ha estado activo en la UIT Monique ejerce en 3 patentes, y tiene un adicional de nueve
presentaciones de patentes presentadas en la Oficina de Patentes de Estados Unidos. Sra. Morrow es el co-autor de varios libros y es autor de numerosos artículos. Ella también mantiene varios
blogs de tecnología, y es un importante contribuyente a Radar Tecnología de Cisco, después de haber alcanzado Medalla de Oro del Salón de la Fama del estado por sus contribuciones. Monique
es también muy activa en asociaciones de la industria. Ella es un nuevo miembro del Consejo Asesor Estratégico de la Facultad de Ciencias de la Computación de la Universidad Estatal de
Carolina del Norte. Monique es particularmente apasionado niñas en las TIC y ha estado activo en la UIT Monique ejerce en 3 patentes, y tiene un adicional de nueve presentaciones de patentes presentadas en la Oficina de P
en este tema - la presentación en el Parlamento de la UE en abril de 2013 como un defensor de Cisco. Dentro de la Oficina del CTO, por primera vez como un miembro,
y ahora como director de tecnología, se ha construido un equipo de liderazgo fuerte, y ella continúa impulsando estrategias de globalización y de país de Cisco.
PAUL POLAKOS (ppolakos@cisco.com) es actualmente un miembro Cisco y miembro del equipo de movilidad director de tecnología de Cisco
Systems se centra en las tecnologías emergentes para los sistemas de movilidad en el futuro. Antes de unirse a Cisco, Paul era Senior Director de
Investigación de Redes Wireless en los Laboratorios Bell, Alcatel-Lucent en Murray Hill, Nueva Jersey y París, Francia. Durante sus 28 años en los
Laboratorios Bell trabajó en una amplia variedad de temas en la física y en la Investigación de Redes inalámbricas, incluyendo la arquitectura IP
plana red celular, la estación Router Base, femtoceldas, antenas inteligentes y MIMO, algoritmos de radio y módem y ASICSs, redes autonómicas y
optimización de red dinámica. Antes de unirse a los Laboratorios Bell, él era un miembro del personal de investigación en el Instituto Max-Planck de
Física y Astrofísica (Munich) y científico visitante en el CERN y el Fermilab. Posee BS, MS, y Ph.

1501 07135 en Es

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

1501 07135 en Es

Cargado por

Copyright:

Formatos disponibles

Este documento ha sido aceptado en el estándar IEEE Network Magazine y aparecerá en mayo / junio el año 2015 Emisión.

Wireless Sensor de virtualización de redes: la arquitectura de principios e Investigación

2. Una visión crítica del estado-of-the-Art

Figura 1: WSN virtualización Categorías

2.1. Ejemplo y Requisitos motivador

2.1.1. Ejemplo motivador

2.2. El Estado-of-the-Art y sus deficiencias

2.2.1. La virtualización de nivel de nodo

2.2.2. La virtualización a nivel de red

2.2.3. Soluciones híbridas

3.1 Principios de arquitectura

TABLA I. do OMPONENTES DE LA UN RCHITECTURE

Abreviatura Componente observaciones

- Sensor de tipo A Legacy / sensor de recursos limitados

- Tipo B Sensor Nueva generación nodo sensor inteligente IP

GTO nodo Gates-a-Overlay Nodo de Pasarela / fregadero susceptible de aplicación unirse

- Registro repositorio de sensor

Acceso sensor virtual

interfaces unificados para apoyar nodos

Capa física Capa de

Figura 2: Multi-capa WSN virtualización Arquitectura

3.4 Procedimiento de creación de superposición

Sensor virtual de GTO Nodo [Agente Aplicación del

Sensor01 [Tipo A] del sensor] Usuario Final

a) Envío de datos de los sensores durante PDi y di las interfaces

Content-Type = application / json

b) Cambio de prioridad de la tarea de aplicación sobre PC _ y ci las interfaces

F igura 3: Ejemplo de comunicación a través de datos e interfaces de control

4 Alternativas aplicación, Prueba de concepto Prototipos y Medidas

4.1 Alternativas de implementación

Aplicación de Visualización del mapa

REST Ciudad de administración

mensaje HTTP POST Peer

En formato JSON Ciudad de

Tarea para ciudad de administración

Una casa Casa B

sensor B Un sensor sensor E

Figura 4: La instanciación de la arquitectura y la configuración Prototype

a) retardo del mensaje HTTP POST b) retraso creación Overlay

c) el retraso mensaje de notificación de incendios

También podría gustarte