6LOWPAN E PROTOCOLOS PARA IOT EDGARD JAMHOUR

Transcrição

1 6LOWPAN E PROTOCOLOS PARA IOT EDGARD JAMHOUR 2017, Edgard Jamhour

2 IEEE Tecnologia de Radio Low Power Baixo Consumo Pequeno Alcance Baixas Taxas de Transmissão Pequeno MTU (Maximum Transmission Unit)

3 CARACTERÍSTICAS DA TECNOLOGIA 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)

4 BANDAS DE OPERAÇÃO E DIVISÃO EM CANAIS (VERSÃO 2006) 868MHz / 915MHz PHY Channel 0 Channels MHz MHz 902 MHz 928 MHz 2.4 GHz PHY Channels MHz 2.4 GHz GHz Joe Dvorak, Motorola

5 Slide 5 PILHA IEEE Upper Layers IEEE SSCS IEEE LLC, Type I IEEE MAC IEEE /915 MHz PHY IEEE MHz PHY Marco Naeve, Eaton Corp. Edgard Jamhour

6 Joe Dvorak, Motorola IEEE PHY OVERVIEW PACKET STRUCTURE 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 Preamble Start of Packet Delimiter PHY Header PHY Service Data Unit (PSDU) 6 Octets Octets

7 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

8 Slide 8 STAR TOPOLOGY PAN coordinator Todos os nós se comunicam com um controlador PAN central Master/slave Controlador PAN é um nó com uma fonte de energia confiável FFD RFD Communications flow Marco Naeve, Eaton Corp.

9 PEER-PEER TOPOLOGY Cluster tree PAN coordinators Marco Naeve, Eaton Corp. FFD RFD Point to point Communications flow Nós podem se comunicar através do controlador Central e através de nós FFD

10 CLUSTER TREE Edgard Jamhour

11 Slide 11 COMBINED TOPOLOGY Clustered stars múltiplas redes em topologia estrela controladas por diferentes controladores e conectadas entre si FFD Communications flow RFD Marco Naeve, Eaton Corp.

12 Slide ESTRUTURA DE SUPERFRAME OPCIONAL Battery life extension GTS 3 GTS 2 GTS 1 Contention Access Period Contention Free Period Slot ms * 2 n where 0 n 14 Network beacon Beacon extension period Contention period Transmitido pelo coordenador PAN Espaço reservado para crescimento do Beacon Acesso livre por CSMA-CA Guaranteed Time Slot Acesso de nós que precisam de garantia de banda [n = 0]. Marco Naeve, Eaton Corp. Edgard Jamhour

13 Slide OPTIONAL FRAME STRUCTURE Inactive Period 15ms * 2 SO where 0 SO 14 15ms * 2 BO where SO BO 14 SO = Superframe order BO = Beacon order Superframe pode ter um periodo de inatividade Marco Naeve, Eaton Corp.

14 IEEE MAC OVERVIEW ESTRUTURA GERAL DOS QUADROS Payload MAC Layer MAC Header (MHR) MAC Service Data Unit (MSDU) MAC Footer (MFR) PHY Layer Synch. Header (SHR) PHY Header (PHR) MAC Protocol Data Unit (MPDU) PHY Service Data Unit (PSDU) 4 TIPOS DE QUADROS MAC Data Frame Beacon Frame Acknowledgment Frame MAC Command Frame Joe Dvorak, Motorola Edgard Jamhour

15 Slide FORMATO GERAL DOS QUADROS MAC Octets:2 1 0/2 0/2/8 0/2 0/2/8 variable 2 Destination Source Destination Source Frame Frame Sequence PAN PAN Frame address address check control number identifier identifier payload sequence Addressing fields MAC header MAC payload MAC footer Bits: Dest. Source Sequrity Frame Frame type Ack. Req. Intra PAN Reserved addressing Reserved addressing enabled pending mode mode Marco Naeve, Eaton Corp Frame control field

16 Slide 16 QUADRO DO TIPO BEACON Octets:2 1 4 or 10 2 variable variable variable 2 Frame control Beacon sequence number MAC header Source address information Superframe specification GTS fields Pending address fields MAC payload Beacon payload Frame check sequence MAC footer Bits: Beacon Superframe Final CAP Battery life PAN Association Reserved order order slot extension coordinator permit Marco Naeve, Eaton Corp

17 QUADROS DE COMANDO Octets:2 1 4 to 20 1 variable 2 Frame control Data sequence number MAC header Address information Command type Tipos de Comando: Command payload MAC payload Frame check sequence MAC footer Association request Association response Disassociation notification Data request PAN ID conflict notification Orphan Notification Beacon request Coordinator realignment GTS request Marco Naeve, Eaton Corp.

18 QUADROS DE DADOS E ACK Octets:2 1 4 to 20 variable 2 Data Frame Frame Address sequence Data payload check control information number sequence MAC MAC header MAC Payload footer QUADROS ACK Octets:2 1 2 Data Frame Frame sequence check control number sequence MAC MAC header footer Marco Naeve, Eaton Corp. Edgard Jamhour

19 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.

20 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.

21 FUNCIONAMENTO DAS PRIMITIVAS wpan_: funções MAC usr_: funções callback Edgard Jamhour

22 PRIMITIVAS MAC Marco Naeve, Eaton Corp. Edgard Jamhour

23 DATA TRANSFER MESSAGE SEQUENCE DIAGRAM Originator higher layer Originator MAC Recipient MAC Recipient higher layer MCPS-DATA.request Data frame Acknowledgment (if requested) MCPS-DATA.indication MCPS-DATA.confirm Marco Naeve, Eaton Corp. Edgard Jamhour

24 INDIRECT DATA TRANSFER MESSAGE SEQUENCE DIAGRAM Coordinator higher layer Coordinator MAC Device MAC Device higher layer MCPS-DATA.request (indirect) Beacon frame Data request Acknowledgement Data frame Acknowledgment MCPS-DATA.indication MCPS-DATA.confirm Marco Naeve, Eaton Corp. Edgard Jamhour

25 ASSOCIATION MESSAGE SEQUENCE DIAGRAM Device higher layer Device MAC Coordinator MAC Coordinator higher layer MLME-ASSOCIATE.request Association request Acknowledgment MLME-ASSOCIATE.indication aresponsewaittime MLME-ASSOCIATE.response Data request Acknowledgment Association response MLME-ASSOCIATE.confirm Acknowledgement MLME-COMM-STATUS.indication Marco Naeve, Eaton Corp. Edgard Jamhour

26 Slide DISASSOCIATION MESSAGE SEQUENCE DIAGRAM = Originator higher layer Originator MAC Recipient MAC Recipient higher layer MLME-DISASSOCIATE.request Disassociation notification Acknowledgment MLME-DISASSOCIATE.confirm MLME-DISASSOCIATE.indication Marco Naeve, Eaton Corp Edgard Jamhour

27 DATA POLLING MESSAGE SEQUENCE CHART Device higher layer MLME-POLL.request Device MAC Coordinator MAC Data request Acknowledgment (FP = 0) MLME-POLL.confirm No data pending at the coordinator Marco Naeve, Eaton Corp. Edgard Jamhour

28 Slide DATA POLLING MESSAGE SEQUENCE CHART Device higher layer MLME-POLL.request Device MAC Data request Coordinator MAC Acknowledgment (FP = 1) Data MLME-POLL.confirm Acknowledgement MCPS-DATA.indication Data pending at the coordinator Marco Naeve, Eaton Corp. Edgard Jamhour

29 Slide 29 PASSIVE SCAN Device higher layer Device MAC Coordinator MAC MLME-SCAN.request Set 1 st Channel ScanDuration Beacon Set 2 nd Channel MLME-SCAN.confirm Marco Naeve, Eaton Corp. Edgard Jamhour

30 ACTIVE SCAN Device higher layer Device MAC Coordinator MAC MLME-SCAN.request Set 1 st Channel Beacon request CSMA ScanDuration Beacon Set 2 nd Channel Beacon request MLME-SCAN.confirm Marco Naeve, Eaton Corp. Edgard Jamhour

31 Slide ESPAÇAMENTO INTER-FRAME Acknowledged transmission Long frame ACK Short frame ACK t ack LIFS t ack SIFS Unacknowledged transmission Long frame Short frame LIFS SIFS aturnaroundtime t ack (aturnaroundtime (12 symbols) + aunitbackoffperiod (20 symbols)) LIFS > amaxlifsperiod (40 symbols) SIFS > amacsifsperiod (12 symbols) For frames amaxsifsframesize use short inter-frame spacing (SIFS) For frames > amaxsifsframesize use long inter-frame spacing (LIFS) Marco Naeve, Eaton Corp. Edgard Jamhour

32 OPERAÇÃO CSMA NÃO SLOTTED Un-slotted CSMA NB = 0, BE = macminbe Delay for random(2 BE - 1) unit backoff periods Perform CCA Usado em Redes sem Beacon Channel idle? N Y NB = NB+1, BE = min(be+1, amaxbe) N NB> macmaxcsmabackoffs? Y Failure Success Marco Naeve, Eaton Corp. Edgard Jamhour

33 Slide OPERAÇÃO CSMA MODO SLOTTED Slotted CSMA NB = 0, CW = 0 Delay for random(2 BE - 1) unit backoff periods Battery life extension? Y BE = lesser of (2, macminbe) Perform CCA on backoff period boundary N BE = macminbe Channel idle? Y N Locate backoff period boundary CW = 2, NB = NB+1, BE = min(be+1, amaxbe) CW = CW - 1 N NB> macmaxcsmabackoffs? CW = 0? N Modo Beacon Y Failure Y Success Edgard Jamhour

34 VERSÕS DA TECNOLOGIA IEEE VERSÃO DETALHES IEEE DSSS (Direct Sequence Spread Spectrum) com taxas de 20 e 40Kbit/s IEEE Maiores taxas de transmissão em DSSS Adição do modo PSS (Parallel Sequence Spread Spectrum) IEEE a IEEE c IEEE d IEEE e IEEE f IEEE g Adição do modo UWB (Direct Sequence Ultra-WideBand) Adição do modo CSS (Chirp Spread Spectrum) ATUALIZAÇÃO DA PHYs e BANDA NA CHINA MHz. ATUALIZAÇÃO DA PHYs e BANDA NO JAPÃO MHz EXTENSÕES PARA AUTOMAÇÃO INDUSTRIAL NOVAS PHYS PARA UWB, 2.4 e 433 MHz PHY PARA SERVIÇOS MUNICIPAIS UTILITÁRIOS (ELETRICIDADE, GAS e AGUA) INCLUIR MELHORIAS NA BANDA MHz

35 WISUN ALLIANCE Especificação da FAN (Field Area Network) para Redes Utilitárias Comparação de Tecnologias Wireless para IoT:

36 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 : MSDU 102 bytes 54 bytes por pacote (sem segurança) 33 bytes por pacote (com segurança)

37 6LOWPAN (RFC 4944) Camada de adaptação para transporte de pacotes IPv6 sobre enlaces IEEE Usa IEEE 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)

38 6LOWPAN & IEEE Chaiporn Edgard Jamhour Jaikaeo

39 BYTE DISPATCH NO CABEÇALHO 6LOWPAN Edgard Jamhour

40 6LOWPAN DISPATCH CODES 6LowPAn inclui um cabeçalho que indica como o pacote foi encapsulado Diversos formatos são suportados:

41 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

42 COMPRESSÃO HC1 Edgard Jamhour

43 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: (16 valores) Portas podem ser representadas por 4 bits 2 bytes 2 bytes CABEÇALHO UDP

44 COMPRESSÃO H1+H2 Edgard Jamhour

45 PAYLOAD COM E SEM COMPRESSÃO Sem Compressão (código ) Com Compressão (código = HC1) Pode ser seguido de compressão HC2 Funciona apenas para endereços Link-Local Edgard Jamhour

46 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

47 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

48 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

49 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

50 EXEMPLO A compressão HC1 não funciona para endereços Globais Nesse caso, é utilizado a compressão IPHC Edgard Jamhour

51 IMPLEMENTAÇÃO 6LOWPAN (STACK) Nesta configuração, o sistema operacional do MOTE efetua a conversão para 6LowPAN

52 IMPLEMENTAÇÃO 6LOWPAN (GATEWAY) Nesta configuração, o adaptador de rede (NIC) efetua a conversão para 6LowPAN RNDIS: Remote Network Driver Interface Specification Edgard Jamhour

53 EXEMPLOS DE REDES 6LOWPAN Gateway 6LowPan para IPv6 Chaiporn Jaikaeo Edgard Jamhour

54 MESH UNDER VS ROUTER Emula um único domínio de broadcast na rede 6LowPan Para camada de rede, a comunicação na WPAN é single hop RPL Edgard Jamhour

55 CABEÇALHO MESH UNDER Hop Left é decrementado a cada salto O quadro é descartando quando o valor chega a zero Edgard Jamhour

56 IEEE Solução de Mesh-Under para redes IEEE IETF não especificou protocolos Mesh-Under para 6LowPan RPL é o protocolo padrão proposto pelo IETF para Router-Over em redes 6LowPan Edgard Jamhour

57 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 ) PLC (Power Line Communications)

58 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 Edgard Jamhour

59 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

60 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

61 A REDE LLN É VISTA COMO UMA SUBREDE Edgard Jamhour

62 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

63 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

64 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 RS RA NS com ARO 6LR Neighbor Cache Entries (NCEs) Todos os endereços registrados pelos nós com TTL NA OK/NOK... NS com ARO RS: Router Solicitation RA: Router Advertisement NS: Neighbor Advertisement ARO: Address Registration Option

65 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

66 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 Edgard Jamhour

67 MÉTRICA ETX ETX: Número estimado de tentativas para que um pacote seja enviado de A para B e confirmado com sucesso ETX = (t AB * t BA ) -1 t AB : taxa de sucesso no envio de A para B (dado) t BA: taxa de sucesso no envio de B para A (confirmação) Exemplo: Suponha que um enlace perca em média 50% da mensagens ETX = = 4 São esperadas em média 4 transmissões

68 RANK: MEDIDA DA DISTÂNCIA DE UM NÓ ATÉ O ROOT (LBR) Edgard Jamhour

69 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 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 O Rank de um nó é o Rank do pai mais o custo do enlace até o pai Edgard Jamhour

70 MENSAGENS DO RPL Edgard Jamhour

71 MENSAGEM RPL DIO DIO: DODAG Information Object 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 Edgard Jamhour

72 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). rede consistente: o LBR mantém o mesmo pai e o mesmo Rank Intervalo de envio (ms) rede inconsistente: o LBR ficou órfão ou mudou de Rank

73 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)

74 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.

75 TIPOS DE COMUNICAÇÃO Rotas DIO Rotas DAO Rotas DAO Non-Storing Edgard Jamhour

76 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

77 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

78 HTTP REST INTERFACE UNIFORME URL: Uniform Resource Locator URN: Uniform Resource Name URI: Uniform Resource Identifier

79 HTTP REST OPERAÇÔES URL GET PUT PATCH /POST Coleção: Elemento: Lista as URIs Recupera o elemento Substitui a coleção Substitui o elemento POST Cria nova entrada PATCH Atualiza o elemento DELETE Apaga a coleção Apaga o elemento Edgard Jamhour

80 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 Linguagem que permite descrever nome de funções, argumentos e valore retornados REST sobre HTTP responde com XML, JSON ou HTML Stateless

81 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

82 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

83 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

84 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 request HTTP response CoAP request HTTP-to-Coap Proxy CoAP response CoAP Server

85 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

86 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

87 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

88 MENSAGEM COAP Edgard Jamhour

89 EXEMPLOS: MENSAGENS COM E SEM CONFIRMAÇÃO Edgard Jamhour

90 EXEMPLOS: PIGGYBACKED Edgard Jamhour

91 EXEMPLO: SEPARATED E NÃO CONFIMADA COAP server 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 Edgard Jamhour

92 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 COAP server

93 OPÇÕES Edgard Jamhour

94 PROXYING E CACHING A opção max-age controla o tempo que os dados podem permanecer em cache

95 COAP OBSERVATION COAP server 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

96 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 (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

97 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

98 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/#

99 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

100 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

101 MQTT VS COAP Edgard Jamhour

102 FIM Edgard Jamhour