Internet das Coisas: Tecnologias Atuais e Futuras, e o Papel do Software

© Antônio M. Alberti 2014
Internet das Coisas: Tecnologias Atuais e
Futuras, e o Papel do Software
Antônio Marcos Alberti
!
alberti@inatel.br
www.inatel.br/novagenesis/

Outline
‣ Internet of Things (IoT) Definitions
‣ Current Internet of Things Technologies
‣ The Current Internet Status
‣ Future Internet (FI) and Internet of Things
‣ European IoT Initiatives
‣ Interrelationships Among IoT and FI Ingredients
‣ NovaGenesis: Convergent Information Architecture

Internet of Things (IoT) Definitions
‣ To make an Internet build of physical “Things”.
‣ To bring the Internet to the “Things”.
‣ To put the “Things” on the Internet.
(c) Antonio Alberti 2014, Inatel - All rights reserved.

Current Internet of Things Technologies
‣ Message Queue Telemetry Transport
(MQTT)
‣ IEEE 802.15.4:
‣ IEEE 802.15.4e (Time Synchronized
Channel Hopping)
‣ ZigBee
‣ Wireless Highway Addressable
Remote Transducer Protocol
(WirelessHART)
‣ IETF:
‣ IPv6 over Low Power Personal Area
Network (6LoWPAN)
‣ IPv6 over the TSCH mode of IEEE
802.15.4e (6TiSCH).
‣ 6TiSCH Operation Sublayer (6top)
‣ IPv6 Routing Protocol for Low-Power
and Lossy Networks (RPL)
‣ Constrained Application Protocol
(CoAP)

‣ Message Queue Telemetry Transport (MQTT)
‣ “Light weight” messaging protocol to run over TCP/IP.
‣ “MQ” comes from IBM's message queuing.
‣ It is not real time - delay of seconds.
‣ Focused on Machine to Server (M2S) scenario.
‣ Follows a publish/subscribe hub-and-spoke paradigm.
‣ MQTT for Sensor Networks (MQTT-SN) is TCP/IP independent.
‣ Operations: Connect, Subscribe, Publish, Unsubscribe,
Disconnect.
‣ Provides agnostic binary payload.

‣ Message Queue Telemetry Transport (MQTT)
MQTT bi-directional, async “push” communication
MQTT!
Broker
CONNECT to MQTT broker
SUBSCRIBE to thing3/data
recv
recv
pub
CONNECT to MQTT broker
PUBLISH to thing3/data
Picture Credits: MQTT: A practical protocol for the Internet of Things, Bryan Boyd, IBM,
2014.
thing #1
thing #2
thing #3
TCP/IP
WebSocket

‣ IEEE 802.15.4:
‣ It is a wireless communication standard for low-power, low-data
rate, and short distance radio coverage.
‣ Developed within IEEE 802.15 Personal Area Network (PAN)
group.
‣ Typical data rate is 250 kb/s with maximum packet size of 127
bytes - Available payload is about 86 up to 116 bytes.
‣ Defines physical layer (16 channels with direct sequence spread
spectrum) and MAC layer.
‣ Can go multi-hop, but requires to keep the radio on all the time.
‣ Employs single channel operation, which suffers with multi-path
fading and shadowing.

‣ IEEE 802.15.4e:
‣ Employs a Time Synchronized Channel Hopping (TSCH)
technique to avoid interferences, shadowing, and multi-path
fading.
!
!
!
!
!
Picture Credits: Standardized Protocol Stack for the Internet of (Important) Things,
Palattella et al., IEEE Comm. Surveys and Tutorials, 2013.
‣ Redesigned MAC protocol to support centralized or distributed
scheduling, channel hoping, and network formation.
of an acknowledged transmission.
energy efficiency, channel
slotframe structure. A
repeat over time. Each
it what to do in each
either transmit, receive,
does not turn on its
schedule indicates with which
which channel offset
long enough for the
length packet, and for the
acknowledgment indicating good
is implement-specific,
[40].
Fig. 2. Dedicated and shared links.
B. Scheduling
IEEE802.15.4e defines how the MAC layer executes a
schedule (as described in Sec. III-A). It does not specify
how such as schedule is built. A schedule needs to be built
carefully so that, when mote A has a transmit slot to mote

‣ ZigBee
‣ Industry standard based on IEEE 802.15.4.
!
‣ Wireless Highway Addressable Remote Transducer Protocol
(WirelessHART)
‣ Industry standard based on IEEE 802.15.4 and TSCH (also
employed on 802.15.4e).

‣ IETF: IPv6 over Low Power Personal Area Network (6LoWPAN)
‣ IPv6 packets are too big for IEEE 802.15.4.
‣ Provides an adaptation layer to segment and reassembly IPv6
datagrams.
‣ Provides IPv6 header compression.
IETF TCP/UDP
IETF IPv6
IETF 6LoWPAN
IEEE 802.15.4 MAC
IEEE 802.15.4 PHY
IETF TCP/UDP
IETF IPv6
IETF 6LoWPAN
IEEE 802.15.4 MAC
IEEE 802.15.4 PHY

‣ IETF: IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH)
‣ “It defines the 6top sublayer and a set of protocols (in particular,
for setting up a schedule with a centralized or distributed
approach, managing the resource allocation), as well as the
architecture to bind them together, for use in IPv6 TSCH based
networks,” from Internet Draft, July 2014.
IETF TCP/UDP
IETF IPv6
IETF 6LoWPAN
IETF 6top IETF 6top
IEEE 802.15.4e MAC
IEEE 802.15.4 PHY
IETF TCP/UDP
IETF IPv6
IETF 6LoWPAN
IEEE 802.15.4e MAC
IEEE 802.15.4 PHY

‣ IETF: 6TiSCH Operation Sublayer (6top)
‣ “6top offers a set of commands so control mechanisms can be
introduced on top of TSCH to configure nodes to join a specific
node and obtain a unique 16-bit identifier from the network. Once
a network is formed, 6top maintains the network’s health,
allowing for nodes to stay synchronized,” from Internet Draft, July
2014.

‣ IETF: IPv6 Routing Protocol for Low-Power and Lossy Networks
(RPL)
‣ Provides a routing approach for Low-Power and Lossy Networks
(LLNs).
‣ Employs a distance-vector approach were nodes construct a
Destination-Oriented Acyclic Graph (DODAG).
‣ The destination is the root node (usually the IoT gateway).

‣ IETF: Constrained Application Protocol (CoAP)
‣ Provides a specialized web transfer protocol for LLNs that
conforms to the REST style.
‣ There is an URI for every “Thing”.
‣ Contrary to HTTP, it employs UDP instead of TCP.
‣ Enables asynchronous message exchange with low complexity
parsing.
‣ HTTP-CoAP mapping is standardized.

‣ IETF: Constrained Application Protocol (CoAP)
‣ How it integrates to the IETF IoT stack?
IETF CoAP IETF CoAP
IETF TCP/UDP
IETF IPv6
IETF 6LoWPAN
IETF 6top IETF 6top
IEEE 802.15.4e MAC
IEEE 802.15.4 PHY
IETF UDP/TCP
IETF IPv6
IETF 6LoWPAN
IEEE 802.15.4e MAC
IEEE 802.15.4 PHY

The Current Internet Status
ü The main protocols in the stack were designed in an era where
technological development was completely different from today.
!
ü There was not enough capacity to support sophisticated
networking services - the solution was to design a simple, but
robust network.
!
ü The terminals were fixed, inside secure university/government
environment - there were not attackers!!
!
ü During decades, it was incrementally developed and deployed,
achieving impressive scales!!!

ü The result is a complex agglomerate of incremental protocols
that inherits the grown legacies of decades of patchwork
solutions.
!
ü New protocols must live with the limitations of the preceding.
!
ü Intermediary layers have been added to overcome unplanned
situations, reducing network efficiency.
!
ü While at the physical layer we are approaching to the theoretic
Shannon’s limit of channels, at network level, lots of bytes are
lost on inefficient stacking.
!
ü Interoperability of dual stacking for IoT (traditional vs LLN).

ü Other limitations of the current stack are:
ú The dual semantics of IP addresses (identifier and locator).
ú The lack of unique addresses and transparency.
ú The inefficient support for host mobility.
ú The inexistent support for service mobility.
ú The incomplete naming approach, which do not name applications
and other important entities in architecture.
ú The weak support for security, privacy, and trust.
ú The weak support for multicast.
ú The weak support for quality of service.
ú The problematic support for inter autonomous system routing.
ú The inexistent support for multihoming.
ú The scalability issues of client/server model.

Future Internet and Internet of Things
‣ Since 2000, several initiatives to rethink the Internet appeared
under the banner of the so called Future Internet Architecture (FIA)
design.
!
‣ They can be classified as:
ú Clean slate - Aim at redesigning from “scratch" the Internet
architecture using the state-of-the-art of contemporary
information and communications technologies.
!
ú Evolutionary - Aim at continuing evolving TCP/IP Internet.
!
‣ Since 2008, I am designing a new convergent information
architecture called NovaGenesis.

Future Internet and Internet of Things
‣ A branch of FIA design is the Internet of Things (IoT), or more
generally the Internet of Everything (IoE).
!
‣ The IoE can be defined as to make everything belong to the
Internet.
!
‣ The clean slate advocates wonder if the current Internet can
support such a challenge, i.e. scalability, naming, identification,
mobility, addressing for billions of nodes.

European IoT Initiatives
IoT-‐A
Partner
List
Produtos
de
Mercado
FP7
ARM
Architecture
Reference
Model
FIA
–
RWI
–
IoT-‐I
Projetos
orientados
a
IoT:
SENSEI,
ASPIRE,
AUTOI
SMARTSANTANDER
WISEBED
Projetos
tocantes
a
IoT:
INSTANT
MOBILITY
OUTSMART,
SAFECITY
SMARTAGRIFOOD
FI-‐PPP
Partners
Serviços
e
Soluções
de
Mercado
FIA
Partners:
EFIA
FI-‐EC
Serviços
e
Soluções
de
Mercado
FIA-‐FP7
-‐
EU’s
Seventh
Framework
Programme
RWI
-‐
Real
World
Internet
FIA
–
Future
Internet
Assembly
IoT-‐I
–
Internet
of
Things
Initiative
FI-‐PPP
–
Future
Internet
Public
Private
Partnership
IoT-‐A
–
Internet
of
Things
Architecture
EFIA
–
European
Future
Internet
Alliance
FI-‐EC
–
Future
Internet
at
European
Commission

Interrelationships Among IoT and FI Ingredients
IoT
Capacity/Ubiquity/
Scalability
Real-Virtual
Exposition/Service-centrism
SDN
Management/
Autonomicity
Information-centrism
Naming/Identification/Mobility/
Multihoming

Resources Exposition and Service-Centrism
ü IoT and FI resources need be exposed to software orchestration
frameworks, allowing the dynamic and integrated composition of
real and virtual existences.
Software Orchestration

Resources Exposition and Service-Centrism
ü Entire services’ life-cycles can be orchestrated involving such
exposed resources.
!
ü The life-cycle can include devices description, search, selection,
negotiation, admission, installation, monitoring, failure handling,
and all the other management functionalities.
!
ü In short, IoT capabilities can be seen as a service (IoT-as-a-service).
!
ü This view approximates the IoT to the so-called Internet of
Services (IoS).

Management and Autonomicity
ü IoT will manage itself or at least reduce considerably the degree
of the human intervention required.
We already have self-driven cars.
Why not to have a self-driven FIA?
ü We cannot expect that the IoT will be managed in the same way
as the telecom operator’s networks today.

Management and Autonomicity
ü The autonomic technology appears to be a natural candidate for
the IoT management.
!
ü However, the IoT provides the information necessary to feed the
autonomic cycle of other FI architectural components.
!
ü Thus, IoT appears to be a natural candidate to implement some
of the phases of the autonomic cycle for FI components.

ü Node-centrism is perhaps the most common approach for
designing WSANs.
!
ü IoT can take great advantage of the precepts behind the
Internet of Information (IoI).
!
ü Self-certifiable names (hash codes) can be used to name data
in a persistent and verifiable way.
!
ü The integrity, provenance, and non-repudiation of sensing and
actuating data can be checked based on such names.

ü Name-based search and discovery of network-enabled devices
and information helps on IoT services’ life-cycle.
Content
UDP
Figure 6. Comparison of IP protocol stack and the proposed solution: a) IP-based
stack; b) non-IP-based stack.
cost for CCN-based IoT
particular, a device using
Fig. 6b can further elimi-nate
management procedure.
be achieved in the CCN
the request arrival, the
the cached data without
activation of the target. More-over,
resource subscription, the
keep the subscription mes-sage
serving the request with the
timely reaction to the
it is in sleep mode for
RESEARCH CHALLENGES
introduced the IETF effort on
communication solution
summarized some of the critical
challenges of bringing the cur-rent
reality. From the techni-cal
Internet of Things relies not
to promote network con-vergency,
academic innovations at a fun-damental
improve engineering designs.
we identify some inter-esting
opportunities and challenges for
in the IoT design [19], such as incentive,
resource pricing, and social-aware privacy.
CONCLUSION
Content
IEEE 802.15.4, WiFi,
Ethernet,...
(b)
IPv6
6LoWPAN
IEEE 802.15.4
(a)
1:00 PM Page 97
Examples:
!
NDN - Named
Data Networking
or NovaGenesis
Picture Credits: A Survey on the IETF protocol suite for the Internet of Things - Standards,
Challenges and Opportunities, Sheng et al., IEEE Wireless Comm., Dec. 2013.

NovaGenesis Overview
‣ It aims to create a “clean slate” architecture to the new new
generation of converging information technologies.
‣ It is a set of distributed systems that cooperate each other towards
self-organizing all architecture functionalities as on demand,
contracted services.
‣ It employs a bottom-up approach where complex distributed
systems are formed by the cooperation of simples ones.
‣ It aims to create a broad, flexible, sustainable, and evolvable digital
business ecosystem (DBE).
‣ NovaGenesis provides an unique way of combining the same
Future Internet ingredients adopted worldwide.

‣ Adopted decision choices:
- Entities and content naming using natural language and self-certifiable
names (hash codes).
- As functionalities are seen as services, including network
protocols.
- Complex protocols like TCP are fragmented on a population of
cooperating services - combined at runtime.
- Name bindings are stored on distributed hash tables, representing
all kind of relationships among named-things.
- Name bindings are published and subscribed, enabling distributed
search, discovery, negotiation, and contracting of services and
content.

- Substrate resources are exposed to software by proxies, which
represent them regarding resource life-cycling and orchestration.
- All the communication is done by message scheduling and
exchanging, with dynamic headers.
- All the contracts can capture intrinsically the required quality,
security, privacy, reputation, etc.
- The services will employ a decision cycle to meet objectives
traced by human and machine operators.
- They compete each other to better satisfy contracts (evolutionary
pressures) and optimize the usage of substrate resources
(evolution environment).

(c) Antonio Alberti 2014, Inatel.
Physical
Individual
Existences
Services!
& Contents
Names
Bidwell
Mansion
525 Esplanade,
Chico, California
39°43′56.47″N
121°50′36.53″W
Raymond
Kurzweil
Bugatti
VeyronTM
OpenOfficeTM Readme.txt
PID = 321 /home/Readme.txt
Hash 6 Hash 7
iPADTM Nexus N5TM
1ABC234
Locators
525 Esplanade,
Chico, California
Hash 1
Identifier
Serial #2,
Hash 5
Bidwell
Mansion 1ABC234
Raymond
Kurzweil
../Readme.txt,
Hash 7
PID = 321,
Hash 6
Serial
Number 1
Serial
Number 2
Hash 2
Hash 4,6
Hash 5,7
39°43′56.47″N
121°50′36.53″W
Hash 1
Hash 2 Hash 3
Hash 4 Hash 5
Hash 1 Hash 2 Hash 3
Serial #1,
Hash 4

NovaGenesis
(c) Antonio Alberti 2014, Inatel.

PSS
GW HT
PS CLI
PGS
GW HT
PG CLI
HTS
GW HT
CLI
GIRS
GW HT
IR CLI
PGS
GW HT
PG CLI
HTS
GW
DHT CLI
MAC/PHY MAC/PHY
Eth/Wi-Fi
PHY Eth/Wi-Fi
PHY
HT
App
GW HT
Core CLI
App
GW HT
Core CLI

‣ NovaGenesis as an architecture to Adaptive and Cognitive Radio
over Fiber (ACRoF) and Internet of Things (IoT)
Optical Switch
To “E” To “E”
From “H”
RoF RoF
Splitter
Access
Point
Spectrum
Analyzer
Antenna Control Link
From “H”
Throughtput (Mbps)
CINR (dB) RF Sa Freque
NovaGenesis Services
for Proxy/Gateway/
Control of:
!
-Spectrum Sensing
-Optically
Controlled Antenna
-Access Point
-Wi-Fi VLAN
!!
!

Developing a NovaGenesis IoT
Towards a Trustable Fellowship of Self-Organizing “Things”
Social Devices
Window Sensor
Storm
Nobody at
home
Open window
Presence Sensors
Weather Sensors
Close the
window
Window !
Representative
Presence Sensors !
Representative
Weather Sensors !
Representative
Smart !
Assistant

Developing a NovaGenesis IoT
Smart Future Internet Architecture
People!
Policies, Rules, Regulations, etc.
Self-Organizing!
Assistants, Controllers, Managers, etc.
Self-Organizing !
Physical World Representatives
Physical World

Obrigado!
Antônio Marcos Alberti
!
www.inatel.br/novagenesis
antonioalberti.blogspot.com
facebook.com/antoniomarcos.alberti
researchgate.net/profile/Antonio_Alberti
linkedin.com/profile/view?id=69752898
http://inatel.academia.edu/AntonioMarcosAlberti
mendeley.com/profiles/antonio-marcos-alberti/
twitter.com/antoniomalberti

Experimenting with current IoT technologies
‣ Building a biometric classroom frequency control software
LPC1769
XBee Wi-Fi Modules

Experimenting with current IoT technologies
‣ Dynamic firmware replacement on LPC 1769
Bootloader
(NovaGenesis)
Aplicação
Troca de Informação
Gateway
NovaGenesis
Dispositivos / Roteadores
Comunicação sem fio

Internet das Coisas: Tecnologias Atuais e Futuras, e o Papel do Software

Recommended

Recommended

More Related Content

What's hot

What's hot (17)

Viewers also liked

Viewers also liked (19)

Similar to Internet das Coisas: Tecnologias Atuais e Futuras, e o Papel do Software

Similar to Internet das Coisas: Tecnologias Atuais e Futuras, e o Papel do Software (20)

More from Antonio Marcos Alberti

More from Antonio Marcos Alberti (20)

Recently uploaded

Recently uploaded (20)

Internet das Coisas: Tecnologias Atuais e Futuras, e o Papel do Software