IoT Roadmap

Ines Robles (maria.ines.robles@ericsson.com)

`
Gustavo Mercado (gmercado@frm.utn.edu.ar)
Alvaro Retana (aretana@cisco.com)
IoT is Here Now – and Growing!
A World of Sensors
Predictive
Maintenance
High-Confidence
Transport and
Energy Saving Asset Tracking
Smart Grid
Improve
Intelligent Productivity
Enable New Buildings
Knowledge Enhanced Safety &
Improve Food Security
and H2O
Healthcare
Smart Home
S+CC
The Investment in IoT Starts With One “Killer App”…

MANUFACTURING SMART CITIES TRANSPORTATION

Operational Efficiency New Revenue Regulatory Compliance

4
 Internet of Things
• Standardise IP into sensors and other objects

• Any object or environmental condition can be

monitored

• Give silent things a voice…(make them Smart

Objects)
Smart Object
Networks

MTC
Low Power &
Lossy
Enabling Technologies
Networks

Routing Protocol for LLNs (RPL)

Internet of Things
Lightweight Constrained
Application Protocol
M2H
Sensor
Networks Protocols (COAP)
Embedded Network O/S
COAP Simple Management
Prorocol (CSMP)
Contiki uIPv6
M2M 6LowPAN
 What is a Low Power Lossy Network (LLN)?
• LLNs comprise a large number of highly constrained devices (smart objects) interconnected by
predominantly wireless links of unpredictable quality
• LLNs cover a wide scope of applications
• Industrial Monitoring, Building Automation, Connected Home, Healthcare, Environmental Monitoring,
Urban Sensor Networks, Energy Management, Asset Tracking, Refrigeration

World’s smallest web server

IoT/M2M Transition M2M
Market Drivers Architectural Philosophy
From To
1 Moving towards ubiquitous Autonomous/Closed systems Open Systems with distributed
computing, intelligence and using proprietary technologies intelligence based on
networking capabilities in all things with minimal Cisco services standardized network layers (IP,
interaction Ethernet, PLC etc…)
2 IP replacing proprietary protocols in the
IoT space (M2M/M2H) dramatically
increasing IPv6 relevance

3 Secure, reliable, quality connectivity

everywhere through multiple
technologies
(Fixed/Mobile/Wireless/Small Cells
etc..)

4 New partnerships between M2M

vendors & SP/Utility Providers
 When You Connect the Unconnected, Everything Changes…..

People Process
Connecting People Delivering the Right
in More Relevant, Information to the Right
Valuable Ways Person (or Machine) at the
Right Time

Data Things
Leveraging Data into More Physical Devices and Objects
Useful Information for Connected to the Internet and
Decision Making Each Other for Intelligent
Decision Making (IoT)

Source: “The Internet of Everything: A $19 Trillion Opportunity,” Cisco Consulting Services, 2014
Technology Trends are Enabling Business in New Ways

How do I cut cost and
improve my business?
How do I create a more How can I create
How do I make better
engaged and productive personalized customer
decisions… faster?
workforce? experiences?

Cloud Mobile Social Data

Create a Secure, Create one-to-one Gain Access and Insight
Enable a Secure,
Optimized, Cloud- connections with from Distributed Data to
Mobile Workforce
Enabled Infrastructure Customers Anytime Speed Decisions

Security
How do I handle a dynamic threat landscape
created by increased connections? Protect Valuable Assets and Reputation
in Real-Time
11
Cities Have Traditionally Addressed These Issues in Silos

Every city department makes investments independently resulting in:

§ No sharing of infrastructure costs and IT resources
§ No sharing of intelligence/information, e.g., video feeds, data from sensors, etc.
§ Waste and duplication of investment and effort
§ Difficulty in scaling infrastructure management

Traffic Public City Pollution/ Waste Parking

management safety lighting environment management optimisation

This fragmented approach is inefficient, has limited effectiveness, and is not 15

economical
City Infographics
Municipal Command Factory
& Control Center Optimization

Cloud &
Services
Smart Logistics
Grid Home Energy Optimization
Lighting Mgmnt
Building
Poles
Optimization
Traffic Flow
Optimization

City
WiFi
INTELLIGENT INTELLIGENT
CITY Community
INTELLIGENT
Building INTELLIGENT
HIGHWAY Traffic
Parking Connected Automated Cameras
Ambulances Intelligent Digital Car System
Signage
Source:16Intel
IoT Standardization
(…at the IETF...)
 IETF Organization: Areas
• ...activities focused on supporting, updating and maintaining the IETF standards
General Area (gen) development process.

• ...focused on security protocols...services: integrity, authentication, non-

Security (sec) repudiation, confidentiality, and access control...key management is also vital.

•Protocols for delay-sensitive communications, and building blocks to be used

Applications and Real Time (art) across a wide variety of applications.

• Network Management, AAA, and various operational issues facing the Internet
Operations & Management (ops) such as DNS, IPv6, operational security and Routing operations.

Transport Services (tsv) • ...works on mechanisms related to end-to-end data transport...

Routing (rtg) • ...responsible for ensuring continuous operation of the Internet routing system...

• ...IP layer (both IPv4 and IPv6), DNS, mobility, VPNs and pseudowires..., and
Internet (int) various link layer technologies.
IoT at the IETF
Area Working Group

SEC Authentication and Authorization for

Constrained Environments (ace)
ART Constrained RESTful Environments (core)

RTG Routing Over Low power and Lossy networks

(roll)
INT IPv6 over Networks of Resource-constrained
Nodes (6lo)
INT IPv6 over the TSCH mode of IEEE 802.15.4e
(6tisch)
INT Light-Weight Implementation Guidance (lwig)

IRTF Thing-to-Thing Research Group (t2trg)

Low Power WAN (LPWAN)
Connectivity Options
Connectivity Options
LPWAN Context
• Growth in IOT end-points
• Device & Service Characteristics
• Low-cost, power-constraint, low data-rate, low delay sensitive, long
range, battery operated, long life
• LPWAN Technologies are designed for supporting such
communication profile. Technologies such as LoRAWAN, SIGFOX
and NB-IOT are gaining good traction.
• Bluetooth, ZigBee, Wi-Fi are short-range technologies, works for
consumer devices, but not suited for Industrial IOT applications,
which require long range access.
 LoRA Overview
• LoRA is a type Wireless modulation for long-range, low-power, low-data-
rate applications developed by Semtech.
• LoRaWAN network architecture, gateways is a transparent bridge
relaying messages between end-devices and a central network server in
the backend.
• Gateways are connected to the network server via standard IP
connections while end-devices use single-hop wireless communication to
one or many gateways.
 LoRA Overview (Continued …)
• Communication between end-devices and gateways on different
frequency channels and data rates. LoRa data rates range from 0.3 kbps
to 50 kbps.
• LoRa network infrastructure can manage the data rate and RF output for
each end-device individually by means of an adaptive data rate (ADR)
scheme.
Medium/Short Range
Wireless Standards
BLE
IEEE 802.15.4

• Low Rate Wireless Personal Area Network

(LoWPAN)
• Important standard for home networking,
industrial control and building automation
• Deals with low data rate, long battery life
(months or even years) and very low
complexity
• Data rates of 250kbps, 40kbps, and 20kbps
• Specifies PHY and MAC layers for
LoWPAN networks
6LoWPAN
IPv6 over Low Power Personal Area Networks (6LoWPAN)

• 6LoWPAN is an adaption layer

for IPv6 over IEEE 802.15.4
links, not a protocol stack, full
solution for smart object
networks!
• Why do we need an adaptation
layer ?
• IEEE 802.15.4 MTU is 127
bytes
• Functions:
• Packet fragmentation and re-
assembly
• Header compression
 6LoWPAN Fragmentation
• 802.15.4-2006 has a link MTU of 127 bytes

• IPv6 requires a min link MTU of 1280 bytes

è 6LoWPAN must provide fragmentation

Disp

802.15.4 IPv6 Datagram

Disp
802.15.4 Frag IPv6 Datagram (Frag 1)

802.15.4 Frag IPv6 Datagram (Frag 2)

802.15.4 Frag IPv6 Datagram (Frag N)

 6LoWPAN Header Compression
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

IPv6 Header 0 Ver Traffic Class Flow Label

4 Payload Length Next Header Hop Limit
8
12
16 Source Address
24
28
32
36 Destination Address
40

• Use little state and do not depend on flows

• Common values for header fields => compact forms

• Version is always 6
• Traffic Class and Flow Label may be elided
• Payload Length always derived from L2 header
• Source and Destination Addrs are link-local and derived from L2 addrs
6LoWPAN Header Compression
• UDP Header
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

0 Source Port Destination Port

4 Length Checksum

• Assume common values for header fields and define compact forms
• Ports within 61616 to 61632 (4 bits)
• Length derived from IPv6 Length
• Checksum may be elided if other integrity checks are in use (e.g. Ipsec)

• No specification for TCP or ICMPv6

• C (Checksum): 0: Inline, 1: Elide

• P (Ports):
• 0: Inline
• 1: Elide first 8 bits of Dest Port
• 2: Elide first 8 bits of Source Port
• 3: Elide first 12 bits of Source and Dest Ports
 Example: Link-Local Unicast

Len = 50 FCF DSN DSTPAN

Link Hdr
DST = 00-17-3B-00-AA-BB-CC-DD
SRC = 00-17-3B-00-11-22-33-44

Ver = 6 Traffic Class = 0 Flow Label = 0

IPv6 Hdr
Payload Length Next Header = UDP Hop Limit = 1
Source Prefix = fe80::/64
Derived from link hdr
Source IID = 0217:3B00:AABB:CCDD
Compact forms
Dest Prefix = fe80::/64
Dest IID = 0217:3B00:1122:3344

UDP Hdr Source Port Destination Port

Length Checksum

1 2 1 1 2
Checksum
UDP-HC
IP-HC

Ports
Disp

802.15.4 48-byte UDP/IPv6 Hdrè 7 bytes

 Example: Global Unicast

Len = 50 FCF DSN DSTPAN

Link Hdr
DST = 00-17-3B-00-AA-BB-CC-DD
SRC = 00-17-3B-00-11-22-33-44

Ver = 6 Traffic Class = 0 Flow Label = 0

IPv6 Hdr
Payload Length Next Header = UDP Hop Limit = 23
Source Prefix = 2001:5a8:4:3721::/64
Derived from link hdr
Source IID = ::1234
Compact forms
Dest Prefix = 2001:5a8:4:3721::/64
Dest IID = ::ABCD Derived from context

UDP Hdr Source Port Destination Port

Length Checksum

1 2 1 2 2 1 1 2

Checksum
Hop Limit

UDP-HC
Source
IP-HC

Ports
Addr

Addr
Dest
Disp

802.15.4 48-byte UDP/IPv6 Hdr è 12 bytes

RFC 6282: 6LoWPAN IPv6 Header
Compression
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

0 1 1 TF NH HLIM CID SAC SAM M DAC DAM

Addressing

TF 2 bits Traffic Class and Flow Label

NH 1 bit Next Header
HLIM 2 bits Hop Limit
CID 1 bit Context Identifier Extension
SAC 1 bit Source Address Context
SAM 2 bits Source Address Mode
M 1 bit Multicast Address Compression
DAC 1 bit Destination Address Context
DAM 2 bits Destination Address Mode

2
RFC 6775 6LoWPAN ND (bis)

• Multicast Avoidance
• Registration for DAD, distributed database for lookup
• Binding (location, owner, MAC) to IPv6 address
• Registrar hierarchy for lookups and policy enforcement
 • Schedule => direct trade-off between throughput, latency and power consumption. A
• A collision-free communication schedule is typical in industrial applications.
• IEEE802.15.4e published April 2012.
C B
16 channel offsets

E
D

F
G

I
e.g. 31 time slots (310ms)
H

J
© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 31
Channel Hopping :
• retry around interference,
• round robin strategy

Time Slotted (or Synchronized) :

• Deterministic: through TDM, Synchronized + Time formatted in SlotFrame(s)
• Tracks: below IP, can be orchestrated by a third party like virtual circuits
• Slotted: benefits of slotted aloha vs. aloha => reduce chances of collisions
• Battery operation: when traffic profile is known, devices only wake upon need
A schedule is a matrix of cells, each of them
indexed by a slotOffset and a channelOffset Absolute Slot Number
ASN

0 1 2 3 4 5

33
A schedule is a matrix of cells, each of them
indexed by a slotOffset and a channelOffset

0 1 2 3 4 5

A single slot is long enough for the Tx to send a

maximum length packet and for the RX to send
back an ACK
34
 Example slot 9.976 ms

2.120ms ≤ 4.256ms 0.800ms 0.400ms

T1 T2 T3 T4
TsCCAOffset AWT
RX
Transmitter CCA TX Packet prepare to receive AC
K
TsRxAckDelay

TsTxOffset

Receiver prepare to receive RX Packet process packet, TX ACK

prepare to ack
TsRxOffset PWT
TsTxAckDelay
R1 R2 R3
End
Start 2.000ms 2.400ms of
of timeslot
timeslot 9.976ms
receiver on
transmit
receive

35
 IoT Uses Cases:
Real deployments and applications
Gustavo Mercado
gmercado@frm.utn.edu.ar
UTN FRM
Mendoza - Argentina
 IoT Uses Cases
• Hardware usado en IoT
• CIAA IoT Gateway
• Save the Peaches
• Smart Grid San Martin
• Smart City Bicing
CIAA IoT Gateway
 IoT Uses Cases: CIAA IoT Gateway

• Proyecto «GW-CIAA-IoT: Gateway con CIAA para red

inalámbrica de IoT»
 IoT Uses Cases: CIAA IoT Gateway
• Proyecto «GW-CIAA-IoT: Gateway con CIAA
– Financiado por Mincyt Ar
• Requisito: USAR CIAA

Computadora Industrial Abierta Argentina Open Mote CC 2538

Es Industrial, ya que su diseño está preparado para

las exigencias de confiabilidad, temperatura, • Open Source Friendly.
vibraciones, ruido electromagnético, tensiones, • Open Hardware
cortocircuitos, etc., que demandan los productos y
• 32-bit Cortex-M3
procesos industriales.
Es Abierta, ya que toda la información sobre su • 32 Kbytes of RAM
diseño de hardware, firmware, software, etc. está • 512 Kbytes of Flash
libremente disponible en internet bajo la Licencia • CC2520-like radio transceiver
BSD, para que cualquiera la utilice como quiera. • IEEE 802.15.4-2006
 IoT Uses Cases: CIAA IoT Gateway
Software
Open Mote CIAA
Sistemas Operativos con porting:
(LPC4337 de la CIAA-NXP)
OpenMote soporta • Linux (*)
• OpenWSN • FreeRTOS
• Contiki • BareMetal
• FreeOSEK (CIAA's Firmware)
• freeRTOS
• Riot OS En FreeRTOS y CIAA Firmware
hay porting de LwIP IPv4
LwIP: lightweight IP: Stack TCP/IP open
Se elige Contiki source TCP/IP diseñado para sistemas
embebidos.
• Buen comportamiento con Open
Mote Se elige
• Se han hecho ensayos • FreeOSEK (CIAA's Firmware)
• Implementado 6LoWPAN, RPL, etc Alternativa
• FreeRTOS
IoT Uses Cases: CIAA IoT Gateway

IPv6 (IPv4)

UART

IEEE 802.15.4
CIIA Gateway
RT-SO: Free OSEK
IP Stack: LwIP

Open Mote
RT-SO: Contiki
Save the Peaches
 IoT Uses Cases: Save the Peaches
• Predicting Frost Event in Peaches Orchad
– UTN (Argentina)
– UDP (Chile)
– INRIA (Francia)
– INTA (Argentina)
• Objetivos
– Predicción localizada de las heladas mediante la construcción de un
modelo de aprendizaje automático a partir de datos microclimáticos
de una red de sensores
– Instalar un prototipo de red de sensores para medir las variables
climáticas involucradas
– Realizar campañas de medición e instalación
Peaches don’t like frost

• Peaches- UTN-UDP-INRIA
2013

before

after

85% peach production loss ∙ 10,000 jobs ∙ 100M USD

Real Time Monitoring System

•air temp
•air RH
•soil temp
•soil moisture

state-of-the-art proposed solution

1.A low-power wireless sensor system

2.Real-time data collection
3.Machine learning to predict frost events
We have the networking technology!

• >50,000 SmartMesh networks deployed

• >99.999% end-to-end reliability
• >10 years of battery lifetime
• Developed as part of the REALMS associate team
Network Architecture
Deployment Site
Smart Grid San Martin
 IoT Uses Cases: Smart Grid
• El concepto de Red Eléctrica Inteligente (Smart
Grid) especifica la adición de inteligencia y la
comunicación digital en dos vías a la red eléctrica
para mejorar significativamente la eficiencia del
sistema, la confiabilidad y la seguridad.
– Algunas funciones de la Red Eléctrica Inteligente:
• Medición inteligente (Smart Metering).
• Detección rápida de fallas y remediación automatizada.
• Tarifas en tiempo real.
• Respuesta a la demanda.
• Mayor incorporación de fuentes de energía renovables.
 IoT Uses Cases: Smart Grid - San Martín Mendoza
PLANTA
FOTOVOLTÁICA
500KW RECOLECCIÓN Y
ADMINISTRACION
APLICACIONES AUTOGENERACIÓN DE DATOS
4 módulos total 30KW

TELECONTROL
RED MT TELEMEDICIÓN
20 PUNTOS 10 salidas
COMUNICACIONES
MEDIDORES
INTELIGENTES
4500

ILUMINACIÓN
TELEMEDICIÓN EFICIENTE
90 CTs 200 LED - 50 Telegestión ADECUACIÒN
SCADA
 IoT Uses Cases: Smart Grid - San Martín Mendoza

Telecomando
Compra - Venta - Scada - GIS - Conocimiento
– Facturación Sistemas Operación Capacidades,
Experiencias,
Sistema Integración Eficiencia,
Sistemas

SOCIEDAD - ESTADO
Prepago Modelo
USUARIO ACTIVO
USUARIO PASIVO

Balance-Curva de Administración
Gen.Dist. Replicable
Carga-Proyección-
Comportamiento

Sistema de Gestión de Datos CIM Normas,

Incentivos,
Sistemas de Recolección de Datos Multitarifas
Control C.S.
Sistemas de Comunicaciones

Medidores Registradores Gen. Fuentes

Medidores Telecomando
Inteligentes en Multivariables Renovables
Convencionale Red MT-BT Salidas y Red
Salidas MT
Usuarios Finales en CTs, Nodos Distribuida -
s M.T.
y AP MT Autogeneración
RED ELÉCTRICA TRADICIONAL
RED ELÉCTRICA INTELIGENTE
Smart City Bicing
 IoT Uses Cases:
Mendoza Smart City Bicing
• Smart City Bicing
– Prototipo de Bicicletas públicas
– Convenio entre Municipalidad de Mendoza, UTN y MyT S.A
Triangulo de Sábato
– Municipalidad
• Gestión del sistema
• Contribuye con parque de bicicletas
– MyT SA
• Contribuye con bahías de gestión automática
– UTN
• Software de Comunicación Bahía-Centro de Datos Municipal
• Propuesta de Estándar de Comunicación/Gestion de bicicletas publicas
Mendoza Smart City Bicing
 IoT Uses Cases:
Real deployments and applications
Gustavo Mercado
gmercado@frm.utn.edu.ar
UTN FRM
Mendoza - Argentina
Desafíos de IoT
Gustavo Mercado
gmercado@frm.utn.edu.ar
UTN FRM
Mendoza - Argentina
 Desafíos de IoT
–Seguridad
–Privacidad
–Interoperabilidad / Estándares
–Cuestiones Legales, Reglamentarias y
de Derechos
–Cuestiones Relacionadas con las
Economías Emergentes y el Desarrollo
Fuente: La Internet de las Cosas — Una Breve Reseña, Karen Rose, Scott Eldridge, Lyman Chapin, ISOC,
Oct 2015
 Desafíos de IoT: SEGURIDAD
• El desafío de seguridad de la IoT
– garantizar la seguridad, la confiabilidad, la resiliencia y la estabilidad
Cada dispositivo mal asegurado conectado en línea potencialmente afecta la
seguridad y la resistencia de Internet a nivel global, no solo a nivel local
• Un espectro de consideraciones de seguridad
– La seguridad de la IoT es un espectro de vulnerabilidad de los
dispositivos
• dispositivos totalmente desprotegidos sin ninguna función de seguridad
• sistemas muy seguros con múltiples capas de elementos de seguridad.

• Desafíos de seguridad que son exclusivos de los dispositivos de

la IoT
– Despliegues de dispositivos a una escala masiva
– Homogeneidad en gran cantidad de dispositivos
– Vida útil anticipada muy superior a la media
 Desafíos de IoT: SEGURIDAD
• Preguntas relacionadas con la seguridad de la IoT
– Buenas Prácticas de Diseño
• ¿Cuáles son las mejores prácticas?
• ¿Cómo se recogen y transmiten las lecciones aprendidas?
• ¿Qué formación y recursos educativos se pueden utilizar?
– Equilibrio Entre Costo y Seguridad
• ¿De qué manera las partes interesadas toman decisiones?
• ¿Cómo se pueden cuantificar y evaluar con precisión los riesgos de
seguridad?
• ¿Qué motivará a los diseñadores y fabricantes para que acepten el costo
adicional?
• ¿Cómo se van a conciliar las incompatibilidades entre la funcionalidad y la
facilidad de uso y la seguridad?
• ¿Cómo nos aseguramos de que las soluciones de seguridad soporten
oportunidades para la innovación, sociales y de crecimiento económico?
 Desafíos de IoT: SEGURIDAD
• Preguntas relacionadas con la seguridad de la IoT
– Estándares e Indicadores
• ¿Qué papel desempeñan los estándares técnicos y operativos en el
desarrollo y despliegue de dispositivos de la IoT seguros y de buen
funcionamiento?
• ¿Cómo se pueden identificar y medir las características de seguridad de
los dispositivos de la IoT?
– Confidencialidad de los Datos, Autenticación y Control de
Acceso
• ¿ Cuál es el papel óptimo del cifrado de los datos con respecto a los
dispositivos de la IoT?
• ¿Utilizar tecnologías de cifrado, autenticación y control de acceso en los
dispositivos de la IoT es una solución adecuada
– Capacidad de Actualización en Campo
• ¿ Los dispositivos deben diseñarse considerando su mantenimiento y su
capacidad de actualización in situ?
 Desafios de IoT: PRIVACIDAD
Es fundamental abordar estos problemas de privacidad, dado que tienen
implicaciones sobre nuestros derechos básicos y nuestra capacidad colectiva
de confiar en Internet.

• Aspectos relacionados con la privacidad que solo se

aplican a la Internet de las Cosas
– IoT aumenta la visibilidad y el alcance de la vigilancia y el
seguimiento.
– modifican drásticamente cómo se recogen, analizan,
utilizan y protegen los datos personales
 Desafios de IoT: PRIVACIDAD
• Preguntas relacionadas con la PRIVACIDAD de la IoT
– Legitimidad en la recopilación y el uso de los datos
• ¿cómo se resuelve la relación de mercado entre las fuentes de los datos y
quienes los recogen?
– Transparencia, expresión y cumplimiento de las preferencias de
privacidad
• ¿Cuáles son las alternativas al modelo tradicional de privacidad de
“notificación y consentimiento” que podrían abordar los aspectos únicos
de la Internet de las Cosas?
– Privacidad por diseño
• ¿Cómo se puede animar a los fabricantes de dispositivos de IoT para que
incorporen los principios de la privacidad por diseño a sus valores
fundamentales?
Desafíos de IoT: INTEROPERABILIDAD /
ESTÁNDARES

La interoperabilidad eficaz y bien definida de los dispositivos puede

fomentar la innovación y ofrecer eficiencias a quienes fabrican dispositivos,
aumentando así el valor económico total del mercado.
Desafíos de IoT: INTEROPERABILIDAD /
ESTÁNDARES
• Consideraciones clave y desafíos en la
Interoperabilidad de la IoT / Estándares
– Los Ecosistemas Propietarios y la Elección del Consumidor
– Limitaciones Técnicas y de Costos
– Riesgos Asociados con los Tiempos al Mercado
– Dispositivos mal Comportados
– Sistemas Heredados
– Configuración
– Proliferación de los Esfuerzos de Estandarización
Desafíos de IoT: CUESTIONES LEGALES,
REGLAMENTARIAS Y DE DERECHOS

La Internet de las Cosas plantea nuevas preguntas regulatorias y legales y

puede amplificar los desafíos legales que ya existen en torno a internet.
Promover la capacidad de los usuarios para conectarse, hablar, innovar,
compartir, elegir y confiar es una consideración fundamental para la
evolución de leyes y reglamentos.
Desafíos de IoT: CUESTIONES LEGALES,
REGLAMENTARIAS Y DE DERECHOS
• Consideraciones clave y desafíos en Cuestiones Legales,
Reglamentarias y de Derechos
– Protección de datos y flujos de datos transfronterizos
– Discriminación de los datos de la IoT
– Los dispositivos de la IoT utilizados como ayudas para las
agencias de aplicación de la ley y la seguridad pública
– Responsabilidad por los dispositivos de la IoT
– Proliferación de dispositivos de la IoT utilizados en acciones
legales
 Desafios de IoT: CUESTIONES RELACIONADAS
CON LAS ECONOMÍAS EMERGENTES Y EL
DESARROLLO
La IoT encierra una gran promesa como habilitador del desarrollo social,
incluyendo el logro de los Objetivos de las Naciones Unidas para el
Desarrollo Sostenible

• Garantizar que las oportunidades de la IoT sean

globales
• Oportunidades económicas y de desarrollo
 CÓMO APROVECHAR LA IOT PARA
EL DESARROLLO GLOBAL
La Internet de las Cosas (IoT) se está
desplegando alrededor del mundo para
resolver algunos de los problemas de
desarrollo más urgentes a nivel global y para
mejorar la prestación de servicios:
• Alivio de la pobreza
• Gestión sostenible del agua y el
saneamiento.
• IoT representa la próxima frontera para las tecnologías de la información y la comunicación
(TIC) para el desarrollo (ICT4D).
• A medida que los dispositivos y servicios continúen volviéndose más asequibles, crecerán las
intervenciones de la IoT en el desarrollo (IoT4D).
• IoT como herramienta para alcanzar los Objetivos de Desarrollo del Milenio de las Naciones
Unidas (ODM) y los Objetivos de Desarrollo Sostenible (ODS)
Fuente: “Harnessing the Internet of Things for Global Development”, por Cisco y la Comisión de la Banda Ancha para el Desarrollo Sostenible de la
UIT/UNESCO
 Desafios de IoT: CUESTIONES RELACIONADAS
CON LAS ECONOMÍAS EMERGENTES Y EL
DESARROLLO
• Preguntas sobre la IoT y su relación con las economías
emergentes y el desarrollo
– Recursos de Infraestructura
• ¿En qué medida la Internet de las Cosas ejercerá presión sobre la infraestructura y
los recursos de Internet y las telecomunicaciones?
• ¿Los desafíos actuales frenarán las oportunidades de la IoT en las regiones
emergentes?
– Inversión
• ¿Hasta qué punto el mercado impulsará la inversión en implementaciones de la IoT
en los países en desarrollo, sobre todo más allá de las aplicaciones en industrias y
entornos con una clara perspectiva de retorno a corto plazo?
– Desarrollo Técnico y de la Industria
• ¿En qué medida están participando investigadores y emprendedores de los países
emergentes en el desarrollo técnico y el despliegue de la IoT?
– Coordinación Regulatoria y de Políticas
• ¿Qué información y recursos necesitan ahora los formuladores de políticas de las
economías emergentes para tener en cuenta las exigencias de políticas y otras
preguntas que surgirán con el crecimiento de la IoT?
Desafios de IoT:

Gustavo Mercado
gmercado@frm.utn.edu.ar
UTN FRM
Mendoza - Argentina
 RPL- Routing over Low
Power and Lossy Networks
 Questions to answers today

1. What is RPL and how does it work?

2. Why couldn't we do this with other (IETF) routing protocols?

3. What are some applicability examples/real life deployments?

 Questions to answers today

1. What is RPL and how does it work?

2. Why couldn't we do this with other (IETF) routing protocols?

3. What are some applicability examples/real life deployments?

LLN: Low-Power and Lossy Network
“ LLN: Low-Power and Lossy Network. Typically composed of many embedded devices with limited

power, memory, and processing resources interconnected by a variety of links, such as IEEE

802.15.4 or low-power Wi-Fi. There is a wide scope of application areas for LLNs, including

industrial monitoring, building automation (heating, ventilation, and air conditioning (HVAC),

llighting, access control, fire), connected home, health care, environmental monitoring, urban

sensor networks, energy management, assets tracking, and refrigeration.” RFC 7228

IPv6 over Low power WPAN

6LBR (6LowPAN Border Router)
(6lowpan) - IPv6 compressed

6LR (6LowPAN Router)

6LN (6LowPAN Node)

 Is a protocol vector distance

The term distance vector refers to the fact that the protocol

manipulates vectors (arrays) of distances to other nodes in

the network

RPL
Is source routing
Allows a sender of a packet to partially or completely specify
the route the packet takes through the network.

Enables a node to discover all the possible routes to a host.

RPL organizes a topology as a...

Directed

Acyclic

Graph

(DAG) That is....

...Partitioned into one or more...

DODAG
root Destination

Oriented

DAGs

(DODAG)
A DAG rooted at a single destination at a single
DAG root (DODAG root) with no outgoing edges
A RPL Instance is a set of one or more
DODAGs that share a RPLInstanceID.

DODAG
root

(DODAG) (DODAG)

RPL Instance
To Identify and maintain a topology RPL uses...

(DODAG) (DODAG)

RPL Instance
To Identify and maintain a topology RPL uses...

(DODAG) (DODAG)

RPLInstanceID is a unique identifier within a network. DODAGs with

the same RPLInstanceID share the same Function (OF) used to
compute the position of node in the DODAG .
To Identify and maintain a topology RPL uses...

DODAGID

(DODAG) (DODAG)

RPLInstanceID is a unique identifier within a network.

To Identify and maintain a topology RPL uses...

DODAGID DODAGVersionNumber

A DODAG Version is a
specific iteration of a DODAG
with a given DODAGID

A DODAGVersionNumber
Is a sequential counter that is
incremented by the root to
form a new version

(DODAG) (DODAG)

RPLInstanceID is a unique identifier within a network.

 To Identify and maintain a topology RPL uses...

DODAGID DODAGVersionNumber

A DODAG Version is a
Rank specific iteration of a DODAG
+ - with a given DODAGID
Defines the rank=1

node's A DODAGVersionNumber
rank=2 Is a sequential counter that is
Individual
position incremented by the root to
form a new version
Relative to
other nodes
with respect to
DODAG root rank=3

(DODAG) (DODAG)

RPLInstanceID is a unique identifier within a network.

Grounded and Floating DODAG

● A grounded DODAG offers connectivity to hosts that are

required for satisfying the application goal
● A floating DODAG is not expected to satisfy the goal, it
only provides routes to nodes within the DODAG. e.g,
provide interconnectivity during repair
Downward traffic: Storing (fully stateful) or Non-Storing (fully
source routed)

Any given RPL Instance is either storing or non-storing.

Storing: The packet may be directed Down towards the

destination by a common ancestor of the source and the
destination prior to reaching a DODAG root.

Non-Storing: the packet will travel all the way to a DODAG root
before traveling Down
 Storing and Non-Storing
Mode-of-Operation
● A storing LLN keeps a downward routing table at each node.
○ traffic travels only as far as common parent.
○ storing mode limited by size of routing table
■ nodes with lower rank, have bigger tables!
■ protocol fails when any table is full.
● A non-storing LLN sends all traffic to root. Root uses source routes to
send traffic to leafs.
○ limited by ram of DODAG root/6LBR, but usually non-constrained
device
○ requires more bits on wire, which often is more expensive
(energy-wise) than more ram, or compute cycles.
● new work (“dao-projection”) tries to add some routes to non-storing
mode.
● original protocol (pre-2011) thought to mix and match, but this proved
unworkable.
Traffic Flows Supported by RPL

P2MP MP2P
● MP2P
● P2MP
● P2P (special
DODAG, always
non-storing)

(DODAG)
 RPL Instance

● A RPL Node may belong to multiple RPL Instances, and it

may act as router in some and as a leaf in others.
● Type: Local and Global

● Control and Data packets has a RPLInstance field.

RPL topology
 Directed

Acyclic
RPL topology
Graph
 Directed

Acyclic DODAG
RPL topology
Graph
 Directed

Acyclic DODAG
RPL topology
Graph

How we form the topology?

 Directed

Acyclic DODAG
RPL topology
Graph

How we form the topology?

Through Control Messages

 Directed

Acyclic DODAG
RPL topology
Graph

How we form the topology?

Through Control Messages

How I send the messages?

 Directed

Acyclic DODAG
RPL topology
Graph

How we form the topology?

Through Control Messages

RPL
How I send the messages?

RPL Control message is a ICMPv6 message

 Directed

Acyclic DODAG
RPL topology
Graph

How we form the topology?

Through Control Messages

How I send the messages?

RPL Control message is a ICMPv6 message

What types of messages we need?

 Directed

Acyclic DODAG
RPL topology
Graph

How we form the topology?

Through Control Messages

How I send the messages?

RPL Control message is a ICMPv6 message

What types of messages we need?

To Request
information to
join the
topology
 Directed

Acyclic DODAG
RPL topology
Graph

How we form the topology?

Through Control Messages

How I send the messages?

RPL Control message is a ICMPv6 message

What types of messages we need?

To Request To be able to
information to send
join the messages
topology upwards
 Directed

Acyclic DODAG
RPL topology
Graph

How we form the topology?

Through Control Messages

How I send the messages?

RPL Control message is a ICMPv6 message

What types of messages we need?

To Request To be able to To be able to

information to send send
join the messages messages
topology upwards downwards
 Directed

Acyclic DODAG
RPL topology
Graph

How we form the topology?

Through Control Messages

How I send the messages?

RPL Control message is a ICMPv6 message

What types of messages we need?

To Request To be able to To be able to To send the

information to send send messages in
join the messages messages a secure
topology upwards downwards way
 RPL Control message is a ICMPv6 message

To Request To be able to To be able to To send the

information to send send messages in
join the messages messages a secure
topology upwards downwards way
 RPL Control message is a ICMPv6 message

To Request To be able to To be able to To send the

information to send send messages in
join the messages messages a secure
topology upwards downwards way
 RPL Control message is a ICMPv6 message

To Request To be able to To be able to To send the

information to send send messages in
join the messages messages a secure
topology upwards downwards way

DIS

DODAG Information Solicitation (DIS)

Solicit a DODAG Information Object (DIO) from a RPL node

Its use is analogous to that of a Router Solicitation of IPv6 Neighbor Discovery

 RPL Control message is a ICMPv6 message

To Request To be able to To be able to To send the

information to send send messages in
join the messages messages a secure
topology upwards downwards way
 RPL Control message is a ICMPv6 message

To Request To be able to To be able to To send the

information to send send messages in
join the messages messages a secure
topology upwards downwards way

DIO

Carries information that allows a node to:

- Discover a RPL instance

DODAG Information Object (DIO) - Learn its configuration parameters

- Select a DODAG parent set

- Maintain the DODAG

 RPL Control message is a ICMPv6 message

To Request To be able to To be able to To send the

information to send send messages in
join the messages messages a secure
topology upwards downwards way
 RPL Control message is a ICMPv6 message

To Request To be able to To be able to To send the

information to send send messages in
join the messages messages a secure
topology upwards downwards way

DAO

Destination Advertisement Object (DAO)

- Used to propagate destination information Upward along the DODAG.

- In Storing mode, the DAO message is unicast by the child to the selected parent(s).

- In Non-Storing mode, the DAO message is unicast to the DODAG root.

The DAO message may optionally, upon explicit request or error, be acknowledged by its destination with

a Destination Advertisement Acknowledgement (DAO-ACK) message back to the sender of the DAO.
 RPL Control message is a ICMPv6 message

To Request To be able to To be able to To send the

information to send send messages in
join the messages messages a secure
topology upwards downwards way

Secure DODAG Information Solicitation (SDIS)

Secure DODAG Information Object (SDIO)
Secure Destination Advertisement Object
(SDAO)
SDAO-ACK
Consistency Check
 RPL Control message is a ICMPv6 message

To Request To be able to To be able to To send the

information to send send messages in
join the messages messages a secure
topology upwards downwards way

Destination
DODAG Advertisement Object - SDIS
DODAG Information
Information Object (DAO)
Solicitation (DIS) - SDIO
(DIO)
DAO-ACK - SDAO
- SDAO-ACK
- Consistency
Check
RPL Control message is a ICMPv6 message

Type=155 Code Checksum

Base

Option(s)

Code: Identify the type of control message

0x00 → DODAG Information Solicitation (DIS)
0x01 → DODAG Information Object (DIO)
0x02 → Destination Advertisement Object (DAO)
0x03 → DAO-ACK
RPL Control message is a ICMPv6 message

Type=155 Code Checksum

Security

Base

Option(s)

Code: Identify the type of control message

0x80 → Secure DODAG Information Solicitation (SDIS)
0x81 → Secure DODAG Information Object (SDIO)
0x82 → Secure Destination Advertisement Object (SDAO)
0x83 → SDAO-ACK
0X84 → Consistency Check
 Destination
DODAG Advertisement Object - SDIS
DODAG Information
Information Object (DAO)
Solicitation (DIS) - SDIO
(DIO)
DAO-ACK - SDAO
- SDAO-ACK
- Consistency
Check
How often I send the messages?
 Destination
DODAG Advertisement Object - SDIS
DODAG Information
Information Object (DAO)
Solicitation (DIS) - SDIO
(DIO)
DAO-ACK - SDAO
- SDAO-ACK
- Consistency
Check
How often I send the messages?

RPL nodes transmit DIOs using a Trickle Timer.

Trickle's basic primitive is simple: every so often, a node transmits data unless it hears a few other
transmissions whose data suggest its own transmission is redundant.
 Directed

Acyclic DODAG
RPL topology
Graph

How a node pick up a parent?

 Directed

Acyclic DODAG
RPL topology
Graph

How a node pick up a parent

Objective Function (OF)

Define how RPL nodes select and optimize routes within a RPL Instance.

Define how nodes translate one or more metrics into a rank.

Define how nodes select parents

 DAG Metric Container

The DAG Metric Container option MAY be present in DIO or DAO messages

The DAG Metric Container is used to report metrics along the DODAG.

Type = 0x02 Option Length Metric Data

Node Metric/Constraint Objects

● Node State and Attribute Object

− Propose to reflect Node workload (CPU, Memory, etc)
● Node Energy Object
− Constraint
− three types of power sources: "powered", "battery", and "scavenger"
● Hop Count Object
− Can be used as metric or constraint
− Constraint: max number of hops can be traversed
− Metric: total number of hops traversed
Link Metric/Constraint Objects

● Throughput Object:
− Currently available throughput (Bytes per second)
● Latency:
− Can be used as a metric or constraint
− Constraint: Max latency allowable on path
− Metric: additive metric updated along path
● Link Reliability:
− Link Quality Level Reliability (LQL): 0=Unknown, 1=High, 2=Medium, 3=Low
− Expected Transmission Count (ETX) (Average number of TX to deliver a
packet)
● Link Colour:
− Metric or constraint, arbitrary admin value

Conversion Metric to Rank

Objective Function (OF)

Of0: Objective Function Zero (default)

OF0 is designed as a default OF that will allow interoperation between implementations

in a wide spectrum of use cases

Minimum Rank with Hysteresis OF.

Objective Function that selects routes that minimize a metric, while using hysteresis to

reduce churn in response to small metric changes.

 RPL has mechanism for loop detection and DODAG Repair

Suppose link between nodes B and D is broken:

(for instance, a metal door closes!)

Node D type node B in its list

Parent Node D is no longer any time in

grounded DODAG Parent, so it will be the root of
floating DAG itself

Source: http://www.slideshare.net/vinatech/slide-tt?related=1
RPL has mechanism for loop detection and DODAG Repair

Node D play DIO to notify change of

sub-DAG

Node I has alternate parent E, so it does

not leave the DAG of LBR-1

I eliminates Node D Node from possible

Parents list

Source: http://www.slideshare.net/vinatech/slide-tt?related=1
RPL has mechanism for loop detection and DODAG Repair

- Node F follows D node, as D leaves

LBR-1 DAG: it has no choice

- Node F hears DIO from D.

- Node G and H also follow floating node F

DAG

Source: http://www.slideshare.net/vinatech/slide-tt?related=1
RPL has mechanism for loop detection and DODAG Repair

Node I found DIO

Node D listens to DIOs for opportunities

to re-enter the last Grounded with depth 5
Node I

Source: http://www.slideshare.net/vinatech/slide-tt?related=1
RPL has mechanism for loop detection and DODAG Repair

Suppose link between A and F is set

Node A send DIO

- Node F release notice Grounded DAG re-entry

opportunities with depth 2 through node A DAG

Hop Node F started with 1 cycle timer

associated with the node A

Source: http://www.slideshare.net/vinatech/slide-tt?related=1
RPL has mechanism for loop detection and DODAG Repair

- DAG node F Timer goes off, issues

DIS, receives DIO from A!

- Node F Grounded DAG with depth 2

by adding the Parent A
- Node F send DIO with new rank/etc.
- Node G and H join to the Grounded
DODAG through F

Source: http://www.slideshare.net/vinatech/slide-tt?related=1
RPL has mechanism for loop detection and DODAG Repair

Node D hears new DIO from F.

Node D start DAG Hop cycle timer with 2

attached to node F, while other timer is running
DAG Hop with 4 cycles associated with the first
node

Source: http://www.slideshare.net/vinatech/slide-tt?related=1
RPL has mechanism for loop detection and DODAG Repair

- DAG node D Hop timer with 2 cycles tend

to end first.
- Node D engaged with depth 3 Grounded

DAG by adding Node F's parent.

- End

Source: http://www.slideshare.net/vinatech/slide-tt?related=1
 Questions to answers today

1. What is a low power/lossy network? How does that relate to IoT?

2. What is RPL and how does it work?

3. Why couldn't we do this with other (IETF) routing protocols?

4. What are some applicability examples/real life deployments?

draft-ietf-roll-protocols-survey
 Results of draft-ietf-roll-protocols-survey

Protocol Routing Loss Control Cost Link Cost Node Cost

State Response

OSPF/IS-IS Fail Fail Fail Pass Fail

OLSRv2 Fail ? ? Pass Pass

TBRPF Fail Pass Fail Pass ?

RIP Pass Fail Pass ? Fail

AODV Pass Fail Pass Fail Fail

DYMO Pass ? Pass ? ?

DSR Fail Pass Pass Fail Fail

 Questions to answers today

1. What is a low power/lossy network? How does that relate to IoT?

2. What is RPL and how does it work?

3. Why couldn't we do this with other (IETF) routing protocols?

4. What are some applicability examples/real life deployments?

RPL Implementations

● Open Source
○ ContikiRPL → https://github.com/contiki-os/contiki/tree/master/core/net/rpl
■ used in multiple companies, with some variations among them
○ TinyRPL → https://github.com/tinyos/tinyos-main/tree/master/tos/lib/net/rpl
○ Unstrung → http://unstrung.sandelman.ca/
■ intended for gateways and other non-constrained (class >2) systems
● https://tools.ietf.org/html/draft-hui-vasseur-roll-rpl-deployment-01
● A lot of Academia papers evaluating the performance of RPL
● Known to be a number of proprietary implementations:
○ Cisco (more than one?), Huawei, Itron*, Landisgyr*, Sigma Design,
● Academia research about RPL for Mobility
Takeaways

- RPL is the routing protocol for Low Power and Lossy

Networks developed in ROLL IETF Working Group

- RPL Control Messages are used to build a topology

- Implementations were developed and help to identify

features to improve the protocol

Application Layer Protocols
Questions to answer today

What is CoAP? How it works?

What is MQTT? How it works?

Constrained Application Protocol (CoAP) - RFC7252

CoAP defines a web transfer protocol based on REpresentational

State Transfer (REST).

REST represents a simpler way to exchange data between clients and

servers over HTTP.
CoAP is a web transfer protocol for use with constrained
nodes/networks.

Application Application

Request/Responses Request/Responses
CoAP
Messages Messages

UDP DTLS

UDP
Abstract Layering of CoAP
Abstract Layering of DTLS-Secured
CoAP

Note: Most of the Images/examples were taken from RFC 7252

CoAP request is sent by a client to request an action (using a Method Code) on a

resource (identified by a URI) on a server.

Type of Messages (Method/Response Code):

- Confirmable (CON)

- Non-confirmable (NON)

- Acknowledgment (ACK)

- Reset (RST)

URI = host + port + path + query component

Method Definition
GET:

Retrieve a representation that corresponds to the resource identified by a URI

POST:

Request that the representation enclosed in the request be processed. (new resource
created or target resource being updated)

PUT:

Request that the resource identified by the request URI be updated or created with the
enclosed representation.

DELETE:

Request that the resource identified by the request URI be deleted.

Messaging Model: Confirmable (CON)

Reliable message transmission

A confirmable message is retransmitted using a default timeout and

exponential back-off between retransmission, until the receipt sends an
ACK, with the same message ID.
Messaging Model: Non-Confirmable (NON)

Unreliable Message Transmission

These are not acknowledged, but have a Message ID for duplicate

detection
Request/Response Model

Two GET Requests with Piggybacked Responses

A request is carried in a CON or NON message.

A Token is used to match responses to requests independently form the underlying messages.

In Piggybacked responses, the response to a request is carried in the ACK.

A GET Request with a Separate Response

Server is not able to respond immediately, then responds with an empty ACK, so the client
stop retransmitting.
When response is ready, the server sends it in a CON message and it is acknowledged by
the client.
A request and a Response carried in
a NON-Confirmable message.
Message Format: 4 bytes header (fix)

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Ver T TKL Code Message ID

Token (if any, TKL bytes) ...

Options (if any) ...

1 1 1 1 1 1 1 1 Payload (if any) ...

The fixed-size 4-bytes header is followed by a variable-length Token value

(between 0 -8 bytes long), followed by a sequence of CoAP Options in
Type-Lenght-Value (TLV) format, optionally followed by a Payload.
CoAP URI Scheme

coap-URI = "coap:" "//" host [ ":" port ] path-abempty [ "?" query ]

Host: IP address or registered name

Port: Default 5683
Path-abempty: The path identifies a resource within the scope of the host and port. It
consists of a sequence of path segments separated by a slash character (“/”). E.g.
"/.well-known/"
Query: The query serves to further parameterize the resource. It consists of a sequence
of arguments separated by an ampersand character (“&”). An argument is often in the
form of a "key=value" pair.

coap://example.com:5683/~sensors/temp.xml
coap://EXAMPLE.com/%7Esensors/temp.xml
coap://EXAMPLE.com:/%7esensors/temp.xml
Additional CoAP Features: Multicast

Multicast: “All CoAP Nodes" - in IPv4: 224.0.1.187 - in IPv6: FF0X::FD

Additional functionalities => Group Communications (RFC 7390)

E.g.: Non-confirmable Request (Multicast); Non-confirmable Response

RFC 7252
Additional CoAP Features: Observe

The Observer Design Pattern

Observing a resource in CoAP
CoAP pub/sub Architecture
CoAP

Messagintg: detects duplications and provides reliable communication over UDP

using exponensial backoff

Request/Response: handles REST communications. CoAP utilizes four types of

messages: confirmable, non-confirmable, reset and acknowlegement.

Response: PIggybacked or separate

Methods: GET, PUT, POST and DELETE to CRUD (Create, Retrieve, Update and
Delete) operations
Features provided by CoAP

Observation: using Publish-Subscriber mechanism.

Resource Discovery: Server utilizes well-Know URI

Security through DTLS (Datagram Transport Layer Security)

Questions to answer today

What is CoAP? How it works?

What is MQTT? How it works?

MQTT (Message Queue Telemetry Transport)

-messaging protocol

- standardized at OASIS

- connection: one-to-one, one-to-many, many-to-many

-Publish/Subscriber pattern

- over TCP

- MQTT-SN: for Sensor Networks, adapt to UDP

- Components: Subscriber, Publisher and Broker.

- Implementaciones: Eclipse: Mosquito & Paho , M2mqtt

MQTT communication model

http://www.systeminsights.com/blog/2015/9/9/paho-python-client-for-mqtt
MQTT has a client/server model, where every sensor is a client and
connects to a server, known as a broker, over TCP.

MQTT is message oriented. Every message is a discrete chunk of data, opaque to the broker.

Every message is published to an address, known as a topic. Clients may subscribe to multiple topics. Every client subscribed to a topic
receives every message published to the topic.

For example, imagine a simple network with three clients and a central broker. All three clients open TCP connections with the broker. Clients
B and C subscribe to the topic temperature . At a later time, Client A publishes a value of 22.5 for topic temperature . The broker forwards
the message to all subscribed clients.

https://eclipse.org/community/eclipse_newsletter/2014/february/article2.php
MQTT message Format

http://www.rfwireless-world.com/Terminology/MQTT-protocol.htm
http://www.slideshare.net/PeterREgli/mq-telemetry-transport?next_slideshow=1
Major differences between MQTT and CoAP

MQTT CoAP

Application Layer Single Layered completely Single layered with 2 conceptual sub
layers (Message Layer and Request
Response Layer)

Transport Layer Runs on TCP Runs on UDP

Reliability Mechanisms 3 Quality of Service levels Confirmable messages,

Non-confirmable
message, Acknowledgment
and retransmissions

Supported Architecture Publish-Subscribe Request-Response,

Resource
observe/Publish-
Subscribe

Thangavel, et. al.,”Perform Evaluation of MQTT and CoAP via a Common Middleware”, 2014.
IoT Management
 Management Management Protocols and Data Models
Architecture/System

Software Distribution Requirements on the Configuration Management

Management of Networks
with Constrained Devices
(RFC7547)
Traffic Management Monitoring Functionality

Implementation Requirements

Self-Management

Transport Layer
Energy Management
Security and Access Control
IoT Management Stack
Information Models and Data Models - - RFC 3444

Information Models are used to model managed objects at a conceptual level, independent

of any specific protocols used to transport the data (protocol agnostic)

Data Models are defined at a lower level of abstraction and include many details (compared

to information models). They are often represented in formal data definition languages that

are specific to the management protocol being used.

https://www.ietf.org/proceedings/86/slides/slides-86-i2rs-3.pdf
 Information
Model
Information
Model Requirements

Data
Model

OMNA
MIB YANG SenML
Objects

Serialization JSON
BER XML JSON
XML
XML
CBOR
EXI
LWM2M (LightWeight Machine-to-Machine)

-Device Management Protocol for constrained networks developed by

OMA (Open Mobile Alliance).

- Management of a Device includes:

- Setting initial configuration information in devices

- Subsequent installation and updates in devices.

- Retrieval of management information from devices.

- Processing events and alarms generated by devices.

- Client Server Structure

http://openmobilealliance.org/
 LWM2M LWM2M M2M App
M2M
App
M2M
App
Server
Architecture LWM2M Server

Interfaces:
Bootstrapping
Registration
Object/Resource Access
Reporting

LWM2M Client

Object 0
Resource 1 | R
Resource 2 | R/W

Resource 3 | E

LWM2M
Client
Object 1
Resource 1 | R
Resource 2 | R/W

Resource 3 | E

URI: /{Object}/{Object Instance}/{Resource}/{Resource Instance}

 LWM2M Stack

M2M Device M2M Server

Objects Objects

LWM2M
LWM2M Client
Server

CoAP CoAP

Transport Transport
Layer Layer

6LoWPAN/IP 6LoWPAN/IP

Lower Layers Lower Layers

Network
LWM2M Interfaces

Requested Bootstrap

Bootstrapping
Write, Delete

Register, Update, De-Register

Registration

Read, Write, Execute, Create,

Delete
Object
Resource Write Attribute, Discover
Access

Observe, Cancel Observation

Reporting
Notify

LWM2M LWM2M Server

Client
E.g. Waakama Implementation

OMA-TS-LightweightM2M-V1_0-20150422-D_cb
- e.g, a measurement from a temperature estimation encoded in the JSON syntax
would be: {”e”:[{ ”n”: ”urn:dev:lmf:111”, ”v”:3.3, ”u”:”Cel” }]}, This array represents a
single measurement for a sensor named ”urn:dev:lmf:111” with a temperature of
3.3 degrees Celsius.

- The resources are accessible by the server with an URI in the format
”/{ObjectID}/{InstanceID}/{ResourceID}”. For example, ”/1024/10/1” is an URI to
access the Object 1024, Instance 10 and Resource 1
 The resources are requested using the command prompt: ”command CLIENT# URI DATA”

E.g. read 0 /3/0/0, In this case, the server run this command (read) to request to the proxy (CLIENT#=0)
read a resource (/3/0/0) from the Device Object (3)., for write e.g. “write 0 /1/0/1 4”
Implementations

- Wakaama [http://projects.eclipse.org/projects/technology.wakaama]

- RIOT

[https://www.google-melange.com/gsoc/project/details/google/gsoc2015/alexa

ndru_c/5676830073815040]

- Contiki [https://github.com/jenseliasson/iot-apps]

- Lualwm2m [https://github.com/sbernard31/lualwm2m]
CoAP Management Interface (CoMI) is an adaptation of the RESTCONF protocol for
use in constrained devices and networks.

CoMI Arch with CoAP Response added

Constrained Objects Language (CoOL): a management function set

CoOL Architecture
CoOL objects
YANG modelling
(datastores,
language.RPCs,
Payloads
actions
are encoded
and notifications)
using theare
CBOR
defined
datausing
format
the
IoT Semantic
Interoperability
Slide from: http://summit.riot-os.org/wp-content/uploads/2016/07/2-Communication-Session-WoT-Matthias1.pdf
Slide from: http://summit.riot-os.org/wp-content/uploads/2016/07/2-Communication-Session-WoT-Matthias1.pdf
Web of Things (WoT) from W3C
In Web of Things (WoT), functional virtual device is named “WoT Servient”
provides the access to, control and status from IoT physical devices.

Functional Architecture of WoT Servient

http://w3c.github.io/wot/architecture/wot-architecture.html
WoT Servient example

http://summit.riot-os.org/wp-content/uploads/2016/07/2-Communication-Session-WoT-Matthias1.pdf
Semantic Interoperability

The ability for data sources and applications to exchange state

information in a meaningful way without prior detailed

knowledge.

https://tools.ietf.org/html/draft-koster-t2trg-hypertext-language-00#section-4
There is an interoperability gap in how
application semantics are defined and used

“...Many organizations and industry alliances are defining vocabulary and taxonomy for
application domains, independent of each other.

These vocabularies are often bound to particular conceptual models, and are often semantically
incompatible with each other.

e.g. an identifier like temperature may appear to be well known but is semantically
incompatible across ecosystems and application domains ….”

https://tools.ietf.org/html/draft-koster-t2trg-hypertext-language-00
One approach to semantic interoperability is to develop a common:

- semantic structure and language => vocabularies

- meta models => to describe events, actions, and properties

https://tools.ietf.org/html/draft-koster-t2trg-hypertext-language-00#section-2
Other approach

Interoperability = Information model + Interaction model

An Information model that describes the exchanged information

An Interaction model that describes the possible interactions

with a service: HATEOAS (Hypermedia As The Engine Of
Application State)

https://www.iab.org/wp-content/IAB-uploads/2016/03/2016-IAB-HATEOAS.pdf
HATEOAS (Hypermedia As The
Engine Of Application State)

“...The server provides in-band descriptions of the API through the publication
of links and forms.

Only the atomic interaction steps (following links and submitting forms) have to
be shared a priori.

Each interaction step corresponds to a request/-response exchange.

This mechanism lets machines not only handle change over time, but also
enables interoperability between changing APIs from different
manufacturers….”

https://www.iab.org/wp-content/IAB-uploads/2016/03/2016-IAB-HATEOAS.pdf
More information
 Open Source
Implementations
(SOME OF THEM… ;)
Open Source

- Operative Systems

- Development Frameworks

- Cloud

- Test beds

- Implementations Scenarios

- Open Hardware
Open Operative Systems

Source: Oliver Hahm, Emmanuel Baccelli, Hauke Petersen, Nicolas Tsiftes. Operating Systems for Low-End Devices in the Internet of
Things: a Survey. IEEE Internet of Things Journal, IEEE, 2015, <10.1109/JIOT.2015.2505901>. <hal-01245551>
Dev. Frameworks e.g . ECLIPSE IOT

http://www.slideshare.net/ManolisNikiforakis/lwm2m-ota-for-esp8266
Sand Boxes:
The IoTivity architectural goal is to create a new standard by which billions of wired and

wireless devices will connect to each other and to the internet. The goal is an extensible

and robust architecture that works for smart and thin devices.

https://www.iotivity.org/
Test-beds,
e.g.

Platform
Overview
Active and publicly available testbeds

Source: Alexander Gluhak, Srdjan Krco, Michele Nati, Dennis Pfisterer, Nathalie Mitton, et al. A Survey on Facilities for Experimental Internet of
Things Research. IEEE Communications Magazine, Institute of Electrical and Electronics Engineers, 2011, 49. (11), pp.58-67.
<10.1109/MCOM.2011.6069710>. <inria-00630092>
Testbeds with interesting features

Source: Alexander Gluhak, Srdjan Krco, Michele Nati, Dennis Pfisterer, Nathalie Mitton, et al. A Survey on Facilities for Experimental Internet of
Things Research. IEEE Communications Magazine, Institute of Electrical and Electronics Engineers, 2011, 49. (11), pp.58-67.
<10.1109/MCOM.2011.6069710>. <inria-00630092>
F-Interop aims and objectives can be summarized as follow:
to integrate and extend several European testbed federations with a shared “Testbed as a Service” interconnecting

three European testbeds federations (Fed4FIRE, OneLab, IoT Lab), bringing together over 32 testbeds and 4755 nodes. It

will develop anew architecture model enabling easier access.

to research and develop online testing tools for the Internet of Things, including for interoperability tests, conformance

tests, scalability tests, Quality of Service (QoS) and Quality of Experience (QoE) tests, and Energy efficiency tests

to support IoT standardization and enable closer cooperation with the industry, through a close collaboration with

standards development organizations, including ETSI, oneM2M, IETF and W3C,- and be researching and developing online

certification and labelling mechanisms. F-Interop will enable an easier participation of researchers and industry in the

standardization process.

to organize an Open call for SMEs and developers to use and enrich the developed testing platform with additional

modules and extensions (additional test tools, tests specifications, etc.).

http://www.f-interop.eu/
RuuviTag: Open Source Bluetooth Smart Sensor Beacon
Platform

http://ruuvitag.com/
Unas de las maneras de participar en
IoT Latinoamérica, lista de correo: iot@lacnog.org
What is next (happening now)?

- How to get Interoperability?

- New work in IoT e.g. IETF Working Group.

New Working Group (e.g. T2TRG)

New IETF-Bofs (e.g. LPWAN

https://tools.ietf.org/bof/trac/wiki/BofIETF95)

New standards (e.g. RFC 7774: Multicast Protocol for Low-Power and
Lossy Networks (MPL) Parameter Configuration Option for DHCPv6)
Muchas GRACIAS!!!! :-)