redes lorawan: implantação e, desenvolvimento de aplicações · 2019-03-11 · para...

Jean Michel de Souza Sant’Ana

Redes LoRaWAN: implantação edesenvolvimento de aplicações

São José

2017



Trabalho de Conclusão de Curso do Bacha-relado em Engenharia de Telecomunicaçõesdo Instituto Federal de Educação, Ciência eTecnologia de Santa Catarina apresentado àbanca avaliadora para obtenção do grau deEngenheiro de Telecomunicações.

Instituto Federal de Educação, Ciência e Tecnologia de Santa Catarina

Bacharelado em Engenharia de Telecomunicações

Orientador: Prof. MSc. Arliones Stevert Hoeller JrCoorientador: Prof. Dr. Mario de Noronha Neto

São José2017



Trabalho de Conclusão de Curso do Bacha-relado em Engenharia de Telecomunicaçõesdo Instituto Federal de Educação, Ciência eTecnologia de Santa Catarina apresentado àbanca avaliadora para obtenção do grau deEngenheiro de Telecomunicações.

Trabalho aprovado. São José, 3 de março de 2017:

Prof. MSc. Arliones Stevert Hoeller JrIFSC - Orientador

Prof. Dr. Mario de Noronha NetoIFSC - Co-orientador

Prof. Dr. Richard Demo SouzaUTFPR - Avaliador

Prof. Dr. Odilson Tadeu ValleIFSC - Avaliador

Prof. Dr. Marcelo Maia SobralIFSC - Avaliador

São José2017

Agradecimentos

Agradeço primeiramente a Deus, por todas as oportunidades colocadas em minhavida.

A minha família, principalmente aos meus pais, por todo apoio, compreensão einvestimento em minha vida acadêmica.

Aos meus professores, em especial meu orientador, pelo incentivo ao aprendizado,ensino de qualidade e total disponibilidade.

Aos amigos e colegas de curso, que sempre proporcionaram boa compania e discus-sões dentro e fora do campus.

“Sempre que te perguntarem se podes fazer um trabalho,respondas que sim e te ponhas em seguida a aprender como se faz”

(F. Roosevelt)

ResumoCom o crescimento do número de dispositivos conectados à rede, cada vez mais a Internetdas Coisas entra em foco. Muitas tecnologias são apontadas para a conexão desses disposi-tivos e as LPWAN (Low Power Wide Area Networks) mostram-se uma alternativa viávelpara aplicações que necessitam se comunicar a longas distâncias e com baixo consumo deenergia. Neste contexto, a tecnologia de comunicação LoRa e sua pilha de protocolos, aLoRaWAN, apresentam-se como uma alternativa promissora. Desta forma, neste trabalhosão descritos equipamentos, software e protocolos disponíveis para a implantação de umarede LoRaWAN, que foi implantada com o objetivo de estudar seu funcionamento. Juntoà rede, foi desenvolvida um sistema gerenciador de aplicações LoRaWAN, configurávelatravés de mensagens enviadas pelo servidor. Este sistema define um protocolo própriopara configuração remota dos dispositivos LoRaWAN. O sistema mostrou-se promissor,sendo capaz de gerenciar até 52 aplicações simultâneas.

Palavras-chaves: internet das coisas, LoRaWAN, sistemas embarcados.

AbstractThe growing number of devices connected to the Internet-of-Things (IoT) brings severaltechnologies into focus. Many technologies are deployed to connect these devices to theIoT, and the LPWAN (Low Power Wide Area Networks) seems to be a viable option toapplications which need to communicate over long distances at low energy consumption.Within this context, the LoRa communication technology and its protocol stack, theLoRaWAN, feature as a promising option. In order to study the LoRaWAN, this workdescribes equipment, software and protocols available for the network, and deploys aLoRaWAN network. Also, a configurable LoRaWAN application system was developed,allowing users to remotely configure the applications running in the LoRaWAN devices bysending configuration messages from a server using a protocol develop for this end. Thesystem showed to be useful during the IoT application development process and was ableto support up to 52 simultaneous applications.

Key-words: internet-of-things, LoRaWAN, embedded systems.

Lista de ilustrações

Figura 1 – Uma taxonomia para aplicações de redes de sensores sem-fio (MOT-TOLA; PICCO, 2011). . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Figura 2 – Arquitetura LoRaWAN. . . . . . . . . . . . . . . . . . . . . . . . . . . 24Figura 3 – Arquitetura da rede LoRaWAN. . . . . . . . . . . . . . . . . . . . . . . 24Figura 4 – Janelas de recepção do dispositivo classe A. . . . . . . . . . . . . . . . 25Figura 5 – Janelas de transmissão de dispositivos classe B. . . . . . . . . . . . . . 26Figura 6 – Estrutura do uplink da camada física. . . . . . . . . . . . . . . . . . . . 27Figura 7 – Estrutura do downlink da camada física. . . . . . . . . . . . . . . . . . 27Figura 8 – Formato dos elementos da mensagem LoRa. . . . . . . . . . . . . . . . 27Figura 9 – Estrutura do MACPayload. . . . . . . . . . . . . . . . . . . . . . . . . 28Figura 10 – Estrutura do FHDR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Figura 11 – Estrutura do DevAddr. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Figura 12 – Estrutura do FCtrl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Figura 13 – Operação de perda de beacon. . . . . . . . . . . . . . . . . . . . . . . . 32Figura 14 – Comportamento das janelas de recepção de dispositivos de classe C. . . 32Figura 15 – Arquitetura de rede comum para projetos LoRaWAN. . . . . . . . . . . 33Figura 16 – Layout do módulo RHF0M301 e conexões com a Raspberry Pi B+. . . 38Figura 17 – Estrutura de uma string JSON. . . . . . . . . . . . . . . . . . . . . . . 40Figura 18 – Estrutura de um numeral JSON. . . . . . . . . . . . . . . . . . . . . . 41Figura 19 – Estrutura de um array JSON. . . . . . . . . . . . . . . . . . . . . . . . 41Figura 20 – Estrutura de um objeto JSON. . . . . . . . . . . . . . . . . . . . . . . 41Figura 21 – Diagrama de sequência de upstream. . . . . . . . . . . . . . . . . . . . 42Figura 22 – Primeiro diagrama de sequência de downstream. . . . . . . . . . . . . . 43Figura 23 – Segundo diagrama de sequência de downstream. . . . . . . . . . . . . . 43Figura 24 – Interface web do LoRa App Server com as aplicações cadastradas. . . . 48Figura 25 – Interface web do LoRa App Server com nós cadastrados em uma aplicação. 49Figura 26 – Interface web do LoRa App Server com os detalhes de um nó cadastrado. 50Figura 27 – Estrutura da mensagem de controle do protocolo de configuração. . . . 51Figura 28 – Diagrama de classe do sistema de gerenciamento de aplicações Lo-

RaWAN configuráveis. . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Figura 29 – Diagrama de sequência do funcionamento do ciclo de transmissão do

sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Figura 30 – Código-fonte em C++ da declaração dos métodos parametrizados com

templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Figura 31 – Código-fonte em C++ com a implementações de métodos paramtrizados

com templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Figura 32 – Código-fonte em C++ para configuração da LMIC no Arduino. . . . . 59Figura 33 – Código-fonte em C++ do tratamento de envio-recepção da máquina de

estados da LMIC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Lista de tabelas

Tabela 1 – Tipos de mensagens MAC . . . . . . . . . . . . . . . . . . . . . . . . . 28Tabela 2 – Conexão do módulo Modtronix inAir9B ao Arduino Mega. . . . . . . . 36Tabela 3 – Conexão do módulo HopeRF RFM95W ao Arduino Mega. . . . . . . . 36Tabela 4 – Conexões do módulo Modtronix inAir9B com a RaspberryPi B+. . . . 37Tabela 5 – Conexões do módulo HopeRF RFM95W com a RaspberryPi B+. . . . 38Tabela 6 – Estrutura da mensagem PUSH_DATA. . . . . . . . . . . . . . . . . . 44Tabela 7 – Estrutura da mensagem PUSH_ACK. . . . . . . . . . . . . . . . . . . 44Tabela 8 – Atributos do objeto com pacote LoRa contidos no vetor rxpk. . . . . . 44Tabela 9 – Atributos do objeto stat. . . . . . . . . . . . . . . . . . . . . . . . . . . 45Tabela 10 – Estrutura da mensagem PULL_DATA. . . . . . . . . . . . . . . . . . 45Tabela 11 – Estrutura da mensagem PULL_ACK. . . . . . . . . . . . . . . . . . . 45Tabela 12 – Estrutura da mensagem PULL_RESP. . . . . . . . . . . . . . . . . . . 46Tabela 13 – Atributos do objeto txpk. . . . . . . . . . . . . . . . . . . . . . . . . . 46Tabela 14 – Estrutura da mensagem TX_ACK. . . . . . . . . . . . . . . . . . . . . 46Tabela 15 – Atributos do objeto txpk_ack. . . . . . . . . . . . . . . . . . . . . . . 47Tabela 16 – Possíveis valores para o campo error. . . . . . . . . . . . . . . . . . . . 47Tabela 17 – Possíveis valores do campo Type. . . . . . . . . . . . . . . . . . . . . . 52Tabela 18 – Possíveis valores para o campo Channel e Ch_Param. . . . . . . . . . 53Tabela 19 – Possíveis configurações para a UART. . . . . . . . . . . . . . . . . . . 53Tabela 20 – Possíveis dispositivos SPI. . . . . . . . . . . . . . . . . . . . . . . . . . 53Tabela 21 – Possíveis dispositivos I2C . . . . . . . . . . . . . . . . . . . . . . . . . 54Tabela 22 – Possíveis dispositivos de interface genérica (GDI). . . . . . . . . . . . . 54Tabela 23 – Possíveis métodos de aquisição de dados. . . . . . . . . . . . . . . . . . 54Tabela 24 – Eventos gerados pela biblioteca LMIC. . . . . . . . . . . . . . . . . . . 55

Sumário

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . 192.1 Internet das Coisas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2 LPWAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.1 LoRaTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3 LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3.1 Mensagens da camada física . . . . . . . . . . . . . . . . . . . . . . . . . 262.3.2 Mensagens da camada de enlace . . . . . . . . . . . . . . . . . . . . . . . 272.3.3 Ativação na rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.3.4 Aquisição e monitoramento do beacon . . . . . . . . . . . . . . . . . . . . 312.3.5 Janelas de transmissão na classe C . . . . . . . . . . . . . . . . . . . . . . 322.4 Topologia da rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3 IMPLANTAÇÃO DE REDE LORAWAN . . . . . . . . . . . . . . . . 353.1 Equipamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.1.1 Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.1.2 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.1.3 Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2 Serviços na rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.1 O formato JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2.2 UDP Packet Forwarder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2.3 LoRaServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.2.4 Servidor de Aplicação LoRa . . . . . . . . . . . . . . . . . . . . . . . . . 48

4 SISTEMA GERENCIADOR DE APLICAÇÕES LORAWAN CONFI-GURÁVEIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.1 Protocolo de configuração . . . . . . . . . . . . . . . . . . . . . . . . 514.2 Aplicação no endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.2.1 LMIC: LoRaMAC-In-C . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.2.2 Estrutura da aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.3 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

17

1 Introdução

A Internet das Coisas (IoT) é um tema recorrente de pesquisa. Existe atualmenteum crescente número de dispositivos conectados à rede, algo que abre possibilidade paranovas aplicações. Pode-se encontrar aplicações para esses dispositivos que demandam altaou baixa taxa de transmissão, grande ou pequena cobertura, ou a necessidade de haverpouca manutenção, para ambientes com difícil acesso, por exemplo. Existe uma série detecnologias bem difundidas que podem cobrir essas demandas.

As possíveis soluções para tais demandas mais difundidas são o GSM e o IEEE802.15.4. Uma das vantagens do GSM é sua ampla rede já instalada cobrindo a maior partedo território nacional e mundial. Porém, essas redes trabalham em faixas de frequêncialicenciadas alocadas a empresas privadas, o que dificulta e encarece as aplicações. Outralimitação é uma baixa eficiência energética comparada a tecnologias concorrentes. Já oIEEE 802.15.4 possui uma eficiência energética melhor, comparado ao GSM, e trabalhaem uma faixa não licenciada. Sua maior limitação é o alcance, fazendo necessário o usonós retransmissores para cobrir áreas com distâncias maiores que quilômetros.

Uma nova categoria de tecnologias sendo explorada se chama LPWAN (Low PowerWide Area Network). Ela inclui tecnologias sem fio de baixo consumo de energia elongo alcance. Suas maiores limitações são as taxas de transmissão, que usualmente nãoultrapassam a casa dos 100 kbps. São especialmente projetadas para conectar dispositivosque enviam pequenas quantidades de dados com um longo alcance e com necessidade deter uma bateria com longa duração, como redes de sensores, por exemplo (LINK LAB’S,2016).

Na categoria de LPWAN duas tecnologias destacam-se: Sigfox e LoRa. A Sigfox éuma tecnologia proprietária, de camada física até rede, que atualmente provê cobertura emboa parte da Europa e está em estado de implantação em países da América do Sul, comoBrasil e Argentina (COLLET, 2016). Utiliza um modelo de negócio onde o usuário compraum end-point e paga uma mensalidade por uma quantidade de tráfego por end-point.Suas mensagens não devem exceder 12 bytes de payload, disponibilizando, no melhorde seus planos, 140 mensagens por dia (NOLAN; GUIBENE; KELLY, 2016). Devido aestas limitações, a tecnologia promete alcance de até 50 km, o maior dentre as principaistecnologias LPWAN. Outra probemática encontrada no Sigfox é a falta de informaçãosobre a sua camada física e códigos-fonte livres que implementam o funcionamento da redepara dispositivos e servidores.

Já a LoRa, que é uma derivação da tecnologia de espalhamento espectral (CSS –Chirp Spread Spectrum), é propriedade da Semtech e compreende somente a camada física.

18 Capítulo 1. Introdução

Por isso, existe a possibilidade do desenvolvimento de diversas pilhas de protocolos queutilizam a tecnologia LoRa. Dentre essas redes já desenvolvidas, a que mais se destaca éa LoRaWAN, regida pela LoRa Alliance, associação de empresas responsáveis pela suapadronização.

A LoRaWAN caracteriza-se por ser uma pilha de protocolos aberta, logo, é possívelencontrar diversas implementaçõs livres do seu funcionamento, bem como a implementaçãodeles com dispositivos de baixo custo disponíveis no mercado. Apresenta uma topologia derede em estrela (típico das LPWAN) onde nós (end-points) conectam-se com um ou maisgateways, que por sua vez estão conectados a um Netserver responsável pelo tratamentodas mensagens recebidas. A rede promete taxa adaptativa de 0,3 a 50 kbps e distâncias deaté 40 km com linha de visada e um alcance de 3 a 5 quilômetros em ambientes urbanos(PETAJAJARVI et al., 2015).

Devido ao fato de somente a camada física LoRa ser patenteada e fechada, possuindouma rede aberta e com boa documentação, o estudos de redes LoRaWAN tornam-seeconomicamente mais viáveis que em redes Sigfox, onde é necessário o pagamento delicensas por dispositivos e a cobertura de gateways Sigfox na região de estudo. Dessaforma, esse trabalho tem como objetivo um estudo sobre o funcionamento do LoRaWAN, aimplantação de uma rede, o desenvolvimento de um sistema de gerenciamento de aplicaçõesLoRaWAN configuráveis para a realização de testes e verificar seu funcionamento.

1.1 ObjetivosO objetivo geral deste trabalho é implantar uma rede LoRaWAN e desenvolver

aplicações para a mesma, permitindo a verificação de seu funcionamento. Para atingir esteobjetivo, os seguintes objetivos foram definidos:

• Estudar e compreender o funcionamento de uma rede LoRaWAN;

• Adquirir, montar e configurar end-points LoRaWAN;

• Adquirir, montar e configurar um gateway LoRaWAN;

• Instalar e configurar um Netserver LoRaWAN;

• Conceber e prototipar um sistema para gerenciamento de aplicações LoRaWAN;

• Implantar aplicações na rede LoRaWAN e verificar seu funcionamento.

19

2 Fundamentação Teórica

Este capítulo servirá como base teórica para a avaliação de redes LoRaWAN. Nele,são levantadas informações sobre Internet das coisas (IoT), uma das principais aplicaçõesdas redes LoRaWAN. Será abordado brevemente o funcionamento básico que as LPWANsapresentam e as características básicas da tecnologia LoRa. Por fim, um estudo maisaprofundado sobre a pilha de protocolo LoRaWAN, os elementos das suas mensagens esuas funcionalidades.

2.1 Internet das CoisasNo início da década de 90 começaram as primeiras ideias de uma Internet ubíqua.

Segundo Weiser (1991), “elementos de hardware e software, conectados por cabos, ondasde rádio e infravermelho, serão tão ubíquos que ninguém perceberá sua presença”. Nos diasatuais, fica nítido a presença de tais tecnologias no cotidiano: edifícios com sensores paraeconomizar energia, aplicações em domótica, smartphones com sensores de passos, medicinaremota (STANKOVIC, 2014), monitoramento de qualidade de ar, controle de tráfego,controle de iluminação (ZANELLA et al., 2014). Segundo Stankovic (2014), teremos ummomento de transição com a sofisticação das tecnologias, onde ocorrerá uma mudançatanto em densidade de dispositivos quanto em área de cobertura. “Neste momento, o graude cobertura deve triplicar ou quadruplicar em relação ao que temos hoje. [...] Assimteremos uma mudança qualitativa no modo de trabalhar e viver”.

Atualmente, uma das grandes aplicações para Internet das Coisas (IoT), se não aque mais se sobressai, são as Redes de Sensores Sem Fio (RSSF). São sistemas distribuí-dos geralmente compostos de dispositivos embarcados, equipados com uma unidade deprocessamento, uma interface de comunicação sem fio e sensores. Os cenários apresentadospara tais redes comumente requerem que esses dispositivos consumam pouca bateria egerem pouco tráfego de dados, tornando os dispositivos baratos e de fácil interação com omundo de forma ubíqua (MOTTOLA; PICCO, 2011).

O conceito de IoT não define um padrão ou tecnologia específico para conectar osdispositivos à rede. Existem opções bem estabelecidas para realizar este papel. Entretanto,são inúmeras as aplicações para RSSF e muitas continuam a surgir, o que torna impossívelgeneralizá-las em um único grupo. Desta forma, Mottola e Picco (2011) propuseramuma taxonomia para aplicações de RSSF, dividindo-as em categorias baseadas em seusrequisitos e propósito. Essa taxonomia pode ser visualizada na Figura 1. Assim, pode-seatribuir a melhor solução tecnológica para cada uma dessas combinações apresentadas nataxonomia de forma que facilite o desenvolvimento de uma nova aplicação.

20 Capítulo 2. Fundamentação Teórica

Figura 1 – Uma taxonomia para aplicações de redes de sensores sem-fio (MOTTOLA;PICCO, 2011).

Fonte: Hoeller e Fröhlich (2010).

Centenaro et al. (2015) encaixa alguns padrões de comunicação para IoT nascategorias enumeradas abaixo:

1. Sistemas alcance extremamente curto, e.g., NFC;

2. Sistemas passivos e ativos de curto alcance, e.g., RFID;

3. Sistemas baseados no padrão IEEE 802.15.4 como ZigBee, 6LoWPAN;

4. Sistemas baseados em Bluetooth, incluindo o Bluetooth Low Energy (BLE);

5. Sistemas proprietários como Z-Wave, CSRMesh;

6. Sistemas baseados no IEEE 802.11, principalmente o Wi-Fi;

Neste contexto de tecnologias, surge como nova categoria para comunicações delongo alcance, com principal uso aplicações para IoT, as LPWANs.

2.2 LPWANUma categoria de tecnologias emergentes para redes de baixa potência é a LPWAN

(Low Power Wide Area Network). Projetadas para trabalharem em redes M2M (Machineto Machine), “conectando dispositivos que necessitam enviar uma pequena quantidadede dados por uma longa distância, sendo capazes de manter uma bateria por um longoperíodo” (LINK LAB’S, 2016).

2.2. LPWAN 21

Atualmente, uma das principais características das LPWANs é a operação embandas não licenciadas, principalmente nas bandas ISM em 2,4 GHz, 868/915 MHz, 433MHz e 169 MHz. Suas camadas físicas são projetadas para terem alta sensibilidade noreceptor, em torno de -130 dBm, quando comparada a outras tecnologias sem fio, queficam em torno de -90 dBm até -110 dBm. Esta sensibilidade só é possível ser alcançadautilizando taxas de modulações mais lentas, aumentando a quantidade de energia porsímbolo. Em contrapartida, baixas taxas de modulação implicam em baixas taxas detransmissão, fazendo com que não ultrapassem 100 kbps de modo geral. Combinando umaalta sensibilidade com a utilização de frequências abaixo da casa dos GHz, as LPWANssão capazes de atingir distâncias de até 10 km em áreas urbanas e 30 km ou mais em áreasrurais, caso haja linha de visada (CENTENARO et al., 2015; LINK LAB’S, 2016). Estastaxas pequenas e longas distâncias assemelham-se em muito à aplicações e serviços paraIoT, com “[...] transmissões intermitentes e esporádicas de pequenos pacotes de dados,tolerantes a atrasos, perda de pacotes[...]” (CENTENARO et al., 2015).

Devido às grandes distâncias alcançadas, a topologia de rede das LPWAN consisteem redes estrela, onde cada nó se comunica com a estação base (gateway) diretamente,sem a necessidade de comunicação entre nós (multi-hop). A topologia estrela é simplesde implementar e reduz a quantidade de tráfego na rede. Por exemplo, para qualquercomunicação entre 2 nós, somente 3 dispositivos (2 nós e 1 gateway) e 2 enlaces (nó1-gateway e gateway-nó2) são envolvidos. No caso das LPWAN, a maioria das trocasde mensagens seguem o fluxo nó-gateway-servidor, contendo apenas um enlace sem fio(geralmente a comunicação entre gateways e servidores utiliza uma outra tecnologia derede, principalmente redes IP). Desta forma, os nós são isolados uns dos outros, facilitandoa reposição desses nós. A centralização da rede também facilita a inspeção do tráfego darede em um único ponto. A grande desvantagem desse tipo de rede é o ponto único de falhalocalizado no gateway, que pode desabilitar uma rede inteira caso haja algum problemanele (SEMTECH, 2015). Este problema, contudo, pode ser facilmente contornado com ouso de gateways redundantes.

Segundo Petajajarvi et al. (2016) “o uso do enlace de comunicação é muito assimé-trico entre conexões uplink e downlink. O uplink é mais utilizado para transmitir dadosmedidos, enquanto o downlink é usado praticamente para confirmações (ACK) na maioriadas aplicações”. Assim é perceptível que o tráfego uplink é maior tanto em quantidade demensagens quanto em conteúdo carregado. Mensagens downlink ainda podem ser utilizadaspara enviar comandos de configurações do servidor para a rede em alguns casos.

Esta forma de topologia das LPWAN assemelha-se com as redes celulares tradicio-nais. Isto simplifica em muito a cobertura de grandes áreas, inclusive de nações inteiras,devido à possibilidade de reutilização da infraestrutura celular atual (torres, por exemplo)para implantação de gateways LPWAN (CENTENARO et al., 2015). O que também


auxilia na cobertura é o grande alcance dos enlaces das LPWAN, algo que diminui aquantidade de gateways para cobrir uma determinada área.

2.2.1 LoRaTM

LoRa é uma tecnologia, de propriedade da Semtech, de espalhamento espectralderivado da modulação CSS (Chirp Spread Spectrum), otimizada para aplicações delongo alcance, baixo consumo de energia e baixa taxa de transmissão. Utilizando estatecnologia, se faz possível a troca de taxa de transmissão por sensibilidade nos receptores,utilizando uma mesma largura de banda por canal, utilizando os três parâmetros chaveda modulação (explicado mais abaixo). Ela implementa taxa de transmissão variávelutilizando fatores de espalhamento ortogonais, fazendo possível projetar troca de taxapor alcance ou potência, otimizando a performance da redes, considerando uma largurade banda constante (SEMTECH, 2015). Atualmente, o circuito integrado produzido pelaSemtech está sendo projetado para funcionar nas frequências 169 MHz, 433 MHz e 915MHz nos Estados Unidos e 868 MHz na Europa (VANGELISTA; ZANELLA; ZORZI,2015).

O manual da Semtech sobre a modulação da LoRa (SEMTECH, 2015) cita algunsfatores chave de sua modulação:

1. Largura de banda escalável: Modulação LoRa é escalável em largura de bandae frequência, sendo possível utilizar em aplicações de frequency hopping1 de bandaestreita e sequência direta de banda larga com apenas alguns ajustes de configuraçãonos dispositivos.

2. Encapsulamento e consumo de energia constante: Os mesmos estágios deamplificação de potência de pouco consumo e alta eficiência podem ser re-utilizadossem modificação. Ainda, devido ao ganho de processamento associado ao LoRa, apotência de saída do transmissor pode ser reduzida, comparado ao FSK.

3. Alta robustez: Seletividade out-of-channel de 90 dB e rejeição co-canal melhorque 20 dB podem ser conseguidas, comparados a 50 dB e -6 dB, respectivamente,obtidos com o FSK. Isto se dá devido ao alto produto largura de banda e tempo (>1) e a natureza assíncrona do sinal LoRa.

4. Resistência a multipercurso e desvanecimento: Ideal para uso urbano e sub-urbano devido à característica banda larga do pulso LoRa, fazendo com que sejaimune a multipercurso e desvanecimento.

1 Técnica de espalhamento espectral consistindo na mudança da portadora utilizando uma sequênciapseudoaleatória conhecida pelo transmissor e receptor.

2.3. LoRaWAN 23

5. Resistência a efeito Doppler: Efeito Doppler causa um pequeno desvio de frequên-cia no pulso LoRa que introduz um desvio desprezível no eixo do tempo do sinal debanda base. Isto mitiga o requisito de fontes de clock com alta precisão.

6. Capacidade de longo alcance: Com potência de saída e vazão fixas, o cálculo deenlace do LoRa excede o do FSK. Quando levado em consideração com mecanismosde robustez à interferência e desvanecimento, isto pode facilmente ser traduzido emuma melhoria no alcance de quatro vezes ou mais.

7. Capacidade de rede melhorada: A modulação LoRa aplica fatores de espalha-mentos ortogonais que permite múltiplos sinais espalhados serem transmitidos aomesmo tempo e no mesmo canal com uma mínima degradação da sensibilidade doreceptor. Os sinais com fatores de espalhamento diferentes aparecem como ruído noreceptor alvo e podem ser tratados como tal.

A modulação pode ser especificada por três parametros: a largura de banda (BW),geralmente 125 kHz ou 250 kHz (podendo ser de 500 kHz também), o fator de espalhamento(FP), que vai de 7 a 12, e o parâmetro CR, que vai de 0 a 4 e determina a taxa do códigocorretor de erro, sendo Codigo = 4

4+CR. Assim a taxa efetiva de dados com carga útil

infinita é dada por:Rb = FP

Codigo2F P

BW

[b/s]

Considerando o preâmbulo de cada pacote que permite sincronização de frequência etempo no receptor, as taxas de transmissão variam de 0.3 kb/s até 11 kb/s, com largura debanda de 250 kHz e levando em consideração um único canal (VANGELISTA; ZANELLA;ZORZI, 2015). Este valor acaba não sendo o real, pois os gateways LoRa são capazes derealizar um processamento paralelo para cada fator de espalhamento, podendo aumentaresta taxa.

Segundo Semtech (2015) “LoRa é uma implementação de camada física e é agnósticadas implementações de camadas de nível mais alto. Isto permite que a LoRa coexista eopere com arquiteturas de rede existentes”. Desta forma, é possível existir uma gama depilhas de protocolos que funcionem com a tecnologia LoRa, uma das características quefazem com que esta seja umas das tecnologias LPWAN com mais destaque. A pilha deprotocolos LoRa mais difundida atualmente é a LoRaWAN.

2.3 LoRaWANLoRaWAN é uma arquitetura de rede aberta, cuja arquitetura pode ser vista na

Figura 2. Suas regras são regidas pela LoRa Alliance, grupo formado por diversas empresasdo ramo como IBM, Actility, Semtech e Microchip. Normalmente utilizado em topologias


de rede do tipo estrela. Utiliza um modelo com duty cycle, ou seja, os dispositivos passammais tempo em modo de espera do que transmitindo. Possui três tipos de dispositivos, osNós (end-devices, motes), conectados por um link de único salto a um ou mais gatewaysque por sua vez possuem conexão, via rede IP, a um Netserver conforme a Figura 3(LORA-ALLIANCE, 2016).

Figura 2 – Arquitetura LoRaWAN.

Fonte: Centenaro et al. (2015)

Figura 3 – Arquitetura da rede LoRaWAN.

Fonte: Centenaro et al. (2015)

Os gateways chaveiam a troca de mensagens entre os nós e o Netserver. Os nós nãonecessitam assossiar-se com um gateway para ter acesso à rede (sendo os gateways transpa-

2.3. LoRaWAN 25

rentes aos nós), mas sim a um Netserver. O gateway atua somente como um encaminhadorde mensagens decodificadas corretamente a um Netserver associado, adicionando algumasinformações extra, como relação sinal-ruído, RSSI, etc. Com estas assossiações, o Netserveré capaz de filtrar mensagens duplicadas, quando por exemplo, um nó é visto por mais deum gateway. Os gateways também possuem a capacidade de realizar um processamentoparalelo de até nove canais. Cada nó utiliza um canal combinado com um espalhamentoespectral (CENTENARO et al., 2015).

Esta configuração move toda a complexidade dos nós para o Netserver, proporcio-nando a criação de dispositivos simples. Segundo Centenaro et al. (2015) “os nós podemse mover livremente por células servidas por gateways diferentes sem gerar tráfego desinalização extra. Por fim, percebemos que o aumento do número de gateways que servemum certo nó aumentará a confiabilidade da sua conexão com o Netserver, que pode serútil para algumas aplicações críticas”.

Os nós LoRaWAN podem implementar três classes de operação: Classe A, B e C.Todos devem implementar a classe A, e dispositivos que implementam mais de uma classesão chamados de “higher Class end-devices” (LORA-ALLIANCE, 2016).

• Nós classe A: Dispositivos classe A permitem transmissões bidirecionais, onde cadatransmissão uplink é seguida de duas curtas janelas de recepção. A transmissão ébaseada nas necessidades de comunicação do dispositivo com uma pequena variaçãobaseada em um tempo aleatório (protocolo do tipo ALOHA). Esta classe consomea menor quantidade de bateria para aplicações que só necessitam de transmissõesdownlink logo após que o dispositivo faz uma transmissão uplink (e.g. ACK). Umexemplo de comunicação de um dispositivo classe A pode ser vista na Figura 4.

Figura 4 – Janelas de recepção do dispositivo classe A.

Fonte: LoRa-Alliance (2016)

• Nós classe B: Dispositivos classe B possuem uma janela de recepção extra, emrelação a classe A, tempos fixos, baseadas em uma sincronização com o gateway.Todos os gateways são sincronizados e enviam beacons periódicos para manter a


célula sincronizada (protocolo do tipo ALOHA-slotted). Após receber um beacon,o dispositivo abre uma janela extra, chamada de ping-slot. A principal ideia destaclasse é ter o dispositivo disponível para uma recepção em um instante previsível.Um exemplo de comunicação de um dispositivo classe B pode ser vista na Figura 5.

Figura 5 – Janelas de transmissão de dispositivos classe B.


• Nós classe C: Dispositivos classe C possuem praticamente uma janela de recepçãoaberta, estando fechada somente quando está transmitindo. Essa classe de operaçãoé indicada para dispositivos conectados diretamente à rede elétrica devido seu altoconsumo de energia e para aplicações que necessitam uma menor latência no downlink.Dispositivos classe C não podem implementar a classe B. Mais detalhes sobre asjanelas de transmissão da classe C podem ser vistos em subseção 2.3.5.

Todas as terminologias e formatos das mensagens a seguir são utilizados em todasas classes de dispositivos, a não ser quando explicitamente indicados.

2.3.1 Mensagens da camada física

As mensagens LoRa seguem esta terminologia:

• Uplink: Mensagens enviadas pelos nós ao Netserver, chaveadas por um ou maisgateways. Estas mensagens utilizam um cabeçalho da camada física do LoRa (PHDR)mais um CRC deste cabeçalho (PHDR_CRC). O payload é protegido por outroCRC. Todos estes campos são inseridos pelo transceiver conforme a Figura 6.

• Downlink: Mensagens enviadas pelo Netserver para somente um nó e chaveadapor um único gateway. Estas mensagens utilizam um cabeçalho da camada física doLoRa (PHDR) mais um CRC deste cabeçalho (PDHR_CRC) conforme a Figura 7.

2.3. LoRaWAN 27

Figura 6 – Estrutura do uplink da camada física.


Figura 7 – Estrutura do downlink da camada física.


Para cada transmissão uplink, o dispositivo abre duas pequenas janelas de recepção(RX1 e RX2). Os temporizadores de início da janela de recepção possuem um períodoconfigurado e inciam suas contagens no final da transmissão do último bit de uplink,conforme a Figura 4. As janelas RX1 e RX2 ainda podem receber configurações de canaldiferentes entre si, como frequência central e espalhamento espectral.

2.3.2 Mensagens da camada de enlace

Todas as mensagens LoRa carregam um payload da camada física, que começacom um octeto de cabeçalho MAC (MHDR), seguido pelo payload MAC (MACPayload) eterminando com um código de integridade da mensagem (MIC) com quatro octetos detamanho. A Figura 8 mostra todos os elementos da mensagem LoRa.

Figura 8 – Formato dos elementos da mensagem LoRa.


O MHDR especifica o tipo da mensagem (MType) e a versão principal (Major) do


LoRaWAN do frame. O LoRaWAN especifica seis tipos de mensagens MAC. A Tabela 1relaciona o valor do MType com o tipo de mensagem correspondente. Mensagens comconfirmação necessitam de um ACK pelo receptor enquanto mensagens sem confirmaçãonão necessitam de um ACK. Mensagens proprietárias podem ser implementadas fora doformato padrão, não sendo compatíveis com mensagens LoRaWAN, havendo comunicaçãosomente com dispositivos específicos.

MType Descrição000 Join Request001 Join Accept010 Dado Uplink Sem Confirmação011 Dado Downlink Sem Confirmação100 Dado Uplink Com Confirmação101 Dado Downlink Com Confirmação110 Reservado para uso futuro111 Formato Proprietário

Tabela 1 – Tipos de mensagens MAC

O MACPayload, ou “quadro de dados”, contém o cabeçalho do quadro (FHDR),seguido pela porta (FPort) e pelo payload do quadro (FRMPayload). Os tamanhos doselementos do MACPayload são descritos na Figura 9.

Figura 9 – Estrutura do MACPayload.


Na Figura 9, o tamanho máximo do payload (N) varia baseado na região específicade atuação conforme LoRa-Alliance (2016, Sessão 7) e deve seguir a seguinte regra:

N ≤ M − 1 − (FHDR_em_octetos)

onde M é o tamanho máximo do payload do MAC.

O FHDR contém o endereço curto do dispositivo (DevAddr), um octeto de controlede quadro (FCtrl), um contador de quadros de dois octetos (FCnt) e um campo de até 15octetos usado para transportar comandos MAC (FOpts), mostrados na Figura 10.

• DevAddr: Endereço de 32 bits separados em dois campos: Identificador de rede(NwkID), que é utilizado para evitar endereços iguais em redes próximas no caso de

2.3. LoRaWAN 29

Figura 10 – Estrutura do FHDR.


Figura 11 – Estrutura do DevAddr.


roaming, e o Endereço de rede (NwkAddr) do nó, que pode ser atribuído arbitraria-mente, como na Figura 11.

• FCtrl: O quadro de controle possui cinco campos, conforme a Figura 12.

Figura 12 – Estrutura do FCtrl.


– ADR (Adaptative Data Rate): Campo responsável por ativar o controle adap-tativo de taxa de transmissão do LoRa.

– ADRACKReq: Bit responsável por validar se o ADR está funcionando nor-malmente caso a taxa otimizada pelo ADR seja maior que a taxa padrão dodispositivo. O dispositivo conta um certo número de mensagens não respondidaspelo servidor até um limite, e então configura o ADRACKReq para 1.

– ACK: Resposta ao ADRACKReq.

– FPending: Somente usado no downlink, indica que o gateway possui mais dadosprontos para serem transmitidos para que o dispositivo abra mais uma janelade transmissão o mais rápido possível.


– FOptsLen: Indica o tamanho do FOpts. Se for 0, indica que não há o campoFOpts. Se for diferente de 0, ou seja, existem comandos MAC no FOpts, FPortdeve ser ausente ou diferente de 0, pois a porta 0 não pode ser utilizada.

– RFU: Reservado para uso futuro. Utilizado no classe B para indicar que odispositivo está com a classe B ativa.

• Fcnt: Cada nó possui dois contadores: um para uplink (FCntUp), incrementadopelo dispositivo e um para downlink (FCntDown), incrementado pelo Netserver.O Netserver usa o FCntUp para gerar o próximo FCntDown. Os contadores sãoreiniciados para 0 após um Join Accept.

• FOpts: Transmite comandos MAC com tamanho máximo de quinze octetos acopla-dos (piggyback) no frame de dados. Comandos MAC não podem estar presentes nocampo payload e no campo de opções simultaneamente.

O FPort define uma porta para a aplicação. Desta forma, é possível executardiversas aplicações em um único nó e ser capaz de diferenciá-las. Se o campo FRMPayloadnão é vazio, isto indica que o campo FPort deve estar presente. Se presente, o valor 0 noFPort indica que o FRMPayload contém somente comandos MAC. FPort com valores de1 até 233 (0x01 até 0xDF) estão disponíveis para as aplicações. Valores de 223 até 255(0xE0 até 0xFF) são reservados para extensão de aplicações padrões futuras.

As mensagens LoRaWAN passam por uma criptografias AES com chaves de tama-nho de 128 bits conforme algoritmo descrito no IEEE. . . (2016, Anexo B). A criptografiaé utilizada no MACPayload antes do cálculo do MIC caso o quadro carregue um payload.Esta é a criptografia de rede que utiliza a chave de sessão de rede (NwkSKey). Cadadispositivo possui sua própria NwkSkey. Já o FRMPayload é criptografado com a chave desessão de aplicação (AppSKey). As duas chaves utilizadas ao mesmo tempo impossibilitaque o provedor da rede acesse os dados da aplicação. Dessa forma, a NwkSkey é obrigatória,enquanto a AppSKey é facultativa à aplicação.

2.3.3 Ativação na rede

Existem duas formas de um dispositivo (nó) participar de uma rede: ativação peloar (OTAA) e ativação personalizada (ABP). Na ativação pelo ar o dispositivo realizaum procedimento de entrada na rede sempre que perder informações sobre o contextoda sessão. Este procedimento requer um identificador único (DevEUI) no formato IEEEEUI64, um identificador de aplicação (AppEUI) no formato IEEE EUI64 e uma chaveAES-128 (AppKey) que irá derivar-se nas chaves NwkSKey e AppSKey. O procedimentoconsiste em duas mensagens MAC:

2.3. LoRaWAN 31

• Join-request: Gerada pelo dispositivo. Contém o AppEUI, o DevEUI e um valoraleatório de dois bytes (DevNonce). O Netserver mantém os últimos DevNonce decada dispositivo afim de ignorar requisições repetidas com os mesmos valores. Estemecanismo previne ataques de repetição com intenção de desconectar o dispositivoda rede. Esta mensagem não é criptografada.

• Join-accept: Gerada pelo gateway. Contém um valor aleatório de três bytes (App-Nonce), um identificador de rede (NetID), um endereço de dispositivo (DevAddr),um atraso entre TX e RX (RxDelay), o DLsettings e uma lista opcional de canais(CFList). O AppNonce é utilizado somente na derivação do AppKey em NwkSKey eAppSKey. O NetID é usado na derivação das chaves de sessão e se divide da seguintemaneira: os sete bits menos significativos são iguais ao endereço curto do dispositivo eos outros são arbitrariamente escolhidos. O DLsetting contém 1 byte e é responsávelpela configuração do downlink. O RxDelay configura o atraso entre o fim de umatransmissão de uplink e o início de uma nova abertura de recepção. O CFList é umalista de frequências utilizadas pelo gateway e varia com a região.

Na ativação personalizada não há procedimento de requisição. O DevAddr,NwkSKey e AppSkey são armazenados previamente no dispositivo ao invés do DevEUI,AppEUI e AppKey. Cada dispositivo deve ter uma combinação única de NwkSkey eAppSKey para não comprometer a segurança do sistema. Nesta forma de ativação, odispositivo está pronto para participar da rede assim que iniciado.

2.3.4 Aquisição e monitoramento do beacon

Antes de trocar de modo de funcionamento de classe A para classe B, o dispositivodeve receber pelo menos um beacon da rede para alinhar sua referência temporal internacom a da rede. Uma vez na rede, o dispositivo deve receber periodicamente um beaconpara realizar um ajuste no seu clock interno. Uma vez sem receber um beacon, o dispositivopode manter sua operação em classe B por até duas horas. Para garantir a recepção sem oajuste de sincronismo, o dispositivo aumenta o tempo de recepção com intenção de alargaro tamanho da janela para acomodar o desvio de tempo entre o dispositivo e a rede. Estaoperação pode ser vista na Figura 13. A recepção de qualquer beacon estende a duraçãoda operação por mais duas horas.

Todo beacon é composto de um preâmbulo um pouco maior que o padrão (dezsímbolos não modulados) e um campo de payload que varia conforme a região de operação.Este payload contém, entre outras informações, o período do beacon, que pode variar de 1a 4294967295 segundos. Todos os beacons não possuem cabeçalho e CRC atribuídos pelacamada física do LoRa. Informações específicas sobre o funcionamento da classe B podemser encontradas em LoRa-Alliance (2016, Class B - Beacon).


Figura 13 – Operação de perda de beacon.


2.3.5 Janelas de transmissão na classe C

Dispositivos classe C estão sempre com a janela de recepção 2 aberta a não ser queesteja transmitindo ou recebendo na janela 1. Não existe nenhuma mensagem específicapara identificar que um dispositivo esteja operando em classe C. Isto deve ser passadocomo informação no procedimento de entrada na rede. O comportamento das janelas naclasse C é mostrado na Figura 14.

Figura 14 – Comportamento das janelas de recepção de dispositivos de classe C.


2.4 Topologia da redeA organização eficiente de grandes volumes de mensagens pequenas, como o gerado

por aplicações da IoT, é tema de vários trabalhos em andamento. Há plataformas, tantolivres quanto pagas, para a implementação destas aplicações. No caso de Netserverspara LoRaWAN, o mesmo se repete. Pode-se citar o próprio Netserver pago da Semtech,

2.4. Topologia da rede 33

projetos já implementados para uso público, com interface web para configurações, e algunsprojetos livres disponíveis em repositórios públicos na rede. A arquitetura majoritariamenteutilizada em projetos LoRaWAN pode ser vista na Figura 15.

Figura 15 – Arquitetura de rede comum para projetos LoRaWAN.


Para o funcionamento de uma aplicação em uma rede LoRaWAN, os seguintespassos devem acontecer:

1. A rede LoRaWAN deve estar funcionando, ou seja, os endpoints devem ser capazes decomunicar-se com ao menos 1 gateway e esse gateway deve ser capaz de comunicar-secom o Netserver ;

2. O endpoint transmite periodicamente uma ou mais informações em suas respectivasportas, cada porta representando uma aplicação;

3. Após passar pelo gateway e Netserver, o servidor de aplicação recebe as mensagense pode agrupá-las da forma que for desejado: por dispositivo, utilizando o DevEUI,ou por proprietário do dispositivo, utilizando o AppEUI. O modo de agrupamentopode variar de acordo com as intenções do proprietário da rede e dos dispositivos;

4. Após isso, esses grupos de mensagens podem ser divididos pela porta utilizada pelodispositivo, que representa de qual aplicação é a informação contida na mensagem;

5. Finalmente, os dados podem ser tratados e distribuídos aos usuários interessados.

35

3 Implantação de rede LoRaWAN

Antes de realizar qualquer tipo de teste com a tecnologia LoRa, foi necessário im-plantar uma rede LoRaWAN. Foram pesquisados diversos equipamentos como transceiversLoRa e gateways, máquinas para hospedar serviços e softwares para servidores de rede(Netserver) e aplicações. Tais opções foram avaliadas e escolhidas com base em custo,facilidade para montagem do cenário e utilização geral pela comunidade. Neste capítulo éapresentado o desenvolvimento e a implantação da rede LoRaWAN utilizada nos testes,desde a escolha e aquisição do hardware até a escolha dos softwares.

3.1 EquipamentosNesta sessão são apresentados todos os equipamentos utilizados na montagem da

rede LoRaWAN utilizada no projeto: endpoints, gateways e servidores.

3.1.1 Endpoints

Para a construção dos endpoints, baseando-se na alta disseminação e a existênciade uma base de código-fonte disponível em comunidades de software livre e fóruns sobreLoRaWAN, a plataforma Arduino Uno foi escolhida. Após alguns testes com o código dosistema de gerenciamento de aplicações LoRaWAN configuráveis, resolveu-se por utilizaroutra versão da plataforma, a Arduino Mega, devido à sua maior disponibilidade dememória, pois o sistema ocupava incialmente aproximadamente 50% da memória dinâmica(1030 bytes). Como o sistema aloca muitas variáveis que escalam de tamanho baseado nonúmero de aplicações configuradas, preferiu-se utilizar uma plataforma com mais memória.É importante ressaltar que futuras versões podem ser otimizadas para a utilização deplacas ArduinoUno.

Após uma busca nos fornecedores de soluções LoRa, dois modelos de interfacesLoRa para testes foram encontrados:

• RFM95W: Módulo da HopeRF, integra o transceiver SX1276 da Semtech e front-end RF para faixa de 915MHz, formando um módulo de 16x16 mm com terminaçãode 50Ω para conexão de antena e interfaces digitais para integração com o processadorde aplicação (HOPERF, 2014). O módulo possui até -148dBm de sensibilidade e,devido a um PA de +14 dBm, +20 dBm de potência de saída RF, gerando um linkbudget de 168dB. Sua pequena dimensão facilita a integração a novos projetos dehardware. Para integração com o Arduino, foi necessária a aquisição de uma placaadaptadora.

36 Capítulo 3. Implantação de rede LoRaWAN

• inAir9B: Módulo da Modtronix que também integra o transceiver SX1276 daSemtech e front-end RF para faixa de 915MHz, porém implementam um módulo demaior dimensão (27,3x24,51mm) (MODTRONIX, 2014). Assim como o RFM95W,o inAir9B também possui terminação de 50Ω para conexão de antena e interfacesdigitais para integração com o Arduino. Possui -139 dBm de sensibilidade e até +20dBm de potência de saída RF, com cálculo de enlace de 159 dB. Estes módulospermitem fácil integração para prototipagem rápida, não necessitando adaptaçõesou placas extra. As características de sensibilidade e potência são as mesmas doRFM95W.

As conexões dos módulos ao Arduino se dão pela ligação de sinais de sinalizaçãodigital, uma interface serial SPI, alimentação de 3,3 V e o terra, como apresentado nasTabela 2 e Tabela 3.

Tabela 2 – Conexão do módulo Modtronix inAir9B ao Arduino Mega.

inAir9B Arduino MegaD0 2D1 3D2 4CS 10S0 50S1 51CK 523V3 3V0V GND

Tabela 3 – Conexão do módulo HopeRF RFM95W ao Arduino Mega.

RFM95W Arduino MegaMISO 50MOSI 51SCK 52NSS 10RES 9DIO0 2DIO1 3DIO2 43.3V 3VGND GND

3.1. Equipamentos 37

3.1.2 Gateway

O hardware do gateway é um pouco mais complexo e caro que os endpoints, jáque um gateway deve ser capaz de processar até 9 canais paralelamente. Este hardwareé disponibilizado pela Semtech apenas para integradores de soluções LoRa. Devido àdificuldade em adquirir um gateway LoRa, os primeiros testes da rede LoRaWAN usaramum protótipo de gateway operando em um único canal, que é conhecido na comunidadecomo Single Channel Gateway (TELKAMP, 2016).

Dada a boa relação custo benefício e o fato de que o software disponível para ogateway executa primariamente em sistemas Linux, a plataforma base selecionada para osgateways foi a RaspberryPi. Foram utilizadas placas do modelo RaspberryPi B+ devidoà disponibilidade. De modo similar aos endpoints, os módulos RF foram conectados àplataforma, conforme as Tabela 4 e Tabela 5. Como software foi utilizado o Single ChannelPacket Forwarder, responsável por realizar as funções de gateway, adicionando camposde informação sobre o enlace LoRa, em um dispositivo capaz de utilizar um único canalpor vez e encaminhar o pacote para um ou mais servidores. Para alterar o canal utilizadopor este gateway, é necessário recompilar o software e reiniciar o processo no sistemaoperacional. O Single Channel Gateway, devido à simplicidade, torna-se muito barato eideal para testes de enlace com redes simplificadas. Em contrapartida, funcionalidadescomo a taxa de transmissão adaptativa (ADR), mensagens de downlink, confirmações ecapacidade de multi-canais ficam impossibilitadas.

Tabela 4 – Conexões do módulo Modtronix inAir9B com a RaspberryPi B+.

inAir9B RaspberryPiD0 7 (GPIO 4)RT 11 (GPIO 17)CS 24 (GPIO 8)0V 25 (GND)SI 19 (GPIO 10)SO 21 (GPIO 9)CK 23 (GPIO 11)3V3 17 (3.3V)

Em uma segunda etapa do trabalho, foi possível a aquisição de um gateway LoRamulticanal. O RHF0M301 da RisingHF (RISINGHF, 2015) é um módulo gateway LoRacom 10 canais (8 multicanais com espalhamento espectral, 1 canal LoRa padrão e 1canal FSK). Com dimensão de 15x8x5 cm, possui um processador multicanal SX1301 daSemtech e front-end SX1255/7 da Semtech TX e RX. O gateway ainda vem com 24 pinospara interface digital com o controlador principal e terminação de 50Ω para conexão deantena com potência máxima de saída de 27 dBm e sensibilidade de até -141,5 dBm. Olayout do módulo e suas conexões com a Raspberry podem ser vistos na Figura 16. O


Tabela 5 – Conexões do módulo HopeRF RFM95W com a RaspberryPi B+.

RFM95W RaspberryPiMISO 21 (GPIO 9)MOSI 19 (GPIO 10)SCK 23 (GPIO 11)NSS 22 (GPIO 25)RES 11 (GPIO 17)GND 6 (GND)DIO0 7 (GPIO 4)3V3 1 (3V3)

gateway vem acompanhado de um guia para instalação rápida em plataformas RaspberryPi. Seguindo o guia, foram utilizados os softwares da própria Semtech: lora_gatewaye packet_forwarder. O software lora_gateway é o responsável por realizar testes paraverificar se há alguma irregularidade nas conexões eletrônicas do módulo com a plataforma.O software packet_forwarder adiciona as informações sobre o enlace LoRa e encaminha opacote para um ou mais servidores utilizando o protocolo UDP Packet Forwarder, maisdetalhado na subseção 3.2.2. Nele que configuramos quais canais serão utilizados pelogateway. Durante a utilização da rede, o gateway apresentou um problema no softwareembarcado, parando de encaminhar pacotes após aproximadamente 3 dias funcionandoininterruptamente. Como este software não foi desenvolvido neste trabalho, optou-se pornão investigar a origem deste problema e por reiniciar o gateway periodicamente.

Figura 16 – Layout do módulo RHF0M301 e conexões com a Raspberry Pi B+.

Fonte: RisingHF (2015)

3.2. Serviços na rede 39

3.1.3 Servidor

Ao longo do projeto foram utilizados alguns modelos diferentes de Netserver. Umadas primeiras alternativas foi a utilização dos servidores da TTN (The Things Network),empresa que investe na tecnologia atualmente. Desta forma, o gateway envia os pacotesaos servidores da TTN e este cuida de todo o processo de Netserver. Utilizando umainterface web, são feitos os processos de registro de sessão, para o caso de autenticaçãopersonalizada, e de manipulação das informações adquiridas.

Visando ter maior controle sobre os processos servidores de rede e aplicação, optou-se por instalar estes servidores localmente em uma máquina virtual Ubuntu dentro darede interna do IFSC (OpenStack). Nesta máquina foi configurado um broker do protocolopacket_forwarder chamado LoRa Gateway Bridge (BROCAAR, 2017b). Este brokerfunciona como uma ponte de comunicação entre o gateway e o Netserver, extraindo osobjetos no formato JSON (ver subseção 3.2.1) destas mensagens e publicando-os comotópicos MQTT1, disponibilizando estas mensagens aos servidores de rede e aplicação eoutros serviços que se registrarem para recebê-las. Utilizando o Node-Red, ferramentavisual desenvolvida em node.js para tratar fluxos de dados, as mensagens MQTT sãolidas e registradas. Este protótipo de servidor não atendia às especificações LoRaWANe servia apenas para adquirir os dados recebidos. Entre os problemas deste protótipodestaca-se a dificuldade em decodificar o payload LoRa, sendo que, durante esta etapa,somente eram visíveis as informações sobre o enlace LoRa geradas pelo gateway.

Devido a problemas de instabilidade e ao desligamento da rede OpenStack previstapara o fim do ano de 2016, o Netserver foi migrado para outra rede. Desta forma, optou-sepor uma máquina virtual Ubuntu na rede de serviços AWS da Amazon, disponibilizadapela empresa Teltec Solutions. Simultaneamente, foram estudados projetos de Netservergratuitos para substituir o atual protótipo de servidor. Assim, foi optado por utilizar oLoraServer, projeto gratuito de código aberto de um Netserver para redes LoRaWAN.Este projeto foi testado ainda no servidor dentro do IFSC, testando suas configuraçõese atualizações que aconteciam com o tempo e finalmente implantado com a migraçãopara o servidor na Amazon. Informações mais detalhadas do LoraServer são encontradasna subseção 3.2.3. Junto com o LoraServer, é disponibilizado um servidor de aplicaçãocompatível, que é visto em mais detalhes na subseção 3.2.4.

3.2 Serviços na rede

Nesta sessão, encontram-se os principais serviços e softwares utilizados na redeLoRaWAN implantada.

1 O Message Queuing Telemetry Transport


3.2.1 O formato JSON

JSON (JavaScript Object Notation) (BRAY, 2014) é um formato para troca dedados na forma de texto UNICODE que independe da linguagem utilizada. Uma mensagemJSON pode ser constituída com os seguintes valores (ECMA, 2013):

• String: Caracteres entre aspas duplas, salvo exceções vistas na Figura 17;

• Numeral: Numerais seguindo o formato mostrado na Figura 18;

• Array: Coleção de valores ordenados, iniciado com [, separados por , e terminadocom ], conforme Figura 19. Representa na maioria das linguagens vetores e listas;

• Objeto: Conjunto desordenado de pares com um nome (string) e um valor respectivo.Assemelha-se a estruturas encontradas em diversas linguagens como struct, object,dicionário, etc. É iniciado com , terminado com , nome e valor são separadospor : e pares separados por ,, conforme Figura 20;

• Uma das 3 palavras reservadas: null, true ou false.

Figura 17 – Estrutura de uma string JSON.

Fonte: ECMA (2013)


Figura 18 – Estrutura de um numeral JSON.

Fonte: ECMA (2013)

Figura 19 – Estrutura de um array JSON.

Fonte: ECMA (2013)

Figura 20 – Estrutura de um objeto JSON.

Fonte: ECMA (2013)

3.2.2 UDP Packet Forwarder

O UDP Packet Forwarder2, especificado pela Semtech, é um protocolo de encami-nhamento de mensagens entre gateway LoRa e Netserver, utilizando datagramas UDP

2 Todo o conteúdo desta sessão é baseado na documentação oficial da Semtech, encontrada emhttps://github.com/Lora-net/packet_forwarder, e na experiência adquirida na utilização desteprotocolo.


como transporte das mensagens. Não há autenticação entre gateway e Netserver e asmensagens de confirmação são utilizadas apenas para avaliação da qualidade da rede. Destaforma, esse protocolo não exige recursos avançados encontrados no TCP, por exemplo,diminuindo o tráfego entre gateway e Netserver. Por sua simplicidade é indicado que oprotocolo seja utilizado somente para demonstrações ou em redes privadas e confiáveis. Oprotocolo é dividido em dois fluxos:

• Upstream: Pacotes de rádio recebidos pelo gateway, meta-dados adicionados pelogateway e encaminhamento para o Netserver. Essas mensagens podem tambémconter o estado do gateway. O fluxo upstream é representado com um diagrama desequência na Figura 21.

Figura 21 – Diagrama de sequência de upstream.

• Downstream: Pacotes gerados pelo Netserver, com meta-dados inclusos, a seremtransmitidos pelo gateway em um canal de rádio. Essas mensagens podem tam-bém conter informações de configuração para o gateway. O fluxo downstream érepresentado com dois diagramas de sequência na Figura 22 e Figura 23.

No upstream, o gateway encaminha ao Netserver os pacotes recebidos dos endpointsjunto de meta-dados do pacote. Esta mensagem é chamada de PUSH_DATA, e suaestrutura é apresentada na Tabela 6. Ao receber esta mensagem, o Netserver respondecom uma mensagem de reconhecimento, a PUSH_ACK, cuja estrutura está na Tabela 7.O objeto JSON raíz contido na PUSH_DATA pode conter um vetor chamado rxpk ou umvetor stat, podendo conter os dois tipos simultaneamente.


Figura 22 – Primeiro diagrama de sequência de downstream.

Figura 23 – Segundo diagrama de sequência de downstream.

O vetor rxpk contém ao menos um novo objeto JSON com o pacote LoRa e seusmetadados. Os campos destes objetos podem ser vistos na Tabela 8. O objeto stat contéminformações estatísticas do gateway e é descrito na Tabela 9. Estes pacotes com objetosstat são enviados periodicamente, sendo que as suas informações são incrementais, ouseja, os contadores que geram estes dados são zerados no gateway após cada reinício, e asinformações refletem as operações realizadas pelo gateway a partir da última vez em queele foi iniciado.

No downstream, existem duas sequências de mensagens. A primeira acontece a cadatempo fixo de segundos (configurado no gateway), onde o gateway envia uma mensagemde keepalive para o Netserver, chamada PULL_DATA, respondido pelo Netserver por


Tabela 6 – Estrutura da mensagem PUSH_DATA.

Bytes Função0 Versão do protocolo (padrão: 2)1-2 Token aleatório3 Identificador do PUSH_DATA (0x00)

4-11 Identificador único do gateway (endereço MAC)12-final Objeto JSON com informações do pacote

Tabela 7 – Estrutura da mensagem PUSH_ACK.

Bytes Função0 Versão do protocolo (padrão: 2)1-2 Mesmo token gerado para o PUSH_DATA equivalente3 Identificador do PUSH_ACK (0x01)

Tabela 8 – Atributos do objeto com pacote LoRa contidos no vetor rxpk.

Atributo Tipo Descriçãotime string Instante do envio da mensagem no formato ISO 8601 compactotmst número Timestamp do recebimento do pacote no gateway (32b unsigned)freq número Frequência central do canal MHz (float, precisão em Hz)chan número Canal IF usado pelo RX (unsigned integer)rfch número “RF chain” usado pelo RX (unsigned integer)stat número Status do CRC: 1 = OK, -1 = falha, 0 = sem CRCmodu string Identificador de modulação “LORA” ou “FSK”dart string Identificador de taxa de dados LoRa (SF e BW)datr número Taxa de dados FSK (unsigned, em bits por segundo)codr string Identificador de taxa de código LoRA em fraçãorssi número RSSI em dBm (signed integer, precisão de 1 dB)lsnr número SNR LoRa em dB (signed float, precisão de 0,1 dB)size número Tamanho do pacote RF em bytes (unsigned integer)data string Payload PHY do pacote RF criptografado e codificado em Base64

uma mensagem chamada PULL_ACK. Esta troca inicial de mensagens se dá pelo fato deser impossível ao servidor enviar pacotes para o gateway se o gateway estiver atrás de umNAT ou firewall. Quando o gateway inicia a negociação, a rota até o Netserver é aberta epermitirá um fluxo de pacotes em ambas as direções. Assim, o gateway deve periodicamenteenviar pacotes PULL_DATA para garantir que a rota na rede permaneça aberta parao servidor utilizá-la a qualquer momento. As estruturas das mensagens PULL_DATA ePULL_ACK podem ser vistas na Tabela 10 e Tabela 11, respectivamente.

A segunda sequência de mensagens acontece após um PULL_ACK do Netserver.O Netserver envia pacotes de rádio e meta-dados associados que deverão ser emitidospelo gateway. Esta mensagem chama-se PULL_RESP e sua estrutura é representada


Tabela 9 – Atributos do objeto stat.

Atributo Tipo Descriçãotime string Instante do envio da mensagem no formato ISO 8601 compactolati número Latitude do gateway em graus (float, N +)long número Longitude do gateway em graus (float, E +)alti número Altitude do gateway em metros (integer)rxnb número Pacotes RF recebidos (unsigned integer)rxok número Pacotes RF recebidos com CRC PHY válido (unsigned integer)rxfw número Pacotes RF encaminhados (unsigned integer)ackr número % de datagramas de uplink confirmados (unsigned integer)dwnb número Datagramas de downlink recebidos (unsigned integer)txnb número Pacotes emitidos (unsigned integer)

Tabela 10 – Estrutura da mensagem PULL_DATA.

Bytes Função0 Versão do protocolo (padrão: 2)1-2 Token aleatório3 Identificados do PULL_DATA (0x02)

4-11 Identificador único do gateway (endereço MAC)

Tabela 11 – Estrutura da mensagem PULL_ACK.

Bytes Função0 Versão do protocolo (padrão: 2)1-2 Mesmo token gerado pelo PULL_DATA equivalente3 Identificador do PULL_ACK (0x04)

pela Tabela 12. O objeto JSON raíz contido na PULL_RESP deve conter um objetochamado txpk, que contém o pacote de rádio e seus meta-dados associados. Os camposdesse objeto podem ser vistos na Tabela 13. Em contrapartida, o gateway responde comuma mensagem chamada TX_ACK., cuja estrutura pode ser vista na Tabela 14. Estamensagem é utilizada para o gateway informar o Netserver se a requisição de downlink foiaceita ou rejeitada pelo gateway. O datagrama pode opcionalmente conter um objeto JSONchamado txpk_ack, com mais detalhes da requisição em um campo chamado error. Aestrutura do objeto txpk_ack e a lista de possíveis valores do campo error são apresentadasna Tabela 15 e Tabela 16, respectivamente.

3.2.3 LoRaServer

O LoRa Server (BROCAAR, 2017c) é um Netserver LoRaWAN de código abertoescrito principalmente na linguagem Go. Faz parte de um projeto maior que é constituídode um broker do protocolo packet forwarder para MQTT (LoRa Gateway Bridge), do


Tabela 12 – Estrutura da mensagem PULL_RESP.

Bytes Função0 Versão do protocolo (padrão: 2)1-2 Token aleatório3 Identificador do PULL_RESP (0x03)

4-final Objeto JSON com informações do pacote

Tabela 13 – Atributos do objeto txpk.

Nome Tipo Descriçãoimme booleano Envia o pacote imediatamente (ignorará tmst e time)tmst número Envia o pacote em um certo valor de timestamp (ignorará time)time string Envia o pacote em um certo tempo (necessita sincronização)freq número Frequência central TX em MHz (unsigned float, precisão em Hz)rfch número "RF chain"do gateway usada para TX (unsigned integer)powe número Potência de saída TX em dBm (unsigned integer)modu string Identificador da modulação "LORA"ou "FSK"datr string Identificador da taxa de dados LoRa (SF e BW)datr número Taxa de dados FSK (unsigned, em bits por segundo)codr string Identificador de taxa de código LoRA em fraçãofdev número Desvio de frequência FSK (unsgned integer, em Hz)ipol booleano Inversão de polarização da modulação LoRaprea número Tamanho do preâmbulo RF (unsigned integer)size número Tamanho do payload do pacote RF em bytes (unsigned integer)data string Payload PHY do pacote RF criptografado e codificado em Base64ncrc booleano Se verdadeiro, desabilita o CRC da camada física (opcional)

Tabela 14 – Estrutura da mensagem TX_ACK.

Bytes Função0 Versão do protocolo (padrão: 2)1-2 Mesmo token gerado pelo PULL_RESP equivalente3 Identificador do TX_ACK (0x05)

4-11 Identificador único do gateway (endereço MAC)12-final Objeto JSON com informações do pacote (opcional)

LoRa Server propriamente dito e um servidor de aplicação compatível. A comunicaçãoentre o LoRa Server e o servidor de aplicação deve ser feita via RPC (Remote ProcedureCall) (THURLOW, 2009), utilizando a implementação gRPC. É responsável por tratar asmensagens de uplink recebidas pelos gateways e escalonamento das transmissões down-link. Atualmente é um projeto em desenvolvimento, logo não possui suporte a todos osmecanismos descritos pela especificação do LoRaWAN. O LoRa Server possui suporteintegral para dispositivos classe A. Mensagens duplicadas são tratadas e encaminhadaspara o servidor de aplicação. Ao ocorrer uma janela de recepção, o servidor elege uma


Tabela 15 – Atributos do objeto txpk_ack.

Nome Tipo Descriçãoerror string Indicação sobre o sucesso ou tipo de falha na requisição de downlink

Tabela 16 – Possíveis valores para o campo error.

Valor DefiniçãoNenhum Pacote foi escalonado para o downlinkTOO_LATE Rejeitado: tarde demais para programar o envioTOO_EARLY Rejeitado: cedo demais para programar o envioCOLLISION_PACKET Rejeitado: instante solicitado está ocupado por um pacoteCOLLISION_BEACON Rejeitado: instante solicitado está ocupado por um beaconTX_FREQ Rejeitado: frequência requisitada não é suportadaTX_POWER Rejeitado: potência requisitada não é suportadaGPS_UNLOCKED Rejeitado: GPS não está disponível para sincronizar relógio

mensagem de downlink do servidor de aplicação, avaliando se a mensagem se adequa emalguma taxa de transmissão disponível baseando-se no tamanho do payload da mensagem.Os mecanismos disponíveis no LoRa Server são:

• Mensagens com confirmação: Ambas mensagens downlink e uplink são tratadaspelo LoRa Server. No caso de mensagens de downlink com confirmação, o LoRaServer mantém a mensagem enfileirada até receber a confirmação do endpoint.

• Ativação do endpoint: Ambos métodos de ativação (Ativação personalizada eAtivação pelo ar) são suportados. No caso de ABP, o servidor de aplicação entregaao LoRa Server as informações da sessão. No caso de OTAA, o LoRa Server chamao servidor de aplicação com a mensagem join-request e, no caso de resposta positiva,transmite a mensagem join-accept ao endpoint.

• ADR (Taxa de transmissão adaptativa): O LoRa server atualmente possui su-porte para ADR somente na banda EU 863-870. Por isso e por ter sido implementadoapós o início dos testes, essa função não foi testada e utilizada no projeto. Para ativaro ADR, devem estar configurados no endpoint o intervalo ADR, número de framespara recalcular a taxa de transmissão, e a potência de transmissão do endpoint. Parainiciar o ADR, as transmissões uplink devem conter a flag ADR ativa.

• Janelas de recepção: Em ambos modos de ativação é possível configurar qualjanela de transmissão será utilizada nas transmissões downlink. Isso inclui parâmetroscomo taxa de transmissão (para a janela 2) e o atraso.


• Bandas ISM3: Ao iniciar o LoRa Server, deve estar configurado qual banda ISMserá utilizada. Atualmente o Loraserver suporta faixas de países situados na Eu-ropa, sudeste asiático, Estados Unidos, Coréia do Sul, Rússia e China, seguindo aespecificação da LoRaWAN.

3.2.4 Servidor de Aplicação LoRa

O LoRa App Server (BROCAAR, 2017a) é um servidor de aplicação LoRa, compa-tível com o LoRa Server, de código aberto e escrito principalmente nas linguagens Go eJavascript. É responsável por cuidar de todos os registros dos endpoints cadastrados narede e suas sessões, tratamento de mensagens das aplicações recebidas e enfileiramentode mensagens de downlink. Possui uma interface web, mostrada nas figuras Figura 24,Figura 25 e Figura 26, para administrar todos os endpoints e suas configurações, podendoutilizar JWT (JSON Web Tokens) (JONES; BRADLEY; SAKIMURA, 2015) como métodode autenticação. Por fim, ainda possui uma API gRPC e RESTful (FIELDING, 2000)para integração com aplicações.

Figura 24 – Interface web do LoRa App Server com as aplicações cadastradas.

Fonte: (BROCAAR, 2017a)

Todas as mensagens de uplink são publicadas em tópicos MQTT depois de seremdescriptografadas. As mensagens de downlink podem ser enfileiradas publicando em um3 Bandas reservadas internacionalmente para o desenvolvimento industrial, científico e médico.


Figura 25 – Interface web do LoRa App Server com nós cadastrados em uma aplicação.


tópico MQTT respectivo ou utilizando a API. Além dessas mensagens, o LoRa App Serverainda pode publicar eventos em tópicos MQTT, como uma ativação de um endpoint, umamensagem confirmada por um endpoint ou um erro, como, por exemplo, um payload dedownlink que excedeu o tamanho máximo permitido.


Figura 26 – Interface web do LoRa App Server com os detalhes de um nó cadastrado.


51

4 Sistema gerenciador de aplicações Lo-RaWAN configuráveis

Neste capítulo são tratados todos os tópicos do desenvolvimento do sistema gerenci-ador de aplicações LoRaWAN configuráveis. Este sistema tem o propósito de utilizar todosos recursos (portas analógicas, digitais, serial, entre outras) da plataforma utilizada parao endpoint (ArduinoUno, Raspberry Pi ou uma placa personalizada), podendo ser confi-gurada e atualizada por mensagens de controle enviadas pelo Netserver. Como proposta,esta aplicação deve ser capaz de:

• Receber mensagens downlink com as configurações de seu funcionamento, interpretá-las e configurar o software do endpoint de acordo com o conteúdo recebido;

• Trabalhar com múltiplas aplicações simultâneas, ou seja, lendo valores de diferentesentradas com diferentes portas, períodos, etc;

• Ser facilmente adaptável para plataformas diferentes;

• Facilitar a criação de aplicações LoRaWAN, expondo os seus principais parâmetrosde configuração.

4.1 Protocolo de configuraçãoPara ser possível a configuração remota das aplicações no endpoint, foi necessário

criar um protocolo de configuração que carregue as informações básicas necessárias parauma aplicação LoRa. Este protocolo foi projetado pensando nos recursos que uma placaArduinoUno possui, entretanto, diversos campos foram reservados para possíveis adaptações.Em sua primeira versão, o protocolo de configuração possui apenas uma mensagem,chamada de mensagem de controle. Essa mensagem de controle é um pacote downlinkLoRaWAN que utiliza a porta 1 como padrão e seu conteúdo no payload deste pacote. Aestrutura da mensagem de controle pode ser vista na Figura 27. Seus campos são:

Figura 27 – Estrutura da mensagem de controle do protocolo de configuração.

52 Capítulo 4. Sistema gerenciador de aplicações LoRaWAN configuráveis

• nApps: Número de aplicações a serem configuradas. Devido ao tamanho máximode uma mensagem de downlink LoRaWAN, este valor não deve ultrapassar o valor 8e deve sempre ser maior que 0.

• Applications: Parâmetros utilizados para configurar as aplicações:

– FPort: Define qual porta LoRaWAN será utilizada na transmissão. Este valornão pode ser 0 (porta para comandos MAC) e 1 (porta para mensagens decontrole deste protocolo);

– Type: Define o tipo do valor que a aplicação irá transportar, listados naTabela 17;

– Channel: Define o canal de informação no qual o endpoint retirará os dados.As opções válidas podem ser vistas na Tabela 18;

– CH_Param: Parâmetro de configuração do canal definido anteriormente.

– Acquisition: Define o método de aquisição dos dados. Opções válidas podemser vistas na Tabela 23;

– Ack: Define se a aplicação deve enviar mensagens com confirmação ou não.Valor 0 para mensagens não confirmadas e 1 para mensagens confirmadas;

– Period: Define a periodicidade das mensagens, em segundos. Este valor estásujeito a desvios de poucos segundos devido ao tempo de processamento.

Tabela 17 – Possíveis valores do campo Type.

Type Valor Nota0 int Inteiro de 16 bits1 string Sequência de caracteres2 boolean Verdadeiro (1) ou Falso (0)3 float Ponto flutuante de 32 bits4-7 RFU Reservado para uso futuro

Os dispositivos inseridos nas tabelas de configurações foram escolhidos com basena disponibilidade de sensores e equipamentos no campus para testes.

4.2 Aplicação no endpointO sistema desenvolvido para os endpoints foi codificado em C++ e utiliza alguns

recursos disponibilizados pela biblioteca do Arduino, como a leitura de suas portas, porexemplo. Toda a parte que se refere ao funcionamento do protocolo LoRaWAN é feita pelabiblioteca LMIC (LoRa Mac-In-C).

4.2. Aplicação no endpoint 53

Tabela 18 – Possíveis valores para o campo Channel e Ch_Param.

Channel Valor Ch_Param0 Digital Número do pino1 Analógico Canal analógico2 Interrupção Número da interrupção3 UART Baudrate (veja Tabela 19)4 SPI Configuração SPI (veja Tabela 20)5 I2C Configuração I2C (veja Tabela 21)6 GDI1 Configuração GDI (veja Tabela 22)7-F RFU Reservado para uso futuro

Tabela 19 – Possíveis configurações para a UART.

Ch_Param Configuração0 300 8N11 600 8N12 1200 8N13 2400 8N14 4800 8N15 9600 8N16 14400 8N17 19200 8N18 28800 8N19 38400 8N1A 57600 8N1B 115200 8N1C-F RFU

Tabela 20 – Possíveis dispositivos SPI.

Ch_Param Dispositivo Tipo0 SCP1000 Sensor de pressão1 BME280 Multisensor Adafruit2 DS3234 Relógio de tempo real3 DS1306 Relógio de tempo real4-F RFU Reservado para uso futuro

4.2.1 LMIC: LoRaMAC-In-C

A LMIC é uma biblioteca incialmente criada pela IBM, posteriormente abandonadapela empresa e disponibilizada em um repositório público. Atualmente ela é mantida pelacomunidade de software livre. Esta biblioteca possui suporte para OTAA (ativação peloar) e ABP (ativação personalizada), bandas europeia (868 MHz) e americana (915 MHz).Trata os eventos de recepção e transmissão com uma máquina de estados e utiliza de umafila temporizada interna para escalonar os envios.


Tabela 21 – Possíveis dispositivos I2C

Ch_Param Dispositivo Tipo0 MPU-6050 Acelerômetro e giroscópio1 GY-302 Sensor de luminescência baseado no BH1750FVI2 DS1307 Relógio de tempo real3-F RFU Reservado para uso futuro

Tabela 22 – Possíveis dispositivos de interface genérica (GDI).

Ch_Param Dispositivo Tipo0 DHT-11 Sensor de temperatura e humidade1 DHT22 Sensor de temperatura e humidade (AM2303)2 DS18B20 Sensor de temperatura digital (1 fio)3-F RFU Reservado para uso futuro

Tabela 23 – Possíveis métodos de aquisição de dados.

Acquisition Método Nota

0 Único Única aquisição1 Média Valor médio de ’x’ aquisições2 RMS Valor RMS de ’x’ aquisições3-F RFU Reservado para uso futuro

O tratamento dos eventos gerados pela máquina de estados da LMIC não é im-plementado pela biblioteca, mas sim, por quem estiver utilizando a máquina. Os eventosgerados por ela são apresentados na Tabela 24.

No sistema no endpoint, a fila de envios foi o único componente utilizado dabiblioteca LMIC. Toda a parte de ativação e seleção de banda deve ser feita em uma outraetapa do software que estiver utilizando o sistema. Para agendar eventos, a LMIC recebeuma função callback de envio (contendo uma transmissão de rádio LoRa) juntamente comum valor de tempo. Esta callback é enfileirada ordenadamente segundo o valor de tempo eum timer é configurado. Assim que um tempo se esgotar, o sistema liga uma interrupção,desenfileira a função callback e a executa.

4.2.2 Estrutura da aplicação

A estrutura da aplicação pode ser vista na Figura 28. Ela consiste em duas classesprincipais, Application e Plataform.

A classe Application é a representação de uma aplicação contendo atributoscomo canal de dados da plataforma a ser utilizado, periodicidade de aquisição, portautilizada, mensagens com confirmação, etc. Esta classe fica invisível ao usuário do sistema,sendo utilizada somente pela classe Plataform. Ao ser criado um objeto desta classe, sua

4.2. Aplicação no endpoint 55

Tabela 24 – Eventos gerados pela biblioteca LMIC.

Evento DescriçãoEV_JOINING Nó começou o processo de entrada na redeEV_JOINED Nó entrou na rede com sucessoEV_JOIN_FAILED Nó não pode entrar na rede (após segunda tentativa)

EV_REJOIN_FAILED Nó não pode entrar em uma nova rede, mas continuaconectado na rede anterior

EV_TXCOMPLETE Dados foram transmitidos e possíveis dados dedownlink foram recebidos

EV_RXCOMPLETE Dados de downlink foram recebidosEV_SCAN_TIMEOUT Nenhum beacon foi encontrado no intervalo de beaconEV_BEACON_FOUND Primeiro beacon foi encontrado no intervalo de beacon

EV_BEACON_TRACKED Próximo beacon foi encontrado dentro do tempoesperado

EV_BEACON_MISSED Nenhum beacon foi encontrado no tempo esperado

EV_LOST_TSYNC Beacon foi perdido repetidas vezes e sincronizaçãofoi perdida

EV_RESET Sessão foi reiniciada

EV_LINK_DEAD Nenhuma confirmação foi recebida do Netserver porum longo período de tempo

Figura 28 – Diagrama de classe do sistema de gerenciamento de aplicações LoRaWANconfiguráveis.

função callback de envio é enfileirada. Quando a callback é executada, após realizar atransmissão, ela se enfileira novamente, gerando um ciclo periódico de envios, segundo aFigura 29. Como a função de envio deve ser estática, foi necessário criar um mapeamentodos objetos com o argumento da função de envio. Isto foi realizado para que a função deenvio saiba de qual instância de Application ela foi invocada e possa acessar os atributosdo objeto Application correto. Este mapeamento foi feito utilizando uma biblioteca deterceiros (MANIACBUG, 2013). Para poder realizar diferentes tipos de aquisição de dados,


são utilizadas classes parametrizadas (templates), onde a função de aquisição de dados ederivadas se adequam a cada tipo de aplicação.

A Plataform é a classe responsável por interpretar as mensagens de controle rece-bidas e criar as aplicações correspondentes. Possui apenas um único método como interfacepara sua utilização, chamado decode, que recebe uma string seguindo a especificação doprotocolo de configuração. Após invocar o método, o objeto trata de deletar possíveis apli-cações existentes, limpar toda a fila de envios da biblioteca LMIC, interpretar a mensagemde controle e criar e armazenar em uma lista as aplicações desejadas contidas na mensagem.A lista encadeada utilizada vem de uma biblioteca de terceiros (CHATZIKYRIAKIDIS,2010).

Figura 29 – Diagrama de sequência do funcionamento do ciclo de transmissão do sistema.

Uma das partes mais importantes do código encontra-se na classe Application,que é o uso de templates para generalizar os tipos de aplicações. Aplicações que extraemdados do tipo inteiro possuem formas de aquisição desses dados diferentes de aplicações queextraem strings, por exemplo. Dessa forma, métodos diferentes devem ser implementadospara cada tipo de aplicação. Entretanto, uma aplicação extrai inteiros não necessita ter osmétodos para extrair uma string. Desta forma, o uso de templates permite que somente osmétodos necessários para um determinado tipo de aplicação sejam alocados, reduzindoo uso de memória do dispositivo. Um exemplo da codificação dos templates no softwarepode visto na Figura 30 e Figura 31

Note que a única parte do código da aplicação dependente da plataforma Arduino

4.3. Testes 57

Figura 30 – Código-fonte em C++ da declaração dos métodos parametrizados com tem-plates.

template <typename T>c l a s s A p p l i c a t i o n : p u b l i c G e n e r i c A p p l i c a t i o n

p r i v a t e :. . .

T rms ( ) ;T ave rage ( ) ;T read_p in ( ) ;T acqu i r e_da ta ( ) ;

. . .

é a utilização dos métodos de aquisição de dados das portas digitais, analógias, seriais dabiblioteca do Arduino. Assim, essa é a única parte necessária adaptar caso seja desejadoutilizar o código em outras plataformas.

4.3 Testes

Os testes a seguir foram realizados visando validar as propostas do sistema degerenciamento de aplicações LoRaWAN configuráveis desenvolvida. Os testes foram inicia-dos após ser obtida uma versão minimamnete estável da aplicação e da rede LoRaWANimplantada.

Para a utilização do sistema, foram criados programas com a IDE do Arduinocontendo as configurações básicas necessárias para o funcionamento da biblioteca LMIC.Em todos os testes foi utilizado o método e ativação personalizado (ABP). As chavesde sessão utilizadas foram as chaves padrão disponibilizadas pela Semtech para testes,também utilizadas nos exemplos que a The Things Network disponibiliza. O endereço dodispositivo utilizado também foi o encontrado nos exemplos da The Things Network. Comoos dois módulos adquiridos possuem algumas diferenças, a configuração da pinagem parao uso da biblioteca é levemente diferente, uma definição foi criada para facilitar a trocados módulos nos testes. Todas essas configurações iniciais podem ser vistas na Figura 32.

A máquina de estados da biblioteca LMIC aparece no código como a funçãoonEvent, que trata os eventos como recepção, transmissão, joining, entre outros. Apósuma transmissão, o sistema verifica se existe algum dado no buffer de recepção (lembrandoque um dado só pode ser recebido após uma transmissão, utilizando as janelas de recepção).Caso exista, ele verifica se a porta 1 foi utilizada para encaminhar a mensagem recebidapara a classe Plataform interpretá-la. Este processo é mostrado na Figura 33.

Os primeiros testes verificaram a funcionalidade da classe Application sozinha.


Figura 31 – Código-fonte em C++ com a implementações de métodos paramtrizados comtemplates.

// A p l i c a c o e s de i n ttemplate <>i n t A p p l i c a t i o n <int >:: read_p in ( )

switch ( t h i s −>channe l )case 1 : // ana log

return analogRead ( t h i s −>ch_param ) ;defau l t :

return 0 ;break ;

// A p l i c a c o e s de char ∗template <>char∗ A p p l i c a t i o n <char ∗>:: read_p in ( )

switch ( t h i s −>channe l )case 3 :

i f ( t h i s −>ch_param>SERIAL_BR_SIZE−1) return NULL ;S e r i a l . end ( ) ;S e r i a l . b eg in ( s e r i a l _ b r [ t h i s −>ch_param ] ) ;i f ( S e r i a l . a v a i l a b l e () >0)

return ( char ∗ ) ( S e r i a l . r e a d S t r i n g ( ) . c_s t r ( ) ) ;break ;

defau l t :return NULL ;

// A p l i c a c o e s de boo ltemplate <>boo l A p p l i c a t i o n <bool >: : r ead_p in ( )

switch ( t h i s −>channe l )case 0 : // d i g i t a l

i f ( d i g i t a l R e a d ( t h i s −>ch_param)==HIGH) return t r u e ; e l s e return f a l s e ; break ;

defau l t :return 0 ;break ;

4.3. Testes 59

Figura 32 – Código-fonte em C++ para configuração da LMIC no Arduino.

s t a t i c const PROGMEM u1_t NWKSKEY[ 1 6 ]= 0x2B , 0x7E , 0x15 , 0x16 , 0x28 , 0xAE , 0xD2 , 0xA6 ,

0xAB , 0xF7 , 0x15 , 0x88 , 0x09 , 0xCF , 0x4F , 0x3C ;

s t a t i c const u1_t PROGMEM APPSKEY[ 1 6 ]= 0x2B , 0x7E , 0x15 , 0x16 , 0x28 , 0xAE , 0xD2 , 0xA6 ,

0xAB , 0xF7 , 0x15 , 0x88 , 0x09 , 0xCF , 0x4F , 0x3C ;

s t a t i c const u4_t DEVADDR = 0x03FF0001 ;

#i f LoRaTransce i v e r == HopeRF_Transce iverconst lmic_pinmap lm i c_p i n s =

. n s s = 10 ,

. r x t x = LMIC_UNUSED_PIN ,

. r s t = 9 ,

. d i o = 2 , 3 , LMIC_UNUSED_PIN , ;#e l i f LoRaTransce i v e r == Modt ron i x_Transce i v e rconst lmic_pinmap lm i c_p i n s =

. n s s = 10 ,

. r x t x = LMIC_UNUSED_PIN ,

. r s t = 9 ,

. d i o = 2 , 3 , 4 , ;

Figura 33 – Código-fonte em C++ do tratamento de envio-recepção da máquina de estadosda LMIC.

case EV_TXCOMPLETE:i f (LMIC . dataLen )

i f (LMIC . f rame [ LMIC . dataBeg −1] == 1) // i f f p o r t == 1p l a t −>decode ( ( char∗)&LMIC . frame [ LMIC . dataBeg ] ) ;

break ;

Dentro dos arquivos da IDE do Arduino, objetos dessa classe foram criados, sendo para-metrizados manualmente. Após validado o funcionamento isolado, foram criados objetossimultâneos, verificado e validado o funcionamento de poucas aplicações (até 5) ao mesmotempo.

Após isso, foi testada a implementação do decodificador do protocolo de configu-ração, juntamente com a criação das aplicações a partir do recebimento das mensagensde controle. Para isso, um pequeno circuito com um termistor foi adicionado ao endpointafim de criar uma aplicação para monitorar temperatura. Este dispositivo foi deixadoligado por alguns dias monitorando a temperatura de um ambiente. Durante esse tempo,diversas mensagens de configuração foram enviadas, alterando a periodicidade do envio


das mensagens, porta utilizada e aumentando o número de aplicações utilizando a mesmainformação gerada pelo termistor. Após algumas verificações do funcionamento e código,percebeu-se um problema na utilização das interrupções por causa da biblioteca LMIC.Este problema foi corrigido alterando as funções de ligar e desligar interrupções pelasutilizadas pela biblioteca LMIC.

O próximo teste teve a intenção de forçar o maior número de aplicações simultâneaspossíveis utilizando o protocolo de configuração. Os limitantes quanto ao número deaplicações simultâneas são a quantidade de memória que a plataforma dispõe, devido aconstante alocação dinâmica do sistema, e ao número de processos simultâneos, podendodescartar pacotes antes de serem transmitidos. Atualmente, como o protocolo nao prevêatualização das aplicações mas um reinício, apagando todas as aplicações existentespreviamente, o máximo de aplicações simultâneos é oito, devido ao tamanho máximo deuma mensagem downlink. Neste teste, o servidor enviou uma mensagem configurando oitoaplicações com período de 16 segundos, cada uma utilizando uma porta diferente com aintenção de identificá-las. Por serem configuradas quase que simultaneamente pelo sistemae por terem os mesmos períodos de envio, os envios foram escalonadas para instantes detempo semelhantes. Assim, houve um atraso no envio de algumas mensagens, entretanto,não houveram perdas devido ao software. Após isso, foi realizado o mesmo teste com asaplicações com período de 255 segundos e o atraso não foi detectado.

Com a tentativa de forçar o sistema, foram configuradas 222 aplicações simultâneas(fPort, seguindo a regra do protocolo de configuração, fica entre 2 e 223) na inicializaçãodo programa, sem utilizar uma mensagem de controle. Ao fazer isso, a plataforma Arduinoapresentou diversos reinícios contínuos, característicos de estouro de memória. Ao diminuiro número de aplicação, o mesmo comportamento continuou a apresentar-se, até cherga-seao número de 52 aplicações simultâneas, sem apresentar nenhum descarte de envio enenhum estou de memória.

61

Conclusão

Neste trabalho foi implementada uma rede LoRaWAN e desenvolvido um sistemagerenciador de aplicações LoRaWAN configuráveis. Para isso, foi realizado um estudo dofuncionamento do protocolo LoRaWAN, servidores de rede de código aberto e bibliotecasque implementam o protocolo nos endpoints.

A implantação da rede LoRaWAN foi realizada com êxito. Com ela foram realizadostodos os testes que envolviam a comunicação fim-a-fim entre os dispositivos e o servidor deaplicação. O sistema gerenciador de aplicações configuráveis foi desenvolvido e apresentouresultados satisfatórios, cumprindo os requisitos propostos. Ele foi capaz de recebermensagens downlink de configuração através do protocolo de configuração e interpretá-las corretamente. O sistema também suportou a existência de múltiplas configuraçõessimultâneas, ultrapassando o limite imposto inicialmente pelo protocolo de configuraçãode 8 aplicações, para até 52 (limite de memória da plataforma utilizada). Por fim, osoftware desenvolvido possui um código que pode ser facilmente portado para outrasplataformas. Uma limitação do sistema é a necessidade de, caso esteja sendo utilizadaativação personalizada e nós classe A, o nó ser iniciado com alguma aplicação enviandomensagens com o intuito de abrir janelas de recepção para que o servidor envie umamensagem de controle.

Devido aos resultados obtidos, as seguintes propostas são feitas para novos testes narede LoRaWAN e melhorias no sistema gerenciador de aplicações LoRaWAN configuráveis:

• Estender o protocolo de configuração para adicionar novas aplicações em um disposi-tivo sem remover todas as aplicações existentes;

• Criar alguma forma de abrir janelas de recepção para nós classe A utilizando ABP,possibilitando a recepção de uma mensagem de controle;

• Continuar atualizando o Netserver para as versões mais recentes e utilizar possíveisnovas funcionalidades;

• Criar um código compatível com o sistema que trate de toda a etapa da ativaçãodos dispositivos na rede, abstraindo ainda mais a biblioteca LMIC;

63

Referências

BRAY, T. The JavaScript Object Notation (JSON) Data Interchange Format.[S.l.], 2014. <http://www.rfc-editor.org/rfc/rfc7159.txt>. Disponível em: <http://www.rfc-editor.org/rfc/rfc7159.txt>. 40

BROCAAR, O. LoRa App Server. [S.l.]: GitHub, 2017. <https://github.com/brocaar/lora-app-server>. 48, 49, 50

BROCAAR, O. LoRa Gateway Bridge. [S.l.]: GitHub, 2017. <https://github.com/brocaar/lora-gateway-bridge>. 39

BROCAAR, O. LoRa Server. [S.l.]: GitHub, 2017. <https://github.com/brocaar/loraserver>. 45

CENTENARO, M. et al. Long-range communications in unlicensed bands: the risingstars in the iot and smart city scenarios. CoRR, abs/1510.00620, 2015. Disponível em:<http://arxiv.org/abs/1510.00620>. 20, 21, 24, 25

CHATZIKYRIAKIDIS, E. QueueList Library For Arduino. [S.l.]: Arduino Playground,2010. <http://playground.arduino.cc/Code/QueueList>. 56

COLLET, L. WND and SIGFOX To Extend Global Internet of ThingsNetwork to Brazil. [S.l.]: Sigfox, 2016. <http://www.sigfox.com/en/press/wnd-and-sigfox-to-extend-global-internet-of-things-network-to-brazil>. 17

ECMA. The JSON Data Interchange Format. 1st edition. ed. [S.l.], 2013. Disponível em:<http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf>. 40,41

FIELDING, R. T. Architectural Styles and the Design of Network-based SoftwareArchitectures. Tese (Doutorado) — University of California, Irvine, Estados Unidos, 2000.Disponível em: <http://www.loa.istc.cnr.it/Guizzardi/SELMAS-CR.pdf>. Acesso em: 22feb. 2017. 48

HOELLER, A. J.; FRöHLICH, A. A. Redes de sensores sem-fio sob a perspectiva doEPOS. Petrópolis, Brasil: [s.n.], 2010. Proceedings of the 11th Symposium on Computing.Disponível em: <http://www.lisha.ufsc.br/pub/Hoeller_WSCAD_2010.pdf>. Acesso em:14 jul. 2016. 20

HOPERF. RFM95/96/97/98(W) - Low Power Long Range Transceiver Module. [S.l.], 2014.V1.0. Disponível em: <http://www.hoperf.com/upload/rf/RFM95_96_97_98W.pdf>.Acesso em: 22 feb. 2017. 35

IEEE Standard for Low-Rate Wireless Networks. IEEE Std 802.15.4-2015 (Revision ofIEEE Std 802.15.4-2011), p. 1–709, abr. 2016. 30

JONES, M.; BRADLEY, J.; SAKIMURA, N. JSON Web Token (JWT). [S.l.],2015. <http://www.rfc-editor.org/rfc/rfc7519.txt>. Disponível em: <http://www.rfc-editor.org/rfc/rfc7519.txt>. 48

http://www.rfc-editor.org/rfc/rfc7159.txt



https://github.com/brocaar/lora-app-server

https://github.com/brocaar/lora-app-server

https://github.com/brocaar/lora-gateway-bridge

https://github.com/brocaar/lora-gateway-bridge

https://github.com/brocaar/loraserver

https://github.com/brocaar/loraserver

http://arxiv.org/abs/1510.00620

http://playground.arduino.cc/Code/QueueList

http://www.sigfox.com/en/press/wnd-and-sigfox-to-extend-global-internet-of-things-network-to-brazil

http://www.sigfox.com/en/press/wnd-and-sigfox-to-extend-global-internet-of-things-network-to-brazil

http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

http://www.loa.istc.cnr.it/Guizzardi/SELMAS-CR.pdf

http://www.lisha.ufsc.br/pub/Hoeller_WSCAD_2010.pdf

http://www.hoperf.com/upload/rf/RFM95_96_97_98W.pdf




64 Referências

LINK LAB’S. A Comprehensive Look At Low Power, Wide Area Networks. White Papper,2016. 17, 20, 21

LORA-ALLIANCE. LoraTMspecification. In: . [S.l.: s.n.], 2016. 24, 25, 26, 27, 28, 29, 31,32

LORA-ALLIANCE. 2017. <https://www.lora-alliance.org/>. Acessado em 23/02/2017.33

MANIACBUG. 2013. <https://maniacbug.wordpress.com/>. Acessado em 23/02/2017.55

MODTRONIX. Wireless SX1276 LoRa Module, 868MHz and 915MHz, 3.3V, SMAConnector. [S.l.], 2014. Disponível em: <http://modtronix.com/inair9.html>. Acesso em:22 feb. 2017. 36

MOTTOLA, L.; PICCO, G. P. Programming wireless sensor networks: Fundamentalconcepts and state of the art. ACM Comput. Surv., ACM, New York, NY,USA, v. 43, n. 3, p. 19:1–19:51, abr. 2011. ISSN 0360-0300. Disponível em:<http://doi.acm.org/10.1145/1922649.1922656>. 11, 19, 20

NOLAN, K. E.; GUIBENE, W.; KELLY, M. Y. An evaluation of low power widearea network technologies for the internet of things. In: 2016 International WirelessCommunications and Mobile Computing Conference (IWCMC). [S.l.: s.n.], 2016. p.439–444. 17

PETAJAJARVI, J. et al. Evaluation of lora lpwan technology for remote health andwellbeing monitoring. 2016 10th International Symposium on Medical Information andCommunication Technology (ISMICT), IEEE, Worcester, MA, USA, v. 1, n. 1, p. 1–5,mar. 2016. 21

PETAJAJARVI, J. et al. On the coverage of lpwans: range evaluation and channelattenuation model for lora technology. In: 2015 14th International Conference on ITSTelecommunications (ITST). [S.l.: s.n.], 2015. p. 55–59. 18

RISINGHF. Set up LoRaWAN GW with RHF0M301. [S.l.], 2015. V1.8. 37, 38

SEMTECH. AN120.22 LoRa Modulation Basics. [S.l.], 2015. 21, 22, 23

STANKOVIC, J. A. Research directions for the internet of things. IEEE Internet ofThings Journal, IEEE, v. 1, n. 1, p. 3–9, fev. 2014. ISSN 2327-4662. 19

TELKAMP, T. Single Channel LoRaWAN Gateway. [S.l.]: GitHub, 2016. <https://github.com/tftelkamp/single_chan_pkt_fwd>. 37

THURLOW, R. RPC: Remote Procedure Call Protocol Specification Version2. [S.l.], 2009. <http://www.rfc-editor.org/rfc/rfc5531.txt>. Disponível em:<http://www.rfc-editor.org/rfc/rfc5531.txt>. 46

VANGELISTA, L.; ZANELLA, A.; ZORZI, M. Long-range iot technologies: The dawn ofloraTM. jan. 2015. 22, 23

WEISER, M. The computer for the 21st century. SIGMOBILE Mob. Comput. Commun.Rev., ACM, New York, NY, USA, v. 3, n. 3, p. 3–11, jul. 1991. ISSN 1559-1662. Disponívelem: <http://doi.acm.org/10.1145/329124.329126>. 19

https://www.lora-alliance.org/

https://maniacbug.wordpress.com/

http://modtronix.com/inair9.html

http://doi.acm.org/10.1145/1922649.1922656

https://github.com/tftelkamp/single_chan_pkt_fwd

https://github.com/tftelkamp/single_chan_pkt_fwd



http://doi.acm.org/10.1145/329124.329126

Referências 65

ZANELLA, A. et al. Internet of things for smart cities. IEEE Internet of Things Journal,v. 1, n. 1, p. 22–32, fev. 2014. ISSN 2327-4662. 19

redes lorawan: implantação e, desenvolvimento de aplicações · 2019-03-11 · para...

Documents