6LOWPAN E PROTOCOLOS PARA IOT - PPGIa

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


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


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


IEEE 802.15.4 MAC OVERVIEW ESTRUTURA GERAL DOS QUADROS


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


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:


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)


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


Edgard Jamhour

FUNCIONAMENTO DAS PRIMITIVAS

wpan_: funções MAC

usr_: funções callback


PRIMITIVAS MAC


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


INDIRECT DATA TRANSFER


Coordinator

MAC Device MAC

Data frame

Acknowledgment

Coordinator higher layer

Device higher layer

MCPS-DATA.request (indirect)


MCPS-DATA.confirm

Beacon frame

Data request

Acknowledgement


ASSOCIATION


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


lid

e

26

DISASSOCIATION


= Originator

MAC Recipient

MAC

Disassociation notification

Acknowledgment

Originator higher layer

Recipient higher layer

MLME-DISASSOCIATE.request

MLME-DISASSOCIATE.indication MLME-DISASSOCIATE.confirm


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


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


Data pending at the coordinator

Edgard Jamhour

PASSIVE SCAN


de

29

Device MAC

Coordinator MAC

Device higher layer

MLME-SCAN.request

MLME-SCAN.confirm

ScanDuration

Beacon

Set 1st Channel

Set 2nd

Channel


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


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)


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

http://www.wi-sun.org/









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

https://a.b.com/resources

https://a.b.com/resources/iten1

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







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

Documents

6LOWPAN E PROTOCOLOS PARA IOT - PPGIa