Contenido Extendido Dispositivos, Tecnologías de Adquisición de Datos y Redes

Contenido Extendido Tema 2.
Dispositivos, tecnologías de
adquisición de datos y redes
Docente autor: Adolfo Cortés

Tema 2. Dispositivos, tecnologías de
ÍNDICE
1. Introducción ........................................................................................................................................ 8
2. Dispositivos .......................................................................................................................................... 8
3. Dispositivos básicos ........................................................................................................................... 10
3.1. Gateways o Pasarelas .................................................................................................................... 14
3.2. CoAP .............................................................................................................................................. 15
3.3. ZigBee ............................................................................................................................................ 16
4. Dispositivos avanzados ...................................................................................................................... 18
4.1. Prototipos y dispositivos genéricos. .............................................................................................. 19
4.1.1. Arduino ..................................................................................................................................................... 20
4.1.2. Raspberry PI .............................................................................................................................................. 21
4.1.3. Cinterion Gemalto Concept Board ........................................................................................................... 22
4.1.4. Intel GALILEO GEN 2 DEVELOPMENT BOARD ........................................................................................... 24
4.1.5. Intel Edison DEVELOPMENT BOARD ......................................................................................................... 24
4.1.6. GlobalCode IoT Surfboard ........................................................................................................................ 25
4.2. Dispositivos de consumo en IoT .................................................................................................... 26
4.2.1. Smartphones ............................................................................................................................................ 26
4.2.2. Smart TV ................................................................................................................................................... 28
4.3. Wearables y BAN ........................................................................................................................... 30

4.3.1. Arduino Gemma ....................................................................................................................................... 32
4.3.2. Arduino LilyPad ......................................................................................................................................... 33
4.3.3. Arduino LilyPad Main Board ..................................................................................................................... 34
4.3.4. Arduino LilyPad Simply ............................................................................................................................. 34
4.3.5. LilyPad SimpleSnap ................................................................................................................................... 35
4.3.6. Otros Wearables ....................................................................................................................................... 35
4.4. Joyas inteligentes........................................................................................................................... 36
4.5. Smartwatch.................................................................................................................................... 37
4.5.1. Apple watch .............................................................................................................................................. 37
4.5.2. Android Wear ........................................................................................................................................... 39
4.6. Pulseras.......................................................................................................................................... 40
5. Sistemas Operativos .......................................................................................................................... 40
6. Gestión de los dispositivos ................................................................................................................ 42
MBIGDA_M8T2_160727
3
6.1. CWMP ............................................................................................................................................ 42

6.2. OMA-DM........................................................................................................................................ 43
7. Redes, capa física y enlace ................................................................................................................ 45
7.1. Redes en el contexto de la IoT....................................................................................................... 45
7.2. Tecnologías para red en IoT .......................................................................................................... 49
7.2.1. 3GPP 3G/LTE/4G ....................................................................................................................................... 51
7.2.2. LAN, WLAN ............................................................................................................................................... 52
7.2.3. IEEE 802.15.4 Low-Rate, Low-Power Networks........................................................................................ 53
7.2.4. SigFox ........................................................................................................................................................ 54
7.2.5. Power Line Communication...................................................................................................................... 57
7.2.6. RPL ............................................................................................................................................................ 58
7.2.7. Bluetooth Low Energy .............................................................................................................................. 59
7.2.8. RFID .......................................................................................................................................................... 69
7.2.9. NFC ........................................................................................................................................................... 82
8. Nivel de red ....................................................................................................................................... 85

8.1. IPv6 Networking ............................................................................................................................ 85
8.2. 6LoWPAN ....................................................................................................................................... 85
8.3. RPL ................................................................................................................................................. 87
8.4. ZigBee ............................................................................................................................................ 90
8.5. Z-Wave ........................................................................................................................................... 91
8.6. INSTEON......................................................................................................................................... 93
9. Protocolos de aplicación.................................................................................................................... 95
9.1. HTTP/REST ..................................................................................................................................... 97
9.2. CoAP ............................................................................................................................................ 100
9.3. XMPP ........................................................................................................................................... 107
9.4. MQTT ........................................................................................................................................... 113
9.4.1. Estructura de información en MQTT ...................................................................................................... 116
9.4.2. Niveles de servicio .................................................................................................................................. 116
9.4.3. Topics ...................................................................................................................................................... 119
9.4.4. Seguridad ................................................................................................................................................ 121
9.4.5. Establecimiento de conexión .................................................................................................................. 123
9.4.6. Publicación de un mensaje ..................................................................................................................... 125
9.4.7. Suscripción a mensajes ........................................................................................................................... 126
MBIGDA_M8T2_160727
4
9.4.8. Cancelar una suscripción ........................................................................................................................ 127

9.4.9. Buenas prácticas ..................................................................................................................................... 127
9.4.10. MQTT y Websockets .......................................................................................................................... 128
9.4.11. Implementaciones de MQTT .............................................................................................................. 130
9.4.12. Ejemplo de uso de MQTT ................................................................................................................... 131
9.5. MQTT-SN ..................................................................................................................................... 132
9.5.1. Dispositivos en redes MQTT-SN ............................................................................................................. 132
9.5.2. Estructura de información en MQTT-SN ................................................................................................ 134
9.6. AQMP........................................................................................................................................... 136
9.6.1. Broker ..................................................................................................................................................... 137
9.6.2. Intercambiadores ................................................................................................................................... 137
9.6.3. Colas ....................................................................................................................................................... 138
9.6.4. Mensajes................................................................................................................................................. 139
9.6.5. Implementaciones Open Source más extendidas de AQMP .................................................................. 142
9.7. Smart Energy Protocol (SEP2.0)................................................................................................... 143

9.8. Universal Plug and Play (UPnP) ................................................................................................... 147
9.8.1. Direccionamiento ................................................................................................................................... 149
9.8.2. Descubrimiento ...................................................................................................................................... 150
9.8.3. Descripción ............................................................................................................................................. 151
9.8.4. Control .................................................................................................................................................... 152
9.8.5. Notificación de eventos .......................................................................................................................... 153
9.8.6. Presentación ........................................................................................................................................... 154
9.9. OPC OLE FOR PROTCOLS.............................................................................................................. 156
9.10. DDS Data Distribution Service ..................................................................................................... 157
9.11. RTPS Real-Time Publish-Subscribe protocol ................................................................................ 160
10. Gestión de datos.............................................................................................................................. 161
10.1. El ciclo de vida de la información en IoT ..................................................................................... 162
10.1.1. Consulta ............................................................................................................................................. 163
10.1.2. Producción ......................................................................................................................................... 164
10.1.3. Recolección ........................................................................................................................................ 164
10.1.4. Agregación / Fusión ............................................................................................................................ 164
10.1.5. Entrega ............................................................................................................................................... 164
10.1.6. Preprocesado ..................................................................................................................................... 165
10.1.7. Almacenamiento, Actualización y Archivado ..................................................................................... 165
MBIGDA_M8T2_160727
5
10.1.8. Procesamiento / Análisis .................................................................................................................... 166
10.2. Bases de datos y propiedades ACID en IoT ................................................................................. 166

10.3. Teorema CAP ............................................................................................................................... 168
10.4. Elementos de diseño ................................................................................................................... 168
10.5. Elementos de recogida de datos ................................................................................................. 169
10.5.1. Descubrimiento de fuentes ................................................................................................................ 169
10.5.2. Estrategia de recolección de datos .................................................................................................... 169
10.5.3. Apoyo a la movilidad .......................................................................................................................... 169
10.6. Elementos de diseño del sistema de base de datos. ................................................................... 170
10.6.1. Arquitectura federada ........................................................................................................................ 170
10.6.2. Data-Centric Middleware ................................................................................................................... 170
10.6.3. Modelo de base de datos flexible ...................................................................................................... 171
10.6.4. Esquema de apoyo ............................................................................................................................. 171
10.6.5. Indexación eficiente ........................................................................................................................... 172
10.6.6. Plataforma de almacenamiento en capas .......................................................................................... 172
10.6.7. Archivado escalable............................................................................................................................ 172
10.7. Elementos de procesamiento ...................................................................................................... 173
10.7.1. Modelo de acceso a datos .................................................................................................................. 173
10.7.2. Estrategia de procesamiento eficiente .............................................................................................. 173
10.7.3. Procesamiento de consultas de adaptación y optimización .............................................................. 174
10.8. Conclusiones sobre la gestión de datos ...................................................................................... 175
11. Dispositivos de procesamiento ....................................................................................................... 177
11.1. Xively............................................................................................................................................ 177
11.2. Azure IoT SUITE............................................................................................................................ 179
11.3. Samsung SAMI ............................................................................................................................. 180
11.4. IBM .............................................................................................................................................. 183
11.4.1. Internet of Things platform Starter .................................................................................................... 184
11.4.2. Driver behaviour ................................................................................................................................ 184
11.4.3. Internet of Things Platform ................................................................................................................ 184
11.4.4. IoT for Electronics .............................................................................................................................. 185
11.4.5. IoT Realtime Insights .......................................................................................................................... 186
11.4.6. Flowthings.io ...................................................................................................................................... 187
11.4.7. IQP Code-free APP development ....................................................................................................... 187
MBIGDA_M8T2_160727
6
11.5. Amazon ........................................................................................................................................ 187

12. Orientación a servicios .................................................................................................................... 189
MBIGDA_M8T2_160727
7
Tema 2. Dispositivos, tecnologías de adquisición de datos

y redes
1. Introducción
La propia naturaleza de IoT implica una gran diversidad de dispositivos, tecnologías,
aplicaciones, y en definitiva de posibilidades a lo largo de toda la infraestructura tecnológica. La
aplicación de las tecnologías previamente existentes, junto con las tecnologías desarrolladas por
motivación de la IoT, y las tecnologías en desarrollo y que serán aplicadas en un futuro, define un
escenario muy variado de dispositivos, sensores, protocolos, sistemas de almacenamiento, de
procesamiento, aplicaciones e interfaces de usuario.
En este capítulo se revisan las tecnologías actuales y sus particularidades, los problemas que
resuelven, y la motivación de su aplicación dentro de IoT, proporcionando una visión general. El
nivel de profundidad alcanzado al estudiar cada caso pretende por una parte hacer hincapié en los
aspectos diferenciadores respecto a otras posibilidades similares, y por otra parte proporcionar
más conocimientos sobre las tecnologías de mayor implantación o relevancia.
2. Dispositivos
Los dispositivos para la interacción con mundo físico para la captación de datos, y realizar la
entrada de datos a IoT, son dispositivos M2M evolucionados o integrados para suministrar las
características de IoT, y nuevos dispositivos diseñados desde el inicio para IoT.
Estos dispositivos generalmente son de características muy diversas orientadas a las

condiciones del medio en que deben realizar su tarea, algunos son para uso doméstico, otros para
uso industrial, algunos para usos especiales por ejemplo dispositivos sumergibles,..
Dependiendo del medio, algunos dispondrán de alimentación de energía, otros de baterías para
almacenarla, y otros obtendrán la energía autónomamente captada del propio medio, por ejemplo
con autogeneración fotovoltaica, generadores por aire, o por inducción en el caso de RFID.
MBIGDA_M8T2_160727
8
De alguna forma es necesario proporcionarles conectividad a Internet, algunos enviarán datos a

un concentrador que dispondrá de conectividad, otros serán autónomos y utilizaran redes Wi-Fi, o
redes inalámbricas y 3G o 4G.
La variedad y las posibilidades es enorme, y estas condiciones del medio y características del
dispositivo y comunicaciones son muy a menudo muy relevantes incluso en fases posteriores de la
explotación de la información, puesto que estas circunstancias pueden influir en cuándo los datos
están disponibles y por el medio en que se encuentran en ciertos comportamientos de los datos de
un dispositivo. Incluso dos dispositivos iguales en medios diferentes y con comunicaciones
diferentes pueden presentar una variedad de situaciones a contemplar en las fases posteriores.
Desde el punto de vista del hardware los dispositivos están formados habitualmente por
pequeños sistemas de procesamiento embebidos de 8, 16 o 32 bits con RAM y memoria flash,
posibilidades de entrada y salida para conectar sensores y de interfaces de red y comunicaciones
como IEEE 802.15.4 y que se integran en pequeñas soluciones (SoC) System-on-a-Chip. Con muy
bajo consumo en el orden de los mili y micro vatios. Estas soluciones incorporan comunicaciones
TCP/IP y pequeños servidores HTTP. En algunos casos algunas de estas funciones son
proporcionadas mediante un Gateway adicional permitiendo al dispositivo centrar su actividad en
la obtención de datos de los sensores.
Característica Capacidades
Microcontrolador 8-16 o 32 bits con memoria y almacenamiento
Fuente de energía Alimentado externamente, con baterías, con autogeneración, y soluciones híbridas
Sensores y actuadores Sensores y actuadores integrados o con capacidades para conectarlos
externamente.
Comunicaciones Redes inalámbricas, de telefonía, LAN o WAN.
Sistema operativo Main-loop, basado en eventos, de tiempo real, o sistema operativo completo
embebido.
Aplicaciones Desde el muestreo de sensores hasta funcionalidades muy complejas.
Interfaz de usuario Pantalla, botones u otros dispositivos para la interacción.
Gestión del dispositivo Funcionalidades para el aprovisionamiento, gestión del firmware, arranque y
monitorización.
Entorno de ejecución Gestión del ciclo de vida de la ejecución de procesos y APIs.
Caracter ísticas de d ispositivos IoT
Los dispositivos básicos proveen de lecturas de sensores y/o tareas de actuación, con capacidad
limitada para la interacción del usuario. La interfaz de comunicaciones proporciona capacidades de
MBIGDA_M8T2_160727
9
interconexión LAN cableada o inalámbrica. En caso de conexión WAN se requiere el uso de un

Gateway adicional. Los dispositivos avanzados además alojan lógica de aplicación y conexión WAN.
Proporcionan funcionalidades para la gestión del dispositivo y para la ejecución de múltiples
aplicaciones. Incluyen Gateway.
Tipo CPU Memoria Alimentación Comunicaciones Sistema operativo

Básico 8-bit PIC, Kilobytes Batería 802.15.4, Main-loop, Contiki,
8-bit 8051, 32- 802.11, RTOS
bit Cortex-M Z-Wave
Avanzado 32-bit ARM9, Megabytes Red 802.11, Linux,
Intel Atom LTE, 3G, Java,
GPRS Python
Dispositivos tip o por su tecno log ía y capac idades
Hoy en día se utilizan tecnologías heredadas como KNX, Z-Wave y Zigbee, en el futuro se
pretende que cada dispositivo tenga su propia IP y esté directamente conectada a Internet.
3. Dispositivos básicos
Son usados para un propósito específico, como hemos indicado el medio y el propósito son muy
relevantes en la construcción del dispositivo, este tipo de dispositivos tendrá las capacidades
mínimas de adaptación a diferentes medios o situaciones, es decir, son limitados para adaptarse lo
que significa que son muy específicos.
Cubren necesidades al menor coste en materiales posible (BOM: Bill of materials) para el
despliegue de muchos sensores, y obtienen mediciones básicas de parámetros físicos (temperatura,
presión atmosférica,…), o de estados de cosas, (válvula abierta/cerrada,…), o contadores (m3 de
agua al día,...).
A menudo el dispositivo completo es integrado en un chip (SoC), la alimentación en algunos

casos esta provista por una batería reemplazable con una duración de años de funcionamiento, la
duración de la batería suele limitar sus modos de funcionamiento, en especial, la frecuencia con
que pueden ser consultados o envían información.
Algunos de estos dispositivos son tan específicos que integran la sensorización dentro del
propio chip, otros ofrecen de forma más genérica entradas y salidas para conectar los sensores.
MBIGDA_M8T2_160727
10
En cuanto al consumo de energía tienen modos de uso orientados al ahorro o incluso capacidad
para obtenerla del medio con autogeneración, estos sistemas pueden ser programados para
“dormir” y “despertar” una parte de sus circuitos bien por una petición exterior o bien de forma
temporizada, economizando al máximo el consumo.
Un interfaz serie SPI, I2C, o UART suele estar presente para poder ampliar funcionalidades en
dispositivos adicionales como pantallas o almacenamiento externo, y también para comunicarse
con otros dispositivos que aporten funcionalidad al sistema.
Para ciertos usos puede ser necesario que el dispositivo aporte funcionalidades de seguridad
como encriptación mediante AES, existen, o se pueden fabricar, dispositivos que lo incorporan.
Ejemplo de dispos it ivo SoC medidor de f lujo de agua media nte ultrasonidos en un ch ip , vista de componente
electrónico
MBIGDA_M8T2_160727
11
Ejemplo de dispos it ivo SoC medidor de f lujo de agua media nte ultrasonidos en un ch ip , vista de arquitectura. Se puede
observar la integrac ión en e l c hip del módulo de sensor de u ltrason idos jun to con el resto de componen tes que
proporcionan el pro cesamiento y almacenamiento, y la entr ada y salida.
Los dispositivos básicos carecen de capacidades de conexión WAN, por tanto estos SoC se
utilizan para tejer una red que se conecta a un Gateway y que proporciona la capilaridad suficiente
para recoger muestras de diversas localizaciones en el alcance entre el dispositivo y el Gateway.
Adicionalmente se utilizan protocolos avanzados para extender el alcance de estos dispositivos,
haciendo de pasarelas unos con otros en redes que se auto-configuran en caso de fallos, hasta
alcanzar al Gateway. Además por necesidades del medio, potencia de emisión, etc. es frecuente
que cuenten con filtros eliminadores de ruidos para las comunicaciones a nivel físico.
Un ejemplo es el protocolo RIAC desarrollado conjuntamente con EMASA (Empresa Municipal

de Aguas de Málaga) y Contazara (Empresa que fabrica medidores).
MBIGDA_M8T2_160727
12
Medidores de agua Contazar a
Este protocolo forma una red auto-configurable inteligente de sensores inalámbricos. Es un

protocolo propietario que funciona sobre redes inalámbricas, usando la banda libre de licencia de
868 MHz, incorpora un corrector de ruido para que la comunicación radio sea eficaz. Esta
comunicación se establece entre los medidores y entre medidores y un Gateway que por conexión
GPRS da conectividad con los servidores centrales.
Las funcionalidades de este dispositivo incluyen algunos aspectos de los citados:
- Medición precisa durante el tiempo de servicio requerido.

- Funcionamiento fiable durante el tiempo de servicio requerido.
- Sin necesidad de alimentación externa (autogeneración de energía).
- Almacenamiento de información y datos estadísticos de consumo.
- Acceso fácil a la información almacenada del consumo registrado.
Los servicios que ofrece directamente el dispositivo son:
- Fecha y hora de lecturas

- Contador acumulativo de consumo de agua.
- Detección de filtraciones y alarmas de fuga, analiza el consumo y determina una
probable fuga o filtración en la instalación.
- Histiograma de consumo.
- Secciones de horario de consumo, esta información es proporcionada por el medidor y
se utiliza para saber el agua que se consume cada cliente en qué momento del día.
Proporcionar estos datos a cada cliente puede ser especialmente útil para cada cliente
sabe cómo consumir el agua y qué mecanismos de control podría aplicarse para reducir
el consumo, una visión general de estos horarios son importantes para la distribución.
MBIGDA_M8T2_160727
13
En cuanto a los sistemas operativos, estos dispositivos básicos cuentan con limitaciones en la
capacidad de procesamiento, a menudo implementan un sistema operativo a veces de hebra única,
otras con capacidades de multi-hebra, ejemplos de sistemas operativos usados son:
Sistemas Operativos frecuentemente usados en dispositivos

básicos
FreeRTOS
Atomthreads
AVIX-RT
ChibiOS/RT
ERIKA Enterprise
TinyOS
Thingsquare Mist/Contiki
Sistemas operativos usados en dispositivos básicos
Este tipo de dispositivos implican el uso de software no estándar y limitan la participación de

terceros al ser soluciones cerradas, lo que no está reñido con el propósito al ser dispositivos para un
uso específico, resaltamos nuevamente que estas configuraciones muy específicas consiguen un
importante ahorro de costes y son apropiadas para despliegues que involucren un número elevado
de dispositivos.
3.1. Gateways o Pasarelas

Las pasarelas permiten interconectar y traducir protocolos permitiendo nuestro propósito de
conectar los dispositivos finalmente a red WAN Internet. Los protocolos de la rama 802.x definen la
tecnología de redes de área local (LAN) y redes de área metropolitana (MAN).
Los pasarelas a considerar permiten la interconexión entre redes IEEE 802.15.4 o IEEE 802.11, y
redes Ethernet o de telefonía celular.
Ejemplos de estos elementos de red son:
- ZigBee Gateway Device (ZigBee) que traduce entre ZigBee y SOAP e IP.
- Gateways que traducen de RFC-7252 Constrained Application Protocol (CoAP) a
HTTP/REST.
MBIGDA_M8T2_160727
14
Las pasarelas pueden ser elementos de hardware muy básico o elementos más potentes,
dependiendo de las tareas que se quieran establecer en el dispositivo, estas tareas están en el
ámbito de la gestión de datos, ejecución de aplicaciones locales, gestión de los dispositivos.
Para la gestión de datos las pasarelas pueden proporcionar cache de datos, funciones de
filtrado, compactación de datos, agregaciones de datos, y almacenamiento temporal.
Las aplicaciones embebidas suelen proporcionar funcionalidades como alarmas,

funcionamiento en caso de desconexión de la WAN por fallos, abaratamiento de costes por
concentrar datos para reducir el uso de red. Para facilitar las aplicaciones se proporciona un
entorno de ejecución con funcionalidades como por ejemplo OSGi que permite ejecutar
aplicaciones java empaquetadas y que son gestionadas por el entorno, esta gestión de entorno a su
vez puede ser realizada remotamente por otros protocolos, de manera que permiten la tele-
gestión. Para estos propósitos es interesante el uso de protocolos como CPE WAN Management
Protocol (CWMP).
Ejemplo de un Gateway OGSi, con CWMP para la gestión, y c on aplicac iones para cámara y dispositivos UPnP.
3.2. CoAP
El protocolo CoAP http://coap.technology/ (Constrained Application Protocol, CoAP ) es un
protocolo web de transferencia especializada para su uso con nodos restringidos y redes
restringidas en Internet de las cosas, está diseñado para aplicaciones M2M como energía
inteligente y automatización de edificios
MBIGDA_M8T2_160727
15
CoAP es un protocolo de capa de aplicación que está destinada para su uso en dispositivos de
Internet con recursos limitados, tales como nodos WSN. Coap está diseñado para traducir
fácilmente a HTTP para la integración simplificada con la web, y al mismo tiempo cumplir los
requisitos especializados tales como la compatibilidad con multidifusión, a bajo coste, y la
simplicidad. Estos aspectos son extremadamente importantes para internet de las cosas (IoT) y para
dispositivos máquina a máquina (M2M). CoAP se puede ejecutar en la mayoría de los dispositivos
que admiten UDP o un análogo de la UDP.
Existen numerosas implementaciones en diversos lenguajes de CoAP abiertas para cliente,

servidor y proxy.
Ejemplo de diagrama c on uso d e protoco lo CoAP para la ges tión de dispos itivos
3.3. ZigBee
ZigBee se basa en el nivel físico y el control de acceso al medio (MAC) definidos en la versión de
2003 del estándar IEEE 802.15.4. El desarrollo de la tecnología se centra en la sencillez y el bajo
costo más que otras redes inalámbricas semejantes de la familia WPAN, como por ejemplo
Bluetooth. El nodo ZigBee más completo requiere en teoría cerca del 10% del hardware de un nodo
Bluetooth o Wi-Fi típico; esta cifra baja al 2% para los nodos más sencillos.
MBIGDA_M8T2_160727
16
Ejemplo de Módulo Z igBee pa ra dispos itivo
Zigbee incluye perfiles de aplicación, como lectura automática, automatización de edificios

comerciales y automatización de hogares basados en el principio de uso de una librería de
soluciones.
Ejemplo de dispos itivo Z igBee sobre 802.15.4
Un aspecto relevante de ZigBee es la variedad de dispositivo en cuanto a la capacidad del

hardware:
- Dispositivo de funcionalidad completa (FFD): También conocidos como nodo activo. Es

capaz de recibir mensajes en formato 802.15.4. Gracias a la memoria adicional y a la
MBIGDA_M8T2_160727
17
capacidad de computar, puede funcionar como Coordinador o Router ZigBee, o puede

ser usado en dispositivos de red que actúen de interfaz con los usuarios.
- Dispositivo de funcionalidad reducida (RFD): También conocido como nodo pasivo.
Tiene capacidad y funcionalidad limitadas (especificada en el estándar) con el objetivo
de conseguir un bajo coste y una gran simplicidad. Básicamente, son los
sensores/actuadores de la red.
Un nodo ZigBee (tanto activo como pasivo) reduce su consumo gracias a que puede permanecer
dormido la mayor parte del tiempo (incluso muchos días seguidos). Cuando se requiere su uso, el
nodo ZigBee es capaz de despertar en un tiempo ínfimo, para volverse a dormir cuando deje de ser
requerido. Un nodo cualquiera despierta en aproximadamente 15 ms.
Se espera que los módulos ZigBee sean los transmisores inalámbricos más baratos de la historia
y, además, producidos de forma masiva. Tendrán un costo aproximado de alrededor de los 8
dólares, y dispondrán de una antena integrada, control de frecuencia y una pequeña batería.
Ofrecerán una solución tan económica porque la radio se puede fabricar con muchos menos
circuitos analógicos de los que se necesitan habitualmente.
4. Dispositivos avanzados
Los dispositivos avanzados consisten en dispositivos que tienen características y funcionalidades
para los que se requiere más potencia de la típicamente usada en aplicaciones M2M, entre estas se
encuentran capacidades de procesamiento y almacenamiento superiores, que permiten la
ejecución en el dispositivo de aplicaciones más complejas, más allá de la captación de datos y
almacenamiento básico. Un sistema de entrada y salida avanzado, por ejemplo de pantalla y
teclado o pantalla táctil. Capacidades de captación, procesamiento y almacenamiento de datos que
requieren altas prestaciones, como por ejemplo podría ser la captación de imágenes en video o
audio, la conversión a formatos diversos de compresión y transmisión de video o audio y la
transmisión de video o audio en streaming.
También se aprovecha la capacidad de procesamiento para dotar a los dispositivos avanzados

de la posibilidad de asumir funciones de gateway para otros dispositivos.
MBIGDA_M8T2_160727
18
Los sistemas operativos para este tipo de dispositivos pueden ser GNU/Linux, sistemas
operativos de tiempo real (RTOS) comerciales, como ENEA’s OSE, WindRiver’s VxWorks, or
Blackberry’s QNX.
Estos dispositivos por su capacidad de cómputo presentan un stack de red de buenas

prestaciones, por lo que la conectividad IP no representa un reto en recursos hardware.
Por otra parte el uso de tecnologías abiertas y extendidas así como APIs de uso extendido
facilitan la entrada de desarrolladores y la construcción de aplicaciones, que se verá muy facilitada
por el uso de interfaces y formatos próximos a los desarrolladores del internet de las personas,
como HTTP/REST/JSON.
En los dispositivos avanzados son factores muy relevantes y que merecen especial atención al
valorar un dispositivo las características de los siguientes aspectos:
- Dispositivos con batería que usan conexiones celulares de consumo de batería

ultrabajo.
- Dispositivos que obtienen la energía de forma autónoma, total o parcialmente, de su
medio físico.
- Dispositivos con versatilidad en cuanto al ancho de banda necesario, usado, y con
posibilidad de usar varios protocolos.
- Capacidad de ajustar la sensibilidad al ancho de banda disponible, es decir, enviar por
unidad de tiempo menos mensajes con más bytes por mensaje, o más mensajes con
menos bytes por mensaje.
- Adopción de procesadores multicore.
- Mejoras en la gestión de la concurrencia y paralelismo.
4.1. Prototipos y dispositivos genéricos.

Entre los dispositivos avanzados se encuentran dispositivos que, con una configuración
genérica, presentan muchas interfaces y facilidades para el desarrollo de soluciones prototipo
hardware, o incluso definitivas dependiendo de los requerimientos. Estos dispositivos entre los que
MBIGDA_M8T2_160727
19
se encuentran Arduino o Raspberry PI, permiten realizar fácilmente prototipos o demostradores.

Sus capacidades de cómputo son altas y disponen de almacenamiento flash, puertos para conectar
periféricos, y configuraciones accesorias como cámaras, cables, cajas, etc.
Está muy extendido el uso de Arduino en casos en que el desarrollo es próximo a técnicos de
hardware, en cambio Raspberry Pi es más extendido o accesible para técnicos de software.
4.1.1. Arduino
Arduino es una compañía de hardware libre, desarrolla placas para desarrollo y prototipado con
un microcontrolador y un entorno de desarrollo (IDE) para facilitar el uso de la electrónica en
proyectos multidisciplinarios. Este sistema está muy orientado a técnicos electrónicos, a diferencia
de Raspberry Pi.
El hardware se presenta en un circuito impreso con un microcontrolador, usualmente Atmel

AVR, y puertos digitales y analógicos de entrada/salida, que pueden conectarse a placas de
expansión (shields) que amplían las características de funcionamiento de la placa.
Por otro lado, el software consiste en un entorno de desarrollo (IDE) basado en el entorno de
Processing y lenguaje de programación basado en Wiring, así como en el cargador de arranque
(bootloader) que es ejecutado en la placa.
El microcontrolador de la placa se programa a través de un ordenador personal, haciendo uso

de comunicación serie mediante un conversor RS-232 a TTL.
La propia descripción del sistema ya deja ver que se trata de un producto de electrónicos para
electrónicos, que facilita el diseño y prototipado de componentes electrónicos. Para los
desarrolladores de software, usar Arduino como prototipo del hardware sobre el que se ejecutará
una solución resulta tedioso o difícil, otros sistemas facilitan un enfoque más utilitario que
proporciona a los desarrolladores la capacidad de diseñar su software con más facilidad.
MBIGDA_M8T2_160727
20
Ejemplo de pla ca Arduino
Existen muchas placas o versiones de Arduino, y un conjunto de extensiones hardware para

proporcionar conectividades, o capacidades adicionales.
4.1.2. Raspberry PI
Está basado en un System-on-a-chip que contiene un procesador central (CPU), un procesador

gráfico (GPU), un procesador de señales (DSP) y una memoria SDRAM y un puerto USB. La versión
más reciente incorpora un 1.2GHz 64-bit quad-core ARMv8 y 1GB de RAM compartido con la GPU.
La GPU es 1080p30 H.264/MPEG-4 AVC3, Para almacenamiento se usa memoria FLASH en tarjeta
SD. No incluye en placa la fuente de alimentación. Más allá del System-on-a-chip, la placa
básicamente se destina a conectividad con periféricos de E/S.
Dispone de 4 puertos USB, 1 conector MIPI CSI que permite instalar un módulo de cámara
desarrollado por Raspberry. 1 conector RCA (PAL y NTSC), 1 conector HDMI (rev1.3 y 1.4), 1 Interfaz
DSI para panel LCD63.
MBIGDA_M8T2_160727
21
Para dotarla de conectividad de red dispone de interfaces 10/100 Ethernet (RJ-45) vía hub USB,
Wifi 802.11n, y Bluetooth 4.1. A través de los puertos USB se pueden conectar otros periféricos de
conectividad, como un modem 3G.
Soporta una gran cantidad de distribuciones de sistemas operativos, software y dispone de

muchos periféricos compatibles. Entre los sistemas operativos soportados están varios Linux,
incluido Android, Unix, Windows IoT.
Detalle del dispos it ivo Raspbe rry Pi 3. Caracter ísticas pr inc ipales y conec tores
La capacidad de un sistema Raspberry Pi permite montar sobre el un sistema operativo, un

motor de base de datos ligero como MongoDB, Redis, etc, máquina virtual java, aplicaciones java,…
4.1.3. Cinterion Gemalto Concept Board
A diferencia de Raspberry o Arduino, que son dos iniciativas pioneras pero provenientes del
mundo académico, en el mundo empresarial otras iniciativas para dispositivos IoT también están
disponibles con una variedad de dispositivos muy alta y de propósitos muy específicos.
Gemalto es una empresa que fabrica soluciones innovadoras para IoT, entre las cuales existen
placas para el diseño de prototipos y componentes para diseños profesionales. Por ejemplo ha
MBIGDA_M8T2_160727
22
presentado un dispositivo de voz sobre LTE (VoLTE) que permite voz y datos simultáneamente,
siendo una alternativa a 4G incluso en coste, apropiado para uso en voz, salud, seguridad y hogar
inteligente.
Sus dispositivos por ejemplo se están aplicando en los modelos más avanzados en integración y
prestaciones como por ejemplo APPLE SIM, en el que proporcionan la conectividad con redes de
telefonía. También se orientan en sectores como vehículos inteligentes.
En el campo del desarrollo de prototipos y pruebas de concepto, Gemalto dispone de Cinterion

Gemalto Concept Board. Esta es una placa similar al concepto de Arduino pero con una tecnología
más avanzada y mayores capacidades integradas en la placa.
Cin terion Gemalto Con cept Bo ard
La placa dispone de:
8 GPIO, 2G/3G, Java™ ME embebido, es compatible con un conjunto de shields Arduino, y

extensiones propias, slot para tarjeta SIM, con detección de tarjeta y para alojar baterías
recargables y con circuito de recarga integrado en la placa. Interfaz serie hasta el modulo Java, y
Bridge FTDI USB/VCP. Interfaz serie LEDs, y funcionalidad de señalización RING and SLEEP para
optimizar la duración de batería, USB y antena GSM/UTMS.
MBIGDA_M8T2_160727
23
Gemalto es un dispositivo a medio camino entre Arduino y Raspberry Pi, que facilita el
desarrollo de aplicaciones IoT sin perder la proximidad a las capacidades restringidas de recursos en
el dispositivo.
4.1.4. Intel GALILEO GEN 2 DEVELOPMENT BOARD
Es una placa de la familia de Arduino desarrollada por Intel y certificada para el desarrollo y
creación de prototipos de las placas basadas en la arquitectura Intel y diseñado específicamente
para fabricantes, estudiantes, educadores, aficionados y la electrónica de bricolaje.
Galileo dispone de las siguientes características: Procesador Intel Quark SoC X1000 de 32 bits,
single-core, single-thread, con conjunto de instrucciones del procesador Pentium arquitectura, a
velocidades de hasta 400 MHz.
Dispone de interfaces I / O estándares de la industria, incluyendo ranura mini-PCI Express, 100

Mb puerto Ethernet, ranura microSD, puerto USB.
En cuanto a memoria dispone de 256 MB DDR3, 512 KB de SRAM incrustada, 8 MB NOR Flash y
EEPROM estándar de 8 kb en placa, además de soporte para tarjetas microSD de hasta 32 GB.
Compatibilidad de hardware y conector con una amplia gama de shields Arduino. 12 GPIO
nativas para una mayor velocidad. 12-bit de modulación de ancho de pulso (PWM) para el control
más preciso de servos y respuesta más suave.
En software y sistema operativo, el kit de desarrollo incluye C, C ++, Python, y Node.js /

Javascript para el desarrollo de aplicaciones de sensores conectados a Internet de las cosas.
Soporta el sistema operativo Linux Yocto, VxWorks (RTOS), y Microsoft Windows.
4.1.5. Intel Edison DEVELOPMENT BOARD
Intel Edison es un módulo que aumenta las capacidades de placas basadas en arquitectura
Arduino, en definitiva consiste en montar entorno de desarrollo hardware y software. El
microcontrolador es single-core de alto rendimiento y con CPU dual-core que admite la
recopilación compleja de datos en un formato de bajo consumo de energía.
MBIGDA_M8T2_160727
24
Sobre este módulo Intel propone varios kits, placas y configuraciones, así como servicios
orientados a facilitar el desarrollo de productos innovadores en IoT.
Kit de desarro llo Hardware / Software Inte l Ed ison, p laca co n slot para e l modulo Edison
Las funciones integradas de Wi-Fi, Bluetooth Low-Energy (LE), memoria y almacenamiento

simplifican la configuración y aumentan la escalabilidad. Se ofrecen 40 interfaces GPIO múltiples
con opciones de placas de expansión para facilitar el diseño del proyecto total y aportar flexibilidad.
Para los sensores o extensiones disponen de una biblioteca de productos / proveedores de

extensiones compatibles. Además disponen de kits orientados para SmartHome, Wearables,
robots,…
4.1.6. GlobalCode IoT Surfboard
GlobalCode es una compañía que ha desarrollado una placa que ofrece alta conectividad para el
aprendizaje, prototipado y desarrollo de proyectos, es una placa restringida en capacidades de
almacenamiento y cómputo, al estar basada en Arduino Nano, pero está altamente sensorizada, y
permite ser integrada con Raspberry Pi e Intel Edison para disponer de capacidades aumentadas.
Basada en Arduino Nano, con microcontrolador Amtel ATMega a 16Mhz, y de 32 KB de

memoria flash para almacenar código (de las cuales 2Kb se reservan para código de arranque), 2 KB
of SRAM y 1 KB EEPROM, las capacidades de cómputo son bajas, pero se orienta a facilitar el
desarrollo de aplicaciones incorporando conectores para sensores y actuadores habituales en
muchos proyectos de Internet de las Cosas y también de slots para dotar de conectividad.
MBIGDA_M8T2_160727
25
Para dotar de conectividad dispone de módulo para la conexión Zigbee, Wi-Fi o Bluetooth, y
conector para RXTX, GPS o modem 3G.
En cuanto a dispositivos facilita el desarrollo al disponer directamente de conector para servo y

sonar, conector para sensor de alcohol, sensor de luminosidad, presencia, infrarrojos y humedad
integrado en la placa. Para control también incluye relé, 4 transistores, y un altavoz.
Placa Io T Glob alCode Sufboar d
4.2. Dispositivos de consumo en IoT

Además de los dispositivos específicos, básicos o avanzados y desarrollados en el entorno M2M
o en la Internet de las Cosas, otros dispositivos genéricos tienen cabida en el desarrollo de Internet
de las Cosas y en las aplicaciones. Son dispositivos ya existentes que, por sus capacidades y la
extensión de su uso entre las personas, pueden jugar un papel muy importante en IoT.
4.2.1. Smartphones
Los teléfonos inteligentes son dispositivos avanzados en capacidades de cómputo,

almacenamiento y comunicaciones, que disponen de conectividad y habitualmente y son
transportados por los usuarios. Estos aspectos lo hacen idóneo para muchas aplicaciones de
internet de las cosas.
MBIGDA_M8T2_160727
26
Un sensor es una pieza de tecnología que mide una cantidad física y la convierte en una señal.
Esta señal puede ser utilizada por una aplicación o leída por un individuo. Dependiendo de qué
teléfono se tiene, va a contener diferentes sensores.
Un teléfono inteligente moderno está equipado con unos 10 sensores, capaces de capturar
aspectos como la localización, la orientación del dispositivo, las condiciones de luz... En conjunto,
estos sensores producen una enorme cantidad de datos, tanto en forma no estructurada (imagen o
vídeos), así como estructurados, como datos de GPS o de aceleración.
Con el auge de los elementos Wearables, como Android Wear o Apple Watch, el teléfono
inteligente juega cada vez más este papel adicional. En esta nueva función puede ser considerada
como el "cerebro" y/o pasarela de la Body Area Network (BAN), teniendo en cuenta las capacidades
de almacenamiento y comunicación (3G, Wi-Fi, Bluetooth) de los teléfonos inteligentes.
Con tecnologías como Near Field Communications (NFC), los teléfonos inteligentes pueden
funcionar no sólo como sensores, sino también como actuadores, es decir, activar acciones (como
pagos) o controlar otras cosas (o participar en el control), como TV o coches.
Los sensores de uso en IoT más evidentes son todo sobre el movimiento. Estos incluyen el
acelerómetro, para medir el movimiento y la orientación, y el giroscopio, para medir la rotación
angular a través de tres ejes, y dando más precisión a la lectura acelerómetro.
Los servicios de localización son atendidos con un magnetómetro para detectar el Norte
magnético y algún tipo de chip de GPS o una variante relacionada a trazar su posición en el mapa.
Además de esto existen los más obvios, como un sensor de proximidad para reconocer cuando
se mueve el teléfono cerca de la cara durante una llamada, un micrófono y una serie de sensores
dentro de la cámara del teléfono para asegurarse de tomar buenas imágenes.
También hay sensores ambientales, que miden factores como la temperatura, presión
barométrica y luminosidad, aunque éstos se encuentran más comúnmente en los teléfonos de
gama alta. Hay sensores adicionales como los teléfonos como iPhone 6S y Samsung Galaxy S7 que
tienen un sensor de huellas dactilares.
MBIGDA_M8T2_160727
27
Este último también va más allá al embalaje incorporado un monitor de frecuencia cardíaca que
comprende tanto un LED y el sensor de pulso. El Google Nexus 5 tiene un podómetro incorporado,
mientras que otros móviles utilizan datos de una serie de sensores para rastrear los pasos.
El uso de estos sensores es variado, a veces para proporcionar funcionalidad al usuario, otras
para el propio dispositivo, por ejemplo el coprocesador de movimiento en el iPhone puede
averiguar cómo se está utilizando el teléfono, si está en una mesa o lo llevas en el bolsillo, y utilizar
esa información para decidir si se debe alimentar ciertos elementos o no, de manera que logre un
ahorro de batería.
Pero estos datos están accesibles en el dispositivo para acceder a ellos y ser usados por
aplicaciones a través de APIS de programación.
Dado que estos dispositivos no están pensados para sensorizar, sino que es una tarea que han
incorporado adicionalmente, y que se mueven en el ámbito de la información personal y la
privacidad, tenemos que tener en consideración que el sistema puede no permitirnos acceder o
usar los datos, o someterlo a que el usuario tenga que dar su permiso. A la hora de realizar
aplicaciones de IoT usando un Smartphone y sus sensores, nos estaremos sometiendo y
necesitaremos a que estos sensores estén accesibles para nosotros.
Los Smartphone además tienen conectividad como hemos comentado, para desplegar sensores
específicos o interactuar con otros dispositivos en el hogar, o en un vehículo por ejemplo.
En este capítulo estamos hablando del Smartphone como dispositivos para el IoT, a nivel de
obtener datos de sensores, actuar como nodo o Gateway, etc. No debemos confundirlo con el uso
de un Smartphone como interfaz de usuario para interactuar con dispositivos de Internet de las
Cosas a través de aplicaciones.
4.2.2. Smart TV
El Smart Tv es un dispositivo que, como el teléfono móvil, se encuentra en una posición de

mercado y de hábitos de uso privilegiada para Internet de las Cosas. La televisión inteligente es un
dispositivo con altas capacidades de procesamiento y/o almacenamiento, y dotado de sistemas de
MBIGDA_M8T2_160727
28
conectividad. Si bien inicialmente el dispositivo se centró en conectarse a internet, se ha dotado de

bastantes interfaces de conectividad que trasciende ya al uso de contenidos multimedia.
Podemos considerarlo técnicamente igual que un Smartphone en el sentido de que, si bien su

propósito principal es diferente aunque cada vez menos, para algunas actividades puede ser
sensorizado y actuar como un intermediario de esta información. En este caso el dispositivo no es
transportado por el usuario, sino que se postula para liderar el espacio del hogar inteligente.
Gama de disposit ivos Io T Samsung alrededor del SmartTv.
Como ejemplo podemos tomar la iniciativa de Samsung Electronics que anunció que el centro
de su Smart TV en 2016 será Internet de las Cosas (IoT), conectada con la plataforma SmartThings.
SmartThings es una plataforma abierta que permite a los usuarios conectar, administrar y
controlar los dispositivos inteligentes y servicios de IoT. Permitiendo que el propio televisor para
actuar como controlador para toda la casa inteligente. Samsung ha desarrollado su propia
tecnología de concentrador IoT con SmartThings en los televisores SUHD 2016.
Con los televisores SUHD se puede conectar y controlar dispositivos de Samsung y los sensores
SmartThings, así como otros dispositivos compatibles, más de 200 SmartThings. Estos incluyen
desde las luces conectadas y las cerraduras de termostatos y cámaras, en una amplia gama de
fabricantes de terceros de alta calidad. Para el pleno apoyo de la conectividad con dispositivos
compatibles SmartThings, se conecta un dispositivo “SmartThings Extender” a través de un
adaptador USB.
MBIGDA_M8T2_160727
29
4.3. Wearables y BAN

En el ámbito de los sensores cabe destacar que estos pueden ser embebidos en diferentes
ámbitos, algunos de ellos muy interesantes para aplicaciones prácticas innovadoras, concretamente
en el ámbito del cuerpo del usuario. Sin llegar a ser implantes (aún) existen dispositivos que se
pueden introducir en prendas, o complementos, y que interactúan con Internet de las Cosas. Estos
dispositivos son básicamente sensores que interactúan con el teléfono inteligente.
Algunos se comercializan como gadgets, como los Smartwatch o las pulseras para deporte como
FitBeat, o joyas inteligentes, otros acabarán formando parte de las prendas o complementos para
aumentar sus prestaciones, (prendas deportivas, prendas con captación de datos de salud,
complementos)… Se pueden implementar dispositivos lavables, con alimentación cableada o con
batería, son extremadamente pequeños.
Al final el teléfono móvil, típicamente, o dispositivos en el entorno, (oficina, hogar, vehículo)

podría acceder a la información que le proporciona sobre el usuario las prendas inteligentes o los
dispositivos Wearables.
El conjunto de dispositivos que un usuario porta recopilando información o utilizando

información alrededor de su cuerpo se ha denominado BAN (Body Area Network).
Los Wearables comercializados como “gadgets” tienen a menudo la capacidad de interactuar

con el usuario, realizar de interfaz de usuario, además recogen a través de sensores algún tipo de
información, sobre la piel, el movimiento, pulso, temperatura,… en este tipo de dispositivos se
encuentran Smartwatchs, pulseras, joyas inteligentes, o Google Glasses.
Los wearables embebidos en prendas para captar información son más específicos, se pueden
embeber en ropa, o complementos, y no tienen la necesidad de estar en lugares visibles, ni de
hacer de interfaz de usuario. Obviamente tienen menos capacidades hardware.
Al igual que ocurre con las placas de IoT existen módulos para aprendizaje, prototipado, etc.
Dispositivos que con batería o alimentados desde una placa o dispositivo externo, despliegan
sensores, son lavables, pequeños y embebibles en prendas. Estos dispositivos lejos de ser llevables
MBIGDA_M8T2_160727
30
a mercado, sirven para realizar prototipos o pruebas de concepto, como podrían ser zapatillas
inteligentes, ropa deportiva inteligente, vendas sanitarias inteligentes, y un largo etcétera.
En este contexto de prototipado destacan por ejemplo los dispositivos extensiones de Arduino
para desarrollo de Wearables. Hay varias marcas que fabrican sobre el hardware Arduino, como
Adafruit, que dispone de muchos dispositivos y materiales para construir prototipos Wearables.
Como ejemplo diseñemos una cremallera inteligente, conectada a un dispositivo, se pueden

usar entradas digitales o analógicas, en este caso usaremos entradas digitales.
Entradas digitales
Borne
Hilo conductor
10 Ohm resistencia
5V DC
Diseño de pro totipo de crema llera in teligente
Se cose un hilo conductor en los bordes internos de la cremallera cruzando de la parte frontal a
la trasera, entre diente y diente, de manera que entren en contacto al estar cerrada (hilo rosa) y no
estén en contacto cuando está abierta.
Una resistencia de 10 Ohmios (por requerimiento del circuito de conexión) se une a uno de los
extremos.
A lo largo del hilo en el otro lado de la cremallera ponemos bornes espaciados a cierta distancia,
conectados con el hilo conductor, destinados a conectar un cable a una entrada digital.
MBIGDA_M8T2_160727
31
Conexión con una pla ca Arduino de la cremallera in t eligente
En la placa Arduino se conectan las entradas digitales a los cables unidos a los bornes, el otro
cable del otro lado de la cremallera se conectará a la salida de alimentación de 5V.
El kit de desarrollo de Arduino facilita la comprobación de las entradas digitales, y su

comparación con el nivel de activación 1, o 0. Por lo que se puede detectar el nivel de activación de
cada borne de la cremallera y por tanto el estado de la cremallera.
Esto sería un prototipo de sensor, con el que se podría desarrollar una funcionalidad de internet
de las cosas, haciendo accesible la cremallera desde internet para consultar su estado o recopilando
su estado y realizando algún tipo de análisis que aporte cierta funcionalidad.
En la parte de diseño estaría el diseño industrial de la cremallera inteligente, y su conectividad

con algún dispositivo.
El sistema Arduino para la construcción de prototipos dispone de dispositivos para realizar

Wearables con sensores:
4.3.1. Arduino Gemma
Es una placa electrónica hecha por Adafruit basada en la ATtiny85. Dispone de 3 pines digitales
de entrada / salida (de los cuales 2 pueden utilizarse para salidas PWM y 1 como entrada
MBIGDA_M8T2_160727
32
analógica), un resonador de 8 MHz, una conexión micro USB, un conector JST para una batería de
3,7 V, y un botón de reinicio. Consta de 512 Bytes de SRAM y 512 Bytes de EEPROM, y una memoria
Flash de 8Kb de los cuales 2.75 Kb son reservados para el arranque.
Arduino Gemma
4.3.2. Arduino LilyPad
Es una placa orientada a e-textiles y proyectos en los que se quieren llevar dispositivos puestos.
Se puede coser a la tela y usar hilo conductor para fuentes de alimentación, sensores y actuadores.
Se puede conectar directamente al ordenador usando sólo un cable micro USB.
El USB Arduino LilyPad es una placa electrónica basada en el ATmega32u4. Cuenta con 9 pines
digitales de entrada / salida (de los cuales 4 pueden utilizarse para salidas PWM y 4 entradas
analógicas), un resonador de 8 MHz, una conexión micro USB, un conector JST para una batería de
3.7V Li-Po, y un botón de reinicio.
Consta de 2,5 Kb de SRAM y 1 Kb de EEPROM, y una memoria Flash de 32 Kb de los cuales 4 Kb

son reservados para el arranque.
Arduino LilyPad
MBIGDA_M8T2_160727
33
4.3.3. Arduino LilyPad Main Board
El USB Arduino LilyPad Main Board es una placa electrónica basada en el ATmega128 o 328V.
Cuenta con 14 pines digitales de entrada / salida (de los cuales 6 pueden utilizarse para salidas
PWM y 6 entradas analógicas, una conexión micro USB, un conector JST para una batería de 3.7V Li-
Po, y un botón de reinicio. Consta de 512 Bytes de SRAM, 1 Kb de EPROM y 16 Kb de memoria
Flash de los cuales 2 kb se reservan para arranque.
Arduino LilyPad Ma in Board
4.3.4. Arduino LilyPad Simply
El LilyPad Simply tiene sólo 9 pines para entrada / salida. 4 entradas analógicas, cuenta con un
conector JST e incorpora circuito de carga para baterías de polímero de litio. Se basa en el
ATmega328.
Consta de 2 Kb de SRAM y 1 Kb de EEPROM, y una memoria Flash de 32 Kb, de los cuales 2 Kb

MBIGDA_M8T2_160727
34
Arduino LilyPad S imply
4.3.5. LilyPad SimpleSnap
Es un dispositivo para crear proyectos de e-textiles usando módulos que se pueden poner y
quitar fácilmente de las prendas, componiendo un sistema. El SimpleSnap es similar al Simply pero
incluye una batería de polímero de litio recargable y conectores rápidos hembra en formato de
botón de presión.
Consta de 9 pines para entrada / salida. 4 entradas analógicas, cuenta con un conector JST e
incorpora circuito de carga para baterías de polímero de litio. Se basa en el ATmega328.
Consta de 2 Kb de SRAM y 1 Kb de EEPROM, y una memoria Flash de 32 Kb, de los cuales 2 Kb

Arduino LilyPad S impleSnap
4.3.6. Otros Wearables
Existen muchos dispositivos Wearables, dentro y fuera del universo Arduino, en el caso Arduino
es relevante el fabricante Adafruit, que dispone de muchos materiales y dispositivos para construir
prototipos.
MBIGDA_M8T2_160727
35
4.4. Joyas inteligentes

En el área de los dispositivos de entrada y salida, y complementos destacan los Smartwatch y las
joyas inteligentes. Las joyas inteligentes ofrecen alguna pequeña funcionalidad oculta en su
propósito de ser un complemento de moda, o camuflan su característica de dispositivo. Destacan
en este ámbito Swarovski y Vinaya, hay un gran recorrido en este campo, y de momento los
esfuerzos están en encontrar funcionalidades y no ser un dispositivo escamoteado sino
verdaderamente una joya con valor añadido.
Joyas Inteligentes Vin aya (co lgante y an illo)
Los dispositivos de Vinaya (Altruis) permiten conectarse por Bluetooth al Smartphone y alertan
mediante una pequeña vibración al usuario que los lleva puesto según los eventos que sucedan, de
manera que no necesita estar mirando el móvil continuamente y ser notificado cuando algo
importante suceda. Se presentan en forma de anillos, pulseras o colgantes, en cuanto a batería se
cargan por USB y tienen un tiempo de funcionamiento por carga de alrededor de un mes. Los
dispostivos de Swarovski se enfocan hacia la monitorización de actividades, calidad del sueño, etc.
Joyas in te ligentes Swarovski
MBIGDA_M8T2_160727
36
4.5. Smartwatch
Los Smartwatch son wearables destinados a facilitar E/S sin necesidad de usar el Smartphone,
además incluyen algunos sensores al estar fijados en la muñeca a través de la pulsera al usuario.
Con estos sensores y conectados con el Smartphone a través de Bluetooth reemplazan a los relojes
tradicionales, proporcionando un pequeño interfaz de E/S para controlar u obtener información de
aplicaciones que residen en el Smartphone. Estas aplicaciones pueden hacer de pasarela para
servicios en la nube o control remoto. La carga de energía se realiza entre diaria y semanalmente
en función del uso, a través de un dispositivo de carga USB.
4.5.1. Apple watch
El dispositivo Apple Watch es compatible únicamente con teléfonos Apple, dispone de un

avanzado interfaz de usuario y su presentación estética es muy lograda, manteniendo el aspecto de
complemento de un reloj.
La resolución de pantalla es 312 x 390 en el modelo de 42 mm y de 272 x 350 en el modelo de

38 mm. La pantalla está construida en cristal zafiro.
El sistema operativo WatchOS que incorpora el Apple Watch es completamente nuevo y

comparte muy pocos nexos en común con iOS. Apple Watch es capaz de diferenciar entre una
simple pulsación y la presión. Un actuador lineal en la pulsera transmitirá una sensación diferente a
tu muñeca en función del tipo de interacción que hagamos con el reloj, o dependiendo del tipo de
alerta, notificación o mensaje que recibamos. Dispone de un sensor de ritmo cardíaco, giroscopio,
acelerómetro y brújula. El sistema de carga es de inducción magnética y la duración de la carga es
18 horas de uso de apps combinado con reposo.
MBIGDA_M8T2_160727
37
Apple Smartwatch
Para el desarrollo y la distribución de aplicaciones Apple aplica una política similar a las apps
móviles, dispone de un market y un proceso de publicación muy estricto en cuanto a la calidad,
formato, etc.
Los proyectos para Apple Watch consisten en dos paquetes separados: una aplicación de reloj y
una extensión WatchKit. La aplicación de reloj contiene el guión gráfico y archivos de recursos
asociados a todas las interfaces de usuario de la aplicación. El paquete de extensión WatchKit
contiene un delegado y los controladores para la gestión de las interfaces y para responder a las
interacciones del usuario. Estos paquetes se distribuyen dentro de una aplicación para iOS, y se
instalan desde iOS en el Apple Watch del usuario, se ejecutan localmente en el reloj.
Apple Watch carga de una aplicación en el reloj
Un proyecto watchOS debe incluir una aplicación de reloj, pero también puede incluir un
“glance” (vista especial para mostrar información de un vistazo), “notificaciones personalizadas”
MBIGDA_M8T2_160727
38
(mostrar información a modo de notificación emegente), y “complicaciones” (mostrar información

a modo de notificación prioritaria). Cada una de estas interfaces proporciona una manera única
para interactuar con la aplicación, permiten transmitir información importante para el usuario con
mayor rapidez que la interfaz principal de la aplicación. Aunque son opcionales, estas interfaces no
deben considerarse secundarias. De hecho son la interfaz principal para muchos usuarios y
aplicaciones.
La mirada, las notificaciones y las complicaciones no son ejecutables por separado. En lugar de
ello, la interfaz de la mirada y las notificaciones están incluidos en el guión gráfico de la aplicación
Reloj. El código para la gestión de las miradas, las notificaciones y las complicaciones son parte de
su extensión WatchKit.
El Watch Connectivity framework ofrece varias opciones para enviar datos entre una aplicación
para iOS y la extensión WatchKit. Cada opción está destinada a un uso diferente. La mayoría de las
opciones son para realizar una transferencia unidireccional de datos en segundo plano y son una
forma conveniente para entregar actualizaciones. Las transferencias de primer plano permiten
enviar un mensaje inmediatamente y esperar la respuesta. La Tabla 4-1 enumera los métodos que
utiliza para las pautas de comunicación y de uso para cada uno.
Para el desarrollo de las aplicaciones es necesario usar las herramientas de desarrollo de Apple.
4.5.2. Android Wear
Similar a la solución de Apple pero con la filosofía Android, Android Wear es un sistema
operativo para Wearables que ejecuten Android, por su orientación actual y necesidades de
computo se puede usar en Smartwatch, joyas inteligentes o pulseras, los fabricantes de hardware
adaptan la versión de Android a su dispositivo según las funcionalidades que quieren proporcionar,
al igual que se hace con los SmartPhone Android.
Android Wear proporciona funcionalidades similares a las de Apple WatchOs, y varios

fabricantes ofrecen productos soportados por este sistema operativo entre ellos Samsung o
Huawei, Motorola, LG,… Estos dispositivos tienen diferentes características hardware.
MBIGDA_M8T2_160727
39
Samsung Smartwatch con Andr oid Wear
El desarrollo de aplicaciones Android Wear se realiza desde Android Studio, un IDE de desarrollo
Android. La arquitectura de las aplicaciones Android Wear es asimilable a la de Apple WatchOS, se
manejan conceptos similares.
El dispositivo puede conectarse al Smartphone Android y utilizarlo como aplicación Gateway

para la conexión con Internet.
Las aplicaciones de Android Wear se distribuyen a través de un market Google Play.
4.6. Pulseras
Con menores prestaciones que los SmartWatch existe un subconjunto de dispositivos en forma
de pulsera que realizan algunas de las tareas similares, su uso se orienta sobre todo a actividades
deportivas, estas por ejemplo como FitBeat. Cada sistema tiene sus características de sensorización
y presentación de datos al usuario.
5. Sistemas Operativos
Además de los dispositivos básicos y las soluciones de sistema operativo específicas o muy
orientadas al dispositivo, como Contiki, toda placa debe disponer de un sistema operativo, respecto
a las placas orientadas a desarrollo, prototipo o pruebas de concepto, podremos encontrar muchas
filosofías.
MBIGDA_M8T2_160727
40
Si bien los dispositivos más potentes como Raspberry Pi tienen capacidad para ejecutar
versiones de los sistemas operativos habituales en otros ámbitos, otras como Edison, Gemalto o
Arduino requieren un sistema operativo propio, como los dispositivos de capacidades restringidas,
pero además de herramientas y soluciones para el desarrollo y la compilación propias, para agilizar
su propósito.
En realidad en IoT podremos establecer la barrera no tanto en el propio hardware sino en el

sistema operativo que son capaces de ejecutar, de modo que, si pudiéramos, sería ideal poder
ejecutar una versión Linux o Windows por ejemplo en el dispositivo más ínfimo. La realidad no es
así, solo los dispositivos más potentes podrán ejecutar versiones ligeras de sistemas operativos de
propósito general. En esta barrera se sitúa Raspberry Pi que puede ejecutar versiones de sistemas
operativos Linux, Android, Windows IoT,… y sus consiguientes aplicaciones o versiones de
aplicaciones. Por ejemplo hacer funcionar una base de datos MongoDB en Arduino es complejo o
imposible, mientras que hacerla funcionar en Raspberry es “inmediato”.
En cuanto a los Smartphones principalmente podemos identificar Android, Apple, Windows 10,
y Mozilla FireOs. Android es una familia de sistemas operativos basada en Linux.
En cuanto a los SmartTV los sistemas operativos están especializándose o absorbiendo

funcionalidad específica, por una parte se mantienen televisiones con sistemas operativos propios
del fabricante, por otra se empiezan a incorporar sistemas operativos Android TV, Apple o Mozilla
FireOs.
En todo caso se están lanzado muchas iniciativas a fijar el estándar o ser una opción de “sistema
operativo del hogar” para estos dispositivos desde Microsoft (Windows IoT), Linux (Zephyr), Google
(Brillo), Huawei (LiteOs),…
Es importante notar que, cuando se trata de información de marketing y consumo al gran

público, el término IoT prácticamente se restringe al hogar inteligente, la salud, y los dispositivos
son el móvil, la televisión, los electrodomésticos y los Wearables. Nuestro campo de visión es más
amplio y esto lo veríamos más como un “sistema operativo del hogar, la persona…”, y se excluyen
MBIGDA_M8T2_160727
41
para el gran público otros propósitos más específicos o visiones más amplias que nosotros si
debemos tener, como la agricultura, la sanidad, etc.
En el caso de los Wearables destacan Apple WatchOS, y Android Wear.
6. Gestión de los dispositivos

Dado que en IoT a diferencia de M2M, los proyectos son más globales, hay muchos aspectos
muy importantes para la viabilidad de un Proyecto en cuanto a la gestión de los dispositivos
(Device Management: DM), gestionar un numero amplio de dispositivos es una tarea compleja y
deben cubrirse aspectos como la provisión del servicio (instalación y puesta en marcha), la
configuración y la gestión de actualizaciones de software o firmware, así como la asistencia técnica
en caso de fallo, necesitando en IoT un grado alto de automatización en estas tareas. Para la
gestión de los dispositivos está aconsejado el uso de estándares como TR-069 y OMA-DM.
6.1. CWMP
El Technical Report 069 o CWMP es un estándar técnico del DSL Forum (renombrado
posteriormente a Broadband Forum) conocido como CPE WAN Management Protocol (CWMP), que
define un protocolo como capa de abstracción para el mantenimiento remoto de los dispositivos
del usuario final. Como protocolo basado en SOAP/HTTP bidireccional proporciona una
comunicación entre el CPE y el servidor de configuración, Auto Configuration Server (ACS), e incluye
también un servicio de autoconfiguración y control del CPE en modo seguro en un entorno de
trabajo.
MBIGDA_M8T2_160727
42
Esquema de gestión de dispos itivos mediante Technic al Rep ort 069 o CWMP
Existen implementaciones de fuente abierta para CWMP como:
- freecwmp cliente CWMP (C/SHELL)

- EasyCwmp - cliente TR069 cwmp desarrollada con C/SHELL
6.2. OMA-DM
La especificación OMA DM está diseñada para la gestión de dispositivos pequeños como
teléfonos móviles, PDAs y Palm Tops. La gestión de dispositivos pretende dar soporte a los
siguientes usos típicos:
- Abastecimiento: Configuración del dispositivo (incluyendo el primer uso), habilitando y

deshabilitando funciones
- Configuración del Dispositivo: Permite cambios en los ajustes y parámetros del
dispositivo
- Mejoras de Software: Provee de nuevo software y/o parches para corrección de
errores, para ser cargados en el dispositivo, incluyendo aplicaciones y software de
sistema
- Gestión de Fallos: Informa sobre errores en el dispositivo, informa sobre el estado del
dispositivo.
MBIGDA_M8T2_160727
43
La especificación OMA DM soporta todas las funciones anteriores y un dispositivo puede

implementar opcionalmente todas o un subconjunto de estas características. Ya que la
especificación OMA DM está orientada hacia dispositivos móviles, se ha diseñado para ser sensible
ante:
- small footprint devices dispositivos en los que la memoria y el almacenamiento puede

ser limitado
- ancho de banda de comunicación limitado, como en el caso de conectividad
inalámbrica
- fuerte seguridad, ya que los dispositivos son vulnerables a ataques de virus y similares;
autenticación y desafíos (authentication and challenges) se incluyen como parte de las
especificaciones.
Técnicamente OMA DM usa XML para el intercambio de datos, más específicamente el

subconjunto definido por SyncML. El Device Management tiene lugar por comunicación entre el
servidor (que controla el dispositivo) y el cliente (el dispositivo controlado).
OMA DM está diseñado para soportar y utilizar un gran número de soportes para transporte de
datos como:
- físicamente sobre cableado (USB, RS-232) y medios inalámbricos (GSM, CDMA, IrDA o
Bluetooth)
- capas de transporte implementadas sobre cualquier WSP (WAP), HTTP u OBEX, o
transportes similares
Hay implementaciones abiertas de ejemplo y referencia de OMA DM:
- Un servidor de fuente abierta OMA DM está disponible en funambol.

- Una implementación de referencia del protocolo OMA DM ha sido creada por los
patrocinadores originales de la iniciativa SyncML, conocida como Reference Toolkit
(RTK). Se mantiene en sourceforge.
MBIGDA_M8T2_160727
44
Ejemplo de soluc ión de gestió n de dispos itivos utilizando OMA -DM
7. Redes, capa física y enlace

7.1. Redes en el contexto de la IoT
IoT requiere la transmisión de datos a través de redes en un nuevo contexto. Desde el punto de
vista de las redes, los dispositivos son llamados “nodos” de la red y se comunican entre sí a través
de “enlaces” de red. Los nodos de red consisten en cualquier elemento conectado a la red. Los
enlaces de una red en cambio consisten en las soluciones que se usan para conectar unos nodos
con otros.
Tanto dispositivos como redes en IoT son completamente heterogéneas, los dispositivos
pueden ser sensores específicos a Smartphones u ordenadores personales, los enlaces de red a su
vez pueden estar formados por señales inalámbricas o unidas con cable físico, por diversos
protocolos y tecnologías. Ambos, dispositivos y enlaces, suponen un ecosistema que puede tener
implicaciones debido a la variedad de capacidades, un mismo dispositivo puede pasar por un enlace
de red Wi-Fi, en otros puede estar conectado mediante fibra óptica, en esta red Wi-Fi puede haber
dispositivos que consuman poco ancho de banda y otros que consuman mucho ancho de banda por
MBIGDA_M8T2_160727
45
su capacidad de almacenamiento o modo de funcionamiento. En definitiva IoT presenta un reto en

cuanto a la variedad de características y capacidades tanto en los nodos como en los enlaces.
Adicionalmente el que las redes tengan la capacidad de reconfigurarse automáticamente aporta

una gran versatilidad y tolerancia a fallos pero a su vez aporta más complejidad a tratar el problema
de la versatilidad. Algunos protocolos incluyen estas posibilidades en las que en cualquier momento
una red puede reconfigurarse y un enlace puede dejar de usarse para usarse otro de otra
tecnología y diferentes características.
Para proveer de esta capacidad a la red es necesario que los nodos sean identificables
independientemente de qué tipo de dispositivo se trata, en esto juega un papel esencial la
convergencia IP, todo nodo de la red dispondrá de una IP que lo identifica, y se comunicarán
mediante el mismo protocolo IP, de manera que, con un mismo protocolo todos los nodos podrán
hablar con todos los nodos, independientemente del medio físico por el cual están conectados
(medio físico del enlace de red) y de los protocolos subyacentes en cada dispositivo. La
convergencia IP permite que los nodos de la red puedan enlazarse unos con otros.
En esta situación tan variada será relevante al realizar proyectos de IoT, en los que se deberá
asegurar que los datos son transmitidos con la velocidad y la precisión adecuadas al propósito.
Es importante comprender que el que los dispositivos sean accesibles e identificables mediante
IP, esto no significa que los dispositivos estén organizados en redes horizontales. Es preciso que las
redes se configuren debidamente acorde al uso que va a realizarse, en el siguiente ejemplo se
puede observar esta situación.
MBIGDA_M8T2_160727
46
200 metros Radio 2.4Ghz Gateway
A0 B
Cable 100 Mbps Ethernet

100 Mbps Ethernet
Servicio
A
1 C
A
2
ADSL
A
A 4
1000
Area Network A D
WSN (Wired Sensor Network)
3
Ejemplo de nodos y en laces e n un despliegue IoT
Disponemos de unos dispositivos sensores (nodos A) que se encuentran desplegados de la

siguiente manera:
- Uno (A0) por necesidades específicas conectado mediante red Wi-Fi, con sus
características de enlace.
- Otros por ejemplo mil sensores (A1 – A 1000) mediante una red cableada WSN.
Para que la red de sensores tenga conectividad se despliega un nodo Gateway B, Este Gateway
conecta la subred de medidores A1-A1000 y el medidor A0.
La red de medidores (WSN) es capaz de dirigir las peticiones a los diferentes medidores de
forma inteligente, de manera que no todos están conectados al Gateway B, sino que existe una ruta
desde B para alcanzarlos a todos dando un número determinado de saltos en nodos de A (son
nodos con capacidad de enrutamiento y solo algunos tienen conexión directa con B).
La información de los sensores quiere ser obtenida desde un servidor C, que se conecta a través
de Ethernet a Internet, alcanzando al Gateway B.
MBIGDA_M8T2_160727
47
Finalmente un usuario se conecta desde D al servidor C para usar el servicio publicado a través
de una ADSL.
Es muy importante observar que el ejemplo está mostrando la solución a nivel de red, no se
está definiendo cómo funciona la comunicación a nivel de aplicación entre los distintos nodos, si los
nodos “A“ tienen un servidor HTTP que devuelve XML o si envían datos a través de protocolos
como MQTT.
Una vez se dispone de la conectividad IP la capa de aplicación puede ser a su vez nuevamente
homogénea o heterogénea en cuanto a tecnologías empleadas y requerimientos en las sucesivas
capas de protocolo. Las aplicaciones por las tecnologías empleadas y su uso establecerán a su vez
requisitos de ancho de banda necesario y precisión de los protocolos y servicios.
Aunque pueda ser deseable disponer de una red completamente IP-a-IP sin traducciones de
protocolos, las redes LLN no son exactamente comparables a las clásicas redes IP por las
restricciones propias de sus dispositivos y medios en los que se despliegan. Esto hace que escalar
redes a cientos de millones de objetos conectados con una diversidad tan grande de
comportamientos que necesitará de ayuda centralizada y especifica. Esta ayuda se puede
proporcionar desde los Gateways aplicando conversores de protocolos y optimizadores adecuados
al medio.
Habitualmente los Gateways proporcionan de puente entre las tecnologías de red WAN y LAN,
esto es, disponen de conectividad de tipo LAN (como Ethernet o Wi-Fi) y de tipo WAN conexión
4GLTE o Wi-Max por ejemplo. En IoT se pretende que dispositivos sean de bajo coste y sean
accesibles desde Internet, para este propósito conectarlos directamente a Internet mediante la red
WAN directamente puede ser muy costoso (por ejemplo cada dispositivo puede contar con tarjeta
SIM y línea de datos). Esta solución es válida solo en escenarios muy justificados. En lugar de
desplegar costosos dispositivos con conectividad WAN se despliegan dispositivos formando una red
WPAN (Wireless Personal Area Network) soportada normalmente en el IEEE 802.15.4 sobre la que
funcionan los protocolos como Zigbee, WirelessHart, Isa100.11.a, 6LoWPAN, RPL y CoAP.
MBIGDA_M8T2_160727
48
IEE802.15.4 cubre el acceso al medio y la capa física para este tipo de redes mediante medio
físico inalámbrico “Wireless Medium Access Control (MAC) and Physical Layer (PHY) specifications
for low-rate wireless personal area networks (LR-WPANs)”, otras tecnologías aparte de IEE802.15.4
permiten también dotar de conectividad a estos dispositivos usando otros medios y características
como Bluetooth LE/Smart, M-BUS, Wireless M-BUS, KNX, y Power Line Communication (PLC).
7.2. Tecnologías para red en IoT

A diferencia de las tecnologías que durante un largo tiempo se vienen desarrollando para web, y
que son usadas hasta el momento habitualmente en las capas superiores para soluciones M2M, IoT
presenta soluciones en la pila de protocolos para resolver las situaciones derivadas del contexto de
IoT.
Hay multitud de aspectos que han propiciado una diversidad de protocolos, estándares o
soluciones para la conexión de los dispositivos, aspectos como: la gran variedad de dispositivos, la
evolución desde dispositivos existentes M2M, la incursión de nuevas tecnologías como RFID o NFC,
y no menos importante, las características diversas de entorno físico en el que deben funcionar los
dispositivos, el volumen de datos, la frecuencia con la que deben transmitirse los datos y la
precisión de los datos a transmitir. Como consecuencia encontramos muchas soluciones que con
enfoques diversos, resuelven problemas o mejor dicho, proponen un valor diferencial en base a
unas características.
Así, la típica pila de protocolos OSI que en tecnologías como la web dirige las implementaciones,
y está muy definida en cuanto a las tecnologías a usar, en el caso de IoT las normas se han ido
formando unas de facto y otras respetando estándares.
MBIGDA_M8T2_160727
49
OSI PROTOCOLOS IoT
Aplicación Aplicación Aplicación
Aplicación ONEM2M / ETSI M2M Service Layer
Presentación
Sesión
HTTP/REST
SEP 2.0
AQMP
MQTT
XMPP
CoAP
ZigBee
Transporte TCP TCP / UDP
RPL
Red IPv6
6LoWPAN
IEEE 802.15.4
Enlace
Bluetooth LE
WI-FI 802.11
Ethernet
802.3
RFID
Física
Pila de protoco los de uso exte ndido en Io T y sus correspond ientes nive les OSI
Las soluciones de IoT actuales pueden ser clasificadas respecto a la conectividad de red, como
soluciones no-IP y soluciones IP. Muchas soluciones pertenecen al grupo No-IP como Zibgbee, Z-
Wave, INSTEON o WAVEM2. La mayoría de estas soluciones son aisladas y tienen sus propias
soluciones verticales, lo que dificulta la compatibilidad entre diferentes sistemas de
comunicaciones, o sistemas heterogéneos.
En el contexto de la convergencia IP, otras soluciones pretenden resolver las dificultades que
presentan las capacidades reducidas de los dispositivos en memoria y limitaciones
MBIGDA_M8T2_160727
50
computacionales, el Grupo de Trabajo en Ingeniería de Internet (IETF) desarrolla y estandariza los

protocolos de comunicación para dispositivos con recursos limitados, incluyendo RPL y COAP.
Además, la Alianza de objetos inteligentes IP (IPSO) también promueve activamente el uso de IP
versión 6 (IPv6) para dispositivos embebidos de máquina a máquina.
Para usar soluciones embebidas en dispositivos No-IP, se necesitan Gateways que realicen una
traducción de protocolos, incluyendo una traducción a nivel semántica entre distintos mecanismos
de enrutamiento, seguridad, calidad de servicio, etc. Por el contrario, el uso de soluciones basadas
en IP permite que estas traducciones solo se deban a los motivos físicos, permitiendo que la
semántica sea común.
Actualmente existen varias iniciativas enfocadas a la implementación de la pila de protocolos

IPv6 en varias plataformas hardware como CoAP sobre TinyOS o sobre Contiki (sistemas operativos
de bajo peso para dispositivos con capacidades limitadas). En el propósito de integrar cosas del
mundo real en internet de la forma más interoperable y fácil de gestionar posibles, toman ventaja
los dispositivos interoperables mediante servicios REST sobre HTTP.
Las tecnologías más extendidas o con más potencial en desarrollo, para dotar de conectividad a
los dispositivos en el contexto de IoT, son las siguientes:
7.2.1. 3GPP 3G/LTE/4G
Los dispositivos pueden utilizar redes de telefonía para la transmisión inalámbrica, estándar
para comunicaciones inalámbricas de transmisión de datos de alta velocidad para teléfonos móviles
y terminales de datos. Está muy extendido 3G y en entornos urbanos de momento el despliegue de
4GLTE.
MBIGDA_M8T2_160727
51
Evolución de 3GPP
La red la proporcionan las operadoras móviles como servicio en pago por uso o tarifa plana, el
coste del dispositivo y el coste de las tarifas sobre datos son elevados. Las características más
importantes a tener en cuenta son:
- Ancho de banda alto, velocidades de pico:
o Bajada: 326,5 Mbps para 4x4 antenas, 172,8 Mbps para 2x2 antenas.
o Subida: 86,5 Mbps
- Muy baja latencia valores de 100 ms para el Control-Plane y 10 ms para el User-Plane.

- Muy alta calidad de servicio.
- Los dispositivos tienen que tener buena calidad de señal en el emplazamiento.
Para las redes 3G tienen las mismas características pero con menores anchos de banda y mayor
latencia. Es habitual encontrar dispositivos con el slot para la tarjeta SIM y el interfaz de red.
7.2.2. LAN, WLAN
Estos protocolos están evolucionando debido a la alta demanda de uso en todos los sectores.
Son los protocolos de red LAN y WLAN extendidos como Ethernet y Wi-Fi. Con la llegada de Internet
de las Cosas se están mejorando Por ejemplo IEEE 802.11n proporciona trafico mejorado para
aplicaciones de Streaming multimedia, otras versiones del protocolo están avanzando en soportar
MBIGDA_M8T2_160727
52
más dispositivos conectados simultáneamente, o mayores velocidades de transferencia de datos.

En muchos casos por su uso extendido el Gateway ya está disponible en la ubicación de los
dispositivos a desplegar, simplificando la instalación, además el uso de tecnologías estándares y
extendidas facilita la comprensión de los productos de IoT y el despliegue.
- Su uso es el más extendido en redes LAN tanto empresariales como domésticas.

- El ritmo de evolución debido a la demanda proporciona grandes avances que pueden
ser utilizados también en IoT.
- Proporcionan una alta fiabilidad.
- Disponen de un buen ancho de banda.
- Su alto consumo de alimentación lo hace aplicable donde la alimentación de los
dispositivos no sea un problema,
- Los protocolos de conexión de los dispositivos LAN son Ethernet (IEEE 802.3) y WLAN
Wi-Fi (IEEE 802.11).
- En algunos entornos son una gran ventaja al ya disponer de estas tecnologías
desplegadas para la conectividad a internet.
7.2.3. IEEE 802.15.4 Low-Rate, Low-Power Networks
Esta familia de soluciones IEEE 802.15.4 es originaria desde su concepción para IoT, son
dispositivos de muy bajo coste, bajo consumo de energía y baja potencia. Con las tecnologías
actuales para el almacenamiento de energía este consumo aun no alcanza los niveles necesarios
para considerarlo de larga duración (más de diez años). Sobre la capa física proporcionada por IEEE
802.15.4 otros protocolos destinados a trabajar con 802.15.4, aportan funcionalidades que
sabiendo de las limitaciones, tratan de preservar o prolongar el uso de la batería.
- Transmiten en velocidades entre 20 kbps y 256 kbps dependiendo de la banda utilizada

- Alcanzan distancias entre metros y kilómetros dependiendo de la potencia empleada.
Si bien el desarrollo del estándar está orientado a redes WPAN, de alcance geográfico
bastante limitado, algunas variantes intentan abarcar alcances mayores IEEE 802.15.4.g
hasta el orden de decenas de kilómetros.
MBIGDA_M8T2_160727
53
- El consumo se mueve en torno a decenas de mili vatios para los nodos en

funcionamiento en modo activo.
7.2.4. SigFox
En el campo de operadoras de comunicaciones se empiezan a proporcionar soluciones

específicas para resolver las necesidades de conexión de IoT a precios competitivos, entre este tipo
de soluciones aparecen innovaciones como SigFox.
Sigfox es un operador de telecomunicaciones que proporciona una red Wireless dedicada a

Internet de las Cosas, capaz de transmitir mensajes entre dispositivos a través de un sistema propio
que ofrece cobertura completa en varios países. Es una red LPWA (Low-Power Wide-Area)
desplegada en Europa Occidental San Francisco y actualmente desplegándose en América del sur y
Asia.
Cobertura S igFox en Europa
Como operador de telecomunicaciones implica que no tienes que lidiar con operaciones de
instalación ni de mantenimiento de la red y la conectividad de los dispositivos.
El sistema SigFox es un sistema desacoplado del desarrollo, de manera que no tiene

connotaciones que se inmiscuyan con el core del proyecto a desarrollar, mas alla de las
prestaciones y capacidades.
MBIGDA_M8T2_160727
54
Establece una comunicación bidireccional desde y hacia el dispositivo, la comunicación siempre

es iniciada por el dispositivo.
La red está diseñada para enviar pequeños (muy pequeños) mensajes, no es apropiada para
altos anchos de banda. Se enfoca a dispositivos con baja capacidad de almacenamiento de energía,
que requieran consumir poca energía para transmitir el mensaje.
Opera en frecuencias por debajo de GHz, 868 MHz en Europa y 902 MHz en Estados Unidos.
Emplea una modulación de banda ultra estrecha, lo que le permite proporcionar una red escalable
y de alta capacidad pese a usar una frecuencia de baja capacidad de transporte.
El alcance de la red es superior a GSM, basándose en enlaces de 162dB.
No existe una negociación entre el dispositivo y la estación receptora, simplemente se emite en

la frecuencia y la señal es detectada por las estaciones, decodificada y enviada a la red de backend.
Los mensajes son enviados a la aplicación y accesibles a través de un API.
Funcionamie nto general de la red SigFox y el acceso a los d a tos a tr avés del Cloud
MBIGDA_M8T2_160727
55
Cada mensaje es autenticado mediante un mecanismo de hash y una clave privada específica de
cada dispositivo, robusto incluso a ataques de tipo “replay” o re-emisión de mensajes antiguos. El
protocolo de radio tiene además una alta resistencia a interferencias.
Cada mensaje transmite 12 octetos (12 bytes, 96 bits) de carga útil, y los metadatos necesarios
por el protocolo, incluyendo en los metadatos un Timestamp del mensaje (fecha y hora) y el
identificador único del dispositivo.
A día de hoy la regulación Europea implica una limitación en la red de 140 mensajes al día por
dispositivo. Un dispositivo en la banda de 868 MHz no puede emitir más de un 1% del tiempo y
cada mensaje no puede exceder los 6 segundos de transmisión. Esto limita la red a enviar 6
mensajes por dispositivo y hora.
Para utilizar esta tecnología se requiere que el dispositivo utilice un módulo SIGFOX-ready o
incorporar al dispositivo un “transceiver” SIGFOX, que fabrican y distribuyen partner, una
suscripción al servicio, para poder hacer uso de la red, Y estar en un área con cobertura de la red.
Existen dispositivos adaptados y chips “transceiver” para construir dispositivos, y modulos para
adaptar sigfox a diferentes dispositivos de prototipado como Raspberry, Arduino, Intel Edison…
Ejemplo de módulo de conexión SigFox para B lackBerry
MBIGDA_M8T2_160727
56
SigFox proporciona herramientas de internet sin coste a fabricantes de semiconductores y

módulos, en una estrategia que facilita la integración con la red SigFox.
Hay que tener en cuenta que vincular un proyecto de despliegue de dispositivos a la red SigFox
implica una vinculación con la empresa y que a día de hoy si bien se puede cambiar de operador
móvil en caso de problemas con la compañía móvil, no es posible cambiar de operador en la red
SigFox, y habría que cambiar técnicamente los dispositivos, es decir, tener en cuenta la continuidad
de la empresa.
7.2.5. Power Line Communication
Conocida como PLC, es un sistema que permite enviar la información sobre la línea eléctrica.
Permite enviar datos a larga distancia (Kilómetros) utilizando una frecuencia baja.
En condiciones de calidad sobre instalaciones existentes dispone de muy bajo ancho de banda
(en torno a cientos de bits por segundo), aunque se pretende alcanzar soluciones de banda ancha
(BPL: Bandwith Power Lines).
Mediante la incorporación de la capa de adaptación 6LoWPAN los dispositivos PLC pueden

transmitir paquetes IPv6 sobre los canales de PLC en las líneas eléctricas.
- Los módems PLC transmiten en las gamas de media y alta frecuencia (señal portadora
de 1,6 a 30 MHz).
- La velocidad asimétrica en el módem va generalmente desde 256 kbit/s a 2,7 Mbit/s.
- En el caso de suministro de un edificio, en el repetidor situado en el cuarto de
medidores, la velocidad es de hasta 45 Mbit/s y se pueden conectar hasta 256 módems
PLC, que se deben repartir este ancho de banda.
- En las estaciones de voltaje medio, la velocidad desde los centros de control de red
hacia Internet es de hasta 134 Mbit/s.
- Para conectarse con Internet, las empresas de electricidad pueden utilizar
un backbone de fibra óptica o enlaces alquilados.
MBIGDA_M8T2_160727
57
Además de la pretensión de ser proveedores de banda ancha a través de la red eléctrica, cuya
competitividad está muy limitada para los usos actuales y las capacidades de otras tecnologías, sí
son muy apropiados para transmitir datos de mediciones en redes inteligentes de suministro
eléctrico.
PLC no está estandarizado, existen múltiples formas de usar la tecnología aunque

recientemente se avanza en la adopción del estándar 6LoWPAN para hacer los sistemas más
homogéneos.
7.2.6. RPL
Es un adaptador de protocolos para IPv6, diseñado para aplicar sobre capas de enlace con alta
tasa de pérdida de datos. Su principal característica es la tolerancia a fallos, tanto en el trasiego de
información, como en la estabilidad de la red.
Esta solución se alcanza a base de perder ancho de banda efectivo, por lo que la fiabilidad se
logra a través de perder velocidad.
No tiene un protocolo específico para la capa física ni de acceso al medio, son compatibles con
capas de enlace PLC, IEEE 802.15.4 y Wi-Fi de baja potencia.
Comunicac ión segura de ex tremo a extremo mediante RPL a través de un border router
Es muy eficaz en la reconfiguración rápida de la red, en caso de caídas o pérdidas de nodos,

readaptando la configuración de la topología de forma muy eficiente.
MBIGDA_M8T2_160727
58
Es apropiado en escenarios que presenten estas debilidades como amenazas.
7.2.7. Bluetooth Low Energy
Es una evolución de Bluetooth orientada a dispositivos de bajo consumo de energía.
- Proporciona velocidades de transferencia de millones de bits por segundo para

conexiones inalámbricas
- Alcances menores a 50 metros.
- Es una tecnología muy extendida, hay muchos dispositivos que ya funcionan con
Bluetooth, por ejemplo en el campo de los Smartphones, Gadgets y Wereables.
Las dos implementaciones más frecuentes de la especificación son Bluetooth Basic

Rate/Enhanced Data Rate (BR / EDR), que fue adoptada como la versión 2.0 / 2.1 y Bluetooth con
bajo consumo de energía (LE), que fue adoptada como la versión 4.0 / 4.1 / 4.2. Las versiones de LE
son comercialmente conocidas como Bluetooth Smart.
Cada aplicación tiene diferentes casos de uso y cada aplicación utiliza un chipset diferente para
satisfacer los requisitos esenciales de hardware. También están disponibles chips de modo dual
para aplicaciones que incluyen ambos casos de uso.
Bluetooth BR / EDR-establece un alcance relativamente corto, con conexión inalámbrica

continua, lo que lo hace ideal para los casos de uso como Streaming de audio.
Bluetooth LE-permite ráfagas cortas de conexión de radio de largo alcance, por lo que es ideal
para Internet de las cosas y aplicaciones que no requieren conexión continua, y que especialmente
dependen de la conservación de la batería.
Bluetooth BR / EDR establece 79 canales, entre 2400 y 2483.5 MHz. Mientras que Bluetooth
Smart establece 40 canales, entre 0 y 39 entre 2400 y 2483.5 MHz, donde los canales 37, 38 y 39
son canales destinados a anunciar servicios.
MBIGDA_M8T2_160727
59
Espectro de radio en BR/EDR y LE y Canales asignados
Los chips de modo dual están disponibles para soportar los dispositivos individuales tales como
teléfonos inteligentes o tabletas que necesitan conectarse a ambos dispositivos BR / EDR (como
auriculares de audio) y dispositivos LE como Wereables o balizas de comercio (retail beacons).
Mientras que cada aplicación tiene requisitos específicos que se detallan en la especificación
Bluetooth, la arquitectura de núcleo del sistema Bluetooth tiene muchos elementos comunes. El
sistema incluye un transceptor RF, banda base y las pilas de protocolos que permiten a los
dispositivos conectarse e intercambiar una variedad de clases de datos.
7.2.7.1. Ejemplo de una comunicación Bluetooth y uso de servicios
De una forma simplificada veremos cómo funciona Bluetooth, para poder comprender los
detalles que se van a tratar sobre este protocolo e internet de las cosas, las claves a tener en cuenta
son las siguientes:
Bluetooth es un sistema por el que se establece una conexión permanente entre dos
dispositivos, vía inalámbrica, a corta distancia.
Sigamos un ejemplo bastante extendido, un móvil y el sistema de radio manos libres de un

vehículo, que puede probar fácilmente, pero entendiendo que ocurre cuando realiza las tareas de
configuración.
MBIGDA_M8T2_160727
60
a) Uno de los dos dispositivos busca dispositivos mediante un protocolo de descubrimiento,

típicamente desde el móvil se busca el dispositivo manos libres del vehículo y aparece en la
lista de dispositivos Bluetooth cercanos.
b) El usuario selecciona en el móvil el nombre Bluetooth del vehículo.
c) Si es la primera vez, el dispositivo no tiene la clave del vehículo:
- Va iniciarse un proceso de autenticación en el que el vehículo muestra en su pantalla un

número,
- Ese número es la clave que hay que indicar en el móvil para vincularlo al vehículo,
- A partir de ese instante el vehículo acepta la petición de conexión del móvil.
d) Vehículo y móvil ahora están interconectados por Bluetooth.
e) Los dispositivos usan el protocolo Bluetooth para interrogarse acerca de los servicios que
ofrecen:
- Los servicios se aglutinan en un “perfil”.

- Cada dispositivo ofrece su perfil de servicios para que sean usados por el otro.
- Por ejemplo en este caso el perfil es el Hands-Free Profile (HFP):
o El teléfono móvil en un enlace HFP es “Audio Gateway” o HFP Server.
o El lado del vehículo del enlace HFP es “Car Kit” o HFP Client.
f) A partir de ese momento el vehículo puede hacer uso de las funcionalidades publicadas por
el servidor (móvil) del servicio de telefonía, enviándole la voz (micro) y emitiendo el
auricular (audio) mediante Streaming.
g) Otros servicios serán acceder a la agenda, iniciar y recibir una llamada, o finalizarla.
h) Son servicios que el teléfono publica y el vehículo utiliza.
Este ejemplo debe tenerse en mente en adelante para identificar de forma concreta conceptos
como el Security Manager, el GATT, el GAP, los perfiles, y la gran diferencia: en internet de las cosas
MBIGDA_M8T2_160727
61
la conexión a través de los Gateways permite el uso de los dispositivos a través de internet
identificados por una IPv6.
7.2.7.2. ARQUITECTURA Y CAPAS DE BLUETOOTH
Los dispositivos Bluetooth intercambian información de protocolo de acuerdo con la

especificación Bluetooth. Los protocolos principales del sistema son el protocolo de radio (RF),
protocolo de control de enlace (LC), protocolo gestor de enlaces (LM) y el protocolo de control de
enlace lógico y adaptación (L2CAP), todos están completamente definidos en la especificación
Bluetooth.
Los protocolos de las tres capas más bajas – protocolos de radio, de control de enlace y gestor
de enlaces- se agrupan en un subsistema conocido como el controlador de Bluetooth. Esta es una
aplicación común que utiliza un estándar de interfaz opcional -Host to controller Interface (HCI)-
que permite la comunicación bidireccional con el resto del sistema Bluetooth, llamado el Bluetooth
Host.
El controlador principal puede ser una de las siguientes configuraciones, dependiendo de caso
de uso:
- Controlador BR / EDR incluyendo la radio, de banda base, Gestor de Enlace y

opcionalmente HCl.
- Controlador LE (Low Energy) incluyendo la capa física PHY, la capa de enlace y
opcionalmente HCl.
- Controlador BR / EDR combinado con controlador LE (Low Energy), con una dirección
de dispositivo Bluetooth compartida.
La especificación Bluetooth permite la interoperabilidad entre los sistemas mediante la

definición de los mensajes de protocolo que se intercambian entre capas equivalentes. También
permite la interoperabilidad entre los subsistemas independientes Bluetooth mediante la definición
de la interfaz común entre los controladores Bluetooth y anfitriones (hosts) Bluetooth.
MBIGDA_M8T2_160727
62
Pila de subsistemas y cap as d e Bluetooth
- Capa Física (PHY): Controla la transmisión / recepción de la radio de 2,4 GHz con
canales de comunicación Bluetooth. BR / EDR ofrece más canales con ancho de banda
más estrecho, mientras LE utiliza un menor número de canales pero da un ancho de
banda más amplio.
- Capa de enlace: Define la estructura de paquetes / canales, el procedimiento de
descubrimiento y conexión, y envía / recibe datos.
- Modo de prueba directa: Permite a los probadores que encarguen a la capa física
transmitir o recibir una determinada secuencia de paquetes, enviando comandos a la
misma, ya sea a través de la HCI o por medio de una interfaz UART de 2 hilos.
- Host to Controller Interface (HCI): Interfaz estándar opcional entre el subsistema
controlador Bluetooth (tres capas inferiores) y el anfitrión Bluetooth.
MBIGDA_M8T2_160727
63
- Protocolo de Control de enlace lógico y capa de adaptación (L2CAP): Un protocolo

basado en paquetes que transmite paquetes a la HCI, o directamente al Gestor de
Enlace en un sistema sin host. Permite la multiplexación de protocolo de más alto nivel,
la segmentación y el re ensamblado de paquetes, y proporciona la información de la
calidad de servicio las capas superiores.
- Protocolo de Atributo (TCA): Define el protocolo cliente / servidor para el intercambio
de datos una vez que se establece una conexión. Los atributos se agrupan en servicios
significativos utilizando el Atributo de Perfil Genérico (GATT). ATT se utiliza en
implementaciones LE y, ocasionalmente, en las implementaciones BR / EDR.
- Gestor de seguridad: Define el protocolo y el comportamiento que gestiona la
integridad de emparejamiento, la autenticación y el cifrado entre dispositivos
Bluetooth, y proporciona funciones de seguridad que utilizan otros componentes para
soportar casi cualquier nivel de seguridad necesarias para diversas aplicaciones.
- Atributo Genérico de Perfil (GATT): Usando el Protocolo de Atributos, GATT agrupa
servicios que encapsulan el comportamiento de parte de un dispositivo y describe un
caso de uso, roles y comportamientos generales en base a la funcionalidad del GATT. Su
framework de servicio define los procedimientos y formatos de los servicios y sus
características, incluyendo descubrimiento, lectura, escritura, notificación y
características, así como la configuración de la transmisión (Broadcast) de las
características. GATT sólo se utiliza en las implementaciones de Bluetooth LE.
- Perfil de acceso genérico (GAP): Trabaja en conjunto con el GATT en las
implementaciones de Bluetooth LE para definir los procedimientos y las funciones
relacionadas con el descubrimiento de dispositivos Bluetooth e intercambiar
información, y los aspectos de gestión de enlaces de conexión de dispositivos
Bluetooth.
En la actualidad, los principales sistemas operativos móviles son compatibles con Bluetooth de
baja energía (LE). Esto ha hecho Bluetooth Low Energy un estándar multiplataforma de facto para la
comunicación inalámbrica de corto alcance. Como consecuencia, han aparecido nuevos mercados
para los accesorios conectados.
MBIGDA_M8T2_160727
64
Esquema general de red con d ispositivos Blue tooth acced id os desde Internet
Las aplicaciones que se ejecutan en dispositivos móviles pueden acceder a los sensores y
actuadores inteligentes Bluetooth y servicios Web en Internet. Esto significa que una aplicación
puede funcionar como una puerta de enlace entre dispositivos Bluetooth inteligentes e Internet.
Por ejemplo, las mediciones pueden ser subidas a un servicio en la nube de salud o puntos de
ajuste y actualizaciones de firmware se pueden descargar a dispositivos Bluetooth de baja energía.
Por lo general, este tipo de aplicaciones de Gateway solamente se conectan de forma

intermitente a Internet y son altamente específicas para una aplicación.
A menos que un dispositivo Bluetooth Low Energy sea un wearable, y por lo tanto se mantiene
unido a su usuario, su conectividad con el dispositivo móvil también es esporádica. Una vez
disponemos de la tecnología en el dispositivo y los protocolos y estándares, surge la dificultad de
conectar los dispositivos para prestar servicios a través de Internet, para esto hay que configurar
una serie de dispositivos de red con software atendiendo a los protocolos que permitan la
interacción desde y con Internet. Bluetooth cumple unas normas que permiten a diferentes
aplicaciones y sensores compartir la misma puerta de enlace a Internet son deseables.
MBIGDA_M8T2_160727
65
7.2.7.3. Ejemplo de publicación de servicios Bluetooth y acceso desde

internet
En área personal y del automóvil, el método de acceso a Internet dominante es el teléfono

móvil (por ejemplo, 3G, 4G). General Motors comenzó a dotar a sus vehículos de 4G LTE en
modelos de coches y camiones en 2015. Otros fabricantes harán lo mismo. Esto permite que un
automóvil pueda actuar como una puerta de enlace a Internet para todos los dispositivos dentro de
ese automóvil. En cambio en el hogar, la oficina y los centros comerciales, el método de acceso a
Internet dominante es un módem de banda ancha por cable, por ejemplo, DSL o cable, con un
puente integrado para Ethernet (802.3) y / o Wi-Fi (802.11) con un servidor de seguridad de red
integrada.
7.2.7.4. Servicios Bluetooth y dispositivos para Internet de las Cosas
Por tanto para dar cabida a diferentes entornos y usos de la tecnología se han definido tres
tipos de dispositivos o interacciones con dispositivos Bluetooth Low Energy que deben prestar los
Gateways para soportar estos usos:
- Bluetooth Low Energy Servers

- Bluetooth Internet-aware Low Energy clients
- Bluetooth IP-native 6LoBTLE Nodes
Tipos de p asarela a Internet c on intera cción con d ispositivo s Bluetooth LE.
MBIGDA_M8T2_160727
66
7.2.7.5. Internet Gateways para Bluetooth Smart Servers
Un Gateway de Internet que soporte Low Energy Servers permite la comunicación con el GATT
de forma remota a través de internet en lugar de forma local.
El protocolo GATT proporciona una serie de comandos al cliente para descubrir información
sobre el servidor, como:
- Descubrir UUID para todos los servicios primarios

- Encontrar un servicio con un UUID dado
- Encuentra servicios secundarios para un servicio primario determinado
- Descubre todas las características de un servicio determinado
- Encuentra las características que coinciden con un UUID dado
- Leer todos los descriptores para una característica particular
También se proporcionan comandos para leer (transferencia de datos desde el servidor al

cliente) y escribir (desde el cliente al servidor) los valores de las características.
GATT ofrece notificaciones e indicaciones: El cliente puede solicitar una notificación para una
característica particular del servidor. El servidor puede enviar el valor al cliente siempre que esté
disponible.
Estas técnicas son aplicadas hoy y se usan en servidores GATT existentes. Un cliente web
remoto puede interactuar mediante un Gateway e impersona a un cliente GATT local, obteniendo
los servicios que ofrece el GATT. Para este tipo de interacción a través de internet se necesita:
- Una conexión a internet.

- Un servidor HTTP para exponer y securizar la conexión a los dispositivos Smart Server.
- Un API RESTful GAP para permitir acceso remoto al perfil de acceso genérico (GAP) a
través de un Gateway (GAP Central Role) para encontrar y conectarse a los dispositivos
Low Energy Servers (GAP Peripheral role).
MBIGDA_M8T2_160727
67
- Un API RESTful GATT para permitir acceso remoto a los atributos del perfil gnérico
Generic Attribute Profile (GATT) a través de un Gateway (GATT Client role) para acceder
y controlar los dispositivos Low Energy Server (GATT Server role)
- Un motor de seguridad que haga de puente entre el Bluetooth Security Manager
Protocol (generación de clave y encriptación) con la seguridad de la capa de transporte
de Internet (Internet Protocol Transport Layer Security) y para autenticar a los
dispositivos Low Energy Servers.
El consorcio Bluetooth tiene publicadas las especificaciones para las APIS RESTful a utilizar.
7.2.7.6. Internet Gateways para Bluetooth Internet-Aware Low Energy

Clients
Permite que los dispositivos accedan a servicios web por HTTP. Se requieren tres tipos de
componentes:
- Una conexión a internet.

- Un proxy HPS.
- Un motor de seguridad que haga de puente entre el Bluetooth Security Manager
Protocol (generación de clave y encriptación) con la seguridad de la capa de transporte
de Internet (Internet Protocol Transport Layer).
7.2.7.7. Internet Gateways para Bluetooth IP-Native Low Energy Nodes.
Para dar soporte a 6LN Bluetooth, IPv6 sobre dispositivos Bluetooth, se dispone de la
especificación 6LoBTLE Low Energy Nodes (Gap Peripheral Role).
Esta especificación permite a dispositivos 6LN Low Energy Node, conectarse a través de un
Router 6LBR 6LoBTLE a un Gateway de Internet (GAP Central Role) desde clientes IPv6 a servidores
web y servicios IPv6.
Este tipo de conexión requiere los siguientes componentes:
- Una conexión a internet

- Un Border Router IPv6 BLR
MBIGDA_M8T2_160727
68
- Un Internet Profile Support Profile (IPSP).

- Un Core Bluetooth con conexión orientada a canal (Connection oriente channel
feature).
- Funcionalidad 6LoBTLE-6LoWPAN sobre Bluetooth Low Energy
Un ejemplo puede ser el Proyecto de código abierto CETIC 6LBR, un 6LoWPAN/RPL Border
Router. 6LBR puede funcionar como independiente, embebido en hardware, o sobre un host Linux.
Soporta varias topologías para configurar inteligentemente una red WSNs con el mundo IP.
Border Router sobre Cont ik i p ara red de sensores con proto colo 802. 15.4
7.2.8. RFID
La identificación por radiofrecuencia (RFID) es una forma de comunicación inalámbrica que

utiliza ondas de radio para almacenar información. El bajo coste de una etiqueta, el no necesitar
alimentación externa y su tamaño y peso, hacen posible un número enorme de aplicaciones
innovadoras en la sociedad actual.
Un sistema RFID tiene lectores y etiquetas que se comunican entre sí por radio. Consiste en dos
tipos de elementos, tag o circuito integrado para almacenar la información y dispositivo para leer y
escribir información en el tag. Una etiqueta está formada por un circuito integrado, de un tamaño
mínimo, y una antena. Un lector está formado por una antena y un software de control y
aplicación.
Un lector de RFID es un dispositivo conectado a la red (de emplazamiento fijo o móvil) con una
antena que envía a la etiqueta la potencia por inducción, datos y comandos. El lector RFID actúa
MBIGDA_M8T2_160727
69
como un punto de acceso para los artículos etiquetados o dispositivos RFID, para que los datos de
las etiquetas puedan ser puestos a disposición de las aplicaciones.
Las etiquetas RFID son tan pequeñas y requieren tan poca potencia que ni siquiera necesitan
una batería para almacenar datos e intercambiarlos de con los lectores de información. Esto hace
que sea fácil y barato aplicar etiquetas a todo tipo de cosas que a identificar o rastrear. Las antenas
recogen la energía y la canalizan al chip para encenderlo. En general, cuanto mayor es el área de la
antena de la etiqueta, más energía será capaz de recoger y canalizar hacia el chip, y podrá ser leído
a mayor distancia.
Una etiqueta RFID se compone de un circuito integrado conectado a una antena que se ha
impreso, grabado, estampado o adherido con vapor sobre una montura que es a menudo un
sustrato de papel o polietileno tereftalato (PET). El chip y la antena en conjunto, llamado una
incrustación, se aplican al objeto, por ejemplo entre una etiqueta impresa y su respaldo adhesivo o
insertado en una estructura más durable.
El chip de la etiqueta o circuito integrado (IC) es el responsable del rendimiento, la memoria y

las funciones ampliadas a la etiqueta. El chip está programado con un identificador de etiqueta
(TID), un número de serie único asignado por el fabricante de chips, e incluye un banco de memoria
para almacenar información.
La antena proporciona la capacidad de tomar la energía inducida en el medio y enviar la

información, las diferentes situaciones que pueden darse por la dependencia del medio físico (por
ejemplo sumergido en agua o un líquido denso) obligan a que existan diferentes antenas.
Dependiendo de la aplicación de la tecnología que se quiera hacer debe utilizarse una antena
adecuada, en algunos casos pueden necesitarse dos antenas por Chip para garantizar la lectura
desde diferentes ángulos y eliminar zonas muertas. De la misma forma hay una gran variedad de
antenas lectoras y la selección de antena óptima varía de acuerdo con la aplicación y el entorno
específico de la solución.
En cuanto a la distancia, se denomina rango de lectura, las antenas lectoras operan ya sea en un
"campo cercano" (de corto alcance) o "campo lejano" (de largo alcance).
MBIGDA_M8T2_160727
70
En aplicaciones de campo cercano, el rango de lectura es inferior a 30 cm y la antena utiliza

acoplamiento inductivo magnético para que el lector y la etiqueta pueden transferir energía. En los
sistemas de campo cercano, la legibilidad de las etiquetas no se ve afectada por la presencia de
dieléctricos, tales como agua y el metal en el campo.
Acoplamiento induc tivo de ca mpo cercano
En aplicaciones de campo lejano, el intervalo entre la etiqueta y el lector es mayor de 30 cm y

puede ser de hasta varias decenas de metros. Las antenas de campo lejano utilizan acoplamiento
electromagnético y dieléctricos pueden debilitar la comunicación entre el lector y las etiquetas.
Acoplamiento e lectromagnético de campo lejano
Los sistemas de RFID pueden ser degradados en su calidad por la banda de frecuencias en la que
actúan: baja frecuencia, alta frecuencia y ultra-alta frecuencia. También hay dos grandes categorías
de sistemas RFID pasivo y activo.
La frecuencia se refiere al tamaño de las ondas de radio utilizadas para la comunicación entre
los componentes del sistema RFID. Los sistemas de RFID operan en baja frecuencia (LF), alta
MBIGDA_M8T2_160727
71
frecuencia (HF) y bandas (UHF) ultra-alta frecuencia. Las ondas de radio se comportan de manera
diferente en cada una de estas frecuencias, con ventajas y desventajas.
Si un sistema de RFID funciona a una frecuencia más baja, que tiene un alcance de lectura más
corto y una tasa de lectura más lenta, pero aumenta las capacidades para la lectura de cerca o
sobre superficies de metal o de líquidos.
Si un sistema funciona a una frecuencia más alta, por lo general tiene mayores velocidades de
transferencia de datos y mayores alcances de lectura que los sistemas de baja frecuencia, pero
también tienen más sensibilidad a la interferencia de las ondas de radio y mayor sensibilidad al
medio como líquidos y metales.
7.2.8.1. LF RFID
La banda LF (Low Frequency) cubre frecuencias de 30 KHz a 300 KHz. Por lo general los sistemas
de LF RFID operan a 125 KHz, aunque hay algunos que funcionan a 134 KHz. Esta banda de
frecuencia proporciona un alcance de lectura de 10 cm, y una velocidad de lectura más lenta que el
resto de frecuencias, pero no es muy sensible a interferencias.
Las aplicaciones LF RFID incluyen control de acceso y seguimiento de animales. Las normas para
los sistemas de rastreo de los animales se definen en la norma ISO 14223 e ISO / IEC 18000-2. El
espectro de frecuencias de LF no se considera una aplicación verdaderamente global debido a
ligeras diferencias en los niveles de frecuencia y potencia en todo el mundo.
La banda de HF oscila de 3 a 30 MHz. La mayoría de los sistemas HF RFID operan a 13,56 MHz
con rangos de lectura de entre 10 cm y 1 m. estos sistemas de alta frecuencia experimentan una
sensibilidad moderada a las interferencias.
7.2.8.2. HF RFID
HF RFID se utiliza comúnmente para aplicaciones de emisión de billetes, de pago y de

transferencia de datos. Hay varias normas HF RFID en su lugar, como el estándar ISO 15693 para el
seguimiento de objetos, y la ECMA-340 e ISO / IEC 18092 para la comunicación de campo cercano
(NFC), una tecnología de corto alcance que se utiliza comúnmente para el intercambio de datos
MBIGDA_M8T2_160727
72
entre dispositivos. Otras normas de alta frecuencia incluyen la ISO / IEC 14443 A y ISO / IEC 14443
para la tecnología MIFARE, que se usa para tarjetas inteligentes y tarjetas de proximidad, y la JIS X
6319-4 para FeliCa, que es un sistema de tarjeta inteligente de uso común en el dinero electrónico.
7.2.8.3. UHF RFID
La banda de frecuencia UHF cubre el rango de 300 MHz a 3 GHz. Los sistemas que cumplan con
el estándar UHF Gen 2 RFID utilizan la banda de 860 MHz a la 960. Si bien hay cierta variación en la
frecuencia de región a región, en la mayoría de los países los sistemas RFID UHF Gen2 operan entre
900 y 915 MHz.
El rango de lectura de los sistemas de UHF RFID pasivos puede ser tan largo como 12 metros, y
tiene una velocidad de transferencia de datos más rápida que LF o HF. UHF RFID es la más sensible
a interferencias, pero muchos fabricantes de productos UHF han encontrado formas de diseñar
etiquetas, antenas y lectores para mantener un buen funcionamiento incluso en entornos difíciles.
Las etiquetas UHF RFID pasivas son más fácil y más baratas de fabricar que las etiquetas de alta
y baja frecuencia. En la mayor parte de nuevos proyectos se está utilizando UHF RFID en oposición a
LF o HF.
La banda de frecuencia UHF está regulada por una única norma global llamado el estándar UHF
Gen2 ECPglobal (ISO 18000-6C).
UHF HF y LF
Estándar global Gen2 Múltiples estándares compiten
Coste de etiquetas muy barato, dos o tres veces Coste de etiquetas superior a UHF
más barato que HF y LF.
Velocidad y alcance 20X Uso adoptado NFC para pago seguro
Más adecuado para solo identificar objetos Más adecuado para usos más complejos como pago seguro, etc.
Principa les carac teríst icas y d iferencias entre UHF -RFID y HR o LF
MBIGDA_M8T2_160727
73
7.2.8.4. RFID Activo, Balizas y Transpondedores.
En los sistemas de RFID activo, las etiquetas usan su propia energía para emitir. Por lo general,
la fuente de energía es una batería. Las etiquetas activas transmiten su propia señal para enviar la
información almacenada en sus microchips.
Los sistemas de RFID activo normalmente operan en la banda de frecuencia ultra alta (UHF) y
ofrecen un alcance de hasta 100 m. En general, las etiquetas activas se utilizan en objetos grandes,
tales como vagones de ferrocarril, contenedores reutilizables grandes, y otros activos que necesitan
ser rastreados a través de largas distancias. Hay dos tipos principales de etiquetas activas:
transpondedores y balizas.
Los transpondedores son "despertados" cuando reciben una señal de radio de un lector, y
responden mediante la transmisión de una señal. Debido a que los transpondedores no irradian
ondas de radio activa hasta que reciban una señal del lector, conservan la vida de la batería.
Ejemplo de dispositivos RFID activos
Las Balizas se utilizan en la mayoría de los sistemas de localización en tiempo real (RTLS), con el
fin de realizar un seguimiento de la ubicación precisa de un activo de forma continua. A diferencia
de los transpondedores, las balizas no son encendidos ante la señal del lector. En lugar de ello,
emiten señales a intervalos preestablecidos. Dependiendo del nivel de precisión requerida en la
localización, las balizas se pueden configurar para emitir señales cada pocos segundos, o una vez al
día. En este caso de ejemplo la señal de cada baliza es recibida por antenas lectoras que se colocan
alrededor del perímetro de la zona vigilada, y comunica la información de identificación de la
etiqueta y la posición.
MBIGDA_M8T2_160727
74
Las etiquetas activas se utilizan normalmente en el seguimiento en tiempo real de los activos de
alto valor en sistemas de circuito cerrado (es decir, sistemas en los que las etiquetas no se pretende
que salir físicamente de las instalaciones de control del titular de la etiqueta o del expedidor). Los
activos de mayor valor por lo general pueden justificar el mayor costo de la etiqueta activa que
presenta una fuerte motivación para su reutilización. Equipo médico, equipo de prueba electrónico,
equipo de cómputo, contenedores de transporte reutilizables son todos excelentes ejemplos de
aplicaciones para la tecnología de RFID activo. Las etiquetas RFID activas pueden proporcionar
seguimiento en términos de presencia (indicación positiva o negativa de si un activo está presente
en un área en particular) o de localización en tiempo real. Las etiquetas RFID activas son por lo
general físicamente más grandes que las etiquetas RFID pasivas. La mayoría de los sistemas RTLS se
basan en el uso de la tecnología de etiqueta de RFID activa.
Las etiquetas activas pueden contener 512 KB de RAM o más, lo que permite a la etiqueta activa
almacenar la información de los objetos y su estado, así como para almacenar a modo de caché la
evolución y devolverla cuando son interrogados por un lector. Esta “gran” capacidad de memoria
hace también a RFID activo preferible ante RFID pasivo en situaciones en las que la etiqueta RFID no
puede simplemente ser utilizado como una "placa" o referencia, y se requiere una búsqueda
inmediata en una base de datos host. Mediante el almacenamiento de datos activo crítico
directamente en la propia etiqueta, esta información puede ser recuperada directamente de la
etiqueta y se utiliza independientemente de la disponibilidad del sistema host anfitrión.
Las etiquetas RFID activas operan a frecuencias 303, 315, 418, 433, 868, 915 y 2400 MHz, con
rangos de lectura de 60 a 300 pies. Suelen mostrar muy altas velocidades de lectura y tienen
fiabilidad de lectura debido a su mayor potencia de transmisión, la antena optimizada, y una fuente
confiable de energía embebida. El costo de la etiqueta RFID activa puede variar significativamente
dependiendo de la cantidad de memoria, la duración necesaria de la batería, y si la etiqueta incluye
características embebidas de valor añadido, tales como sensores de temperatura, detección de
movimiento, o interfaces de telemetría.
MBIGDA_M8T2_160727
75
La durabilidad y características de la carcasa de la etiqueta también afectan al precio, las

soluciones más duraderas o especializadas suponen un aumento del costo. Al igual que con la
mayoría de los componentes electrónicos de esta naturaleza,
Las etiquetas RFID activas para balizamiento se utilizan en muchos sistemas de RTLS y son
principalmente útiles cuando la ubicación de un activo tiene que ser rastreados en cualquier lugar y
en cualquier momento a través de la utilización de los receptores de localización. Con una etiqueta
de RFID activa de balizamiento, un mensaje corto que contiene el identificador único de la etiqueta
RFID se emite a intervalos preestablecidos. Este intervalo se programa en la etiqueta por el
propietario etiqueta o usuario.
7.2.8.5. RFID activas 802.11
Las etiquetas RFID activas 802.11 (Wi-Fi) están diseñadas para funcionar en las bandas ISM sin
licencia del 2,4 GHz a 5,8 GHz. Actualmente los dispositivos fabricados se limitan a 2,4 GHz.
Estas etiquetas tienen las características de las etiquetas RFID activas, pero también cumplen
con las normas aplicables y protocolos IEEE 802.11. Las etiquetas RFID Wi-Fi pueden fácilmente
comunicarse directamente con la infraestructura estándar Wi-Fi sin ninguna modificación especial
de hardware o firmware y puede coexistir con clientes Wi-Fi, como ordenadores portátiles, o
teléfonos VoWLAN. Cuando se encienden, los activos equipados con cliente Wi-Fi 802.11 pueden
ser rastreados de forma nativa sin la necesidad de tener una etiqueta de propiedad adjunta.
7.2.8.6. RFID activas multimodo
Las etiquetas RFID activas transpondedor ofrecen la combinación de un modo de

funcionamiento etiqueta primaria con un método secundario de comunicación que puede ser
utilizado para una gran cantidad de funciones de valor añadido, tales como activación,
desactivación, o modificación del comportamiento. Este tipo de etiqueta se ha utilizado durante
bastante tiempo en aplicaciones de peaje de carretera, por ejemplo, iniciando al pasar un débito en
la cuenta del usuario para la carga del peaje.
MBIGDA_M8T2_160727
76
Las etiquetas multimodo ofrecen el equivalente funcional de tener activos equipadas con varias
etiquetas individuales diferentes en un solo paquete físico. Esto puede ser muy útil cuando los
activos deben moverse por varios sistemas, por ejemplo, varias empresas o sedes con diferentes
tecnologías. Se han hecho mucho más factibles por la disponibilidad de la etiqueta altamente
integrada OEM de silicio que combina dos o más tecnologías de etiquetas RFID distintas en un solo
chip o conjunto de chips. Esto se ejemplifica por ejemplo en el dispositivo G2C501 de G2
Microsystems un sistema-en-chip (SoC) que incluye Wi-Fi 802.11b RFID activa, EPC Global 900 MHz
Gen 1 Clase 0 RFID pasiva, 2.4 GHz ISO24730-2 TDOA, una CPU de 32 bits, aceleradores de cifrado,
reloj en tiempo real e interfaces de sensores.
G2C501 RFID System -On-A-Chip (SoC) Multimodo
7.2.8.7. Chokepoint triggers
Son dispositivos de comunicación de proximidad que desencadenan acciones ante la presencia

de las etiquetas cuando la etiqueta pasa por la zona del gatillo, típicamente un cuello de botella
físico. Esta alteración podría ser tan simple como que la etiqueta de transmita su identificador
único, o más complejo, incluyendo que la etiqueta cambie su configuración, información, o estado
interno. Una de las funciones principales de un disparador cuello de botella es estimular la etiqueta
MBIGDA_M8T2_160727
77
de tal manera que proporciona una indicación de que ha entrado (o ha salido) de los límites de una
zona conocida como por un punto en un determinado momento.
No todas las etiquetas activas son compatibles con Chokepoint triggers, y en las que sí, el
Chokepoint trigger tiende a ser específico del fabricante. En el momento actual no son
interoperables entre las etiquetas de activos de diferentes fabricantes. Estos productos funcionan
con la señalización magnética de baja frecuencia. El alcance tiende a ser predecible, con una
excelente penetración de materiales de construcción típicos y sus contenidos.
Chokepoint trigger (Excitters) se ubican en cuellos de bo tella fís icos
7.2.8.8. RFID Pasivo
En los sistemas RFID pasivos, el lector y la antena del lector envía una señal de radio a la
etiqueta. La etiqueta RFID utiliza entonces la señal transmitida para encenderse, y reflejar la
energía recibida para enviar la información al lector.
Los sistemas RFID pasivos pueden operar en baja frecuencia (LF), alta frecuencia (HF) o ultra alta
frecuencia (UHF). Están limitados en su alcance a menos de 10 metros por la potencia de
retrodispersión (reflexión de ondas) de la etiqueta, es decir, la señal de radio reflejada desde la
etiqueta de vuelta al lector. Debido a que no requieren una fuente de alimentación, y sólo
MBIGDA_M8T2_160727
78
requieren un chip de la etiqueta y la antena, son más baratos, más pequeñas y más fácil de fabricar
que las etiquetas activas.
Las etiquetas pasivas se pueden empaquetar de muchas formas diferentes, dependiendo de los
requisitos específicos de la aplicación RFID. Por ejemplo, pueden ser montados sobre un sustrato, o
intercalados entre una capa adhesiva y una etiqueta de papel para crear etiquetas inteligentes
RFID. Las etiquetas pasivas también pueden ser incorporadas en una variedad de dispositivos o
empaquetados para hacer la etiqueta resistente a temperaturas extremas o productos químicos
agresivos.
Ejemplo de dispos it ivos et iqu etas RFID pasivo en dis tin tos empaquetados
Las soluciones RFID pasivo son útiles para muchas aplicaciones, y son comúnmente desplegados
para realizar un seguimiento de mercancías en la cadena de suministro, a los activos de inventario
en la industria minorista, para autenticar productos tales como productos farmacéuticos. RFID
pasivo se puede utilizar en almacenes y centros de distribución, a pesar de su menor alcance,
mediante la ubicación de los lectores en los puntos de estrangulamiento para controlar el
movimiento de activos.
MBIGDA_M8T2_160727
79
Ejemplo de dispos itivos de lectura RFID Pasivo
La tecnología RFID tiene un alto potencial para mejorar y proteger la vida de los consumidores,
y también a revolucionar la forma de hacer negocios. A medida que la tecnología de auto-
identificación es más flexible, RFID se puede utilizar para hacer trazabilidad y control de objetos del
mundo físico automáticamente y con precisión.
7.2.8.9. RFID semipasivo o asistido por batería (Battery Assisted Pasi ve

BAP)
Una etiqueta RFID BAP, pasiva asistida por batería, es un tipo de etiqueta pasiva que en lugar de
usar la energía captada de la señal del lector RFID a alimentar de energía chip, y a enviar la señal
mediante retrodispersión de la etiqueta al lector, utilizan una fuente de alimentación integrada
(por lo general una batería) para encender el chip, y toda la energía capturada del lector se puede
utilizar para la retrodispersión, lo que les proporciona una mejor señal y alcance. A diferencia de los
transpondedores, etiquetas BAP no tienen sus propios transmisores.
Ilustrac ión de l sis tema RFID S emipasivo o BAP
MBIGDA_M8T2_160727
80
Una actualización para el estándar UHF Gen 2, llamado UHF Gen 2 V2, o simplemente G2 se
basa en el estándar V1 original, pero asegura que las comunicaciones RFID tienen opciones de
seguridad más complejas para proteger los datos y evitar su falsificación. En el estándar G2, el
usuario es capaz de ocultar todo, parte o nada del contenido de la memoria de la etiqueta.
Dependiendo de qué privilegios de acceso tenga el lector, y su proximidad a la etiqueta, la
capacidad del lector para acceder y / o modificar los datos de la etiqueta varía. Esto evita el robo de
datos de la etiqueta o la manipulación. Las normas G2 también establecen una medida anti
falsificación que implica etiquetas con autentificación criptográficamente. Las etiquetas UHF Gen2
V1 envían respuestas estáticas de vuelta al lector, por lo que es fácil para clonación para crear
etiquetas falsificadas. Conforme a las normas G2, cada vez que un lector envía una señal a una
etiqueta se envía un número secreto diferente y la etiqueta calcula una respuesta específica a esa
interacción.
7.2.8.10. EPC en RFID para la identificación de objetos
La capacidad de almacenamiento de una etiqueta RFID es superior a un código de barras, RFID

puede decir lo que un objeto es, dónde está, e incluso su estado, por lo que es una tecnología clave
para el desarrollo de la Internet de las cosas.
RFID lleva el concepto de código de barras y lo digitaliza para el mundo moderno

proporcionando la capacidad de:
- Identificar de manera única un elemento individual más allá de su tipo de producto

- Identificar los elementos sin línea directa de visión
- Identificar muchos elementos (hasta 1.000 s) de forma simultánea
- Identificar artículos dentro de un entorno de entre unos pocos centímetros a varios
metros
La información que almacena la etiqueta consiste en un código de producto electrónico

(Electronic Product Code EPC) además de información variable en cada caso, y puede ser leído por
cualquier lector RFID.
MBIGDA_M8T2_160727
81
Una etiqueta RFID se compone de un circuito integrado conectado a una antena que se ha
impreso, grabado, estampado o adherido con vapor sobre una montura que es a menudo un
sustrato de papel o polietileno tereftalato (PET). El chip y la antena en conjunto, llamado una
incrustación, se aplican al objeto, por ejemplo entre una etiqueta impresa y su respaldo adhesivo o
insertado en una estructura más durable.
El chip de la etiqueta o circuito integrado (IC) es el responsable del rendimiento, la memoria y

las funciones ampliadas a la etiqueta. El chip está programado con un identificador de etiqueta
(TID), un número de serie único asignado por el fabricante de chips, e incluye un banco de memoria
para almacenar el identificador único de seguimiento de los objetos (código de producto
electrónico o EPC).
El código de producto electrónico (EPC) almacenado en la memoria del chip de etiqueta se

escribe en la etiqueta mediante una impresora de RFID y toma la forma de una cadena de 96 bits de
datos, donde:
- Los primeros 8 bits son una cabecera que identifica la versión del protocolo.
- Los siguientes 28 bits identifican el organismo que gestiona los datos de esta etiqueta;
el número de organismo es asignado por el consorcio EPCglobal.
- Los siguientes 24 bits son para una clasificación de objeto, que identifica el tipo de
producto.
- Los últimos 36 bits son un número de serie único de una determinada etiqueta.
Estos dos últimos campos son establecidos por la organización que emitió la etiqueta.
El número total código de producto electrónico se puede utilizar como una clave en una base de
datos global para identificar de forma única ese producto particular.
7.2.9. NFC
NFC (Near Field Communication) es un protocolo inalámbrico, de corto alcance y de alta

frecuencia. Para el medio físico no requiere licencia al funcionar sobre la banda 13,56 Mhz. Es un
MBIGDA_M8T2_160727
82
conjunto de estándares dirigidos por el NFC Forum, está muy extendido el NFCIP-1. Está basado en
la tecnología RFID y FeliCa.
NFCIP-1 puede funcionar a diversas velocidades en el orden de centenas de Kilobit por segundo,
106, 212, 424 o 848 Kbit/s. El protocolo es flexible en cuanto a cambiar la velocidad de
funcionamiento, esta velocidad se acuerda por las dos partes y se puede modificar durante la
comunicación. Su enfoque, en parte debido por la tasa de transferencia, es para comunicación
instantánea, más que para la transmisión de grandes cantidades de datos, es decir, para la
identificación y validación de equipos/personas. Los equipos con tecnología NFC son capaces de
enviar y recibir información al mismo tiempo.
El alcance de NFC es muy reducido (20 cm). Su uso es transparente a los usuarios, se utiliza por
proximidad, acercando los dispositivos, y en ciertas aplicaciones no requiere más interacción con el
usuario, es decir, el simple hecho de aproximar los dispositivos implica una acción.
Sistema de pago NF C en un au tobús
A nivel físico NFC puede funcionar como un dispositivo RFID activo o pasivo. En el caso activo,
requiere que ambos dispositivos estén alimentados y proporcionen un campo electromagnético
para el intercambio de datos. En el caso pasivo solo un elemento genera el campo magnético que el
otro dispositivo utiliza. La diferencia entre NFC y RFID estriba básicamente en que NFC es un
subconjunto de RFID en el que el alcance está limitado para requerir la proximidad.
MBIGDA_M8T2_160727
83
Smartphone con NFC act ivado para transferenc ia de d atos p or proximidad
En cuanto a la seguridad, la poca distancia es un elemento a tener en cuenta, pero aun así se
podría realizar la copia de los códigos del chip para un uso fraudulento, o alterar la comunicación.
La seguridad será proporcionada por las capas de comunicación seguras como SSL.
NFC ha sido adoptado por la industria del Smartphone por la multitud de aplicaciones que
pueden realizarse usando este protocolo, pero principalmente por sus posibilidades de uso en
sistemas de pago móvil, la proximidad necesaria para realizar la comunicación asemeja el uso físico
al de una tarjeta de crédito. Está presente en casi todos los teléfonos Smartphone.
Algunas aplicaciones de NFC para la identificación consisten en acercar el teléfono o la tarjeta

con chip NFC pasivo a un lector activo, por ejemplo las tarjetas de metro, autobús o
estacionamiento, que portan un identificador que será contrastado para verificar que el portador
de esta tarjeta ha abonado el pago y tiene permiso para realizar la acción. Para el pago consisten en
acercar el terminal y que se realice una transferencia entre monederos electrónicos de ambos, o se
ordene una transferencia bancaria.
MBIGDA_M8T2_160727
84
Las et iquetas NF C de Sony Xp eria permiten c onf igurar el perfil de uso de l Smartphone co nforme al lugar en e l que
estás.
8. Nivel de red
8.1. IPv6 Networking
Esta tecnología aporta la capacidad de conectar los dispositivos a la red mediante una IP, de
forma que la capa física y de enlace está solucionada en el uso del dispositivo. Pueden presentar
problemas si necesitan convivir en un entorno orientado a M2M heredado, donde los Gateways no
estén contemplando IP como protocolo para comunicarse con los dispositivos.
8.2. 6LoWPAN
Desde el principio IPv6 ha sido elegido por IETF como la única forma de dar soporte a las
comunicaciones Wireless sobre IoT, descartando cualquier solución no basada en el escenario de
convergencia IP. Para disponer de un estándar que proporcione conectividad con redes WSNs de
dispositivos con recursos reducidos, el protocolo 6LoWPAN realiza una optimización sobre redes
construidas con protocolo IEEE 802.15.4. En concreto 6LoWPAN resuelve cómo integrar IPv6 con la
capa de acceso al medio y la capa física de IEEE 802.15.4. El protocolo incluye soluciones para la
autoconfiguración de direcciones y la gestión de una red mallada.
MBIGDA_M8T2_160727
85
Posición de la capa 6LowPAN en la p ila de pro toco los de se nsores.
Esta capa de adaptación resuelve dos problemas principales entre el protocolo IEEE 802.15.4 y
el protocolo IPv6. Por una parte el protocolo IEEE 802.15.4 solo soporta paquetes de 127 bytes, y
considerando la cabecera está sobrecargada por información de las capas superiores de los
protocolos, por ejemplo las cabeceras de control del protocolo MAC, IPv6, seguridad y transmisión,
el tamaño que queda para la aplicación es muy pequeño. Por otra parte el tamaño mínimo de MTU
(transmisión) en IPv6 es de 1280 bytes (RFC 2460), pero IEEE 802.15.4 tiene un valor de MTU
inferior, es decir, hay que fraccionar los paquetes IPv6 para convertirlos en varios 802.15.4, y re-
ensamblar los 802.15.4 para convertirlos en IPv6.
6LoWPAN proporciona una solución para estas dos situaciones, por una parte compresión sin
estado sobre las cabeceras, y por otra parte fragmentación y ensamblado de paquetes entre IPv6 y
IEEE 802.15.4.
La compresión que se realiza de las cabeceras IP está completamente orientada al uso y la

problemática de la capa inferior, así por ejemplo el campo Hop Limit de la cabecera no es
comprimido para que pueda ser rápidamente utilizado en toma de decisión sobre el enrutamiento
de paquetes por la red:
Version (4 bits) El valor es 6, puede ser omitido en redes IPv6.
Traffic Class (8 bits) Puede ser comprimido
Payload Length (16 bits) Puede ser omitido porque la longitud del paquete IP puede ser obtenido de la
información de la longitud en la capa MAC.
Next Header (8 bits) Puede ser comprimido en el contexto de la convergencia IP si se asume que la
siguiente capa es UDP, ICMP, TCP.
Hop Limit (8 bits) El único campo que no puede ser omitido.
Source Address (128 bits) Puede ser comprimido omitiendo el prefijo (o identificador de interfaz)
MBIGDA_M8T2_160727
86
Para la implementación de la compresión de las cabeceras se indican dos algoritmos

LOWPAN_HC1 and LOWPAN_IPHC (RFC6282). LOWPAN_HC1 es aplicable solo en redes que utilicen
direcciones de enlace local (link-local) y no puede ser usado para conectar 6LoWPAN a internet.
8.3. RPL
Las redes de baja potencia y con altas tasas de pérdida de paquetes (LLNS) representan una de
las áreas de investigación más interesantes. Incluyen por lo general redes inalámbricas (WPAN
redes de área), de baja potencia mediante “Power Line Communication” (PLC) y redes de sensores
inalámbricos (WSNs).
Las redes LLNS y, en particular, las WSNs están emergiendo rápidamente como un nuevo tipo
de sistemas distribuidos, con aplicaciones en diferentes áreas tales como seguimiento de objetos,
medio ambiente, gestión del tráfico, etc. Sin embargo, para conseguir una comunicación fiable,
para garantizar una alta relación de entrega y al mismo tiempo gestionar la energía de forma
eficiente requiere de mecanismos especiales en la capa de red. Como resultado, RPL se ha
especificado y desarrollado con el fin de superar estos requisitos.
El protocolo de enrutamiento de IPv6 para redes con energía baja y con pérdidas (RPL), que ha
sido diseñado para superar los problemas de enrutamiento en LLNS.
El grupo de trabajop de IETF “Routing over Lossy and Low-power Networks working group
(RoLL)” se ha centrado en el diseño del enrutamiento con objeto de alcanzar una estandarización
para el uso de IPv6 en este tipo de redes. Dado que la situación requiere una adaptación a los
dispositivos y al medio, esta estandarización se produce conforme a escenarios de aplicación, se
han definido cuatro escenarios hasta el momento “Home Automation (RFC5826)”, “Industrial
Control (RFC5673)”, “Urban Environment (RFC5548)” y “Building Automation (RFC 5867)”.
Este tipo de redes suelen estar optimizados para ahorrar energía usando patrones diferentes de
la comunicación estándar, ejecutar los protocolos de enrutamiento a través de capas de enlace de
elementos embebidos en tamaños y capacidades restringidas
MBIGDA_M8T2_160727
87
Implementa medidas para reducir el consumo de energía, tales como el envío de tasa de
mensajes de control dinámico y hacer frente a las incoherencias de topología sólo cuando los
paquetes de datos tienen que ser enviados. E protocolo también proporciona soluciones de
Gateway y saltos intermedios entre nodos de la topología.
RPL soporta tres tipos de tráfico: point-to-point (entre dispositivos dentro de la LLN), pointto-
multipoint (un centro de control a un subconjunto de dispositivos dentro de la LLN) y multipoint-to-
point (desde los dispositivos dentro de la LLN hacia un punto de control central).
Los dispositivos de red que ejecutan el protocolo están conectados de una manera tal que no
hay ciclos. Para este propósito se construye un grafo acíclico orientado a destino (DODAG), que
encamina las peticiones a un solo destino sin caer en ciclos de enrutamiento. El grafo es gestionado
por un nodo raíz.
El grafo es construido con una función que calcula las métricas a tener en cuenta en el cálculo
del peso de los caminos construidos, de manera que pueden darse diferentes funciones de
optimización en función de las necesidades del escenario de despliegue.
Otro hecho importante sobre el diseño del protocolo es el mantenimiento de la topología. Dado
que la mayoría de los dispositivos en un LLN se alimentan por batería, es crucial limitar la cantidad
de mensajes de control enviados a través de la red. Muchos protocolos de encaminamiento hacen
difusión de paquetes de control en un intervalo de tiempo fijo, que hace que la energía que se
desperdicie cuando la red está en una condición estable.
RPL adapta la tasa de envío de mensajes de control extendiendo el algoritmo Trickle. En una red
con enlaces estables los mensajes de control serán raros mientras que un ambiente en el que los
cambios en la topología sean frecuentes RPL enviará información de control con mayor frecuencia.
RPL emplea mensajes de dos tipos DIO para configurar la red y DAO para enrutar envíos entre
los nodos.
En general, hay tres tipos de nodos en una red RPL: El primer tipo son nodos raíz que se hace
referencia comúnmente como nodos de puerta de enlace que proporcionan conectividad a otra
MBIGDA_M8T2_160727
88
red. El segundo tipo son los routers. Dichos nodos pueden anunciar información de topología a sus
vecinos. El tercer tipo son las hojas que no envían ningún mensaje de control (DIO) y sólo tienen la
capacidad de unirse a un grafo (DODAG) existente.
La construcción de la topología se inicia en un nodo raíz que comienza a enviar mensajes de

DIO. Cada nodo que recibe el mensaje se ejecuta un algoritmo para elegir una matriz apropiada. La
elección se basa en las limitaciones métricas y usos definidos por la función de optimización.
Posteriormente cada uno de ellos calcula su propio rango y en caso de que un nodo sea un router,
se actualiza su posición en el mensaje de DIO y lo envía a todos los pares vecinos. Esos nodos
repiten los mismos pasos y el proceso termina cuando un mensaje DIO llega a un nodo hoja o
cuando no hay más nodos a su alcance.
Existen definidas funciones de optimización para la construcción de la topología atendiendo a

diferentes criterios.
Muchos de los protocolos de enrutamiento de hoy en día utilizan métricas de enlace que no
tienen en cuenta el estado actual de un nodo. El estado incluye recursos típicos como el uso de la
CPU, la memoria disponible y la energía restante. Esto puede ser crucial para LLNS donde los
dispositivos de red son por lo general alimentados con baterías y tienen recursos limitados de
hardware. Considerar estos aspectos conlleva por ejemplo, el que en una topología de red de
sensores, el último nodo antes de la raíz por lo general experimentará un tráfico más alto, y
mayores gastos de sus recursos por reenviar datos de los otros nodos.
El protocolo es una solución basada en IP de extremo a extremo que no requiere Gateways de

traducción a fin de alcanzar los nodos. Por otra parte, el uso de IPv6 permite el despliegue de
servicios web RESTful para redes de sensores. De esta manera, un cliente (por ejemplo, PC
conectado a la raíz) puede iniciar solicitudes mediante el uso de HTTP para los nodos dentro de la
red que devolverán las respuestas apropiadas. Es aún más fácil de usar esta característica, ya que
RPL define en su especificación soporte al tráfico hacia abajo. Debido a P2MP un nodo raíz puede
propagar fácilmente estas peticiones a los nodos.
MBIGDA_M8T2_160727
89
También debe mencionarse que RPL se puede ejecutar en nodos que tienen limitadas
capacidades de energía y memoria. El protocolo se adapta dinámicamente la tasa de envío de
mensajes de control de enrutamiento que se generarían frecuentemente sólo si la red está en una
condición inestable. Además, el protocolo educe la sobrecarga de la memoria en los nodos
intermedios.
RPL también permite la optimización de la red para distintos escenarios y despliegues. Por
ejemplo, se puede tener en cuenta la calidad del enlace entre nodos o su cantidad actual de
energía, lo que hace que sea una solución eficiente para implementaciones WSN.
8.4. ZigBee
Para formar una red ZigBee se necesitan tres tipos distintos de dispositivo según su papel en la
red:
- Coordinador ZigBee (ZigBee Coordinator, ZC). El tipo de dispositivo más completo. Debe
existir al menos uno por red. Sus funciones son las de encargarse de controlar la red y
los caminos que deben seguir los dispositivos para conectarse entre ellos.
- Router ZigBee (ZigBee Router, ZR). Interconecta dispositivos separados en la topología
de la red, además de ofrecer un nivel de aplicación para la ejecución de código de
usuario.
- Dispositivo final (ZigBee End Device, ZED). Posee la funcionalidad necesaria para
comunicarse con su nodo padre (el coordinador o un router), pero no puede transmitir
información destinada a otros dispositivos. De esta forma, este tipo de nodo puede
estar dormido la mayor parte del tiempo, aumentando la vida media de sus baterías.
Un ZED tiene requerimientos mínimos de memoria y es por tanto significativamente
más barato.
ZigBee permite tres topologías de red:
- Topología en estrella: el coordinador se sitúa en el centro.

- Topología en árbol: el coordinador será la raíz del árbol.
MBIGDA_M8T2_160727
90
- Topología de malla: al menos uno de los nodos tendrá más de dos conexiones.
La topología más interesante (y una de las causas por las que parece que puede triunfar Zigbee)
es la topología de malla. Ésta permite que si, en un momento dado, un nodo del camino falla y se
cae, pueda seguir la comunicación entre todos los demás nodos debido a que se rehacen todos los
caminos. La gestión de los caminos es tarea del coordinador.
Ejemplo de red ZigBee con un coordinador , varios routers y dispositivos f ina les
Como ejemplo de aplicación en Domótica, en una habitación de la casa tendríamos diversos

Dispositivos Finales (como un interruptor y una lámpara) y una red de interconexión realizada con
Routers ZigBee y gobernada por un Coordinador.
8.5. Z-Wave
Z-Wave es un protocolo de comunicaciones inalámbricas para la automatización residencial. Se
orienta al control y la automatización intentando proveer de un método confiable y simple para
controlar elementos de las viviendas tales como luces, sistemas de climatización, seguridad, home
cinema, ventanas, piscinas, y garajes. El protocolo es propietario y fue creado en 2005. Es un
sistema de éxito en domótica en el sector residencial y hay muchos dispositivos que son
interoperables por este protocolo.
MBIGDA_M8T2_160727
91
Un Sistema Z-Wave puede ser utilizado remotamente a través de Internet usando un Gateway
Z-Wave. Los nodos Z-Wave usan el chip ZW0201, basado en Intel MCS-51. Actualmente Z-Wave ha
adaptado el protocolo para su uso en System-On-a-Chip (SOC) de la serie 500.
Algunos productos Z-Wave se presentan con versiones Open Source, aunque Z-Wave es una
solución muy cerrada y para desarrollar se requieren versiones OEM para fabricante.
En cuanto a ancho la comunicación Z-Wave proporciona confiabilidad y baja latencia para

pequeños paquetes de datos y tasas de transferencia de hasta 100 kbit/s. Su diseño se orienta a
mover paquetes de datos pequeños, de sensores y para realizar actuación, en contraposición a WiFi
que principalmente busca obtener unas tasas de transferencia mayores.
La distancia alcanzable entre dos nodos Z-Wave es de unos 30 metros. El protocolo permite
realizar hasta cuatro saltos entre nodos, junto con la distancia de 30 metros entre nodos, ambos
aspectos combinados dan suficiente cobertura para cubrir el tamaño de una casa.
La banda elegida para la transmisión es una banda libre para uso industrial, científico y médico,
puede estar sujeto a interferencias con algunos dispositivos como teléfonos inalámbricos, pero
queda libre de interferencias con WiFi o Bluetooth.
Z-Wave implementa una red mallada de nodos en la que los paquetes se dirigen de forma
dinámica a través de la vivienda evitando los obstáculos o nodos caídos. Si la ruta preferida no está
disponible, un nodo probará otras rutas hasta que se encuentre el camino hasta el destino. Estas
situaciones pueden provocar variaciones significativas en las latencias, y deben ser consideradas
especialmente en las acciones de control.
Una red Z-Wave puede tener entre 2 y 232 nodos, dos redes Z-Wave pueden ser unidas.
Los nodos de una red no pueden ser móviles, se considera que son dispositivos fijados
físicamente a una localización, por lo que no es un protocolo adecuado por ejemplo en robots de
servicio con capacidades de desplazamiento. Durante la unión de un dispositivo a la red se asigna la
localización de este, y para ubicarlo en otra localización se requiere desagregarlo de la red y volver
a agregarlo a la red.
MBIGDA_M8T2_160727
92
Los nodos pueden funcionar en modo de bajo consumo (para dispositivos alimentados con
batería) pero en este modo de funcionamiento no pueden realizar la función de enrutar paquetes
para otros dispositivos de la red.
8.6. INSTEON
El sistema INSTEON es un sistema de domótica donde los dispositivos no se diferencia por su
funcionalidad en la red (todos son emisores, repetidores y receptores). Es un sistema que dispone
de banda dual: funciona en radiofrecuencia (RF) y mediante la red eléctrica de corriente alterna
(CA), el protocolo permite construir redes mezclando estos tipos de medios físicos, lo que facilita
evitar interferencias y superar obstáculos.
Una particularidad del enrutamiento es que cada nodo emite todo mensaje que recibe, de
manera que este alcanza a todos los nodos en su cercanía, indistintamente de si la conexión es RF o
CA para los dispositivos que tienen los dos interfaces DualBand. Los mensajes incluyen un número
de saltos máximo para no ser retransmitidos indefinidamente. Dispone de sistema de detección y
corrección de errores en los paquetes.
MBIGDA_M8T2_160727
93
Topolog ía de un a red Insteon DualBand en la que los enlace s representados con lín eas c o ntinuas representan
conexiones CA, y las líneas d is continuas RF.
Puede realizar (SimulCast) una especie de difusión (Broadcast) a todos los dispositivos de forma
óptima.
Existen dispositivos de muy diversa índole para el uso en domótica residencial, incluyendo
soluciones técnicas para interconexión de redes y con el sistema, son esenciales obviamente los
enchufes e interruptores que son anfitriones de versiones de pasarela entre las dos capas físicas
(CA y RF).
MBIGDA_M8T2_160727
94
Esquema ejemplo de una red I NSTEON
9. Protocolos de aplicación
Conceptualmente Internet e las cosas se refiere a la idea genera de que las cosas,
especialmente los objetos cotidianos, son accesibles, reconocibles, localizables, direccionables y/o
controlables a través de Internet; bien vía RFID, WLAN, WAN, o cualquier otra forma de construir
una red para interconectarlos. Los objetos cotidianos no solo se refieren a dispositivos electrónicos
ni de un alto desarrollo tecnológico y grandes prestaciones como vehículos o teléfonos móviles,
sino también a elementos como alimentos, ropa, complementos, materiales, etc.
MBIGDA_M8T2_160727
95
La interconexión de estos elementos hacia un espacio común (Internet) requiere de

mecanismos que transporten muchos datos que se generan a distintas velocidades y con distintos
volúmenes de información, de una forma segura y confiable.
Debemos realizar una diferenciación en internet de las cosas referida a si la generación y el uso
de la información es en un entorno de consumo / social o es en un entorno industrial / profesional.
Así, no tiene la misma criticidad una aplicación de internet de las cosas para controlar la
temperatura en casa, que para controlarla en una empresa que tiene una parte de su proceso
productivo en cámaras frigoríficas, o si vamos más allá en un entorno hospitalario, o militar.
En el concepto de Internet de las Cosas Industrial destacan dos aspectos claves diferenciadores:
- La conexión de máquinas industriales con sensores y actuadores que funcionan de

forma local, y conectadas a Internet.
- La interconexión con otras redes industriales que pueden generar valor
independientemente.
Los sistemas industriales que actualmente utilizan estas tecnologías incluyen sectores tan
representativos como aeroespacial y defensa, control de tráfico aéreo, sistemas de gestión y
control de combate, modelado y simulación, vetrónica (vehículo electrónico), sanidad y entorno
hospitalario, ferrocarril y gestión de vehículos, energía inteligente en sistemas SCADA de gran
tamaño, y Smart Cities.
Existen muchas tecnologías de protocolo aplicables al entorno de IoT, pero cuando se

consideran aspectos industriales, de misión crítica, sistemas en tiempo real, muchas de ellas no son
apropiadas para el enfoque Industrial de Internet de las Cosas: DDS, AMQP, MQTT, JMS, REST,
CoAP, XMPP.
MBIGDA_M8T2_160727
96
Aplicac ión de protoco los en d istintas áreas de sis temas IoT.
9.1. HTTP/REST
Los servicios a través de HTTP se han popularizado gracias a la web, de manera que existen
multitud de tecnologías, herramientas, software y personas con conocimiento en este protocolo.
Esta popularización ha conllevado una evolución en los usos del protocolo y en el desarrollo de
conceptos que son usables o extrapolables a otros ámbitos. Así el protocolo HTTP se presenta
idóneo para un rápido desarrollo y popularización del Internet de las Cosas, y allí donde sea
aplicable será un protocolo idóneo. HTTP es un protocolo de envío y respuesta, el cliente HTTP
envía una petición al servidor que es respondida, hasta la siguiente petición del cliente no existirá
vínculo entre cliente y servidor. Cada petición se enruta de forma independiente de las anteriores,
no existe una conexión permanente.
En la evolución de HTTP y para proveer servicios que la tecnología y la demanda de uso han ido
favoreciendo, se han incorporado capacidades que incluso han roto con el concepto de protocolo
MBIGDA_M8T2_160727
97
de envío y respuesta, como la posibilidad de establecer una conexión permanente (para enviarse
mutuamente datos entre servidor y cliente).
REST (Representational State Transfer) es un concepto aplicado sobre http para favorecer el
desarrollo de servicios web. REST consiste en utilizar el protocolo HTTP cumpliendo unas normas
(por convención) que facilitan tanto el desarrollo como el uso de aplicaciones que proporcionan
servicios y aplicaciones cliente de servicios.
Dado su fácil uso se ha popularizado, en contraposición a protocolos más complejos como

SOAP, WSDL, o RPC. Un principio básico de REST consiste en que cada petición es independiente,
esto es, no es necesario conservar el estado en el servidor ni en el cliente para interpretar las
peticiones. Además hay un conjunto reducido de peticiones o verbos (POST, PUT, GET, DELETE) que
se basan en los verbos del propio protocolo HTTP, y a los que se atribuye un significado de la acción
que se pretende realizar, asimilados a (crear, modificar, obtener, borrar). La semántica detallada de
lo que hace la acción depende de cada servicio pero dentro de ese contexto se asimilan a esas
acciones.
En REST todo recurso está identificado por una URI, un identificador que permite,
inequívocamente, acceder a los servicios que proporcione el recurso. Esta URI en HTTP tiene la
forma de una URL.
Los servicios REST devuelven un documento XML, HTML, JSON de tipo hipermedia, de forma
que es fácilmente interpretable de forma básica sin requerir aplicaciones especializadas para
interpretar la respuesta de un servicio (se puede invocar por ejemplo desde un navegador web).
Dado que la información se transmite sobre HTTP es habitual disponer de conectividad,

seguridad, y toda la configuración de red necesaria para este protocolo en una infraestructura,
haciendo prácticamente indiferente la red y la infraestructura en los proyectos que usan REST.
Una gran ventaja de REST sobre HTTP es la interoperabilidad entre diferentes tecnologías para
conectarse a los servicios ofrecidos mediante este protocolo. Por una parte clientes HTTP existen
en prácticamente todas las tecnologías, por otra no hay transferencia binaria que obligue a
MBIGDA_M8T2_160727
98
traducciones complejas. Así a un servicio REST es fácil desde una aplicación nativa de un sistema
Apple, o desde un navegador web escrito en C++, o desde un script Python.
Ejemplo de una ap licac ión en una telev isión que ofrece un interfaz REST para ser s inton iz ada. El cliente ( Dia l Client) se
comunica con REST con la Tele visión ( TV) que desen cadena acciones sobre la API de la aplicac ión que se ejecu ta en esta
ante las peticiones rea lizadas por el c liente.
En el ejemplo de un sintonizador de TV podríamos tener diferentes URIS para los servicios, para
configurar, para usar, etc. Por ejemplo:
SERVICIO SINTONIZADOR:
- POST crea un nuevo canal con la frecuencia indicada

- GET obtiene para un canal la frecuencia guardada
- PUT modifica un canal estableciendo una frecuencia
- DELETE elimina un canal
Una vez creado el servicio que responde a estas peticiones por HTTP y en el que se fija además
como se representan los objetos que se envían bajo un verbo y se reciben bajo un verbo (un
determinado XML o JSON) es fácil crear un cliente para sintonizar la TV.
MBIGDA_M8T2_160727
99
Nótese que al ser un servicio HTTP, es muy fácil interaccionar con la TV localmente, el cliente se
ejecuta desde la botonera de la propia TV, desde el módulo receptor de infrarrojos, o remotamente
desde un cliente a través de Internet.
El problema de HTTP REST para IoT consiste en que las redes subyacentes tienen que tener unas
capacidades y comportamientos asimilables a la web, en el sentido de tiempo de espera en TCP,
anchos de banda, etc. Algunos dispositivos por su potencia y capacidades podrán enviar y recibir los
datos por HTTP sin problema, es decir, se podrá montar un servidor web y dispondrá de potencia y
de alcance suficiente a través de la red que le de soporte, pero los servicios que sean prestados por
dispositivos con capacidades restringidas no será tan fácil, hacen falta soluciones que ofrezcan un
interfaz HTTP/REST pero internamente resuelvan la problemáticas del medio, en este sentido CoAP
es un ejemplo.
9.2. CoAP
Proporciona un protocolo de la IETF, del grupo de trabajo “Constrained RESTful Environments
working group” (CoRE), para realizar transferencia de tipo web RESTful, y está especializado para su
uso en dispositivos con restricciones severas en capacidades de cómputo y comunicaciones. Estas
situaciones se dan, además de en otros campos, en el campo de M2M e IoT.
Es un protocolo de envío / respuesta en el que los nodos se hacen peticiones independientes sin
estado. REST es una solución muy aplicada en desarrollo de aplicaciones web en internet, y cada
vez más en todo tipo de servicios y en interoperabilidad entre sistemas.
CoAP, realiza una abstracción de las particularidades de los objetos de la red, convirtiéndolos en
recursos de manera que cada recurso es identificado mediante un identificador universal de
recurso (URI), y además puede ser utilizado de forma que no requiera mantener el estado
“stateless”, usando comandos GET, PUT, POST, DELETE. Cabe pensar que para este propósito, es
suficiente con desplegar un Servidor/Cliente en el dispositivo y para optimizar la comunicación en
redes de sensores aplicar una compresión al HTTP, pero estrictamente hablando, CoAP no es un
protocolo de compresión HTTP. Por una parte CoAP realiza la función de optimización pero por otra
parte proporciona funcionalidades necesarias en el entorno de IoT como el descubrimiento de
MBIGDA_M8T2_160727
100
recursos, la transmisión a múltiples dispositivos (multicast), y el intercambio asíncrono de

mensajes.
A diferencia de HTTP, CoAP utiliza un protocolo subyacente de transporte orientado a

datagrama, con objeto de asegurar las transmisiones sobre UDP. CoAp se estructura en dos capas:
Una capa de mensajes para controlar la interacción con UDP para dar soporte a usarlo de forma
asíncrona y una capa de petición/respuesta que permite transmitir tanto peticiones de operación
como datos.
Ubicación de CoAP en la capa de protocolos
En la capa de mensajes se existen cuatro tipos de mensajes:
- Confirmable (CON): se necesita un ACK del receptor.

- Non-confirmable (NON): no se necesita un ACK del receptor.
- Acknowledgment (ACK): representa que una confirmación se ha recibido.
- Reset (RST): representa que un mensaje de confirmación se ha recibido pero no puede
ser procesado.
La capa de envío / respuesta proporciona funcionalidades para:
- Protocolo web restringido para cumplir requerimientos de uso en M2M.

- Intercambio asíncrono de mensajes.
- Elaborar cabeceras de baja complejidad y con bajos requerimientos de análisis
“parseo”.
MBIGDA_M8T2_160727
101
- Proporciona el soporte para el uso de URI y tipo de contenido “Content-type”.

- Proporciona cacheado y proxy simple.
- Descubrimiento de recursos.
- Enlace con la capa UDP con confiabilidad ajustable en peticiones a un dispositivo
(unicast) o a un grupo (multicast).
- Proporciona un mapeo HTTP-CoAP haciendo de proxy para proveer acceso a recursos
CoAP mediante HTTP y viceversa.
Aplicando CoAP en una WSN se puede acceder desde internet a los recursos de la red de
sensores de forma directa o a través de un proxy.
El acceso directo significa que desde Internet se accede a la WSN a través de un Gateway que
solo realiza la conversión de protocolo entre IPv6 y 6LoWPAN, pero no procesa los protocolos de
las capas superiores, por ejemplo CoAP o TCP, este uso reduce la sobrecarga de procesamiento,
pero requiere que en ambos extremos se estén usando los mismos protocolos.
El acceso a través de un Proxy significa que el usuario accede a la WSN a través de un proxy que
convierte formatos de datos incompatibles externos a formatos compatibles internos en las redes
WSN y viceversa, así se puede por ejemplo interactuar con HTTP, TCP, e IPv4 sobre IPV6 con UDP.
Estas conversiones las realiza el Gateway.
MBIGDA_M8T2_160727
102
La ventaja de usar un proxy es que los servicios actuales de internet pueden acceder fácilmente
a los recursos de redes WSN sin realizar cambios gracias a la transformación que realiza el Gateway
proxy. Pero además, los dispositivos de baja potencia no pueden gestionar conexiones TCP de
forma eficiente, la conexión TCP está diseñada para unos tiempos de respuesta que los pequeños
dispositivos y los anchos de banda de las WSNs no pueden cumplir, TCP interpreta que el servicio
no está disponible o la conexión se ha perdido. El proxy proporciona la capacidad de realizar de
buffer para procesar las peticiones y evitar el timeout del protocolo TCP manteniendo viva la
conexión TCP.
Un ejemplo de implementación de un sistema IoT con capacidades de interoperabilidad

mediante HTTP a través del protocolo CoAP con una red de sensores puede ser construido sobre un
Hardware que realice las funciones de Proxy Gateway dotado de interfaces físicas para protocolos
de Internet y de 802.15.4
Basado en un hardware de plataforma abierta, el Router debe ser dotado de capacidades para
la conectividad 802.15.4 y de una implementación del proxy HTTPCoAP que se debe instalar en el
MBIGDA_M8T2_160727
103
sistema operativo del Gateway (OpenWrt). El Gateway realizará el mapeo de una IPv4 a la IPv6 de
la red de sensores.
Hardware para un proxy Gate way HTTP -CoAP
En este Gateway el software que realiza la implementación de la traducción de protocolo

proporciona una capa para mapear las peticiones HTTP a CoAP y viceversa, una capa para manejar
las peticiones / respuestas de CoAP, se apoya en una librería (libcoap) que realiza la capa de
mensajes UDP de CoAP.
Interacciones en tre las capas de software y Arquitectura de capas de sof tware en e l Prox y Gateway HC (HTTP -CoAP).
MBIGDA_M8T2_160727
104
La capa CoAP de petición y respuesta implementa las funciones para interactuar con los
dispositivos a través de una librería que implementa el protocolo CoAP. Como CoAP usa UDP y no
es confiable, la capa CoAP response deberá incluir la gestión del ACK de mensajes CoAP, la
retransmisión de peticiones por Timeout, el procesamiento de los mensajes directos, asíncronos y
segmentados, etc.
La capa de mapeo de servicios HTTP-CoAP implementa la invocación entre servicios HTTP y

servicios CoAP y viceversa. Al convertir una petición HTTP a CoAP el proxy tiene que traducir el
método HTTP (POST GET,…), la URI, y las opciones de cabecera. Si se produce un error debe
devolver el error correspondiente.
Cuando se implementa este tipo de solución se observa la gran problemática que resuelve. Por
una parte subyacente está la red de sensores que funciona con 6LowPAN/IPv6/RPL y CoAP, el proxy
CoAP tiene que resolver las situaciones que se van a dar en las capas inferiores en cuanto a
proporcionar el servicio deseado en una red de sensores que tiene alta inestabilidad de forma
inherente. En este caso de ejemplo se observa como al lidiar con una red WSN conforme aumenta
el número de saltos entre nodos, se pierden paquetes, y se deben resolver estas situaciones para
proporcionar servicios confiables. En este caso en el nivel 6 se llegan a perder hasta el 56% de los
paquetes.
Todos estos fallos aunque el Gateway sea capaz de resolverlos hasta proporcionar la
información implican por un lado que la velocidad de respuesta crece conforme los nodos están a
distancia y como se enrute el tráfico, por otro que no lo hacen de forma lineal o predecible
directamente en función del número de saltos. Finalmente el funcionamiento puede estar
MBIGDA_M8T2_160727
105
comprometido por sobrecarga de mensajes en la red por las tasas de fallos, y lentitud en la
respuesta. Aquí el criterio de la función de optimización de RPL resulta crítico.
PAQUETES PERDIDOS
60
50
40
30
20
10
0
0 1 2 3 4 5 6 7
% de paquetes perdidos en fu nción de l número de sa ltos en una red prototipo Proxy Gate way HTTP -CoAP. El escenario
de prueba fue def inido con un entorno con mucho ruido en el que la comun icac ión entre dispositivos so lo ten ía u n
alcance de 30 cm.
En el caso de ejemplo se despliegan varios dispositivos 802.15.4 uno de ellos una cámara
conectada al Gateway, el recurso se publica bajo la IPv6 que se le asigna, de manera que enviando
una petición HTTP desde un navegador web conectado al Gateway por Wifi 802.11, el Gateway
gestiona la petición hasta el dispositivo y devuelve la respuesta al navegador.
La URI del recurso es http://[2001:2::19]/camera y la petición que se realiza es el método GET.

Al realizar esta petición desde un navegador web se muestra la imagen de la cámara sin necesidad
de implementar código específico alguno para conectar, solicitar, interpretar la respuesta y
visualizarla.
En contraposición, con un cliente CoAP (no HTTP REST) se puede hacer la conexión directa
lanzando la petición coap://[2001:2::19]:5683/camera que devolverá la imagen sin pasar por el
servicio proxy del Gateway, al cliente específico COAP.
Este caso representa la importancia de la convergencia en servicios HTTP/REST más allá aún de
la importancia de la convergencia IP.
MBIGDA_M8T2_160727
106
9.3. XMPP
XMPP es un protocolo abierto y extensible basado en XML, originalmente ideado para
mensajería instantánea (anteriormente conocido como Jabber). Sus siglas significan Protocolo
extensible de mensajería y comunicación de presencia (Extensible Messaging and Presence
Protocol).
El protocolo XMPP establece una plataforma para el intercambio de datos XML que puede ser
usada en aplicaciones de mensajería instantánea. Por su origen como software libre existen
servidores y clientes que pueden ser usados sin coste alguno.
Véase que aunque los usuarios tienen como concepto de mensajería las aplicaciones de chat, y
en este caso aún más al haber sido usado de forma muy generalizada XMPP para sistemas de chat,
la mensajería entre maquinas consiste en el paso de mensajes para establecer una comunicación,
típicamente de forma asíncrona.
Las características de XMPP son adecuadas para IoT, y se postula como una herramienta para
construir dispositivos, servicios y aplicaciones sólidas, seguras e interoperables, para la Internet de
las cosas.
XMPP es particularmente rico cuando se trata de dar soporte a diferentes patrones de

comunicación, tales como envío / respuesta, mensajería asíncrona, publicación / suscripción,
suscripción a eventos (Observar) y entrega retrasada. XMPP también tiene soporte para diferentes
niveles de Calidad de Servicio para la mensajería.
XMPP ofrece diversas opciones, tales como conexiones de socket standard Binding, Streaming
Bidireccional sobre HTTP síncrona (BOSH) , e intercambio eficiente de XML (EXI). Los diferentes
modelos para establecer conexión en XMPP consisten en:
- XMPP Standard Binding: Permite a las cosas que conectarse a la red mediante una
conexión normal de socket bidireccional al servidor. Los fragmentos XML son
posteriormente enviados en ambas direcciones a través de esta conexión. Este método
se describe en las especificaciones XMPP RFC: RFC 6120, RFC 6121 y RFC 6122.
MBIGDA_M8T2_160727
107
- BOSH – Streaming Bidireccional sobre HTTP síncrona: Este mecanismo de unión

permite a los clientes que sólo pueden acceder a Internet utilizando el protocolo HTTP
serie (como clientes de Javascript) para conectarse a la red XMPP. BOSH se describe en
XEP-0206.
- EXI – XML de intercambio eficiente: Para pequeños dispositivos con recursos limitados,
XMPP puede parecer un formato demasiado pesado. A menudo los paquetes de red
tienen que ser pequeños para no ser fragmentados, como es el caso en redes de radio
6LoWPAN. Para permitir que este tipo de dispositivos pueda usar XMPP se puede
utilizar EXI en XMPP. EXI, o XML de intercambio eficiente, es una forma
excepcionalmente eficiente de compresión XML, utilizando los conocimientos derivados
de los esquemas XML, permite que los fragmentos se compriman a tamaños adecuados
para las redes con recursos restringidos. EXI se describe en XEP-0322: Efficient XML
Interchange (EXI) Format.
XMPP ofrece varias posibilidades para la comunicación, conocidos como patrones de

comunicación, para un determinado problema un patrón resuelve o proporciona las soluciones
básicas que resuelven la comunicación en un problema tipo. Los patrones de comunicación XMPP
son:
- Comunicación por Petición / Respuesta:
El patrón de comunicación de petición / respuesta es uno de los patrones más básicos de

comunicación. Permite a un cliente solicitar información de un servidor y como resultado de la
petición obtener inmediatamente la respuesta. Las palabras "cliente" y "servidor" se utilizan aquí
únicamente para ilustrar los roles de los participantes en el patrón, no para describir una jerarquía
de la red. Lo más común en IoT es que la comunicación sea entre dos elementos similares en la red.
XMPP proporciona un método intrínseco para poner en práctica un mecanismo de petición /

respuesta genérico.
Si la respuesta es lenta en producirse y ser obtenida por quién hizo la petición, y los resultados
parciales tienen que ser devueltos para mostrar el progreso, este sistema básico no es suficiente.
MBIGDA_M8T2_160727
108
Este podría ser el caso cuando se comunica con dispositivos detrás de puertas de enlace, detrás de
la cual se utilicen protocolos de comunicación muy lentos. Otro ejemplo importante, es si se desean
soluciones interoperables. En tales casos, las soluciones propietarias dificultades que las hacen
difíciles de integrar en contextos más grandes.
Para facilitar la creación de una arquitectura abierta y débilmente acoplada que permita la
interoperabilidad entre las cosas y las aplicaciones, se define el estándar XEP-0323: “Internet of
Things - Sensor Data was created”. Se define un mecanismo de petición / respuesta, donde los
datos del sensor se pueden leer desde los dispositivos de forma asíncrona. Aparte del mecanismo
de petición / respuesta normal proporcionada por XMPP, permite una respuesta lenta y define un
formato de datos que puede ser usado para encapsular los datos del sensor de una manera
interoperable. Está diseñado para permitir añadir nuevos tipos de dispositivo que a las redes sin la
necesidad de actualizar el software para realizar las tareas básicas, tales como lectura de los datos
del sensor, el procesamiento de datos y la presentación de datos a los usuarios humanos. También
permite a los dispositivos de diferentes fabricantes y aplicaciones de diferentes desarrolladores
intercambiar datos de fichero con facilidad.
Ejemplo de petición / respuesta asíncrona, el cliente rea liza una petición y rec ibe varias r espuestas enviadas desde el
disposit ivo has ta ob tener una respuesta de f inalizac ión.
MBIGDA_M8T2_160727
109
- Comunicación por Mensajería Asíncrona:
El patrón de comunicación de mensajería asíncrona permite a sus compañeros en la red enviar

mensajes de forma asíncrona en tiempo real entre sí cuando estos lo deciden, no cuando se les
solicite.
Para facilitar el intercambio de datos en IoT, entre las cosas de diferentes fabricantes, de forma
asíncrona, los datos se pueden encapsular utilizando el formato de datos del sensor. Esta forma uso
se define en XEP-0323: Internet of Things - Sensor Data y para control en XEP-0325: Internet of
Things - Control.
- Comunicación mediante Publicación / Subscripción:
El patrón de publicación / suscripción permite la distribución masiva de información a las partes

interesadas de una manera eficiente. Reduce el tráfico de red hasta la mitad, al permitir que el
emisor de la información la envíe una sola vez a un servidor de publicación / suscripción, que la
retransmite a cada uno de los suscriptores.
En este patrón un nodo hace de broker proporcionando el servicio, típicamente se crean

canales o colas de mensajes, y se mantienen en el sistema hasta que el último suscriptor lo lee.
El patrón de publicación / suscripción para XMPP se define en XEP-0060: Publish-Subscribe. Los

datos de sensor pueden ser encapsulados con XEP-0323: Internet of Things - Sensor Data, y los
datos de control con XEP-0325: Internet of Things - Control.
- Comunicación mediante observador:
Observador es un patrón de diseño que define una dependencia del tipo uno-a-muchos entre
objetos, de manera que cuando uno de los objetos cambia su estado, notifica este cambio a todos
los dependientes. Cuando un aspecto de un programa cambia frecuentemente, estos patrones
definen un objeto que encapsula dicho aspecto. En XEP-0060: Publish-Subscribe se implementa el
patrón observador.
- Ejemplo
MBIGDA_M8T2_160727
110
Un ejemplo de uso del protocolo de envío y respuesta entre dos nodos de la red
intercambiarían los siguientes mensajes:
Envío de la petición de un dispositivo llamado “client” a un dispositivo llamado “device”.
<iq type='get' from='client@clayster.com/amr' to='device@clayster.com' id='S0001'>
<req xmlns='urn:xmpp:iot:sensordata' seqnr='1' momentary='true'/>
</iq>
Respuesta que emite el dispositivo al cliente indicando que acepta la petición.
<iq type='result' from='device@clayster.com' to='client@clayster.com/amr' id='S0001'>

<accepted xmlns='urn:xmpp:iot:sensordata' seqnr='1'/>
</iq>
Siguiente mensaje enviando los datos desde el dispositivo al cliente.
<message from='device@clayster.com' to='client@clayster.com/amr'>

<fields xmlns='urn:xmpp:iot:sensordata' seqnr='1' done='true'>
<node nodeId='Device01'>
<timestamp value='2013-03-07T16:24:30'>
<numeric name='Temperature' momentary='true' automaticReadout='true'
value='23.4' unit='°C'/>
<numeric name='load level' momentary='true' automaticReadout='true' value='75'
unit='%'/>
</timestamp>
</node>
</fields>
</message>
- Extensiones
Las diferentes extensiones del protocolo XMPP relacionadas con internet de las cosas son las
siguientes:
XEP Descripción
xep-0000-IoT- Define cómo manejar las peculiares relacionadas con los dispositivos
BatteryPoweredSensors alimentados con batería, y otros dispositivos que tienen presencia
intermitente en la red.
MBIGDA_M8T2_160727
111
xep-0000-IoT-Events Define cómo sensores envían eventos, cómo se configura la

suscripción de eventos, los niveles de histéresis, etc.
xep-0000-IoT- Define las directrices para lograr la interoperabilidad de las redes de

Interoperability sensores, la publicación de las interfaces de interoperabilidad para
diferentes tipos de dispositivos.
xep-0000-IoT-Multicast Define como los datos de sensores pueden ser difundidos (multicast)
de forma eficiente.
xep-0000-IoT-PubSub Define como los datos de sensores pueden ser publicados (de forma
eficiente
xep-0000-IoT-Chat Define como podrían construirse interfaces humano-máquina usando

mensajes de chat para ser amigables, automatizables y consistentes
con otras extensiones y la arquitectura.
XEP-0322 Define como usar EXI para alcanzar compresión eficiente de datos. No
es una extensión específica para datos de sensores, pero debería
considerarse su uso en cualquier red de sensores que tengan que
cuidar el uso de memoria y tamaño del paquete de datos.
XEP-0323 Esta especificación provee la arquitectura subyacente, las operaciones

básicas, y las estructuras para la comunicación de datos de sensores a
través de XMPP. Incluye un modelo de abstracción de hardware
eliminando cualquier detalle técnico de implementación dependiente
de la tecnología. Esta extensión es usada por todas las demás
extensiones relacionadas con redes de sensores.
MBIGDA_M8T2_160727
112
XEP-0324 Define el aprovisionamiento, la gestión de los privilegios de acceso,

etc. puede ser eficientemente y fácilmente implementado.
XEP-0325 Define como controlar actuadores y otros dispositivos en Internet de

las Cosas.
XEP-0326 Define como manejar arquitecturas que contienen concentradores o

servidores manejando múltiples sensores.
XEP-0331 Define extensiones sobre como colorear parámetros, basado en Data

Forms XEP-0004. Tiene utilidad en la interacción humano-dispositivo.
XEP-0336 Define extensiones para crear formularios dinámicos, basado en Data

Forms (XEP-0004), Data Forms Validation (XEP-0122) , Publishing
Stream Initiation Requests (XEP-0137) y Data Forms Layout (XEP-
0141).
XEP-0347 Define las particularidades del descubrimiento de sensores en redes

de sensores. Aparte del descubrimiento de sensores mediante el JID
(Jabber ID) define como descubrirlos basado en la localización, etc.
Extensiones del pro toco lo XM PP relac ionad as con Io T
9.4. MQTT
MQTT es un estándar ISO que define un protocolo de comunicaciones (ISO/IEC PRF 20922), la
comunicación se basa en mensajería de publicación y suscripción sobre TCP/IP. El protocolo fue
orientado desde sus inicios hacia la telemetría, sus siglas significan “Message Queue Telemetry
Transport”. Es muy útil para conexiones donde es importante no consumir mucho ancho de banda
MBIGDA_M8T2_160727
113
(se usa por ejemplo en comunicaciones entre sensores, conexiones GPRS,…) y para aplicaciones
móviles por su envío eficiente.
Un sistema de mensajería implica la existencia de un broker que se encarga de recibir y

despachar los mensajes, almacenándolos temporalmente hasta que son consumidos. Típicamente
los productores de mensajes envían los mensajes al broker para un topic, o “nombre de cola”, en el
otro extremo los consumidores de mensajes se suscriben a un topic para recibir los mensajes
enviados por los productores.
Una de las grandes ventajas que supone utilizar un intermediario con capacidad de
almacenamiento es que desacopla el funcionamiento de dos sistemas, una característica muy
deseable para IoT donde las variadas características de las redes de sensores y de los dispositivos
pueden condicionar al resto del sistema.
mensaje mensaje mensaje
BROKER
Productor Consumidor
Esquema general de un sistem a de mensajerí a as íncrona.
El protocolo fue diseñado originariamente por IBM con objeto de ser útil en entornos en los que
el código a ejecutar debe ser ligero y el ancho de banda es limitado, si bien no se llegan a establecer
de forma cuantificada estos dos objetivos. Actualmente hay dos versiones de MQTT: MQTT v3.1 y
MQTT-SN (Sensor Network) una variante del protocolo para dispositivos no-IP publicada en 2013.
MQTT en el contexto de IoT por su diseño no presenta capacidades de Big Data, aunque algunas
implementaciones permiten modo clúster, la arquitectura de MQTT sigue una topología de
estrella, con un nodo central no distribuido, que hace de servidor o “broker” con una capacidad de
hasta 10000 clientes. Se requiere de otros sistemas Big Data para combinarlos de manera que se
pueda construir un broker que atienda un gran número de mensajes y dispositivos.
MBIGDA_M8T2_160727
114
HTTP es un buen protocolo para envío de petición y respuesta, pero no es una buena solución
para envíos PUSH ni para garantizar calidad de servicio QoS, transmite texto y requiere bastante
ancho de banda comparado a una transmisión binaria, las soluciones HTTP consumen bastante
batería, mantener un servidor web desplegado para recibir peticiones es costoso, y para actuar
como host requiere toda la pila de software de un servidor web.
La capa de transporte sobre la que montar MQTT debe proporcionar ordenación, ausencia de
pérdidas, stream de bytes. MQTT puede funcionar sobre TCP/IP, TLS y WebSocket. UDP por
ejemplo no es válido para MQTT por no garantizar o poder modificar el orden de los datos.
Las comunicaciones en MQTT se orientan a proporcionar las siguientes funcionalidades para

una red de dispositivos:
Un cliente MQTT puede:
- Publicar un mensaje de aplicación que otros clientes pueden estar interesados en

recibir.
- Solicitar la suscripción a mensajes de aplicación en los que puede estar interesado.
- Cancelar una suscripción a mensajes de aplicación.
- Desconectarse del servidor.
El servidor MQTT se encarga de:
- Aceptar peticiones de conexión de red de clientes.

- Aceptar mensajes de aplicación publicados por clientes.
- Procesar las peticiones de suscripción y cancelación de suscripción de los clientes.
- Enviar a los clientes suscritos los mensajes de aplicación.
En este contexto un mensaje de aplicación es el contenido que transporta MQTT, los datos que
una aplicación que está usando MQTT pretende enviar o recibir.
MBIGDA_M8T2_160727
115
9.4.1. Estructura de información en MQTT
MQTT intercambia paquetes formados por tres bloques, una cabecera fija, presente en todos
los paquetes, una cabecera variable presente en algunos paquetes y una carga (“payload”) presente
en algunos paquetes.
La cabecera fija tiene tres campos:
- Cabecera: En el primer octeto están dos campos de 4 bits, el código de tipo de paquete,
y los “flags” u opciones para ese tipo de paquete, y un campo de entre 1 y 4 octetos
que indica la longitud total de los campos de cabecera variable y carga útil. La
codificación de este campo utiliza el ultimo bit de cada byte para saber si el valor
continua en el siguiente byte o ya ha finalizado, se usan entre 1 y 4 bytes, de forma que
la representación máxima es de 256MB.
- Cabecera variable: Algunos paquetes contienen una parte de cabecera variable, el
contenido y la longitud varía en función del tipo de paquete, por ejemplo un valor
común en varios tipos de paquete es el identificador de paquete compuesto por un
long de dos bytes. El cliente y el servidor asignan identificadores de paquetes de forma
independiente el uno del otro. Como resultado de ello, los emparejamientos entre
servidor y cliente pueden participar en intercambios de mensajes simultáneos
utilizando los mismos identificadores de paquete. Esto evita que se tenga que abordar
la complejidad y soportar las ineficiencias que supone de controlar una secuencia de
generación de identificadores distribuida.
- Carga útil: Algunos paquetes pueden portar carga útil, en tal caso un tercer campo está
presente, en el caso del paquete PUBLISH es donde residen los datos a transportar
entre las aplicaciones que estén haciendo uso de MQTT.
9.4.2. Niveles de servicio
MQTT entrega mensajes de aplicación de acuerdo con la calidad de los niveles de servicio (QoS)
definida. El protocolo de entrega es simétrico, en la siguiente descripción del cliente y el servidor
pueden cada uno tomar el papel de cualquiera de emisoras o receptoras. El protocolo de entrega se
MBIGDA_M8T2_160727
116
refiere únicamente a la entrega de un mensaje de aplicación desde un único emisor a un único

receptor.
Cuando el servidor está entregando un mensaje de aplicación a más de un cliente. Cada cliente
es tratado de forma independiente. El nivel de calidad de servicio se utiliza para decidir la forma de
funcionamiento en la entrega de un mensaje de aplicación.
- A lo sumo una vez: El mensaje se entrega de acuerdo a las capacidades de la red

subyacente (TCP). No hay respuesta del receptor y ningún reintento se realiza por el
remitente. No se almacena ni se intenta reenviar, tampoco se confirma al emisor. El
mensaje llega al receptor, una vez o ninguna.
- Al menos una vez: Se asegura que el mensaje llega al menos una vez, pero los mensajes
pueden duplicarse, el bróker almacena el mensaje hasta que el receptor confirma la
entrega, si transcurrido un tiempo el receptor no ha confirmado, el bróker vuelve a
enviar el mensaje. Una vez el bróker procesa el envío a los suscriptores se envía la
confirmación al emisor.
- Exactamente una vez: Cuando ni pérdida ni duplicación de mensajes son aceptables.
Hay una sobrecarga asociada con esta calidad de servicio. El funcionamiento consiste
en enviar la petición de publicación y responder con un mensaje una vez se ha
procesado, una vez se recibe este mensaje en el emisor se puede borrar la información,
y mantener esta confirmación, ahora hay que comunicar al receptor que se ha recibido
la respuesta, se envía un mensaje, cuando el receptor recibe este mensaje de
confirmación, puede eliminar la copia de los datos, él ha procesado la información y el
cliente lo sabe y no la reenviará. Por último el receptor envía al emisor una
confirmación de que ha recibido este último mensaje y el ciclo queda completo.
Es importante conocer que la QoS que se establece entre el emisor y el bróker puede ser
diferente a la QoS que se establezca entre un suscriptor y el bróker.
El identificador de paquete usado en QoS1 y QoS2 es único entre un cliente y un bróker y no es

único entre todos los clientes. El identificador de paquete puede ser reusado, el espacio de
MBIGDA_M8T2_160727
117
direccionamiento es de 65535 paquetes, se considera que no puede haber más de este número de
paquetes entre un cliente y un bróker sin que sean procesados.
Esto en Big Data supone un punto débil, e implica que puede necesitarse un sistema de apoyo
Big Data para el sistema de mensajería.
QoS Caso de uso
QoS 0 A lo sumo una Cuando la capa TCP sea estable y ofrezca bajas tasas de fallo, por
vez. ejemplo en una conexión cableada estable.
No es un problema el que algún dato se pierda.
No se necesita una cola de mensajes (esto es, almacenamiento

temporal), los mensajes solo se encolarán para los clientes
desconectados en sesión persistente y además con QoS 1 o QoS 2.
QoS 1 Al menos una Puedes gestionar mensajes duplicados.

vez
Es necesario recibir todos los mensajes y que no se pierda ningún

dato.
No puedes usar QoS2 por la sobrecarga que supone.
QoS 2 Exactamente Es crítico para la aplicación que no se reciban mensajes duplicados.

una vez
Obviamente es lo deseable, pero no siempre es posible por la

sobrecarga que supone.
Niveles de servic io y casos de uso
MBIGDA_M8T2_160727
118
9.4.3. Topics
Los topics, o “nombres de cola”, pueden presentar un separador “/” que se usa para dividir la
cola en una jerarquía de tipo árbol. Por ejemplo una jerarquía podría representar ubicaciones en la
forma: “29004/Calle2/5/planta1/humedad”.
Separadores continuos pueden aparecer en un topic por ejemplo “29004///planta1/humedad”

es válido y significan “la raíz” de ese nivel.
Para nombrar los topics y filtros hay que tener en cuenta las siguientes reglas:
- Debe contener al menos un carácter

- Es sensible a mayúsculas
- Puede incluir espacios
- Un topic iniciado o acabado en separador “/” es un topic diferente.
- Un topic consistente solo en un separador es un topic válido.
- No puede incluir el carácter null.
- Se codifican mediante UTF-8 y no pueden tener más de 65535 bytes.
Ejemplos:
- “ACCOUNTS” y “Accounts” son dos topics diferentes

- “Accounts payable” es un topic válido
- “/finance” es un topic diferente a “finance”
Una suscripción a un topic puede contener comodines “wildcard” que permiten suscribirse a
varios topics a la vez. Los comodines pueden ser usados en los filtros pero no en el nombre del
topic de suscripción.
El comodín “#” significa cualquier número de niveles, por ejemplo si un cliente se suscribe a
“sport/tennis/player1/#” recibirá mensajes enviados a:
- “sport/tennis/player1”
- “sport/tennis/player1/ranking”
MBIGDA_M8T2_160727
119
- “sport/tennis/player1/score/wimbledon”
Algunas consideraciones a tener en cuenta para usar los wildcards
- “sport/#” también recibe “sport”, puesto que # incluye al nivel padre.

- “#” es valido y recibe todo mensaje.
- “sport/tennis/#” es válido.
- “sport/tennis#” no es válido.
- “sport/tennis/#/ranking” no es válido.
El comodín “+” significa solo un nivel, por ejemplo si un cliente se suscribe a “sport/tennis/+”
recibirá mensajes enviados a:
Y no recibirá mensajes enviados a:
- “sport/tennis/player1/ranking”.
- “sport/+” no coincidirá con la cola “sport” pero sí con “sport/”.
Algunas consideraciones a tener en cuenta en el uso del wildcard “+”
- “+” es válido
- “+/tennis/#” es válido
- “sport+” no es válido
- “sport/+/player1” es válido
- “/finance” unifica con “+/+” y con “/+”, pero no con “+”.
El carácter especial “$”: Los topics que comienzan por $ tienen un tratamiento especial.
- $SYS/ ha sido adoptado como prefijo para topics que puedan tener información
específica del servidor o para implementar un API de control.
- Las aplicaciones no pueden usar un topic que comience por $.
MBIGDA_M8T2_160727
120
Por ejemplo:
- Una suscripcion a “#” no recibirá ningún mensaje publicado a un topic que comience
por “$”.
- Una suscripción a “+/monitor/Clients” no recibirá mensajes publicados en
“$SYS/monitor/Clients”
- Una suscripción a “$SYS/#” recibirá mensajes publicados a topics que comiencen por
- Una suscripción a “$SYS/#” recibirá mensajes que comiencen por “$SYS/”
- Una suscripción a “$SYS/monitor/+” recibirá mensajes publicados a
- Para que un cliente reciba mensajes “$SYS/” y también que no comienzan por $, tiene
que suscribirse a ambos “#” y “$SYS/#”
9.4.4. Seguridad
Típicamente el puerto definido para MQTT es TCP 8883 (nombre de servicio IANA: secure-mqtt).
En un protocolo como MQTT hay que tener en consideración circunstancias en torno a la seguridad,
amenazas, que las diferentes implementaciones deben contemplar y resolver, por ejemplo:
- Los dispositivos pueden estar comprometidos, es decir, se desconfía de la seguridad del

dispositivo.
- Datos en el cliente o servidor podrían ser accesibles.
- El comportamiento del protocolo podría tener efectos laterales por ejemplo “ataques
de tiempo”.
- Podría realizarse un ataque de denegación de servicio (DoS).
- Las comunicaciones pueden ser interceptadas, alteradas, redirigidas, o dada a conocer.
- Se podrían inyectar o falsificar paquetes de control.
Se deben proveer mecanismos para:
MBIGDA_M8T2_160727
121
- Autenticación de usuarios y dispositivos.

- Autorización de acceso a recursos del servidor.
- Integridad de paquetes de control de MQTT y de los datos contenidos.
- Privacidad de paquetes de control de MQTT y de los datos contenidos.
MQTT es un protocolo de transporte, y proporciona únicamente la transmisión de los datos, es

la implementación la que tiene la responsabilidad de proveer de las características de seguridad
apropiada, Habitualmente esto se alcanza usando TLS [RFC5246] entre la capa TCP y la capa MQTT.
Adicionalmente, se puede necesitar cubrir otros aspectos de seguridad específicos del ámbito
de aplicación del sistema, geográficos (p.e. U.S.-EU SafeHarbor [USEUSAFEHARB]), específicos de
una industria (p.e. PCI DSS [PCIDSS]) y normativas (p.e. Sarbanes-Oxley [SARBANES]).
Para la encriptación en dispositivos de capacidades restringidas existen recomendaciones ISO

29192 [ISO29192].
Existen muchos aspectos a considerar al implementar o usar MQTT:
- Autenticación de clientes por el servidor: consiste en que el servidor reconozca la

identidad del cliente de forma que un cliente no pueda suplantar la identidad de otro
cliente.
- Autorización de clientes por el servidor: consiste en que el servidor permita al cliente
realizar la acción que solicita.
- Autenticación del servidor por el cliente: consiste en que el cliente reconozca la
identidad del servidor, de manera que no pueda un servidor suplantar al servidor con
quien trata de hablar.
- Integridad de los mensajes de aplicación y de control: consiste en que durante la
comunicación entre cliente y servidor no se puedan alterar los mensajes.
- Privacidad de los mensajes de aplicación y de control: consiste en que se preserve el
contenido de los mensajes
- No rechazo de un mensaje: consiste en que no se pueda rechazar un mensaje que ha
sido correctamente enviado.
MBIGDA_M8T2_160727
122
- Detectar el compromiso de cliente o servidor: consiste en detector que un cliente o

servidor tiene la seguridad comprometida.
- Detectar comportamientos anormales: consiste en la detección como amenaza de un
comportamiento anormal, no habitual o inesperado.
- Otras consideraciones de seguridad.
- SOCKS: uso transparente de firewalls.
- Aplicar perfiles de seguridad: consiste en que la seguridad este normalizada en perfiles
que agrupan permisos, de manera que permita una fácil gestión y monitorización.
9.4.5. Establecimiento de conexión
Una conexión MQTT es siempre entre un cliente y un bróker, dos clientes no se conectan nunca
entre sí directamente. La conexión comienza cuando un cliente envía el mensaje CONNECT al
bróker, este le responde con un mensaje CONNACK y un código de estado. Una vez que la conexión
se ha establecido el bróker la mantendrá abierta de manera permanente hasta que el cliente envíe
un mensaje solicitando la desconexión DISCONNECT o hasta que se pierda la conexión.
Al permanecer la conexión abierta y ser alcanzable la dirección del bróker por el cliente MQTT,
el hecho de que en la infraestructura existan redirecciones por NAT para alcanzar el bróker en
direcciones privadas desde la dirección pública no supondrá ningún problema para hacer llegar
respuestas.
Cada librería o sistema puede tener parámetros adicionales aunque los parámetros
comúnmente requeridos, y esencialmente necesarios, para establecer la conexión son:
- El identificador de cliente es un identificador de cada cliente MQTT a conectar a un

bróker MQTT. Debe ser único por corredor. El bróker lo utiliza para identificar el cliente
y para controlar el estado actual del cliente. Si no se necesita que el bróker mantenga
un estado del cliente, en MQTT 3.1.1 (estándar actual) también es posible enviar un
identificador vacío, lo que se traduce en una conexión sin ningún estado, en este caso
debe indicarse “clean session” a true.
MBIGDA_M8T2_160727
123
- Indicar al broker si el cliente quiere establecer una sesión persistente o no. Una sesión
persistente (CleanSession es falso) significa, que el bróker va a almacenar todas las
suscripciones para el cliente y también todos los mensajes perdidos, cuando se
suscriben con calidad de servicio (QoS) 1 ó 2. Si “clean session” se establece a true, el
bróker no almacenará nada del cliente y también purgará toda la información de una
sesión persistente anterior.
- Usuario y clave: MQTT permite enviar un nombre de usuario y la contraseña para la
autenticación y autorización del cliente. Sin embargo, la contraseña se envía en texto
claro, a no ser que esté cifrado o en hash por la implementación o se utilice TLS por
debajo. Es muy recomendable utilizar nombre de usuario y contraseña junto con un
transporte seguro de la misma. Algunas implementaciones permiten también usar un
certificado SSL, en cuyo caso no se necesita indicar nombre de usuario y contraseña.
- Ultima voluntad, permite notificar a otros clientes, cuando un cliente se desconecta de
forma abrupta. Un cliente que se conecta proporcionará su voluntad en forma de un
mensaje de MQTT y del topic al que enviarlo en el mensaje de CONEXIÓN. Si el cliente
se desconecta abruptamente el bróker envía este mensaje en nombre del cliente.
- El “Mantener Vivo” (Keep alive) es un intervalo de tiempo en el que el cliente enviará
mensajes regulares de PING al bróker. La respuesta del bróker con el PING de respuesta
permitirá a ambas partes determinar si el otro está todavía vivo y accesible.
Una vez se recibe la petición de conexión el bróker responderá con un mensaje CONNACK, que
contendrá un indicador que determina si existe una sesión persistente previa para el cliente en el
bróker, y un código de respuesta que indica si se ha aceptado la conexión o si se ha rechazado, el
código indica el motivo de rechazo.
CONNECT
Cliente Broker
CONNACK
Establecim iento de c onexión en MQTT
MBIGDA_M8T2_160727
124
9.4.6. Publicación de un mensaje
Una vez que se ha establecido una conexión de un cliente MQTT a un broker, el cliente puede
publicar mensajes. Cada mensaje debe contener un topic, que será utilizado por el bróker para
reenviar el mensaje a los clientes interesados en este topic.
Cada mensaje tiene típicamente una carga útil que contiene los datos reales a transmitir en
formato binario. MQTT transporta datos de forma agnóstica, la carga útil puede ser cualquier cosa:
datos binarios, texto, XML, JSON,.... El mensaje de publicación MQTT tiene además:
- Nombre del topic: tema en el que se publicará la información enviada, estructurado

jerárquicamente mediante un separador de niveles “/”.
- Calidad de servicio (QoS): un valor que indica el modo de calidad de servicio solicitado
para el mensaje, supone diferentes niveles de garantía de entrega, a lo sumo una vez, al
menos una vez o una sola vez.
- Conservar último mensaje: Este indicador determina si el mensaje se guardará por el
broker con el topic especificado como el último valor correcto conocido. Los nuevos
clientes que se suscriban a ese topic recibirán el último mensaje retenido
inmediatamente después de suscribirse.
- Carga útil: Este es el mensaje a transmitir, el contenido real del mensaje a enviar,
pueden ser imágenes, textos en cualquier codificación, datos en binario,…
- Identificador de paquete: un identificador único entre el cliente y el broker para
identificar el mensaje. Sólo es relevante para QoS al menos una vez y solo una vez.
Establecer el valor de este identificador interno de MQTT es responsabilidad de la
implementación de la librería cliente y/o del broker.
- Duplicado: indica, que este mensaje es un duplicado y se vuelve a enviar porque el otro
extremo no confirmó el mensaje original. Sólo es relevante para QoS al menos una vez
y solo una vez. Establecer el valor de este identificador interno de MQTT es
responsabilidad de la implementación de la librería cliente y/o del broker.
MBIGDA_M8T2_160727
125
Una vez que el broker recibe el mensaje lo procesará y lo enviará a los clientes suscritos para el
topic, atendiendo a estos criterios establecidos en el mensaje: topic, QoS, retener último valor,
etc…
Cliente
Suscrito
Cliente Broker
PUBLISH
Cliente
Suscrito
Mensaje de public ació n MQTT
9.4.7. Suscripción a mensajes
Para que un cliente se suscriba a mensajes tiene que enviar un mensaje de suscripción al
broker, el mensaje de suscripción indicará un identificador de paquete y una lista de suscripciones
con la calidad de servicio deseada para cada suscripción.
- Identificador de paquete: un identificador único entre el cliente y el broker para

identificar el mensaje. Sólo es relevante para QoS al menos una vez y solo una vez.
Establecer el valor de este identificador interno de MQTT es responsabilidad de la
implementación de la librería cliente y/o del broker.
- Lista de suscripciones, donde cada suscripción es una pareja de topic y QoS. El topic
puede contener comodines. En caso de que existan suscripciones que se solapen, se
realizará la suscripción que tenga el nivel más alto de calidad de servicio.
MBIGDA_M8T2_160727
126
Una vez se produzca la suscripción el broker responderá con el mensaje SUBACK, que contendrá
el identificador de paquete para el control interno de la suscripción, y la lista de códigos de retorno,
uno para cada suscripción solicitada, indicando si la suscripción es fallida, o en caso de éxito el nivel
de servicio con el que finalmente se ha realizado la suscripción.
Lista de topics y QoS
SUBSCRIBE
Broker Cliente
SUBACK
Lista de resultados, fallos o QoSs
Mensaje de suscripción en MQTT y Mensaje de resultado
9.4.8. Cancelar una suscripción
Un cliente suscrito podrá cancelar la suscripción enviando un mensaje UNSUBSCRIBE para dejar
de recibir mensajes, en este tipo de mensaje el cliente indica la lista de topics a los que quiere dejar
de estar suscrito, no se indica QoS, solamente el topic. Al realizar la cancelación el broker
responderá con un mensaje UNSUBACK.
9.4.9. Buenas prácticas
MQTT presenta muchas formas de uso pero mientras algunas de ellas son válidas en cualquier
escenario, algunas de ellas presentan problemas en algunas circunstancias, es importante
contemplar el contexto y aplicar unas buenas prácticas:
- No usar el carácter “/” en la raíz del topic, crea un nivel innecesario. Es preferible usar
“hogar/temperatura” a “/hogar/temperatura/”.
- No usar el espacio en los nombres de los topic, aunque mqtt lo permite, el espacio
complica el uso y la monitorización desde programas externos.
- Usar topics cortos y concisos.
MBIGDA_M8T2_160727
127
- Usar solo caracteres ASCII imprimibles en los topic, el uso de caracteres especiales
complica el uso y la monitorización desde programas externos.
- Incorporar un identificador del cliente o el clientId en el topic, es útil para reforzar el
esquema de autorización o en general para desarrollar aplicaciones o monitorizar.
- No suscribirse a “#”, recibir todo lo que llega a MQTT puede ser un problema, a veces
es conveniente guardar todos los mensajes en una base de datos, sin embargo, a
menos que puedas garantizar que el cliente va a ser capaz de recibir todos los datos y
guardarlos, suscribirse a “#” podría causar un problema. Algunas implementaciones
MQTT disponen de plugins para realizar eficientemente esta tarea. En cualquier caso en
sistemas Big Data es posible tratar con esta situación, pero debe ser contemplada.
- La estructura jerárquica del topic debe contemplar que pueda extenderse en diferentes
niveles, es decir, que tenga un diseño capaz de ser evolucionado. Por ejemplo, si se está
diseñando un topic para un hogar, tener en cuenta que puede incorporarse un nuevo
sensor, un nuevo electrodoméstico, o incluso levantarse una nueva planta.
- Usar la jerarquía para especificar, en lugar de usar jerarquías genéricas o dejar los datos
sin especificar, por ejemplo es mala práctica llegar a “casa/salón” y hacer llegar todos
los dispositivos y mediciones a ese topic. Sería más adecuado llegar a cada magnitud
“casa/salón/sensorventana/temperatura”
9.4.10. MQTT y Websockets
Puede ser muy útil usar un servidor web para monitorizar o presentar la información MQTT, por
la facilidad y popularidad que presenta la tecnología web para construir interfaces de usuario. Por
esto es de especial interés en algunos casos facilitar la comunicación de la información entre un
bróker y un cliente web.
Websocket es un protocolo de red creado para proveer comunicación bidireccional entre un

servidor web y un cliente web (típicamente navegador). Es un protocolo estandarizado en 2011 que
soportan los navegadores “modernos”.
Actualmente desde un navegador no se puede realizar una conexión puramente MQTT ya que
no es posible abrir una conexión TCP de tipo raw. Esto está cambiando debido a un cambio en la
MBIGDA_M8T2_160727
128
API de sockets, pero de momento pocos navegadores presentan esta funcionalidad, por lo que se
necesita apoyarse en una capa de transporte que realice en ensamblado y desensamblado de
paquetes emulando la comunicación raw.
TCP TCP
TLS TLS
Websocket Websocket
Web Server
Aplicación
Bridge Navegador web
MQTT Librería js
MQTT
Websocket
Bróker
MQTT Aplicación
Comunicac ión MQTT Broker – Navegador. Posibles esquema s de conexión y protoco los.
Dado que Websocket proporciona el transporte entre navegador y servidor de forma

bidireccional, ordenada y sin pedida de paquetes, es posible encapsular los paquetes de MQTT
sobre el protocolo Websocket. Existen dos posibilidades para proporcionar esta funcionalidad: que
el bróker soporte Websocket de forma “nativa” o utilizar un servidor web con Websocket como
intermediario en la comunicación, la primera forma es más simple y transparente.
En el cliente es necesario introducir una librería Javascript que realice de puente entre
Websocket y MQTT para enviar y recibir los mensajes.
Al usar Websocket como capa de transporte para MQTT se podrá utilizar la versión segura sobre
TLS (Secure Websocket), incorporando seguridad en las comunicaciones.
MBIGDA_M8T2_160727
129
9.4.11. Implementaciones de MQTT
Existen múltiples implementaciones de MQTT, cada una puede o no resolver las diferentes
características del protocolo. En la siguiente tabla se muestra una comparativa de
implementaciones en función de las características que cubren. Una de las soluciones Open Source
más extendidas es Mosquitto.
plugin system
websockets
dynamic
cluster
bridge
topics
QoS 0
QoS 1
QoS 2
Server
$SYS
auth
SSL
mosquitto ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✘ ✔ ✔
RSMB ✔ ✔ ✔ ✔ ✔ ✔ ✘ ✔ ✘ ✘ ?
WebSphere MQ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ? ? ?
HiveMQ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
Apache Apollo ✔ ✔ ✔ ✔ ✘ ✘ ✔ ✔ ? ✔ ?
Apache ActiveMQ ✔ ✔ ✔ ✔ ✘ ✘ ✔ ✔ ✔ ✔ ✔
my-Channels ✔ ✔ ✔ § ✘ ✘ ✔ ✘ ? ? ?
Nirvana Messaging
RabbitMQ ✔ ✔ ✘ ✔ ✘ ✘ ✔ ✔ ? ? ?
Solace ✔ ✔ ✘ ✔ § ✔ ✔ ✔ ✔ ✔ ✘
MQTT.js ✔ ✔ ✔ § ✘ ✘ ✔ ✔ ✘ ✔ ✘
moquette ✔ ✔ ✔ ✔ ? ? ✔ ? rm ✔ ✘
mosca ✔ ✔ ✘ ✔ ? ? ? ? ✘ ✔ ✘
IBM MessageSight ✔ ✔ ✔ ✔ ✘ ✔ ✔ ✔ § ✔ ✘
2lemetry ✔ ✔ ✔ ✔ ✔ § ✔ ✔ ✔ ✔ ✘
GnatMQ ✔ ✔ ✔ ✔ ✘ ✘ ✘ ✔ ✘ ✘ ✘
JoramMQ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
ThingMQ ✔ ✔ ✔ ✔ ✔ ✘ ✔ ✔ ✔ ✔ ✔
VerneMQ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
emqttd ✔ ✔ ✔ ✔ ✔ ✔ ✔ ? ✔ ✔ ✔
Leyenda : ✔ soportado, ✘ no soportado,? no se ha podido comprobar, § con limitaciones, rm en la hoja de ruta
MBIGDA_M8T2_160727
130
Las implementaciones presentan algunas consideraciones especiales:
- MQTT.js y my-Channels Nirvana Messaging aceptan peticiones con usuario y clave pero
no realiza actualmente la autenticación.
- IBM MessageSight permite un modo de alta disponibilidad que provee redundancia
similar a un sistema en clúster, pero no realiza balanceo de carga.
- 2lemetry utiliza dominos en los topic, el primer segmento del topic es el nombre de
dominio. El topic $SYS está bajo el dominio (p.e. “com.example/$SYS/#”)
- Solace provee una solución propietaria de bridge entre brokers.
9.4.12. Ejemplo de uso de MQTT
Un ejemplo de instalación y uso de mosquitto en Servidor cloud Ubuntu (12.04 LTS) en este
ejemplo se muestra el envió desde un cliente de consola de un mensaje.
a) Iniciar sesión reemplazando AwsKeyPair.pem con las claves de tu servidor y 0.0.0.0 con la IP.
ssh -i AwsKeyPair.pem ubuntu@0.0.0.0
b) Instalar mosquito en el servidor
sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa
sudo apt-get update
sudo apt-get install mosquito
sudo apt-get install mosquitto-clients
c) Iniciar el servidor mosquitto
mosquitto
d) Iniciar un cliente consumidor de un topic en un nuevo terminal ssh
mosquitto_sub -d -t hola/mundo
e) Iniciar un cliente productor de mensajes para el topic en un nuevo terminal ssh
MBIGDA_M8T2_160727
131
mosquitto_pub -d -t hola/mundo -m "Este es mi primer mensaje"
f) El mensaje enviado desde el terminal del publicador aparecerá en el suscriptor.
9.5. MQTT-SN
MQTT-SN es una variante del protocolo MQTT surgida para dar respuesta a dispositivos y redes
LSNN, con pérdida de paquetes y pocas capacidades. Si bien MQTT contempla esta situación como
un principio en su especificación, no establece unos criterios objetivos ni subjetivos para ello, solo
es un principio de diseño. MQTT-SN cubre las necesidades simplificando el protocolo para trabajar
en redes de sensores. Como bróker se usa un bróker MQTT al que se conectan pasarelas que
realizan la traducción MQTT-SN a MQTT.
9.5.1. Dispositivos en redes MQTT-SN
Esquema general de arquitec tura MQTT -SN
Existen tres tipos de nodo MQTT-SN: Clientes (Client), Pasarelas (GW) y Enrutadores (Fowarder).
Los clientes se conectan a un servidor MQTT a través de una pasarela MQTT-SN GW usando el
protocolo MQTT-SN. La pasarela puede o no estar integrada directamente en un broker MQTT (no
SN). En caso de no estar integrada, el protocolo MQTT se usa entre la pasarela y el broker MQTT. La
principal función de la pasarela es la traducción entre MQTT-SN y MQTT.
MBIGDA_M8T2_160727
132
Los clientes MQTT-SN pueden acceder al MQTT-GW a través de un enrutador (Fowarder) que
encapsula las tramas MQTT-SN que recibe de la zona wireless lo reenvía al Gateway, y realiza la
misma tarea en sentido contrario, sin modificar el contenido de la trama.
Existen dos modos de funcionamiento para las pasarelas MQTT-SN, modo transparente y modo
agregación:
- En modo transparente cada cliente establece y mantiene una conexión con el broker,
por tanto habrá tantas conexiones en el broker como clientes. La traducción de
protocolo (MQTT-SN <-> MQTT) será meramente sintáctica. Dado que la conexión es
entre los dos extremos, clientes y broker, todas las funciones y características del
broker serán proporcionadas a los clientes. Si bien la implementación de la pasarela en
modo transparente es más simple, requiere que el servidor mantenga tantas
conexiones como clientes, lo que puede resultar en un problema de escalabilidad o
rendimiento.
- En modo agregación se mantiene una única conexión entre la pasarela y el broker. El
intercambio de mensajes con los clientes finaliza en la pasarela que decide la
información que se enviará al broker. Las pasarelas de agregación actúan como un
concentrador, y el número de conexiones con el broker se reducen, lo que es útil en
redes WSN con muchos dispositivos.
Pasarelas MQTT -SN en modo T ransparente y Agregación
MBIGDA_M8T2_160727
133
9.5.2. Estructura de información en MQTT-SN
Un mensaje MQTT-SN consiste en dos campos: una cabecera y una parte variable. La cabecera
está presente en todo mensaje y dependiendo del tipo de mensaje tendrá 2 o 4 octetos, en cambio
la parte variable estará o no presente, y su longitud dependerá del tipo de mensaje indicado en la
cabecera.
Cabecera Parte variable

2 ó 4 octetos N octetos
La cabecera tiene un número long de uno o tres octetos, e indica el número de octetos total del
mensaje, incluida la cabecera. Si el primer octeto es 0x01entonces la longitud del campo es de 3
octetos y representa un long codificado mediante MSB (byte más significante primero), si no, el
primer octeto representa la longitud.
Longitud Tipo de mensaje

1 ó 3 octetos 1 octetos
Es importante tener en cuenta que por los objetivos de ser un protocolo de “bajo peso“, MQTT-
SN no realiza fragmentación ni re-ensamblado de paquetes, por tanto, el tamaño máximo de un
mensaje que puede usar en una red está limitado por el tamaño máximo de un paquete en la red, y
no por el valor máximo representable en el campo longitud codificado en la cabecera del mensaje
MQTT-SN.
MQTT-SN permite que dispositivos con restricciones de consumo optimicen la batería

quedando “dormidos”. Los Gateway no disponen de este modo de funcionamiento. Cuando un
mensaje es enviado a un nodo que está dormido, este será almacenado en el Gateway hasta que
pueda ser entregado cuando el nodo vuelva a conectarse.
En cuanto a la compatibilidad con redes ZigBee hay dos aspectos importantes a considerar: los
nodos Gateway MQTT-SN deben desplegarse en nodos coordinadores, en nodos en modo “router
always-on” para que estén siempre disponibles para recibir mensajes. Por otra parte los mensajes
están limitados a la capacidad máxima de ZigBee que es de 60 octetos.
MBIGDA_M8T2_160727
134
Existen varias implementaciones de Broker MQTT cada una de ellas presenta variedades y
funcionalidades adicionales:
Broker MQTT
EMQTTD Broker clusterizable, escalable masivamente, Opensource,
versión de protocolo MQTT V3.1/3.1.1 escrito en
Erlang/OTP soporta WebSocket, STOMP, StockJS, CoAp y
MQTT-SN simultáneamente.
ActiveMQ Sistema de mensajería OpenSource de la fundación
Apache con plugin para MQTT.
Apollo Nuevo sistema de mensajería Apache construido sobre las
bases de ActiveMQ que soporta MQTT mediante plugin.
HiveMQ Solución propietaria escalable y segura.
IBM MessageSight IBM Soluciones propietarias de IBM para MQTT
Websphere MQ Telemetry
JoramMQ Proporciona MQTT sobre el sistema de mensajería Open
Source JORAM escrito en Java basado en ActiveMQ.
Mosquito Servidor opensource MQTT con clientes C,C++, Python y
Javascript
RabbitMQ Broker AMQP de SpringSource que tiene un MQTT plugin.
Solace Message Routers Sistema de mensajería propietario con funcionalidades
para MQTT
MQTT.js Servidor MQTT node.js
Brokers MQTT
Por otra parte el uso de un protocolo estandarizado permite independizar las tecnologías o
implementaciones utilizadas en consumidores, productores y broker, algunos clientes son:
Clientes MQTT
Arduino client for MQTT Cliente para Arduino
NanodeMQTT Cliente para placa Nanode (dispositivo parecido a Arduino).
Eclipse Paho Implementaciones en diferentes lenguajes de clientes
OpenSource MQTT y MQTT-SN.
MeQanTT Proyecto que muestra las bases de un cliente MQTT, de
carácter formativo, no es para ser usado en producción.
Mosquito javascript websocket Cliente Javascript experimental de Mosquito
client
Clientes MQTT p ara implementar Productores y Consumidor es
Como utilidades o herramientas de trabajo se pueden emplear:
MBIGDA_M8T2_160727
135
Herramientas MQTT
Mqtt.io Cliente web para cualquier Broker MQTT público.
Eclipse Paho Vista de eclipse para interactuar con un broker MQTT.
MQTT/HTTP Bridge Pasarela que expone MQTT bajo HTTP
MQTT/HTTP Bridge Sensemote Pasarela que expone MQTT bajo HTTP REST
MQTT Over Websockets Experimental de proyecto Mosquito
Herramientas MQTT
9.6. AQMP
AQMP es un estándar que define un protocolo de comunicaciones, la comunicación se basa en
colas de mensajería de publicación y suscripción sobre TCP/IP. El protocolo fue orientado desde sus
inicios hacia el sector financiero, y lograr una gran interoperabilidad. Se define como protocolo a
nivel de cable: El estándar de AQMP permite alta interoperabilidad al transportar entre las
aplicaciones octetos de bytes. Cualquier programa que pueda crear e interpretar mensajes
conforme a este formato de datos puede interoperar con cualquier otra herramienta que cumpla
con este protocolo, independientemente del lenguaje de implementación.
Está muy extendida la versión 0.91 pero ha sido estandarizada una nueva versión 1.0 que es
estándar internacional ISO/IEC 19464 promovido por OASIS. Es un protocolo completamente
abierto.
En AMPQ intervienen varios actores conforme a los siguientes conceptos:
- El bróker de mensajes es un servidor al que los clientes se conectan usando el

protocolo (algunas implementaciones de bróker funcionan de forma distribuida, en
varios servidores).
- El intercambiador es una estructura lógica en el bróker que se encarga de distribuir los
mensajes a las diferentes colas que pueden crearse para un intercambio de mensajes.
MBIGDA_M8T2_160727
136
TCP TCP
Intercambiador Cola
Cliente Cliente
BROKER
Esquema general de AQMP
- Los clientes son aplicaciones que pueden conectarse al bróker, en un esquema con
autenticación por nombre de usuario y clave.
- La conexión se realiza de forma permanente sobre un protocolo de transporte como
TCP, una conexión está ligada a un cliente.
- Las conexiones se aprovechan multiplexando en ella la información a transmitir a un
cliente, para esto se define y se maneja en el protocolo el concepto de canal, de
manera que, en una misma conexión física puede circular información de diferentes
canales lógicos.
- Una vez se establece la conexión, dentro de un canal, se crean las estructuras lógicas o
entidades necesarias para el comportamiento deseado según las opciones que ofrece
AMQP.
9.6.1. Broker
El bróker AQMP es el software que, de forma centralizada o distribuida (en una máquina o
varias), proporciona un servicio por el que recibe mensajes enviados por programas software y los
entrega a los programas software destinatarios que se han suscrito para recibirlos.
9.6.2. Intercambiadores
Un intercambiador es un enrutador que aplicará unas reglas para enviar los mensajes a las
colas, donde los mensajes esperarán para ser consumidos por los clientes. Los clientes envían los
MBIGDA_M8T2_160727
137
mensajes a un intercambiador en un bróker, este decidirá a que colas debe enviarlo para resolver
las suscripciones.
Para decidir el enrutamiento de los mensajes a las colas, el intercambiador tiene varios modos
de funcionamiento:
Modo fanout: se ignora el valor de la clave de enrutamiento de manera que todo mensaje es
enviado a todas las colas, sin aplicar distinción.
Ejemplo de enrutamiento Fan out, los mensajes se envían a todas las co las
Modo Intercambio directo: el sistema enviará únicamente los mensajes a las colas cuyo
nombre esté enlazado mediante una regla al nombre indicado en el campo de enrutamiento del
mensaje. Una cola puede ser receptora de mensajes con diferentes valores si se definen varias
entradas en la tabla de enrutamiento para la misma cola, y un mensaje puede ser dirigido también
a varias colas si se definen varias salidas en la tabla de enrutamiento para el mismo mensaje.
Ejemplo de enrutamiento dire cto en e l que se envían mensajes a diferentes co las, los men sajes info y warn ing van a una
cola, mientras que los mensa j es de error van a las dos c olas .
9.6.3. Colas
Una cola consistirá en una lista de mensajes que se encola en el bróker bajo un nombre
identificador de la cola, los datos se almacenan en orden de llegada hasta ser entregados a los
MBIGDA_M8T2_160727
138
clientes suscritos formando una cola FIFO, en algunos casos el orden podría no garantizarse
dependiendo de la implementación y la situación (por ejemplo en algunas recuperaciones ante una
caída del sistema).
Entre las propiedades al crear una cola, y en consecuencia formas de uso, están:
Un intercambiador alternativo, que se usará cuando un mensaje sea rechazado por un

subscriptor o quede huérfano debido a la destrucción de la cola. Estos mensajes serán reenviados al
intercambiador alternativo, que se podrá usar para repescar o tratar los mensajes no procesados.
Persistencia de la cola, que permite indicar si la cola será persistente ante una caída del
servidor. Dependiendo de la naturaleza de la información y de su uso, puede ser innecesario un
sistema de persistencia de información en disco o por lo contrario muy necesario, AQMP permite
ambos modos de funcionamiento.
Las colas pueden ser usadas por varios clientes o ser de uso exclusivo de un único cliente.
Además de estas propiedades, una cola puede ser eliminada de forma automática cuando no
queden suscripciones o se cierren todas las sesiones.
Una forma de funcionamiento consistirá en hacer llegar todos los mensajes de una cola a todos
los consumidores, otra en enviar los mensajes en round-robin a diferentes consumidores, este
modo de funcionamiento es muy útil para distribuir trabajos o realizar equilibrios de carga.
9.6.4. Mensajes
Los mensajes no tienen nombre y son enviados para publicarse a un intercambiador. Están
compuestos de un encabezamiento y un cuerpo de mensaje con el contenido. AQMP proporciona
en su estructura de mensaje la capacidad de proporcionar información relativa al mensaje,
mientras que el cuerpo contiene simplemente datos, que el protocolo no procesará (agnóstico), el
mensaje consiste en una estructura que permite incorporar información acerca del mensaje.
MBIGDA_M8T2_160727
139
El mensaje se compone de dos partes annotated message y bare message, Annotated message
es el mensaje que envía el emisor y que encapsula al bare message, Bare Message es el mensaje
que obtiene el cliente, y obviamente encapsula los datos a transmitir en el mensaje.
Estructura de un mensaje AQ MP
Header o Cabecera del mensaje: Contiene los campos necesarios para el protocolo AQMP:
- clave de enrutamiento (routing-key): este campo se usa de diferentes formas

dependiendo del tipo de intercambiador.
- inmediato: el mensaje será tratado como imposible de enrutar si al menos una de las
colas que deberían recibir el mensaje no tiene ninguna subscripción.
- modo de entrega: indica si un mensaje usará persistencia. Sólo para este tipo de
mensajes el bróker puede hacer un intento (best-effort, se puede demorar la entrega y
hacerse sin confirmar) para impedir la pérdida del mensaje antes de que sea
consumido. Si hay alguna incertidumbre del lado del bróker sobre la recepción correcta
del mensaje (por ejemplo en caso de errores), puede ocurrir que se entregue el mismo
mensaje más de una vez. Los modos de entrega no persistentes no muestran este tipo
de comportamiento.
- prioridad: un indicador (en el rango entre 0 y 9) de que un mensaje tiene prioridad
sobre otros en caso de usar prioridad la cola se comporta como una FIFO con
prioridades.
- vencimiento: la duración en milisegundos antes de que el bróker trate el mensaje como
imposible de entregar, es un valor TTL (tiempo de vida).
MBIGDA_M8T2_160727
140
Delivery-annotations o anotaciones de entrega: En esta sección, opcional, se indican

propiedades no estándar específicas para la entrega del mensaje. Es información que se transfiere
entre el emisor y el receptor de la comunicación. Las anotaciones pueden ser específicas para una
sola implementación, o comunes para varias implementaciones. Estas anotaciones las usará el
implementador del sistema de mensajería y no los implementadores de emisores o clientes. Su
utilidad es muy amplia puesto que permite añadir propiedades para definir comportamientos del
protocolo diferentes al estándar, o solucionar problemas que el estándar no soporte.
Message-annotations: Las anotaciones del mensaje son anotaciones que trascienden más allá
del extremo de la conexión, y deben ser propagada por toda la infraestructura hasta el cliente, pero
no pertenece a la aplicación su información es igualmente para la implementación del protocolo,
igualmente permite personalizar el protocolo o transmitir información adicional para poder
proporcionar comportamientos personalizados.
Properties: Son un conjunto de propiedades estándar del mensaje. Esta sección pertenece al
“Bare Message”, por tanto será retransmitida por todo intermediario, de forma inalterada, la
información estará disponible para el cliente de aplicación al pertenecer al “Bare Message”.
Application-properties: las propiedades de aplicación son un mecanismo flexible para que el

usuario pueda introducir propiedades en el mensaje que serán recibidas por el cliente, esto significa
que podrá introducir información para interpretar el contenido del mensaje, por ejemplo si acerca
del formato del contenido (XML, JSON, texto, video,…) o propiedades específicas de la aplicación
que este construyendo (metadatos).
DATA: la sección de datos contiene una de las siguientes tres posibles secciones:
- Un conjunto de datos binarios opacos para el protocolo.

- Una lista de valores.
- Un valor.
Footer: una serie de información que podrá ser usada por el protocolo una vez el mensaje ha
sido obtenido: hash, firmas, datos de encriptación,…
MBIGDA_M8T2_160727
141
9.6.5. Implementaciones Open Source más extendidas de AQMP
- RabbitMQ está escrito en Erlang, y es uno de los sistemas más ampliamente utilizado.
RabbitMQ es fácil de usar y conveniente para la escala cloud. La aplicación es apoyada
por la mayoría de los principales sistemas operativos y plataformas, y es de código
abierto bajo la licencia pública de Mozilla. Está diseñado para la mensajería empresarial
y presta servicios de mensajería a través de adaptadores, SMTP, STOMP, HTTP y
mensajería web ligera. Cuenta con una próspera comunidad de usuarios activos y
colaboradores, y proporciona una gama completa de apoyo a la ejecución comercial a
través de la división de SpringSource Vmware. No hay limitación de un mensaje en el
tiempo RabbitMQ que le permite enviar mensajes dos veces para los consumidores y a
los consumidores obtener múltiples mutuamente diferentes mensajes a la vez.
- OpenAMQ: Incluye WireAPI que cuenta con herramientas de administración remotas,
federación instantánea, conmutación por error de la línea, protección contra los
clientes lentos y muchas otras características. No tiene una amplia comunidad de
desarrollo.
- StormMQ proporciona un middleware orientado a mensajes alojados en las
instalaciones o como solución en la nube. Se proporciona la plataforma abierta y
segura, con la protección jurídica necesaria para los datos transferidos a través de la
nube. La solución funciona con clientes de RabbitMQ y Apache Qpid, y también a través
de código abierto con el código bajo licencia pública de Mozilla. El software está escrito
en Java.
- Apache Qpid: proporciona APIS C ++, JMS, Java, Python, .Net y Ruby. Todos los datos de
la cola y los metadatos se replica a través de los nodos que forman un clúster. QPID es
un tipo de proyecto de Apache, que tiene muchos clientes y dos bróker que soportan
versiones de estándares AMQP de terceros.
- Red Hat Enterprise MRG ofrece un buen número de características que incluyen la
gestión completa del sistema, clustering activo a través de Apache Qpid, federación, y
el apoyo a la consola web. También está disponible en la versión más reciente de
Fedora como Infraestructura AMQP. Su versión incluye QPID de Apache, que ayuda a
MBIGDA_M8T2_160727
142
mejorar su sistema de mensajería, su rendimiento y también proporciona soporte para

la tecnología tradicional de SOA. Proporciona la infraestructura de TI de la próxima
generación de mensajería y ofrece más de rendimiento, durabilidad, la
interoperabilidad y un procesamiento rápido. Red Hat es compatible con la mensajería
de archivos de gran tamaño, así como la programación distribuida, computación de alto
rendimiento y gestión de carga de trabajo distribuida.
9.7. Smart Energy Protocol (SEP2.0)

El protocolo Smart Energy Profile 2.0 se desarrolla para crear un protocolo estándar e
interoperable que conecta dispositivos inteligentes de energía en el hogar. El estándar en sí está
diseñado para funcionar sobre TCP / IP y, por tanto, es agnóstico al control de acceso al medio
(MAC) y la capa física (PHY). Una coalición de alianzas compuesta por Wi-Fi Alliance, ZigBee
Alliance, HomePlug Alliance y HomeGrid Alliance desarrolla el estándar.
SEP es un ejemplo de protocolo específico cuya función es la gestión energética en el hogar

inteligente integrada en una red de distribución inteligente de energía.
El propósito del protocolo es el consumo inteligente de la energía por parte de los dispositivos
de un hogar, atendiendo a la producción y a la demanda de energía existente, pretendiendo que
estos consuman energía de una forma más inteligente al estar interconectados e intercambiando
información con la red de distribución y el usuario. SEP2.0 pretende que los dispositivos de forma
nativa (principalmente electrodomésticos) incluyan este protocolo y con sus funciones para
proporcionar y tomar la información necesaria para desarrollar un comportamiento inteligente
respecto del consumo de energía.
MBIGDA_M8T2_160727
143
SEP2.0 en la p ila de proto colo s
Respecto al modelo de red OSI, el Energy Smart Profile 2.0 es un protocolo de aplicación que se
construye utilizando el modelo de Internet de pila de cuatro capas. Esta especificación define la
capa de "aplicación" con servicios REST a través de HTTP sobre TCP/IP. Dependiendo de la capa
física que se use (por ejemplo, 802.15.4, 802.11, 1901) una variedad de protocolos en las capas
inferiores pueden estar implicados en la construcción de una solución completa SEP2.0. El
protocolo SEP2.0 define los mecanismos para el intercambio de mensajes de aplicación, y los
elementos de seguridad utilizados para proteger los mensajes de aplicación.
El perfil de energía inteligente está diseñado para implementar una arquitectura REST. Está
construido en torno a las operaciones básicas GET, HEAD, PUT, POST y DELETE (tal como se utiliza
MBIGDA_M8T2_160727
144
en REST), con la adición de un mecanismo de suscripción de peso ligero. Cualquier protocolo de

aplicación que puede poner en práctica un conjunto de comandos REST podría ser utilizado con la
SEP 2.0, pero HTTP es una base requerida para la interoperabilidad en las implementaciones de
SEP2.0.
El contenido de los mensajes intercambiados se expresa en XML o EXI (codificación de XML para
reducir el tamaño del documento).
El protocolo hace hincapié en proveer mecanismos de seguridad sobre TLS a nivel de aplicación,
proporcionando una solución para la autenticación y la autorización, sobre dispositivos y servicios,
atendiendo a perfiles y lista de control de acceso (ACL). Proporciona un perfil por defecto de
atributos y valores para políticas de seguridad, que incluye aspectos muy globales como
mensajería, descarga, medición, facturación, prepago, suscripción,…
El protocolo especifica métodos basados en DNS para el descubrimiento de servicios,

localización de recursos, y resolución de nombre de host a dirección IP. Un servicio se define como
una instancia de aplicación identificada de forma única por {host, puerto, protocolo}, donde el
protocolo en este caso es-SEP-2 más sus enlaces de transporte subyacentes (por ejemplo, HTTP (S)
/ TCP / IP). El descubrimiento de servicios basado en DNS (DNS-SD) es un uso convencional de la
sintaxis de nombres DNS y mensajes y formatos de registro (PTR, SRV, TXT) para descubrir
instancias de un servicio determinado dentro de un dominio dado. En SEP2.0, DNS-SD se utiliza para
describir la localización de los conjuntos de funciones y grupos de recursos suministrados por un
host, puerto y protocolo, junto con los detalles adicionales proporcionados por los servidores.
El dispositivo contiene un conjunto de funciones proporcionadas por SEP2.0 de carácter general

para la gestión, una vez resueltos los problemas de seguridad, de registro, etc. las funcionalidades
se centran en el consumo energético, proporcionando funcionalidades y mensajes en dos grupos
principales: orientados a un propósito común de la gestión del dispositivo y orientados al propósito
concreto de la gestión energética.
MBIGDA_M8T2_160727
145
Servicios orientados a la gestión del dispositivo:
- Gestión de tiempo / hora etc.

- Información del dispositivo
- Estado de alimentación de energía
- Estado de red de datos
- Eventos de registro de trazas (logevents)
- Configuración (servicios para configuración del dispositivo)
- Descarga de ficheros del dispositivo
Servicios orientados a la gestión energética:
- Funcionalidad común: destaca el concepto de aleatorización que pretende evitar que

los dispositivos consuman energía al mismo tiempo provocando picos de demanda,
aplanando la curva de consumo.
- Respuesta a la demanda y control de carga: incluye funcionalidades para la gestión
coordinada de los dispositivos, de manera que se pueda interactuar con estos para
controlar la carga y la demanda de energía, el protocolo contempla mensajes para la
programación horaria de actividades.
- Medición: Servicios para conocer los valores medidos de los dispositivos en relación al
consumo de energía.
- Tarificación: Servicios para indicar a los dispositivos los precios de la energía, permite
varios modelos de tarificación y combinaciones de estos.
- Mensajes: servicios para el intercambio de mensajes de texto, como complemento al
protocolo.
- Facturación: servicios que se utilizan para apoyar las funciones relacionadas con la
facturación. El conjunto de funciones de facturación proporciona el consumo o los
costes, las estimaciones de consumo futuro, y / o el consumo histórico de un proveedor
de servicio a un dispositivo final. Además del consumo y los costes que se calcularían
por los sistemas de back-end y se compartirían con los dispositivos finales, la
facturación también proporciona un mecanismo para que el servicio proveedor para
MBIGDA_M8T2_160727
146
empujar hacia abajo los objetivos. Un objetivo podría ser un porcentaje o valor fijo de la
reducción de factura - posiblemente elegido por el consumidor - para lograrse dentro
de un marco de tiempo definido.
- Prepago: El conjunto de funciones de Prepago define un mecanismo para la distribución
condicional de los servicios basados en el crédito pendiente o débito. Proporciona una
interfaz para clientes con privilegios adecuados para ver, actualizar o actuar sobre la
información del saldo de la cuenta y decidir realizar o no actividades.
- Reserva de energía: Este conjunto de funciones proporciona una interfaz para el
intercambio de energía (por ejemplo, carga o descarga) mediante eventos de reserva.
Los dispositivos cliente de este conjunto de funciones incluyen dispositivos de
almacenamiento de energía distribuida, enchufes de vehículos eléctricos, y otras cargas
que consuman mucha energía. Permiten la programación de los períodos de alta
demanda como por ejemplo durante las operaciones de carga rápida, para que
funcionen en diferentes momentos y evitar la gran demanda agregada. Por lo general,
las tarifas de energía tienen multas, cargos, o clases de clientes por diferentes niveles
de demanda, por lo que es generalmente menos costoso mantener la máxima demanda
lo más bajo posible. Empresas de distribución pueden apoyar esta función ajustada
para minimizar la demanda máxima en todo el sistema de distribución.
- Recursos distribuidos: Funcionalidades para gestionar las situaciones en que la energía
se almacena y se consume a posteriori, por ejemplo vehículo eléctrico, baterías en el
hogar, etc. estas funcionalidades proporcionan mecanismos para la gestión de distribuir
y almacenar la energía en el destino para su consumo posterior.
- Mirror de medición: Funcionalidades para dispositivos con capacidades restringidas tal
que puedan enviar las mediciones y no tengan que almacenarlas localmente.
9.8. Universal Plug and Play (UPnP)

Universal Plug and Play (UPnP) es un conjunto de protocolos de comunicación que permite a
periféricos en red, como ordenadores personales, impresoras, pasarelas de Internet, puntos de
acceso Wi-Fi y dispositivos móviles, descubrir de manera transparente la presencia de otros
dispositivos en la red y establecer servicios de red de comunicación, compartición de datos y
MBIGDA_M8T2_160727
147
entretenimiento. UPnP está diseñado principalmente para redes de hogar sin dispositivos del
ámbito empresarial. Está muy orientado a la actuación o control sobre los dispositivos de forma
remota.
SALÓN HABITACIÓN
PUNTO DE CONTROL
VCR (TV-VIDEO DEVICE)
Internet
OFICINA
Ejemplo de uso de UPnP para controlar dispos itivos del hog ar de forma remota
El Foro UPnP está compuesto por más de ochocientos fabricantes de diferentes ámbitos que
van desde la Electrónica de consumo hasta las redes de ordenadores. Los dispositivos UPnP son
"plug-and-play" en el sentido de que una vez conectados a una red son capaces de establecer de
manera automática comunicaciones con otros dispositivos.
MBIGDA_M8T2_160727
148
Pila de protoco lo UPnP
9.8.1. Direccionamiento
La base de UPnP es el direccionamiento IP: cada dispositivo debe implementar un cliente DHCP
y buscará un servidor DHCP en cuanto se conecte por primera vez a la red. Si no hay ningún
servidor DHCP disponible, el dispositivo debe asignarse a sí mismo una dirección.
El proceso por el cual un dispositivo UPnP se auto-asigna una dirección se denomina AutoIP. En
la versión 1.0 de la especificación de la arquitectura UPnP, se incluye textualmente la propia
especificación de AutoIP; en versión 1.1, la especificación de AutoIP referencia el RFC
3927 de IETF RFC 3927.
Si durante la transacción DHCP, el dispositivo obtiene un nombre de dominio, por ejemplo,

mediante un servidor DNS o mediante DNS forwarding, el dispositivo deberá emplear dicho nombre
en las operaciones de red posteriores; en otro caso, el dispositivo deberá utilizar su propia
dirección IP.
MBIGDA_M8T2_160727
149
Dispositivo Busca servidor DHCP en la red
Cliente DHCP
DHCP asigna IP y/o Nombre de dominio
Obtener IP
Auto IP Si el dispositivo no obtiene IP o nombre

de dominio mediante DHCP se auto-
asigna una IP
Obtención de IP por e l d ispositivo en uPnP
9.8.2. Descubrimiento
Una vez que un dispositivo ha establecido una dirección IP, el siguiente paso en UPnP es el
descubrimiento. El protocolo de descubrimiento de UPnP se denomina Simple Service Discovery
Protocol (SSDP). SSDP permite a los dispositivos que acaban de añadirse a una red anunciar sus
servicios a los puntos de control presentes en la red. Asimismo, cuando se añade un punto de
control a la red, SSDP le permite buscar los dispositivos que le interese controlar.
El intercambio fundamental en ambos casos es un mensaje de descubrimiento que contiene

datos básicos del dispositivo o uno de sus servicios, por ejemplo, su tipo, identificador y un enlace
una URL en la que obtener información más detallada.
MBIGDA_M8T2_160727
150
Dispositivo Punto de control uPnP

Cliente SSDP Notifica los servicios que ofrece, el
punto de control sabrá qué dispositivos
hay en la red.
Anunciar servicios
Búsqueda de dispositivos que ofrecen

un servicio, el punto de control podrá
encontrar dispositivos que provean un
servicio determinado.
Notificación de servicios a un punto de control uPnP
9.8.3. Descripción
Después de que un punto de control haya descubierto un dispositivo, todavía dispone de muy
poca información acerca de él. El punto de control debe obtener la descripción del dispositivo
desde la URL proporcionada por el dispositivo en el mensaje de descubrimiento para conocer mejor
sus capacidades y poder interactuar con él.
La descripción de un dispositivo se codifica en XML e incluye información específica del

fabricante como nombre de modelo y número, número de serie, nombre de fabricante, URLs a
sitios web específicos de fabricante, etc. La descripción también incluye una lista de dispositivos o
servicios embebidos, así como URLs de control, manejo de eventos y presentación.
Para cada servicio, la descripción incluye una lista de los comandos, o acciones, a las que
responderá el servicio, y parámetros, o argumentos, de cada acción; la descripción de un servicio
también incluye una lista de variables; estas variables modelan el estado del servicio en tiempo de
ejecución, y se describen en términos de su tipo de datos, rango y las características de sus eventos.
MBIGDA_M8T2_160727
151
Interroga al dispositivo para obtener la

Cliente SSDP lista de servicios (XML) que ofrece,
comandos, parámetros, argumentos,
etc.
Descripción de
servicios
Descripción de servic ios
9.8.4. Control
Al obtener la descripción del dispositivo, el punto de control puede enviar acciones a los
servicios de un dispositivo. Para ello, el punto de control envía un mensaje de control apropiado a
la URL de control del servicio (proporcionada en la descripción del dispositivo). Los mensajes de
control también se codifican en XML mediante Simple Object Access Protocol (SOAP).
El servicio responderá con un mensaje de control con los resultados de la acción de forma
similar a una llamada a una función. Los efectos de la acción, en caso de existir, se modelarán
mediante cambios en las variables que describen el estado del servicio.
MBIGDA_M8T2_160727
152
Envío de comandos de control (XML

Control SOAP)
Server
Actuación
El API de contro l permite la a ctuación sobre el dispos itivo
9.8.5. Notificación de eventos
Una capacidad adicional de UPnP es la notificación de eventos. El protocolo de notificación de

eventos definido en la arquitectura UPnP se conoce como General Event Notification Architecture
(GENA).
La descripción UPnP de un servicio incluye una lista de las acciones a las que el servicio
responde y otra con las variables que modelan el estado del servicio en tiempo de ejecución. El
servicio enviará actualizaciones cuando cambien dichas variables a cualquier punto de control que
se haya suscrito para recibir dicha información.
El servicio publica actualizaciones enviando mensajes codificados en XML de evento que

contiene los nombres de una o más variables de estado y el valor actual de dichas variables.
Cuando un punto de control se suscribe por primera vez se le envía un mensaje especial de
eventos; que contiene el nombre y los valores de todas las variables que generan eventos y permite
al suscriptor conocer el estado actual del servicio.
La notificación de eventos UPnP se ha diseñado para mantener a todos los puntos de control
informados por igual sobre los efectos de cualquier acción, de este modo se permite soportar
escenarios con múltiples puntos de control. Por tanto, los mensajes de eventos se envían a todos
MBIGDA_M8T2_160727
153
los suscriptores, los suscriptores reciben mensajes para todas las variables que han cambiado a las
que se han suscrito y los mensajes se envían sin importar el motivo que modificó la variable de
estado (tanto en respuesta a una petición, como por el cambio del estado interno del servicio).
Dispositivo Punto de control UPnP
Suscripción a eventos de servicio.

Publicar
mensajes Los cambios de valor en variables del
dispositivo se reciben en XML
Notificación de
eventos
Punto de control UPnP
Suscripción a eventos de servicio.
Los cambios de valor en variables del

dispositivo se reciben en XML
Los puntos de contro l se mant ienen in formados del estado del dispos itivo median te una suscripción a eventos.
9.8.6. Presentación
El último paso en UPnP es la presentación. Si un dispositivo tiene una URL de presentación,

entonces el punto de control podrá obtener una página desde dicha URL, mostrarla en un
navegador y, dependiendo de las características de la página, permitirá al usuario controlar el
dispositivo y/o consultar su estado. El grado de control que se puede obtener depende en gran
medida del dispositivo y de la interactividad presente en la interfaz de presentación.
MBIGDA_M8T2_160727
154
Dispositivo Punto de control UPnP
Obtiene la aplicación HTML, el usuario

Servidor podrá interactuar con ella.
HTTP
Aplicación HTML de
presentación
Punto de control UPnP
Obtiene la aplicación HTML, el usuario

podrá interactuar con ella.
El dispos it ivo puede implementar presentac ión a través de un inter faz de usuar io HTML
Las arquitecturas embebidas usualmente no utilizan directamente un desarrollo sobre el

protocolo sino que disponen de un framework o arquitectura de propósito general a la que se dota
de posibilidades de conectividad UPnP, en el caso de dispositivos embebidos es muy habitual el uso
de arquitecturas OGSi. Un proyecto de la fundación Apache felix (felix.apache.org) permite el
desarrollo de estos dispositivos con conectividad UPnP bajo una arquitectura OGSi.
Control Point Application Device Application
API API
SSDP GENA SOAP XML SSDP GENA SOAP XML WEB

PARSE PARSE SERVER
HTTP HTTP
UDP TCP UDP TCP
IP IP
MBIGDA_M8T2_160727
155
Implementaciones de un d isp osit ivo y un pun to de c ontro l, la d ifer enc ia pr inc ipa l en cua nto a c omponentes está en el
servidor web para servir las a plic aciones de presentación e n el d ispositivo.
9.9. OPC OLE FOR PROTCOLS

OPC aparece en 1996 como una solución para intercomunicar sistemas de información en
entornos industriales. Unifica multitud de protocolos y sistemas industriales en un servidor que
ofrece unos servicios y acceso a estos.
OPC estandarizó los sistemas industriales, permitiendo construir aplicaciones que podían usarse
en diferentes sistemas o industrias, bajo el sistema OPC puede haber múltiples protocolos,
específicos de cada sistema o dispositivo.
El sistema OPC es un sistema local centralizado en un servidor que constituye una arquitectura
cliente-servidor, en la que se accede a datos de diferentes sistemas o servicios subyacentes.
Las aplicaciones pueden acceder a varios servidores OPC y los servidores OPC albergan los
drivers para interoperar con los dispositivos específicos desplegados.
Ejemplo de aplicac iones a cced iendo a d ispositivos mediante OPC.
MBIGDA_M8T2_160727
156
La especificación OPC es OPC Data Access, que se utiliza para leer y escribir datos en tiempo
real. Cuando los fabricantes se refieren a OPC de forma genérica, por lo general significan OPC Data
Access (OPC-DA).
OPC-DA en ha pasado por tres revisiones importantes desde su creación. Las versiones son
compatibles hacia atrás, un OPC Server versión 3 todavía se puede acceder por una versión 1 de
OPC Client. Sin embargo, un cliente compatible con DA-3 no necesariamente va a trabajar con un
servidor DA 1.0.
Además especificación OPC DA, la Fundación OPC también mantiene la especificación OPC HDA
(Historical Data Access). En contraste con los datos en tiempo real que se puede acceder con el
OPC-DA, OPC-HDA permite el acceso y la recuperación de los datos archivados.
La especificación OPC AE (Alarmas y Eventos) también es mantenida por la Fundación OPC.

Define el intercambio de información del mensaje de alarma y el tipo de evento, así como los
estados de variables y la administración del estado de los dispositivos.
Ejemplo de comunicac ión OPC
9.10. DDS Data Distribution Service

DDS es un modelo de publicación y suscripción centrado en los datos (data-centric) para la
integración y comunicación, distribuida de aplicaciones. Tiene como objetivo el proporcionar una
forma eficiente y robusta de entregar la información correcta en el lugar correcto y en el tiempo
correcto.
MBIGDA_M8T2_160727
157
Una diferencia importante de DDS frente a OPC consiste en que mientras que OPC está
orientado a una arquitectura centralizada de tipo cliente-servidor, y se comparten objetos, DDS
comparte datos, y es sobre los datos sobre los que se define la visibilidad, el descubrimiento, la
seguridad, etc. en lugar de ser sobre los sistemas y dispositivos. Otra gran diferencia es el protocolo
subyacente en DDS de publicación subscripción en tiempo real.
Estructura de so lución DDS.
DDS está formado por las siguientes capas o bloques:
- DDS describe la semántica de la compartición de la información, mediante un sistema

de tipo nominal, para describir los modelos de información DDS.
- DDSI-RTPS define el protocolo para interoperar con la semántica DDS.
- DDS X-Types extiende el sistema DDS para datos con estructuras y tipos de datos
dinámicos.
- DDS-Security proporciona mecanismo de seguridad sobre los datos.
- DDS-RPC extiende DDS permitiendo llamadas de procedimiento remoto.
- DDS-PSM define un API de mapeo para lenguajes de programación específicos en lugar
de usar DDS-PSM-IDL
- DL-RL define un mapeo de objetos y relaciones independiente del lenguaje.
MBIGDA_M8T2_160727
158
Con DDS las aplicaciones pueden de forma autónoma y asíncrona leer y escribir datos
disfrutando de desacoplamiento local y temporal, incorpora descubrimiento dinámico, aislando las
aplicaciones de la topología de red y de los detalles de conectividad. Dispone de un sistema de
políticas de calidad de servicio que define las restricciones de tiempo y de disponibilidad de los
datos.
Espacio global de datos en DDS
DDS define un espacio global de datos y permite construir arquitecturas descentralizadas, que
eviten tener puntos únicos de fallo. La conectividad entre los nodos se adapta dinámicamente para
elegir la forma óptima (TCP, o UDP Unicast/Multicast) para compartir los datos.
En DDS un Topic de publicación está definido por un nombre, una calidad de servicio y un tipo, y
permite la expresión de propiedades funcionales y no funcionales de un modelo de información.
DDS es utilizado en sistemas como la Integración de Centros de Control de Tráfico aéreo a nivel
Europeo, Sistemas de Transporte, Smart Cities, Centros de control de satélites, vehículos
autónomos, Sistemas financieros de auto trading de alta frecuencia…
MBIGDA_M8T2_160727
159
Ejemplo de uso de DDS en vehículo autó nomo.
Está en curso una definición de Gateway que permita la conexión de un sistema OPC en un DDS
de forma transparente.
9.11. RTPS Real-Time Publish-Subscribe protocol

Es un protocolo de publicación y suscripción en tiempo real orientado a la interoperabilidad,
que permite dar soporte a las implementaciones de DDS (Data Distribution Service).
Está diseñado para funcionar sobre IP en modo multicast (envío de mensajes de uno a muchos)
y capa de transporte sin conexión best-effort como IP sobre UDP.
Es idóneo en entornos críticos o industriales con control, por las garantías que ofrece y la
robustez del sistema.
- Comunicaciones fiables con calidad de servicio y rendimiento ajustable.

- Tolerancia a fallos para construir redes sin puntos únicos de fallo.
- Extensibilidad a través de extensiones del protocolo que permite compatibilidad,
interoperabilidad y mejora con nuevos servicios.
- Conectividad plug-and-play para nuevas aplicaciones y servicios que permiten la
detección automática, altas y bajas de la red en cualquier momento sin configuración.
- Permite equilibrar por configuración los requisitos de fiabilidad y oportunidad para
cada transacción de suministro de datos.
MBIGDA_M8T2_160727
160
- Modularidad permitiendo que los dispositivos implementen solo un subconjunto del

protocolo.
- Escalabilidad para interconectar redes a gran escala mediante publicación-suscripción.
- Tipo de seguridad que evita errores de programación de aplicaciones que
comprometen el funcionamiento de los nodos remotos en la red de publicación-
suscripción.
- Timestamping a nivel de nanosegundos.
10. Gestión de datos

La gestión de datos (Data Management) es un concepto base que se refiere a las arquitecturas,
prácticas y procedimientos para una apropiada gestión de las necesidades de un sistema respecto
al ciclo de vida de los datos. En el contexto de IoT la gestión de los datos debería participar como
una capa entre los objetos y los dispositivos que generan los datos y las aplicaciones que acceden a
los datos con propósitos de análisis y prestación de servicios.
Los dispositivos pueden ser agrupados en subsistemas, y disponer de una gestión interna
jerárquica. La funcionalidad y los datos que provean esos subsistemas estarán disponibles en la red
de Internet de las Cosas, dependiendo del nivel de privacidad deseado por el propietario del
subsistema, o los datos.
Los datos de IoT tienen características distintivas que hacen que la gestión de bases de datos
relacionales tradicional sea una solución obsoleta o escasamente aplicable. Un volumen masivo de
datos heterogéneos, en stream, dispersos geográficamente, en tiempo real será creado por
millones de dispositivos periódicamente, enviando datos sobre situaciones u objetos
monitorizados, e información de interés.
Las necesidades de comunicación y almacenamiento de los datos generados por tal volumen de
dispositivos requieren el desarrollo de tecnología y la aplicación de tecnologías diferentes a las
convencionales. Por otra parte es necesario guardar metadatos que describen las cosas y como
interactuar con ellas, así como quien puede acceder a los datos y las acciones sobre estas. Esta
MBIGDA_M8T2_160727
161
información debe guardarse de una forma flexible dada la inmensa variedad de cosas y acciones
que debe ser capaz de describir.
El almacenamiento, procesamiento y las comunicaciones deben ser tenidos en cuenta en el

diseño de los sistemas de gestión de datos. La utilización de almacenamiento remoto para las cosas,
el soporte a datos no estructurados, la relajación de las propiedades de consistencia, atomicidad,
aislamiento y durabilidad (ACID) para lograr sistemas viables y eficientes energéticamente.
10.1. El ciclo de vida de la información en IoT

Los sistemas de gestión de datos tradicionales manejan el almacenamiento, la recuperación y
actualización de elementos de datos elementales, registros y archivos. En el contexto de la IoT, los
sistemas de gestión de datos deben resumir los datos “online” y proporcionar al mismo tiempo
facilidades para almacenamiento, registro y auditoría para el análisis “offline”.
Primero vamos a definir el ciclo de vida de los datos en el contexto de la IoT y luego desgranar
las actividades clave a realizar, con el fin de tener una mejor comprensión de la gestión de datos IO.
La producción, recolección, agregación, filtrado y algunas consultas básicas y funcionalidades de

procesamiento preliminar son consideradas operaciones a realizar “online” o conforme se produce
la información, e implican un uso intensivo de comunicaciones. En cambio, el pre-procesado
intensivo de información, almacenamiento a largo plazo, archivado y procesamiento o análisis en
profundidad son consideradas operaciones offline de almacenamiento intensivo.
MBIGDA_M8T2_160727
162
Esquema general de procesamiento de inf ormación en IoT
El ciclo de vida de los datos en un sistema IoT comienza en la producción de datos y agregación,
la transferencia y opcionalmente el filtrado y pre-procesamiento, finalmente los datos son
almacenados y archivados.
Los datos tienen como finalidad ser consultados o analizados a través de peticiones y consumo
de los datos producidos, pero también pueden ser enviados a los servicios que consumen
información “online”.
10.1.1. Consulta
Sistemas de uso intensivo de datos se basan en la consulta como el proceso central para
acceder y recuperar datos. En el contexto de la IoT, una consulta puede ser emitida ya sea para
solicitar datos en tiempo real para ser recogidos con fines de vigilancia, o temporales para
recuperar una vista de los datos almacenados en el sistema. El primer caso es típico cuando se
necesita una solicitud de tiempo real, típicamente datos muy concretos o localizados sin una visión
MBIGDA_M8T2_160727
163
global. El segundo caso representa análisis más globalizados de datos y análisis en profundidad de
tendencias y patrones.
10.1.2. Producción
La producción de datos implica la detección y la transferencia de datos por las "cosas" en el

marco de la IoT e informar estos datos a las partes interesadas de forma periódica (como en un
modelo de publicación /suscripción, los datos son enviados hacia arriba en la red de puntos de
agregación y, posteriormente, a los servidores de bases de datos, o se envían como una respuesta
desencadenada por las consultas que soliciten los datos de los sensores y objetos inteligentes. Los
datos son por lo general datos de series temporales con marca de tiempo y, posiblemente, geo-
localizados, y puede ser desde simples pares clave valor, estructuras de datos en formatos de
representación interoperable como JSON, XML,… y hasta contenido binario complejo como audio,
imagen, vídeo…
10.1.3. Recolección
Los sensores y objetos inteligentes en IoT pueden almacenar los datos durante un cierto
intervalo de tiempo o enviarlos directamente. Los datos pueden ser recogidos en los puntos de
concentración o puertas de enlace dentro de la red donde se filtra y se procesa adicionalmente, y
posiblemente pueden ser fundidos en formas compactas para realizar una transmisión eficiente.
Las tecnologías de comunicación inalámbrica tales como Zigbee, Wi-Fi y 3GPP son utilizados por los
objetos para enviar datos a los puntos de recogida.
10.1.4. Agregación / Fusión
La transmisión de todos los datos en bruto de la red en tiempo real, a menudo es

prohibitivamente costoso, dada las crecientes tasas de transmisión de datos y el ancho de banda
limitado. Técnicas de agregación y fusión se pueden aplicar sobre los datos para facilitar la tarea.
10.1.5. Entrega
Si se producen estas fases de filtrado, agregación, y posiblemente procesado de datos, ya sea en

los puntos de concentración o dentro de la IoT, los resultados de estos procesos puede ser
MBIGDA_M8T2_160727
164
necesario que tengan que ser llevados a otros sistemas ya sea para dar respuestas finales, o para el
almacenamiento y el análisis en profundidad. Para transferir datos a los almacenes de datos
permanentes se pueden usar conexiones de cable o Wireless.
10.1.6. Preprocesado
Los datos de IoT vendrán de diferentes fuentes con diferentes formatos y estructuras. Los datos
pueden necesitar ser pre-procesados para completar datos que faltan, eliminar redundancias e
integrar datos de diferentes fuentes en un esquema unificado antes de ser almacenados. Este
procesamiento previo es un procedimiento conocido en la minería de datos denominada limpieza
de datos. Este pre-procesado tiene que ser ligero, no puede tratarse de un proceso de fuerza bruta,
por lo que podrá realizar ciertas comprobaciones para evitar el compromiso de la información
almacenada pero no garantizará más allá la calidad de los datos.
10.1.7. Almacenamiento, Actualización y Archivado
Esta fase se ocupa del almacenamiento eficiente y la organización de los datos, así como de la
continua actualización de los datos con la nueva información a medida que esté disponible.
Archivado se refiere al almacenamiento a largo plazo de los datos que no se necesita estar
disponible de inmediato para las operaciones del sistema. El núcleo de almacenamiento
centralizado es el despliegue de estructuras de almacenamiento que se adaptan a los diferentes
tipos de datos y la frecuencia de captura de datos. Sistemas de gestión de bases de datos
relacionales son una opción popular que consiste en la organización de los datos en un esquema de
la tabla con interrelaciones predefinidas y metadatos para la recuperación eficiente en las etapas
posteriores. Almacenes NoSQL de claves y valores están ganando popularidad por el soporte del
almacenamiento Big Data, especialmente aquellos sin ninguna dependencia de esquema relacional
o requisitos de integridad referencial fuertes típicas de los sistemas de bases de datos relacionales.
El almacenamiento también puede ser descentralizado para sistemas de IoT autónomos, en los que
los datos se necesitan y se mantienen en los objetos que lo generan y no se requiere enviarlos a un
sistema centralizado. Sin embargo, debido a la reducida capacidad de este tipo de objetos, la
capacidad de almacenamiento es limitada en comparación con el modelo de almacenamiento
MBIGDA_M8T2_160727
165
centralizado. Por ejemplo un vehículo autónomo tendrá que mantener la información necesaria
disponible en el vehículo para poder funcionar ante un fallo en la conexión.
10.1.8. Procesamiento / Análisis
Esta fase incluye el análisis de las operaciones realizadas y de los datos recuperados,
almacenados y los datos con el fin de proporcionar investigación y análisis de los datos históricos y
predecir tendencias futuras, o para detectar anomalías en los datos que pueden dar lugar a nuevas
investigaciones o acciones. Tareas específicas de limpieza y pre-procesado tienen que ser realizadas
orientando la información para facilitar estas operaciones. Cuando un subsistema de la IoT es
autónomo y no requiere el almacenamiento permanente de los datos, sino que más bien mantiene
el procesamiento y almacenamiento en la red, a continuación, dentro de la red de procesamiento
se puede generar una respuesta en tiempo real o consultas sobre datos localizados (en el tiempo).
10.2. Bases de datos y propiedades ACID en IoT

En sistemas de IoT, con un número creciente y masivo de fuentes de datos; sensores,
dispositivos RFID, sistemas integrados y dispositivos móviles, contrariamente a las actualizaciones
ocasionales y las consultas enviadas a los DBMS tradicionales, los datos se transmiten
constantemente a partir de una multitud de "cosas" a los almacenes de datos, y las consultas son
además muy frecuentes y con necesidades muy versátiles. La presentación de datos jerárquica y la
agregación pueden ser necesarias para las garantías de escalabilidad, así como para habilitar la
funcionalidad de procesamiento rápido. El esquema de base de datos relacional y la práctica de la
normalización de relaciones pueden estar relajados en favor de formas más estructuradas y
flexibles que se adaptan a los diversos tipos de datos y consultas sofisticadas.
En IoT la alta variedad de los datos crean un ambiente altamente dinámico para los
optimizadores de consulta. Así, garantizar los requisitos de transparencia de los modelos de datos
relacionales RDBMS es difícil, si no imposible. El mantenimiento de las propiedades ACID en IoT es
posible quizá en espacios delimitados (subsistemas), en los que las transacciones de ejecución
MBIGDA_M8T2_160727
166
pueden ser afrontadas, pero es un reto no resuelto mantener las propiedades ACID en el espacio
global del sistema.
Las propiedades ACID se refieren a las funcionalidades que proporcionan los sistemas de bases
de datos respecto a las garantías que ofrecen en el procesamiento de la información, el acrónimo
representa a las siguientes propiedades:
- Atomicidad: Si una operación consiste en una serie de pasos, todos ellos ocurren o
ninguno, es decir, las transacciones son completas.
- Consistencia: Integridad. Es la propiedad que asegura que sólo se empieza aquello que
se puede acabar. Por lo tanto se ejecutan aquellas operaciones que no van a romper las
reglas y directrices de Integridad de la base de datos. La propiedad de consistencia
sostiene que cualquier transacción llevará a la base de datos desde un estado válido a
otro también válido. "La Integridad de la Base de Datos nos permite asegurar que los
datos son exactos y consistentes, es decir que estén siempre intactos, sean siempre los
esperados y que de ninguna manera cambien ni se deformen. De esta manera podemos
garantizar que la información que se presenta al usuario será siempre la misma."
- Isolation (Aislamiento): es la propiedad que asegura que una operación no puede
afectar a otras. Asegura que la realización de dos transacciones, sobre la misma
información, sea independiente y no generen ningún tipo de error. Esta propiedad
define cómo y cuándo los cambios producidos por una operación se hacen visibles para
las demás operaciones concurrentes. El aislamiento puede alcanzarse en distintos
niveles, siendo el parámetro esencial a la hora de seleccionar un SGBD.
- Durabilidad: Persistencia. Es la propiedad que asegura que una vez realizada la
operación, ésta persistirá y no se podrá deshacer aunque falle el sistema y que de esta
forma los datos sobrevivan de alguna manera.
Existen dos técnicas ampliamente utilizadas para lograr ACID: una consiste en escribir a un
registro antes de continuar, la atomicidad es garantizada asegurándose que toda la información
esté escrita a un registro antes que se escriba a la base de datos, la otra forma extendida consiste
MBIGDA_M8T2_160727
167
en sombrear, las actualizaciones se aplican a una copia de la base de datos, y se activa la nueva
copia cuando la transacción sea confiable.
Es difícil garantizar características en un ambiente de red. Las conexiones de red pueden fallar,
o dos usuarios pueden utilizar la misma parte de la base de datos al mismo tiempo.
10.3. Teorema CAP

Según la demostración realizada en 2000 el teorema CAP dice que en un sistema de
computación distribuida es imposible garantizar simultáneamente la consistencia (que todos los
nodos vean la misma información a la vez), la disponibilidad (la garantía de que cada petición a un
nodo reciba una confirmación de si ha sido o no resuelta satisfactoriamente), y la tolerancia a fallos
(que el sistema sigue funcionando a pesar de que ha sido partido por un fallo de red).
A lo sumo se pueden dar dos de las condiciones por lo que los sistemas distribuidos, solo
podrán garantizar AP, CA, o CP. Los subsistemas deben ser concordantes o contemplar esta
situación.
10.4. Elementos de diseño

Una plataforma de gestión de datos de IoT necesita cubrir unas operaciones que consideramos
“mínimas” y clasificamos como “elementos” y agrupamos en “bloques”. Estos bloques se orientan a
áreas de actividad formando bloques para la recopilación de datos, el diseño del sistema de gestión
de datos y el procesamiento.
Los elementos de recogida de datos se dirigen al descubrimiento y la identificación de las

"cosas" y subsistemas-estáticos o dispositivos, cuyos datos van a alimentar a los almacenes de
datos.
El diseño del sistema de gestión de datos define la gestión de los datos y cómo los datos se
deben almacenar y archivar.
Los elementos de procesamiento se ocupan del acceso útil para el usuario a los almacenes de
datos.
MBIGDA_M8T2_160727
168
Elementos de diseño para una soluc ión de gestión de d atos para IoT
10.5. Elementos de recogida de datos

10.5.1. Descubrimiento de fuentes
Uno de los servicios de valor añadido para proporcionar la IoT es la capacidad de aprovechar
diversas fuentes de datos que no necesariamente pertenecen al mismo subsistema. Por lo tanto, se
necesita un mecanismo fuentes de descubrimiento para aplicaciones de IoT para que puedan
anunciar sus necesidades de servicio y obtener respuestas de fuentes cuyos datos pueden
satisfacer estas necesidades. El sistema puede descubrir fuentes de datos ya sea a través de
rastreo, o por medio de a partir de un conjunto predefinido de fuentes de datos que más tarde
pueden crecer medida que se descubren nuevas.
10.5.2. Estrategia de recolección de datos
La recolección de datos puede ser temporal o modal. La recopilación de datos temporal incluye
la recolección de datos de todas las "cosas" a intervalos determinados, mientras que la recolección
modal incluye la recolección de los datos correspondientes a elementos específicos. La variación de
las necesidades de datos que es de esperar en sistemas de IoT puede dictar que se tenga más de un
esquema de base de datos para acomodar las dos metodologías de recopilación de datos
10.5.3. Apoyo a la movilidad
Los dispositivos móviles y sus entidades son un subconjunto importante de las "cosas". A
medida que avanza su uso, necesitan ser capaces de informar y acceder a almacenes de datos de
una manera transparente. Se han propuesto soluciones para los sistemas de gestión de bases de
MBIGDA_M8T2_160727
169
datos que se ejecutan en dispositivos móviles, que utilizan un sistema de sincronización basada en
sesión para el intercambio de datos y mecanismos de almacenamiento para facilitar la
sincronización de datos. La abstracción de la conectividad y el mantenimiento del contexto
semántico en movimiento son los principales factores que deben ser abordados con el fin de
apoyar la movilidad en la gestión de los datos de la IoT.
10.6. Elementos de diseño del sistema de base de datos.

10.6.1. Arquitectura federada
Conceptos de sistemas distribuidos y bases de datos federadas pueden adaptarse a las

necesidades de gestión de datos de la IoT. Los sistemas de bases de datos distribuidas permiten
gestionar una única base de datos distribuida a través de múltiples sitios. Sistemas de base de datos
federada, por otro lado, permiten gestionar almacenes de datos independientes y posiblemente
heterogéneos ubicados en múltiples sitios. En una arquitectura federada, la autonomía completa de
un sitio sobre sus datos se mantiene. Los subsistemas de la IoT son inherentemente distribuidos y
heterogéneos.
Además de las arquitecturas federadas, existe una tendencia creciente de construir sistemas de
IoT alrededor de arquitecturas orientadas a servicios interoperables.
10.6.2. Data-Centric Middleware
Hay una necesidad de middleware centrado en los datos en lugar de centrado en las
comunicaciones. Esta capa de middleware servirá para proporcionar capacidades más versátiles
para descubrir las fuentes de datos y el acceso y análisis de datos heterogéneos y distribuidos
geográficamente. La capa de middleware también se centrará en la transferencia escalable de gran
volumen de datos enviado desde la red a los almacenes de datos. Hay una necesidad de aprovechar
todo el potencial de conocimiento que puede ser obtenida de diferentes fuentes de datos dentro
de la IoT, proporcionando los medios para descubrir esas fuentes basadas en la ubicación,
modalidad (es decir, el tipo de fuente) o las necesidades de consulta globales, que son agnósticos a
la red subyacente.
MBIGDA_M8T2_160727
170
Una opción consiste en la representación virtual de los sensores de una WSN que integra
múltiples flujos de datos procedentes de los sensores reales en capas más bajas en un único flujo
de datos. Consultas sobre el flujo de entrada son realizadas y los resultados se almacenan en
relaciones temporales, y el resultado de la combinación de estos flujos de datos se almacena
permanentemente sólo si se requiere, de lo contrario, se consume por la aplicación.
10.6.3. Modelo de base de datos flexible
En los sistemas de bases de datos relacionales, los principios de atomicidad, dependencia

funcional, y la normalización se utilizan para definir la estructura de las relaciones en una base de
datos relacional. Los modelos de bases de datos que se apartan del modelo relacional en favor de
una estructura de base de datos más flexibles y están ganando una popularidad considerable,
aunque se ha demostrado que los DBMS relacionales paralelos superan a los paradigmas de DBMS
no estructurados.
10.6.4. Esquema de apoyo
Define formalmente la estructura de un sistema de base de datos. En el modelo relacional, el

esquema se define de antemano como tablas y las relaciones que unen estas tablas, y todas las
inserciones de datos / actualizaciones deben cumplir con ese esquema. En los últimos tiempos han
surgido soluciones de gestión de datos que soportan grandes volúmenes de datos y datos variados,
ha sido habitual ir a soluciones sin esquema para permitir una estructura más flexible de la base de
datos. Hay una serie de soluciones de compromiso entre la aplicación de un esquema y no
esquema. La falta de esquema conduce a registros que se analizan en tiempo de ejecución, en lugar
de analizar, filtrar e indexar la información en el momento de la inserción, que es típico en los
sistemas de bases de datos relacionales. Esto provoca la degradación en el rendimiento de los
sistemas sin esquema en la explotación, y la compresión se vuelve menos eficaz. La falta de
esquema también conducirá a los usuarios escriban sus propios programas de análisis o consulta, lo
que compromete la interoperabilidad de que es deseable para aplicaciones de IoT. La optimización
de la consulta es un reto en sistemas sin esquema, debido a la falta de conocimiento sobre índices,
particiones de tabla, cardinalidades y estadísticas sobre los valores de los datos.
MBIGDA_M8T2_160727
171
10.6.5. Indexación eficiente
La indexación se ve muy afectada por las operaciones de inserción y es un elemento principal de

diseño para sistemas de almacenamiento. Tener varios índices que se utilizan para diferentes
requisitos de recuperación es esencial para las aplicaciones dinámicas de la IoT. Sin embargo, la
construcción y el almacenamiento de los índices para facilitar el acceso y recuperación de datos
para un volumen masivo de datos de sensores, puede ser prohibitivamente costoso tanto en
términos de almacenamiento adicional requerido como por la sobrecarga de procesamiento. Por
tanto, el equilibrio entre la recuperación eficiente y escalable de almacenamiento es un requisito
indispensable. Por otra parte, la indexación dinámica espacio-temporal necesita ser adaptada para
la transmisión de datos. Modelos para lograr esta indexación dinámica incluyen ventanas
deslizantes (sliding window indexing), indexación multi-gránulo (multi-granule indexing), índices de
onda (wave indexing), y el modelo de índice de tiempo (time index).
10.6.6. Plataforma de almacenamiento en capas
Contrariamente a los sistemas de bases de datos tradicionales, en los que los datos se recogen a
priori y almacenan en servidores de bases centralizadas o distribuidas, los datos de la IoT se
actualizan continuamente a medida que los estados de cosas y la monitorización cambian. Incluso si
fuera posible que todos los datos generados por las cosas en un cierto punto en el tiempo estén
disponibles para ser almacenados en el almacenamiento permanente, se convertirán en obsoletos
rápidamente y los nuevos datos deberán estarán disponible. El estado actual de la técnica heredada
de sistemas M2M permite datos en tiempo real y almacenamiento, sin embargo, el diseño de estos
sistemas se enfoca a almacenamiento centralizado, y no es adecuado para la escala y la distribución
de los volúmenes de datos generados por fuentes de la IoT. La gestión de datos en IoT debe tener
en cuenta esta volatilidad de la validez de los datos almacenados.
10.6.7. Archivado escalable
El sistema de gestión de datos debe proporcionar una solución escalable de archivado, con
soluciones de descubrimiento competentes con fines de recuperar y analizar datos archivados con
diversos grados de frecuencia de recuperación. Los sistemas deben proporcionar esquemas de
MBIGDA_M8T2_160727
172
caducidad y considerar métricas de "utilidad" de los datos en lugar de métricas en tiempo simples,
para decidir el archivado de los datos.
10.7. Elementos de procesamiento

10.7.1. Modelo de acceso a datos
Para acceder a los datos en sistemas relacionales se han desarrollado lenguajes de consulta.
Structured Query Language (SQL) ha sido el estándar de facto para el acceso a datos, con las
operaciones de selección / proyección / unión / agregación estándar que pueden anidarse para
construir consultas complejas. Construcciones adicionales se han añadido al lenguaje con el fin de
dar cabida a nuevas formas de datos, tales como TinySQL para redes de sensores y StreamSQL para
el procesamiento de flujo de datos. Como SQL se ha vuelto demasiado complejo debido a las
extensiones continuas a medida que se añaden nuevas capacidades, los desarrolladores para las
diferentes aplicaciones de la IoT tendrán dificultades para aprender todos los dialectos y trucos de
SQL, de los que van necesitar sólo un subconjunto de ellos. Avances en esta área se deben producir
y, el acceso a través de servicios debe lograrse en las arquitecturas cuanto antes, desacoplando el
desarrollo lo máximo posible de la expresión de las consultas.
10.7.2. Estrategia de procesamiento eficiente
Los dos objetivos principales de la recogida de datos de la capa son el reporting y el análisis.
Ambos implican el tratamiento de datos en un cierto punto en el sistema con el fin de agregar /
inferir información útil. La determinación de la ubicación en la que los datos se van a procesar en
sistemas de IoT es una preocupación principal de diseño en la que se debe tener en cuenta la
naturaleza descentralizada del sistema y el volumen de los datos producidos. Dos enfoques de
procesamiento pueden implementarse para sistemas de IoT: dentro de la red de procesamiento y
procesamiento centralizado. Dentro de la red de procesamiento consiste en mover el "programa" a
los datos y enviando sólo los resultados de vuelta al usuario (como el paradigma map-reduce), lo
que reduce el volumen de datos que necesita ser transportado a un almacenamiento centralizado
en las capas superiores de arquitectura en el sistema. Procesamiento centralizado, por el contrario,
requiere que los datos sean transportados al lugar de procesamiento, un centro de
MBIGDA_M8T2_160727
173
almacenamiento persistente para permitir tareas de análisis sofisticados. Un híbrido de ambas

técnicas se puede utilizar para un modo de procesamiento más flexible, con diversos grados de
personalización para adaptarse a las diversas necesidades de la aplicación de la IoT.
10.7.3. Procesamiento de consultas de adaptación y optimización
El procesamiento de consultas se realiza tradicionalmente cerca de almacenes de datos con el

fin de ofrecer planes de ejecución de consultas, La optimización de la consulta tradicional consiste
en asignar un coste a cada uno de los diferentes planes para la obtención de datos con el fin de
elegir el plan que es menos costoso. En el contexto de la IoT, el procesamiento de consultas,
además, implica encontrar planes para obtener los datos de los sensores y dispositivos que están
distribuidos geográficamente y que regresan lecturas agregadas como resultados. Por lo tanto, se
requiere un gran volumen de intercambios de mensajes que se traducen en sobrecarga de
comunicación
La optimización de consultas que consiste en elegir los mejores planes de consulta sobre la base
de sus respectivos costos de energía se están considerando para redes inalámbricas de sensores en
y los servidores de base de datos, a fin de encontrar el mejor plan de ejecución de la consulta con
los menores costos de energía. Sin embargo, la optimización se hace por una sola consulta a la vez y
no tiene en cuenta el dinamismo de la red.
La optimización multi-consulta también se utiliza para el procesamiento de consultas de alta

eficiencia energética en redes inalámbricas de sensores. Dos niveles se utilizan para optimizar la
ejecución de consultas: A nivel de estación base vuelve a escribir una serie de consultas para
producir un conjunto sintético de consultas con las redundancias y sub-consultas combinadas.
La agregación y fusión de datos de sensores es esencial para la reducción de la sobrecarga de

comunicación esperada de la transmisión de datos. Además, la agregación y fusión pueden ser un
requisito para determinadas aplicaciones en las que el almacenamiento de datos en bruto no da
ningún valor añadido. Un factor que debe ser tenido en consideración es la posible pérdida de
precisión resultante de filtrar los datos detallados subyacentes en esta agregación o fusión. Por lo
tanto, la agregación inteligente debe ser un factor de diseño para la gestión de datos de la IoT.
MBIGDA_M8T2_160727
174
10.8. Conclusiones sobre la gestión de datos

Una arquitectura debe contemplar estos aspectos críticos para establecer un framework de IoT
capaz de abordar varias soluciones, las diferentes herramientas y tecnologías existentes, a
desarrollar y a personalizar en función del ámbito de la solución que se desea construir. Las
diferentes capas deben abordar estas necesidades y problemas, y proponer la solución.
MBIGDA_M8T2_160727
175
Ejemplo de arquitectura desde el punto de vis ta de la gestión de datos p ara IoT
MBIGDA_M8T2_160727
176
11. Dispositivos de procesamiento

Cuando un sistema recibe datos de un dispositivo de entrada, los datos deben pasar por fases
intermedias antes de que puedan ser enviados a un dispositivo de salida, los dispositivos de
procesamiento son cualquier dispositivo que realice esta etapa intermedia, siendo responsable de
controlar el almacenamiento y recuperar los datos.
Desde este punto de vista, en IoT es necesario un conjunto de tecnologías para almacenar y
procesar un gran volumen de información, como se indicó en el apartado de gestión de datos.
Eminentemente Internet de las Cosas implica el uso de tecnologías Big Data capaces de
almacenar grandes volúmenes y procesarlos como datos reposados, y también con tecnologías de
procesamiento en Streaming.
En IoT por el alto volumen de información aplican las tecnologías Big Data, en proyectos IoT se
pueden aplicar tecnologías para construir un Stack o infraestructura propia sobre tecnologías base,
integradas, con herramientas para la gestión y verticales para construir las soluciones o aplicaciones
específicas, o bien se pueden utilizar plataformas que abstraen de la tecnología subyacente.
Si bien no existen sistemas específicos de tecnología de procesamiento para IoT, las tecnologías
empleadas son genéricas, y es su uso el que determina que se trata de un sistema para Internet de
las Cosas, sí existen plataformas construidas con las tecnologías y que resuelven o proporcionan
funcionalidades para Internet de las cosas, estas plataformas proveen servicios de almacenamiento
y procesamiento, de captura de datos de información y de analítica facilitando la construcción de
aplicaciones sobre Internet de las Cosas.
11.1. Xively
Xively es pionera en construir y proporcionar una plataforma IoT de empresa, la plataforma se
ofrece como una solución para las empresas para conectar con seguridad y firmeza sus productos y
usuarios, gestionar los datos de la IoT a escala.
MBIGDA_M8T2_160727
177
Es un servicio cloud multitenant (cada proyecto mantiene sus datos y procesamientos

separados de otros proyectos en una misma plataforma compartida). Ofrece librerías, SDK y APIs
para conectar los dispositivos a la plataforma y enviar la información, un servicio de gestión de
dispositivos,…
Funciona lidades de la platafor ma Xively
Además permite contratar servicios profesionales para acelerar o apoyar el proyecto a

construir.
A través de las APIs y los servicios que proporciona la plataforma se pueden construir
aplicaciones verticales usando los datos recopilados o enviados.
Ejemplo de graf ica mostrada en Xively sobre un sensor en Arduino enviando da tos a X ively .
MBIGDA_M8T2_160727
178
Los pasos por ejemplo para construir una aplicación que recibe datos desde un Arduino y los
muestra en internet son:
- Conectar el sensor DS18B20 de temperatura a Arduino

- Leer el sensor usando el interfaz de 1 cable (apropiado para el sensor)
- Enviar los datos a xively.com directamente desde Arduino
- Ver el resultado en Internet
11.2. Azure IoT SUITE

Microsoft a través de sus servicios de cloud Azure ofrece una suite de soluciones para IoT, que
contemplan la recogida de datos, el análisis, machine learning y la integración de los sistemas de la
empresa a través de APIs.
En su web Azure muestra un ejemplo de cómo construir un sistema de mantenimiento

preventivo (predictivo) con su solución IoT Suite. Los pasos para realizar un proyecto en Azure son:
- Conectar las fuentes de datos

- Normalizar los datos
- Analizar los datos
- Probar los modelos predictivos para usar los que ajusten a su caso de uso
- Pilotar la solución localmente en un área o con un subconjunto
- Integrar esta nueva información en sus procesos de negocio.
Básicamente Azure IoT Suite proporciona herramientas para desplegar una plataforma de
gestión de datos y procesamiento de datos en la que integrar los procesos.
Los servicios de Azure IoT Suite son módulos que se pueden contratar por separado y que se
complementan entre sí, la orientación de IoT Suite es hacia funcionalidad, y la contratación de
servicios se realiza también con este enfoque:
- IoT Hub: para conectar, controlar, monitorizar millones de dispositivos de IoT.
MBIGDA_M8T2_160727
179
- Machine Learning: Herramienta para realizar análisis predictivo sobre la información

recopilada.
- Stream Analytics: Herramienta para el análisis y monitorización en tiempo real de
millones de dispositivos.
- Notificaciones Push: Un sistema escalable para el envío de mensajes PUSH
- Power BI: Herramienta de Bussiness Intelligence para transformar datos en información
visual de valor.
Estas herramientas están orientadas a un desarrollo y despliegue rápido de soluciones, de

forma que los proyectos se abstraigan de las tecnologías el máximo posible.
Herramienta de Mach ine Lear ning de Azure IoT
11.3. Samsung SAMI

Samsung ha desarrollado una plataforma de IoT que define como un ecosistema abierto para
los desarrolladores de IoT, con el objetivo de reunir y hacer que los datos sean más accesibles, y
liberar a los desarrolladores de aplicaciones de IoT de la construcción de infraestructura subyacente
de los sistemas para la gestión y procesamiento de los datos. Propusieron crear un corredor de
datos en la nube, que pudiera manejar todos los datos, desde cualquier dispositivo o aplicación.
MBIGDA_M8T2_160727
180
Con la visión de que SAMI debía considerarse como un banco de datos privados, con los
controles de seguridad y privacidad solucionadas para los desarrolladores. SAMI es una plataforma
orientada al desarrollador, con APIs y herramientas sencillas y potentes para acelerar el camino
para construir y habilitar nuevas experiencias de usuario, servicios y modelos de negocio.
En tan sólo dos años, el equipo SAMI contrató a los mejores talentos de Silicon Valley y creció
de cero a 40 personas - incluyendo múltiples equipos de desarrollo, DevOps, especialistas en
seguridad, e ingenieros de control de calidad - y en ese tiempo ha puesto en marcha una
plataforma de datos de IoT que cuenta con un alcance muy ambicioso.
Al más alto nivel, SAMI proporciona una capa de abstracción para la ingestión de los datos del
dispositivo, procesamiento, enrutamiento y para acceder a él a través de APIs muy amigables para
el desarrollador. SAMI se ocupa de “todo”, desde la seguridad de los datos, los datos en tiempo
real, las transformaciones, agregaciones y almacenamiento. Mediante el desarrollo en la parte
superior de una plataforma que permite el acceso fácil y seguro a cualquier tipo de datos, desde
cualquier tipo de dispositivo, y se interconecta con otras plataformas de dispositivos, así los
desarrolladores utilizando SAMI pueden centrarse en la construcción de su valor añadido para el
ecosistema.
Esquema conceptual de SAMI
SAMI soporta una amplia gama de lenguajes de programación, permite construir herramientas,
frameworks y tecnologías distribuidos (Java, Scala, Play, Akka, Kafka, Zookeeper, Cassandra,
Elasticsearch, MongoDB, TitanDB, Redis, MySQL, Spark, Samza , Mesos, Docker, Consul, etc.) para
proporcionar una serie de características y funciones avanzadas.
MBIGDA_M8T2_160727
181
- Normalización de datos simplificada para desarrolladores de IoT: Los datos que entran
en SAMI pueden estar en el formato que quiera enviar el dispositivo, en el centro hay
un proceso de normalización para producir un formato JSON estándar disponible a
través de la API.
- Agnóstico a los dispositivos y los datos: Un aspecto diferenciador clave de SAMI es que
no hay ninguna limitación en cuanto a qué tipo de datos se puede enviar: los
desarrolladores definen campos de datos, su clase y unidad, sin restricción. Estos datos
pueden enviarse en cualquier formato, incluyendo binario, JSON, XML, texto, o
cualquier formato personalizado para el cual el desarrollador proporciona código de
normalización.
- Nuevos estándares para descripción de datos: Una de las metas de SAMI es que los
desarrolladores describan los datos. Eso se hace a través de lo que se conoce como el
"manifiesto". Otros desarrolladores pueden entender los datos que está siendo
capturado por un determinado dispositivo y escribir aplicaciones o algoritmos con ellos.
- Acceso a datos históricos y en tiempo real: Permite acceder a ambos tipos de datos
desde las APIs.
SAMI está ideada desde el principio para el prototipado rápido y la productividad de los
desarrolladores, contando con tecnologías Scala y el framework Play, además de emplear Akka para
la transformación de datos y capas WebSocket.
La clave para la capacidad de recuperación de la plataforma SAMI es su diseño como una

plataforma basada en microservicios con Akka. El uso de Akka para el aislamiento de componentes
de grano fino y Docker para el despliegue, SAMI está construida para la concurrencia, escalabilidad
y capacidad de recuperación (resiliencia), y se ejecuta sobre la máquina virtual de Java.
Las propiedades de aislamiento que Akka proporciona ayudan a proteger el sistema contra
fallos individuales, y también permite un modelo de implementación continua eficiente. Este
enfoque libera al equipo de desarrollo para crear rápidamente nuevas características sin tener que
mantener un monolito.
MBIGDA_M8T2_160727
182
SAMI está escrito para funcionar de forma asíncrona en la Máquina Virtual de Java (JVM). El
equipo cree en la fiabilidad y el diseño de la JVM para la concurrencia, y sintió que proporciona
importantes ventajas para el tipo de Streaming masivo requerido por SAMI. Con los dispositivos IoT,
algunos envían un punto de datos por día, mientras que otros envían miles de puntos de datos por
hora - y la JVM ha ayudado a soportar a SAMI millones de eventos por día.
Aproximadamente el 60% de SAMI está escrito en Scala, el resto en Java. El equipo eligió Scala,
ya que cree que el lenguaje es conciso, elegante y “typesafe” y que integra sin problemas
programación orientada a objetos y programación funcional. El equipo SAMI también aprecia las
fortalezas de Scala en el manejo de múltiples usuarios al mismo tiempo, sin bloqueos por esperar
una respuesta. Esta característica de Scala ajusta con SAMI en los requisitos de "always-on" para el
manejo de cualquier número de dispositivos concurrentes enviando millones de mensajes a la
plataforma.
Para las APIs y el desarrollo front-ed SAMI utiliza el framework Play. Play ha permitido la
implementación sencilla del manejo de peticiones sin estado (REST), reactivo, y asíncrono. El uso de
WebSockets en Play es muy importante para la plataforma SAMI, y la flexibilidad para el desarrollo
de las aplicaciones Java y Scala.
Akka está construido para ser un motor de ejecución y plataforma middleware para manejar la
concurrencia y escalabilidad sobre la JVM. SAMI utiliza Akka en dos niveles fundamentales: (1) a
nivel de la manipulación WebSocket, donde se utiliza actores dedicados a los clientes para cada
WebSocket, cada uno con un buzón que se procesa y se encola en Kafka; (2) en la capa de
transformación, donde los datos se envían en streaming y se normalizan. También se usa en gran
medida Apache Cassandra - base de datos NoSQL - que es distribuida, asíncrona y tolerante a fallos
por defecto, y tiene un fuerte vínculo con Akka.
11.4. IBM
IBM proporciona sus soluciones en nuevos modelos de negocio Cloud Computing a través de la
plataforma IBM Bluemix. Esta plataforma contiene soluciones y herramientas desplegables en
Cloud para TI. Las diferentes soluciones para IoT en Bluemix se pueden contratar en modelos de
MBIGDA_M8T2_160727
183
pago por uso, pueden ser de IBM o de proveedores externos, y comprenden (a día de hoy) los
siguientes productos:
11.4.1. Internet of Things platform Starter
Kit de inicio que contiene lo necesario para empezar a trabajar con una aplicación Internet of
Things Platform utilizando Node-RED en Bluemix. Dispone de un flujo de ejemplo con un simulador
y puede personalizarse para sus propios dispositivos.
- Context Mapping: El servicio IBM Watson IoT Context Mapping permite analizar los
movimientos y trayectorias de los objetos en movimiento mediante los servicios
geoespaciales basados en la red de carreteras. Proporciona interfaces de consulta en
tiempo real para acceder a datos de la red de carreteras y servicios de búsqueda
mediante la estructura de índice único y mecanismos de caché avanzada.
- MAP DATA QUERY: El servicio proporciona atributos de carretera, topología de la red, y
otra información estática de datos de mapa.
- GEOSPATIAL SERVICE: Este servicio incluye interfaces API REST para el realizar
búsquedas geoespaciales en mapas de tipo “matching”, camino más corto, y “búsqueda
enlazada”
11.4.2. Driver behaviour
Permite analizar el comportamiento de un conductor de un vehículo contemplando información

interna e información contextual. Se puede analizar el comportamiento como aceleraciones y
frenadas bruscas, frenado excesivamente frecuente, velocidad, giros bruscos y situaciones
parecidas.
11.4.3. Internet of Things Platform
El servicio IBM Internet of Things permite a las apps comunicarse con dispositivos conectados,
sensores y pasarelas, y consumir los datos que recopilan. A través de recetas hacen que sea muy
fácil conectar dispositivos a la nube de Internet of Things. Sus apps pueden utilizar las API REST y en
MBIGDA_M8T2_160727
184
tiempo real para comunicarse con los dispositivos y consumir los datos que ha configurado para
que recopilen.
Para que las apps puedan funcionar, primero se deben conectar los dispositivos. La plataforma
tiene un conjunto de instrucciones comprobadas o 'recetas' para conectar dispositivos, sensores y
pasarelas de una gran variedad de colaboradores y particulares.
Las comunicaciones entre los dispositivos y la nube se producen a través del protocolo abierto y
ligero MQTT. Por ejemplo, puede tener un sensor que recopile y envíe lecturas de humedad cada
minuto. Las API REST y en tiempo real le permiten obtener rápidamente los datos del dispositivo en
las apps para analizarlos.
Funcionamiento general de la s olución IoT Foundation
11.4.4. IoT for Electronics
Es un componente de la solución IoT for Electronics y no debe desplegarse por separado. Para
usar IoT for Electronics, debe instalarse previamente la solución IoT for Electronics Starter del
catálogo Bluemix.
MBIGDA_M8T2_160727
185
IoT for E lectron ics para una la vadora
11.4.5. IoT Realtime Insights
Plataforma de análisis de tiempo real le permite comprender los datos en su contexto y

supervisar las condiciones de los dispositivos y operaciones en tiempo real. IoT Realtime Insights
funciona con la plataforma de IoT para enriquecer y controlar los datos de dispositivos, visualizar lo
que está sucediendo ahora, y responder a las condiciones emergentes a través de acciones
automatizadas.
IoT Realtime Insights
MBIGDA_M8T2_160727
186
11.4.6. Flowthings.io
Es un proveedor externo integrado en BlueMix, proporciona una plataforma de CEP (Complex

Event Processing) similar al procesamiento de información en tiempo real, según ocurren eventos,
como la llegada de datos a la plataforma. Su propuesta contiene varias tecnologías para la conexión
de dispositivos o fuentes de datos y soluciones para aplicar sobre la información y publicar los
resultados o construir aplicaciones.
11.4.7. IQP Code-free APP development
Integrado con IBM Bluemix IoT Foundation recibe la información y permite construir
aplicaciones sobre internet de las cosas. La solución no requiere que se realice implementación de
código para desplegar soluciones sobre Internet de las cosas, gestionar los dispositivos y eventos, y
realizar visualizaciones de la información.
Esquema conceptual de la solución de IQP dispon ible en la plata forma BlueMix
11.5. Amazon
Amazon IoT es una forma segura, bidireccional de comunicación entre AWS y las cosas
conectadas a internet, como sensores, actuadores, dispositivos embebidos o dispositivos
MBIGDA_M8T2_160727
187
inteligentes. Permite recolectar datos de telemetría de diferentes dispositivos, almacenarlos en

AWS y analizarlos. Se pueden crear aplicaciones para que los usuarios controlen los dispositivos
desde interfaces de usuario como móviles o tabletas.
Los componentes de AWS IoT son:
- Broker de mensajería MQTT para publicar y suscribir mensajes, y HTTP REST para
publicar.
- Motor de reglas con expresiones tipo SQL sobre los mensajes para procesar la
información. Adicionalmente puede enviarse la información a otros sistemas de AWS
para utilizar su capacidad de almacenamiento y procesamiento.
- Registro de dispositivos para gestionar los dispositivos asociar recursos y atributos.
- Things Shadow, mantener una cache de estado del dispositivo, o versión virtual del
dispositivo, con la que las aplicaciones interactúan y que no requieren que el dispositivo
este permanentemente conectado, al conectase se sincroniza con su dispositivo
sombra en cloud.
- Gateway de comunicaciones para gestionar la comunicación con los dispositivos.
- Sistema de seguridad e identidad.
- SDKs y APIS.
Además de estos sistemas específicos, la solución de Amazon AWS es compatible con otros
servicios de Amazon como:
- Amazon Simple Storage Service: Almacenamiento escalable.

- Amazon DynamoDB: Base de datos NoSQL.
- Amazon Kinesis: Procesamiento de datos en tiempo real en Streaming.
- AWS Lambda: Ejecución de código en servidores virtuales.
- Amazon Simple Notification Service: Envío de notificaciones.
- Amazon Simple Queue Service: Colas de mensajería de Amazon para conectar
aplicaciones.
MBIGDA_M8T2_160727
188
12. Orientación a servicios

Como se ha indicado en los capítulos anteriores, existe una tendencia actual a proporcionar una
interacción centrada en la conexión o los datos (data-centric). En ambos modelos se interactúa con
los dispositivos, las plataformas, y las aplicaciones a través de servicios interoperables. Desde los
dispositivos y los protocolos, la orientación a servicios se va extendiendo o complementando.
El que el sistema este orientado a servicios no solamente afecta al usuario sino que permite
implementar estos servicios con principios de interoperabilidad que permiten a las plataformas
interactuar con otros sistemas o servicios.
Cada módulo o subsistema podrá ofrecer servicios de datos, servicios para la administración, la
gestión y configuración, que en cada caso según el enfoque de la plataforma serán asumidos y
ofrecidos a unos participantes u otros, o incluso a los usuarios finales.
El nivel de desarrollo de las herramientas de administración de los servicios, su sofisticación y su

enfoque son aspectos claves en un proyecto de IoT, y deben ser tenidos en cuenta en la elección,
junto con las operaciones técnicas de administración necesarias en la provisión de los servicios.
La tendencia actual es proporcionar, aplicaciones de gestión o administración que interactúan

con la plataforma a través de APIS de servicios interoperables de tipo REST / JSON, de manera que
existe una independencia entre la aplicación de gestión y los servicios, y permite el recorrido
necesario en cada área para orientar la plataforma al caso de uso concreto.
MBIGDA_M8T2_160727
189

Contenido Extendido Dispositivos, Tecnologías de Adquisición de Datos y Redes

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

Contenido Extendido Dispositivos, Tecnologías de Adquisición de Datos y Redes

Cargado por

Copyright:

Formatos disponibles

Contenido Extendido Tema 2.

Docente autor: Adolfo Cortés

4.3. Wearables y BAN ........................................................................................................................... 30

6.1. CWMP ............................................................................................................................................ 42

8. Nivel de red ....................................................................................................................................... 85

9.4.8. Cancelar una suscripción ........................................................................................................................ 127

9.7. Smart Energy Protocol (SEP2.0)................................................................................................... 143

10.1.8. Procesamiento / Análisis .................................................................................................................... 166

10.2. Bases de datos y propiedades ACID en IoT ................................................................................. 166

11.5. Amazon ........................................................................................................................................ 187

Tema 2. Dispositivos, tecnologías de adquisición de datos

Estos dispositivos generalmente son de características muy diversas orientadas a las

De alguna forma es necesario proporcionarles conectividad a Internet, algunos enviarán datos a

Caracter ísticas de d ispositivos IoT

interconexión LAN cableada o inalámbrica. En caso de conexión WAN se requiere el uso de un

Tipo CPU Memoria Alimentación Comunicaciones Sistema operativo

Dispositivos tip o por su tecno log ía y capac idades

A menudo el dispositivo completo es integrado en un chip (SoC), la alimentación en algunos

Un ejemplo es el protocolo RIAC desarrollado conjuntamente con EMASA (Empresa Municipal

Medidores de agua Contazar a

Este protocolo forma una red auto-configurable inteligente de sensores inalámbricos. Es un

Las funcionalidades de este dispositivo incluyen algunos aspectos de los citados:

- Medición precisa durante el tiempo de servicio requerido.

Los servicios que ofrece directamente el dispositivo son:

- Fecha y hora de lecturas

Sistemas Operativos frecuentemente usados en dispositivos

Sistemas operativos usados en dispositivos básicos

Este tipo de dispositivos implican el uso de software no estándar y limitan la participación de

3.1. Gateways o Pasarelas

Ejemplos de estos elementos de red son:

Las aplicaciones embebidas suelen proporcionar funcionalidades como alarmas,

Existen numerosas implementaciones en diversos lenguajes de CoAP abiertas para cliente,

Ejemplo de Módulo Z igBee pa ra dispos itivo

Zigbee incluye perfiles de aplicación, como lectura automática, automatización de edificios

Ejemplo de dispos itivo Z igBee sobre 802.15.4

Un aspecto relevante de ZigBee es la variedad de dispositivo en cuanto a la capacidad del

- Dispositivo de funcionalidad completa (FFD): También conocidos como nodo activo. Es

capacidad de computar, puede funcionar como Coordinador o Router ZigBee, o puede

También se aprovecha la capacidad de procesamiento para dotar a los dispositivos avanzados

Estos dispositivos por su capacidad de cómputo presentan un stack de red de buenas

- Dispositivos con batería que usan conexiones celulares de consumo de batería

4.1. Prototipos y dispositivos genéricos.

se encuentran Arduino o Raspberry PI, permiten realizar fácilmente prototipos o demostradores.

El hardware se presenta en un circuito impreso con un microcontrolador, usualmente Atmel

El microcontrolador de la placa se programa a través de un ordenador personal, haciendo uso

Ejemplo de pla ca Arduino

Existen muchas placas o versiones de Arduino, y un conjunto de extensiones hardware para

Está basado en un System-on-a-chip que contiene un procesador central (CPU), un procesador

Soporta una gran cantidad de distribuciones de sistemas operativos, software y dispone de

La capacidad de un sistema Raspberry Pi permite montar sobre el un sistema operativo, un

4.1.3. Cinterion Gemalto Concept Board

En el campo del desarrollo de prototipos y pruebas de concepto, Gemalto dispone de Cinterion

Cin terion Gemalto Con cept Bo ard

La placa dispone de:

8 GPIO, 2G/3G, Java™ ME embebido, es compatible con un conjunto de shields Arduino, y

4.1.4. Intel GALILEO GEN 2 DEVELOPMENT BOARD

Dispone de interfaces I / O estándares de la industria, incluyendo ranura mini-PCI Express, 100

En software y sistema operativo, el kit de desarrollo incluye C, C ++, Python, y Node.js /

4.1.5. Intel Edison DEVELOPMENT BOARD

Las funciones integradas de Wi-Fi, Bluetooth Low-Energy (LE), memoria y almacenamiento

Para los sensores o extensiones disponen de una biblioteca de productos / proveedores de

4.1.6. GlobalCode IoT Surfboard

Basada en Arduino Nano, con microcontrolador Amtel ATMega a 16Mhz, y de 32 KB de