Capítulo 7 — Procedimento de Join e Gerenciamento de Sessão

 

7. Introdução

Antes que um dispositivo LoRaWAN possa transmitir dados de aplicação, ele precisa ingressar na rede.
Esse processo é chamado de Join e é fundamental para:

  • Segurança

  • Geração de chaves de sessão

  • Alocação de parâmetros de rede

  • Funcionamento correto no plano AU915

7.1 Visão geral do Join (OTAA)

No método OTAA (Over-The-Air Activation), o dispositivo realiza um procedimento de autenticação com a rede.

Fluxo simplificado

End Device → Join Request → Network Server
End Device ← Join Accept ← Network Server

Após esse processo:

  • O dispositivo passa a ter uma sessão ativa

  • Chaves temporárias são geradas

  • Contadores são inicializados

✔️ Método recomendado e padrão no Brasil

7.2 Join Request

O Join Request é enviado pelo dispositivo final.

Conteúdo principal

  • JoinEUI (identifica a aplicação)

  • DevEUI (identidade única do dispositivo)

  • DevNonce (valor aleatório)

  • MIC (integridade da mensagem)

Características

  • Enviado em uplink

  • Usando canais de 125 kHz

  • Spreading Factor geralmente alto (SF10–SF12)

  • Payload pequeno

🔎 Nota AU915
Devido ao grande número de canais, a correta configuração da sub-banda é essencial para que o Join seja recebido.

7.3 Join Accept

O Join Accept é enviado pelo Network Server em resposta ao Join Request.

Conteúdo principal

  • AppNonce

  • NetID

  • DevAddr

  • Parâmetros regionais

  • CFList (lista de canais)

Características

  • Enviado em downlink

  • Usa canais de 500 kHz

  • Criptografado com a AppKey

⚠️ Ponto crítico no AU915
Se o gateway não estiver configurado corretamente para downlink 500 kHz, o Join falha.

7.4 Derivação de chaves de sessão

Após o Join, são geradas as chaves de sessão:

ChaveFunção
NwkSKeyIntegridade e controle
AppSKeyCriptografia do payload

Essas chaves são derivadas a partir de:

  • AppKey

  • AppNonce

  • DevNonce

  • NetID

🔐 Segurança
As chaves de sessão:

  • São únicas por sessão

  • Mudam a cada novo Join

  • Impedem replay attacks

7.5 Gerenciamento de sessão

Uma sessão LoRaWAN inclui:

  • DevAddr

  • Chaves de sessão

  • Contadores de frame (FCntUp / FCntDown)

  • Parâmetros de data rate e potência

A sessão permanece válida até:

  • Reset do dispositivo

  • Rejoin

  • Expiração por política da rede

7.6 Contadores de frame (Frame Counters)

Os frame counters protegem contra replay attacks.

  • FCntUp: uplink

  • FCntDown: downlink

Regras importantes

  • Devem ser monotonicamente crescentes

  • Não podem ser reutilizados

  • Reset incorreto invalida a sessão

🔎 Erro comum no Brasil
Trocar bateria ou resetar o dispositivo sem novo Join → perda de comunicação.

7.7 Rejoin

O LoRaWAN define mecanismos de Rejoin para:

  • Atualizar chaves

  • Reconfigurar parâmetros

  • Recuperar comunicação

Tipos de Rejoin

  • Rejoin Type 0 — similar ao Join

  • Rejoin Type 1 — atualização periódica

  • Rejoin Type 2 — mudanças regionais

✔️ Uso crescente em redes modernas

7.8 ABP vs OTAA (na prática)

CritérioOTAAABP
SegurançaAltaBaixa
FlexibilidadeAltaBaixa
RejoinSimNão
Uso recomendado✔️⚠️

➡️ ABP só em cenários muito controlados

7.9 Erros comuns em AU915

⚠️ Sub-banda errada
⚠️ Gateway sem downlink 500 kHz
⚠️ CFList mal configurado
⚠️ Reset de dispositivo sem rejoin
⚠️ Frame counter fora de sincronia

Encerramento do Capítulo 7

Neste capítulo você aprendeu:

  • Como funciona o Join OTAA

  • Estrutura de Join Request e Join Accept

  • Derivação de chaves

  • Sessão LoRaWAN

  • Frame counters

  • Rejoin

  • Erros comuns no AU915

Comentários

Postar um comentário