Post on 24-Jul-2022
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
lid
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. Sli
de
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. Slid
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
lid
e
12
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. Sli
de
13
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
ayer
MA
C
Layer
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
lid
e
15
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
payloadMAC 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 typeSequrity
enabled
Frame
pendingAck. Req. Intra PAN Reserved
Dest.
addressing
mode
Reserved
Source
addressing
mode
Frame control field
05 2004 Marco Naeve, Eaton Corp. S
lid
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
extensionReserved
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
typeCommand 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 PayloadMAC
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.request
MLME-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
lid
e
26
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
lid
e
28
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. Sli
de
29
Device MAC
Coordinator MAC
Device higher layer
MLME-SCAN.request
MLME-SCAN.confirm
ScanDuration
Beacon
Set 1st Channel
Set 2nd
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 1st Channel
CSMA
Set 2nd
Channel
Beacon request
Edgard Jamhour Marco Naeve, Eaton Corp. S
lid
e
31
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
tack
LIFS tack
SIFS
Acknowledged transmission
Long frame Short frame
LIFS SIFS
Unacknowledged transmission
aTurnaroundTime tack
(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
Sli
de
33
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 broadcast
na 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 sistemas REST 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