ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO.

4, CUARTO TRIMESTRE 2015 2347

Internet de las cosas: una encuesta sobre tecnologías de

capacitación, protocolos y aplicaciones
Ala Al-Fuqaha, Senior Member, IEEE, Mohsen Guizani, Fellow, IEEE, Mehdi Mohammadi, Student, IEEE,
Mohammed Aledhari, Student, IEEE, Moussa Ayyash, Senior Member, IEEE

Abstracto -Este documento ofrece una visión general de la Internet de las

Cosas (IOT) con énfasis en tecnologías de capacitación, protocolos y cuestiones de
aplicación. El IO está habilitado de los últimos desarrollos en tecnología RFID, sensores
inteligentes, tecnologías de la comunicación y protocolos de Internet. La premisa básica
es tener sensores inteligentes COL- laborate participación humana directlywithout para
ofrecer una nueva clase de aplicaciones. La revolución actual en Internet, móvil y de
máquina a máquina (M2M) tecnologías puede ser visto como la primera fase de la IO. En
los próximos años, se espera que la IO para cubrir diversas tecnologías que permiten
nuevas aplicaciones mediante la conexión de los objetos físicos juntos en apoyo de la
toma de decisiones inteligentes. Este documento comienza proporcionando una visión
horizontal de la IO. A continuación, damos una visión general de algunos detalles
técnicos que pertenecen a la IO permitiendo tecnologías, protocolos y aplicaciones.
Comparado con otros documentos de la encuesta en el campo, nuestro objetivo es
proporcionar un resumen más completo de los protocolos más relevantes y los
problemas de la aplicación para permitir que los investigadores y desarrolladores de
aplicaciones para ponerse al día rápidamente sobre cómo los diferentes protocolos fi cio
juntos para entregar funcionalidades deseadas sin tener que ir a través de RFC y los
estándares de las especificaciones. También proporcionamos una visión general de
algunos de los principales retos de la IO presentados en la reciente atura litro-y
proporcionar un resumen de los trabajos de investigación relacionados. Por otra parte,
se explora la relación entre la IO y otras tecnolo- gías emergentes incluyendo analítica de
grandes datos y la nube y la computación en la niebla. También se presenta la necesidad
de una mejor integración horizontal entre los servicios de la IO. Finalmente,

Fig. 1. El cuadro general de la IO haciendo hincapié en los mercados verticales y la integración

horizontal entre ellos.

Términos del Índice -Internet de los objetos (IO), COAP, MQTT, AMQP, a los desastres naturales y artificiales donde la toma de decisión humana es difícil.
XMPP, DDS, mDNS, puerta de entrada IO.

El IO permite que los objetos físicos para ver, oír, pensar y realizar trabajos por tener
I. INTRODUCCIÓN
ellos “hablan” entre sí, para compartir información y coordinar las decisiones. El IO

UN conectados a los
Creciente de Internet
número a un ritmo
de objetos físicossinestán
precedentes realizar la idea de la
siendo con-
transforma estos objetos de ser tradicional inteligente mediante la explotación de sus
tecnologías subyacentes, tales como la computación ubicua y omnipresente, dispositivos
Internet de los objetos (IO). Un ejemplo básico de este tipo de objetos incluye integrados, tecnologías de la comunicación, redes de sensores, protocolos y aplicaciones
termostatos y HVAC (Calefacción, Ventilación y Aire Acondicionado) sistemas de de Internet. Los objetos inteligentes, junto con sus supuestas tareas constituyen
vigilancia y control que permiten a los hogares inteligentes. También hay otros aplicaciones de dominio especí fi cos (mercados verticales) mientras que los servicios
dominios y entornos en los que la IO puede desempeñar un papel notable y mejorar independientes de dominio de la informática y servicios de análisis formulario de solicitud
la calidad de nuestras vidas. Estas aplicaciones incluyen el transporte, la salud, la ubicua (mercados horizontales). La Fig. 1 ilustra el concepto general de la IO en el que
automatización industrial, y la respuesta de emergencia cada aplicación c especificidad de dominio está interactuando con servicios
independientes de dominio, mientras que en cada uno de los sensores de dominio y
actuadores comunicarse directamente entre sí.
Manuscrito recibido 11 de octubre de, 2014; Revisado 11 de de abril de, 2015; aceptado el 25 de mayo de 2015.
Fecha de publicación 15 de junio de, 2015; fecha de la versión de corriente 18 de noviembre de 2015.

A. Al-Fuqaha, M. Mohammadi, y M. Aledhari son con el Departamento Con el tiempo, se espera que la IO tener aplicaciones en el hogar fi cante y de
de Ciencias de la Computación de la Universidad de Western Michigan, Kalamazoo, MI 49008 EE.UU.
negocios significantes, para contribuir a la calidad de vida y hacer crecer la economía del
(e-mail: ala.al-fuqaha@wmich.edu; mehdi.mohammadi@wmich.edu; mohammed.aledhari@wmich.edu).
mundo. Por ejemplo, inteligentes Casas permitirá a sus residentes para abrir
M. Guizani es con el Departamento de Ciencias de la Computación e Ingeniería, automáticamente su garagewhen llegar a casa, preparar el café, el control de los
Universidad de Qatar, Doha 2713, Qatar (e-mail: mguizani@ieee.org).
sistemas de climatización, televisores y otros electrodomésticos. Para la realización de
M. Ayyash es con el Departamento de Estudios de la Información, Chicago State
Universidad, Chicago, IL 60628 EE.UU. (e-mail: mayyash@csu.edu).
este potencial de crecimiento, tecnologías e innovaciones emergentes, y el servicio
Objetos Digitales identi fi cador 10.1109 / COMST.2015.2444095

1553-877X © 2015 IEEE. El uso personal está permitida, pero republicación / redistribución requiere el permiso del IEEE.
Ver http://www.ieee.org/publications_standards/publications/rights/index.html para más información.
2348 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 4, CUARTO TRIMESTRE 2015
aplicaciones necesitan para crecer proporcionalmente para que coincida con las demandas del
mercado y las necesidades del cliente. Además, los dispositivos deben ser desarrollados a los
requerimientos del cliente fi t en términos de disponibilidad en cualquier momento y en cualquier
lugar. Además, se requieren nuevos protocolos para la compatibilidad comunicación entre cosas
heterogéneas (los seres vivos, vehículos, teléfonos, electrodomésticos, productos, etc.).
Por otra parte, la arquitectura normalización puede ser visto como una
columna vertebral de la IO para crear un entorno competitivo para las
empresas que ofrecen productos de calidad. Además, la arquitectura
tradicional de Internet necesita ser revisada para que coincida con los desafíos
de la IO. Por ejemplo, el tremendousnumberofobjectswilling para conectarse a
Internet debe considerarse inmany protocolos subyacentes. En 2010, el
número de objetos conectados a Internet había superado a la población
humana de la tierra [1]. Por lo tanto, la utilización de un gran espacio de
direccionamiento (por ejemplo, IPv6) se hace necesario para satisfacer las
demandas de los clientes para los objetos inteligentes. La seguridad y la
privacidad son otros requisitos importantes para la IoTdue a la heterogeneidad
inherente de los objetos conectados a Internet y la capacidad tomonitor y
controlar los objetos físicos. Además,
Hay varios documentos publicados de la encuesta que cubren diferentes aspectos
de la tecnología de la IO. Por ejemplo, la lista por Atzori et al. [ 2] cubre la
comunicación principal que permite tecnologías, e inalámbricas por cable y los
elementos de las redes de sensores inalámbricos (WSNs). En [3], los autores
abordan la arquitectura de la IO y los retos del desarrollo y despliegue de aplicaciones
de la IO. Las tecnologías de apoyo y servicios de aplicación utilizando una visión
nube centralizado se presentan en [4]. Los autores en [5] proporcionan una encuesta
de la IO para dispositivos inalámbricos clínicas especializadas utilizando 6LoWPAN /
IEEE 802.15.4, Bluetooth y NFC para aplicaciones de salud móvil y la salud en línea.
Por otra parte, [6] se ocupa de la IO en términos de tecnologías de capacitación con
énfasis en RFID y sus aplicaciones potenciales. retos de la IO se presentan en [7]
para cerrar la brecha entre la investigación y los aspectos prácticos. Una visión
general de las normas y los desafíos para la IO IETF actuales se ha presentado en
[8].
El contorno de las aportaciones de este trabajo en relación con la literatura
reciente en el campo se puede resumir como:
• En comparación con otros papeles de la encuesta en el campo, este estudio
proporciona un resumen más profunda de los protocolos y normas más
relevantes IETF, IEEE y EPCglobal para permitir a los investigadores a ponerse
al día rápidamente sin tener que excavar a través de los datos presentados en
las RFC y los estándares especificaciones.
• Proporcionamos, una descripción algunos de los desafíos clave de la IO presentados
en la literatura reciente y proporcionar un resumen de los trabajos de investigación
relacionados. Por otra parte, se explora la relación entre la IO y otras tecnologías
emergentes incluyendo analítica de grandes datos y la nube y la computación en la
niebla.
• Se presenta la necesidad de una mejor integración horizontal entre los servicios
de la IO.
• También presentamos los casos de uso de servicios detallados para ilustrar cómo los
diferentes protocolos presentados en el documento fi cio juntos para ofrecer servicios
de IO deseados.
El resto del trabajo se organiza como sigue: Sección II proporciona un resumen
de themarket oportunidad que está habilitado por el
IO. Secciones III y IVdiscuss la arquitectura general de la IO y sus elementos,
respectivamente. protocolos y normas de la IO actuales se presentan en la Sección V.
Seguridad, la confianza, el seguimiento, la gestión y la calidad de servicio (QoS) temas
se discuten en SecciónVI. La interacción entre los grandes datos y la IO y la necesidad
de gestionar y analizar grandes cantidades de datos generados por la IO es el foco de
SectionVII. En SectionVIII, se presenta la necesidad de servicios de intercambio de
datos y la gestión inteligente de la IO para lograr una mejor integración horizontal entre
los servicios de la IO. La integración de los diferentes protocolos de IO para ofrecer
funcionalidades deseadas se presenta en la Sección IX usando algunos casos de uso
de las aplicaciones y servicios de la IO. Por último, la sección X presenta un resumen
de las lecciones aprendidas y concluye este estudio.
II. METRO ERCADO O portunidad
El IO ofrece una gran oportunidad de mercado para equipmentmanufacturers,
andapplicationdevelopers serviceproviders Internet. Se espera que los objetos
inteligentes de la IO para llegar a 212 mil millones cuando estén desplegados en todo el
mundo a finales de 2020 [9]. Por 2022, M2M tráfico c Se espera que fluye a constituir
hasta el 45% de todo el tráfico de Internet fi c [1], [9], [10]. Más allá de estas
predicciones, McKinsey Global Institute informó que el número de máquinas conectadas
(unidades) ha crecido un 300% en los últimos 5 años [11]. Traf fi c monitorización de una
red celular en los EE.UU. también mostró un aumento de 250% para el volumen M2M
tráfico c en 2011 [12].
El crecimiento económico de los servicios basados ​en la IO también es considerable
para las empresas. Se prevé que las aplicaciones sanitarias y de fabricación para formar el
mayor impacto económico. aplicaciones de salud y servicios basados ​en la IO relacionados,
tales como la salud móvil (m-Health) y la teleasistencia que permiten médica de bienestar,
prevención, diagnóstico, tratamiento y seguimiento de los servicios a ser entregado e fi
ciente a través de medios electrónicos se espera que genere alrededor de $ 1.1- $ 2,5
billones en el crecimiento anualmente por la economía mundial en el año 2025. todo el
impacto económico anual causado por la IO se estima en el rango de $ 2.7 billones a $ 6.2
billones para el 2025 [11]. La Fig. 2 muestra la cuota de mercado proyectada de
aplicaciones de IO dominantes [11].
Por otro lado, Wikibon predice que el valor creado a través de Internet industrial sea
alrededor de $ 1279 mil millones en 2020, con retorno de la inversión (ROI) que crecen a un
149% en comparación con el 13% en 2012 [13]. Por otra parte, Navigant informó
recientemente que se espera que el mercado de la construcción Automation Systems (BAS)
aumentará de $ 58,1 mil millones en 2013 para llegar a $ 100,8 mil millones en 2021; un
aumento del 60% [14].
Todas estas estadísticas, sin embargo, apuntan a un fi cante y el rápido ritmo
potencialmente signi crecimiento de la IO en un futuro próximo, las industrias y servicios
relacionados. Esta progresión ofrece una oportunidad única para los equipos tradicionales y
los fabricantes de electrodomésticos para transformar sus productos en “cosas inteligentes.”
Spreading la IO y servicios relacionados a nivel mundial requiere que los proveedores de
servicios de Internet (ISP) para el suministro de sus redes para proporcionar QoS para una
mezcla de M2M, persona a máquina ( P2M) y persona a persona
(P2P) tráfico c flujos.
III. A la IO RCHITECTURE
El IO debe ser capaz de interconectar mil millones o billones de objetos
heterogéneos a través de Internet, por lo que hay una
AL-Fuqaha et al .: IOT Encuesta sobre tecnologías de capacitación, protocolos y aplicaciones
Fig. 2. Proyección de la cuota de mercado de las aplicaciones dominantes de la IO 2025.
Fig. 3. La arquitectura de la IO. (A) de tres capas. (B) medio-ware basado. basa (c) SOA. (D) de cinco
capas.
acuciante necesidad de una arquitectura de capas flexible. El número cada vez mayor de
las arquitecturas propuestas aún no ha convergido a un modelo de referencia [15].
Mientras tanto, hay algunos proyectos como la IO-A [16], que tratan de diseñar una
arquitectura común basada en el análisis de las necesidades de los investigadores y la
industria.
Desde la piscina de modelos propuestos, el modelo básico es una arquitectura de
3 capas [3], [17], [18] que consta de la Solicitud, la red y las capas de Percepción. En
la literatura reciente, sin embargo, se han propuesto algunos otros modelos que
añadir más abstracción de la arquitectura de la IO [2], [3], [17] - [20]. La Fig. 3 ilustra
algunas arquitecturas común entre ellos es el modelo de 5 capas (que no debe
confundirse con las capas de TCP / IP), que se ha utilizado en [3], [17], [18]. A
continuación, ofrecemos una breve discusión sobre estas cinco capas.
A. objetos de la capa
La primera capa, los objetos (dispositivos) o capa de la percepción, representa los
sensores físicos de la IO que tienen como objetivo recoger y procesar información.
Esta capa incluye sensores y actuadores para realizar diferentes funciones tales como
la ubicación consultar, temperatura, peso, movimiento, vibración, aceleración, la
humedad,
2349
etc. estandarizada plug-and-playmechanisms necesitan ser utilizados por la capa de
percepción para con objetos heterogéneos cifra [17], [18]. La capa percepción digitaliza y
transferencias de datos a la capa de abstracción de objeto a través de canales seguros.
Los grandes volúmenes de datos creadas por la IO se inician en esta capa.
B. Objeto de capa de abstracción
Objeto de datos de transferencias de Abstracción producidos por la capa de objetos
a la capa ServiceManagement a través de canales seguros. Los datos pueden
transferirse a través de diversas tecnologías tales como RFID, 3G, GSM, UMTS, Wi-Fi,
BluetoothLowEnergy, infrarrojo, ZigBee, etc. Además, otras funciones como procesos
de computación en la nube y de gestión de datos se manejan en esta capa [17].
Capa C. Gestión de Servicios
Gestión de servicios o Middleware (emparejamiento) pares de capas de un servicio con
su solicitante sobre la base de direcciones y nombres. Esta capa permite a los
programadores de aplicaciones de la IO para trabajar con objetos heterogéneos y sin
consideración a una plataforma de hardware especí fi co. Además, estos procesos de capa
de datos recibidos, toma decisiones, y proporciona los servicios requeridos en los
protocolos de alambre red [3], [18], [20].
Capa de Aplicación D.
La capa de aplicación proporciona los servicios solicitados por los clientes. Por ejemplo,
la capa de aplicación puede proporcionar mediciones de la temperatura y la humedad del aire
para el cliente que solicita que los datos. La importancia de esta capa de la IO es que tiene la
capacidad de proporcionar servicios inteligentes de alta calidad para satisfacer las
necesidades de los clientes. La capa de aplicación abarca numerosos mercados verticales
tales como el hogar inteligente, edificio inteligente, el transporte, la automatización industrial y
la asistencia sanitaria inteligente [3], [17] - [19].
Capa E. Negocio
El (gestión) capa de negocio gestiona las actividades y servicios generales del sistema
de la IO. Las responsabilidades de esta capa son para construir un modelo de negocio,
gráficos, owcharts fl, etc. basado en los datos recibidos de la capa de aplicación. También
se supone que debe diseñar, analizar, implementar, evaluar, supervisar y desarrollar los
elementos relacionados con el sistema de la IO. La capa de negocios hace que sea posible
para apoyar los procesos de toma de decisiones basadas en el análisis de datos grandes.
Además, el seguimiento y la gestión de las cuatro capas subyacentes se logra en esta
capa. Por otra parte, esta capa compara la salida de cada capa con la salida esperada
para mejorar los servicios y mantener la privacidad de los usuarios [3], [18].
observaciones: Las arquitecturas que se endeudan sus capas y conceptos de pilas de
red (como el modelo de tres capas) no se ajustan a los entornos reales de la IO, ya que,
por ejemplo, la “capa de red” no cubre todas las tecnologías subyacentes que transfieren
datos a una plataforma de la IO. Además, estos modelos han sido diseñados para hacer
frente a tipos específicos de los medios de comunicación tales como WSNs. Más
importante aún, se supone que las capas se puede ejecutar en dispositivos con recursos
limitados mientras que la arquitectura basada en SOA que tiene una capa como
“Composición de servicio” en la toma lugar
2350 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 4, CUARTO TRIMESTRE 2015
Fig. 4. Los elementos de la IO.
una gran fracción del tiempo y la energía del dispositivo se comunique con otros
dispositivos e integrar los servicios requeridos.
En los cinco-capa del modelo, la capa de aplicación es la interfaz bywhich los usuarios
finales pueden interactuar con un dispositivo y consulta de datos interesantes. También
proporciona una interfaz a la capa de negocio donde el análisis y los informes de alto nivel
pueden ser producidos. Los mecanismos de control de acceso a los datos en la capa de
aplicación también se manejan en esta capa. Esta capa está alojado en dispositivos de
gran alcance debido a sus necesidades computacionales complejos y enormes.
Considerando estos puntos, por una parte y que se pega a la simplicidad de la
arquitectura en el otro lado, los cinco-capa de la arquitectura es el modelo más aplicable
para aplicaciones de IO.
IV. IO E ELEMENTOS
La comprensión de los bloques de construcción de la IO ayuda a obtener una mejor
penetración en el significado real y la funcionalidad de la IO. En las siguientes secciones
se discuten seis elementos principales necesarios para ofrecer la funcionalidad de la IO
como se ilustra en la Fig. 4. La Tabla II muestra las categorías de estos elementos y
ejemplos de cada categoría.
A. La identificación
Identi fi cación es crucial para la IO para nombrar y servicios de los partidos con su
demanda. Muchos métodos de identi fi cación están disponibles para la IO tales como
códigos electrónicos de productos (EPC) y códigos ubicuos (UCODE) [21]. Además,
frente a los objetos IO es crítica para diferenciar entre ID de objeto y su dirección. ID
del objeto se refiere a su nombre como “T1” para un sensor de temperatura particular y
la dirección del objeto se refiere a su dirección dentro de una red de comunicaciones.
Además, los métodos de direccionamiento de objetos IO incluyen IPv6 e IPv4.
6LoWPAN [22], [23] proporciona un mecanismo de compresión sobre cabeceras IPv6
que hace que el direccionamiento IPv6 apropiado para redes inalámbricas de baja
potencia. Distinguir entre la identi fi cación del objeto y dirección es imprescindible ya
que los métodos de identi fi cación no son única a nivel mundial, por lo que abordar
asistencias para identificar objetos. Además, los objetos dentro de la red podrían
utilizar direcciones IP públicas y privadas cuáles no. métodos fi cación se utilizan para
proporcionar una identidad clara para cada objeto dentro de la red.
B. detección
La detección de la IO significa reunir datos de objetos relacionados dentro de la red y
enviarlo de nuevo a un almacén de datos, base de datos o en la nube. Los datos recogidos se
analizan para tomar acciones especí fi cas sobre la base de los servicios requeridos. Los
sensores de la IO pueden ser sensores inteligentes, actuadores o dispositivos de detección
usables. Por ejemplo, empresas como Wemo, Revolv y SmartThings ofrecen hubs inteligentes
y aplicaciones móviles que permiten a las personas para monitorear
y controlar miles de dispositivos inteligentes y aparatos dentro de los edificios utilizando
sus teléfonos inteligentes [24] - [26].
Individuales ordenadores de a bordo (SBC) integrados con sensores incorporados y
funcionalidades TCP / IP y de seguridad normalmente se utilizan para la realización de productos
de la IO (por ejemplo, Arduino Yun, Frambuesa Pi, BEAGLEBONE Negro, etc.). Tales dispositivos
se conectan normalmente a un portal de gestión central para proporcionar los datos requeridos por
los clientes.
C. Comunicación
Las tecnologías de la comunicación de la IO se conectan objetos heterogéneos juntos
para ofrecer servicios inteligentes fi cas. Normalmente, los nodos de la IO deben
funcionar con baja potencia en la presencia de enlaces de comunicación con pérdida y
ruidosos. Ejemplos de protocolos de comunicación utilizados para la IO son WiFi,
Bluetooth, IEEE
802.15.4, Z-Wave, andLTE-avanzada. Algunas tecnologías de la comunicación fi cas que
también se utilizan como RFID, Near Field Communication (NFC) y ultra gran ancho de banda
( UWB). RFID es la tecnología de primera utilizado para realizar el concepto de M2M (etiqueta
RFID y el lector). La etiqueta RFID representa un chip simple o etiqueta adjunta para
proporcionar la identidad del objeto. El lector RFID transmite una señal de consulta a la
etiqueta y recibe la señal re fl eja de la etiqueta, que a su vez se pasa a la base de datos. La
base de datos se conecta a un centro de procesamiento para identificar los objetos en función
de la re fl señales ejadas dentro de un (10 cm a 200 m) Rango [27]. Las etiquetas RFID
pueden ser activos, pasivos o semi-pasivo / activo. Las etiquetas activas son alimentados por
la batería, mientras que las pasivas no necesitan batería. etiquetas semi-pasivos / activos
usan alimentación de la placa cuando sea necesario.
TheNFCprotocolworks en banda de alta frecuencia a 13,56 MHz y soporta la velocidad
de datos de hasta 424 kbps. La gama aplicable es de hasta 10 cm donde puede ocurrir la
comunicación entre lectores activos y etiquetas pasivas o dos lectores activos [28]. La
tecnología TheUWBcommunication está diseñado para soportar las comunicaciones
dentro de un área de baja cobertura de gama baja que utilizan energía y alto ancho de
banda cuyas aplicaciones para conectar los sensores se han incrementado recientemente
[29].
Otra tecnología de la comunicación es inalámbrica que utiliza ondas de radio para el
intercambio de datos entre las cosas dentro de 100 m de alcance [30]. Wi-Fi permite a los
dispositivos inteligentes para comunicarse e intercambiar información sin necesidad de
utilizar un router de alguna ad hoc estafar configuraciones fi. Bluetooth presenta una
tecnología de comunicación que se utiliza para intercambiar betweendevices datos en
distancias cortas utilizando la radio de onda corta para reducir al mínimo el consumo de
energía [31]. Recientemente, el Bluetooth grupo de interés especial ( SIG) produjo Bluetooth
4.1 que incorpora Bluetooth Low Energy, así como de alta velocidad y conectividad IP para
apoyar la IO [32]. el IEEE
802.15.4 estándar es especí fi tanto una capa física y un control de acceso al medio
para redes inalámbricas de baja potencia de orientación comunicaciones fiables y
escalables [33].
AL-Fuqaha et al .: IOT Encuesta sobre tecnologías de capacitación, protocolos y aplicaciones 2351

TABLA I TABLA II
do O OMÚN TR ABAJO S ISTEMAS U SED EN IOTE NVIRONMENTS B uilding B CERRADURAS Y TECNOLOGÍAS DE LA IOT

LTE (Long-TermEvolution) es originalmente una comunicación inalámbrica estándar

para la transferencia de datos de alta velocidad entre teléfonos móviles basados ​en GSM /
UMTS tecnologías de red [34]. Puede cubrir los dispositivos de rápido que viajan y
proporcionar servicios de multidifusión y difusión. LTE-A (LTE Avanzado) [35] es una
versión mejorada de LTE incluyendo la extensión de ancho de banda que soporta hasta
100 MHz, enlace descendente y enlace ascendente de multiplexado espacial, cobertura
extendida, mayor rendimiento y latencias más bajas.

D. Cálculo

unidades de procesamiento (por ejemplo, microcontroladores, microprocesadores,

SOC, FPGAs) y aplicaciones de software representan el “cerebro” y la capacidad
computacional de la IO. Varias plataformas de hardware se han desarrollado para
ejecutar aplicaciones de la IO como Arduino, UDOO, FriendlyARM, Intel Galileo,
Frambuesa Pi, Gadgeteer, BEAGLEBONE, Cubieboard, Z1, WiSense, Mulle, y Sky
T-Mote. Servicios, servicios de colaboración-Aware y servicios ubicuos. servicios relacionados con

Por otra parte, muchas plataformas de software se utilizan para proporcionar la identidad son los servicios más básicos e importantes que se utilizan en otros tipos de

funcionalidades de la IO. Entre estas plataformas, sistemas operativos son de vital servicios. Cada aplicación que necesita para llevar objetos del mundo real al mundo virtual

importancia, ya que siguen durante todo el tiempo de activación de un dispositivo. Hay tiene que identificar esos objetos. Agregación de Servicios de Información recoger y resumir

varios sistemas de tiempo real (RTOS) de funcionamiento que son buenos candidatos las mediciones sensoriales primas que necesitan ser procesados ​y reportado a la aplicación

para el desarrollo de aplicaciones basadas en la IO RTOS. Por ejemplo, la Contiki RTOS de la IO. Servicios de colaboración-Aware actúan en la parte superior de agregación de

se ha utilizado ampliamente en los escenarios de la IO. Contiki tiene un simulador de información Servicios y utilizar los datos obtenidos para tomar decisiones y reaccionar en

llama Cooja que permite a los desarrolladores investigador y para simular y emulan red consecuencia. Servicios ubicuos, sin embargo, tienen por objeto proporcionar servicios de

de sensores inalámbricos (WSN) aplicaciones [36] la IO y. TinyOS [37], LiteOS [38] y Riot colaboración-Aware en cualquier momento que son necesarios para nadie ¿Quién los

OS [39] también ofrecen OS peso ligero diseñado para entornos de IO. Además, algunos necesita en cualquier sitio. Con esta clasificación, se revisan algunas aplicaciones de la IO

líderes de la industria automotriz con Google establecieron el Abierto de Auto Alliance en los siguientes párrafos. El objetivo final de todas las aplicaciones de la IO es alcanzar el

(OAA) y están planeando traer nuevas características a la plataforma Android para nivel de servicios ubicuos. Sin embargo, este extremo no se puede lograr fácilmente, ya

acelerar la adopción de la Internet de Vehículos (IOV) paradigma [40]. Algunas de las que hay una gran cantidad de di fi cultades y los retos que deben abordarse. La mayor

características de estos sistemas operativos se comparan en la Tabla I. parte de las aplicaciones existentes proporcionan identityrelated, agregación de
información, y los servicios de colaboración con conciencia. asistencia sanitaria inteligente y
redes inteligentes entran en la categoría de agregación de información y el hogar
inteligente, edificios inteligentes, sistemas de transporte inteligente (ITS), y la

Las plataformas de nubes forman otra parte computacional importante de la IO. Estas automatización industrial están más cerca de la categoría de colaboración consciente.

plataformas proporcionan facilidades para los objetos inteligentes para enviar sus datos a la

nube, para grandes volúmenes de datos a ser procesados ​en tiempo real, y con el tiempo para

que los usuarios finales se benefician de los conocimientos extraídos de los datos recogidos

grandes. Hay una gran cantidad de plataformas en la nube libres y comerciales y los marcos

disponibles para albergar los servicios de la IO. Algunos de estos servicios se introducen en la Casa inteligente [ 43] Los servicios de la IO contribuyen a mejorar el estilo de vida personal,

sección VII-B. haciendo que sea más fácil y más conveniente para controlar y operar los aparatos

electrodomésticos y sistemas (por ejemplo, aire acondicionado, sistemas de calefacción,

contadores de consumo de energía, etc.) de forma remota. Por ejemplo, una casa inteligente

puede cerrar automáticamente las ventanas y bajar las persianas de las ventanas de la planta
E. Servicios
superior sobre la base de la previsión meteorológica. Los hogares inteligentes están obligados a

En general, los servicios de la IO se pueden clasificar en cuatro clases [41], [42]: Servicios tener interacción regular con sus entornos internos y externos [44].

relacionados con la identidad, información de agregación

2352 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 4, CUARTO TRIMESTRE 2015
El medio interno puede incluir todos los electrodomésticos y dispositivos que están
conectados en Internet, mientras que el entorno externo se compone de entidades que no
están en el control de la casa inteligente, tales como entidades de red inteligente.
edificios inteligentes conectar Los sistemas de automatización de edificios ( BAS) a Internet
[45]. BAS permite controlar y gestionar los diferentes dispositivos de construcción, usando
sensores y actuadores, tales como climatización, iluminación y sombreado, la seguridad, la
seguridad, entretenimiento, etc. Además, BAS puede ayudar a mejorar el consumo de energía y
el mantenimiento de los edificios. Por ejemplo, un sistema de lavavajillas o de enfriamiento /
calentamiento intermitente puede proporcionar indicaciones cuando hay un problema que
necesita ser comprobado y resuelto. Por lo tanto, las solicitudes de mantenimiento pueden ser
enviados a una empresa contratada sin ninguna intervención humana.
los sistemas de transporte inteligente ( ITS) o Sistemas de transporte
Cyber-físicos ( T-CPS) representan integración entre cálculo y comunicación
para supervisar y controlar la red de transporte [46], [47]. Sus objetivos para
lograr una mayor fiabilidad, e fi ciencia, la disponibilidad y la seguridad de la
infraestructura de transporte. ITS emplea cuatro componentes principales, a
saber: subsistema del vehículo (consta de GPS, lector RFID, OBU, y la
comunicación), subsistema de estación (equipo de lado de la carretera), su
centro de vigilancia y subsistema de seguridad. Por otra parte, los vehículos
conectados son cada vez más importantes con el objetivo de hacer la
conducción más segura, agradable y e fi ciente [48], [49]. Por ejemplo, Audi se
convirtió en el primer fabricante de automóviles fi con una licencia para
selfdriving en Nevada [50]. Google es otro de los pioneros en este ámbito [51].
Además, en diciembre de 2013, Volvo anunció su coche de auto-conducción
para conducir a unas 30 millas de carreteras con mucho tráfico en
Gotemburgo, Suecia [52].
Automatización industrial [ 53], [54], es la informatización de dispositivos robóticos para
completar las tareas de fabricación con una mínima intervención humana. Permite un grupo de
máquinas para producir productos de forma rápida andmore con precisión sobre la base de
cuatro elementos: el transporte, el procesamiento, la detección y la comunicación. La IO es
utilizado en la automatización industrial para controlar y supervisar las operaciones, funciones, y
la tasa de productividad de las máquinas de producción a través de Internet. Por ejemplo, si una
máquina de producción particular se encuentra con un problema de repente, un sistema IO
envía una solicitud de mantenimiento de inmediato al departamento de mantenimiento para
manejar la fi x. Por otra parte, la IO aumenta la productividad mediante el análisis de los datos
de producción, el momento y las causas de los problemas de producción.
asistencia sanitaria inteligente juega un papel significativo en aplicaciones de atención médica
a través de la incorporación de sensores y actuadores en los pacientes y sus medicamentos con
fines de vigilancia y seguimiento. El IO es utilizado por la atención clínica para monitorizar estados
fisiológicos de los pacientes a través de sensores mediante la recopilación y el análisis de su
información y después el envío de los datos del paciente analizado de forma remota a centros de
procesamiento para realizar las acciones adecuadas. Por ejemplo, Masimo Radical-7monitors el
estado del paciente y de forma remota informa de que a un personal clínico [55]. Recientemente,
IBM utiliza la tecnología RFID en uno de los hospitales de OhioHealth para rastrear el lavado de
manos después de comprobar cada paciente [56] - [58]. Esa operación se podría utilizar para
evitar las infecciones que causan cerca de 90 000 muertes y perdiendo cerca de $ 30 mil millones
al año.
Redes inteligentes [ 44], [59] utilizar la IO para mejorar y aumentar el consumo de
energía de casas y edificios. El empleo de la IO en las redes inteligentes ayuda a los
proveedores de energía para controlar andmanage recursos para proporcionar energía
proporcionalmente al aumento de la población. Por ejemplo, los gridsuse inteligente
IoTtoconnectmillions o mil millones de metros inmobiliaria a la red de proveedores de
energía. Estos indicadores se utilizan para recoger, analizar, controlar, supervisar y
gestionar el consumo de energía. El IO permite a los proveedores de energía para mejorar
sus servicios tomeet necesidades de los consumidores. Además, la utilización de la IO en la
red inteligente reduce los posibles fallos, aumenta la e fi ciencia y mejora la calidad de los
servicios.
UN ciudad inteligente lo que podría ser visto como una aplicación de servicios ubicuos,
tiene como objetivo mejorar la calidad de vida en la ciudad, haciendo que sea más fácil y más
conveniente para los residentes de encontrar información de interés [60], [61]. En un entorno
de ciudad inteligente, varios sistemas basados ​en tecnologías inteligentes están conectados
entre sí para proporcionar los servicios requeridos (salud, servicios públicos, transporte,
gobierno, casas y edificios).
F. Semántica
Semántica en la IO se refiere a la capacidad de extraer el conocimiento
inteligentemente por diferentes máquinas para proporcionar los servicios requeridos.
extracción de conocimiento incluye el descubrimiento y el uso de los recursos y la
información de modelado. Además, incluye el reconocimiento y análisis de datos para
dar sentido a la decisión correcta para proporcionar el servicio exacto [62]. Por lo tanto,
semántica representa el cerebro de la IO mediante el envío de demandas para el recurso
adecuado. Este requisito se apoya en tecnologías de Web Semántica como el Marco de
Descripción de Recursos (RDF) y el Lenguaje de Ontologías Web (OWL). En 2011, el Consorcio
Mundial de la red
(W3C) adoptó el E fi ciente de intercambio XML ( EXI) formato como una
recomendación [63].
EXI es importante en el contexto de la IO ya que está diseñado para optimizar las
aplicaciones XML para entornos con recursos limitados. Además, reduce las necesidades de
ancho de banda sin afectar los recursos relacionados, como la duración de la batería, el
tamaño del código, la energía consumida para el procesamiento y el tamaño de la memoria.
EXI convierte los mensajes XML a binario para reducir el ancho de banda necesario y
minimizar el tamaño de almacenamiento requerido.
observaciones: En esta sección, los principales componentes de la IO Se
identificaron junto con sus estándares, tecnologías y realizaciones. La variedad de
normas y tecnologías en estos elementos y la forma en que deben interoperar es
un reto principal que puede impedir el desarrollo de aplicaciones de la IO. La
heterogeneidad de los elementos de la IO necesita una solución de fondo para
que los servicios de la IO ubicuos una realidad. Sección VIII aborda este
problemby proponer un modelo arquitectónico que alivia los problemas de
interoperabilidad causados ​por la diversidad de protocolos y tecnologías utilizadas
en el contexto de la IO.
V. IO C OMÚN S NORMAS
Se proponen muchos estándares de la IO para facilitar y simplificar los empleos de los
proveedores de servicios y aplicaciones programadores. Los diferentes grupos se han
creado para proporcionar protocolos en apoyo de la IO incluidos los esfuerzos dirigidos por el
World Wide Web Consortium (W3C), Grupo de Trabajo de Ingeniería de Internet ( IETF),
EPCglobal,
AL-Fuqaha et al .: IOT Encuesta sobre tecnologías de capacitación, protocolos y aplicaciones 2353

TABLA III
S FFORTS TANDARDIZATION E en S POYO DE LA IOT

Fig. 5. funcionalidad coap.

COAP tiene por objeto permitir diminutos dispositivos con capacidades de baja
potencia, cálculo y comunicación para utilizar las interacciones RESTful. Coap puede
ser dividido en dos sub-capas, a saber: la sub-capa de mensajería y la petición /
respuesta sub-capa. La subcapa de mensajería detecta duplicaciones y proporciona
una comunicación fiable a través de la capa de transporte UDP usando retroceso
exponencial desde UDP no tiene un mecanismo de recuperación de errores
incorporado. La sub-capa de petición / respuesta en el otro lado maneja las
Instituto de Ingenieros Eléctricos y Electrónicos ( IEEE) y el Instituto Europeo de
comunicaciones de reposo. Coap utiliza cuatro tipos de mensajes: con fi rmable, no con
Estándares de Telecomunicaciones ( ETSI). Tabla III, proporciona un resumen de los
fi rmable, reset y de acuse de recibo. Fiabilidad de coap se logra mediante una
más prominentes protocolos definida por estos grupos. En este trabajo, clasificamos los
combinación de con fi rmable y no con fi mensajes rmable. También emplea cuatro
protocolos de la IO en cuatro grandes categorías, a saber: los protocolos de aplicación,
modos de respuestas como se ilustra en la Fig. 6. El modo de respuesta separada se
protocolos de descubrimiento de servicios, protocolos de infraestructura y de otro tipo en
utiliza cuando el servidor tiene que esperar un tiempo específico antes de responder al
los protocolos influyentes. Sin embargo, no todos estos protocolos tienen que ser
cliente. En el modo de respuesta rmable no con fi del COAP, el cliente envía los datos
agrupados juntos para ofrecer una aplicación de la IO dado. Por otra parte, en base a la
sin esperar una ACKmessage, mientras que los ID de mensaje se utilizan para detectar
naturaleza de la aplicación de la IO, puede no ser necesaria algunas normas para ser
duplicados. El servidor responde con un mensaje RST cuando los mensajes se pierden
apoyada en una aplicación. En las siguientes subsecciones, se proporciona un resumen
o se producen problemas de comunicación. COAP, como en HTTP, utiliza métodos
de algunos de los protocolos comunes en estas categorías y su funcionalidad principal.
tales como GET, PUT, POST y DELETE para lograr crear, recuperar, actualizar y
eliminar (CRUD). Por ejemplo, el método GET puede ser utilizado por un servidor para
preguntar la temperatura del cliente utilizando el modo de respuesta en cascada. El
cliente envía de nuevo la temperatura si existe; de lo contrario, responde con un código
de estado para indicar que no se encuentra la información solicitada. Coap utiliza un
A. protocolos de aplicación formato simple y pequeña para codificar mensajes. La parte fija primero y fi de cada
mensaje es de cuatro bytes de cabecera. Entonces puede aparecer un valor de
1) Protocolo de Aplicación constreñido (COAP): El IETF constreñido RESTful
contadores cuya va de cero a ocho bytes de longitud. El valor del testigo se utiliza para
Environments (núcleo) grupo de trabajo creado coap, que es un protocolo de capa de
correlacionar las solicitudes y respuestas. Las opciones y la carga útil son los siguientes
aplicación [64], [65] para aplicaciones de IO. El COAP define un protocolo de
campos opcionales. Un mensaje típico coap puede ser de entre 10 a 20 bytes [67]. El
transferencia de banda basado en Transferencia de estado representacional ( REST) ​en la
formato de mensaje de los paquetes de coap se representa en la Fig. 7 [64].
parte superior de funcionalidades HTTP. RESTO representa una manera más sencilla
para el intercambio de datos entre clientes y servidores a través de HTTP [66]. RESTO
puede ser visto como un protocolo de conexión cacheables que se basa en la
arquitectura cliente-servidor sin estado. Se utiliza en aplicaciones de red móvil y social y
que elimina la ambigüedad mediante HTTP obtener, POST, PUT, y borrar métodos. REST
permite a los clientes y servidores para exponer y servicios consumeweb como el Simple
Object Access Protocol (SOAP), pero en una forma más fácil utilizando uniformes de
Los campos de la cabecera son los siguientes: Ver es la versión del COAP, T es
recursos los identificadores (URI) como sustantivos y HTTP GET, POST, poner, y borrar métodos
el tipo de transacción, OC es recuento de Opción y código representa el método de
como los verbos. RESTO no requiere XML para el intercambio de mensajes. A diferencia
solicitud (1-10) o código de respuesta (40 a 255). Por ejemplo, el código para GET,
de REST, coap está obligado a UDP (no TCP) por defecto que hace que sea más
POST, PUT y DELETE es 1, 2, 3, y 4, respectivamente. El ID de transacción en la
adecuado para las aplicaciones de la IO. Por otra parte, coap modi fi ca algunas
cabecera es un único er fi identi para hacer coincidir la respuesta.
funcionalidades HTTP para cumplir con los requisitos de la IO, tales como bajo consumo
de energía y operación en presencia de pérdidas y enlaces ruidosos. Sin embargo, desde
Algunas de las características importantes proporcionadas por coap incluyen [65], [68]:
COAP ha sido diseñado basado en REST, la conversión entre estos dos protocolos en
proxies REST-COAP es sencillo. La funcionalidad general del protocolo coap se
demuestra en la Fig. 5. • observación de recursos: suscripciones a la carta para monitorear los recursos
de interés mediante publicación / suscripción mecanismo.

• el transporte de recursos por bloques: Capacidad para intercambiar datos de

transceptor entre el cliente y el servidor sin
2354 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 4, CUARTO TRIMESTRE 2015

Fig. 6. tipos de mensajes coap [64]. (A) Con fi rmable. (B) para no con fi rmable. (C) es llevada a cuestas respuestas. (D) la respuesta independiente.

Fig. 7. coap formato de mensaje.

la necesidad de actualizar los datos enteros para reducir la sobrecarga de

comunicación.
• descubrimiento de recursos: Servidor utiliza caminos URI conocidos a partir de los campos

de enlace web en formato de enlace de núcleo para proporcionar la localización de recursos

para el cliente. Fig. 8. La arquitectura de MQTT.

• Interactuar con HTTP: La flexibilidad de la comunicación con varios
dispositivos porque la arquitectura REST común permite coap para
interactuar fácilmente con HTTP a través de un proxy.

• Seguridad: COAP es un protocolo seguro, ya que se construye en la parte superior de seguridad

datagrama capa de transporte ( DTLS) para garantizar la integridad y la
confidencialidad de los mensajes intercambiados.

Como un ejemplo de cómo un protocolo de aplicación funciona en un entorno IO,

proporcionamos un código de ejemplo en [69]. Dado que el servicio en la nube para este Fig. 9. publicación / suscripción proceso utilizado por MQTT [70].

proyecto, Nimbits, no es compatible con coap Actualmente, se utiliza REST HTTP para
integrarse con Nimbits.
2) Message Queue Telemetry Transport (MQTT): MQTT es un protocolo de
mensajería que se introdujo por Andy StanfordClark de IBM y Arlen pinza de
Arcom (ahora Eurotech) en 1999 y fue estandarizado en 2013 en OASIS [70].
MQTT apunta a la conexión de dispositivos y redes integrados con aplicaciones
y middleware. La operación de conexión utiliza un mecanismo de
encaminamiento (uno-a-uno, uno-a-muchos, muchos-a-muchos) y permite
MQTT como un protocolo de conexión óptima para la IO y M2M.
MQTT utiliza el patrón de publicación / suscripción para proporcionar transición flexibilidad
y simplicidad de aplicación, como se representa en la Fig. 8. También, MQTT es adecuado
para dispositivos de recursos limitados que utilizan enlaces de ancho de banda no fiables o
bajas. MQTT se construye en la parte superior del protocolo TCP. Se entrega los mensajes a
través de tres niveles de QoS. Existen dos principales especificaciones para MQTT: v3.1
MQTT y MQTT-SN [71] (anteriormente conocido como MQTT-S) V1.2. Este último se definió
especí fi camente para redes de sensores y define un mapeo de UDP MQTT y añade soporte
para el corredor de nombres de los temas de indexación. Las especificaciones proporcionan
tres elementos: la semántica de conexión, enrutamiento y de punto final.
MQTT simplemente consta de tres componentes, abonado, editor, y el corredor. Un
dispositivo interesados ​registraría como suscriptor de temas especí fi cos con el fin de
que sea informado por el corredor cuando los editores publican temas de interés. El
editor actúa como un generador de datos interesantes. Después de eso, el editor
transmite la información a través del corredor de las entidades interesadas (abonados).
Por otra parte, el corredor de seguridad logra mediante la comprobación de
autorización de los editores y los suscriptores [71]. Numerosas aplicaciones utilizan la
MQTT tales como el cuidado de la salud, la vigilancia, contador de energía, y
Facebook noti fi cación. Por lo tanto, el protocolo MQTT representa un protocolo de
mensajería ideal para las comunicaciones de la IO y M2M y es capaz de proporcionar
encaminamiento para, de baja potencia pequeña barato, y dispositivos de memoria
bajas en las redes de ancho de banda vulnerables y bajas. Higo. 9 ilustra el proceso
de publicación / suscripción utilizado por MQTT y Fig. 10 muestra el formato de
mensajes utilizado por el protocolo MQTT [70]. Los dos primeros bytes del mensaje de
cabecera son fi jo. En este formato, el valor del tipo de mensaje campo indica una
variedad de mensajes incluyendo CONNECT (1), CONNACK (2), publicar (3),
SUSCRIPCIÓN (8) y así sucesivamente. El pabellón DUP indica que el masaje se
duplica y que el receptor puede tener
AL-Fuqaha et al .: IOT Encuesta sobre tecnologías de capacitación, protocolos y aplicaciones
Fig. Formato de mensaje 10. MQTT.
Fig. 11. Comunicaciones en XMPP.
recibido antes. Tres niveles de calidad de servicio para el aseguramiento de la entrega de
mensajes Publicar son identificados por el campo Nivel de calidad de servicio. El campo Retener
fi informa al servidor para retener el último mensaje recibido Publicar y lo presentará a los
nuevos suscriptores como un primer mensaje. El restante campo Longitud fi muestra la longitud
restante del mensaje es decir, la longitud de las piezas opcionales.
3) Extensible Messaging and Presence Protocol (XMPP):
XMPP es un estándar IETF mensajería instantánea (IM) que se utiliza para el chat
multipartidista, voz y llamadas de vídeo y telepresencia [72]. XMPP fue desarrollado por la
comunidad de código abierto Jabber para apoyar un protocolo abierto, seguro y libre de
spam descentralizada de mensajería. XMPP permite que los usuarios se comunican entre sí
mediante el envío de mensajes instantáneos en Internet independientemente del sistema
operativo que utilicen. XMPP permite a las aplicaciones de mensajería instantánea para
lograr la autenticación, control de acceso, la medición de la privacidad, hop-by-hop y el
cifrado de extremo a extremo, y la compatibilidad con otros protocolos. La Fig. 11 ilustra el
comportamiento general del protocolo XMPP, en el que las puertas de enlace pueden tender
un puente entre las redes de mensajería externo [73].
Muchas de las funciones XMPP lo convierten en un protocolo preferido por la mayoría de
las aplicaciones de mensajería instantánea y relevante en el ámbito de la IO. Se ejecuta a
través de una variedad de plataformas basadas en Internet de forma descentralizada. XMPP
es seguro y permite la adición de nuevas aplicaciones en la parte superior de los protocolos
centrales. XMPP conecta un cliente a un servidor mediante una corriente de estrofas XML.
Una estrofa XML representa una pieza de código que se divide en tres componentes: (vea la
Fig. 12 [72]) mensaje, presencia y iq (info / query). estrofas de mensajes identificar la fuente
(de) y las direcciones de destino (a), los tipos y los ID de XMPP entidades que utilizan un
método push para recuperar los datos. A fi mensaje estrofa lls los campos asunto y el cuerpo
Fi con el título del mensaje y el contenido. Los espectáculos presencia estrofa y fi caciones
ES clientes de las actualizaciones de estado como autorizados. los iq pares estrofa remitentes
de mensajes y receptores.
La comunicación basada en texto en XMPP usando XML impone una bastante
alta sobrecarga de la red. Una solución a este problema consiste en comprimir
flujos XML utilizando EXI [63] que se aborda en [74].
2355
Fig. 12. Estructura de XMPP estrofa.
Fig. 13. publicación / suscripción mecanismo de AMQP.
Fig. Formato de mensaje 14. AMQP.
4) Avanzado Mensaje Queuing Protocol (AMQP): AMQP [75] es un protocolo de capa
de aplicación estándar abierto para la IO centrándose en entornos orientados a mensajes.
Es compatible con una comunicación fiable a través de las primitivas garantía de entrega
de mensajes incluidos en-más-una vez, al menos, una vez y exactamente una vez la
entrega. AMQP requiere un protocolo de transporte fiable como TCP para intercambiar
mensajes.
protocolo de nivel de ningawire fi Byde, las implementaciones AMQP son capaces de
interoperar con otros. Comunicaciones son manejados por dos componentes principales como
se muestra en Fig. 13: intercambios y colas de mensajes. Los intercambios se utilizan para
encaminar los mensajes a las colas apropiadas. Enrutamiento entre intercambios andmessage
colas está basado en unas reglas y condiciones pre-nidas de fi. Los mensajes pueden ser
almacenados colas inmessage y luego ser enviado a los receptores. Más allá de este tipo de
comunicación punto a punto, AMQP también es compatible con el modelo de publicación /
suscripción de comunicación.
AMQP de fi ne una capa de mensajes en la parte superior de su capa de transporte.
capacidades de mensajería se manejan en esta capa. AMQP la define dos tipos de
mensajes: masajes desnudos que son suministrados por el emisor y los mensajes que se
ven en el receptor anotados. En la Fig. 14 se muestra el formato del mensaje de AMQP
[75]. El encabezado en este formato transmite los parámetros de entrega incluyendo
durabilidad, prioridad, tiempo para vivir, primer adquirente, y el recuento de entrega.
2356 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 4, CUARTO TRIMESTRE 2015

Fig. Formato de trama 15. AMQP.

La capa de transporte proporciona los puntos de extensión requerida para la capa

de mensajería. En esta capa, las comunicaciones se frameoriented. La estructura de
tramas AMQP se ilustra en la Fig. 15 [75]. Los primeros cuatro bytes muestran el
tamaño del marco. DOFF (datos de corrección) da la posición del cuerpo en el interior
Fig. 16. El modelo conceptual de DDS.
del marco. El campo Tipo fi indica el formato y el propósito de la trama. Por ejemplo,
0x00 se utiliza para mostrar que la trama es una trama AMQP o código de tipo 0x01
resultados, MQTT entrega los mensajes con un retardo menor que coap cuando la tasa de
representa un marco SASL.
pérdida de paquetes es bajo. Por el contrario, cuando la tasa de pérdida de paquetes es alta,
coap supera MQTT. En caso de mensajes de poco volumen y una tasa de pérdida inferior al
5) Servicio de Distribución de Datos (DDS): Servicio de distribución de datos (DDS) es un
25%, coap supera MQTT en la generación de menos adicional tráfico c. Otro estudio de
protocolo de publicación-suscripción para comunicaciones M2M en tiempo real que ha sido
investigación [79] comparó estos dos protocolos en un entorno de aplicaciones de teléfonos
desarrollado por el Object Management Group (OMG) [76]. A diferencia de otros protocolos
inteligentes y demostró que el uso de ancho de banda de COAP y el tiempo de ida y vuelta son
de aplicación de publicación-suscripción como MQTT o AMQP, DDS se basa en una
más pequeñas que las de MQTT.
arquitectura de corredor-menos y utiliza la multidifusión para traer excelente calidad de
servicio (QoS) y alta confiabilidad a sus aplicaciones. Su corredor-menos de
La comparación de rendimiento entre COAP y HTTP es investigado por el consumo
publicación-suscripción trajes arquitectura bien a las restricciones de tiempo real para
de energía y tiempo de respuesta en [67]. Debido a su cabecera condensada y tamaño
comunicaciones M2M y la IO. DDS es compatible con 23 políticas de QoS mediante el cual
de paquete pequeño, coap ismore e fi ciente de HTPP en tiempo de transmisión y el
una variedad de criterios de comunicación, como la seguridad, la urgencia, la prioridad, la
uso de energía. Los autores en [80] presentan una evaluación de XMPP para verificar
durabilidad, fiabilidad, etc., pueden ser abordados por el desarrollador.
su aplicabilidad a las comunicaciones en tiempo real en la web. Se evaluaron el
rendimiento de XMPPover HTML5WebSocket y sus resultados muestran que XMPP es
una opción e fi ciente para aplicaciones web que requieren la comunicación en tiempo
DDS arquitectura de fi ne dos capas: centrada en los datos
real. La evaluación del desempeño de AMQP y REST se informa en [81]. Para llevar a
PublishSubscribe (EPDC) y Capa Reconstrucción de datos local (DLRL).
cabo su estudio, los autores utilizaron el número medio de intercambiar mensajes entre
DCPS es responsable de entregar la información a los suscriptores. DLRLon
el cliente y el servidor en un intervalo específico para medir el rendimiento. Bajo un
otro lado, es una capa opcional y sirve como la interfaz a las funcionalidades
gran volumen de intercambios de mensajes, AMQP demostró mejores resultados que
de DCPS. Facilita el intercambio de datos distribuidos entre objetos
los servicios web RESTful.
distribuidos [77].
Cinco entidades están involucrados con el flujo de datos en la capa EPDC: (1)
Editorial que difunde datos; y (2) DataWriter que es utilizado por la aplicación
para interactuar con el editor sobre los valores y los cambios de datos específica Una evaluación experimental de dos implementaciones de DDS [77] señala

a un tipo dado. La asociación de DataWriter y editor indica que la aplicación va a que este protocolo escala bien cuando se aumenta el número de nodos.

publicar los datos fi cado en un contexto proporcionado; (3) de abonado que

recibe los datos publicados y los entrega a la aplicación; (4) DataReader que es A lo mejor de nuestro conocimiento, no existe una evaluación completa de todos

empleado por el suscriptor para el acceso a los datos recibidos; y (5) un tema que estos protocolos juntos. Sin embargo, cada uno de estos protocolos pueden realizar

es fi identificado por un tipo de datos y un nombre. Los temas se refieren a bien en escenarios y entornos fi cas. Por lo tanto, no es posible proporcionar una única

DataWriters DataReaders. La transmisión de datos se permite dentro de un DDS receta para todas las aplicaciones de la IO. Tabla IV proporciona una breve

domainwhich es un entorno virtual para la publicación conectado y aplicaciones comparación entre los protocolos comunes de aplicación de la IO. La última columna

de suscripción. La Fig. 16 demuestra la arquitectura conceptual de este protocolo. de la tabla indica el tamaño mínimo de cabecera requerida por cada protocolo.

observaciones: Las evaluaciones por pares y las comparaciones de estos protocolos se

B. Protocolos de descubrimiento de servicios
han reportado en la literatura. Por ejemplo, [78] compara el rendimiento de MQTT y coap en
términos de retardo de transmisión de extremo a extremo y la utilización de ancho de banda. La alta escalabilidad de la IO requiere un mecanismo de gestión de
Sobre la base de su recursos que es capaz de registrar y descubrir recursos
AL-Fuqaha et al .: IOT Encuesta sobre tecnologías de capacitación, protocolos y aplicaciones
TABLA IV
do OMPARACIÓN B NTRE LA IOTA PLICACIÓN P ROTOCOLS
Fig. 17. Solicitud / Respuesta en el protocolo mDNS.
y servicios en un auto-sido con fi gurado, e fi ciente, y de manera dinámica. Los
protocolos más dominantes en esta área son multicast DNS (mDNS) y Descubrimiento
de servicio DNS (DNS-SD) que se puede descubrir recursos y servicios ofrecidos por los
dispositivos IO. Aunque estos dos protocolos han sido diseñados originalmente para
dispositivos resourcerich, hay estudios de investigación que se adaptan versiones ligeras
de ellos para entornos de IO [82], [83].
1) Multicast DNS (mDNS): Un servicio de base para algunas aplicaciones de la IO como
el chat es de resolución de nombres. mDNS es un servicio de tal manera que puede realizar
la tarea de servidor DNS unicast [84]. mDNS es flexible debido al hecho de que el espacio
de nombres DNS se utiliza localmente, sin tasas adicionales o con fi guración. mDNS es
una opción apropiada para dispositivos embebidos basados ​en Internet, debido a los
hechos que a) No hay necesidad de reconfiguración manual de ficción o administración
adicional para gestionar los dispositivos; b) Es capaz de funcionar sin la infraestructura; y c)
Es capaz de seguir trabajando si el fallo de la infraestructura pasa.
mDNS indaga nombres mediante el envío de un mensaje de multidifusión IP para todos los
nodos en el dominio local, como se muestra en la Fig. 17. Por esta consulta, el cliente pide a
los dispositivos que tienen el nombre dado a contestar de nuevo. Cuando el equipo de destino
recibe su nombre, multicasts un mensaje de respuesta que contiene la dirección IP. Todos los
dispositivos en la red que obtienen el mensaje de respuesta actualicen su caché local utilizando
el nombre y la dirección IP dada. Un ejemplo práctico que utiliza el descubrimiento de servicios
mDNS se puede encontrar en [69].
2) Descubrimiento de servicio DNS (DNS-SD): La función de emparejamiento de los
servicios requeridos por los clientes que utilizan mDNS se llama
2357
Fig. 18. El descubrimiento de servicio de impresión por el DNS-SD.
descubrimiento de servicios basado en DNS (DNS-SD). Usando este protocolo, los clientes
pueden descubrir un conjunto de servicios deseados en una red c especificidad mediante el
empleo de mensajes DNS estándar. La Fig. 18 proporciona una ilustración visual de cómo
funciona este protocolo. DNS-SD, como mDNS, es parte de la cero con ayudas fi guración
para conectar máquinas sin administración externa o con fi guración [85].
Esencialmente, DNS-SD utiliza mDNS para enviar paquetes DNS para especí direcciones de
multidifusión fi c a través de UDP. Hay dos pasos principales para procesar Descubrimiento de
servicios: los nombres de host hallazgo de los servicios necesarios, tales como impresoras y
direcciones IP emparejamiento con sus nombres de host mediante mDNS. Encontrar los nombres
de host es importante porque las direcciones IP pueden cambiar, mientras que los nombres no lo
hacen. Los datos adjuntos emparejamiento difusión múltiple de funciones de red como IP y
número de puerto a cada host relacionados. Usando DNS-SD, los nombres de instancia en la red
se puede mantener constante el mayor tiempo posible para aumentar la confianza y la fiabilidad.
Por ejemplo, si algunos clientes conocen y usan una impresora especí fi co de hoy, van a tener la
posibilidad de utilizarlo posteriormente sin ningún problema.
observaciones: IO necesita algún tipo de dependencia architecturewithout en un
mecanismo de con fi guración. En este tipo de arquitectura, dispositivos inteligentes pueden
unirse a la plataforma o dejarlo sin afectar el comportamiento de todo el sistema. mDNS y
DNS-SD puede suavizar esta forma de desarrollo. Sin embargo, el principal inconveniente de
estos dos protocolos es la necesidad de almacenamiento en caché de las entradas de DNS
especialmente cuando se trata de dispositivos con recursos limitados a. Sin embargo, el
momento de la caché para un intervalo específico y ozono que puede resolver este problema.
Bonjour y Avahi dos implementaciones conocidas que cubren ambos mDNS y DNS-SD.
Protocolos C. Infraestructura
1) Protocolo de enrutamiento de la energía baja y con pérdidas Redes
(RPL): El enrutamiento de IETF sobre baja potencia y los enlaces con pérdidas (rollo) grupo de
trabajo estandarizado un protocolo de enlace independiente de enrutamiento basado en IPv6
para nodos de recursos limitados llamados RPL [86], [87]. RPL fue creado para soportar los
requerimientos mínimos de enrutamiento a través de la construcción de una topología robusta a
través de enlaces con pérdidas. Este routingprotocol apoya cmodels fi TRAF simpleandcomplex
como multipunto a punto, punto a multipunto y punto a punto.
ADestinationOrientedDirectedAcyclicGraph (DODAG) representa el núcleo de RPL
que muestra una nodos de enrutamiento diagramof. El DODAG se refiere a un gráfico
acíclico dirigido con una sola raíz, como se muestra en la Fig. 19. Cada nodo en el
DODAG es consciente de sus padres pero no tienen información sobre los niños
relacionados. Además, RPL mantiene al menos un camino para cada nodo de la raíz y el
padre prefiere seguir un camino más rápido para aumentar el rendimiento.
2358
Fig. 19. topología DODAG.
Con el fin tomaintain la topología de enrutamiento y mantener actualizada la
información de enrutamiento, RPL utiliza cuatro tipos de mensajes de control.
El mensaje más importante es objeto de información DODAG (DIO), que se
utiliza para mantener la posición actual (nivel) del nodo, determinar la distancia
de cada nodo de la raíz en base a unos cmetrics especificaciones, y elegir la
ruta padre preferido. El tipo othermessage es DestinationAdvertisementObject
(DAO). RPL proporciona ascendente tráfico c así como el apoyo tráfico hacia
abajo fi c utilizando mensajes DAO por la que unicasts información de destino
hacia los padres seleccionados. El tercer mensaje es información DODAG
Solicitation (DIS) que es utilizado por un nodo de adquirir mensajes DIO desde
un nodo adyacente accesible.
Un DODAG comienza a formarse cuando la raíz, el único nodo que consisten en
la DODAG, comienza a enviar su ubicación a través de mensaje de DIO a todos de
baja potencia con pérdida de red (LIN) niveles. En cada nivel, los routers receptores
registran ruta padre y caminos de participación para cada nodo. A su vez, propagan
sus mensajes DIO y todo el DODAG poco a poco se construye. Cuando se construye
el DODAG, la padres preferida obtenido por un router coloca como ruta
predeterminada hacia la raíz (rutas hacia arriba). La raíz también puede almacenar
los prefijos de destino obtenidos byDIOs de otros routers en sus mensajes DIO tener
rutas ascendentes. Para apoyar rutas descendentes, los routers deben emitir y
difundir DAOmessages por unidifusión a la raíz a través de los padres. Estos
mensajes identifican el nodo correspondiente de una ruta pre fi x, así como la ruta de
cruce.
routers RPL trabajan bajo uno de los dos modos de operación (MOP): Non-almacenar o modos
de almacenamiento. En No Almacenamiento modo, RPL enruta los mensajes se mueven hacia
niveles más bajos a base de enrutamiento de origen IP, mientras que en modo de
almacenamiento, enrutamiento hacia abajo se basa en direcciones IPv6 de destino [88].
El código de ejemplo para la red de sensores inalámbrica presenta en [69] utiliza
ContikiRPL como una implementación del protocolo de RPL para el encaminamiento de los
paquetes.
2) 6LoWPAN: Baja potencia Wireless Personal Area Networks (WPAN), que muchas
comunicaciones de la IO pueden depender tiene algunas características especiales
diferentes de las tecnologías anteriores capa de enlace, como el tamaño del paquete
limitado (por ejemplo, un máximo de 127 bytes para IEEE 802.15.4), varias longitudes de
dirección, y la anchura de banda baja [89] - [91]. Por lo tanto, había una necesidad de
hacer una capa de adaptación que fi ts IPv6 paquetes a los IEEE 802.15.4
especificaciones. El grupo de trabajo IETF 6LoWPAN desarrolló un estándar tal en 2007.
6LoWPAN es la especificación de servicios de mapas
ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 4, CUARTO TRIMESTRE 2015
requerido por el IPv6 sobre WPAN de baja potencia para mantener una red IPv6 [89].
El estándar proporciona compresión de cabecera para reducir la sobrecarga de
transmisión, la fragmentación para cumplir el requisito IPv6 unidad de transmisión
máxima (MTU), y el reenvío de la capa de enlace para apoyar la entrega multi-hop
[91].
Los datagramas encapsulados por 6LoWPAN son seguidos por una combinación de
algunas cabeceras. Estos encabezados son de cuatro tipos que son identificados por dos
bits [89]: (00) 6LoWPAN Header NO, (01) Envío Header, (10) engranan
Direccionamiento, y (11) de fragmentación. Por 6LoWPAN Header NO, se descartarán
los paquetes que no concederá a los 6LoWPAN específico de cationes. La compresión
de cabeceras IPv6 o la multidifusión se realiza mediante la especificación de cabecera de
despacho. La malla cabecera de direccionamiento de identi fi ca aquellos paquetes IEEE
802.15.4 que tienen que ser remitido a la linklayer. Para datagramas cuyas longitudes
exceder un solo IEEE
marco 802.15.4, cabecera de fragmentación se debe utilizar. 6LoWPAN elimina una gran cantidad
de gastos generales de IPv6 de manera tal que una pequeña datagrama IPv6 puede ser enviada
a través de una sola IEEE
802.15.4 hop en el mejor de los casos. También puede comprimir cabeceras IPv6 a dos bytes
[91].
3) IEEE 802.15.4: El protocolo IEEE 802.15.4 se ha creado para especificar un sub-capa
de Control de Acceso al Medio (MAC) y una capa física (PHY) para redes de área privadas
inalámbricas de baja velocidad (LR-WPAN) [33]. Debido a sus especificaciones tales como
bajo consumo de energía, baja velocidad de datos, de bajo costo, y de alto rendimiento
mensaje, que también es utilizado por la IO, M2M, y WSNs. Proporciona una comunicación
fiable, la operabilidad en diferentes plataformas, y puede manejar un gran número de nodos
(aproximadamente 65 k). También proporciona un alto nivel de servicios de seguridad,
encriptación y autenticación. Sin embargo, no provideQoS garantías. Este protocolo es la
base para el protocolo ZigBee, ya que ambos se centran en ofrecer servicios de baja
velocidad de datos en dispositivos de potencia limitada y construyen una pila completa de
protocolos de red para redes inalámbricas de sensores.
IEEE 802.15.4 es compatible con tres bandas de canal de frecuencia y utiliza un método
de espectro ensanchado de secuencia directa (DSSS). Sobre la base de los canales de
frecuencia utilizados, la capa física transmite y recibe datos a través de tres velocidades de
datos: 250 kbps a 2,4 GHz, 40 kbps a 915 MHz, y 20 kbps a 868 MHz. Las frecuencias más
altas y las bandas más anchas proporcionan un alto rendimiento y baja latencia mientras que
las frecuencias más bajas proporcionan una mejor sensibilidad y cubren distancias más
grandes. Para reducir las colisiones potenciales, IEEE 802.15.4 MAC utiliza el protocolo
CSMA / CA.
El estándar IEEE 802.15.4 es compatible con dos tipos de nodos de red: completa
Aparatos y reducción de la función. los dispositivo de función completa ( FFD) puede servir
como una área de trabajo personal ( PAN) coordinador o simplemente como un nodo normal.
Un coordinador es responsable de la creación, control y mantenimiento de la red. FFDs
pueden almacenar una tabla de enrutamiento dentro de su memoria y poner en práctica un
MAC completa. También pueden comunicarse con cualquier otro dispositivo utilizando
cualquier topología disponible como se ve en la Fig. 20. La dispositivos de función reducidas
( RFD), por otra parte, son muy simples nodos con recursos restringidos. Sólo pueden
comunicarse con un coordinador, y se limitan a una topología en estrella.
topologías estándares para formar IEEE 802.15.4 redes son estrella, peer-to-peer
(malla), y cluster-árbol (Ver Fig. 20). La topología en estrella contiene al menos un
FFD y algunos RFDs. El FFD que trabaja como coordinador de PAN debe estar
ubicado en el centro de la topología y tiene como objetivo gestionar y controlar todos
los demás
AL-Fuqaha et al .: IOT Encuesta sobre tecnologías de capacitación, protocolos y aplicaciones
Fig. 20. IEEE802.15.4topologies [33]. (una estrella. (B) Peer-to-peer. (C) Cluster-árbol.
los nodos en la red. La topología de punto a punto contiene un coordinador de
PAN y de otros nodos se comunican entre sí en la misma red o a través de nodos
intermedios, a otras redes. Una topología de clúster de árbol es un caso especial
de la topología peerto-peer y consta de un coordinador de PAN, una cabeza de
racimo y linfáticos normales.
4) Bluetooth Low Energy: Bluetooth baja energía (BLE) o Bluetooth inteligente utiliza
un radio de corto alcance con una cantidad mínima de energía para funcionar durante
más tiempo (incluso años) en comparación con sus versiones anteriores. Su rango de
cobertura (unos 100 metros) es diez veces mayor que la de los clásicos Bluetooth
mientras que su latencia es 15 veces más corto [92]. BLE puede ser operado por una
potencia de transmisión entre 0.01 mW a 10 mW. Con estas características, BLE es un
buen candidato para aplicaciones de IO [93].
El estándar BLE se ha desarrollado rápidamente por los fabricantes de teléfonos
inteligentes y ya está disponible en la mayoría de modelos de teléfonos inteligentes. La
viabilidad del uso de esta norma se ha demostrado en comunicaciones de vehículo a
vehículo [92], así como las redes de sensores inalámbricas [94]. En comparación con
ZigBee, BLE es más e fi ciente en términos de consumo de energía y la relación de energía
de transmisión por bit transmitido [95].
pila de red de BLE es como sigue: En el nivel más bajo de la pila de BLE hay una
capa física (PHY) que transmite y recibe bits. Durante el PHY, la capa de enlace
includingmediumaccess servicios, establecimiento de la conexión, el control de
errores y control de flujo se proporcionan. A continuación, el control de enlace lógico
y protocolo de adaptación (L2CAP) proporciona multiplexación para los canales de
datos, la fragmentación y reensamblaje de paquetes más grandes. Las otras capas
superiores son protocolo Attribute Genérico (GATT), que proporciona la recogida de
datos e fi ciente de los sensores, y de acceso genérico Pro fi le (GAP) que permite la
solicitud de con fi guración y funcionamiento en diferentes modos como la publicidad
o de exploración, y la iniciación de conexión y la gestión [95 ].
BLE permite que los dispositivos funcionan como maestros o esclavos en una topología en
estrella. Para el mecanismo de descubrimiento, los esclavos envían anuncios sobre uno o más
de los canales dedicados Publicidad. Para ser descubierto como un esclavo, estos canales son
explorados por el maestro. Excepto por el momento en el que dos dispositivos están
intercambiando datos, que están en modo de reposo durante el resto del tiempo.
2359
Fig. 21. sistema RFID.
5) EPCglobal: El Código Electrónico de Producto (EPC) es un número de identi fi
cación única que se almacena en una etiqueta RFID y se utiliza básicamente en la
gestión de la cadena de suministro para identificar artículos. EPCglobal como la
organización original responsable del desarrollo de la EPC, gestiona la tecnología y los
estándares EPC y RFID. La arquitectura subyacente utiliza tecnologías RFID basados
​en Internet junto con etiquetas RFID y lectores baratas para compartir información de
producto [96]. Esta arquitectura es reconocida como una técnica prometedora para el
futuro de la IO debido a su apertura, la escalabilidad, la interoperabilidad y la fiabilidad
más allá de su apoyo a los requisitos principales de la IO tales como objetos
identificaciones y descubrimiento de servicios [97].
EPCs son clasificarse en cuatro tipos: de 96 bits, 64 bits (I), 64 bits (II) y 64 bits (III).
Todos los tipos de EPCs 64 bits admiten aproximadamente 16 000 empresas con
identidades únicas y abarcan 1 a 9 millones de tipos de productos y 33 millones de
números de serie para cada tipo. El tipo de 96 bits compatible con aproximadamente 268
millones de empresas con identidades únicas, 16 millones de clases de productos y 68 mil
millones de números de serie de cada clase.
El sistema RFID puede dividirse en dos componentes principales: transpondedor señal de
radio (tag) y lector de etiquetas. La etiqueta consta de dos componentes: un chip para almacenar
la identidad única del objeto y una antena para permitir que el chip para communicatewith el lector
de etiquetas mediante ondas de radio. El lector de etiquetas genera una frecuencia de radio de
campo para identificar los objetos a través de re fl ejadas las ondas de radio de la etiqueta. RFID
funciona enviando el número de la etiqueta para el lector de etiquetas mediante ondas de radio
como se muestra en la Fig. 21. Después de eso, el lector pasa a ese número para una aplicación
informática fi específico llamado el Los servicios objeto de denominación ( ONS). Un ONS se ve
encima de los detalles de la etiqueta de una base de datos, tales como cuándo y dónde fue
fabricado.
Red EPCglobal se puede dividir en cinco componentes: EPC, el sistema de
identificación, EPC middleware, servicios de descubrimiento, y EPC Information Services.
EPC como un número único a los objetos, consta de cuatro partes como se ve en la Fig.
22 [96], [98].
El sistema de ID une las identidades EPC a una base de datos usando un lector de EPC a
través del middleware. El servicio de descubrimiento es un mecanismo de EPCglobal de
encontrar los datos requeridos por las etiquetas utilizando el ONS.
La segunda generación de etiquetas EPC (llamada etiquetas Gen 2), puesto en marcha a
mediados de 2006 tiene como objetivo cubrir globalmente diversos productos de la compañía. Una
etiqueta Gen 2 proporciona mejores servicios para los clientes que la primera generación de
etiquetas (conocido como RFID pasivo) basado en características como: interoperabilidad bajo
objetos heterogéneos,
2360 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 4, CUARTO TRIMESTRE 2015
Fig. 22. EPC partes de etiqueta de 96 bits [96].
TABLA V EPC T AG C
lasses [96]
de alto rendimiento para todas las necesidades, alta fiabilidad, y las etiquetas baratos
y lectores. Las diferentes clases de etiquetas EPC se resumen en la Tabla V.
6) LTE-A (Long Term Evolution-Avanzado): LTE-A abarca un conjunto de
protocolos de comunicación celular que fi cio así forMachine-TypeCommunications
(MTC) y la IO infraestructuras especialmente para las ciudades inteligentes donde se
espera que la durabilidad a largo plazo de la infraestructura [99]. Por otra parte,
supera a otras soluciones celulares en términos de costo de servicio y escalabilidad.
En la capa física, LTE-A utiliza división de frecuencia ortogonal de acceso múltiple
(OFDMA) por el que el ancho de banda de canal se divide en bandas más pequeñas
llamadas bloques de recursos físicos (PRB). LTE-A también emplea una técnica de
espectro ensanchado de múltiples componentcarrier (CC) que permite que tiene hasta
cinco 20 MHz bandas. La arquitectura de LTE-Anetwork se basa en dos partes
esenciales. La primera es theCoreNetwork (CN) que controla los dispositivos móviles y
se ocupa de paquete IP flujos. La otra parte es la Red de Acceso Radio (RAN) que se
ocupa de la comunicación y el acceso de radio inalámbrica y establece el plano de
usuario y protocolos del plano de control. RAN consta principalmente de estaciones base
(también llamados evolvedNodeBs) que están conectados entre sí por la interfaz X2. La
RAN y la CN están conectados a través de la interfaz S1. Los dispositivos móviles o MTC
se pueden conectar a las estaciones de base directamente oa través de la puerta de
enlace MTC (MTCG). También pueden tener una comunicación directa con otros
dispositivos de la MTC.
Sin embargo, este protocolo tiene sus retos, tales como alta congestión de la
red cuando un gran número de dispositivos están accediendo a la red. Otro reto
dispositivos MTC, QoS puede compromisedwhen intentan acceder a la red a través
de la selección eNB orMTCG. Estos problemas se han investigado en [99] junto
con una solución basada en aprendizaje por refuerzo para la selección eNB. En
[100], los autores también analizaron el rendimiento de MTC
communicationswith un queuingmodel así como la selección eNB. Basándose en sus
resultados, cuando theMTCdevices permanecen inactivos durante un tiempo en lugar de
estar activo más tiempo, el rendimiento de theMTC deviceswill ser improveddue para
bajar contención en la red.
7) Z-Wave: Z-Wave como un protocolo de comunicación inalámbrica de bajo consumo
para Home Automation Networks (HAN) se ha utilizado ampliamente en las aplicaciones de
control remoto en casas inteligentes, así como de pequeño tamaño dominios comerciales
[101]. Este protocolo fue desarrollado inicialmente por Zensys (actualmente Sigma Designs)
y más tarde se empleó y mejorado por Alianza Z-Wave. Z-Wave cubre la comunicación de
unos 30 metros de punto a punto y se especi fi ca para aplicaciones que necesitan la
transmisión de datos tan pequeño como control de iluminación, control de electrodomésticos,
energía inteligente y de climatización, control de acceso, control de asistencia sanitaria
portátil, y detección de incendios. Z-Wave opera en bandas ISM (alrededor de 900 MHz) y
permite que la velocidad de transmisión de 40 kbps. Las versiones recientes también
admiten hasta 200 kbps. Su capa MAC beneficios de un mecanismo de evitación de
colisiones. transmisión fiable es posible en este protocolo por los mensajes ACK opcionales.
En su arquitectura, hay controlador y esclavo nodos. Controladores de gestionar los esclavos
mediante el envío de comandos a ellos. Para los fines de encaminamiento, un controlador
mantiene una tabla de toda la topología de red. Enrutamiento en este protocolo se realiza por
el método de enrutamiento de origen en la que un controlador somete la trayectoria dentro de
un paquete.
observaciones: En esta sección, se revisaron algunos protocolos de
infraestructura importantes que son necesarios para establecer la
comunicación subyacente sea necesario por las aplicaciones de la IO. A
continuación, se revisan algunos aspectos e fi ciencia y de rendimiento de
estos estándares y poner de relieve algunos de los estudios de investigación
que evaluaron estos protocolos. En [88], se ha realizado una evaluación de
RPL para las redes de baja potencia y con pérdida en la que varios problemas
son identi fi ed incluyendo: bajo especí fi cación, la incompatibilidad de los
modos de operación en el almacenamiento y no storingmodes, y bucles. Otro
análisis de rendimiento de RPL se informa en [102] que identi fi ca red rápida
puesta en marcha y los retrasos de comunicación acotadas como su eficacia,
mientras que la alta sobrecarga es un inconveniente potencial. [103] También
se ha informado de algunos problemas de falta de fiabilidad con RPL debido a
la falta del conocimiento completo de las cualidades de enlace.
Analizar el rendimiento de 6LoWPAN en redes de sensores inalámbricas [104] utilizando
una comunicación banco de pruebas de punto-a-punto muestra un aumento en el retardo de
ida y vuelta cuando se aumenta el tamaño de la carga útil ICMP. Algunos otros problemas
han sido reportados para una puerta de enlace 6LoWPAN tales como alta tasa de pérdida de
paquetes, y la facilidad de interferencia [105].
Más allá del consumo de energía menor que BLE demostró en comparación
con IEEE 802.15.4 [95], el trabajo en [106] investigaron el comportamiento de
IEEE 802.15.4 IEEE contra 802.11ah (que es un estándar candidato para la IO y
M2M que está actualmente en etapas preliminares) en términos de rendimiento y
uso de energía. Sus resultados muestran que la IEEE 802.11ah logra un mejor
rendimiento de IEEE 802.15.4 en ambos canales en reposo y no inactivos. Por
otro lado, el consumo de energía de la
AL-Fuqaha et al .: IOT Encuesta sobre tecnologías de capacitación, protocolos y aplicaciones
TABLA VI
do ARACTERÍSTICAS DE ROTOCOLS P PHY
IEEE 802.15.4 IEEE supera a la 802.11ah, especialmente en redes densas.
Con el fin de disminuir el número de colisiones en el EPC Gen-2 protocolo y
para mejorar etiqueta identi fi procedimiento de cationes, así, han propuesto
los investigadores a utilizar por división de código de acceso múltiple técnica
(CDMA) en lugar de la dinámica enmarcado ALOHA ranurado técnica [107].
Una evaluación del rendimiento de estas técnicas se ha llevado a cabo en
[108]. Utilizaron el número promedio de peticiones y el número total de bits
transmitidos que se requieren para identificar todas las etiquetas en el sistema
como sus factores de medición. Sus resultados muestran que el número
esperado de consultas para etiqueta identi fi cación utilizando la técnica de
CDMA es menor que el EPC protocolo Gen-2. La razón es que la técnica
CDMA en este caso se reduce el número de colisiones y por lo tanto el número
de consultas.
Z-Wave ha demostrado un rendimiento aceptable y a pesar de ser de alguna
manera más caro que ZigBee, se ha utilizado ampliamente en aplicaciones de
domótica. Además, las aplicaciones de Z-Wave pueden beneficiarse de la
flexibilidad y la seguridad de este protocolo. Su rendimiento general ha informado
que es superior a la actuación de ZigBee [109]. Tabla VI resume las características
principales de los protocolos de capa PHY utilizados en la IO.
D. Otros influyente Protocolos
Más allá de las normas y protocolos que definen un marco operativo para
aplicaciones de IO, hay algunas otras consideraciones como la seguridad y la
interoperabilidad que deben tenerse en cuenta. La explotación de los protocolos y
estándares que cubren dichas consideraciones influyen en la aceptabilidad de los
sistemas de IO.
1) Seguridad: Nuevas características andmechanisms de la IO no puede obtenerse
mediante protocolos de seguridad convencionales que se utilizan en Internet. Los protocolos
de seguridad en Internet están diseñados para trabajar a través de dispositivos con
restricciones de recursos no convencionales como los ordenadores de sobremesa y
portátiles. Por otra parte, la aparición de nuevos protocolos y arquitecturas en apoyo de la
IO apunta a nuevos problemas de seguridad y esta preocupación se debe considerar en
todas las capas de la IO de la aplicación a la infraestructura
2361
capas que incluyen asegurar los datos dentro de los dispositivos de recursos limitados.
Para el almacenamiento seguro de datos, Codo [110] es una solución de seguridad
a nivel del sistema fi l, diseñado para el sistema operativo Contiki. Al almacenar en
caché los datos para el cifrado y el descifrado mayor, Codo podría mejorar el
rendimiento de las operaciones de seguridad. En la capa de enlace, el protocolo de
seguridad IEEE 802.15.4 proporciona mecanismos para proteger la comunicación entre
dos dispositivos vecinos [111]. En la capa de red, IPSec es el protocolo de seguridad
obligatorio para la capa de red IPv6. Una especificación de IPsec para 6LoWPAN se ha
presentado en [112]. Considerando la naturaleza multi-hop y los grandes tamaños de
los mensajes en las redes 6LoWPAN, IPsec presenta la comunicación más e fi ciente de
IEEE
802.15.4 de seguridad [111]. Desde IPSec funciona en la capa de red, puede servir
cualquier capa superior que incluye todos los protocolos de aplicación que la respuesta en
TCP o UDP. Por otro lado, la seguridad de la capa de transporte (TLS) es un protocolo de
seguridad bien conocido que se utiliza para proporcionar la capa de transporte seguro para
las comunicaciones TCP. Su versión contraparte que asegura las comunicaciones UDP se
denomina datagramas de TLS (DTLS).
En la capa de aplicación, no hay muchas soluciones de seguridad y la
mayoría de ellos se basan en los protocolos de seguridad en la capa de
transporte, es decir, ya sea TLS o DTLS. Algunos ejemplos de este tipo de
soluciones que apoyan el cifrado y la autenticación son EventGuard [113] y
QUIP [114]. En consecuencia, la aplicación de protocolos tienen sus propias
consideraciones y métodos de seguridad. [115] presentó esbelta para Secure
coap utilizando una versión comprimida de DTLS y coap. La mayoría de las
soluciones de seguridad MQTT parecen ser los protocolos TLS / SSL
simplemente aprovechando proyecto específico o. subcomité de seguridad
OASIS MQTT está trabajando en un estándar para secureMQTTmessaging
usingMQTT Ciberseguridad marco [116]. XMPP utiliza el protocolo TLS para
asegurar sus corrientes. También utiliza un específico per fi l de autenticación
simple y el protocolo de capa de seguridad (SASL) para autenticar corrientes.
Más allá de los servicios de cifrado y autenticación para las comunicaciones de
la IO, puede haber alguna otra vulnerabilidad a ataques inalámbricos desde dentro
de la red 6LoWPAN y desde Internet. En tales casos, se requieren sistemas de
detección de intrusiones (IDS). [117] investigado el uso de tales sistemas en el
contexto de los entornos de la IO considerando enrutamiento ataques ejecutados
sobre la Contiki OS.
2) Interoperabilidad (IEEE 1905.1): Los diversos dispositivos en entornos de IO se
basan en diferentes tecnologías de red. Por lo tanto, hay una necesidad de
interoperabilidad de las tecnologías subyacentes. El estándar IEEE 1905.1 fue diseñado
para redes domésticas digitales convergentes y tecnologías heterogéneas [118]. Se
proporciona una capa de abstracción que oculta la diversidad de medios de comunicación
topologías de control de acceso tal como se representa en la Fig. 23, mientras que no
requiere cambios en las capas subyacentes. Este protocolo proporciona una interfaz para
las tecnologías de red hogar común de modo que una combinación de enlace de datos y
protocolos de la capa física, incluyendo IEEE 1901 a través de líneas de potencia, WiFi /
IEEE 802.11 sobre las diversas bandas de RF, Ethernet a través de par o fi cables BER
retorcidos, y Moca 1,1 durante cables coaxiales pueden coexistir con otros.
Si bien las normas antes mencionadas ayudan a la IO tomove un paso adelante hacia
la mejora de la calidad de vida, otras preocupaciones
2362 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 4, CUARTO TRIMESTRE 2015

TABLA VII
P ROYECTOS Y R NVESTIGACIÓN A DDRESSING IOTK EY C ESAFÍOS

Fig. 23. Teniendo en cuenta 1905,1 protocolo en pila de red.

al igual que el impacto ambiental de IoTdevices y tecnologías, a gran escala y el

despliegue de sistemas de IO verde [119] permanecen abiertos.

VI. QOS C CRITERIOS, IO C ESAFÍOS

Y F UTURO re IRECTIONS

Al darse cuenta de la visión de la IO no es una tarea fácil debido a los muchos retos
que deben abordarse. Los ejemplos de los desafíos clave incluyen la disponibilidad,
fiabilidad, movilidad, rendimiento, escalabilidad, interoperabilidad, la seguridad, la
gestión y la confianza. Hacer frente a estos retos permite a los proveedores de servicios
y los programadores de aplicaciones para implementar sus servicios e fi ciente. Por
ejemplo, la seguridad y la privacidad juegan un papel significativo en todos los mercados
a nivel mundial debido a la sensibilidad de la privacidad de los consumidores. Además,
la evaluación del rendimiento de los servicios de la IO es un reto clave [120]. La mayoría
de los desafíos fi cados se reportan en las encuestas [3], [7], [8], [121], [122]. Por otra
parte, hay algunos proyectos de investigación como IoT6 [123], RERUM 1 y RELYonIT 2 que
tienen la intención de investigar los problemas y deficiencias de la IO y proporcionar
directrices para las soluciones. En los párrafos siguientes, proporcionamos una breve
discusión de los principales desafíos que enfrentan en las fases de desarrollo y
despliegue de la IO y los esfuerzos y proyectos de investigación pertinentes. Tabla VII
presenta un resumen de los esfuerzos de investigación y proyectos asociados a los
desafíos de la IO en discusión.

B. Confiabilidad

La fiabilidad se refiere al funcionamiento apropiado del sistema en función de su

específica catión [124]. La fiabilidad tiene como objetivo aumentar la tasa de éxito de la
A. disponibilidad prestación de servicios de la IO. Tiene una estrecha relación con la disponibilidad como

La disponibilidad de la IO debe realizarse en los niveles de hardware y por fiabilidad, garantizamos la disponibilidad de información y servicios a través del

software para proporcionar servicios en cualquier momento y en cualquier lugar tiempo. La fiabilidad es aún más crítica y tiene requisitos más estrictos cuando se trata de

para los clientes. Disponibilidad del software se refiere a la capacidad de las la esfera de las aplicaciones de respuesta de emergencia [126]. En estos sistemas, la

aplicaciones de la IO para prestar servicios a todo el mundo en diferentes parte crítica es la comunicación networkwhichmust ser resistente a los fallos con el fin de

lugares simultáneamente. disponibilidad de hardware se refiere a la existencia realizar la distribución de información fiable. La fiabilidad debe ser implementado en

de dispositivos de todo el tiempo que son compatibles con las funcionalidades y software y hardware a través de todas las capas de la IO. Con el fin de tener una e fi

protocolos de la IO. Protocolos tales como IPv6, 6LoWPAN, RPL, coap, etc., ciente la IO, la comunicación subyacente debe ser fiable, ya que por ejemplo, por una

deben estar incrustados dentro de los dispositivos de recursos limitados de percepción poco fiable, recopilación de datos, procesamiento, y la transmisión puede

placa única que proporcionan la funcionalidad de la IO. Una solución a conducir a largos retrasos, pérdida de datos, y las decisiones equivocadas, finalmente,

achievehigh availabilityof IoTservices es proporcionar redundancia para que pueden conducir a situaciones desastrosas y por lo tanto pueden hacer que la IO

dispositivos y servicios [124] críticos. Por otra parte, hay algunos estudios sobre menos fiable [127]. [126] propone un esquema de fiabilidad a nivel de transmisión para

la evaluación y la evaluación de la disponibilidad de las aplicaciones de la IO en reducir al mínimo las pérdidas de paquetes en entornos de IO. Prestación de servicios a

las primeras etapas de diseño del sistema [124], [125]. los dispositivos inteligentes necesitan composición servicio confiable. En [128], [129], los
autores explotan modelo probabilístico control de los métodos para evaluar la fiabilidad y
el coste de la composición de servicios en sistemas de IO.

1http: 2http //ict-rerum.eu/:

//www.relyonit.eu/
AL-Fuqaha et al .: IOT Encuesta sobre tecnologías de capacitación, protocolos y aplicaciones
C. Movilidad
La movilidad es otro desafío para las implementaciones de la IO, porque la
mayoría de los servicios se espera que sea entregado a los usuarios móviles.
Conectar a los usuarios con sus servicios deseados de forma continua mientras
está en movimiento es una premisa importante de la IO. interrupción del servicio
para los dispositivos móviles se puede producir cuando estos dispositivos se
transfieren de una entrada a otra. [129] se propone un esquema de
resourcemobility que soporta dos modos: el almacenamiento en caché y
tunelización para apoyar la continuidad del servicio. Estos métodos permiten que
las aplicaciones accedan a los datos de la IO en el caso de la no disponibilidad
temporal de los recursos. El enorme número de dispositivos inteligentes en
sistemas de IO también requiere algunos mecanismos e fi cientes para la gestión
de la movilidad. Un enfoque viable ha sido presentado en [130]. En este
esquema,
Otro esquema de gestión de la movilidad se propone en [131] en el que la movilidad
de los nodos de sensores, así como la disponibilidad del servicio se dirigen al
proporcionar un mecanismo de gestión de ciclo de vida de servicio distribuido. Esta
técnica controla el ciclo de vida de las instancias de servicio web que representan un
sensor. Internet de vehículos (IOV) como un área emergente de la IO necesita una
atención precisa a los problemas de movilidad. [132] discute varias soluciones que
soportan la movilidad de las redes de vehículo a vehículo. Un mecanismo de movilidad
de grupos de redes ad hoc móviles se presenta en [133] que se inspira de las aves
voladoras en rebaños.
D. Rendimiento
Evaluar el desempeño de los servicios de la IO es un gran reto, ya que depende del
rendimiento ofmany componentes aswell como el desempeño de las tecnologías
subyacentes. El IO, al igual que otros sistemas, tiene que desarrollar y mejorar sus
servicios tomeet requerimientos de los clientes de forma continua. Los dispositivos de la
IO necesitan bemonitored y evaluado para proporcionar thebest posible rendimiento a un
precio asequible para customers.Manymetrics puede ser utilizado para evaluar el
rendimiento de la IO incluyendo la velocidad de procesamiento, velocidad de
comunicación, factor de forma del dispositivo, y el costo.
Evaluación del funcionamiento de los protocolos subyacentes individuales y
tecnologías como BLE [95], IEEE 802.15.4 [95], [111], RFID [120], 6LoWPAN [104],
RPL [88], [102], los protocolos de capa de aplicación [ 67], [78], [79], [81], y QoS 134]
se han reportado en la literatura, pero la falta de una evaluación de desempeño a
fondo para las aplicaciones de la IO es todavía una cuestión abierta [.
Gestión E.
La conexión de los mil millones o billones de dispositivos inteligentes presenta
servicio providerswith problemas enormes tomanage la Falla, con fi guración,
contabilidad, aspectos de seguridad (FCAPS) de estos dispositivos y rendimiento.
Este esfuerzo de gestión hace necesario el desarrollo de nuevos protocolos de
gestión de peso ligero para manejar el potencial pesadilla de gestión que
potencialmente se derivan de la implantación de la IO en los próximos años. La
gestión de dispositivos y aplicaciones de IO puede ser un factor eficaz para el cultivo
de las implementaciones de la IO [135]. Por ejemplo, el control de la comunicación
M2M de la IO objetos es importante asegurarse de toda la conectividad de veces para
proporcionar a la carta
2363
servicios. La Luz-weightM2M (LWM2M) [136] es un estándar que está siendo desarrollado por la Open
Mobile Alliance para proporcionar la interfaz entre los dispositivos M2M y servidores M2M para construir
un esquema agnóstico aplicación para la gestión de una variedad de dispositivos. Su objetivo es
proporcionar aplicaciones M2M con capacidades de gestión remota de dispositivos de máquina a
máquina, servicios y aplicaciones. El protocolo NETCONF luz [137], que es un esfuerzo del IETF para la
gestión de dispositivos comprimidos proporciona mecanismos para instalar, manipular y eliminar la con fi
guración de los dispositivos de red. Es capaz de gestionar una amplia gama de dispositivos de recursos
limitados a resourcerich dispositivos. El MASH [138] Plataforma IO es un ejemplo de una plataforma que
facilita la gestión (seguimiento, control, y con fi guración) de los activos de la IO en cualquier lugar en
tiempo real, utilizando un panel de control IO en los teléfonos inteligentes. El mantenimiento de la
compatibilidad a través de las capas de la IO también necesita ser administrado para mejorar la
velocidad de conexión y para garantizar la prestación de servicios. En [139], los autores proponen un
marco para la gestión de la IO a través del concepto de interceptar intermediario en el que se ejecutan
las tareas DeviceManagement pesados ​sobre los routers de frontera o puertas de enlace de redes
restringidas. El grupo de trabajo de gestión de dispositivos Open Mobile Alliance (OMA) es especificar los
protocolos y mecanismos para la gestión de dispositivos y servicios móviles en entornos con recursos
limitados. los autores proponen un marco para la gestión de la IO a través del concepto de interceptar
intermediario en el que se ejecutan las tareas DeviceManagement pesados ​sobre los routers de frontera
o puertas de enlace de redes restringidas. El grupo de trabajo de gestión de dispositivos Open Mobile
Alliance (OMA) es especificar los protocolos y mecanismos para la gestión de dispositivos y servicios
móviles en entornos con recursos limitados. los autores proponen un marco para la gestión de la IO a
través del concepto de interceptar intermediario en el que se ejecutan las tareas DeviceManagement
pesados ​sobre los routers de frontera o puertas de enlace de redes restringidas. El grupo de trabajo de
gestión de dispositivos Open Mobile Alliance (OMA) es especificar los protocolos y mecanismos para la gestión de disposit
F. Escalabilidad
La escalabilidad de la IO se refiere a la posibilidad de añadir nuevos dispositivos,
servicios y funciones para los clientes sin afectar negativamente a la calidad de los
servicios existentes. La adición de nuevas operaciones y el apoyo a nuevos dispositivos
no es una tarea fácil, especialmente en presencia de diversas plataformas de hardware y
protocolos de comunicaciones. Las aplicaciones de la IO deben ser diseñados desde
cero para que los servicios y operaciones [140] extensibles. Una arquitectura genérica IO
se ha presentado en [141] mediante la introducción de un daemon la IO que consiste en
tres capas: objeto virtual, objeto virtual compuesto y capa de servicio. La presentación de
estas capas destacados con la automatización, la inteligencia y la configuración zerocon
fi en cada una escalabilidad garantías de objetos, así como la interoperabilidad en el
entorno de la IO. Con el fin de ofrecer servicios escalables [142], propuesto su
plataforma de la IO PaaS través de la entrega del servicio vertical virtual. IO-iCore 3 Es un
trabajo en progreso que tiene como objetivo proporcionar un marco en capas que ofrece
mecanismos escalables para el registro, look-up y el descubrimiento de las entidades,
así como la interoperabilidad entre los objetos.
G. interoperabilidad
la interoperabilidad de extremo a extremo es otro reto para la IO debido a la necesidad
de manejar un gran número de cosas heterogéneas que pertenecen plataformas
todifferent. shouldbe interoperabilidad considerado por los desarrolladores de aplicaciones
y dispositivos IoT fabrica para garantizar la prestación de servicios para todos los clientes,
independientemente de las especificaciones de la hardwareplatformthat que utilizan. Por
ejemplo, la mayoría de los teléfonos inteligentes en la actualidad soportan las tecnologías
de comunicación comunes, tales como WiFi, NFC, y
GSMtoguaranteetheinteroperabilityindifferentscenarios. También,
3http: //www.iot-icore.eu/
2364 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 4, CUARTO TRIMESTRE 2015
los programadores de la IO deben construir sus aplicaciones para permitir la adición de
nuevas funciones sin causar problemas o perder funciones mientras se mantiene la
integración con diferentes tecnologías de comunicación. En consecuencia, la
interoperabilidad es un criterio signi fi cativo en el diseño y la construcción de los servicios
de la IO para satisfacer las necesidades de los clientes [143]. Junto variedad de
protocolos, diferentes interpretaciones de la misma norma implementado por diferentes
partes presenta un desafío para la interoperabilidad [144]. Para evitar tales ambigüedades,
pruebas de interoperabilidad entre diferentes productos en un banco de pruebas como
ETSI Plugtests sería útil. SONDA-IT 4 es un proyecto de investigación que tiene como
objetivo garantizar la interoperabilidad de las soluciones de la IO validados que llevan a
cabo las pruebas de interoperabilidad como COAP, 6LoWPAN, y la IO interoperabilidad
semántica.
H. Seguridad y Privacidad
Seguridad presenta un reto significativo para las implementaciones de la IO debido a la falta de
norma común y la arquitectura de la seguridad de la IO. En las redes heterogéneas como en el caso de
la IO, no es fácil de garantizar la seguridad y privacidad de los usuarios. La funcionalidad principal de la
IO se basa en el intercambio de información entre mil millones o incluso billones de objetos de conexión
a Internet. Uno de los problemas de seguridad abierta en la IO que no ha sido considerado en las normas
es la distribución de las claves entre dispositivos [144]. Objeto inteligente del ciclo de vida del IETF
Arquitectura para entornos con restricciones (SOLACE) inició un trabajo para superar este problema. Por
otro lado, las cuestiones de privacidad y per fi l de las operaciones de acceso entre los dispositivos IO sin
interferencias son extremadamente crítica. Todavía, asegurar el intercambio de datos es necesario para
evitar perder o comprometer la privacidad. El aumento del número de cosas inteligentes que nos rodean
con datos sensibles requiere una gestión de control de acceso transparente y fácil de tal manera que, por
ejemplo, un proveedor solo puede leer los datos mientras que otro se le permite controlar el dispositivo.
En este sentido, algunas soluciones se han propuesto tales como la agrupación de dispositivos
integrados en las redes virtuales y solamente presentes dispositivos deseada dentro de cada red virtual.
Otro enfoque es para apoyar el control de acceso en la capa de aplicación en una base por proveedores
[144]. algunas soluciones han sido propuestas, tales como la agrupación de dispositivos integrados en
las redes virtuales y solamente presentes dispositivos deseada dentro de cada red virtual. Otro enfoque
es para apoyar el control de acceso en la capa de aplicación en una base por proveedores [144]. algunas
soluciones han sido propuestas, tales como la agrupación de dispositivos integrados en las redes
virtuales y solamente presentes dispositivos deseada dentro de cada red virtual. Otro enfoque es para
apoyar el control de acceso en la capa de aplicación en una base por proveedores [144].
observaciones: Aunque una gran cantidad de investigación se ha hecho en la IO, hay
una necesidad de muchos más esfuerzos para que madure. La creciente atención de los
gobiernos y las industrias de esta tecnología disruptiva ha dado lugar a un extenso
researchprojects rangeof. Algunos de los desafíos como la arquitectura y la seguridad
global han llamado mucho la atención, mientras que otros como la disponibilidad, la
fiabilidad y el rendimiento todavía requieren más atención. Algunos estudios de
investigación han llevado a cabo en los laboratorios, mientras que otros todavía están en
la fase de simulación. Esto es natural, ya que estos últimos desafíos necesitan
aplicaciones reales o bancos de pruebas basadas en las tecnologías actuales; algo que no
ha sucedido en un gran escala todavía.
Otro empuje investigación IO naciente es estimar la ubicación de red de los objetos
inteligentes para darse cuenta de los nuevos servicios de localización y contextaware. Los
métodos actuales para la estimación de localización se basan en IP. Sin embargo,
denominado Datos de Redes (NDN) es uno de los candidatos para la denominación de la
infraestructura en el futuro de Internet [145].
4http: //www.probe-it.eu/
VII. segundo YO G re ATA UN NALYTICS, do Y FUERTE
FOG C EN OMPUTING S POYO DE LA IOT Conexión de un gran número de objetos físicos, como
seres humanos, animales, plantas, teléfonos inteligentes, ordenadores, etc. equipados con sensores
para Internet genera lo que se denomina “grandes datos.” Big data necesidades de almacenamiento fi
ciente y e inteligente. Obviamente, los dispositivos conectados necesitan mecanismos para almacenar,
procesar y recuperar datos. Pero los grandes datos es tan grande tal que excede la capacidad de los
entornos de hardware de uso común y herramientas de software para capturar, gestionar y procesarlas
dentro de una ranura de tiempo aceptable. La tecnología emergentes y en desarrollo de la computación
en nube se define por el Instituto Nacional de Normas y Tecnología (NIST) como un modelo de acceso a
una red bajo demanda de fuentes de computación gurable compartida con fi tales como redes,
servidores, almacenes, aplicaciones y servicios. servicios en la nube permiten a los individuos y
empresas para el uso remoto de software de terceros y componentes de hardware [164]. La computación
en nube permite a los investigadores y las empresas de usar y mantener muchos recursos de forma
remota, fiable ya un bajo costo. El IO emplea un gran número de dispositivos embebidos, como sensores
y actuadores que generan grandes volúmenes de datos que a su vez requiere cálculos complejos para
extraer conocimiento [165]. Por lo tanto, los recursos informáticos y de almacenamiento de la nube
presentan la mejor opción para la IO para almacenar y procesar grandes volúmenes de datos. En las
siguientes subsecciones, se discute la relación entre la IO y análisis de grandes volúmenes de datos,
computación en la nube y niebla. El IO emplea un gran número de dispositivos embebidos, como
sensores y actuadores que generan grandes volúmenes de datos que a su vez requiere cálculos
complejos para extraer conocimiento [165]. Por lo tanto, los recursos informáticos y de almacenamiento
de la nube presentan la mejor opción para la IO para almacenar y procesar grandes volúmenes de datos.
En las siguientes subsecciones, se discute la relación entre la IO y análisis de grandes volúmenes de
datos, computación en la nube y niebla. El IO emplea un gran número de dispositivos embebidos, como
sensores y actuadores que generan grandes volúmenes de datos que a su vez requiere cálculos
complejos para extraer conocimiento [165]. Por lo tanto, los recursos informáticos y de almacenamiento de la nube prese
A. El análisis del Big datos en apoyo de la IO
lo que hace big Data un activo importante para las empresas es que hace
posible la extracción de la analítica y en consecuencia el conocimiento, por el
cual una empresa puede lograr una ventaja competitiva. Hay algunas
plataformas para el análisis de datos grandes como Apache Hadoop y SciDB.
Sin embargo, estas herramientas son apenas lo suficientemente fuerte como
para las necesidades de grandes volúmenes de datos de la IO [166]. La cantidad
de datos IO generalmente es demasiado grande para ser alimentados y
procesados ​por las herramientas disponibles. En apoyo de la IO, estas
plataformas deben trabajar en tiempo real para servir a los usuarios fi ciente. Por
ejemplo, Facebook se ha utilizado una versión mejorada de Hadoop para
analizar mil millones de mensajes al día y ofrecer estadísticas en tiempo real de
las acciones del usuario [167]. En términos de recursos,
En lugar de proporcionar especí fi análisis Solicitud C IO necesita un gran analítica
de datos común platformwhich puede ser entregado como un servicio a las aplicaciones
de la IO. Tal servicio analítico no debe imponer una sobrecarga considerable en el
ecosistema global IO.
Una investigación reciente ha propuesto un servicio de análisis de datos grandes tales IO
conocido como TSaaaS el uso de análisis de datos de series de tiempo para llevar a cabo la
minería patrón sobre una gran cantidad de datos de sensor recogidos [169]. Su servicio analítico
se basa en el servicio de base de datos de series de tiempo y es accesible por un conjunto de
interfaces REST. Sus evaluaciones muestran que TSaaaS puede realizar el patrón busca más
rápido que los sistemas existentes. También informaron de que se necesitaba 0,4% del volumen
de datos original como el espacio superior para el almacenamiento de índice del proveedor de
servicios.
Una solución viable para grandes datos IO es hacer un seguimiento de sólo sólo los datos
interesantes. enfoques existentes pueden ayudar en este
AL-Fuqaha et al .: IOT Encuesta sobre tecnologías de capacitación, protocolos y aplicaciones 2365

campo como análisis principio componente (PCA), la reducción de patrón, la reducción de TABLA VIII
IOTC P ruidoso LATFORMS y T HEIR C ARACTERÍSTICAS
dimensionalidad, la selección de características, y métodos de computación distribuida
[166].
Un caso de uso que ilustra el uso de análisis de tráfico c en el contexto de la IO
se presenta en la Sección IX-B.

B. Cloud Computing para la computación en la nube IO ( CC) ofrece un mecanismo

newmanagement
para grandes volúmenes de datos que permite el tratamiento de datos y la extracción de un

valioso conocimiento de ella.

El empleo de CC para la IO no es una tarea fácil debido a los siguientes

desafíos:
• Sincronización: vendedores Synchronizationbetweendifferentcloud presenta un desafío

para proporcionar servicios en tiempo real ya que los servicios se basan en la parte

superior de varias plataformas en la nube.

• Normalización: StandardizingCC también presenta un reto significativo para los

servicios basados ​en la nube de la IO debido tener que interactuar con los
diversos proveedores.
• Equilibrio de: Haciendo un balance entre los entornos de servicio en la nube
y los requisitos generales de la IO presenta otro reto debido a las diferencias • Con el apoyo de muchos fabricantes de equipos originales (OEM)
en la infraestructura. como ARexx, Nanode, OpenGear, Arduino y mbed.
• Confiabilidad: La seguridad de los servicios basados ​en la nube de la IO
presenta otro reto debido a las diferencias en los mecanismos de seguridad
Como otro ejemplo, Nimbits es una plataforma de código abierto como servicio (PaaS)
entre los dispositivos IO y las plataformas en la nube.
que conecta dispositivos integrados inteligentes para la nube [173]. También lleva a cabo
el análisis de datos en la nube, genera alertas, y se conecta con las redes sociales y hojas
• Administración: La gestión de sistemas de IO CC y también es un factor difícil
de cálculo. Por otra parte, se conecta a sitios web y puede almacenar, compartir y
debido al hecho de que ambos tienen diferentes recursos y componentes.
recuperar los datos de sensores en varios formatos, incluyendo numérico, basado en
texto, GPS, JSON o XML. Para el intercambio de datos o mensajes, XMPP es un servicio
• Mejora: La validación de los servicios basados ​en la nube de la IO es necesario
integrado en Nimbits. El núcleo de Nimbits es un servidor que proporciona servicios web
garantizar que proporciona buenos servicios que satisfagan las expectativas de los
REST para el registro y la recuperación de datos en bruto y procesados.
clientes.

IO puede utilizar numerosos nube platformswith diferentes capacidades y fortalezas

como ThingWorx, OpenIoT, la nube de Google, Amazon, GENI, etc. Por ejemplo,
Tabla VIII resume algunas características de varias plataformas en la nube a disposición
Xively (anteriormente conocido como Cosm y Pachube) representa uno de los
del público para la IO (en la tabla, “+” representa el apoyo y “ - ”Es sinónimo de falta de apoyo)
proveedores de servicios de primera aplicación de la IO de alojamiento permite que los
[174]. Las métricas de evaluación incluyen: dispositivos de soporte de puerta de enlace a la
datos del sensor a estar disponible en la web. Xively tiene como objetivo conectar los
reducción de la red de corto alcance y de la red de área amplia, apoyando el descubrimiento,
dispositivos a las aplicaciones de forma segura en tiempo real. Xively proporciona una
la entrega, con fi guración y la activación de aplicaciones y servicios, que proporcionan
plataforma como una solución de servicio (PaaS) para los desarrolladores de
aseguramiento proactivo y reactivo de la plataforma, el apoyo de contabilidad y facturación de
aplicaciones y proveedores de servicios de IO. Es capaz de integrar dispositivos con la
aplicaciones y servicios, y finalmente el apoyo de los protocolos de aplicación estándar.
plataforma por las bibliotecas listas (tales como ARM mbed, Energía Imp y el IOS /
Todas las plataformas de apoyo de detección o dispositivos de accionamiento, una interfaz de
OSX) y facilitar la comunicación a través de HTTP (S), de sockets / WebSocket, o
usuario para interactuar con los dispositivos, y un componente de Web para ejecutar la lógica
MQTT [170]. También podría integrarse con otras plataformas que utilizan las
empresarial de la aplicación en la nube. Además, ninguno de ellos es compatible con el
bibliotecas de Java, JS, Python y Ruby. El estacionamiento automatizado presentado
protocolo de DDS.
en [171],

Algunas de las características que hicieron Xively uno de la

C. Niebla Computing en apoyo de la IO
nube-basedserviceprovidersfor preferida IoTserviceofferingsare [172]:

• de código abierto, libre y fácil de usar, ya que expone interfaces de
programación de aplicaciones (API) accesibles.
• La interoperabilidad con muchos protocolos, entornos y su capacidad para
gestionar sensores en tiempo real y distribuir datos en numerosos formatos
como JSON, XML y CSV.
• Permite a los usuarios visualizar sus datos de forma gráfica en tiempo real usando un sitio web
para monitorear las actividades basadas en sensores de datos. Además, permite a los
usuarios controlar de forma remota mediante la modificación de los sensores de guiones para
recibir una alerta.
Niebla Informática (aka nubecillas o informática borde) puede actuar como un puente
entre los dispositivos inteligentes y de gran escala computación en la nube y servicios de
almacenamiento. A través de la computación en la niebla, es posible extender los servicios de
computación en la nube a los dispositivos de borde de la red. Debido a su proximidad a los
usuarios finales en comparación con los centros de datos en la nube, la computación en la
niebla tiene el potencial de ofrecer servicios que ofrecen un mejor rendimiento de retardo. Se
debe enfatizar aquí que, por lo general hay una diferencia significativa en la escala entre la
niebla y la nube de forma que la
2366 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 4, CUARTO TRIMESTRE 2015

El análisis de ine fi ya no son interesantes. Por otra parte, la tendencia actual es aumentar los
recursos informáticos en apoyo de analítica de grandes datos a través de dispositivos de
borde de la IO.
Un aspecto importante de plataformas en la nube es la capacidad de interactuar con
diferentes protocolos de aplicación. Acloud platformmay tienen diferentes clientes que
utilizan protocolos de aplicación en particular. Si los clientes desean utilizar los servicios de
otros clientes, a continuación, la limitación de la nube que ofrece sólo un protocolo de
aplicación en particular es una barrera para su expansión. Las plataformas en la nube
disponibles casi no admiten todos los protocolos de aplicación estándar, mientras que casi
todos ellos soporte de apoyo. Sin embargo, una solución es utilizar las nubes híbridas. El
proyecto de embalse [176] es una plataforma que tiene como objetivo proporcionar una
arquitectura en la que los proveedores de nube serán capaces de unirse entre sí para hacer
un gran número de soluciones de TI. IoTCloud [177] es otro proyecto que tiene como objetivo
Fig. 24. La función de los recursos de la nube y la niebla en la prestación de servicios de la IO.
proporcionar una plataforma en la nube rendimiento escalable y de alta para la aplicación de
la IO.
nube tiene computacional masiva, almacenamiento y capacidades de comunicación en

comparación con la niebla [175]. La Fig. 24 ilustra los roles que los centros de datos en la nube

y las nubecillas (informática niebla) desempeñan para ofrecer servicios de IO a los usuarios
A través de la computación en la niebla, se propone el uso de dispositivos inteligentes como
finales. operadores de redes móviles son los potenciales proveedores de computación en la
teléfonos móviles o pasarelas residenciales [168]. Sin embargo, el campo de la informática
niebla, ya que pueden ofrecer servicios de niebla como uno de los modelos IaaS, PaaS, SaaS
niebla necesita más atención para resolver otros problemas como la fiabilidad, la movilidad y la
o a los negocios de la empresa, proporcionando servicios a su red de servicio o incluso antena
seguridad de los datos analíticos sobre los dispositivos de borde [178]. En [179], los autores
de telefonía móvil [170].
presentan un modelo de computación en la niebla (Edge Nube) que trata de llevar la información

capacidades de nube céntricas hasta el borde. En este modelo, los centros de datos
Niebla computing puede servir como una opción óptima para los diseñadores de la IO para las
tradicionales soluciones alojadas en la nube que son ideales para grandes cálculos y el
siguientes características:
almacenamiento de propósito general se mejoran los servicios en el borde de la red. Usando
• Ubicación: recursos antiniebla están posicionados entre los objetos inteligentes y los
esta arquitectura proporciona una especie de prestación de servicios con una latencia reducida y
centros de datos en la nube; por lo tanto, proporcionar un mejor rendimiento demora.
ancho de banda mientras se mantiene la resistencia de servicio y localización.

• Distribución: Desde la computación niebla se basa en centros de “micro” con

capacidades de almacenamiento, procesamiento y comunicación limitado en
comparación con la nube, es posible deploymany tales centros “micro” más cerca de
los usuarios finales como su costo es típicamente una fracción pequeña en VIII. T ÉL norte EED PARA segundo ARTA H ORIZONTAL yo NTEGRACIÓN
comparación con la nube centros de datos. segundo NTRE UN OLICITUD L AYER PAG ROTOCOLS

dispositivos IO pueden clasificarse en dos categorías principales; a saber: recursos

• escalabilidad: Niebla permite sistemas de IO para ser más escalable de tal manera
constrainedand dispositivos ricos en recursos aparatos de las marcas de fi ne ricos en
que a medida que aumentan el número de usuarios finales, el número de centros
recursos como los que tienen la capacidad de hardware y software para soportar el conjunto
de niebla desplegados “micro” puede aumentar para hacer frente a la carga
de protocolos TCP / IP. En los dispositivos que soportan el conjunto de protocolos TCP / IP,
creciente. Tal aumento no se puede lograr por la nube porque el despliegue de
aplicaciones de la IO se implementan en la parte superior de una variedad de protocolos de
nuevos centros de datos es el costo prohibitivo.
nivel de aplicación y los marcos que incluye reposo, COAP, MQTT, MQTT-SN,
AMQPandothers.On theother mano, dispositivos que DONOT tienen los recursos necesarios
• Densidad de dispositivos: Niebla ayuda a proporcionar servicios flexibles y
para apoyar TCP / IP no puede interoperar fácilmente con dispositivos ricos en recursos que
replicados.
apoyan el conjunto de protocolos TCP / IP. Por ejemplo, los electrodomésticos y aparatos
• apoyo a la movilidad: recursos de niebla actúan como una nube “móvil” ya que se encuentra
basados ​en microcontroladores deben tener la capacidad de interoperar con otros elementos
cerca de los usuarios finales.
de la IO que son TCP / IP habilitado. Más allá de los problemas de interoperabilidad entre los
• Tiempo real: Niebla tiene el potencial de proporcionar un mejor rendimiento para los
dispositivos que admiten TCP / IP y las que no lo hacen, dispositivos habilitados para TCP / IP
servicios interactivos en tiempo real.
utilizan una variedad de protocolos que conducen a una miríada de problemas de
• Normalización: recursos de niebla pueden interoperatewith varios nube
interoperabilidad que limitan las posibles aplicaciones de la IO. Esta fragmentación entre los
ofrece.
protocolos utilizados para la comunicación dentro ya través de dispositivos con recursos
• En el análisis de fl y: recursos niebla puede realizar la agregación de datos para enviar
limitados y ricos en recursos no se prevé que cambie en el futuro cercano.
datos parcialmente procesados ​en contraposición a los datos en bruto a los centros de datos

en la nube para su posterior procesamiento. Por lo tanto, la computación en la niebla tiene el

potencial de aumentar el rendimiento general de las aplicaciones de la IO, ya que trata de

realizar parte de los servicios de alto nivel que son ofrecidos por la nube dentro de los recursos
locales.
observaciones: En esta sección, se introdujeron tres elementos complementarios a la
IO. En el campo de análisis de datos grandes en apoyo de la IO, las herramientas
analíticas convencionales que se basan en
Este panorama sombrío para la interoperación entre los dispositivos IO pide
una pasarela de protocolo que permite una mejor integración horizontal entre estas
diversas tecnologías. Varios intentos se han hecho en la literatura reciente para
abordar esta cuestión. Paramount entre estos intentos es Ponte [180] que fue
desarrollado inicialmente como QEST [181]. Ponte ofrece uniforme abierta
AL-Fuqaha et al .: IOT Encuesta sobre tecnologías de capacitación, protocolos y aplicaciones
Fig. 25. Los proyectos Eclipse IO.
API para el programador para permitir la conversión automática entre los diferentes
protocolos de aplicación, tales como la IO coap y MQTT. Ponte se desarrolla en el marco
del proyecto Eclipse IO [182], que contiene otros sub-proyectos para facilitar el desarrollo de
soluciones de IO para los consumidores. Otros proyectos son Kura [159], Eclipse SCADA
[183], Eclipse SmartHome [184], y Krikkit [185]. Kura como una plataforma M2Mapplication
se supone proporcionar un recipiente basada en OSGi Java / para aplicaciones M2M que se
ejecutan en pasarelas de servicio. Los requisitos más comunes de M2Mapplications que los
objetivos a Kura cubren son I / O de acceso, servicios de datos, perro guardián,
configuración de red con fi y gestión remota. El enfoque de la SCADA es proporcionar una
manera de conectar diferentes dispositivos industriales a un sistema de comunicación
común. También tiene como objetivo facilitar el post-proceso y visualización de los datos.
Eclipse sugiere proyecto itsSmartHome como marco para la construcción de soluciones
inteligentes para el hogar. La integración de los diferentes protocolos y estándares en un
entorno heterogéneo es uno de sus principales objetivos prometedores. Además, se
pretende llevar un acceso uniforme a los dispositivos subyacentes y para soportar diferentes
tipos de interacciones entre ellos. Sin embargo, el sistema necesita ser ejecutado en
plataformas que se pueden ejecutar una pila de OSGi. Con el fin de superar el problema de
pospuesto procesamiento de datos de la secuencia (tienda primera, analizar más adelante)
en las soluciones de la IO, el proyecto Krikkit viene con una API RESTful que permite a un
usuario o desarrollador para adquirir los datos de interés en dispositivos de borde, tales
como puertas de enlace de sensores . La arquitectura Krikkit utiliza publicación / suscripción
modelo por el cual los datos de la adquisición de reglas o políticas están registrados en los
dispositivos de borde. La Fig. 25 resume estos marcos.
Más allá de los proyectos antes mencionados, hay otros esfuerzos de investigación
académica que proponen soluciones parciales al problema o que han sido diseñados para
aplicaciones o protocolos especí fi cos o la necesidad de hardware específico. Por
ejemplo, los autores en [186] proponen una puerta de enlace para cubrir el hueco entre
ZigBee y protocolos GPRS para facilitar la transmisión de datos entre las redes de
sensores inalámbricos y redes de comunicaciones móviles. Esta arquitectura asume el uso
de protocolos TCP / IP. En [187], una puerta de enlace se propone que es específica para
redes de sensores inalámbricos que utilizan los dispositivos basados ​en TCP / IP. La
arquitectura de pasarela que se propone por [188] también necesita ser ejecutado en un
sistema de cómputo de gran alcance (PC).
El Light-weightM2M (LWM2M) Protocolo [136] whichwas citado antes en este
documento como un estándar DeviceManagement, objetivos
2367
para proporcionar una forma unificada para hacer frente a los dispositivos de manejarlos
thisprotocol remotely.Although es aplicable toCellular, WiFi y WSNdevices, es limitado a
aquellos dispositivos que admiten IP [189].
En [190], en lugar de las pasarelas, los autores proponen una solución para integrar objetos
inteligentes con recursos limitados en el Internet a través de redes virtuales. Este trabajo puede
proporcionar una comunicación de extremo a extremo entre dispositivos, pero la escalabilidad y
la unión a protocolos específicos c son los principales desafíos.
Autores en [191] presentan un modelo de comunicación para soportar múltiples
protocolos en una aplicación de la IO médica. Su propósito es evitar que el conflicto
entre los sistemas de transmisión inalámbrica médicos y aumentar el rendimiento de
estos dispositivos en los hospitales y entornos médicos. Utilizaron la tecnología
definida De fi Radio (SDR) Software como parte de su plataforma de detectar y señales
transformthewireless en el spectrum.Ademo de frecuencia también se presenta en
[192] en el que la tecnología SDR se utiliza para construir una infraestructura de
comunicaciones para aplicaciones de IO.
Se propone un enfoque basado en la creación de redes fi nida por software
para tareas de IO en [193]. En su investigación, los autores desarrollaron un
controlador amiddlewarewith IoTSDN capas tomanage entornos multi-red
dinámicos y heterogéneos.
A partir de los datos anecdóticos que hemos recogido hasta ahora acerca de las diversas
necesidades de las aplicaciones de la IO y las capacidades del hardware subyacente, es
evidente para nosotros que la estrategia utilizada por Ponte a cerrar la brecha entre los
diferentes protocolos de la IO no es su fi ciente y una mayor se necesita una solución
inteligente. Para ser específico, mientras Ponte tiene la capacidad para llevar a cabo
cualquiera a cualquier conversión de protocolo automático de esta conversión tiene un precio
como la comunicación de paquetes subyacente tiende a ser más detallado con el fin de que
sea de aplicación agnóstico. Por otra parte, Ponte tantas otras pasarelas de protocolo que se
han presentado en la literatura asume los dispositivos subyacentes a ser habilitado el
protocolo TCP / IP.
Mientras que esta “talla fi cios para todos” protege a los programadores de tener que
escribir varias instancias de la misma aplicación para soportar diferentes protocolos, el
protocolo underlyingwire no puede ser controlado por el programador y en consecuencia,
conduce a problemas de rendimiento y de ineficiencias. Sin embargo, más importante aún,
los dispositivos con recursos limitados son tratados como ciudadanos de segunda clase y
no se consideran en absoluto en esta solución.
Por lo tanto, wearemotivatedby los siguientes threemainobservations a los contenidos
de la necesidad de un nuevo IoTgateway inteligente:
• Los programadores deben siempre estar en control y deben tener la flexibilidad para
controlar el protocolo de conexión. dispositivos IO pueden ser los recursos limitados
y el uso de mensajería agnóstico aplicación conduce a intercambios de paquetes
innecesarios. Una puerta de enlace inteligente debe permitir a los programadores
para controlar la fi alambre de protocolo de tráfico c según sea necesario para
optimizar el rendimiento en función de las necesidades específicas de la aplicación
dada.
• dispositivos con recursos limitados no deben ser tratados como ciudadanos de
segunda clase. Una pasarela inteligente debe permitir una verdadera
interoperabilidad entre dispositivos con recursos limitados rico en recursos naturales
y.
• ¿Puede la introducción de una pasarela de protocolo en la IO proporcionar una
newopportunity? Una pasarela inteligente debe ser oportunistas para crear
nuevas oportunidades fuera del cuadro sombrío causado por la fragmentación
del mercado entre los protocolos de la IO.
2368 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 4, CUARTO TRIMESTRE 2015
Fig. 26. La arquitectura de una base de reglas de puerta de enlace Inteligente IO.
Sobre la base de las observaciones mencionadas, consideramos que hay una
necesidad de una puerta de enlace inteligente de la IO que ofrece servicios “inteligentes”
que está profundamente reprogramable través de un lenguaje basado en reglas escritas
por el programador. Se debe enfatizar aquí que nuestra propuesta más profunda
re-programación de la pasarela de la IO a través de un lenguaje basado en reglas no
conflicto con los esfuerzos de interoperabilidad y estandarización de gestión actuales. En
realidad, nuestra propuesta complementa el esfuerzo de interoperabilidad en el estándar
IEEE 1905.1 y los esfuerzos de gestión en LWM2M y NETCONF luz.
El concepto de la puerta de enlace propuesto se demuestra en la Fig. 26 [194].
Debemos destacar aquí que la figura ilustra la pila de protocolos que necesita ser
instalado en dispositivos resourceconstrained basado en las tecnologías actuales
vis-à-vis de recursos-constraineddevices que utilizan la puerta de entrada inteligente.
La figura también detalla la secuencia de flujo de paquetes de datos (d1. . .d12, a
continuación, a través de la Data- flujo lógica basada en reglas de la puerta de enlace,
y d13 fi nalmente. . .d22) y la secuencia de flujo de paquetes de gestión (m1. . .m12, a
continuación, a través de la lógica de gestión basada en reglas de la puerta de enlace,
y m13 fi nalmente. . .m22). La lógica de las reglas se aplica a los datos recibidos y los
paquetes de gestión (es decir, d12 y M12 en la Fig. 26) para generar correspondientes
paquetes de datos y de gestión (es decir, d13 y m13 en la Fig. 26). Las normas que
pertenecen a los servicios de gestión y de agregación de datos autónomo puede
resultar en el origen y la transmisión de nuevos datos y paquetes de gestión por la
propia puerta de enlace. Debería ser evidente a partir de la figura que la pasarela
inteligente resultará en una pila de protocolo más ligero que se basa en uIP / lwIP
solamente (sin necesidad de TCP / UDP, DTLS, TLS o otros protocolos de seguridad
en el dispositivo con recursos limitados). El “transporte de la IO” y “Gestión de la IO”
son dos protocolos de peso ligero para encapsular y decapsulate los paquetes de datos
y de gestión, respectivamente. Los servicios de seguridad también pueden ser
delegadas a la puerta de entrada para que la confidencialidad, la autenticidad, y la
integridad tráfico c puede ser intercambiada con la puerta de enlace y no directamente
con los dispositivos de recursos limitados. Apoyando un lenguaje basado en reglas
protegerá a los programadores de tener que escribir varias instancias de la misma
aplicación para apoyar los diferentes protocolos de alambre. Aunque el programador
tendrá
reglas para escribir en un lenguaje de alto nivel para describir las transformaciones que la
pasarela debe realizar para traducir el protocolo de conexión según sea necesario. El
beneficio de este enfoque se deriva de la capacidad del programador para realizar
optimizaciones de protocolo de cable como sea necesario a costa de tener que escribir
normas de alto nivel para describir las transformaciones necesarias. Con el uso de
plantillas estándar de transformación, la mensajería de protocolo de conexión será menor
e fi ciente pero en este caso los programadores no tienen que especificar las reglas que
son específico para su aplicación. En este último caso, el rendimiento del sistema
propuesto será similar a la de Ponte.
La introducción de una entidad de puerta de enlace en el contexto de IoTwill también
instigar la oportunidad de utilizar la puerta de enlace y su profunda re-programación para
la gestión autonómica localizada de los elementos de la IO sin intervención humana. En
escenarios de implementación reales, los nodos de la IO se pueden implementar por los
miles o incluso millones en apoyo de una sola aplicación. Por lo tanto, teniendo Fallo de
autogestión, con fi guración, Contabilidad, capacidades de seguridad (FCAPS)
Rendimiento y es una necesidad.
La mayoría de las aplicaciones de la IO son de bajo precio, pero el gran número de
dispositivos IO que participan en una sola aplicación se traducirá en tener los elementos de la
red para hacer frente a “ratones” flujos. Una pasarela profundamente re-programable también
puede ofrecer una oportunidad para llevar a cabo de datos y flujo de la agregación de limitar el
número de flujos que los elementos de la red tienen que manejar. Por lo tanto, lo que resulta en
grandes ganancias de rendimiento y limitar el número de entradas en las tablas de fluencia de
los elementos de la red de transporte.
Creemos que en el fondo de re-programación de la pasarela de la IO througha lenguaje
basado en reglas canput thegateway inauniqueposition para ofrecer “inteligente”
autonomicmanagement, datos / flujo de agregación,
andprotocoladaptationservices.Thepresenceofmultiple gatewayswithin la IO también puede
ofrecer beneficios únicos para equilibrar el potencialmente enorme carga de la IO entre las
puertas de enlace disponibles.
Con el fin de tener una e fi ciente y mejor- solución fi cio para la conversión de protocolo,
creemos que hay una necesidad de un mecanismo protocolfriendly en el interior del
convertidor de protocolos que puede aumentar la velocidad de conversión. El punto clave
de este mecanismo es una tabla de índice nombre-valor de los datos que se lleva en las
cabeceras opcionales de los diferentes protocolos de aplicación. Cuando un paquete
AL-Fuqaha et al .: IOT Encuesta sobre tecnologías de capacitación, protocolos y aplicaciones
Fig 27. El mecanismo de traductor de protocolo.; (A) ers protocolo de aplicación Headings. (B) conversión
Protocolo.
llega a la puerta de entrada, el convertidor de protocolos examina los títulos
opcionales. Si fi nds una tabla de índice aceptable allí, entonces agarra los datos al
instante de la carga útil y forma un paquete de orientación el protocolo de destino. La
Fig. 27 demuestra (a) el encabezado opcional del protocolo de aplicación, la tabla de
índice y (b) el mecanismo de conversión dentro de la puerta de enlace. Desde la tabla
de índice se almacena como una cabecera opcional, protocolos de aplicación no
podrán utilizar las tablas de índice. En tales casos, la conversión se realiza en la
forma convencional y en consecuencia se necesita tiempo más largo.
En el escenario en el que un paquete que consta de n pares de nombre y valor necesita ser
convertido a partir de un protocolo de origen a un protocolo deseado en el formato convencional,
y puesto que los datos se almacenan en una estructura lineal dentro de la carga útil de cada
paquete, necesitamos O ( n / 2) operaciones para hallar un elemento de datos en la carga útil
antes de insertarlo en el protocolo deseado. Así que tiene n pares nombre-valor, O (n 2) Se
necesitan operaciones para convertir todos los datos dentro de un paquete. Este análisis
también es válido para XMPP en el que se almacenan los datos en las etiquetas XML.
Operaciones de búsqueda e inserción en XML tarda un tiempo lineal. Por lo tanto, la conversión
de / a XMPP toma O (n 2)
también. Por otro lado, si los protocolos de aplicación utilizan la tabla de índice
descrita anteriormente, el tiempo de conversión se reduce a O (n), ya que la posición
de cada elemento de nombre-valor es fácilmente disponible en la tabla de índice.
IX. UN Y OLICITUD S ERVICIO T SE- do ASES
En esta sección, se discuten tres casos de uso de la aplicación para señalar a los lectores
cómo los principales protocolos discutidos en las secciones anteriores encajan juntos para ofrecer
la funcionalidad deseada IoTapplication. Entonces, también ofrecemos dos casos de uso de las
capacidades de servicio de analíticas que pueden ser relevantes para diversas aplicaciones de la
IO.
2369
Esta sección se centrará en la estructura general de las aplicaciones de la IO deseados
y no proporcionará fragmentos de código detallados. Los lectores pueden fi nd código
fuente relevante muestra de la IO en [69] que incluye los siguientes proyectos:
• WSN, que es una simulación de una red de sensores inalámbricos en el que un
nodo receptor, tiene que recibir paquetes frommotes para construir una tabla
local que identi fi ca el nodo de anclaje más cercano a cada nodo no ancla en la
red. Las normas que se han empleado en este proyecto son IPv6 y RPL.
• Descubrimiento de servicios, que es una implementación y simulación de un protocolo
de descubrimiento de servicios para redes de sensores inalámbricos que utilizan
multicast DNS (mDNS).
• Cloud Computing, en el que varios motas de enviar a sus valores (lecturas
de temperatura) a la nube Nimbits (http: // cloud.nimbits.com) utilizando el
método HTTP REST. Hicimos el código fuente de estos proyectos a disposición
del público en GitHub para los lectores que prefieren ir a través de ejemplos
prácticos. Estos ejemplos se han implementado con Contiki / cooja para que
sean accesibles en el aula por los profesores y estudiantes. Los ejemplos
también se pueden ejecutar en motas reales que soportan Contiki. La guía para
utilizar estos ejemplos está disponible en la página wiki del proyecto.
A. Aplicación casos de uso
Las tres aplicaciones que nos centraremos en esta sección son un sistema de
enfermería del paciente monitoreo en casa, un sistema para el control y mitigación de
los trastornos de la alimentación, y un sistema de navegación interior para las personas
ciegas y con discapacidad visual. El siguiente detalle párrafos la arquitectura general de
estas aplicaciones.
1) Nursing Home Sistema de monitorización de pacientes: En este caso de uso de
aplicaciones, estamos interesados ​en la recopilación de mediciones de signos vitales de los
pacientes y la entrega a múltiples estaciones de enfermería. También estamos interesados ​en la
implementación de un sensor de luz y un sensor de puerta para controlar el nivel de actividad de
los pacientes y potencialmente identificar a los que sufren de depresión si se asume que los
pacientes tienen habitaciones privadas.
Para implementar esta funcionalidad de forma rápida, un desarrollador de
aplicaciones puede elegir los SmartThings relevantes o sensores BITalino que utilizan
ZigBee o Z-Wave para la comunicación para recoger las mediciones senor en las
plataformas SmartThings y utilizan su API para construir una aplicación los tirones de
los datos recogidos en el estaciones de enfermería.
Si bien el enfoque SmartThings descrito anteriormente se puede implementar de
forma rápida, un enfoque personalizado que utiliza sensores USB Phidgets en
conjunctionwith un microcontrolador o procesador único basado Ordenador de a bordo
(SBC) puede proporcionar una mejor opción de integrar componentes de hardware y
software de diferentes proveedores. Estos nodos sensores pueden utilizar WiFi o IEEE
802.15.4 para comunicar sus mediciones. En este escenario, una aplicación
developermight primero descargar e instalar un corredor MQTT de código abierto como
mosquitto. Entonces, una implementación de código abierto del protocolo MQTT como
Eclipse OPS podría ser usado para implementar un cliente que se ejecuta en el SBC
asociado con los sensores USB Phidgets la recogida de los datos de los signos vitales, la
luz y sensor de la puerta. Los clientes MQTT publican los datos de los sensores al
corredor MQTT. A su vez, los servidores conectados a la MQTT
2370 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 4, CUARTO TRIMESTRE 2015
estaciones de enfermería suscribirse al corredor MQTT en busca de mensajes de interés.
Si se necesita la colaboración entre sensor, un protocolo de enrutamiento como RPL puede
ser utilizado entre los sensores para permitir la entrega de saltos múltiples de datos entre
sensores.
Con el fin de allowdoctors acceder a los datos recogidos de forma remota, una aplicación
móvil puede ser desarrollado para conectar con el corredor MQTT para suscribirse a los
mensajes que tienen los temas de interés. El agente puede ser expuesto públicamente en
Internet detrás de un cortafuego a través de un LTE-A conexión utilizando 819 M2M puerta
de enlace de Cisco.
2) Monitoreo y Mitigación de los TCA: Ahora, supongamos que queremos
extender la aplicación para permitir que los pacientes con temblores esenciales o la
enfermedad de Parkinson para comer sin derramar comida. En este escenario, un
guante puede ser equipado con pequeños motores MEMS vibrantes para
contrarrestar la inestabilidad movimiento de la mano medida por los acelerómetros.
En esta aplicación, los sensores de acelerómetro y vibratingmotors tienen que
comunicarse con el mínimo retraso posible entregar la funcionalidad requerida. Por
lo tanto, el protocolo DDS sería la mejor opción para este escenario para permitir la
comunicación directa mínima entre los acelerómetros y los motores vibratorios
MEMS sin la participación del corredor. Con el fin de integrar esta funcionalidad con
las estaciones de enfermería, una puerta de entrada necesita ser desplegado para
traducir los mensajes de DDS a MQTT para permitir dicha integración.
La expansión de las capacidades de las soluciones basadas MQTT se puede hacer
fácilmente como nuevos sensores y aplicaciones móviles / fijos pueden desarrollarse para
publicar y / o suscribirse a los mensajes de interés a través del corredor. Un despliegue
agente individual puede sufrir de fallas o cuellos de botella en el caso de un gran número de
conexiones del sensor y la aplicación del cliente. En tales casos, se necesita una solución
que involucra múltiples corredores y la topología y el cliente asignación es estos casos se
conviertan en problemas interesantes.
3) Dentro de la puerta Sistema de navegación para ciegos y personas Im-
Las personas emparejadas: Supongamos que queremos extender la aplicación adicional
de utilizar una constelación de decaWave o Nanotron transceptores para proporcionar
servicios de Localización en tiempo real (RTLS) a los usuarios. En este caso, un
dispositivo de usuario puede utilizar mDNS para conectarse a un servidor local, obtener un
token de autenticación para acceder a los servicios de RTLS. El RTLS linfáticos mismos
podrían utilizar DDS para el intercambio oportuno de paquetes de datos. Los nodos RTLS
pueden entonces transmitir sus datos recogidos al servidor de RTLS locales a fin de que
para estimar la ubicación actual del usuario. El servidor de RTLS local puede superponer la
ubicación en un fl oorplan obtenido a partir de un servidor conectado a Internet para
proporcionar información de navegación táctil a los usuarios permitiéndoles evitar los
obstáculos y otros movimientos físicos constriñe reportados anteriormente por otros
usuarios del sistema.
La Fig. 28 proporciona un diagrama de bloques de los casos de uso de tres
aplicaciones discutidos en esta sección. La figura ofrece una ilustración visual de cómo
los protocolos de capa de aplicación discutidos en las secciones anteriores encajan juntos
para proporcionar la funcionalidad global aplicación IO.
B. Servicio Analítico casos de uso
Más allá de la funcionalidad básica de las aplicaciones mencionadas anteriormente, los
desarrolladores de aplicaciones pueden ser también interesado en
la recogida de análisis de servicios y la gestión proactiva de las diferentes entidades
utilizadas para ofrecer funcionalidad de la aplicación. En los siguientes párrafos
proporcionamos dos casos de uso de tales capacidades analíticas de servicios que
podrían ser de interés en las implementaciones típicas de la IO.
1) E fi ciente estimación del número de IP address únicos
El uso de un determinado servicio: Tenga en cuenta que los servicios de la IO puede
havemillions de los usuarios y conocer el número de usuarios únicos en un período de
tiempo es de interés. Además, el almacenamiento de las direcciones IP únicas en una base
de datos relacional puede ser costoso. En su lugar, el servicio puede hash de la dirección IP
de cada paquete en su local de invertible filtro Bloom (FIB) [195]. Para ilustrar los beneficios
potenciales de este enfoque, se realizó un experimento en el que se asumió que en un
período de tiempo, una corriente de N (N = 1000, 2000, y 3000) los paquetes llegan al
servicio. En la Fig. 29 se ilustra el compromiso entre el tamaño de la FIB y la precisión
alcanzada. La comparación baselineof es un tablewithone relacional mil registros. Si
queremos almacenar estas direcciones IP en una tabla relacional tradicional, necesitamos 4 * N
bytes de memoria, mientras que en el enfoque propuesto, que necesitamos mucha menos
memoria. Tabla IX muestra la parte de memoria utilizada por la FIB (en el caso de que
necesitamos una precisión al menos
0,95) para los diferentes tamaños de entrada. En el peor de los casos que utilizamos 2250
bytes para cubrir N = 1000 IPs, nuestro uso de la memoria es de 56% (2250/4000) del
enfoque de línea de base. Mientras que en escenarios realistas el tamaño de entrada será
mucho más grande, este escenario ilustra el beneficio potencial de empleo de la FIB en el
contexto de la IO en apoyo de la recopilación de análisis de servicios.
2) El seguimiento de la frecuencia de uso del servicio por un IP Teniendo en cuenta:
El seguimiento de la frecuencia de uso de los servicios de la IO puede ser de gran ayuda
en las tareas de gestión de redes y aplicaciones. Un servicio puede ef tienda fi
cientemente el conjunto de direcciones IP y sus frecuencias de acceso asociados en
forma de par clave-valor en su FIB local. Para ilustrar el beneficio de usar el FIB en este
contexto, se realizó un experimento en el que simulamos una corriente de solicitudes de
servicio generados por 250 direcciones IP diferentes. Por lo que las direcciones IP y sus
frecuencias se mantienen en el FIB. El número de solicitudes de servicio en este
experimento llega a 10 000. Fig. 30 muestra la comparación de la exactitud de las
estadísticas de frecuencia y el coste de uso de memoria para la FIB frente a una
estructura de datos relacional. Es interesante que la FIB con un tamaño de 50 bytes que
son capaces de tener una lista completa de direcciones IP y sus frecuencias. En una
estructura relacional, necesitamos 6 bytes para cada IP (4 bytes) y la frecuencia (2
bytes). Por lo tanto, para cubrir las estadísticas de todos los 250 IPs por una estructura
convencional que necesitamos 1.500 bytes. Una vez más, mientras que en escenarios
realistas el tamaño de entrada será mucho más grande; este escenario ilustra el
potencial beneficio de emplear el FIB en el contexto de la IO en apoyo de la recogida de
análisis de servicio.
X. C ONCLUDING R eMarks
A. Lecciones aprendidas
En el presente trabajo, hemos revisado la IO desde diferentes ángulos y aquí
resumimos las lecciones aprendidas por esta revisión. En primer lugar, desde la
perspectiva oportunidades de mercado, la inversión en esta nueva tecnología es racional
para las organizaciones que buscan competitividad en el mercado. Desde el punto de vista
de la arquitectura, la estructura en capas de sistemas de IO se adopta así la IO y por
marcos
AL-Fuqaha et al .: IOT Encuesta sobre tecnologías de capacitación, protocolos y aplicaciones
Fig. 28. La integración de protocolos de IO en escenario de enfermería.
TABLA IX
EL FIB M EMORIA R ATE PARA D ifferent I Nput S IZES
intentos de investigación [2], [3], [15] - [20]. Sin embargo, el número de capas y sus
alcances se definen de manera diferente dependiendo de las infraestructuras y
tecnologías subyacentes. Como escalabilidad e interoperabilidad tener una gran
importancia en las aplicaciones de la IO, aumentando la arquitectura con mejores
abstracciones pueden aliviar estos problemas. Las cinco capas arquitectura [3], [17], [18]
presentan un modelo tal.
A continuación, presentamos los diferentes elementos de la IO y sus tecnologías y
herramientas que se necesitan para realizar una solución de la IO relacionados. Identi
fi cación y de detección son los componentes elementales de un sistema. De bajo peso
comunicación e fi ciente entre dispositivos de detección y la interoperabilidad entre
diferentes mecanismos de comunicación son problemas críticos de la IO.
2371
Fig. 29. solución de compromiso entre la precisión y el tamaño de la FIB.
tecnologías de comunicación como ZigBee, Bluetooth LE, NFC, RFID, Z-Wave, y
LTE-A se encuentran entre las tecnologías más atractivas para su uso en
entornos de IO y M2M.
Nos echamos más en los protocolos y normas de la IO mediante la revisión de
los diferentes protocolos y estándares en las diferentes capas de un entorno IO.
Hemos abordado la funcionalidad principal y el papel de estos protocolos para que
el lector pueda aprender los fundamentos de estos protocolos sin tener que pasar
a través de los miles de páginas de documentos fi caciones para los diferentes
protocolos. La optimización de los protocolos actuales es algo que requiere un
mayor desarrollo.
2372
Fig. 30. La estructura de la FIB frente relacional en términos de espacio necesario.
También se revisaron un gran número de estudios recientes de encontrar los principales
retos y cuestiones abiertas en el área de la IO. La seguridad y la privacidad son la máxima
prioridad para las aplicaciones de la IO seguido de rendimiento, fiabilidad y gestión. A
continuación, investigaron la consecuencia de la IO que es Big Data y la necesidad de una
nueva generación de datos de análisis de algoritmos y herramientas que son adecuados para
grandes volúmenes de datos IO. Nos encontramos con que de análisis de datos en tiempo real
las técnicas que son capaces de reducir el tamaño de entrada serían prometedor. También se
revisaron el papel de la computación en nube y la niebla en el ecosistema de la IO. Al nivel de
las nubes, necesitamos plataformas para apoyar la IO grande de datos, análisis de la IO y la
disponibilidad.
En la sección IX, presentamos tres casos de uso detalladas que ilustran cómo los
diferentes protocolos presentados en esta encuesta fi cio juntos para ofrecer nuevos
servicios inteligentes de IO que proporcionan nuevas funcionalidades a
theuserswhilebridging thegapbetween thedivergent protocolos de la IO y la realización de
análisis de trá fi co oportunistas.
B. Conclusión
La idea emergente de la Internet de los objetos (IO) es rápidamente hallazgo de su
trayectoria a lo largo de nuestra vida moderna, con el objetivo de mejorar la calidad de
vida mediante la conexión de muchos dispositivos inteligentes, tecnologías y
aplicaciones. En general, la IO sería permitir la automatización de todo lo que nos rodea.
En este trabajo se presenta una visión general de la premisa de este concepto, sus
tecnologías de capacitación, protocolos, aplicaciones y la investigación reciente sobre
diferentes aspectos de la IO. Esto, a su vez, debe proporcionar una buena base para los
investigadores y profesionales que estén interesados ​en obtener una visión de las
tecnologías y protocolos de la IO para entender la arquitectura general y el papel de los
diferentes componentes y protocolos que constituyen la IO. Promover, algunos de los
problemas y las cuestiones que se refieren al diseño y despliegue de las
implementaciones de la IO se han presentado. Por otra parte, la interacción entre la IO,
análisis de datos grandes, la nube y la computación niebla se ha discutido.
Nos finalmente presentó la necesidad de una nueva gestión “inteligente”
autonómico, la agregación de datos y servicios de adaptación del protocolo para lograr
una mejor integración horizontal entre servicio de la IO. Finalmente, se presentan casos
detallados aplicación de uso para ilustrar escenarios típicos de integración protocolo
para ofrecer servicios de IO deseadas.
R EFERENCIAS
[1] D. Evans, “Internet de las cosas: ¿Cómo la próxima evolución de Internet
está cambiando todo “, CISCO, San Jose, CA, EE.UU., WhitePaper de 2011.
ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 4, CUARTO TRIMESTRE 2015
[2] L. Atzori, A. Iera, y G. Morabito, “Internet de las Cosas: Una encuesta,”
Comput. Netw., vol. 54, no. 15, pp 2787-2805, octubre de 2010. [3] R. Khan, SU Khan, R.
Zaheer, y S. Khan, “Internet futuro:. El In-
ternet de la arquitectura de las cosas, las posibles aplicaciones y desafíos clave “, en Proc. 10ª Int.
Conf. AJUSTE, 2012, pp. 257-260.
[4] J. Gubbi, R. Buyya, S. Marusic, y M. Palaniswami, “Internet de los objetos
(IO): Una visión, elementos arquitectónicos, y las direcciones futuras” Gener futuro. Comput.
Syst., vol. 29, no. 7, pp. 1645-1660, Sep. 2013. [5] P. López, D. Fernandez, AJ Jara, y AF
Skármeta, “Estudio de las
Internet de las Cosas tecnologías para entornos clínicos “, en Proc. 27 Int. Conf. Waina, 2013,
pp. 1349-1354.
[6] D. Yang, F. Liu, y Y. Liang, “Un estudio de la Internet de los objetos”, en
Proc. Primero ICEBI, 2010, pp. 358-366.
[7] A. Gluhak et al., “Una encuesta sobre instalaciones para Internet experimental de
Cosas investigación” IEEE Commun. Revista., vol. 49, no. 11, pp. 58-67, noviembre de 2011. [8] Z.
Sheng et al., “Un estudio sobre el conjunto de protocolos del IETF para Internet
de las cosas: Normas, desafíos y oportunidades” IEEE Wireless Commun., vol. 20, no. 6, pp
91-98, diciembre de 2013. [9] J. Gantz y D. Reinsel, “El universo digital en 2020:. Datos grande,
más grande
sombras digitales, y mayor crecimiento en el Lejano Oriente” IDC iView: IDC anal. Futuro, vol.
2007, pp. 1-16, diciembre de 2012. [10] S. Taylor, “La próxima generación de Internet
revolucionando la forma
trabajamos, vivimos, jugamos y aprendemos “, CISCO, San Francisco, CA, EE.UU., CISCO Punto
de vista, 2013. [11] J. Manyika et al., Las tecnologías de punta: Los avances que transformarán
La vida, negocios, y la economía mundial. San Francisco, CA, EE.UU.:. McKinsey Global
Instit, 2013.
[12] MZ Sha fi q, L. Ji, AX Liu, J. Pang, y J. Wang, “Un primer vistazo a CEL
lular de máquina a máquina de tráfico c: medición a gran escala y caracterización,”en Proc.
ACM Sigmetrics llevar a cabo. Eval. Rdo., 2012, pp. 65-76.
[13] D. Floyer, “De fi Ning y el dimensionamiento de la Internet industrial,” Wikibon,
Marlborough, MA, EE.UU., 2013.
[14] “Los sistemas de automatización de edificios comerciales,” Navigant Consulting Res.,
Boulder, CO, EE.UU., 2013.
[15] S. Krco, B. Pokric, y F. Carrez, “arquitectura Proyectos IO (s):
Una perspectiva europea “, en Proc. IEEE WF-IO, 2014, pp. 79-84.
[16] de la UE 7PM Internet de las cosas Proyecto de Arquitectura, 18 de septiembre de 2014. [En línea].
Disponible: http://www.iot-a.eu/public [17] Z. Yang et al., “Estudio y aplicación en la
arquitectura y la clave
tecnologías para la IOT,”en Proc. ICMT, 2011, pp. 747-751.
[18] M. Wu, TJ Lu, FY Ling, J. Sun, y HY Du, “Investigación sobre
la arquitectura de Internet de las cosas “, en Proc. ICACTE tercero, 2010, pp. V5-484-V5-487.
[19] L. Tan y N. Wang, “Internet del Futuro: La Internet de las cosas”, en Proc.
ICACTE tercero, 2010, pp. V5-376-V5-380.
[20] MA Chaqfeh y N. Mohamed, “Retos en soluciones de middleware
para la Internet de las cosas “, en Proc. En t. Conf. CTS, 2012, pp. 21-26.
[21] N. Koshizuka y K. Sakamura, “Ubiquitous Identificación: Normas para Ubiqui-
tous computación y la Internet de las cosas” IEEE Comput generalizado.,
vol. 9, no. 4, pp. 98-101, octubre-Dec. 2010. [22] N. Kushalnagar, G. Montenegro, y C.
Schumacher, “IPv6 sobre Bajo
Potencia personal inalámbricas (redes de área 6LoWPANs): Descripción general, supuestos,
planteamiento del problema, y ​metas,”Internet Esp. Grupo de Trabajo (IETF), Fremont, CA,
EE.UU., RFC4919, vol. 10, agosto de 2007. [23] G. Montenegro, N. Kushalnagar, J. Hui, y D.
Culler, “Transmission
de paquetes IPv6 sobre IEEE 802.15. 4 redes,”Internet Esp. Grupo de Trabajo (IETF),
Fremont, CA, EE.UU., Internet Propuesto Std. RFC 4944,
2007.
[24] K. Pilkington, “equipos Revolv arriba con Home Depot para mantener su casa
conectada “, Centro Nacional de Estudios de Telecomunicaciones (CNET), San Francisco,
CA, EE.UU., CNET-News, 2014. [En línea]. Disponible:
http://Ces.Cnet.Com/8301-35306_1-57616921/Revolv-Teams-Upwith-Home-Depot-to-Keep-Your-House-Conn
[25] “SmartThings | domótica, seguridad en el hogar, y la paz de la mente”
SmartThings, Palo Alto, CA, EE.UU., septiembre de 2014. [En línea]. Disponible:
http://www.smartthings.com [26] U. Rushden, Belkin trae su hogar a su alcance con Wemo
Sistema de automatización del hogar. Los Ángeles, CA, EE.UU.: Sala de prensa de Belkin, 2012.
[27] R. desea, “Una introducción a la tecnología RFID” IEEE generalizado
Comput., vol. 5, no. 1, pp. 25-33, enero-Mar. 2006. [28] R. desea, “Cerca de la comunicación de
campo” IEEE Comput generalizado., vol. 10,
no. 3, pp. 4-7, Jul./Sep. 2011.
[29] RS Kshetrimayum, “Una introducción a la comunicación UWB
sistemas” IEEE Potenciales vol. 28, no. 2, pp. 9-13, mar.-abr. 2009.
AL-Fuqaha et al .: IOT Encuesta sobre tecnologías de capacitación, protocolos y aplicaciones
[30] protocolos inalámbricos E. Ferro y F. Potorti “, Bluetooth y Wi-Fi: A
encuesta y una comparación” IEEE Wireless Commun., vol. 12, no. 1, pp. 12-26, Feb. de
2005.
[31] P. McDermott-Wells, “¿Qué es Bluetooth?” IEEE Potenciales vol. 23,
no. 5, pp. 33-35, enero de 2005.
[32] “Notas de prensa detalle: sitio web de la tecnología Bluetooth,” Bluetooth Tech-
nol. Sitio web, Kirkland, WA, EE.UU., septiembre de 2014. [En línea]. Disponible: http: //
www.bluetooth.com/Pages/Press-Releases-Detail.aspx?ItemID=197 [33] Norma IEEE para locales
y redes de área metropolitana-Parte 15.4:
Low-Rate Wireless Personal Area Networks (LR-WPAN), IEEE Std.
802. 15. 4-2011, 2011.
[34] GV Crosby y F. Vafa, “redes de sensores inalámbricos y LTE-A red
convergencia “, en Proc. IEEE Conf 38a. LCN, 2013, pp. 731-734.
[35] A. Ghosh, R. Ratasuk, B. Mondal, N. Mangalvedhe, y T. Thomas,
“LTE-Advanced: la tecnología inalámbrica de banda ancha de próxima generación [invitado
papel],” IEEE Wireless Commun., vol. 17, no. 3, pp. 10-22, Jun. De 2010.
[36] A. Dunkels, B. Gronvall, y T. Voigt, “Contiki-A ligero y fl ex
sistema operativo ible para los sensores conectados en red diminutos,”en Proc. 29 Annu. IEEE Int.
Conf. Comput local. Netw., 2004, pp. 455-462.
[37] P. Levis et al., “TinyOS: Un sistema operativo para redes de sensores”
en Inteligencia Ambiental. Nueva York, NY, EE.UU.: Springer-Verlag, 2005, pp 115-148..
[38] P. Cao, T. Abdelzaher, J. Stankovic, y T. Él, “Los LiteOS operativo
Sistema: Hacia abstracciones Unix para redes de sensores inalámbricos,”en Proc. En t.
Conf. IPSN, 2008, pp. 233-244.
[39] E. Baccelli, O. Hahm, M. Günes, M. Wählisch, y TC Schmidt,
“OS RIOT: Hacia un sistema operativo para la Internet de las cosas”, en Proc. IEEE Conf.
INFOCOM WKSHPS, 2013, pp. 79-80.
[40] Open Auto Alliance, 20 de octubre de 2014. Disponible: http: // www.
openautoalliance.net/
[41] X. Xiaojiang, W. Jianli, y L. Mingdong, “Servicios y tecnolo- clave
gías de la Internet de las cosas “, ZTE Commun., Shenzhen, China, vol. 2,
pag. 011, 2010.
[42] M. y S. Gigli Koo, “Internet de las cosas: servicios y aplicaciones cat-
egorization” Adv. Las cosas de Internet, vol. 1, no. 2, pp 27-31, Julio 2011. [43] DJ Cook, AS
Crandall, BL Thomas, y NC Krishnan, “CASAS..:
Una casa inteligente en una caja” Computadora, vol. 46, no. 7, pp. 62-69, Jul. 2013. [44] N.
Komninos, E. Philippou, y A. Pitsillides, “Encuesta en red inteligente
y seguridad en el hogar inteligente: temas, retos y contramedidas” IEEE Commun. Encuestas, Tuts. vol.
16, no. 4, pp. 1933-1954, cuarta Quart. 2014. [45] E. Finch, “¿Es IP en todas partes el camino a seguir
para la automatización de edificios?”
Instalaciones, vol. 19, no. 11/12, pp. 396-403, 2001. [46] C. Talcott, “sistemas y eventos
Cyber-física”, en Software-intensivo
Sistemas y Nuevos Paradigmas de computación, M. Wirsing, J. Banatre,
M. Hölzl, y A. Rauschmayer, Eds. Nueva York, NY, EE.UU.: Springer Sci. Media Business,
2008, pp. 101-115.
[47] L. Yongfu, S. Dihua, L. Weining, y Z. Xuebo, “Un servicio orientado
arquitectura para los sistemas ciber-físicos de transporte “, en Proc. 31
CCC, 2012, pp. 7.674-7.678.
[48] ​L. Ying y Z. Lingshu, “El diseño nuevo de Internet inteligente-de-vehículos
sistema de gestión basado en la nube de computación e Internet-de-cosas,”en Proc. En t. Conf.
EMEIT, 2011, pp. 3190 hasta 3193.
[49] M. Gerla, L. Eun-Kyu, G. Pau, y L. Uichin, “Internet de los vehículos: De
rejilla inteligente para vehículo autónomo y nubes vehiculares,”en Proc. IEEE WF-IO, 2014, pp.
241-246.
[50] A. extraño “Toyota, Audi preparar coches auto-conducción,” PC, Nueva York,
NY, EE.UU., PCMag.Com: Nuevo producto Rev. 2013. [En línea]. Disponible:
http://Www.Pcmag.Com/Article2/0,2817,2413841,00.Asp [51] J. Markoff, “coches de Google Drive a
sí mismos, en el trá fi co”, New York Times,
NewYork, NY, EE.UU., 2010. [En línea] .Available: http: //www.Nytimes.com/ 2010/10/10 /
Ciencia / 10google.Html Pagewanted = all & # x0026; _r = 0 [52] A. Del Colle, “Volvo pondrá a
prueba vehículo autónomo en calles- de Suecia
Mecánica Popular,”Mecánica Popular, Coches, Noticias, Nueva York, Nueva York, EE.UU., 2013.
[53] I. Ungurean, NC Gaitan, y VG Gaitan, “Una arquitectura IO para
cosas de entorno industrial “, en Proc. 10ª Int. COMM, 2014, pp. 1-4.
[54] C. Wang, Z. Bi, y LD Xu, “computación IO y la nube en la automatización
de los sistemas de modelado de montaje,” IEEE Trans. Ind. Informat., vol. 10, no. 2, pp. 1426 a 1434,
mayo de 2014.
[55] “-7 radicales mediciones de avance. Monitor radical “, Masimo
Hoja Corp., Irvine, CA, EE.UU., datos Radical-7, 2013.
[56] C. No “Sensores recordar a los médicos para lavarse,” IBM Res., Armonk, NY,
EE.UU., 2013.
[57] K. Michaelsen, JL Sanders, SM Zimmer, y GM Bump,
“La superación de las barreras de pacientes para discutir higiene de las manos del médico: Hacer
2373
pacientes prefieren recordatorios electrónicos a otros métodos?” Control de infección, vol. 34, no. 9,
pp. 929-934, Sep. 2013. [58] S. Jain et al., “Un sistema RFID HF encargo de bajo costo para al lavado a
mano
ing vigilar el cumplimiento,”en Proc. IEEE octavo ASICON, 2009, pp. 975-978.
[59] Y. Yan, Y. Qian, H. Sharif, y D. Volquete, “Una encuesta sobre com- red inteligente
infraestructuras municación: motivaciones, necesidades y desafíos”
IEEE Commun. Encuestas, Tuts. vol. 15, no. 1, pp. 5-20, primero Quart. 2013. [60] T. Gea, J. Paradells,
M. Lamarca, ANDD. Roldan, “ciudades inteligentes como una apli-
cación de Internet de las cosas: experiencias y lecciones aprendidas en el Barcelona “, en Proc.
7º Int. Conf. IMIS ubicua Comput., 2013, pp. 552-557.
[61] J. Jin, J. Gubbi, S. Marusic, y M. Palaniswami, “An información
marco para la creación de una ciudad inteligente a través de Internet de las cosas” IEEE
Internet Cosas J., vol. 1, no. 2, pp. 112-121, abril de 2014. [62] P. Barnaghi, W. Wang, C. Henson, y
K. Taylor, “semántica para el
Internet de las cosas: El progreso inicial y de nuevo al futuro” Proc. IJSWIS,
vol. 8, no. 1, pp. 1-21, enero de 2012.
[63] T. Kamiya y J. Schneider, “Ef fi ciente XML Interchange (EXI)
Formato 1.0,”World Wide Web Consortium, Cambridge, MA, EE.UU., recomienda.
REC-Exi-20110310, 2011. [64] Z. Shelby, K. Hartke, C. Bormann, y B. Frank, “constreñido
Aplica-
Protocolo ción (COAP) .Draft-IETF-core-coap-18,”Internet Ing. Grupo de Trabajo (IETF), Fremont,
CA, EE.UU., 2013.
[65] C. Bormann, AP Castellani, y Z. Shelby, “COAP: Una aplicación
Protocolo para los mil millones de nodos de Internet diminutos,” IEEE Comput Internet.,
vol. 16, no. 2, pp. 62-67, mar.-abr. 2012. [66] RT Fielding, “estilos arquitectónicos y el diseño
de red basada
arquitecturas de software “, Ph.D. disertación, Inf. Comput. Sci., Univ. California, Irvine, CA,
EE.UU., 2000.
[67] W. Colitti, K. Steenhaut, N. De Caro, B. Buta, y V. Dobrota, “Evaluation
ación de protocolo de aplicación restringida para redes de sensores inalámbricos,”en Proc.
18a IEEE LANMAN taller, 2011, pp. 1-6.
[68] C. Lerche, K. Hartke, y M. Kovatsch, “adopción Industria de la Inter-
neto de las Cosas: Una encuesta protocolo de aplicación restringida “, en Proc. IEEE 17a Conf.
ETFA, 2012, pp. 1-6.
[69] Código de IO: Recetas. RPL, mDNS y REST, Jul 8, 2014. [En línea].
Disponible: http://github.com/mehdimo/IoTCodeRecipes [70] D. Locke, “transporte MQ
telemetría (MQTT) v3. SPEC- 1 protocolo
i fi cación,”IBM developerWorks, Markham, ON, Canadá, Tech. Lib., 2010. [En línea].
Disponible: Http://Www.Ibm.Com/Developerworks/ webservices / Library / Ws-MQTT /
index.html [71] U. Hunkeler, HL Truong, y A. Stanford-Clark, “MQTT-S-A
publicación / suscripción protocolo para redes de sensores inalámbricos “, en Proc. Int tercero. Conf.
COMSWARE, 2008, pp. 791-798.
[72] P. Saint-Andre, “mensajería Extensible y protocolo de presencia (XMPP):
Core,”Internet Ing. Grupo de Trabajo (IETF), Fremont, CA, EE.UU., Petición de Comentarios: 6120,
2011.
[73] MT Jones, “Meet Messaging and Presence Protocol extensible
(XMPP),”IBM developerWorks, Markham, ON, Canadá, 2009. [74] P. Waher e Y. Doi, E fi
ciente de intercambio XML (EXI) Formato, Std. XEP-
0322, 2013.
[75] “OASIS avanzada Mensaje Protocolo Queuing (AMQP) Version 1.0”,
Adv. Abrir Std. Inf. Soc. (OASIS), Burlington, MA, EE.UU., 2012. servicios [76] de distribución de
datos específica de cationes, V1.2, objeto gestionar. Grupo
(OMG), Needham, MA, EE.UU., 2 de abril de 2015. [En línea]. Disponible: http: //
www.omg.org/spec/DDS/1.2/
[77] C. Esposito, S. Russo, y D. Di Crescenzo, “Evaluación del desempeño
de OMG middleware de distribución de datos compatible “, en Proc. IEEE PDPI,
2008, pp. 1-8.
[78] D. Thangavel, X. Ma, A. Valera, H. Tan, y CK Tan, “Performance
evaluación de MQTT y coap a través de un middleware común “, en Proc. IEEE Int noveno.
Conf. ISSNIP, 2014, pp. 1-6.
[79] N. De Caro, W. Colitti, K. Steenhaut, G. Mangino, y G. Reali,
“Comparación de los dos protocolos ligeros para detección basado en la smartphone,” en Proc.
IEEE 20 TVSC, 2013, pp. 1-6.
[80] M. Laine y K. SAILA, “Evaluación del funcionamiento de XMPP en la Web,”
Aalto Univ. Tech. Rep., Aalto, Finlandia, 2012. [81] JL Fernandes, IC Lopes, JJPC
Rodrigues, y S. Ullah, “Per-
Evaluación Formance de los servicios web RESTful y el protocolo AMQP,”en
Proc. ICUFN quinto, 2013, pp. 810-815.
[82] AJ Jara, P. Martínez-Julia, y A. Skármeta, “multicast ligero
DNS y DNS-SD (SD-lmDNS): recursos y servicio de detección basada en IPv6 para la web
de las cosas,”en Proc. 6º Int. Conf. IMIS ubicua Comput., 2012, pp. 731-738.
[83] R. y M. Klauck Kirsche, “Chatty cosas de decisiones de Internet
Cosas fácilmente utilizables para las masas con XMPP,”en Proc. Octavo Int. Conf.
CollaborateCom, 2012, pp. 60-69.
2374 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 4, CUARTO TRIMESTRE 2015
[84] S. Cheshire y M. Krochmal, “Multicast DNS,” Internet Eng. Tarea
Force (IETF), Fremont, CA, EE.UU., Petición de Comentarios: 6762, 2013. [85] M. y S. Krochmal
Cheshire, “el descubrimiento de servicios basado en DNS,” Internet
Ing. Grupo de Trabajo (IETF), Fremont, CA, EE.UU., Petición de Comentarios:
6763, 2013.
[86] J. Vasseur et al., “RPL: El protocolo de enrutamiento IP diseñado para baja
poder y redes con pérdida,”Protocolo de Internet de los objetos inteligentes (IPSO) Alliance, San
Jose, CA, EE.UU., 2011. [87] T. invierno et al., “RPL: protocolo de enrutamiento IPv6 para baja potencia
y IPsec,”en Proc. En t. Conf. DCOSS, 2011, pp. 1-8.
redes con pérdida,”Internet Ing. Grupo de Trabajo (IETF), Fremont, CA, EE.UU., Petición de
Comentarios: 6550, 2012.
[88] T. Clausen, U. Herberg, y M. Philipp, “una evaluación crítica de la
IPv6 protocolo de enrutamiento para baja potencia y redes con pérdida (RPL),”en Proc. IEEE Int séptimo.
Conf. Wimob, 2011, pp. 365-372.
[89] MR Palattella et al., “Pila de protocolo normalizado de Internet
de (importantes) cosas” IEEE Commun. Encuestas, Tuts. vol. 15, no. 3, pp. 1389-1406, tercera Quart.
2013. [90] J. Ko et al., “Conexión de bajo consumo de energía y las redes con pérdida de la Internet”
IEEE Commun. Revista., vol. 49, no. 4, pp. 96-101, abril de 2011. [91] JW Hui y DE Culler,
“Extender IP a baja potencia, per- inalámbrico
redes de área Sonal” IEEE Comput Internet., vol. 12, no. 4, pp. 37-45, Jul./Aug. 2008.
[92] R. Frank, W. Bronzi, G. Castignani, y T. Engel, “Bluetooth baja
energía: Una tecnología alternativa para aplicaciones Vanet,”en Proc. 11 Annu. Conf.
WONS, 2014, pp. 104-107.
[93] J. Decuir, “Presentación de Bluetooth inteligente: Parte 1: Una mirada a la vez clásico
y las nuevas tecnologías” IEEE Consum. Electrón. Revista., vol. 3, no. 1, pp. 12-18, enero de
2014.
[94] E. Mackensen, M. Lai, y TM Wendt, “baja energía Bluetooth (BLE)
sensores inalámbricos basados ​“, en IEEE Sens., 2012, pp. 1-4.
[95] M. Siekkinen, M. Hiienkari, JK Nurminen, y J. Nieminen, “¿Cómo
bajo consumo de energía es baja energía Bluetooth? Las mediciones comparativas con ZigBee /
802.15.4,”en Proc. IEEE WCNCW, 2012, pp. 232-237.
[96] CE Jones y CA Chung, RFID y Auto-ID en Planificación y Lo-
Gistics: Una guía práctica para aplicaciones militares UID. Boca Raton, FL, EE.UU.: CRC
Press, 2011. [97] D. Minoli, La construcción de la Internet de las cosas con IPv6 y MIPv6:
El cambiante mundo de las comunicaciones M2M. Nueva York, NY, EE.UU.: Wiley, 2013.
[98] J. Grasso, “La red EPCglobal: Visión general de diseño, beneficios, y
seguridad “, EPCglobal Inc, Documento de posición, vol. 24, 2004. [99] M. Hasan, E. Hossain,
y D. Niyato, “acceso aleatorio para máquina-
a-máquina de la comunicación en las redes LTE-Avanzada: Cuestiones y enfoques” IEEE
Commun. Revista., vol. 51, no. 6, pp. 86-93, Jun. De 2013.
[100] D. Niyato, P. Wang, y DI Kim “, el modelado y análisis de rendimiento
de comunicaciones del tipo máquina heterogéneos,” IEEE Trans. Commun inalámbrica., vol. 13,
no. 5, pp. 2836 a 2849, mayo de 2014.
[101] C. Gómez y J. Paradells, “redes de automatización del hogar inalámbrica: a
encuesta de arquitecturas y tecnologías” IEEE Commun. Revista., vol. 48, no. 6, pp. 92-101,
Jun. De 2010.
[102] N. Accettura, LA Grieco, G. Boggia, y P. Camarda, “Rendimiento
análisis del protocolo RPL enrutamiento,”en Proc. IEEE ICM, 2011, pp. 767-772.
[103] E. Ancillotti, R. Bruno, y M.. Conti, “protocolo de enrutamiento RPL en avanzado
infraestructuras de medición: Un análisis de los problemas de falta de fiabilidad,”en
Proc. SustainIT, 2012, pp. 1-10.
[104] B. Cody-Kenny et al., “Evaluación del funcionamiento de la 6LoWPAN
protocolo sobre MicaZ y TelosB motas,”en Proc. ACM cuarto taller Ejecutar. Monitoreo Meas.
Heterogénea inalámbrica con conexión de cable Serv., 2009, pp. 25-30.
[105] B. Enjian y Z. Xiaokui, “Evaluación del funcionamiento de 6LoWPAN Gate-
forma utilizada en el entorno de red real,”en Proc. ICCECT, 2012, pp. 1036-1039.
[106] BB Olyaei, J. Pirskanen, O. Raeesi, A. Hazmi, y M. Valkama, “Per-
Formance comparación entre ranurado IEEE 802.15.4 e IEEE 802.1 LAH en las aplicaciones
basadas en la IO,”en Proc. IEEE Int noveno. Conf. Wimob, 2013, pp. 332-337.
[107] JY Maina, MH Mickle, MR Lovell, y LA Schaefer, “Aplica-
ción de CDMA para anticolisión y el aumento de leer e fi ciencia de múltiples etiquetas RFID” J.
Manuf. Syst., vol. 26, no. 1, pp. 37-43, enero de 2007. [108] E. Vahedi, RK Ward, y SI Blake,
“Análisis de rendimiento de RFID
protocolos: CDMA frente al estándar EPC Gen-2,” IEEE Trans. Autom. Sci. Eng., vol. 11, no. 4,
pp. 1250-1261, octubre de 2014.
[109] C. Withanage, R. Ashok, C. Yuen, y K. Otto, “Una comparación de la
tecnologías de automatización del hogar populares “, en Proc. IEEE ISGT Asia, 2014, pp. 600-605.
[110] I. Bagci, M. Pourmirza, S. Raza, U. Roedig, y T. Voigt, “Codo: Con fi-
almacenamiento de datos confidencial para redes de sensores inalámbricos “, en Proc. IEEE Int noveno. Conf. MASA, 2012,
pp. 1-6.
[111] S. Raza, S. Duquennoy, J. Höglund, U. Roedig, y T. Voigt, “Secure
comunicaciones de la Internet de las cosas-Una comparación de la seguridad de capa de enlace e
IPsec para 6LoWPAN” Commun seguridad. Netw., vol. 7, no. 12, pp. 2654-2668, diciembre de 2012.
[112] S. Raza et al., “Protección de la comunicación en 6LoWPAN con comprimido
[113] M. Shrivatsa y L. Liu, “Protección de publicación-suscripción de servicios de superposición
con EventGuard,”en Proc. 12 ACMConf. Comput. Commun. Seguridad,
2005, pp. 289-298.
[114] AB Corman, P. Schachte, y V. Teague, “QUIP: Un protocolo para
asegurar el contenido en peer-to-peer de publicación / suscripción redes superpuestas,”en
Proc. Conf Australasia 13. Comput. Sci., 2007, vol. 62, pp. 35-40.
[115] S. Raza, H. Shafagh, K. Hewage, R. Hummen, y T. Voigt, “Ágil:
Coap seguro Ligera en Internet de las Cosas” IEEE Sens. J.,
vol. 13, no. 10, págs. 3711 hasta 3720, octubre de 2013. [116] MQTT NIST Marco de Seguridad
Cibernética, Jun. 15, 2014. [En línea].
Disponible: https://www.oasis-open.org/committees/download.php/
52.641 / MQTT-NIST-ciberseguridad-v1.0-wd02.doc [117] S. Raza, L. Wallgren, y T. Voigt,
“SVELTE: intrusión en tiempo real
detección en el Internet de las cosas” Ad Hoc Serv., vol. 11, no. 8, pp. 2661-2674, noviembre
de 2013. [118] Norma IEEE para una red doméstica convergente digital para heterogéneo
Tecnologías neos, IEEE Std. 1905. 1-2013, pp 1-93, 2013. Y. Liu, Y. Meng, y J. Huang,
“Gemini [119]:. Un esquema de despliegue verde
por Internet de las cosas “, en Proc. 22 WOCC, 2013, pp. 338-343.
[120] D. Uckelmann, “La medición del rendimiento y bene costo fi t aná-
sis de RFID e Internet de las cosas en las implementaciones de logística “, en Cuantificar el
valor de RFID y la arquitectura marco de EPCglobal en Logística. Nueva York, NY, EE.UU.:
Springer-Verlag, 2012, pp 71-100..
[121] JA Stankovic, “Direcciones de investigación para el Internet de las cosas” IEEE
Internet de las cosas J., vol. 1, no. 1, pp 3-9, Feb. 2014. [122] S. Chen, H. Xu, D. Liu, B. Hu, y
H. Wang, “Una visión de la IO:. Aplica-
ciones, desafíos y oportunidades con la perspectiva china,” IEEE Internet Cosas J., vol. 1, no. 4,
pp. 349-359, agosto de 2014. [123] S. Ziegler et al., IoT6-en movimiento a un futuro IO basada en
IPv6. Nueva York,
NY, EE.UU.: Springer-Verlag, 2013.
[124] D. Macedo, LA Guedes, e I. Silva, “Una evaluación de la fiabilidad
Internet de las cosas que incorporan aspectos de redundancia,”en Proc. IEEE 11 ICNSC, 2014,
pp. 417-422.
[125] I. Silva, R. Leandro, D. Macedo, y LA Guedes, “A fiabilidad
herramienta de evaluación para la Internet de las cosas” Comput. Electr. Eng., vol. 39, no. 7, pp. 2005-2018,
octubre de 2013.
[126] N. Maalel, E. Natalizio, A. Bouabdallah, P. Roux, y M. Kellil,
“La fiabilidad para aplicaciones de emergencia en Internet de las cosas”, en Proc. IEEE Int. Conf.
DCOSS, 2013, pp. 361-366.
[127] J. Kempf, J. Arkko, N. Beheshti, y K. Yedavalli, “Reflexiones sobre fiabi-
bilidad en el Internet de las cosas “, en Proc. La interconexión de los objetos inteligentes de Internet
Taller, 2011, pp. 1-4.
[128] L. Li, Z. Jin, G. Li, L. Zheng, y Q. Wei, “Modelado y análisis
la fiabilidad y el coste de la composición de servicios en la IO: Un enfoque probabilístico,”en Proc.
IEEE 19a ICWS, 2012, pp. 584-591.
[129] F. Ganz, R. Li, P. Barnaghi, y H. Harai, “Un esquema de movilidad de los recursos
para el servicio de continuidad en el Internet de las cosas “, en Proc. IEEE Int. Conf. GreenCom, 2012,
pp. 261-264.
[130] H. Fu, P. Lin, H. Yue, G. Huang, y C. Lee, “manage- movilidad Group
ment para redes a gran escala de máquina a máquina móvil” IEEE Trans. Veh. Technol., vol.
63, no. 3, pp. 1296-1305, marzo de 2014. [131] T. Elsaleh, A. Gluhak, y K. Moessner,
“continuidad de servicio para
los suscriptores de Internet móvil en el mundo real “, en Proc. Talleres IEEE ICC, 2011, pp.
1-5.
[132] Z. Zhu, L. Zhang, y R. Wakikawa, “Apoyando la movilidad de Internet
carros," IEEE Commun. Revista., vol. 49, no. 5, pp. 180-186, mayo de 2011. [133] S. Misra y P.
Agarwal, “modelo de movilidad grupo Bio-inspirado para móviles
las redes ad hoc basadas en el comportamiento fl ómo bloquear bird-” Comput suave., vol. 16, no. 3, pp. 437-450,
marzo de 2012.
[134] R. Duan, X. Chen, y T. Xing, “Una arquitectura de QoS para IOT,” en Proc.
En t. Conf. 4º iThings / CPSCom, 2011, pp. 717-720.
[135] MA Rajan, P. Balamuralidhar, KP Chethan, y M. Swarnahpriyaah,
“Un sistema de auto-fi recon gurable red de sensores de gestión de Internet de paradigma
cosas,” en Proc. ICDeCom, 2011, pp. 1-5.
[136] OMA M2M Ligera, Sep. 28, 2014. [En línea]. Disponible: http: //
technical.openmobilealliance.org/Technical/technical-information/ liberar-programa /
actuales de prensa / OMA-lightweightm2m-v1-0-2
AL-Fuqaha et al .: IOT Encuesta sobre tecnologías de capacitación, protocolos y aplicaciones
[137] V. Perelman, M. Ersue, J. Schönwälder, y K. Watsen, “Red
Con fi guración Protocolo de luz (Light NETCONF),”Internet Ing. Grupo de Trabajo (IETF),
Fremont, CA, EE.UU., Red 2012.
Plataforma de la IO [138] MASH, Canal Youtube, Sep. 28, 2014. [En línea]. Aprovechar-
poder: http://www.youtube.com/user/MASHPlatform
[139] F. Van den Abeele, J. Hoebeke, I. Moerman, y P. Demeester,
“La gestión de las interacciones coap con dispositivos IO con restricciones de grano fino,” en Proc.
IEEE NOMS, 2014, pp. 1-5.
[140] D. Uckelmann, M. Isenberg, M. Teucke, H. Halfar, y B. Scholz-Reiter,
“Control autónomo y la Internet de las Cosas: El aumento de robustez, escalabilidad y
agilidad en las redes logísticas,” Innovación de radio único para el siglo 21, Pp. 163-181,
2010.
[141] C. Sarkar, SNAU Nambi, RV Prasad, y A. Rahim, “A escalable
arquitectura distribuida hacia las aplicaciones de la IO unificadores “, en Proc. IEEE WF-IO, 2014, [167] D. Borthakur et al., “Apache Hadoop va en tiempo real en Facebook,”
pp. 508-513.
[142] F. Li, M. Vogler, M. Claessens, y S. Dustdar, “Ef fi ciente y escalable
IO prestación de servicios en la nube,”en Proc. IEEE Int sexto. Conf. NUBE,
2013, pp. 740-747.
[143] A. Dunkels, J. Eriksson, y N. Tsiftes, “interop- de baja potencia
erability para Internet basada en IPv6 de cosas “, en Proc. 10a escandinava Taller
inalámbrica ADHOC, Estocolmo, Suecia, 2011, pp. 10-11. [144] I. Ishaq et al., “Estandarización
del IETF en el campo de la Internet de
Los objetos (IO): Una encuesta,” Sens J.. Actuador Serv., vol. 2, pp. 235-287,
2013.
[145] L. Zhang et al., “El nombre de red de datos” ACM SIGCOMM Comput.
Commun. Rdo., vol. 44, pp. 66-73, 2014.
[146] SK Datta, C. Bonnet, y N. Nikaein, “An IO gateway centrada archi-
tecture proporcionar nuevos servicios M2M,”en Proc. IEEE Foro Mundial WF-IO, 2014, pp.
514-519.
[147] AP Castellani et al., “Arquitectura y protocolos de Internet de
Cosas: Un estudio de caso “, en Proc. 8 de IEEE Int. Conf. Percom Talleres, 2010, pp.
678-683.
[148] I. Silva, LA Guedes, P. Portugal, y F. Vasques “, fiabilidad y dispo-
Evaluación de la capacidad de las redes de sensores inalámbricos para aplica- ciones industriales” sensores,
vol. 12, no. 1, pp. 806-838, 2012.
[149] DG Costa, I. Silva, LA Guedes, F. Vásquez, y P. Portugal “, dispo-
problemas de capacidad en las redes de sensores inalámbricos, visuales” sensores, vol. 14, no. 2, pp.
2795-2821, Feb. de 2014.
[150] G. Wang, S. Chen, H. Lu, y M. Lin, “Pa-GFDP: Un en- algoritmo
hancing fiabilidad de redes inalámbricas de sensores” WSEAS Trans. Comput., vol. 11, no. 12, pp. 445-454, diciembre de
de 2012.
[151] A. Dâmaso, N. Rosa, y P. Maciel, “Fiabilidad de sensor inalámbrico
redes” sensores, vol. 14, pp. 15 760 a 15 785, 2014. [152] EZ Tragos et al., “Activación de ciudad
inteligente basada en la IO fiable y seguro
Aplicaciones “, en Proc. IEEE Int. Conf. Percom Talleres, 2014, pp. 111-116.
[153] F. Shaoshuai, S. Wenxiao, W. Nan, y L. Yan, “evalua- basado en MoDM
modelo ción de la calidad del servicio en el Internet de las cosas” Procedia Environ. Sci., vol. 11,
pp. 63-69, 2011.
[154] X. Che y S. Maag, “Un enfoque de prueba pasiva para los protocolos de Internet
de las cosas “, en Proc. IEEE Int. Conf. IEEE cibernético, Phys. Soc. Comput. GreenCom,
iThings / CPSCom, 2013, pp. 678-684.
[155] W. Pöttner, H. Seidel, J. Brown, U. Roedig, y L. Wolf, “Construir
horarios para la entrega de datos en tiempo crítico en redes de sensores inalámbricos,”
Proc. ACM TOSN, vol. 10, no. 3, p. 44, abril de 2014.
[156] G. Colistra, V. Pilloni, y L. Atzori, “asignación de tareas en grupo de
los nodos en la IO: un enfoque de consenso “, en Proc. IEEE ICC, 2014, pp. 3848-3.853.
[157] R. Lan-Lan, M. Luo-Ming, Q. Xue-Song, y Z. Jie, “hombre-Integrated
modelo agement para dispositivos terminales en redes de comunicación ubicuos,”en Proc.
ICCAE segundo, 2010, pp. 249-253.
[158] P. Castillejo, J. Martínez, L. López, y G. Rubio, “Una Internet de
Las cosas se aproximan para la gestión de servicios inteligentes proporcionados por dispositivos portátiles” En t.
J. Distrib. Sens. Serv., 2013.
[159] Marco de aplicación basada en Kura-OSGi para M2M Servicio Gate-
maneras, eclipse, Ottawa, ON, Canadá, el 25 de septiembre de 2014. [En línea]. Disponible:
http://www.eclipse.org/proposals/technology.kura/
[160] S. Ziegler, C. Crettaz, y I. Thomas, “IPv6 como un direccionamiento global
esquema e integrador para la Internet de las cosas y la nube “, en Proc. 28 Int. Conf. Waina, 2014,
[189] J. Vermillard, “M2M, IO, gestión de dispositivos: Un protocolo para gobernar
pp. 797-802.
[161] X. Wang, J. Zhang, EM Schooler, y M.. Ion “, Evaluación del desempeño
de encriptación basada en atributos: Hacia la privacidad de los datos en la IO,”en Proc. IEEE ICC, 2014,
pp. 725-730.
[162] F. Bao, I. Chen, y J. Guo, “escalable, adaptable y hombre-confianza survivable
agement para la comunidad de Internet basado en el interés de los sistemas de cosas “, en
Proc. ISADS 11 de IEEE, 2013, pp. 1-7.
2375
[163] Keoh SL, SS Kumar, y H. Tschofenig, “Protección de la Internet de las
Cosas: una perspectiva de Normalización,” IEEE Internet Cosas J., vol. 1, no. 3, pp. 265-275,
Jun. De 2014.
[164] B. Rao, P. Saluia, N. Sharma, A. Mittal, y S. Sharma, “Cloud computa-
ing de Internet de los objetos y aplicaciones de detección basados”en Proc. ICST sexto, 2012, pp.
374-380.
[165] R. Bryant, RH Katz, y ED Lazowska, “Big-datos informática:
La creación de revolucionarios avances en el comercio, la ciencia y la sociedad “, Comput.
Commun. Consortium (CCC), Washington, DC, EE.UU.,
2008.
[166] C. Tsai, C. Lai, M. Chiang, y LT Yang, “La minería de datos para Internet de
Cosas: Una encuesta,” IEEE Commun. Encuestas, Tuts. vol. 16, no. 1, pp. 77-
97, 1 de Quart. 2014.
en Proc. 2011 ACM SIGMOD Int. Conf. Los datos de gestión, 2011, pp. 1071-1080.
[168] A. Mukherjee, SA Paul, S. Dey, y A. Banerjee, “ángeles para dis-
análisis Tributado en la IO,”en Proc. IEEE WF-IO, 2014, pp. 565-570.
[169] X. Xu, S. Huang, Y. Chen, K. Browny, I. Halilovicy, y W. Lu,
“TSAaaS: análisis de series de tiempo como un servicio en la IO,” en Proc. IEEE ICWS, 2014, pp.
249-256.
[170] DC Verma y P. Verma, Las técnicas para Sobrevivir a Mobile Data exploraciones
sión (capítulo 8). Nueva York, NY, EE.UU.: Wiley, 2014. [171] K. Yang et al., “Parque-a-lot: Un sistema
de gestión del aparcamiento automatizado,”
Comput. Sci. Informar. Technol., vol. 1, no. 4, pp. 276-279, 2013. [172] C. Doukas, La
construcción de Internet de las cosas con el Arduino, CreateSpace
Independiente bar. Plataforma, Dougherty, GA, EE.UU., 2012. [173] Nimbits, Sep. 25, 2014.
[En línea]. Disponible: http://www.nimbits.com/ [174] O. y P. Mazhelis Tyrväinen, “Un marco para la
evaluación de Internet-
Cosas de plataformas: Aplicación punto de vista del proveedor,”en Proc. IEEE WF-IO, 2014, pp.
147-152.
[175] F. Bonomi, R. Milito, J. Zhu, y S. Addepalli, “Fog computación y
su papel en la Internet de las cosas “, en Proc. 1ª Edición MCC taller móvil nube Comput., 2012,
pp. 13-16.
[176] B. Rochwerger et al., “El modelo de yacimiento y arquitectura para Fe- abierto
rados cloud computing” IBM J. Res. Desarrollar., vol. 53, no. 4, pp. 535-
545, Jul. De 2009.
[177] GC Fox, S. Kamburugamuve, y RD Hartman, “Arquitectura y
características medidas de un Internet basado en la nube de cosas “, en Proc. En t. Conf. CTS, 2012,
pp. 6-12.
[178] H. Madsen, G. Albeanu, B. Burtschy, y FL-Popentiu Vladicescu,
“La fiabilidad en la era informática de servicios: hacia la computación en la niebla fiable”, en Proc.
20 IWSSIP, 2013, pp. 43-46.
[179] H. Chang, A. Hari, S. Mukherjee, y TV Lakshman, “Llevar la
nube para el borde,”en Proc. IEEE Conf. INFOCOM WKSHPS, 2014, pp. 346-351.
[180] marco Ponte-M2M puente para los desarrolladores REST, Eclipse, Ottawa,
ON, EE.UU., el 25 de septiembre de 2014. [En línea] .Available: http: //eclipse.org/proposals/ technology.ponte /
[181] M. Collina, GE Corazza, y A. Vanelli-Coralli, “Presentación de la
corredor QEST: Escala de la IO puenteando MQTT y REST,”en Proc. IEEE 23 Int. Symp.
PIMRC, 2012, pp. 36-41.
[182] Eclipse IO, Sep. 25, 2014. [En línea]. Disponible: https: //projects.eclipse.
org / proyectos / IOT
[183] ​Eclipse SCADA, Sep. 25, 2014. [En línea]. Disponible: http: // proyectos.
eclipse.org/projects/technology.eclipsescada [184] Eclipse SmartHome, Sep. 25, 2014. [En
línea]. Disponible: http: // eclipse.
org / propuestas / technology.smarthome / [185] Eclipse Krikkit, Sep. 25, 2014. [En línea].
Disponible: http://eclipse.org/
propuestas / technology.krikkit /
[186] P: Zhu, R. Wang, Q. Chen, Y. Liu, y W. Qin, “gateway IOT: Bridging
redes de sensores inalámbricos en Internet de las cosas “, en Proc. IEEE / IFIP octavo Int. Conf.
EUC, 2010, pp. 347-352.
[187] S. Guoqiang, C. Yanming, Z. Chao, y Z. Yanxu “, Diseño y imple-
mentación de una puerta de enlace IO inteligente “, en Proc. IEEE Int. Conf. IEEE cibernético, Phys. Soc.
Comput. GreenCom, iThings / CPSCom, 2013, pp. 720-723.
[188] L. Wu, Y. Xu, C. Xu, y F. Wang “, orientada a servicios Plug-con fi gura-play
pasarela para el desarrollo de aplicaciones de redes de sensores rápido y fácil “, en
Proc. SENSORNETS, 2013, pp. 53-58.
todos ellos?”EclipseCon, San Francisco, CA, EE.UU., 2014. [190] I. Ishaq, J.Hoebeke,
I.Moerman, andP.Demeester,“Internet ofThingsvir-
redes tuales: Llevar la virtualización de red para dispositivos con recursos limitados “, en Proc.
IEEE Int. Conf. GreenCom, 2012, pp. 293-300.
[191] X. Wang, JT Wang, X. Zhang, y J. Song, “comunicación Amultiple
normas del sistema IO compatible para uso médico,”en Proc. IEEE FTFC, 2013, pp. 1-4.
2376 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 4, CUARTO TRIMESTRE 2015

[192] YH Lin, Q. Wang, JS Wang, L. Shao, y J. Tang, “plata- IO Wireless
formulario basado en la tecnología SDR,”en Proc. IEEE Int. Conf. IEEE cibernético, Phys. Soc.
Comput. GreenCom, iThings / CPSCom, 2013, pp. 2245-2246.
[193] Z. Qin, G. Denker, C. Giannelli, P. Bellavista,
N. Venkatasubramanian, “Una arquitectura de red de software de fi nida por las cosas de
Internet-de-”, en Proc. IEEE NOMS, 2014, pp. 1-9.
[194] A. Al-Fuqaha, A. Khreishah, M. Guizani, A. Rayes, y M. Moham-
Madi, “Hacia una mejor integración horizontal entre los servicios de la IO,” IEEE Commun. Revista., De
agosto de 2015, que se publicará.
[195] MT Goodrich, y M. Mitzenmacher, “búsqueda floración invertible
tablas “, en Proc. 49ª Annu. Allerton, 2011, pp. 792-799.
Mehdi Mohammadi ( S'14) recibió la licenciatura en ingeniería
informática por la Universidad Kharazmi, Teherán, Irán, en 2003 y la
maestría en ingeniería informática (software) de la Universidad
y Sheikhbahaee (SHBU) Isfahan, Irán, en 2010. En la actualidad
trabaja hacia la Doctor en Filosofía. grado con el Departamento de
Ciencias de la Computación de la Universidad de Western Michigan
(UMM), Kalamazoo, MI, EE.UU.. Sus intereses de investigación
incluyen la Internet de las cosas, el futuro de Internet, las redes fi
nida de software-de, el cloud computing, la minería de datos, y el
lenguaje natural
tratamiento.
El Sr. Mohammadi ha servido como co-investigador en un proyecto de investigación que lleva a cabo la

Ala Al-Fuqaha ( S'00-M'04-SM'09) recibió el traducción de idiomas automática financiado por Unitec Instituto de Tecnología de Auckland, Nueva Zelanda.

MS y Ph.D. títulos en ingeniería eléctrica e informática de la También se desempeña como revisor de Wiley

Universidad de Missouri-Columbia, Columbia, MO, EE.UU., y la Seguridad y Redes de Comunicaciones Inalámbricas diario y un miembro del Comité del Programa
Universidad de Missouri-Kansas City, Kansas City, MO, EE.UU., en Técnico (TPC) de la rueda de la IO-NAT 2015. Recibió un Doctorado Ayudantía de la Tecnología de
1999 y 2004, respectivamente. En la actualidad es Profesor la Información de la UMM Bibliotecas en 2013. Él era el recipiente de cuatro becas de viaje de la
Asociado y Director del Laboratorio de Investigación de NEST, National Science Foundation para asistir a la conferencia GENI.
Departamento de Ciencias de la Computación de la Universidad de
Western Michigan, Kalamazoo, MI, EE.UU.. Se desempeñó como
Investigador Principal (IP) o Co-PI en varios proyectos de
investigación financiados por la NSF,

Qatar Foundation, Cisco, Boeing, AVL, Stryker, Wolverine, Traumasoft, y la Western Michigan University.
Sus intereses de investigación incluyen redes inalámbricas vehiculares (VANETs), la cooperación y la
etiqueta de acceso al espectro en las redes de radio cognitiva, servicios inteligentes en apoyo de la Internet
de las cosas, la gestión y la planificación de las redes de software de fi nida (SDN), servicios inteligentes
Mohammed Aledhari ( S'14) recibió el grado BE en informática de
para el ciego y el discapacitados visuales, el encaminamiento QoS en redes ópticas e inalámbricas, y el
la Universidad de Anbar, Ramadi, Irak, en 2003 y el grado de MS
análisis del rendimiento y la evaluación de informáticas y de telecomunicaciones redes de alta velocidad.
en informática de la Universidad de Basora, Basora, Irak, en 2010.
En la actualidad trabaja hacia el Ph.D. grado con el Departamento
de Ciencias de la Computación de la Universidad de Western
El Dr. Al-Fuqaha ha servido como miembro del Comité del Programa Técnico y un revisor de
Michigan, Kalamazoo,
muchas revistas y congresos internacionales. En la actualidad cumple en el Consejo Editorial de
John Wiley Seguridad y Redes de Comunicaciones revista, John Wiley Comunicaciones inalámbricas
MI, EE.UU.. Actualmente es Asistente de Investigación en el Centro de
y móviles Computing diario, Transacciones EAI en redes industriales y sistemas inteligentes,
Computación de Alto Rendimiento y grandes volúmenes de datos (CHPCBD),
la Western Michigan University, para diseñar e implementar una nueva
y Diario Internacional de Computación y Sistemas Digitales. Fue el ganador del Premio Investigador
transferencia de datos en cuenta
Destacado en la Facultad de Ingeniería y Ciencias Aplicadas, Universidad de Western Michigan, en
protocolo para grandes datos genómicos. Antes de unirse a CHPCBD, se desempeñó como Asistente de Re-
2014.
búsqueda en las redes de computadoras, sistemas integrados y Telecomunicaciones Laboratorio (NEST).
También se desempeñó como microcontroladores y PLC Embedded Software Engineer en el Drilling Company
Iraquí (IDC) a partir de enero de 2005 a agosto de 2011. Sus intereses de investigación incluyen Internet de las
Mohsen Guizani ( S'85-M'89-SM'99-F'09) recibi- do la BS (con
cosas, las redes, los grandes datos, cloud computing, aprendizaje automático, microcontroladores, y los robots .
distinción) y MS grados en ingeniería eléctrica y la MS y Ph.D.
El Sr. Aledhari era un recipiente de varios premios otorgados por el Ministro de Petróleo iraquí, por sus
grados en la ingeniería informática de Syracuse Uni- versidad,
contribuciones a la esfera de los microcontroladores. También era un recipiente del Premio de Ministro de
Syracuse, NY, EE.UU., en 1984, 1986, 1987, y 1990,
Educación Superior en Irak para sostener el promedio más alto en su programa de licenciatura.
respectivamente. En la actualidad es profesor en el Departamento
de Ciencias de la Computación e Ingeniería de la Universidad de
Qatar (QU), Doha. Anteriormente, se desempeñó como
Vicepresidente Asociado de Estudios de Posgrado de la QU en
2011-2014; el Presidente del Departamento de Ciencias de la
Computación, Western Michigan

Universidad, en el período 2002-2006; y el Presidente del Departamento de Ciencias de la Computación de la

Universidad de West Florida, en el período 1999-2002. También se desempeñó en cargos académicos en la
Universidad de Missouri-Kansas City, Universidad de ColoradoBoulder, Syracuse University y la Universidad de
Kuwait.
Sus intereses de investigación incluyen las comunicaciones inalámbricas y la informática móvil, redes
informáticas, la computación en nube, la seguridad informática y de redes inteligentes. El Dr. Guizani es
Miembro Senior de la ACM y miembro de la Sociedad de Comunicaciones del IEEE, IEEE Computer
Society, y ASEE. Actualmente es miembro de los consejos editoriales de varias revistas técnicas
internacionales y el fundador y editor en jefe de Wiley Comunicaciones inalámbricas y móviles Computing
(Http://www.interscience.wiley.com/jpages/1530-8669/). Es autor de nueve libros y más de 400
publicaciones en revistas arbitradas y conferencias (con un índice h = 30, de acuerdo a Google
Académico). El invitado editado una serie de números especiales en revistas y revistas IEEE.
También se desempeñó como miembro, Presidente, y Presidente General de una serie de
conferencias. Fue el Presidente del Comité Técnico inalámbrica IEEE Communications Society (WTC
2009-
2010) y el Presidente de la transmisión, acceso y sistemas ópticos (TAOS 2007-2009). Sirvió como el
orador distinguido IEEE Computer Society de 2003 a 2005. Recibió el premio a la mejor investigación
de ambas instituciones.
Moussa Ayyash ( M'98-SM'12) recibió el B.Sc. grado en ingeniería
eléctrica y de comunicaciones de la Universidad de Mu'tah,
Maw'tah, Jordan, en 1997, el M.Sc. grado en ingeniería eléctrica y
de comunicaciones de la Universidad de Jordania, Amman,
Jordania, en 1999, y el Ph.D. título en ingeniería eléctrica e
informática de Illinois Institute of Technology, Chicago, IL, EE.UU.,
en 2005. Él actualmente es de Profesor Asociado en el
Departamento de Estudios de la Información de la Universidad
Estatal de Chicago, Chicago. Él es el director del Centro de Infor-
mación y la Educación Nacional de Seguridad e Investigación. Sus líneas de investigación actuales abarcan
las áreas de comunicación de datos digitales y, las redes inalámbricas, comunicaciones de luz visible,
Internet de las cosas, y la reducción de la interferencia. El Dr. Ayyash es un miembro de las Sociedades de
Comunicaciones IEEE Computer yy un miembro de la Association for Computing Machinery.