Redes de Computadores - 6LowPan e Procolos para IOT

Prévia do material em texto

2017, Edgard Jamhour 
6LOWPAN E 
PROTOCOLOS PARA 
IOT 
EDGARD JAMHOUR 
IEEE 802.15.4 
Tecnologia de Radio “Low Power” 
Baixo Consumo 
Pequeno Alcance 
Baixas Taxas de Transmissão 
Pequeno MTU (Maximum Transmission Unit) 
CARACTERÍSTICAS DA TECNOLOGIA 
802.15.4 
Taxas de Transmissão: 
• 250 Kb/s, 40 Kb/s e 20 Kb/s 
 
Topologias: 
• Estrela ou Ponto-a-Ponto 
 
Frequências de Operação: 
• 16 canais em 2.4 GHz (ISM) 
• 10 canais em 915 MHz (ISM) 
• 1 canal em 868 MHz (Europeu) 
868MHz / 915MHz 
PHY 
2.4 GHz 
868.3 MHz 
Channel 0 Channels 1-10 
Channels 11-26 
2.4835 GHz 
928 MHz 902 MHz 
5 MHz 
2 MHz 
2.4 GHz 
PHY 
Joe Dvorak, Motorola 
BANDAS DE OPERAÇÃO E DIVISÃO EM 
CANAIS (VERSÃO 2006) 
Edgard Jamhour 
PILHA IEEE 802.15.4 
05 2004 
Marco Naeve, Eaton Corp. S
li
d
e
 5
 
IEEE 802.15.4 MAC 
Upper Layers 
IEEE 802.15.4 SSCS 
IEEE 802.2 
LLC, Type I 
IEEE 802.15.4 
2400 MHz 
PHY 
IEEE 802.15.4 
868/915 MHz 
PHY 
Preamble 
Start of 
Packet 
Delimiter 
PHY 
Header 
PHY Service 
Data Unit (PSDU) 
PHY Packet Fields 
• Preamble (32 bits) – sincronização 
• Start of Packet Delimiter (8 bits) 
• PHY Header (8 bits) – PSDU length 
• PSDU (0 to 1016 bits) – Data field 
6 Octets 0-127 Octets 
Joe Dvorak, Motorola 
IEEE 802.15.4 PHY OVERVIEW 
PACKET STRUCTURE 
TIPOS DE DISPOSITIVOS 
FULL Function Device (FFD) 
• Qualquer topologia 
• Pode ser coordenador de PAN 
• Conversa com qualquer outro dispositivo 
• Implementa toda a pilha do protocolo 
 
Reduced Function Device (RFD) 
• Opera em topologias estrela ou como “folhas” (end-devices) 
• Não podem ser coordenadores PAN 
• Implementação simples 
• Implementação simplificada da pilha de protocolos 
 
Marco Naeve, Eaton Corp. S
li
d
e
 8
 
STAR TOPOLOGY 
FFD 
RFD Communications flow 
Master/slave 
PAN 
coordinator 
Todos os nós se 
comunicam com 
um controlador 
PAN central 
 
Controlador PAN é 
um nó com uma 
fonte de energia 
confiável 
Marco Naeve, Eaton Corp. 
PEER-PEER TOPOLOGY 
Communications flow 
Point to point 
Cluster tree 
FFD 
RFD 
PAN 
coordinators 
Nós podem se comunicar 
através do controlador 
Central e através de nós 
FFD 
Edgard Jamhour 
CLUSTER TREE 
Marco Naeve, Eaton Corp. S
li
d
e
 1
1
 
COMBINED TOPOLOGY 
FFD 
RFD 
Communications flow 
Clustered stars – múltiplas redes em 
topologia estrela 
controladas por diferentes 
controladores e conectadas entre si 
Edgard Jamhour 
Marco Naeve, Eaton Corp. S
li
d
e
 
1
2
 
ESTRUTURA DE SUPERFRAME 
OPCIONAL 
15ms * 2n 
where 0  n  14 
GTS 3 GTS 2 
Network 
beacon 
Transmitido pelo coordenador PAN 
Beacon 
extension 
period 
Espaço reservado para crescimento do Beacon 
Contention 
period 
Acesso livre por CSMA-CA 
Guaranteed 
Time Slot 
Acesso de nós que precisam de garantia de banda [n = 0]. 
GTS 1 
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15Slot 
Battery life extension 
Contention Access Period Contention Free Period 
Marco Naeve, Eaton Corp. S
li
d
e
 
1
3
 
OPTIONAL FRAME STRUCTURE 
Superframe pode ter um periodo de inatividade 
15ms * 2BO 
where SO  BO  14 
15ms * 2SO 
where 0  SO  14 
SO = Superframe order 
BO = Beacon order 
Inactive Period 
Edgard Jamhour 
Payload
PH
Y L
aye
r
MA
C
Lay
er MAC Header
(MHR)
MAC Footer
(MFR)
MAC Protocol Data Unit (MPDU)
MAC Service Data Unit
(MSDU)
PHY Header
(PHR)
Synch. Header
(SHR)
PHY Service Data Unit (PSDU)
4 TIPOS DE QUADROS MAC 
• Data Frame 
• Beacon Frame 
• Acknowledgment Frame 
• MAC Command Frame 
Joe Dvorak, Motorola 
IEEE 802.15.4 MAC OVERVIEW 
ESTRUTURA GERAL DOS QUADROS 
05 2004 
Marco Naeve, Eaton Corp. S
li
d
e
 
1
5
 
FORMATO GERAL DOS QUADROS MAC 
Octets:2 1 0/2 0/2/8 0/2 0/2/8 variable 2
Destination 
PAN 
identifier
Destination 
address
Source 
PAN 
identifier
Source 
address
MAC 
payload
MAC footer
Frame 
check 
sequence
MAC header
Addressing fields
Frame 
control
Sequence 
number
Frame 
payload
Bits: 0-2 3 4 5 6 7-9 10-11 12-13 14-15
Frame type
Sequrity 
enabled
Frame 
pending
Ack. Req. Intra PAN Reserved
Dest. 
addressing 
mode
Reserved
Source 
addressing 
mode
Frame control field 
05 2004 
Marco Naeve, Eaton Corp. S
li
d
e
 1
6
 
QUADRO DO TIPO BEACON 
Bits: 0-3 4-7 8-11 12 13 14 15
Beacon 
order
Superframe 
order
Final CAP 
slot
Battery life 
extension
Reserved
PAN 
coordinator
Association 
permit
Octets:2 1 4 or 10 2 variable variable variable 2
MAC 
footer
Frame 
check 
sequence
MAC header
Source address 
information
MAC payload
Superframe 
specification
GTS 
fields
Pending 
address 
fields
Frame 
control
Beacon 
sequence 
number
Beacon payload
QUADROS DE COMANDO 
Tipos de Comando: 
Marco Naeve, Eaton Corp. 
Octets:2 1 4 to 20 1 variable 2
MAC 
footer
Frame 
check 
sequence
Frame 
control
Data 
sequence 
number
Address 
information
MAC header MAC payload
Command 
type
Command payload
• Association request 
• Association response 
• Disassociation notification 
• Data request 
• PAN ID conflict notification 
• Orphan Notification 
• Beacon request 
• Coordinator realignment 
• GTS request 
Edgard Jamhour 
Marco Naeve, Eaton Corp. 
QUADROS DE DADOS E ACK 
QUADROS ACK 
Octets:2 1 2
MAC 
footer
Frame 
check 
sequence
MAC header
Frame 
control
Data 
sequence 
number
Octets:2 1 4 to 20 variable 2
MAC Payload
MAC 
footer
Data payload
Frame 
check 
sequence
MAC header
Frame 
control
Data 
sequence 
number
Address 
information
TIPOS DE COMUNICAÇÃO 
• Com ou Sem confirmação (ACK) 
• Direto ou Indireto 
• Com ou sem garantia (GTS em modo beacon) 
 
• Maximum data length (MSDU) 
• aMaxMACFrameSize (102 bytes) 
 
Marco Naeve, Eaton Corp. 
PRIMITIVAS MAC 
A camada MAC oferece uma 
interface entre a camada de 
Aplicação e a camada PHY 
São oferecidos dois grupos de 
serviços: 
 
MLME-SAP: 
Serviços de Gerenciamento 
PIB (PAN Information Base) 
 
MCPS-SAP: 
Serviços de Dados 
 
Marco Naeve, Eaton Corp. 
Edgard Jamhour 
FUNCIONAMENTO DAS PRIMITIVAS 
wpan_: funções MAC 
usr_: funções callback 
Edgard Jamhour 
Marco Naeve, Eaton Corp. 
PRIMITIVAS MAC 
Edgard Jamhour 
Marco Naeve, Eaton Corp. 
DATA TRANSFER 
MESSAGE SEQUENCE DIAGRAM 
 
Originator 
MAC 
Recipient 
MAC 
Data frame 
Acknowledgment (if requested) 
Originator 
higher layer 
Recipient 
higher layer 
MCPS-DATA.request 
MCPS-DATA.indication 
MCPS-DATA.confirm 
Edgard Jamhour 
Marco Naeve, Eaton Corp. 
INDIRECT DATA TRANSFER 
MESSAGE SEQUENCE DIAGRAM 
 
Coordinator 
MAC 
Device 
MAC 
Data frame 
Acknowledgment 
Coordinator 
higher layer 
Device 
higher layer 
MCPS-DATA.request 
(indirect) 
MCPS-DATA.indication 
MCPS-DATA.confirm 
Beacon frame 
 
Data request 
Acknowledgement 
Edgard Jamhour 
Marco Naeve, Eaton Corp. 
ASSOCIATION 
MESSAGE SEQUENCE DIAGRAM 
 
Device 
MAC 
Coordinator 
MAC 
Association request 
Acknowledgment 
Device 
higher layer 
Coordinator 
higher layer 
MLME-ASSOCIATE.requestMLME-ASSOCIATE.indication 
MLME-ASSOCIATE.response 
Acknowledgement 
Association response 
MLME-ASSOCIATE.confirm 
aResponseWaitTime 
MLME-COMM-STATUS.indication 
Data request 
Acknowledgment 
Edgard Jamhour 
05 2004 
Marco Naeve, Eaton Corp. S
li
d
e
 
2
6
 
DISASSOCIATION 
MESSAGE SEQUENCE DIAGRAM 
= 
Originator 
MAC 
Recipient 
MAC 
Disassociation notification 
Acknowledgment 
Originator 
higher layer 
Recipient 
higher layer 
MLME-DISASSOCIATE.request 
MLME-DISASSOCIATE.indication MLME-DISASSOCIATE.confirm 
Edgard Jamhour 
Marco Naeve, Eaton Corp. 
DATA POLLING 
MESSAGE SEQUENCE CHART 
 
Device 
MAC 
Coordinator 
MAC 
Data request 
Acknowledgment (FP = 0) 
Device 
higher layer 
MLME-POLL.request 
MLME-POLL.confirm 
No data pending at the coordinator 
Edgard Jamhour 
Marco Naeve, Eaton Corp. S
li
d
e
 
2
8
 
DATA POLLING 
MESSAGE SEQUENCE CHART 
 
Device 
MAC 
Coordinator 
MAC 
Data request 
Acknowledgment (FP = 1) 
Device 
higher layer 
MLME-POLL.request 
MLME-POLL.confirm 
Data 
Acknowledgement 
MCPS-DATA.indication 
Data pending at the coordinator 
Edgard Jamhour 
PASSIVE SCAN 
 
Marco Naeve, Eaton Corp. S
li
d
e
 
2
9
 
 
Device 
MAC 
Coordinator 
MAC 
Device 
higher layer 
MLME-SCAN.request 
MLME-SCAN.confirm 
ScanDuration 
Beacon 
Set 1
st
 Channel 
Set 2
nd
 Channel 
Edgard Jamhour 
Marco Naeve, Eaton Corp. 
ACTIVE SCAN 
 
 
Device 
MAC 
Coordinator 
MAC 
Beacon request 
Device 
higher layer 
MLME-SCAN.request 
MLME-SCAN.confirm 
ScanDuration Beacon 
Set 1
st
 Channel 
CSMA 
Set 2
nd
 Channel 
Beacon request 
Edgard Jamhour 
Marco Naeve, Eaton Corp. S
li
d
e
 
3
1
 
ESPAÇAMENTO INTER-FRAME 
 
For frames ≤ aMaxSIFSFrameSize use short inter-frame spacing (SIFS) 
For frames > aMaxSIFSFrameSize use long inter-frame spacing (LIFS) 
Long frame ACK Short frame ACK
t
ack
LIFS t
ack
SIFS
Acknowledged transmission
Long frame Short frame
LIFS SIFS
Unacknowledged transmission
aTurnaroundTime  t
ack
  (aTurnaroundTime (12 symbols) + aUnitBackoffPeriod (20 symbols))
LIFS > aMaxLIFSPeriod (40 symbols)
SIFS > aMacSIFSPeriod (12 symbols)
Edgard Jamhour 
Marco Naeve, Eaton Corp. 
OPERAÇÃO CSMA 
NÃO SLOTTED 
NB = 0,
BE = macMinBE
Delay for
random(2BE - 1) unit
backoff periods
Perform CCA
Channel idle?
NB = NB+1,
BE = min(BE+1, aMaxBE)
NB>
macMaxCSMABackoffs
?
Failure Success
Un-slotted CSMA
Y
Y
N
N
Usado em Redes sem 
Beacon 
Edgard Jamhour 
S
li
d
e
 
3
3
 
OPERAÇÃO CSMA 
MODO SLOTTED 
NB = 0, CW = 0
Battery life
extension?
BE = macMinBE
BE = lesser of
(2, macMinBE)
Locate backoff
period boundary
Delay for
random(2BE - 1) unit
backoff periods
Perform CCA on
backoff period
boundary
Channel idle?
CW = 2, NB = NB+1,
BE = min(BE+1, aMaxBE)
CW = CW - 1
CW = 0?
NB>
macMaxCSMABackoffs
?
Failure Success
Slotted CSMA
Y
Y Y
Y
N
N
N
N
Modo Beacon 
VERSÕS DA TECNOLOGIA IEEE 802.15.4 
VERSÃO DETALHES 
IEEE 802.15.4 - 2003 DSSS (Direct Sequence Spread Spectrum) com taxas de 20 e 40Kbit/s 
IEEE 802.15.4 - 2006 Maiores taxas de transmissão em DSSS 
Adição do modo PSS (Parallel Sequence Spread Spectrum) 
IEEE 802.15.4a Adição do modo UWB (Direct Sequence Ultra-WideBand) 
Adição do modo CSS (Chirp Spread Spectrum) 
IEEE 802.15.4c ATUALIZAÇÃO DA PHYs e BANDA NA CHINA 779-787 MHz. 
IEEE 802.15.4d ATUALIZAÇÃO DA PHYs e BANDA NO JAPÃO 950 - 956 MHz 
IEEE 802.15.4e EXTENSÕES PARA AUTOMAÇÃO INDUSTRIAL 
IEEE 802.15.4f NOVAS PHYS PARA UWB, 2.4 e 433 MHz 
IEEE 802.15.4g PHY PARA SERVIÇOS MUNICIPAIS UTILITÁRIOS (ELETRICIDADE, GAS e 
AGUA) 
INCLUIR MELHORIAS NA BANDA 902 - 928 MHz 
WISUN ALLIANCE 
WWW.WI-SUN.ORG 
Especificação da FAN (Field Area Network) para Redes Utilitárias 
 
Comparação de Tecnologias Wireless para IoT: 
https://www.wi-sun.org/index.php/tcwp-en/file 
 
 
 
MOTIVAÇÃO PARA 6LOWPAN 
• Oferecer suporte a tecnologia IP para dispositivos de IoT 
• Aplicações desenvolvidas sobre IP são independentes da 
tecnologia de comunicação 
• Adaptar o uso de IPv6 as tecnologias de rádio existentes 
• IPv6: MTU mínimo de 1280 bytes 
• Cabeçalho IPv6: 40 bytes 
• Cabeçalho UDP: 8 bytes 
• IEEE 802.15.4: MSDU 102 bytes 
• 54 bytes por pacote (sem segurança) 
• 33 bytes por pacote (com segurança) 
6LOWPAN (RFC 4944) 
• Camada de adaptação para transporte de pacotes IPv6 sobre enlaces 
IEEE 802.15.4 
 
• Usa IEEE 802.15.4 em modo CSMA/CA unslotted (sem beacom) 
• Beacon apenas para descoberta de dispositivos 
 
• Introduz a fragmentação e remontagem de pacotes IPv6 
 
• Compressão dos cabeçalhos IPv6, UDP e ICMP 
 
• Suporte ao roteamento MESH (mesh under) 
Edgard Jamhour 
6LOWPAN & IEEE 802.15.4 
Chaiporn Jaikaeo 
Edgard Jamhour 
BYTE DISPATCH NO CABEÇALHO 
6LOWPAN 
6LOWPAN DISPATCH CODES 
• 6LowPAn inclui um cabeçalho que indica como o pacote foi 
encapsulado 
• Diversos formatos são suportados: 
 
COMPRESSÃO HC1 
• A versão é sempre 6 
• O Endereço IPv6 (HOST) pode ser inferido a partir do MAC 
• O tamanho do pacote pode ser obtido do quadro 
• Flow Label e Traffic Class são raramente usados (0) 
• Next Header é quase sempre TCP, UDP ou ICMP 
Cabeçalho IPv6 
Edgard Jamhour 
COMPRESSÃO HC1 
COMPRESSÃO HC2 
• Compressão de UDP de 8 para 3 bytes 
• O tamanho pode ser deduzido pelo tamanho do quadro 
• Restringir as portas a faixa: 61616-61631 (16 valores) 
• Portas podem ser representadas por 4 bits 
 
 
2 bytes 2 bytes 
CABEÇALHO UDP 
Edgard Jamhour 
COMPRESSÃO H1+H2 
Edgard Jamhour 
PAYLOAD COM E SEM COMPRESSÃO 
Sem Compressão (código 01000001) 
Com Compressão (código 01000010 = HC1) 
Pode ser seguido de compressão HC2 
Funciona apenas para 
endereços Link-Local 
IPHC: IMPROVED HC 
• Compressão HC1 e HC2 
são sem estado e 
funcionam apenas para 
endereços IPv6 do tipo 
Link Local 
• IPHC é uma forma de 
compressão mais geral, 
que operar em modo com 
ou sem estado 
• Os prefixos IPv6 são 
removidos 
 
QUADROS FRAMENTADOS 
1. Pacotes IPv6 maiores que o MTU são fragmentados 
 
2. Introduz campo de offset para fragmentos 
 
3. Tempo máximo de remontagem é 60 segundos 
 
Edgard Jamhour 
EXEMPLO 
Os endereços de 
origem e destino são 
mostrados no 
Wireshark, mas não 
são efetivamente 
transmitidos. 
 
O cabeçalho 6LowPan 
acaba no campo Hop 
Limit 
Edgard Jamhour 
EXEMPLO 
Pacotes fragmentados 
6LowPAN são muito 
mais simples que no 
IPv4, uma vez que o 
cabeçalho IP não é 
incluído no fragmento 
Edgard Jamhour 
EXEMPLO 
 
A compressão HC1 
não funciona para 
endereços Globais 
 
Nesse caso, é 
utilizado a 
compressão IPHC 
IMPLEMENTAÇÃO 6LOWPAN (STACK) 
Nesta configuração, 
o sistema 
operacional do 
MOTE efetua a 
conversão para 
6LowPAN 
Edgard Jamhour 
IMPLEMENTAÇÃO 6LOWPAN (GATEWAY) 
RNDIS: Remote Network Driver Interface Specification 
Nesta configuração, 
o adaptador de rede 
(NIC) efetua a 
conversão para 
6LowPAN 
Edgard Jamhour 
EXEMPLOS DE REDES 6LOWPAN 
Chaiporn Jaikaeo 
Gateway 
6LowPan para IPv6 
Edgard Jamhour 
MESH UNDER VS ROUTER 
RPL 
Emula um 
único domínio 
de broadcastna rede 
6LowPan 
 
Para camada 
de rede, a 
comunicação 
na WPAN é 
single hop 
Edgard Jamhour 
CABEÇALHO MESH UNDER 
Hop Left é decrementado a cada salto 
O quadro é descartando quando o valor 
chega a zero 
Edgard Jamhour 
IEEE 802.15.5 
Solução de Mesh-Under 
para redes IEEE 
802.15.4-2006 
 
IETF não especificou 
protocolos Mesh-Under 
para 6LowPan 
 
RPL é o protocolo padrão 
proposto pelo IETF para 
Router-Over em redes 
6LowPan 
RPL: IPV6 ROUTING PROTOCOL FOR LLN 
• Protocolo padrão proposto pelo IETF para 6LowPAN 
• Definido pela RFC 6550 (Março de 2012) 
• Destinado a LLN (Low-Power and Lossy Networks) 
• Assume restrições nos dispositivos de rede: 
• Consumo de energia, memória e processamento 
• Assume restrições nos meios de comunicação: 
• Altas taxas de perdas, baixas taxas de transmissão e instabilidade 
• Tecnologias de comunicação: 
• Rádios de baixa capacidade (IEEE 802.15.4) 
• PLC (Power Line Communications) 
Edgard Jamhour 
QUÃO RUIDOSO É UM AMBIENTE 
RUIDOSO? 
Muitos protocolos de 
roteamento propostos para 
redes sem fio irão tratar 
perda de pacotes como 
mudanças de topologia 
devido a mobilidade 
PROATIVO VS REATIVO 
Proativo: 
• Tentam obter informações de roteamento antes que sejam necessárias 
• Avalia as rotas continuamente, e encaminha pacotes para o destino 
assim que recebidos 
 
Reativo: 
• Obtém informação sobre a rota apenas quando ela é requisitada 
• O encaminhamento de pacotes para destinos ainda descobertos sofre 
atraso 
 
 
Edgard Jamhour 
PROTOCOLOS PARA REDES AD-HOC 
Redes Ad-Hoc 
são aquela 
formadas de 
forma natural, 
sem estrutura 
fixa definida 
RPL é Proativo 
e assume que 
as mudanças 
na rede são 
lentas 
Edgard Jamhour 
A REDE LLN É VISTA COMO UMA SUBREDE 
A REDE LLN NÃO SUPORTA BROADCAST 
IPv6 ND (Neighbor Discovery) 
assume que todos os nós de 
uma sub-rede estão no mesmo 
domínio de broadcast 
 
Contudo isso não é verdade 
para 6LowPAN 
 
RPL implementa uma 
abordagem “Router Over” e usa 
uma versão simplificado do 
protocolo IPv6 ND 
NEIGHBOR DISCOVERY PARA 6LOWPAN 
• ND: Neighbor Discovery 
• NS: Neighbor Solicitiation 
• NA: Neighbor Advertisement 
 
• A RFC6675 (2012) modifica o comportamento do protocolo ND do IPv6 para redes 
6LowPAN. 
• Permitir que host entrem em modo sleep 
• Eliminar a resolução de endereços multicast pelos hosts 
• Permitir a descoberta de vizinhos através de mensagens em unicast (NA e NS) 
• Distribuir contexto de compressão de cabeçalho para hosts 
• Multihop Duplicate Address Detection (DAD) com 2 novas mensagens 
 
 
ND PARA 6LOWPAN 
Nós se registram nos roteadores informado seus endereços 
Todos os endereços, exceto os multicast e os FE80:: são considerados off-link, isto é, 
enviados ao roteador. 
host 
6LR 
RS 
RA 
NS com ARO 
NS com ARO 
... 
NA OK/NOK 
Neighbor Cache Entries 
(NCEs) 
 
Todos os endereços 
registrados pelos nós com 
TTL 
RS: Router Solicitation 
RA: Router Advertisement 
NS: Neighbor Advertisement 
ARO: Address Registration Option 
DODAG VS DAG 
• DODAG: Directed Oriented Acyclic Graph 
• Árvores: Um único caminho até a raiz (Root) 
• DAG: Um ou mais caminhos até um ou mais Rots (sem loops) 
• DODAG: DAG com apenas um ROOT 
Edgard Jamhour 
RPL: TOPOLOGIA DODAG 
Para o nó G 
D,H,L são vizinhos 
D é o pai preferencial 
Enlaces tem um 
custo (ETX, atraso, 
distância, etc.) 
que pode ser 
penalizado se o nó 
estiver com pouca 
energia, por 
exemplo. 
Para o nó I 
E é o pai (único) 
G & H são irmãos 
MÉTRICA ETX 
ETX: Número estimado de tentativas para que um pacote seja enviado de A 
para B e confirmado com sucesso 
 
ETX = (tAB * tBA)
-1 
• tAB: taxa de sucesso no envio de A para B (dado) 
• tBA: taxa de sucesso no envio de B para A (confirmação) 
 
Exemplo: Suponha que um enlace perca em média 50% da mensagens 
• ETX = 0.52 = 4 
• São esperadas em média 4 transmissões 
 
 
Edgard Jamhour 
RANK: MEDIDA DA DISTÂNCIA DE UM 
NÓ ATÉ O ROOT (LBR) 
Edgard Jamhour 
O RANK DO PAI DEVE SER SEMPRE 
MAIOR QUE O DOS FILHOS 
Para o G poder usar o 
nó H ele precisa 
aumentar seu Rank até 
ele ficar maior que o 
Rank de H 
O Rank de um nó é o 
Rank do pai mais o 
custo do enlace até o 
pai 
Rank é uma medida da 
distância do nó até o 
Root (6LBR) 
Inicialmente, esse Rank 
pode ser apenas a 
soma do custo dos 
enlaces. 
Contudo um nó pode 
mudar seu Rank para 
poder conectar-se a um 
vizinho 
Edgard Jamhour 
MENSAGENS DO RPL 
Edgard Jamhour 
MENSAGEM RPL 
DIO 
Nós 6LR enviam 
periodicamente mensagens 
DIO, em multicast (ff02::1a), 
contendo seu Rank 
Nós que recebem uma 
mensagem DIO deixam de 
ser órfãos e passam a fazer 
parte da DODAG 
Mensagens DIO são tipos 
especiais de mensagens 
ICMPv6 
DIO: DODAG Information 
Object 
ALGORITMO TRICKLE 
• Mensagens DIO são enviadas de acordo com o algoritmo TRICKLE (RFC 
6206). 
• O intervalo entre mensagens DIO aumenta exponencialmente quando a 
rede está estável (consistência). 
• O intervalo decresce abruptamente quando há uma alteração na rede 
(inconsistência). 
Intervalo 
de envio 
(ms) 
rede consistente: o LBR mantém o mesmo pai e o mesmo Rank 
rede inconsistente: o LBR ficou 
órfão ou mudou de Rank 
MENSAGENS RPL DAO 
Mensagens DAO (Destination 
Advertisement Object) são enviadas 
em unicast para o pai preferencial (e 
opcionalmente, alternativos). 
Elas carregam o endereço dos nós 
alcançáveis pelo 6LBR (ele próprio 
e abaixo dele na DODAG) 
STORING VS NON-STORING 
Modo Storing: 
• As informações da DAO são armazenadas localmente pelos 6LR. 
• Cada nó conhece todos os nós na sub-DODAG abaixo dele. 
• A comunicação entre dois nós quaisquer sobe em direção ao 6LBR até 
encontrar um pai comum aos nós 
 
 
Modo Non-Storing: 
• Nós 6LR não armazenam informações de rota, apenas o 6LBR. 
• A comunicação entre nós precisa passar sempre pelo 6LBR. 
 
Edgard Jamhour 
TIPOS DE COMUNICAÇÃO 
Rotas DIO Rotas DAO Rotas DAO Non-Storing 
COAP: CONSTRAINED APPLICATION 
PROTOCOL 
• Definido pela RF7228 (2014) 
 
• Protocolo de aplicação para “constrained devices” 
• Micro-controladores de 8 bits 
• Pouca quantidade de RAM e ROM 
• Rede de comunicação limitada (6LowPan) 
• Alta taxa de perda e throughput de dezenas de kbit/s 
 
• Pode ser facilmente traduzível para HTTP 
 
 
REST (REPRESENTATIONAL STATE 
TRANSFER ) 
• REST é um conjunto de restrições que são usadas como guia para obter um sistema escalável 
• Um sistema REST podem ser implementado em HTTP, SNMP, SMTP 
• Um sistema RESTfull satisfaz as seguintes restrições: 
Arquitetura cliente-servidor • A interface com o usuário existe apenas na aplicação cliente 
• O servidor é responsável por armazenar os dados 
Sem estado 
 
• As requisições do cliente contém toda a informação para o servidor processar a consulta 
• O “estado” é mantido no cliente, e o servidor não mantém estado do cliente 
Cacheável 
 
• Clientes e intermediários podem cachear respostas 
• Respostas indica se podem ou não ser cacheadas 
Sistema em Camadas 
 
• O cliente não pode dizer se está conectado ao servidor final ou a um nó intermediário 
[Código sob Demanda] 
 
• Servidores podem transferir código para o cliente (JavaScript ou Java Applets) 
Interface Uniforme 
 
• URI em sistemasREST baseados em WEB 
• Respostas em: XML, HTML ou JSON 
 
HTTP REST 
INTERFACE UNIFORME 
• URL: Uniform Resource Locator 
• URN: Uniform Resource Name 
• URI: Uniform Resource Identifier 
Edgard Jamhour 
HTTP REST 
OPERAÇÔES 
URL GET PUT PATCH 
/POST 
DELETE 
Coleção: 
https://a.b.com/resources 
Lista as 
URIs 
Substitui a 
coleção 
POST 
Cria nova 
entrada 
Apaga a 
coleção 
Elemento: 
https://a.b.com/resources/iten1 
Recupera o 
elemento 
Substitui o 
elemento 
PATCH 
Atualiza o 
elemento 
Apaga o 
elemento 
PARADIGMA WEB SERVICE 
Web Service é um serviço oferecido de um dispositivo eletrônico para 
outro (M2M) usando padrões WWW 
Atualmente, um Web Service pode ser implementado de duas formas: 
• SOAP sobre HTTP 
• responde com recursos XML 
• Descreve a interface com WSDL 
 
• REST sobre HTTP 
• responde com XML, JSON ou 
HTML 
• Stateless 
Linguagem que permite descrever 
nome de funções, argumentos e 
valore retornados 
REQUISIÇÃO HTTP 
• HTTP é implementado sobre TCP 
• O overhead gerado em um simples requisição de recurso HTTP é 
muito grande devido as mensagens necessárias para criar e 
terminar a conexão TCP. 
7 mensagens 
5 mensagens de conexão TCP 
2 mensagens HTTP 
CORE – CONSTRAINED RESTFUL 
ENVIRONMENTS 
Para aplicações de IoT o sistema REST precisa ser implementado 
sobre um protocolo de transporte mais leve que HTTP/TCP 
COAP: CONSTRAINED APPLICATION 
PROTOCOL 
• Protocolo de transferência Web para sistemas embarcados (coap://) 
• Modelo de transação assíncrono 
• Transporte UDP com suporte a multicast e confiabilidade 
• Métodos: GET, POST, PUT e DELETE 
• Suporte a URI 
• Cabeçalho simples < 10 bytes 
• Subset de tipos MIME e códigos de resposta HTTP 
• Observação, Transferência de Bloco e Descoberta opcionais 
ARQUITETURA CORE 
CONSTRAINED RESTFUL ENVIRONMENTS 
Aplicações de IoT que comunicam-se com a CLOUD são formadas por dois tipos de 
rede: 
• Com restrições: ambiente wireless dos nós IoT 
• Sem restrições: Internet 
A comunicação COAP pode ser fim-a-fim ou ser convertida para HTTP através de um 
Proxy (RFC 8075) 
Cliente
HTTP 
HTTP-to-Coap 
Proxy 
CoAP 
Server 
HTTP 
request 
HTTP 
response CoAP 
request 
CoAP 
response 
O QUE É COAP 
O QUE NÃO É COAP 
COAP é um protocolo: 
• RESTful 
• Que opera em modo síncrono e assíncrono 
• Que suporta dispositivos e redes com restrições 
• Especializado para aplicações M2M 
• Que pode ser facilmente convertido em HTTP 
 
COAP não é: 
• Um substituto do HTTP 
• Uma forma de compressão de HTTP 
• Um protocolo para operar fora da Web 
 
MODOS DE COMUNICAÇÃO COAP 
Mensagem confirmável/ não-confirmável 
Mensagem ACK 
Mensagem RESET (cancela um pedido) 
Piggyback: a resposta é 
enviada junto com ACK 
CABEÇALHO COAP 
Version (Ver) : 1 
Type (T): 0=confirmable, 1=non-confirmable, 2=ACK (2) e 3=Reset 
Token Length (TKL): tamanho do Token 
Code: 3bit class: 5 bit detail (códigos indicam sucesso ou erro) 
Message ID: usado para detectar mensagens duplicadas e associar confirmações 
Options: Formato TLV 
Edgard Jamhour 
MENSAGEM COAP 
Edgard Jamhour 
EXEMPLOS: MENSAGENS COM E SEM 
CONFIRMAÇÃO 
Edgard Jamhour 
EXEMPLOS: PIGGYBACKED 
Edgard Jamhour 
EXEMPLO: SEPARATED E NÃO CONFIMADA 
Separate response é usada para processar 
requisições que podem levar muito tempo para 
serem respondidas 
 
Observe que a associação entre requisição e 
resposta é feita pelo Token 
COAP server 
COAP server 
TRANSMISSÃO CONFIÁVEL 
• Similar ao TCP, a 
mensagem é re-enviada 
caso um ACK ou RST não 
seja recebido a tempo 
• Número máximo de 
retransmissões = 4 
• Tempo total máximo para 
enviar uma mensagem = 
93s 
• O tempo de espera é 
dobrado a cada 
retransmissão 
http://programmingwithreason.com/article-iot-coap.html 
COAP server 
Edgard Jamhour 
OPÇÕES 
PROXYING E CACHING 
A opção max-age 
controla o tempo 
que os dados 
podem permanecer 
em cache 
COAP OBSERVATION 
O modelo REST é do tipo PULL 
Dados são obtidos mediante o envio 
de uma requisição 
Contudo, em muitas aplicações de 
IoT, dados são enviados 
periodicamente pelos sensores 
Para atender a essa demanda a 
opção Observe foi introduzida pela 
RFC 7641 
COAP server 
DEVICE DISCOVERY 
Um dispositivo é identificado por uma ou mais URIs: 
• coap://example.com:5683/~sensors/readings.xml 
COAP suporta a descoberta dinâmica de dispositivos através da requisição NON GET: 
• "coap://FF05::FD:5683/.well-known/core" 
Dispositivos que desejam ser descobertos escutam o endereço multicast: 
• “All CoAP Nodes” na porta UDP 5638 
• 224.0.1.187 (IPv4) ou FF05::FD (IPv6) 
O dispositivo responde com seu endereço Unicast, Porta e URIs 
COAP Resource Directory é uma 
entidade (um nó especial na rede) que 
mantém a descrição dos servidores 
COAP e seus recursos 
 
Nós se registram enviando um POST 
MQTT: MESSAGE QUEUE TELEMETRY 
TRANSPORT 
Protocolo PUBLISH/SUBSCRIBE transportado sobre TCP, originalmente desenvolvido 
pela IBM 
MQQT segue uma arquitetura, cliente-servidor, onde o servidor denomina-se Broker 
 O broker distribui mensagens para 
clientes interessados nos tópicos da 
mensagem 
TÓPICOS MQTT 
As informações publicadas pelos sensores são identificadas por “tópicos” no seguinte formato: 
• area/ID/sensor/ID/temperatura 
• area/ID/sensor/ID/umidade 
 
As publicações possíveis seriam: 
• area/10/sensor/5000/temperatura 
• area/10/sensor/5000/umidade 
• area/10/sensor/5001/temperatura 
• area/10/sensor/5001/umidade 
• area/20/sensor/4000/temperatura 
• area/20/sensor/4000/umidade 
• area/20/sensor/4001/temperatura 
• area/20/sensor/4001/umidade 
 
Wildcards pode ser usada para ignorar um (+) ou múltiplos (#) diretórios: 
• Informações de temperatura de todos os sensores na área 10 
• area/10/sensor/+/temperatura 
• Todas as informações de todos os sensores na área 20 
• area/20/sensor/# 
 
 
NÍVEIS DE QOS 
• O Broker persiste apenas a última mensagem recebida 
• Se o mesmo tópico for enviado para o Broker, ele substitui o valor anterior 
 
• A conexão com o broker obedece aos seguintes níveis de QoS: 
 
• QoS 0 (at most once) 
• Mensagens são enviadas sem confirmação ou retransmissão 
• QoS 1 (at least once) 
• Mensagens são enviadas e retransmitidas até obter confirmação 
• QoS 2 (exactly once) 
• Garante que a mensagem será enviada uma única vez 
• A confirmação é feita nos dois sentidos: confirmação de recebimento e confirmação de 
recebimento de recebimento 
 
MQTT-SN 
• Implementação de MQTT sobre UDP 
• Utiliza a mesma semântica 
• Clientes MQTT-SN são nós wireless que se comunicam via Gateway 
com o Broker MQTT 
https://www.slideshare.net/nivertech/zvi-mqtts-foreuc2013 
Edgard Jamhour 
MQTT VS COAP 
Edgard Jamhour 
FIM