Encuesta de protocolos estandarizados

para Internet de las cosas

Resumen: Internet de las cosas es una tecnología en crecimiento que se desarrolla en múltiples
campos, desde hogares inteligentes hasta la salud y las industrias. Desde una perspectiva
tecnológica, permite el desarrollo de nuevos protocolos y escenarios, ya que el conjunto de
protocolos de red estándar no puede hacer frente al creciente número de dispositivos conectados y
datos transmitidos. Este documento tiene como objetivo presentar varios protocolos
estandarizados, en diferentes niveles de red, desarrollados especialmente para dispositivos
integrados con poca memoria, bajo poder de procesamiento y baja velocidad de datos. También
proponemos escenarios de hogares inteligentes que solo utilicen protocolos estandarizados de IoT.

introduction

Recientemente, Internet of Things (IoT) se ha convertido en un importante campo de investigación.

Se puede describir como un sistema de comunicación donde cualquier dispositivo se puede
conectar a Internet y ser capaz de identificarse a otros objetos. Se puede aplicar en diferentes
dominios, desde el uso personal, como hogares inteligentes o dispositivos portátiles, hasta campos
como el monitoreo del entorno urbano, la atención médica, la automatización industrial o
emergencias.
En general, los dispositivos IoT tienen poca memoria, capacidad de batería reducida, capacidades
de procesamiento reducidas y condiciones de radio vulnerables. La pila TCP / IP estándar no es
adecuada para este entorno, por lo que los grupos de trabajo han comenzado a adaptar los
protocolos existentes a nuevas versiones para IoT. Se debe tener en cuenta un esquema de
direccionamiento, como IPv6, ya que hay miles de millones de nodos interconectados. Múltiples
grupos de trabajo ya comenzaron a estandarizar protocolos específicos de IoT, como 6LoWPAN
(RFC 4944 y RFC 6282), IEEE802.15.4 y ZigBee describen formas de habilitar IPv6 en entornos
restringidos. Otros requisitos se refieren a la seguridad y la privacidad, ya que el número de
ataques de denegación de servicio ha aumentado recientemente.
En la capa de aplicación, un nivel común En la capa de aplicación, una forma común de recuperar
y solicitar datos es usar arquitectura web, y más específica, HTTP. Esto utiliza URI como
identificadores de recursos y se basa en la arquitectura REST para publicar información. Para
incrustado
dispositivos, existe un grupo de trabajo IETF de Entornos Restringidos RESTful (CoRE), que tiene
como objetivo desarrollar protocolos RESTful, compatibles con HTTP para dispositivos con
recursos limitados. Especificaron CoAP, un protocolo de capa de aplicación para IoT. En este
documento, presentamos una encuesta de los protocolos estandarizados más utilizados para
Internet de las cosas. Investigamos protocolos de capa de aplicación (CoAP, MQTT), protocolos de
descubrimiento de servicio (mDNS, DNS-SD, uBonjour) y protocolos de infraestructura (IEEE
802.15.4, 6LoWPAN, LoRaWAN). Presentamos diferentes formas de integrar diferentes protocolos
de capa de aplicación como MQTT, CoAP y HTTP. Finalmente, proponemos un sistema hogareño
inteligente con nodos sensores inalámbricos y asistentes robóticos que utilizan protocolos
estandarizados de IoT (IEEE 802.15.4, 6LoWPAN, CoAP). El documento está organizado de la
siguiente manera. La segunda sección presenta los protocolos de capa de aplicación, el tercero los
métodos de descubrimiento de servicio, el cuarto la interacción entre protocolos y el quinto
presenta un escenario de hogar inteligente, que usa solo protocolos estandarizados. Finalmente,
se resumen algunas conclusiones.

II.PROTOCOLOS DE CAPA DE APLICACIÓN

 La capa de aplicación proporciona los servicios que los usuarios necesitan. Estos
protocolos manejan información entre pasarelas en redes locales e Internet, actualizan a
los usuarios con los últimos datos obtenidos y transmiten comandos desde las aplicaciones
hasta los dispositivos finales.
  CoAP

Hoy en día, las aplicaciones dependen de la arquitectura web, usando HTTP para obtener
información o actualizaciones. Esto se basa en el estilo arquitectónico REST (Representational
State Transfer), que hace que los recursos estén disponibles a través de URI. HTTP es bastante
complejo para dispositivos IoT pequeños, por lo que IETF especificó un nuevo protocolo basado en
REST CoRE working group. Este protocolo se llama protocolo de aplicación restringida
(CoP), un protocolo de transferencia web que intercambia datos entre servidores y clientes [1].
Utiliza UDP en lugar de TCP en la capa de transporte y define una "capa de mensaje" para tratar
las retransmisiones. Figura 1.

2017 21 ° Conferencia Internacional sobre Sistemas de Control y Ciencias de la Computación

presenta el encabezado CoAP, que tiene una longitud que varía de 4 a un máximo de 16 bytes [2].
Los primeros dos bits, "Ver" representan la versión de CoAP, establecida en 1 por ahora; define la
versión actual y otros valores están reservados para el futuro. El siguiente campo, "T" es el tipo de
transacción. Es un entero de 2 bits y sus valores posibles son 0, para mensajes confirmables, 1
para no confirmable, 2 para acuse de recibo y 3 para restablecer paquetes. "OC" es el recuento de
opciones, que se refiere al número de opciones establecidas en el paquete. "Código" en un entero
de 8 bits, dividido en una clase de 3 bits y un detalle de 5 bits. La clase puede indicar una solicitud
(0), una respuesta correcta (2), una respuesta de error del cliente (4) o una respuesta de error del
servidor (5). Un código de 0.00 significa un mensaje vacío. El "ID del mensaje" se utiliza para
detectar duplicados y para unir paquetes de tipo Acknowledgegment / Reset a paquetes de tipo
Confirmable / Non-Confirmable. Los valores "Token" se utilizan para emparejar solicitudes a
respuestas. Esto puede ir seguido de cero o más "Opciones". Si también hay una "Carga útil",
entonces está presente un marcador de prefijo (0xFF), para separar los dos últimos campos [3].

Algunas de las características más importantes proporcionadas por CoAP son la

observación de recursos, que se refiere a suscripciones a datos publicados
interesantes, transporte de recursos en bloque (intercambio de datos del
transceptor con actualizaciones parciales, para evitar gastos indirectos),
seguridad, junto con DTLS, descubrimiento de recursos, basado en URIs bien
conocidos [2]. Una de las ventajas más importantes es que puede interactuar con
HTTP a través de proxies. Es posible construir productos intermedios que ejecuten
CoAP por un lado y HTTP por el otro. Como hay métodos, solicitudes y códigos de
respuesta equivalentes, es fácil mapear estáticamente entre los dos protocolos.
Ambos usan URI para la identificación: "coap: //" y "http: //". Los proxies inversos
también se pueden habilitar para que los clientes HTTP estándar puedan acceder
de forma transparente a los servidores CoAP. También es posible asignar una
única solicitud HTTP a una solicitud CoAP de multidifusión. Las respuestas se
agregan en una sola respuesta HTTP y se envían al cliente [1].
Con respecto a las opciones de CoAP, algunas de las más importantes son Bloquear, Observar y
Descubrir. El primero se usa en el caso de paquetes más grandes. En general, los mensajes CoAP
de sensores de luz o temperatura implican pequeñas cargas útiles, pero en caso de actualizar el
firmware, se necesitan paquetes más grandes. CoAP no se basa en la fragmentación de IP y utiliza
la opción Bloquear. Esto significa que se envían múltiples paquetes en pares de solicitud-
respuesta. Permite que un servidor sea completamente apátrida y maneje cada transferencia por
separado.
Observe es una opción enviada por clientes a petición. En lugar de enviar múltiples mensajes GET
para obtener información sobre un recurso, pueden especificar esta opción y recibir mensajes
asíncronos cada vez que cambie. En entornos de máquina a máquina, los dispositivos deberían
poder descubrir recursos, de forma similar a las páginas HTTP "/ index /". Para esta página /.well-
known/scheme "está disponible.
Las descripciones de recursos también están estandarizadas y se pueden encontrar en los URI "/
well-knows / core" y se puede acceder a través de los paquetes GET [1].

 MQTT
Message Queue Telemetry Transport (MQTT) es un protocolo de mensajería que tiene
como objetivo conectar dispositivos integrados con aplicaciones y middleware,
estandarizados en 2003, por OASIS [4]. Está construido sobre la capa TCP y es adecuado
para dispositivos de bajo recurso. Se compone de tres elementos, suscriptor, editor y
corredor. El editor es el que envía los datos y los reenvía a través del intermediario a través
de suscriptores.
El corredor también actúa como un mecanismo de seguridad, pudiendo autorizar ambas
entidades. Dado que utiliza pocos recursos, se usa comúnmente en mensajes de máquina
a máquina, en atención médica, monitoreo o notificaciones de Facebook [2].
El encabezado de un mensaje MQTT tiene una longitud variable, entre 1 y 4 bytes. Los primeros
dos bits son fijos, luego el "Tipo de mensaje" puede obtener uno de los siguientes valores:
CONNECT (1), CONNACK (2), PUBLISH (3), SUBCRIBE (8) u otros. El siguiente campo es el
indicador "DUP". Si está configurado, entonces el mensaje es un duplicado y el servidor puede
haberlo recibido antes. Hay tres niveles de "QoS" para PUBLICAR mensajes que se pueden
encontrar en el encabezado. El campo "Retener" le dice al intermediario que conserve el mensaje y
lo envíe a los suscriptores como primer mensaje [2].

Cada cliente, publicado o suscriptor, envía un mensaje de "CONEXIÓN" al intermediario para

establecer una conexión. Para mantener viva la conexión, el cliente debe enviar mensajes
periódicos al intermediario, ya sea datos o ping. En el mensaje "CONEXIÓN", el cliente puede
enviar un mensaje de "voluntad", que sería publicado por el intermediario en caso de que no reciba
ningún mensaje de mantener vivo del cliente. Pueden enviar mensajes "PUBLICAR", que contienen
un tema y un mensaje, o pueden enviar mensajes de "SUSCRIBIR" para recibir paquetes. Además,
los clientes pueden enviar "SUSCRIBIRSE" para dejar de recibir mensajes sobre un tema
determinado y reconocen cada paquete que envían [5].

Hay dos especificaciones principales, MQTT y MQTT-SN. El último fue definido para redes de
sensores y fue optimizado para dispositivos de bajo ancho de banda, operados por batería y fallas
de enlace alto. Hay varias diferencias entre las dos implementaciones. En primer lugar, en MQTT-
SN, el mensaje "CONEXIÓN" se divide entre un mensaje obligatorio y dos mensajes opcionales,
que se utilizan para transferir el tema y el mensaje "Voluntad" al servidor. En el mensaje
"PUBLICAR", los nombres de los temas fueron reemplazados por ID. Antes de esto, se enviaban
mensajes de registro para obtener, desde el servidor, una identificación única para un tema
específico. En este caso, los clientes también deben ser informados de antemano por los ID
correspondientes. Además, se pueden agregar temas predefinidos o nombres cortos, para omitir el
registro. Estos son de dos bytes y son conocidos de antemano por los clientes y los editores. Se
agregó un procedimiento de descubrimiento para que los clientes obtengan la dirección de red de
una puerta de enlace operativa que se comunica con el intermediario. Los temas y el mensaje
"Will" son persistentes en el caso de MQTT-SN, y los clientes pueden modificarlos durante una
sesión.
Si los dispositivos están en modo de suspensión, los mensajes dirigidos a ellos se almacenan en el
servidor y se envían cuando se despiertan [6].

 CoAP versus MQTT

Thangavel et al. [7] realiza una comparación entre los dos protocolos que se ejecutan en el
mismo entorno. El middleware es extensible, tiene soporte para protocolos de aplicaciones
existentes y futuros, proporciona una API común para acceder a diferentes funcionalidades
y es adaptable, por lo que en el futuro podrá elegir un protocolo en ejecución basado en las
restricciones. En la primera prueba, se consideró la influencia de la pérdida de paquetes en
la demora. Con una tasa de pérdida inferior al 20%, MQTT tiene poca demora, pero en el
caso de tasas más altas, CoAP tiene un mejor rendimiento. Esto sucede porque CoAP se
ejecuta sobre UDP, tiene su propio esquema de retransmisión y evita la sobrecarga
implícita en TCP

retransmisiones La segunda prueba calcula la cantidad total de datos transferidos

en caso de diferentes valores de pérdida de paquetes. En el caso de CoAP, se
reenvían menos datos y los valores más altos se obtienen en MQTT cuando se
establece el nivel 2 de QoS, ya que requiere un intercambio de cuatro manos. Se
realizó otra prueba para comparar la sobrecarga para diferentes tamaños de
mensaje. Cuando la pérdida de paquetes es baja, CoAP genera menos
sobrecarga, independientemente del tamaño del mensaje. En el caso de tasas
más altas y paquetes más grandes, MQTT genera menos gastos generales. Esto
se puede explicar por el hecho de que existe un mayor riesgo de perder paquetes
grandes cuando se usa UDP que en el caso de TCP [7].

III. PROTOCOLOS DE DESCUBRIMIENTO DE SERVICIOS

En Internet, la arquitectura de descubrimiento más extendida se basa en el Servidor de nombres

de dominio (DNS), pero esta no es una opción adecuada para Internet de las cosas, porque los
dispositivos de IoT se unen o abandonan las redes con más frecuencia. Por lo tanto, se han
desarrollado dos extensiones, llamadas DNS-SD (Service Discovery) y mDNS (DNS de
multidifusión).
Los desafíos que deben enfrentar, relacionados con el Internet de las cosas, son la escalabilidad,
ya que se estima que, en 2020, habrá casi 50 mil millones de dispositivos conectados, dinamismo,
para dispositivos inteligentes portátiles, que puedan cambiar fácilmente las conexiones, los
dispositivos en modo de suspensión, que da lugar a una limitación de las consultas dirigidas a los
puntos finales y al tamaño de la carga útil, a medida que se transfieren menos datos.

Los directorios locales deberían extenderse para brindar información sobre otros
dominios donde haya recursos disponibles. Además, los directorios deben admitir
multidifusión, para consultas tales como "apagar todas las luces en la sala", donde
todos los puntos finales se tratan como uno solo. El acceso a los directorios se
debe hacer de una manera ya conocida y se debe usar una descripción común
para los servicios y atributos [8].
  mDNS and DNS-SD

mDNS (RFC6762) [9] es un servicio que puede realizar la tarea de un servidor DNS. En una red
local, cada cliente tiene un caché donde guarda el emparejamiento entre nombres y direcciones.
Cada vez que un dispositivo quiere obtener información de nombre, envía una consulta de
multidifusión y espera una respuesta. La máquina objetivo envía una respuesta de multidifusión en
la red y todos los dispositivos que la reciben guardan el emparejamiento en su caché local. Tiene el
ventaja de que no hay necesidad de un servidor dedicado y también se adapta fácilmente a los
cambios en la red [2].

DNS-SD (RFC6763) [10] es una solución propuesta por IETF ZeroConf WG que
reutiliza y amplía las capacidades del DNS. Utiliza los mismos tipos de consultas (AAA,
PTR) y permite ubicar y publicar servicios en una red [9]. Por ejemplo, los clientes que
desean obtener servicios de impresora en la red usan DNS-SD. Primero tienen que
obtener los nombres de los dispositivos que brindan el servicio requerido, luego usan
mDNS para obtener la dirección. Es esencial encontrar primero el nombre de host,
porque la dirección IP puede cambiar. El principal inconveniente de estos dos
protocolos es la necesidad de mantener entradas de caché en dispositivos con poca
memoria. Bonjour y Avahi son dos implementaciones bien conocidas basadas en DNS.

 uBonjour
uBonjour es un servicio liviano que combina mDNS y DNS-SD para direccionar y
descubrir servicios disponibles en una red. Proporciona descubrimiento estandarizado
y autoconfiguración sin ninguna dirección codificada, ambas necesarias en IoT.
Implementa los estándares definidos por los protocolos de DNS y los sistemas pueden
descubrirse entre sí sin ninguna puerta de enlace. Cuando un nodo de IoT solicita un
servicio, se agrega a la base de datos y se borran al recibir un mensaje de "servicio no
disponible" [11].
La resolución de nombres de host se basa en mDNS, lo que significa que se envía una solicitud de
multidifusión. Las respuestas del dispositivo con un registro A, que contiene la dirección. Este
mensaje se transmitirá a todos los dispositivos de escucha. En el caso de los servicios, se envía un
registro PTR de multidifusión. Si se encuentra el nombre del servicio, se envía un mensaje de
difusión que contiene la dirección y el puerto. De lo contrario, se dispara un tiempo de espera [11].

Para publicar un servicio, un nodo IoT debe enviar cuatro registros DNS
estándar y cada aplicación debe registrar una dirección, un nombre de host y
un puerto. Para eliminar un servicio, el dispositivo debe enviar un registro PTR
con el TTL establecido en 0. La actualización de un servicio implica volver a
enviar los cuatro registros con nuevos datos. Ocho registro de servicio son
compatibles por dispositivo [11].
Se pueden obtener optimizaciones adicionales al minimizar el tráfico de datos, mediante el uso de
dos métodos. El primero, Supresión de respuesta conocida. Si un nodo ya tiene una respuesta más
antigua a una consulta y quiere obtener información más nueva, envía una consulta que contiene
no solo la pregunta, sino también los datos que ya tiene. El respondedor no envía nada si la
información correcta ya está en la consulta. De lo contrario, envía actualizaciones. El otro es
Supresión de preguntas duplicadas. Si un servidor desea enviar una consulta y ve que otro
servidor está enviando la misma solicitud, entonces debe esperar la respuesta de difusión [12].
Otra optimización es One-Way Traffic, que pone un dispositivo en modo pasivo. Publica servicios
periódicamente y responde a las solicitudes entrantes. Por lo tanto, evita la resolución activa de
nombres de host y el análisis de consultas desde otros dispositivos.

IV. INFRASTRUCTURE PROTOCOLS

En la capa de acceso físico y de medios, los protocolos estandarizados están diseñados para
diferentes necesidades. Parte de ellos están especializados para redes locales, que requieren baja
distancia y baja potencia. Están dirigidos especialmente a edificios u hogares inteligentes. Otros
pueden ofrecer un rango alto, pudiendo satisfacer las necesidades de ciudades inteligentes o
entornos industriales.

 IEEE 802.15.4
 El estándar IEEE 802.15.4 [13] fue especialmente diseñado para dispositivos
incrustados de baja potencia, corto alcance y baja velocidad de bits. Los grupos de
trabajo IEEE 802.15 tienen como objetivo mantener los costos de hardware bajos,
para extender la compatibilidad del protocolo entre los sensores. El protocolo
describe la capa física y la subcapa de control de acceso a medios [14].

La capa física es responsable de la activación y desactivación del transceptor de radio, la

recepción y transmisión de datos, la selección de un canal y la escucha en él. En esta capa, hay
dos frecuencias admitidas. La banda baja (868/915 MHz), que usa la modulación de la tecla de
cambio de fase binaria y la banda alta (2.4GHz) que usa modulación por desplazamiento de fase
en cuadratura desplazada. Hay 27 canales disponibles, 11 en banda baja y 16 en banda alta. Las
velocidades de bits sin procesar son de 20-40 kbps en banda baja y 250 kbps en banda alta. Al
usar estos
modulaciones y técnicas de difusión, las transmisiones son robustas y resistentes al ruido [15].
En la capa MAC, CSMA / CA está habilitado, junto con la estructura y la seguridad del intervalo de
tiempo opcional. Cada vez que un dispositivo desea enviar datos, el medio es verificado por la
capa PHY. Si está ocupado, la transmisión se pospone durante un cierto período de tiempo [14].
Las unidades de transmisión se denominan Unidad de datos de protocolo físico para la Capa 1 y la
Unidad de datos de protocolo MAC. El encabezado PPDU tiene dos campos, luego se agrega la
carga útil. El campo SYNC se utiliza para la sincronización del reloj y el campo PHY contiene la
longitud de la carga útil. En la trama MAC, los primeros dos bytes indican el tipo de cuadro [14].
Hay cuatro tipos de marcos definidos en el estándar. Los primeros, los marcos de baliza son
utilizados por los coordinadores para describir la forma en que se puede acceder a los canales.
Luego, hay marcos de datos y reconocimientos enviados como respuestas para el control y los
paquetes de datos. Los últimos marcos de control se utilizan para la administración de redes, como
asociaciones o disociaciones [15]. La siguiente bandera, el número de secuencia, es utilizada por
los agradecimientos y se refiere al marco recibido. Luego, hay información de direccionamiento,
relacionada con la fuente, las direcciones de destino y la seguridad.
Los dos últimos bytes representan la suma de comprobación, utilizada para la integridad de los
datos.
Los dispositivos se clasifican en dos categorías: función completa (FFD) y dispositivos de
función reducida (RFD). Un RFD puede comunicarse solo con un FFD, mientras que un FFD puede
comunicarse con ambos tipos. Estos últimos tienen, generalmente, el papel de coordinadores.
Mantienen una tabla de enrutamiento y son responsables de la creación y el mantenimiento de la
red. Las topologías estándar en 802.15.4 incluyen star, con un FFD central y varios RFD que se
comunican con él, peer-to-peer (malla), donde hay un coordinador, varios FFD y RFD y clúster, que
tienen un coordinador, un FFD y varios RFD [2].
Una situación interesante ocurre cuando los dispositivos 802.11 y 802.15.4 se ejecutan en la
misma área y usan la frecuencia de 2.4 GHz. Dos situaciones fueron analizadas. El primer caso es
el

uno cuando las transmisiones 802.11b interfieren con las comunicaciones

802.15.4. La degradación es más alta si las frecuencias no se cambian con
7MHz. Además, hay más errores para paquetes más grandes. En el
segundo caso, las transmisiones inalámbricas 802.11b / g son interferidas.
Aquí, hay errores cuando los paquetes WiFi son más grandes que
600bytes y el desplazamiento entre las frecuencias centrales es de 2MHz
[15]. La seguridad se proporciona en la capa MAC, utilizando AES-128 con
modo de operación CCM. Admite 8 niveles de seguridad, donde 0 significa
no seguro, los niveles 1 a 3 proporcionan solo integridad y autenticación,
mientras que los niveles 4 a 7 también proporcionan confidencialidad de
datos [13].

 6LoWPAN

6LowPAN es desarrollado por un grupo de trabajo IETF especialmente para redes pequeñas y
dispositivos integrados interconectados por IEEE 802.15.4 en RFC4944 [16]. Mantiene una red
IPv6, pero con encabezados comprimidos. Se agrega una nueva capa, entre la red y el enlace de
datos, responsable de la fragmentación, el reensamblaje, la compresión del encabezado y el
enrutamiento de la capa de enlace de datos para el salto múltiple [16]. El primer byte del
encabezado de encapsulación identifica el siguiente encabezado. Los primeros tres bits se utilizan
para la indicación, mientras que los otros tienen diferentes propósitos, dependiendo del tipo de
encabezado. Si son 00x, entonces este no es un cuadro 6LoWPAN y se usan si existe coexistencia
de protocolos. 010 significa sin comprimir o HC1 comprimido y el tipo de la dirección puede
determinarse por los últimos 5 bits. 10x significa que el siguiente encabezado es un encabezado de
malla y los siguientes 5 bits se usan para el enrutamiento. 11x es un encabezado de fragmentación
[16]. HC1 es la técnica de compresión principal definida en RFC4944 [16]. Se utiliza para paquetes
que contienen direcciones de capa de enlace y elimina los campos comunes, como Versión, TC,
etiqueta de flujo, no envía las direcciones de capa de enlace (que se pueden calcular desde el
encabezado 802.15.4) y el prefijo estándar longitud. El siguiente campo de encabezado está
limitado a TCP, UDP e ICMP [16]. RFC 6282 agrega dos nuevas técnicas de compresión,
LOWPAN_IPHC y LOWPAN_NHC. El primero usa 13 bits para la compresión. Elimina el campo
Versión y comprime la clase de tráfico y la etiqueta de flujo en 2 bits. El límite de salto tiene
asignados 2 bits, suponiendo que está configurado en 1, 64 o 255. Las direcciones IPv6 globales
también se transforman y pueden determinarse utilizando bits de compresión de dirección de
origen (SAC) y compresión de dirección de destino (DAC), junto con la dirección de origen Modo
(SAM) [17].
El estándar no especifica ningún mecanismo de seguridad y utiliza las opciones de capa MAC en el
protocolo 802.15.4 [16].

 LoRaWAN
Como parte de las tecnologías desarrolladas para IoT se centran en dispositivos
cercanos, LoRaWAN es una solución diseñada para grandes distancias. Es
adecuado para ciudades inteligentes o proyectos de agricultura inteligente, donde
las aplicaciones deben enviar poca cantidad de datos a grandes distancias. El
 protocolo consta de dos partes, LoRA, que especifica la capa física capaz de crear
enlaces de comunicación largos y LoRaWAN, que define la arquitectura del
sistema para la red [18].

En el nivel físico, usa el espectro extendido chirp, una señal sinusoidal cuya frecuencia aumenta y
disminuye con el tiempo. Tiene las mismas características que proporciona la modulación FSK,
pero ofrece la ventaja de distancias más grandes [18].
En cuanto a la arquitectura de red, existen cuatro tipos de dispositivos: nodos, puertas de enlace,
servidor de red y servidor de aplicaciones. Los nodos no están asociados a una puerta de enlace
específica, sino que envían datos que pueden ser recibidos por múltiples concentradores.
Cada uno de ellos reenviará los paquetes recibidos a un servidor de red en la nube y será
responsable de filtrar los paquetes duplicados, realizar comprobaciones de seguridad y enviar
acuses de recibo a través de la puerta de enlace óptima. Los nodos son asincrónicos y se activan
cuando tienen datos para enviar o cuando están programados. No necesitan mantener un reloj
interno sincronizado con la red, lo que brinda la ventaja de una mayor duración de la batería. LoRa
se basa en la modulación spreadspectrum, por lo que las señales son ortogonales entre sí cuando
se utilizan diferentes factores de dispersión. Las pasarelas tienen incorporado un transceptor
multimodelo, por lo que pueden escuchar datos en múltiples canales a la vez, y así poder
adaptarse a una gran cantidad de nodos. Los dispositivos cercanos a las puertas de enlace no
cambian a la velocidad de datos más baja, cambian a valores más altos para llenar el espacio,
enviar más rápido y dejar más espacio para que los otros transmitan [18].
Hay tres tipos de dispositivos, Clase A (sensores alimentados por batería), Clase B (actuadores
con batería) y Clase C (actuadores con alimentación principal). Los dispositivos de Clase A son los
más eficientes desde el punto de vista energético, pueden enviar datos y luego tienen dos
ventanas de recepción cortas, cuando esperan los mensajes. Si el servidor no responde en ese
período de tiempo, entonces tiene que esperar hasta recibir otro mensaje del dispositivo. Los
dispositivos de clase B tienen un intervalo de tiempo configurable adicional cuando pueden recibir
información. Para despertarse, la puerta de enlace envía una baliza de sincronización. Los
dispositivos de Clase C pueden obtener datos en cualquier momento, excepto el período de tiempo
cuando están transmitiendo [18].
LoRaWAN integra dos capas de seguridad, una en la red y la otra en la capa de aplicación. El
primero garantiza la autenticación, mientras que el otro cifra los datos para que el operador de red
no pueda acceder a los datos de la aplicación del usuario. Ambos usan AES con una longitud de
clave de 128 bits [18].

V. INTEGRACIÓN ENTRE PROTOCOLOS DE APLICACIÓN

A gran escala, en IoT, los dispositivos se pueden dividir en dos categorías: ricos en recursos, los
que admiten la pila TCP / IP y los dispositivos restringidos. Los primeros son los que admiten
aplicaciones desarrolladas sobre CoAP, MQTT, REST, AMQP y otros. Además, los dispositivos
basados en microcontroladores, por ejemplo, deberían tener la capacidad de comunicarse con
dispositivos "inteligentes".
A nivel de aplicación, hay varias soluciones implementadas. Uno de ellos es Ponte, desarrollado
por el grupo Eclipe IoT. Su objetivo es crear un puente entre CoAP, MQTT y HTTP. Expone una
API REST compatible y puede convertir varios formatos de datos, como JSON, XML o Byson.
Funciona
como una puerta de enlace entre CoAP y HTTP, que utiliza el mismo formato de datos y como
intermediario para MQTT.
Otro proyecto de Eclipse es Franca, construido para la industria automotriz, pero puede ampliarse
a entornos IoT. Su objetivo es integrar software de diferentes proveedores, utilizando diversos
marcos, plataformas y herramientas de comunicación entre procesos. Tiene el papel de un centro,
traduciendo el código a otro idioma. Contiene lenguajes de descripción de interfaz y un editor,
mecanismos de generación de código, especificación de comportamiento dinámico entre clientes y
servidores y creación rápida de prototipos de interfaz.
Para la definición de interfaz, Eclipse también proporciona Vorto, una herramienta que mantiene
modelos de metainformación y proporciona generación de código. Los fabricantes de dispositivos
pueden crear un repositorio, utilizando un marco de modelado proporcionado por Eclipse, donde
pueden agregar información sobre funcionalidades proporcionadas. Un desarrollador puede
acceder a los repositorios, invocar la herramienta de generación de código y crear las solicitudes.
Ligero M2M es un protocolo de administración de dispositivos que proporciona una forma unificada
de administrar dispositivos de forma remota. La implementación actual se basa en CoAP y usa
DTLS para seguridad. Define una arquitectura usando objetos REST. Aunque puede aplicarse a
redes de sensores inalámbricos o dispositivos celulares, por ahora solo es compatible con IP [19].
Otro enfoque es la virtualización. Se crea una red IoT-Virtual, donde se incluyen todos los
dispositivos, incluso los de recursos limitados. Se puede establecer sobre la capa 3 para objetados
conectados a Internet, o sobre la capa 2, para sensores restringidos. En el interior, las aplicaciones
y los servicios solo ven la capa lógica. Esto se puede usar al particionar una red de sensores
inalámbricos. Si los dispositivos son mantenidos por diferentes administradores, se pueden dividir
en varias redes virtuales y solo se podrá acceder a una parte de ellas. Esta técnica también se
puede usar para agregar redes de sensores separadas. En este caso, se pueden conectar usando
un túnel de Capa 3 y permitiendo una comunicación segura. Además, una WSN se puede extender
con dispositivos no restringidos, como servidores en la nube que recopilan datos [20].

VI. USE CASE: SMART HOME

Una implementación interesante para Internet of Things es un escenario de hogar inteligente que
además del sistema de monitoreo doméstico también incluye un asistente de robot inteligente. Este
sistema tiene el objetivo principal de mejorar la calidad de vida asistiendo al usuario en su vida
diaria.
Las capacidades de detección del sistema de monitoreo doméstico pueden representarse
mediante nodos de sensores inalámbricos de baja potencia habilitados para IoT. Los nodos utilizan
protocolos WSN estandarizados y se conectan a la puerta de enlace de la residencia. El uso del
paradigma IoT nos permite desacoplar las capacidades de detección del sistema del componente
de procesamiento. El procesamiento puede realizarse en el sitio, para usuarios conscientes de la
privacidad, o en la nube, para mayor flexibilidad, representada por capacidades de procesamiento
y almacenamiento casi ilimitadas e interacción con otros servicios.
Tener un sistema mediado por Internet permite varias opciones para interactuar con el entorno y
cerrar el ciclo de retroalimentación. Los datos procesados pueden ser igualmente fáciles de
acceder desde servidores en el sitio o desde la nube mediante varias aplicaciones asistentes. Esto
podría llegar a tener asistentes de robots vagando por la casa que ayudan a los usuarios en su
vida cotidiana [21]. El sistema puede aprender hábitos de los usuarios basándose en datos
detectados y enviar asistentes de robots para ayudarlo con varias tareas: despertarse por la
mañana, presentar el clima y el tránsito en días laborables, mostrar los eventos de la casa perdidos
por la noche y seleccionar recetas de cocina para la cena.
Los asistentes del robot son dispositivos habilitados para IoT, lo que significa que pueden servir al
usuario de forma remota, si lo desean, o pueden interactuar directamente con otros dispositivos IoT
en la casa (por ejemplo, nodos de sensores, dispositivos, dispositivos de usuario). En el sistema
basado en la nube, los asistentes aún podrían funcionar incluso si la conectividad a Internet es
limitada, interactuando directamente con otros dispositivos en la casa, en lugar de ir al centro de
procesamiento para obtener información. Esta situación proporcionará menos funcionalidad que el
sistema completo, pero aún permitirá a los usuarios hacer consultas básicas al sistema.
 Los principales componentes del sistema de hogar inteligente (nodos de
sensores, puerta de enlace, asistentes de robot, centro de procesamiento)
utilizan protocolos estandarizados para comunicarse entre sí. Todos los
componentes del sistema son direccionables a través de IPv6, a través de
Internet.
Los nodos del sensor y la puerta de enlace ejecutan una pila de red que incluye IEEE 802.15.4,
6LoWPAN y CoAP. Estos protocolos estandarizados han sido especialmente diseñados para
dispositivos con recursos limitados, como se especifica en la Sección II y IV. Los nodos de sensor
son interrogados por el centro de procesamiento a través de las solicitudes de CoAP y envían los
datos recopilados a través de las respuestas de CoAP.
Además, la puerta de enlace puede traducir de 6LoWPAN a IPv6 y viceversa, para habilitar la
comunicación entre los nodos del sensor y el servidor. Esto permite la integración entre las redes
6LoWPAN e IPv6.
Los asistentes del robot ejecutan una pila completa de TCP / IP y se comunican directamente con
los servidores de Internet para obtener información para el usuario. Ellos interrogan el centro de
procesamiento a través de HTTPS y reciben datos en formato JSON.
Sin embargo, los asistentes también pueden comunicarse con los nodos del sensor enviando
solicitudes de CoAP. Esto se hace para obtener datos en bruto muy rápido, por ejemplo, cuando un
asistente de robot quiere averiguar la posición del usuario.
Por lo tanto, el sistema de hogar inteligente propuesto integra tecnología de vanguardia, como
asistentes de robot y nodos de sensores inalámbricos, y utiliza solo protocolos estandarizados para
la comunicación entre sus componentes.
 VII. CONCLUSIONS
La idea de Internet of Things está creciendo rápidamente y se está convirtiendo en parte de la vida
humana moderna. Su objetivo es mejorar la calidad de vida, mediante la automatización, conectar
dispositivos, aplicaciones y publicar más información rápidamente.
Esta encuesta ofrece una breve descripción de varias tecnologías estandarizadas desarrolladas
especialmente para dispositivos integrados y entornos restringidos. Presentamos protocolos de
aplicaciones y una comparación entre dos de ellos, descubrimiento de servicios y la forma en que
se extendió DNS para redes que cambian los protocolos de capa física y rápida desarrollados para
transmisiones de bajo rango y largas.
Además, se proporcionó un escenario IoT donde se usan estos protocolos junto con las
tecnologías TCP / IP. Propusimos un escenario de hogar inteligente basado en nodos de sensores
y asistentes de robots que utiliza solo protocolos estandarizados para permitir la comunicación
entre los diferentes componentes.