Material de Estudio2

1
Contenido Pág.
Módulo 2: Protocolos, estándares y modelos de comunicación

del Internet de las Cosas

Unidad 1: Protocolos para el Internet de las Cosas 3

1.1. Introducción 3
1.2. Arquitectura de protocolos TCP/IP 5
1.2.1. Descomposición en Niveles de TCP/IP 6
1.3. Protocolos del Internet de las Cosas 9
1.3.1. Transporte y Red 10
1.3.2. Sesión 17
1.3.3. Presentación 18
1.3.4. Aplicación 19
Unidad 2: Estándares de Comunicación en el Internet de la Cosas 20

2.2. Estandares para el Internet de las Cosas 22
2.2.1. AllSeen Alliance 22
2.2.2. Open Interconnect Consortium 22
2.2.3. Zigbee 23
2.2.4. Threat, de Google Nest 23
2.2.5. Apple HomeKit 24
2.2.6. FIWARE 24
Unidad 3: Modelos de Comunicación 25

3.2. Comunicación Dispositivo a Dispositivo 26
3.3. Comunicaciones Dispositivo a la Nube 27
3.4. Modelo Dispositivo a Puerta de Enlace 28
3.5. Modelo de Intercambio de Datos a Través del Back-End 20
3.6. Modelos de Comunicación de la Internet de las Cosas: Resumen 31
Bibliografía: 33
2
Unidad I: Protocolos para el Internet de las Cosas
1.1 Introducción
Realizar simplemente la conexión física entre los dispositivos finales no es suficiente para habilitar la
comunicación. Para que se produzca la comunicación, los dispositivos deben saber cómo comunicarse y
ese saber cómo comunicarse se realiza utilizando protocolos, mecanismos que indican la forma de cómo
hacerlo.
Figura No. 1 El circuito de la comunicación
Fuente: https://www.bing.com/images
La comunicación comienza con un mensaje, que se debe enviar desde un emisor hasta un receptor regi-
do por protocolos que deben respetarse para que el mensaje se envíe por el canal correspondiente y se
reciba de manera adecuada.
Para que el mensaje llegue de forma satisfactoria, se debe cumplir con una estructura, con unas reglas
y procedimientos que deben respetarse para el envío y la recepción de datos a través de una red que
denominamos protocolos, tales como1:
• Codificación de los mensajes.
• Formato y encapsulación del mensaje.
• Tamaño del mensaje.
• Temporización del mensaje
• Opciones de entrega del mensaje.
1 https://www.slideshare.net/groberth/clase-5-protocolos-y-comunicaciones-de-red
3
Existen diversos protocolos de acuerdo a cómo se espera que sea la comunicación. Algunos protocolos,
por ejemplo, se especializarán en el intercambio de archivos (FTP); otros pueden utilizarse simplemente
para administrar el estado de la transmisión y los errores (como es el caso de ICMP).
En Internet, los protocolos utilizados pertenecen a una sucesión de protocolos o a un conjunto de pro-
tocolos relacionados entre sí. Este conjunto de protocolos se denomina TCP/IP.
TCP/IP son las siglas de Protocolo de Control de Transmisión/Protocolo de Internet (en inglés Transmis-
sion Control Protocol/Internet Protocol), un sistema de protocolos que hacen posibles servicios Telnet,
FTP, E-mail, y otros entre ordenadores que no pertenecen a la misma red2. Contiene los siguientes pro-
tocolos: HTTP, FTP, ARP, ICMP, IP, TCP, UDP, SMTP, Telnet, NNTP. (Ver figura No.2)
Figura No. 2 Protocolo TCP/IP
El protocolo IP es parte de la capa de Internet del conjunto de protocolos TCP/IP. Es uno de los protoco-
los de Internet más importantes, ya que permite el desarrollo y transporte de datagramas de IP (paquetes
de datos), aunque sin garantizar su entrega. En realidad, el protocolo IP procesa datagramas de IP de ma-
nera independiente al definir su representación, ruta y envío3. Generalmente los protocolos se clasifican
en dos categorías según el nivel de control de datos requerido4:
2 http://www.masadelante.com/faqs/tcp-ip
3 https://es.ccm.net/contents/274-el-protocolo-ip
4 https://es.ccm.net/contents/275-protocolo-de-comunicacion
4
• Los protocolos orientados a conexión: son protocolos que controlan la transmisión de datos durante
una comunicación establecida entre dos máquinas. En tal esquema, el equipo receptor envía acuses
de recepción durante la comunicación, por lo cual el equipo remitente es responsable de la validez de
los datos que está enviando. Los datos se envían entonces como flujo de datos. Por ejemplo TCP es
un protocolo orientado a conexión.
• Los protocolos no orientados a conexión: son un método de comunicación en el cual el equipo remi-
tente envía datos sin avisarle al equipo receptor, y este recibe los datos sin enviar una notificación de
recepción al remitente. Los datos se envían entonces como bloques (datagramas). Por ejemplo UDP
es un protocolo no orientado a conexión.
Un protocolo define únicamente cómo deben comunicar los equipos, es decir, el formato y la secuencia
de datos que van a intercambiar. No define cómo se programa el software para que sea compatible con
el protocolo, esto se denomina implementación o la conversión de un protocolo a un lenguaje de pro-
gramación.
Las especificaciones de los protocolos nunca son exhaustivas. Asimismo, es común que las implementa-
ciones estén sujetas a una determinada interpretación de las especificaciones, lo cual genera especifici-
dades de ciertas implementaciones o, aún peor, incompatibilidad o fallas de seguridad5.
Los protocolos son importantes en la comunicación entre dispositivos, para IoT el protocolo TCP/IP es
fundamental, a continuación, se presenta la arquitectura de este protocolo.
1.2 Arquitectura de Protocolos TCP/IP6
Para poder solucionar los problemas que van ligados a la comunicación de ordenadores dentro de la red
Internet, se tienen que tener en cuenta una serie de particularidades sobre las que ha sido diseñado
TCP/IP, con las siguientes características:
• Los programas de aplicación no tienen conocimiento del hardware que se utilizara para realizar la
comunicación (módem, tarjeta de red, entre otros).
• La comunicación no está orientada a la conexión de dos máquinas, eso quiere decir que cada paquete
de información es independiente, y puede viajar por caminos diferentes entre dos máquinas.
• La interfaz de usuario debe ser independiente del sistema, así los programas no necesitan saber sobre
qué tipo de red trabajan.
• El uso de la red no impone ninguna topología en especial (distribución de los distintos ordenadores).
5 ttps://es.ccm.net/contents/275-protocolo-de-comunicacion
6 http://www.mailxmail.com/curso-que-son-redes/que-es-tcp-ip
5
De esta forma, podremos decir, que dos redes están interconectadas, si hay una máquina común que
pase información de una red a otra. Además, también podremos decir que una red de Internet virtual
realizará conexiones entre redes, que a cambio de pertenecer a la gran red, colaborarán en el tráfico de
información procedente de una red cualquiera, que necesite de ella para acceder a una red remota. Todo
esto independiente de las máquinas que implementen estas funciones, y de los sistemas operativos que
estas utilicen7.
1.2.1 Descomposición en Niveles de TCP/IP8.
Toda arquitectura de protocolos se descompone en una serie de niveles, usando como referencia el mo-
delo (OSI) Open Systems Interconnection (Interconexión de Sistemas abiertos). Esto se hace para poder
dividir el problema global en sub-problemas de más fácil solución.
A diferencia de OSI, formado por siete niveles o capas, TCP/IP se descompone en cuatro niveles, tres
niveles software y un nivel hardware. Describiremos los niveles de software, los cuales tienen cierto pa-
ralelismo con el modelo OSI. (Ver figura No. 3)
Figura No. 3 Modelo OSI
6
Niveles de TCP/IP
1. Nivel de Aplicación.
Constituye el nivel más alto de la torre TCP/IP. A diferencia del modelo OSI, se trata de un nivel simple
en el que se encuentran las aplicaciones que acceden a servicios disponibles a través de Internet. Estos
servicios están sustentados por una serie de protocolos que los proporcionan. Por ejemplo, tenemos el
protocolo FTP (File Transfer Protocol), que proporciona los servicios necesarios para la transferencia de
ficheros entre dos ordenadores.
Otro servicio, sin el cual no se concibe Internet, es el de correo electrónico, sustentado por el protocolo
SMTP (Simple Mail Transfer Protocol).
2. Nivel de Transporte.
Este nivel proporciona una comunicación extremo a extremo entre programas de aplicación. La máquina
remota recibe exactamente lo mismo que le envió la máquina origen. En este nivel el emisor divide la
información que recibe del nivel de aplicación en paquetes, le añade los datos necesarios para el control
de flujo, control de errores, y se los pasa al nivel de red junto con la dirección de destino.
En el receptor, este nivel se encarga de ordenar y unir las tramas para generar de nuevo la información
original.
Para implementar el nivel de transporte se utilizan dos protocolos:
• UDP (User Datagram Protocol): proporciona un nivel de transporte no fiable de datagramas, ya que
apenas añade información al paquete que envía al nivel inferior, solo brinda la información necesaria
para la comunicación extremo a extremo. Lo utilizan aplicaciones como NFS y RPC, pero sobre todo
se emplea en tareas de control.
• TCP (Transport Control Protocolo): es el protocolo que proporciona un transporte fiable de flujo de
bits entre aplicaciones. Está pensado para poder enviar grandes cantidades de información de forma
fiable, liberando al programador de aplicaciones de la dificultad de gestionar la fiabilidad de la cone-
xión (retransmisiones, perdidas de paquete y orden en que llegan los paquetes. Pero la complejidad
de la gestión de la fiabilidad tiene un coste en eficiencia, ya que para llevar a cabo las gestiones ante-
riores se tiene que añadir bastante información a los paquetes a enviar. Debido a que los paquetes a
enviar tienen un tamaño máximo, como más información añada el protocolo para su gestión, menos
información que proviene de la aplicación podrá contener ese paquete. Por eso, cuando es más im-
portante la velocidad que la fiabilidad, se utiliza UDP, en cambio TCP asegura la recepción en destino
de la información a transmitir.
7
3. Nivel de Red.
Coloca la información que le pasa el nivel de transporte en datagramas IP, le añade cabeceras necesaria
para su nivel y lo envía al nivel inferior. Es en este nivel donde se emplea el algoritmo de encamina-
miento, al recibir un datagrama del nivel inferior, decide en función de su dirección, si debe procesarlo y
pasarlo al nivel superior, o bien encaminarlo hacia otra máquina. Para implementar este nivel se utilizan
los siguientes protocolos:
• IP (Internet Protocol): es un protocolo no orientado a la conexión, con mensajes de un tamaño máxi-

mo. Cada datagrama se gestiona de forma independiente, por lo que dos datagramas pueden utilizar
diferentes caminos para llegar al mismo destino, provocando que lleguen en diferente orden o bien
duplicados. Es un protocolo no fiable, eso quiere decir que no corrige los anteriores problemas, ni
tampoco informa de ellos. Este protocolo recibe información del nivel superior y le añade la informa-
ción necesaria para su gestión (direcciones IP, checksum)
• ICMP (Internet Control Message Protocol): proporciona un mecanismo de comunicación de informa-

ción de control y de errores entre maquinas intermedias por las que viajaran los paquetes de datos.
Esto datagramas los suelen emplear las maquinas (gateways, host) para informarse de condiciones
especiales en la red, como la existencia de una congestión, la existencia de errores y las posibles pe-
ticiones de cambios de ruta. Los mensajes de ICMP están encapsulados en datagramas IP.
• IGMP (Internet Group Management Protocol): este protocolo está íntimamente ligado a IP. Se emplea
en máquinas que emplean IP multicast. El IP multicast es una variante de IP que permite emplear
datagramas con múltiples destinatarios.
También en este nivel tenemos una serie de protocolos que se encargan de la resolución de direcciones:
• ARP (Address Resolution Protocol): cuando una maquina desea ponerse en contacto con otra conoce
su dirección IP, entonces necesita un mecanismo dinámico que permite conocer su dirección física.
Entonces envía una petición ARP por broadcast (o sea a todas las maquinas). El protocolo establece
que solo contestará a la petición, si esta lleva su dirección IP. Por lo tanto solo contestará la máquina
que corresponde a la dirección IP buscada, con un mensaje que incluya la dirección física. El software
de comunicaciones debe mantener una caché con los pares IP-dirección física. De este modo la si-
guiente vez que hay que hacer una transmisión a esa dirección IP, ya conoceremos la dirección físico
• RARP (Reverse Address Resolution Protocol): a veces el problema es al revés, o sea, una máquina solo
conoce su dirección física, y desea conocer su dirección lógica. Esto ocurre, por ejemplo, cuando se
accede a Internet con una dirección diferente, en el caso de PC que acceden por módem a Internet,
y se le asigna una dirección diferente de las que tiene el proveedor sin utilizar. Para solucionar esto
se envía por broadcast una petición RARP con su dirección física , para que un servidor pueda darle
su correspondencia IP.
8
• BOOTP (Bootstrap Protocol): el protocolo RARP resuelve el problema de la resolución inversa de di-
recciones, pero para que pueda ser más eficiente, enviando más información que meramente la direc-
ción IP, se ha creado el protocolo BOOTP. Este además de la dirección IP del solicitante, proporciona
información adicional, facilitando la movilidad y el mantenimiento de las máquinas.
4. Nivel de Acceso a Red9.
Este nivel se limita a recibir datagramas del nivel superior (nivel de red) y transmitirlo al hardware de la
red. Pueden usarse diversos protocolos:
La interconexión de diferentes redes genera una red virtual en la que las maquinas se identifican me-
diante una dirección de red lógica. Sin embargo a la hora de transmitir información por un medio físico se
envía y se recibe información de direcciones físicas. Un diseño eficiente implica que una dirección lógica
sea independiente de una dirección física, por lo tanto es necesario un mecanismo que relacione las di-
recciones lógicas con las direcciones físicas. De esta forma podremos cambiar nuestra dirección lógica IP
conservando el mismo hardware, del mismo modo podremos cambiar una tarjeta de red, la cual contiene
una dirección física, sin tener que cambiar nuestra dirección lógica IP
1.3 Protocolos del Internet de las Cosas
Un gran desafío de IoT es la interoperatividad, conectar dispositivos en plataformas IoT es un gran reto,
existen varios protocolos para llevar a cabo la interoperabilidad, algunos son propietarios que fueron
diseñados para un propósito específico (control industrial por ejemplo) y que no son directamente inte-
grables con IP y otros que son estándares abiertos.
Dado que los dispositivos IoT son pequeños, baratos y de muy bajo consumo, IP no es una solución di-
rectamente aplicable para IoT, IP es un protocolo sencillo, que solo lleva el mensaje hasta el nodo, siendo
necesario la pila TCP/IP completa.
Un protocolo IoT debe permitir construir una inter-red de dispositivos de tecnología que se puedan
comunicar directa y simétricamente con cualquier otro, sin transformaciones y sin intermediarios/dele-
gados. Muchas soluciones IoT se basan en el envío de lecturas procedentes de sensores hacia almacena-
mientos de datos en la nube y después, las aplicaciones acceden a esos almacenamientos, de modo que
no hay comunicación directa entre el origen de la información y el destinatario que la necesita.
Internet de las Cosas abarca una amplia gama de industrias y se presentan casos que varían desde un
solo dispositivo restringido, hasta despliegues masivos multi-plataforma de tecnologías integradas y sis-
temas en la nube que se conectan en tiempo real.
9 tp://www.mailxmail.com/curso-que-son-redes/que-es-tcp-ip
9
Existe una variedad de protocolos empleados en IoT para diversos fines. Estos protocolos están en uso
tanto en despliegues fijos como celulares; a continuación se desglosan los protocolos en las siguientes
capas para organizarlos de acuerdo a su ubicación según el modelo OSI: (ver figura No. 4)
Figura No. 4 Protocolos IoT
Fuente: https://www.dsi.fceia.unr.edu.ar/images
1.3.1Transporte y Red
IPv6
es un protocolo de capa de Internet (evolución de IPv4) para interconexión de conmutación de paque-

tes, que proporciona transmisión de datagramas de extremo a extremo a través de múltiples redes IP.
La base en la que se fundamente el IoT es poder distribuir objetos y dispositivos conectados por todo
nuestro entorno. Esto implica que la información adquirida pueda provenir de diferentes lugares y a su
vez, procesada por máquinas o servidores diferentes.
Como consecuencia vamos a tener un montón de objetos, dispositivos y máquinas separadas físicamen-
te y conectadas entre sí por una red de comunicaciones. Cada componente con su propio software y
hardware. La arquitectura debe ser capaz de mostrar todos los componentes como un único sistema a
los ojos de los usuarios y desarrolladores.
Si decimos que miles de millones de dispositivos se conectarán a Internet un futuro no muy lejano y ade-
más reconocemos que las direcciones de IPv4 se están agotando, es natural que IoT deba implementarse
sobre IPv6. De hecho el IETF ha estandarizado el stack (pila) de IoT por medio de un protocolo denomi-
nado 6lowPAN (RFC 4944). Existen algunas tecnologías que forman parte de IoT y no utilizan IPv6, como
RFID o ZigBee, la tendencia es migrar estas tecnologías hacia IP.
10
Las funciones centrales de IPv6 son el direccionamiento de elementos de red a través de las denomina-
das direcciones IPv6 y el reenvío de paquetes entre subredes, también llamado enrutamiento. Para ello,
IPv6 se adhiere a la capa de red (capa 3) del modelo OSI. La expansión del espacio de direcciones de 32
a 128 bits no solo combate la creciente escasez de direcciones IP, sino que también permite direccionar
a todos los dispositivos de una red de forma inequívoca.
La asignación de direcciones IP se realiza a través de los llamados RIR (Registros Regionales de Internet)
quienes, a su vez, reciben una dirección IP de su propio rango por parte de la IANA (Internet Assigned
Numbers Authority). El RIR competente para Europa, Oriente Medio y Asia Central es el RIPE NCC (Ré-
seaux IP Européens Network Coordination Centre).
Las nuevas características introducidas con el protocolo IPv6 son básicamente las siguientes:
• Nuevo formato de cabecera.
• Infraestructura eficiente.
• Jerárquica de direccionamiento y enrutamiento.
• Espacio de direcciones mucho más grande y sin estado.
• La configuración de direcciones firewall.
• Seguridad IP.
• Extensibilidad.
• Mejor calidad de servicio (QoS).
• Nuevo protocolo para la interacción con nodos cercanos ( ver figura No. 5)
11
Figura No. 5 Estructura trama IPv6
6LoWPAN
Acrónimo de “IPv6 Sobre Redes Inalámbricas de Área Personal de Baja Potencia. Es una capa de adapta-
ción para IPv6 sobre enlaces IEEE802.15.4. Este protocolo opera solo en el rango de frecuencias de 2,4
GHz con una tasa de transferencia de 250 kbps.
Es un estándar que permite que los dispositivos simplifiquen su cabecera de forma muy compacta (ideal
para el protocolo CoAP), introduciendo de esa manera tecnologías basadas en IPs de nodos inalámbri-
cos de baja potencia para resolver problemas de interoperabilidad (aspecto muy importante a la hora de
elegir un sistema operativo).
La pila de protocolos que presenta 6LoWPAN es bastante parecida a la de IPv6, pero con diferencias
notables en la capa física y de enlace, tal como se muestra en la Figura No.6
12
Figura No. 6 Pila protocolos 6LoWPAN frente IPv6
Fuente: J. Olsson, (2014) 6LowPAN demystified, Texas Intruments, USA.
Este protocolo es compatible con IPv6 gracias a una pequeña capa de adaptación que permite conexio-
nes IPv6 sobre IEEE 802.15.4, de manera que puede ser mostrado como parte de la capa de red.
En la capa de transporte, 6LoWPAN viene implementado por el protocolo de transporte UDP, el cual
puede ser comprimido, mientras que el protocolo TCP normalmente no es usado por motivos de rendi-
miento, eficiencia y complejidad.
6LowPAN utiliza el protocolo de control de mensajes de Internet conocido como ICMPv6 para los men-
sajes de control, descubrimiento de vecinos y detección de destinos inalcanzables. Esta adaptación de
IPv6 y el formato 6LowPAN se lleva a cabo en los routers frontera.
Características IPV610
• Se adapta perfectamente a dispositivos de bajo consumo permitiendo el modo “sleep” cuando no

estén funcionando.
• Compatibilidad con la multidifusión, permite multicast (envío de información en múltiples redes a

múltiples destinos simultáneamente).
• Los protocolos de enrutamiento IP permiten una amplia cobertura mediante topología mallada (red
en que cada nodo está conectado a todos los nodos) y tecnologías RADIO integradas.
• El ancho de banda es 1280 Bytes.
10 http://repositorio.upct.es/bitstream/handle/10317/4163/pfc5908.pdf;sequence=1
13
• Las direcciones IPv6 son de 128 bits de longitud y consisten en dos partes , una de 64 bits que co-
rresponde a un prefijo y otra de 64 bits que corresponden al identificador de interfaz que casi siem-
pre se genera de la dirección MAC de la interfaz que ha sido asignada la dirección obtenida del ser-
vidor DHCPv6 (Protocolo de Configuración Dinámica de Hosts para IPv6) o por asignación manual.
UDP
(User Datagram Protocol - Protocolo de Datagramas de Usuario): Protocolo simple de capa de transporte

OSI, para aplicaciones de red cliente/servidor basadas en Protocolo de Internet (IP). UDP es la principal
alternativa a TCP y uno de los protocolos de red más antiguos en existencia, introducido en 1980. UDP
a menudo se utiliza en aplicaciones especialmente optimizadas para el rendimiento en tiempo real.
Se define en el RFC 76811 y utiliza el mecanismo conocido como “entrega de mejor esfuerzo”, es decir,
la entrega de datos ocurre de la forma más rápida posible en detrimento de una garantía de entrega en
destino, aunque sí implementa un control de errores de tramas que pudieran estar corruptas (checksum).
Comparado a otros protocolos como TCP, con UDP no se establecen conexiones de punto a punto entre
los sistemas que se comunican.
El protocolo UDP no ofrece fiabilidad o garantía de entrega de mensajes (reliability) por lo que estos
pueden llegar fuera de orden, repetidos o perderse.
Además, no dispone de control de flujo y permite el envío de datagramas con una velocidad máxima
impuesta por la interfaz de red, en muchas ocasiones superior a lo soportado por los dispositivos de
encaminamiento entre el origen y el destino.
El protocolo UDP dispone de características que lo hacen más apropiado para ser utilizado en aplicacio-
nes que no requieran un uso excesivo de memoria, por ejemplo aquellas presentes en microcontrola-
dores, como también en el caso de requerir el envío de información y no represente una penalización el
hecho de perder parte de la misma.
El protocolo UDP permite el envío de paquetes de la forma más rápida posible. Se tra-
ta de un protocolo sin conexión, es decir, a diferencia de TCP que mantiene las conexiones acti-
vas por dirección IP y puerto para así poder transferir un flujo de paquetes, UDP permite el en-
vío de mensajes a una dirección IP y puerto de destino sin mantener una conexión persistente.
11 https://rua.ua.es/dspace/bitstream/10045/1109/1/InformeTecZB.pdf
14
ZigBee12
Es una tecnología inalámbrica de corto alcance y bajo consumo originaria de la antigua alianza HomeRF
y que se definió como una solución inalámbrica de baja capacidad para aplicaciones en el hogar como la
seguridad y la automatización.
Entre las aplicaciones que puede tener están:
• Domótica.
• Automatización industrial.
• Reconocimiento remoto.
• Juguetes interactivos.
• Medicina.
Su principal objetivo al utilizar ZigBee no es obtener velocidades muy altas, ya que solo puede alcanzar
una tasa de 20 a 250Kbps en un rango de 10 a 75 metros, sino que es conectar sensores cuyos trans-
ceptores tengan un muy bajo consumo energético. Algunos dispositivos alimentados con dos pilas AA
puedan aguantar 2 años sin el cambio de baterías. Por tanto, dichos dispositivos pasan la mayor parte del
tiempo en un estado latente, es decir, durmiendo para consumir mucho menos energia13.
En ZigBee hay tres tipos de dispositivos: (ver figura No.7)14
• Coordinador
-Sólo puede existir uno por red.
-Inicia la formación de la red.
-Es el coordinador de PAN.
• Router
-Se asocia con el coordinador de la red o con otro router ZigBee.
-Puede actuar como coordinador.
-Es el encargado del enrutamiento de saltos múltiples de los mensajes.
15
• Dispositivo final
-Elemento básico de la red.
-No realiza tareas de enrutamiento.
Figura No. 7 Red ZigBee
Fuente: https://rua.ua.es/dspace/bitstream/10045/1109/1/InformeTecZB.pdf
RLP
(Routing Protocol Designed for Low Power and Lossy Networks ) Se caracteriza por ser un protocolo
proactivo basado en vector de distancia, el cual define las rutas antes de que sean necesarias por los
nodos de la red. Su modo de funcionamiento está basado en el intercambio de mensajes de control
(enviados de forma periódica) para encontrar y propagar rutas en la red, estos mensajes pueden ser a
nivel local o de enlace permitiendo el envío de información a los vecinos o a nivel global para propagar
la información relacionada con la topología a todos los nodos de la red.
Es un protocolo de red con arquitectura IP que separa las tareas de procesado y reenvío de paquetes (son
encaminados en base a la tabla de enrutamiento). Este protocolo está orientado a un enrutamiento de
vector de distancia genérico que tiene definida una Función Objetivo (OF) compuesta por una combina-
ción de métricas y restricciones que permiten elegir el “mejor camino”.
Por defecto, el protocolo RPL dispone de un mecanismo multipunto a punto (MP2P) para el envío de
datos de los nodos en la red hacia el nodo raíz. Este tipo de tráfico se conoce como “upward” o “tráfico
hacia arriba” y esta implementado con el uso de mensajes DIO. Sin embargo, RPL Recognitin of prior
learning (Reconocimiento del aprendizaje previo), es capaz de funcionar mediante otro mecanismo deno-
minado flujo de tráfico “hacia abajo” o “downward” basado en una conexión punto a multipunto (P2MP).
El establecimiento de rutas downward se establece mediante el intercambio de mensajes DAO (Destina-
tion Advertisement Object).
16
1.3.2 Sesión
AMQP15 (Protocolo Avanzado de Colas de Mensajería): Protocolo de capa de aplicación estándar y

abierto, para middleware orientado a mensajería de datos. Las características definitorias de AMQP son
la orientación de los mensajes, la puesta en cola, el enrutamiento (incluyendo punto a punto, publicación
y suscripción), así como “confiabilidad y seguridad”.
DDS16 (Servicio de Distribución de Datos para Sistemas en Tiempo Real): El primer estándar internacional
abierto de middleware, que aborda directamente las comunicaciones bajo el esquema publicación/
suscripción para sistemas en tiempo real e integrados.
SOAP17 (Protocolo Simple de Acceso a Objetos):18 Protocolo estándar que define cómo dos objetos en
diferentes procesos, pueden comunicarse por medio de intercambio de datos usando XML. Está actual-
mente bajo el auspicio de la W3C y es uno de los protocolos más utilizados en los servicios Web.
Características19
• Sencillo de implementar, probar y usar ya que atraviesa “Firewalls” y routers por lo cual parece que
es una comunicación HTTP.
• Permite el intercambio de documentos o llamada a procedimientos remotos (RPC).
• Extensibilidad: seguridad y WS-routing son extensiones aplicadas en el desarrollo.
• Neutralidad: puede ser utilizado por cualquier protocolo de transporte como HTTP, SMTP, TCP o
JMS.
• Permite la interoperabilidad entre múltiples entornos, al no importar la plataforma, los mensajes

SOAP son independientes de los sistemas operativos y pueden ser transportados por los protocolos
que funcionan en la Internet.
Aprovecha los estándares existentes en la industria, SOAP aprovecha XML para la codificación de los
mensajes, en lugar de utilizar su propio sistema de tipo que ya están definidas en la especificación es-
quema de XML.
15 https://blog.techdata.com/ts/latam/internet-de-las-cosas-a-nivel-industrial
17 https://www.ecured.cu/Protocolo_simple_de_acceso_a_objetos_(SOAP)
18 https://www.ecured.cu/Protocolo_simple_de_acceso_a_objetos_(SOAP)
17
1.3.3 Presentación
MQTT (Message Queue Server Telemetry Transport): Habilita un modelo de mensajería de publicación/

suscripción de una manera extremadamente ligera. Usado para la comunicación máquina a máquina
(M2M). Idóneo para aplicaciones de Internet de las Cosas en las cuales se envían de información y por
tanto no se necesita un gran ancho de banda. Es un protocolo de comunicación que permite conectar
un dispositivo a Internet, mediante este protocolo se puede depositar el dato de un dispositivo en una
base de datos (ver figura No.8).
El protocolo MQTT define los tipos de entidades en la red: un intermediario de mensajes y un número de
clientes. El intermediario es un servidor que recibe todos los mensajes de los clientes y luego los redirige
a clientes de destinos relevantes. Un cliente es cualquier cosa que pueda interactuar con el intermediario
para enviar y recibir mensajes. Un cliente puede ser un sensor de IoT en el campo o una aplicación del
centro de datos que procesa datos de IoT.
Hay 5 métodos para su funcionamiento: conectar y desconectar, para darse de alta como cliente y darse
de baja subscribe a un tema que permite recibir todo lo que se publica bajo un tema determinado20.
Figura No. 8 Diagrama operación MQTT
Fuente: http://director-it.com/index.php
HTTP/221: El Protocolo de Transferencia de Hipertexto, versión 2, es un protocolo de red utilizado por la

World Wide Web que llega con el objetivo de actualizar el protocolo HTTP/1.1, con el que es compati-
ble. HTTP 2.0 no modifica la semántica de aplicación de HTTP, permitiendo un uso más eficiente de los
recursos de red y una menor percepción de la latencia al introducir la compresión del campo del encabe-
zado, permitiendo múltiples intercambios simultáneos en la misma conexión.
20 http://rdiaz.es/blog/mqtt-el-protocolo-para-iot/
18
1.3.4 Aplicación
CoAP22 (Protocolo de aplicación restringido): Es un protocolo de capa de aplicación, diseñado para

dispositivos de Internet con recursos limitados como los nodos WSN. CoAP está diseñado para traducirse
fácilmente a HTTP para una integración simplificada con la web, al mismo tiempo que cumple con los
requisitos especializados como el soporte de multidifusión, gastos generales muy bajos y simplicidad.
Está pensado especialmente para sensores de baja potencia, se ha diseñado para trasladar el modelo
HTTP pero incluyendo otros requisitos como multicast, bajo overhead y simplicidad, que son muy impor-
tantes para el Internet de las Cosas (IoT) y Máquia a Máquina (MaM)23.
CoAP implementa el modelo REST de HTTP (con las primitivas GET, POST, PUT y DELETE), usa cabece-
ras reducidas, y limita el intercambio de mensajes, añadiendo soporte UDP y otras modificaciones como
mecanismos de seguridad específicos.
Características24
• Reducción de sobrecargas TCP por medio de una vinculación UDP en opciones de fiabilidad unicast
y apoyo multicast de peticiones.
• El diseño del protocolo traduce fácilmente a HTTP la integración simplificada con la web.
• Intercambio de mensajes asíncronos.
• Apoyo de URI y contenido (Content-Type).
• Búsqueda de recursos y mecanismos de suscripción opcional.
• Caching simple basado en MAX-AGE.
XMPP-IoT: De la misma manera que XMPP, silenciosamente ha creado una comunicación interoperable
de persona a persona. Su objetivo es hacer que las máquinas de comunicación Persona a Persona y Má-
quina a Máquina sean interoperables.
Diferencia entre MQTT y CoAP
La principal diferencia entre CoAP y MQTT es que el primero se ejecuta en la parte superior del User
Datagram Protocol (UDP) mientras que el segundo se ejecuta en la parte superior de TCP. Como UDP no
es inherentemente fiable, CoAP proporciona su propio mecanismo de fiabilidad. Esto se logra con el uso
de “mensajes confirmables y mensajes no confirmables”.
23 https://unpocodejava.com/2013/04/28/que-es-coap/
19
Los mensajes confirmables requieren un reconocimiento mientras que los mensajes no confirmables no
necesitan un acuse de recibo.
Se han resumido las principales diferencias entre COAP y MQTT en la Tabla 1.
Tabla 1. Diferencias entre MQTT y COA
Fuente: https://eclipse.org/community/eclipse_newsletter/2014/february/article2.php
Unidad II: Estándares de Comunicación en el Internet de las Cosas
2.1 Introducción
Las “cosas” conectadas podrían ser cualquiera. El Internet de las Cosas debería codificar de 50.000 a
100.000 millones de objetos y seguir el movimiento de estos; se calcula que todo ser humano está ro-
deado de por lo menos 1.000 a 5.000 objetos. Según Gartner25, en 2020 habrá en el mundo aproximada-
mente 26.000 millones de dispositivos con un sistema de adaptación al Internet de las Cosas.
Abi Research, por otro lado, asegura que para el mismo año existirán 30.000 millones de dispositivos ina-
lámbricos conectados a Internet. Por su parte Cisco, uno de los grandes abanderados de esta tendencia,
predice que se llegará a los 50.000 millones en el 202026.
Como se indicó en el capítulo anterior, la próxima generación de aplicaciones de Internet (protocolo

IPv6) ya implementado en algunos sectores, se podría identificar todos los objetos, algo que no se puede
hacer con IPv4, el sistema actualmente en uso27.
25 https://www.gartner.com
26 http://smartcio.es/internet-of-things/
20
Ya hemos visto que es posible que los dispositivos hablen entre sí pero primero tendrán que hablar el
mismo idioma, para lo cual es necesario el establecimiento de estándares como lo habíamos indicado.
Han surgido diferentes alianzas que intentan imponer un estándar común.
Son muchos los fabricantes que piensan que ellos pueden encargarse de hacer los dispositivos, pero es
absurdo desarrollar también un idioma de comunicación propio.
El principal escollo para un estándar común es que las empresas más importantes del mundo tecnológico
están apostando a su propio ecosistema para Internet de las Cosas, especialmente las relacionadas con
los smartphones, dispositivos vitales dentro del universo IoT28.
Muchas organizaciones trabajan en el proceso de normalización, nos centramos en aquellas que trabajan
sobre la IoT y proporcionan una definición para esta.
El IEEE es una organización global de ingeniería, profesional, cuya misión es promover la innovación tec-
nológica. Uno de los proyectos que se relaciona directamente con la IoT es el IEEE P2413.
El alcance de IEEE P2413 es definir una arquitectura, frente a las descripciones de diversos dominios
de la IoT, las definiciones de las captaciones de dominio de la IoT, y la identificación de puntos en común
entre diferentes dominios de la IoT.
La UIT asigna el espectro radioeléctrico y órbitas satelitales a nivel mundial, desarrolla las normas técni-
cas que garanticen las redes y tecnologías de interconexión a la perfección y se esfuerza por mejorar el
acceso a las TIC a comunidades en todo el mundo29.
La Comisión de Estudio 20 (CE20), ha definido Internet de las Cosas (IoT) en la Recomendación UIT-T
Y.2060, como una infraestructura global para la sociedad de la información, lo que permite servicios
avanzados mediante la interconexión de las cosas (físicas y virtuales) en base a la información existente,
evolución interoperable y tecnologías de la comunicación30.
En su última reunión realizada en el Cairo del 6 al 16 de mayo del 2018, en la que participaron más de
200 delegados, en lo que respecta a recomendaciones, el evento culminó con nueve recomendaciones
que alcanzaron consentimiento; una aprobada; y 14 ítems de trabajo nuevos para analizar. Algunas de
las temáticas de las recomendaciones con consentimiento, la cuales fueron aprobadas a inicios de julio
2018 son: requerimientos de apps IoT para pequeñas tiendas de retail; panorama de manufactura “in-
teligente” en el marco de IoT Industrial; marco para self-organizing networks (SON) en entornos de IoT;
marco arquitectónico para servicios de seguridad para el transporte.
Para una lista completa de las nuevas recomendaciones e ítems de trabajo visite el sitio31
28 http://www.tynmagazine.com/la-uit-se-involucra-en-el-mercado-de-iot-para-buscar-un-estandar-internacional-2/
29 https://www.itu.int/es/about/Pages/default.aspx
30 UIT: REC-Y.2060-201206-I!!PDF-S%20(3).pdf
31 https://www.itu.int/en/ITU-T/studygroups/2017-2020/20/Pages/exec-sum-may18.aspx.
21
Los miembros del 3GPP, entidad encargada de los estándares de telefonía móvil, llegaron a un acuerdo
para poner en marcha dos especificaciones para versiones de LTE para dispositivos de baja potencia. Es-
tas tecnologías, denominadas respectivamente Categoría M1 y Categoría NB1, se utilizarán para que las
operadoras puedan desplegar servicios pensados específicamente para IoT. Ambas son más lentas que el
servicio de datos móviles convencional, pero emplean menos energía32.
2.2 Estándares para el Internet de las Cosas
2.2.1 AllSeen Alliance33
Esta es una de las primeras asociaciones que busca este estándar común basado en software Open Sour-
ce y que pueda ser utilizado por cualquier fabricante. Fue creada con el apoyo de la Linux Foundation
y en ella se encuentran empresas como Sharp, Haier, LG, Sony, HTC, Harman, Bosch, Panasonic, Qual-
comm, Cisco y Microsoft.
Este software Open Source se llama AllJoyn y permite que exista una interoperabilidad entre distintos
dispositivos de diferentes fabricantes con distintos sistemas operativos. AllJoyn ya se utiliza en las te-
levisiones LG y en altavoces Panasonic. Aunque según los analistas este estándar todavía tiene un largo
camino que recorrer.
AllJoyn es un proyecto creado por Qualcomm, pero que se encuentra bajo el amparo de la AllSeen Allian-
ce. Este estándar se define como flexible, dinámico, avanzado y compatible. No pretende ser un pro-
tocolo de comunicación de bajo nivel, si no que quiere resolver problemas de alto nivel. Sus áreas de
funcionamiento son la conexión, notificaciones, paneles de control y el audio.
2.2.2 Open Interconnect Consortium34
La finalidad de esta alianza es similar a la de AllSeen, la diferencia es que aquí las empresas son otras.
En este caso la conforman Atmel, Broadcom Corporation, Dell, Intel, Samsung Electronics y Wind River.
También apuesta por el código abierto para crear un estándar común. Según exponen, ellos tratan temas
que no se están abordando en la All Seen, como es la seguridad.
La Linux Fundation también les apoya y según su director Jim Zemlim, el Open Interconnect Consortium
es otra prueba de como el código abierto ayuda a la innovación.
Su objetivo, dicen, es conectar los próximos 25 mil millones de dispositivos al Internet de las Cosas. To-
das las partes de este acuerdo se han comprometido a invertir tiempo de sus ingenieros para que en el
tercer trimestre de este año ya se empiecen a ver los frutos de esta alianza.
32 https://www.muycomputerpro.com/2017/01/16/expertos-estandares-iot
22
2.2.3 ZigBee35
Fue una de las primeras en llegar. La especificación 1.0 de ZigBee se aprobó el 14 de diciembre de 2004
y está disponible a miembros del grupo de desarrollo dentro de la ZigBee Alliance. Un primer nivel de
suscripción, denominado adopter, permite la creación de productos para su comercialización adoptando
la especificación por 3.500 dólares anuales.
Esta especificación está disponible al público para fines no comerciales en la petición de descarga. La
revisión actual de 2006 se aprobó en diciembre de dicho año.
Se trata de un conjunto de protocolos de alto nivel de comunicación inalámbrica para su utilización con
radiodifusión digital de bajo consumo, basada en el estándar IEEE 802.15.4 de redes inalámbricas de
área personal.
En la junta de la ZigBee Alliance se encuentran NXP, Comcast Cable, Freescale Semiconductor, Itron, Kro-
ger, Landis+Gyr, Legrand Group, Philips Electronics, Schneider Electric, Silicon Labs y Texas Instruments.
La Alianza promueve la adopción global de ZigBee como el estándar líder de redes inalámbricas en las
normas de detección y control para ser empleadas en los sectores de consumo, comerciales e industria-
les. En este caso no se basan en un estándar libre, si no en uno propio que ya alcanza los 1.000 productos
certificados36.
2.2.5 Threat, de Google Nest37
Recordemos que Google también tiene su apuesta en el Internet de las Cosas. Compró Nest, una em-
presa puntera en el hogar inteligente que desarrolló un termostato capaz de regular las necesidades de
la casa por sí mismo. Tras su compra Google aclaró que Nest sería independiente, pero ya ha realizado
algunas acciones para que tome fuerza, una de ellas es la creación del protocolo Threat.
Este estándar ayudaría a conectar multitud de objetos con nuestro teléfono o tablet, desde una cerradu-
ra hasta una bombilla. Thread es un protocolo de red con funciones de seguridad y de bajo consumo que
conecta los dispositivos del hogar, independientemente del tipo de conexión que puede ser WiFi, NGC,
Bluethooth o ZigBee. Según el director de producto de Nest, Chris Boross, los productos de la marca ya
están utilizan la versión Thread para conectarse. Además en junio, Nest ya anunció su asociación con
Mercedes Benz, Whirlpool y LIFX, que integrarían sus productos con los termostatos y detectores de
humo de Google.
Lo más curioso es que a este grupo también se ha apuntado Samsung y junto a él se encuentran ARM,
Freescale, Silicon Labs y Big Ass Fans, un fabricante de sistemas de ventilación.
23
2.2.6 Apple HomeKit38
HomeKit es la apuesta de Apple para los hogares inteligentes. Se trata de una API específica para que los
fabricantes de dispositivos puedan integrarlo: desde termostatos, hasta cerraduras pasando por control
mediante Siri, todos los dispositivos podrán integrar este nuevo sistema.
Apple ha asegurado que la red que utilizará esta nueva plataforma será totalmente segura en lo referente
a la conexión (opciones como la encriptación a buen seguro que están contempladas). Por lo tanto, pare-
ce que la compañía está teniendo en cuenta todas las opciones.
Otro de los pilares en los que se debe sustentar es que el API que utilice HomeKit sea accesible para las
compañías que trabajan en este sector. Aquí Apple ha asegurado por medio de Craig Federighi, vicepre-
sidente senior de ingeniería de Apple, que está trabajando con empresas líderes del sector, como por
ejemplo Philips, que también forma parte de la ZigBee Alliance, o Chamberlain.
2.2.7 FIWARE39
Es una iniciativa open source (código abierto) que pretende impulsar la creación de estándares necesa-
rios para desarrollar aplicaciones Smart en diferentes dominios: Smart Cities, Smart Ports, Smart Logis-
tics, Smart Factories, entre otros.
Cualquier aplicación Smart se caracteriza por recoger información relevante para la aplicación de dife-
rentes fuentes sobre lo que está pasando en un momento dado. Esto se conoce como “información de
contexto”. La información de contexto actual e histórico se procesa, visualiza y analiza a gran escala. De
esta forma, se produce el comportamiento inteligente esperado.
Es un estándar que describe cómo recopilar, gestionar y publicar información de contexto y adicional-
mente aporta elementos que permiten explotar esta información una vez recopilada.
También resuelve de manera sencilla cómo capturar información procedente de redes de sensores, aun-
que se comunican usando diferentes protocolos y lenguajes IoT. En ese sentido es capaz de resolver la
complejidad de tratar la información recogida por los sensores y traducirlos a un lenguaje común.
En el entorno de Smart Cities, tenemos un estándar sobre cómo recoger información, gestionarla y pu-
blicarla, describiendo qué está pasando en la ciudad en cualquier momento en tiempo cuasi-real.
El procesamiento y análisis de la información actual e histórica proporciona a las ciudades una visión
holística, ayudándole a obtener mayor control y monitorización de la calidad del servicio que ofrece a los
ciudadanos.
39 https://iot.telefonica.com/blog/2016/09/es-fiware-estandar-iot
24
Adicionalmente la ciudad es capaz de exportar y publicar parte de esa información para que terceros
puedan desarrollar aplicaciones interesantes para el ciudadano, para la economía local y para los proce-
sos productivos de la ciudad. Por este motivo, se dice que adoptar estándares FIWARE convierte a las
ciudades en motores de crecimiento40.
Una aplicación Smart es capaz de entender esta información de contexto, procesarla y reaccionar ante
ella exhibiendo un cierto comportamiento inteligente. El contexto de lo que ocurre en una ciudad se
puede entender por el conjunto de las calles, los servicios que ofrece la ciudad y lo que hacen los ciuda-
danos41.
Unidad III: Modelos de Comunicación
3.1 Introducción
Cómo se conectan y comunican los dispositivos de la IoT desde el punto de vista operativo, en marzo de
2015, el Comité de Arquitectura de Internet (IAB) dio a conocer un documento para guiar la creación de
redes de objetos inteligentes (RFC 7452)42, que describe un marco de cuatro modelos de comunicación
comunes que utilizan los dispositivos de la IoT. En este capítulo se presenta este marco y se explican las
principales características de cada modelo.
Los modelos de comunicación para Internet de las Cosas son referencias que describen cómo se distribu-
yen e interactúan los diferentes protagonistas que forman una red de varios dispositivos conectados43.
Para el caso particular de los proyectos para Internet de las Cosas, cualquier modelo ayuda mucho a la
hora de simplificar el desarrollo de nuevos productos y reducir su coste, algo que los ingenieros de siste-
mas agradecerán, puesto que en este entorno se necesita tener conocimientos de hardware, software y
protocolos de todo tipo.
Así que, disponer de unas guías generales sobre cómo conseguir que un conjunto de objetos accedan a
Internet o para el desarrollo de cualquier aplicación de Internet de las Cosas en general, siempre es de
agradecer. Aunque no significa que la tarea vaya a ser fácil44.
El uso de estos modelos de comunicación para Internet de las Cosas, fomentan ampliamente la intero-
perabilidad entre sistemas, punto esencial para la evolución de esta tecnología45.
42 Tschofenig, H., et. al., Architectural Considerations in Smart Object Networking. Tech. no. RFC 7452. Internet Architecture Board, marzo de
2015. Web. https://www.rfc-editor.org/rfc/rfc7452.txt
43 http://www.ermesh.com/modelos-de-comunicacion-para-internet-de-las-cosas/
25
Los 4 modelos de comunicación de Internet de las Cosas son:
1. Modelo de Comunicación Dispositivo – Dispositivo.
2. Modelo de Comunicación Dispositivo – Internet.
3. Modelo de Comunicación Dispositivo – Gateway.
4. Modelo de Comunicación Back-End.
3.2 Comunicación Dispositivo a Dispositivo46
Este modelo representa dos o más dispositivos que se conectan y se comunican directamente entre sí y
no a través de un servidor de aplicaciones intermediario. Estos dispositivos se comunican sobre muchos
tipos de redes, entre ellas las redes IP o la Internet. Sin embargo, para establecer comunicaciones direc-
tas de dispositivo a dispositivo, muchas veces se utilizan protocolos como Bluetooth, 40 Z-Wave41 o
ZigBee42, como se muestra en la Figura 9.
Estas redes dispositivo a dispositivo permiten que los dispositivos que, para comunicarse e intercambiar
mensajes, se adhieren a un determinado protocolo de comunicación logren su función. Por lo general,
este modelo de comunicación se utiliza en aplicaciones como sistemas de automatización del hogar, que
habitualmente utilizan pequeños paquetes de datos para la comunicación entre dispositivos con requi-
sitos relativamente bajos en términos de la tasa de transmisión. Los dispositivos para la IoT residenciales
—bombillas de luz, interruptores, termostatos y cerraduras— normalmente se envían pequeñas cantida-
des de información (por ejemplo, un mensaje del estado de bloqueo de una puerta o un comando para
encender una bombilla) en un escenario de automatización del hogar.
Desde el punto de vista de los usuarios, esto significa que los protocolos de comunicación dispositivo
a dispositivo subyacentes no son compatibles, lo que los obliga a seleccionar una familia de dispositi-
vos que emplean un protocolo común. Por ejemplo, la familia de dispositivos que utilizan el protocolo
Z-Wave no es compatible de forma nativa con la familia de dispositivos ZigBee. Si bien estas incompa-
tibilidades limitan la capacidad de elección de los usuarios a los dispositivos de una determinada familia
de protocolos, los usuarios también saben que los productos de una familia determinada tienden a co-
municarse bien47.
46 https://www.internetsociety.org/wp-content/uploads/2017/09/report-InternetOfThings-20160817-es-1.pdf
26
Figura 9: Modelo de comunicación dispositivo a dispositivo
Fuente: http://www.ermesh.com/modelos-de-comunicacion-para-internet-de-las-cosas/
3.3 Comunicaciones Dispositivo a la Nube
En un modelo de comunicación de dispositivo a la nube, el dispositivo de la IoT se conecta directamente

a un servicio en la nube, como por ejemplo un proveedor de servicios de aplicaciones para intercambiar
datos y controlar el tráfico de mensajes. Este enfoque suele aprovechar los mecanismos de comunica-
ción existentes (por ejemplo, las conexiones Wi-Fi o Ethernet cableadas tradicionales) para establecer
una conexión entre el dispositivo y la red IP, que luego se conecta con el servicio en la nube. Esto se
ilustra en la Figura 10.
Este modelo de comunicación es empleado por algunos dispositivos electrónicos de consumo para la
IoT, entre ellos el Learning Thermostat48 de Nest Labs y el SmartTV de Samsung.49 En el caso del Learning
Thermostat, el dispositivo transmite los datos a una base de datos en la nube donde se pueden usar para
analizar el consumo de energía en el hogar. Además, esta conexión a la nube permite que el usuario ac-
ceda a su termostato en forma remota, a través de un teléfono inteligente o una interfaz web, y también
soporta las actualizaciones del software del termostato. Algo similar ocurre con la tecnología SmartTV
de Samsung — el televisor utiliza una conexión a Internet para transmitir información a Samsung para
su análisis y para activar las funciones interactivas de reconocimiento de voz de la televisión. En estos
casos, el modelo dispositivo a la nube agrega valor para el usuario final, ya que amplía las capacidades del
dispositivo más allá de sus características nativas50.
No obstante, al intentar integrar dispositivos de diferentes fabricantes pueden surgir problemas de inte-
roperabilidad. Muchas veces el dispositivo y el servicio en la nube son del mismo proveedor de tecnolo-
gía51. Si entre el dispositivo y el servicio en la nube se utilizan protocolos de datos propietarios, el dueño
del dispositivo o el usuario podrían quedar atados a un servicio en la nube específico, lo que limitaría o
impediría el uso de proveedores de servicios alternativos.
48 “Meet the Nest Thermostat | Nest.”Nest Labs. Web. 31 de agosto de 2015.https://nest.com/thermostat/meet-nestthermostat/
49 “Samsung Privacy Policy—SmartTV Supplement.” Samsung Corp. Web. 29 de septiembre de 2015. http://www.samsung.
51 Duffy Marsan, Carolyn. “IAB Releases Guidelines for Internet-of-Things Developers.” IETF Journal 11.1 (2015):
27
Esto generalmente se conoce como “dependencia de un proveedor’’ (vendor lockin), un término que
abarca otras facetas de la relación con el proveedor, como por ejemplo la propiedad y el acceso a los
datos. A la vez, los usuarios generalmente pueden confiar en que los dispositivos diseñados para su pla-
taforma específica se podrán integrar52.
Figura 10: Modelo de comunicación dispositivo a dispositivo
3.4 Modelo Dispositivo a Puerta de Enlace
En el modelo dispositivo a puerta de enlace, o más generalmente el modelo dispositivo a puerta de en-
lace de capa de aplicación (ALG), el dispositivo de la IoT se conecta a través de un servicio ALG como
una forma de llegar a un servicio en la nube. Dicho de otra manera, esto significa que hay un software de
aplicación corriendo en un dispositivo de puerta de enlace local, que actúa como intermediario entre el
dispositivo y el servicio en la nube y provee seguridad y otras funcionalidades tales como traducción de
protocolos o datos. Este modelo se ilustra en la Figura 11.
En los dispositivos de consumo se utilizan diferentes formas de este modelo. En muchos casos, el dispo-
sitivo de puerta de enlace local es un teléfono inteligente con una aplicación para comunicarse con un
dispositivo y transmitir datos a un servicio en la nube. Esto suele ser el modelo empleado con los artícu-
los de consumo populares como los dispositivos utilizados para llevar registro de la actividad física. Estos
dispositivos no tienen capacidad nativa para conectarse directamente a un servicio en la nube, por lo
que muchas veces utilizan una aplicación para teléfono inteligente como puerta de enlace intermedia53.
Otra forma de este modelo tipo dispositivo a puerta de enlace es la aparición de dispositivos “hub” en las
aplicaciones de automatización del hogar. Se trata de dispositivos que sirven de puerta de enlace local
entre los dispositivos individuales del IoT y un servicio en la nube, pero que también pueden reducir los
problemas de interoperabilidad entre los propios dispositivos. Por ejemplo, el hub SmartThings es un
28
dispositivo de puerta de enlace independiente que tiene instalados transceptores Z-Wave y Zigbee para
comunicarse con ambas familias de dispositivos54. Luego se conecta al servicio en la nube SmartThings
y permite que el usuario acceda a los dispositivos usando una aplicación para teléfono inteligente y una
conexión a Internet.
Desde una perspectiva técnica más amplia, el artículo del IETF Journal explica las ventajas del enfoque
dispositivo a puerta de enlace.
Este modelo de comunicación se usa en situaciones donde los objetos pequeños deben interoperar con
dispositivos que no utilizan el protocolo de Internet. A veces se adopta este enfoque para integrar dispo-
sitivos que solo soportan IPv6, lo que significa que se necesita una puerta de enlace para los dispositivos
y servicios existentes que solo soportan IPv455.
En otras palabras, este modelo de comunicación se suele utilizar para integrar nuevos dispositivos inte-
ligentes en un sistema heredado con dispositivos que no son interoperables de forma nativa. Una des-
ventaja de este enfoque es el costo y la complejidad que implican el desarrollo del software y el sistema
para la puerta de enlace de capa de aplicación.
La RFC7452 del IAB sugiere una perspectiva para este modelo.
Se anticipa que en el futuro se desplegarán más puertas de enlace genéricas con menores costos e in-
fraestructura menos compleja para los consumidores finales, las empresas y los entornos industriales.
La existencia de tales puertas de enlace será más probable si el diseño de los dispositivos del IoT utiliza
protocolos de Internet genéricos y no requiere puertas de enlace de capa de aplicación para traducir un
protocolo de capa de aplicación a otro.
En general, el uso de puertas de enlace de capa de aplicación llevará a un despliegue más frágil, como
ya se ha observado en el pasado56. Los sistemas que utilizan el modelo de comunicación dispositivo a
puerta de enlace y su papel más amplio en el abordaje de los problemas de interoperabilidad entre dis-
positivos de la IoT todavía están evolucionando57.
54 “How It Works.” SmartThings, 2015. http://www.smartthings.com/how-it-works

55 Duffy Marsan, Carolyn. “IAB Releases Guidelines for Internet-of-Things Developers.” IETF Journal 11.1 (2015): 6-8. Internet Engineering
Task Force, julio de 2015. Web. https://www.internetsociety.org/ sites/default/files/Journal_11.1.pdf
56 Tschofenig, H., et. al., p. 6.
29
Figura 11: modelo de comunicación dispositivo a puerta de enlace
3.5 Modelo de Intercambio de Datos a Través del back-end
El modelo de intercambio de datos a través del back-end se refiere a una arquitectura de comunicación
que permite que los usuarios exporten y analicen datos de objetos inteligentes de un servicio en la nube
en combinación con datos de otras fuentes. Esta arquitectura soporta “el deseo del usuario de permitir
que terceros accedan a los datos subidos por sus sensores”58.
Este enfoque es una extensión del modelo de comunicación tipo ‘dispositivo único a la nube’, que puede
llevar a la existencia de silos de datos donde “los dispositivos del IoT suben datos a un único proveedor
de servicios de aplicaciones’’59.
Una arquitectura de intercambio de datos a través del back-end permite agregar y analizar los datos re-
cogidos de flujos obtenidos de un solo dispositivo del IoT.
Por ejemplo, a un usuario corporativo a cargo de un complejo de oficinas le interesaría consolidar y

analizar los datos de consumo de energía y otros servicios que producen todos los sensores del IoT y
los correspondientes sistemas habilitados para Internet disponibles en las instalaciones. En el modelo
‘dispositivo único a la nube’, muchas veces los datos que produce cada sensor o sistema del IoT queda en
un silo de datos independiente. Una arquitectura eficaz de intercambio de datos a través del back-end
permitiría que la empresa acceda y analice fácilmente, en la nube, los datos producidos por toda la gama
de dispositivos instalados en el edificio. Además, este tipo de arquitectura facilita la portabilidad de los
datos.
58 Tschofenig, H., et. al., p. 9.

59 Ibid
30
Las arquitecturas eficaces de intercambio de datos a través del back-end permiten que los usuarios mue-
van sus datos al cambiar de servicio de IoT, rompiendo así las barreras tradicionales de los silos de datos.
El modelo de intercambio de datos a través del back-end sugiere que, para lograr la interoperabilidad de
los datos de dispositivos inteligentes alojados en la nube, se requiere un enfoque de servicios federa-
dos60 o interfaces de programación de aplicaciones (APIs) en la nube61.
La Figura 12 muestra una representación de este diseño.
Este modelo de arquitectura es un enfoque para lograr interoperabilidad entre estos sistemas de back-
end. Como sugiere el IETF Journal, “los protocolos estándares pueden ayudar, pero no son suficientes
para eliminar los silos de datos dado que entre proveedores son necesarios modelos de información
comunes62.” En otras palabras, este modelo de comunicación es apenas tan eficaz como los diseños de
los sistemas subyacentes de la IoT. Las arquitecturas de intercambio de datos a través del back-end no
pueden superar completamente los diseños de los sistemas cerrados63.
Figura 12: Diagrama del modelo de intercambio de datos a través de back-end
3.6 Modelos de Comunicación de la Internet de las Cosas: Resumen64
Los cuatro modelos básicos de comunicación muestran las estrategias de diseño subyacentes utilizadas
para permitir que los dispositivos de la IoT se comuniquen. Además de ciertas consideraciones técnicas,
el uso de estos modelos está influenciado en gran parte por la naturaleza abierta versus propietaria de
los dispositivos del IoT que se conectan en red.
60 Un enfoque de servicios federados en la nube es aquel que combina los recursos de diferentes proveedores de servicios de nube para satisfa-
cer una necesidad de negocio más amplia.
61 Producida por ownCloud.org, Own Cloud es un ejemplo de una herramienta de nube federada lista para usar. https://owncloud.org/blog/
faster-easier-file-sync-and-sharewith-federated-self-hosted-owncloud-8-0/
62 Duffy Marsan, Carolyn. p.7
31
En el caso del modelo ‘dispositivo a puerta de enlace’, su principal característica es la capacidad de su-
perar las restricciones que implica la conexión de dispositivos propietarios del IoT. Esto significa que la
interoperabilidad de los dispositivos y los estándares abiertos son consideraciones clave para el diseño y
el desarrollo de sistemas del Internet de las Cosas interconectados.
Desde el punto de vista del usuario en general, estos modelos de comunicación sirven para ilustrar la
capacidad de agregar valor que tienen los dispositivos conectados en red. Al permitir que el usuario
logre un mejor acceso a un dispositivo del IoT y a sus datos, el valor global del dispositivo aumenta. Por
ejemplo, en tres de los cuatro modelos de comunicación descritos, en última instancia los dispositivos se
conectan a servicios de análisis de datos en un entorno de cómputo en la nube.
Al crear conductos para comunicar datos a la nube, los usuarios y los proveedores de servicios pueden
agregar los datos, analizar grandes volúmenes de datos y visualizar datos más fácilmente; además, las
tecnologías de análisis predictivo obtienen más valor de los datos del IoT del que pueden obtener las
aplicaciones de silos de datos tradicionales. En otras palabras, las arquitecturas de comunicación eficaces
son un importante generador de valor para el usuario final, ya que abren la posibilidad de utilizar la in-
formación de formas nuevas. Sin embargo, cabe señalar que estos beneficios no vienen sin desventajas.
Al considerar una arquitectura determinada, es necesario considerar cuidadosamente los costos que
deben incurrir los usuarios para conectarse a recursos en la nube, especialmente en las regiones donde
los costos de conectividad del usuario son elevados.
Los modelos de comunicación efectivos benefician al usuario final, pero también cabe mencionar que
los modelos eficaces de comunicación del IoT también mejoran la innovación técnica y las oportunidades
para el crecimiento comercial. Se pueden diseñar nuevos productos y servicios que aprovechen los flujos
de datos del IoT que antes no existían, y estos podrían catalizar la innovación.
32
Bibliografía
1. “How It Works.” SmartThings, 2015. http://www.smartthings.com/how-it-works

2. Duffy Marsan, Carolyn. “IAB Releases Guidelines for Internet-of-Things Developers.” IETF Journal 11.1
(2015): 6-8. Internet Engineering Task Force, julio de 2015. Web. https://www.internetsociety.org/ sites/
default/files/Journal_11.1.pdf Tschofenig, H., et. al., p.
3. UIT: REC-Y.2060-201206-I!!PDF-S%20(3).pdf
4. Tschofenig, H., et. al., Architectural Considerations in Smart Object Networking. Tech. no. RFC 7452. Inter-
net Architecture Board, marzo de 2015. Web. https://www.rfc-editor.org/rfc/rfc7452.txt
5. Meet the Nest Thermostat | Nest.”Nest Labs. Web. 31 de agosto de 2015.https://nest.com/thermostat/
meet-nestthermostat/
6. “Samsung Privacy Policy—SmartTV Supplement.” Samsung Corp. Web. 29 de septiembre de 2015. http://
www.samsung.com/sg/info/privacy/smarttv.html
7. Duffy Marsan, Carolyn. “IAB Releases Guidelines for Internet-of-Things Developers.” IETF Journal 11.1
(2015):
Referencias web
8. https://www.slideshare.net/groberth/clase-5-protocolos-y-comunicaciones-de-red
9. http://www.masadelante.com/faqs/tcp-ip
10. https://es.ccm.net/contents/274-el-protocolo-ip
11. https://es.ccm.net/contents/275-protocolo-de-comunicacion
12. https://es.ccm.net/contents/275-protocolo-de-comunicacion
13. http://www.mailxmail.com/curso-que-son-redes/que-es-tcp-ip
17. https://es.wikipedia.org/wiki/6LoWPAN
18. https://es.wikipedia.org/wiki/Grupo_de_Trabajo_de_Ingenier%C3%ADa_de_Internet
19. https://es.ccm.net/contents/265-el-protocolo-icmp
20. https://sites.google.com/site/proyectointernet9393/protocolo-tcp-ip-y-sus-funciones
21. https://es.wikipedia.org/wiki/Uni%C3%B3n_Internacional_de_Telecomunicaciones
22. https://www.internetglosario.com/1096/IPv6.html
33

Material de Estudio2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Material de Estudio2

Cargado por

Copyright:

Formatos disponibles

1

Módulo 2: Protocolos, estándares y modelos de comunicación

Unidad 1: Protocolos para el Internet de las Cosas 3

Unidad 2: Estándares de Comunicación en el Internet de la Cosas 20

Unidad 3: Modelos de Comunicación 25

Figura No. 1 El circuito de la comunicación

• Codificación de los mensajes.

• Formato y encapsulación del mensaje.

• Tamaño del mensaje.

• Temporización del mensaje

• Opciones de entrega del mensaje.

Figura No. 2 Protocolo TCP/IP

1.2 Arquitectura de Protocolos TCP/IP6

1.2.1 Descomposición en Niveles de TCP/IP8.

Figura No. 3 Modelo OSI

Para implementar el nivel de transporte se utilizan dos protocolos:

• IP (Internet Protocol): es un protocolo no orientado a la conexión, con mensajes de un tamaño máxi-

• ICMP (Internet Control Message Protocol): proporciona un mecanismo de comunicación de informa-

1.3 Protocolos del Internet de las Cosas

Figura No. 4 Protocolos IoT

es un protocolo de capa de Internet (evolución de IPv4) para interconexión de conmutación de paque-

• Nuevo formato de cabecera.

• Jerárquica de direccionamiento y enrutamiento.

• Espacio de direcciones mucho más grande y sin estado.

• La configuración de direcciones firewall.

• Mejor calidad de servicio (QoS).

Fuente: J. Olsson, (2014) 6LowPAN demystified, Texas Intruments, USA.

• Se adapta perfectamente a dispositivos de bajo consumo permitiendo el modo “sleep” cuando no

• Compatibilidad con la multidifusión, permite multicast (envío de información en múltiples redes a

• El ancho de banda es 1280 Bytes.

(User Datagram Protocol - Protocolo de Datagramas de Usuario): Protocolo simple de capa de transporte

Entre las aplicaciones que puede tener están:

En ZigBee hay tres tipos de dispositivos: (ver figura No.7)14

-Sólo puede existir uno por red.

-Inicia la formación de la red.

-Es el coordinador de PAN.

-Se asocia con el coordinador de la red o con otro router ZigBee.

-Puede actuar como coordinador.

-Es el encargado del enrutamiento de saltos múltiples de los mensajes.

-Elemento básico de la red.

-No realiza tareas de enrutamiento.

Figura No. 7 Red ZigBee

AMQP15 (Protocolo Avanzado de Colas de Mensajería): Protocolo de capa de aplicación estándar y

• Permite el intercambio de documentos o llamada a procedimientos remotos (RPC).

• Extensibilidad: seguridad y WS-routing son extensiones aplicadas en el desarrollo.

• Permite la interoperabilidad entre múltiples entornos, al no importar la plataforma, los mensajes

MQTT (Message Queue Server Telemetry Transport): Habilita un modelo de mensajería de publicación/

Figura No. 8 Diagrama operación MQTT

HTTP/221: El Protocolo de Transferencia de Hipertexto, versión 2, es un protocolo de red utilizado por la

CoAP22 (Protocolo de aplicación restringido): Es un protocolo de capa de aplicación, diseñado para

• Intercambio de mensajes asíncronos.

• Apoyo de URI y contenido (Content-Type).

• Búsqueda de recursos y mecanismos de suscripción opcional.

• Caching simple basado en MAX-AGE.

Diferencia entre MQTT y CoAP

Se han resumido las principales diferencias entre COAP y MQTT en la Tabla 1.

Tabla 1. Diferencias entre MQTT y COA

Unidad II: Estándares de Comunicación en el Internet de las Cosas

Como se indicó en el capítulo anterior, la próxima generación de aplicaciones de Internet (protocolo

2.2 Estándares para el Internet de las Cosas

2.2.1 AllSeen Alliance33

2.2.2 Open Interconnect Consortium34

2.2.5 Threat, de Google Nest37