Lorawan-stack: Tipos de dispositivo de documento OTAA, ABP e Multicast

Removidas seções irrelevantes para emissão do tipo "pergunta"

Referência nº 890

P: Existe a possibilidade de enviar mensagens multicast com webhook?

R: Sim, a pilha suporta o registro de sessões multicast Classe C como qualquer outro dispositivo final com o sinalizador --multicast . Isso está descrito em nosso Guia de introdução: https://github.com/TheThingsNetwork/lorawan-stack/blob/master/doc/gettingstarted.md#creating -a-device

P: Existe a possibilidade de enviar dados de downlink de firmware como mensagens multicast para muitos nós (para o aplicativo) usando webhooks?

R: Sim, a sessão multicast é registrada como qualquer outro dispositivo, então você pode agendar o downlink para ela exatamente da mesma maneira que faria para um dispositivo normal.

P: Existem alguns documentos/informações para isso?

R: Não mais do que está atualmente no Guia de Introdução.

@rvolosatovs @adriansmares IIRC vocês fizeram testes com Classe C e com Multicast, certo? Devemos escrever uma boa página de documentação sobre isso?

Se sim, então vamos esperar pelo #401 antes de fazer isso.

@htdivsser - obrigado pela resposta. Eu vi isso no começo.

A sintaxe do webhook (url) é:
curl http://localhost :1885/api/v3/as/applications/ap2/webhooks/fwup/devices/dv1/down/push -X POST -H 'Autorização: Portador NNSXS.CLCIYOYYYEDPLJSSWRNMYS5KCDI45HOE6M3WZIDY.E6DXAAZ4HSX2V6VL7C3244HGNKBO24SEROTXOE6M3WZIDY.E6DXAAZ4HSX2V6VL7C3244HGNKBO24SEROTXOV6VL7C3244HGNKBO24SEROTXOE6M3WZIDY. "downlinks":[{"frm_payload":"vu8=","f_port":15,"priority":"NORMAL"}]}'

Há um nome de dispositivo único especificado para o destino de downlink

Então, qual é a sintaxe do webhook impondo mensagens multicast para vários dispositivos?

A ideia é que você registre um único "pseudodispositivo" representando um grupo multicast que contém vários dispositivos físicos. Ao usar o webhook para agendar o downlink para o grupo multicast, você o direciona para esse pseudodispositivo.

Como você pode ver no Guia de Introdução, o registro de tal pseudodispositivo é essencialmente o mesmo de um dispositivo ABP. O DevAddr é o endereço Multicast, o NwkSKey é o McNwkSKey e o AppSKey é o McAppSKey.

Como ainda não implementamos a Configuração Multicast Remota, a sessão multicast no lado do dispositivo ainda precisa ser configurada pela camada de aplicação.

@htdvisser obrigado.
O pseudodispositivo multicast precisa ser ABP?
Espero que não colida com o acesso direto a dispositivos finais reais?

Não consigo encontrar nada sobre criação de pseudodispositivo e adicionar dispositivos a este "grupo" na introdução que você mencionou.

Também verifiquei:
ttn-lw-cli --help
ttn-lw-cli end-devs --help
ttn-lw-cli dev --help
e não pode ver a descrição "intuitiva" para pseudodispositivos e grupos.

Você pode fornecer comandos, para conseguir isso?

Os dispositivos multicast @ecities precisam ser ABP, pois não enviam uplinks e, portanto, não suportam fluxo OTAA por definição
Registre o dispositivo da mesma forma que faria com um dispositivo ABP, mas adicione o sinalizador multicast .

@rvolosatovs obrigado
Multicast devices have to be ABP, since they do not send uplinks and hence do not support OTAA flow by definition
Então temos que escolher apenas um dos ??:
-dev padrão com otta (classe A ou C)
-multicast dev com abp (classe C) - sinalizador criado na criação do dispositivo e não pode ser removido. Não é possível fazer o uplink de dados.

Ou talvez haja uma solução alternativa, por exemplo: adicionar dispositivos a 2 aplicativos diferentes?
1) para trabalho normal (uplink/downlink) (ap1)
2) apenas para downlink multicast (ap2)
_Mas parece haver problemas com direitos de acesso - relatamos um problema aqui_

Register the device same way you would an ABP device, but add the multicast flag.

Talvez um exemplo:
Digamos que eu tenha 2 dispositivos (dev1, dev2 com o mesmo McNwkSKey, McAppSKey e talvez dev-addr)
dispositivos finais ttn-lw-cli criam app1 dev1 \
--frequency-plan-id EU_863_870 \
--lorawan-versão 1.0.2 \
--lorawan-phy-versão 1.0.2-b \
--abp \
--session.dev-addr 00E4304D \
--session.keys.app-s-key.key A0CAD5A30036DBE03096EB67CA975BAA \
--session.keys.nwk-s-key.key B7F3E161BC9D4388E6C788A0C547F255 \
--multicast

dispositivos finais ttn-lw-cli criam app1 dev2 \
--frequency-plan-id EU_863_870 \
--lorawan-versão 1.0.2 \
--lorawan-phy-versão 1.0.2-b \
--abp \
--session.dev-addr 00E4304D \
--session.keys.app-s-key.key A0CAD5A30036DBE03096EB67CA975BAA \
--session.keys.nwk-s-key.key B7F3E161BC9D4388E6C788A0C547F255 \
--multicast

Está certo?

e deseja enviar mensagem multicast para ambos com webhook.
Ainda não está claro para mim o que seria URL para webhook?
http://localhost :1885/api/v3/as/applications/ap2/webhooks/fwup/devices/00E4304D/down/push

Isso está correto?

Ou talvez:

http://localhost :1885/api/v3/as/applications/ap2/webhooks/fwup/devices/dev1/down/push

e será recebido por outros dispositivos com as mesmas configurações de segurança onde
--session.keys.app-s-key.key A0CAD5A30036DBE03096EB67CA975BAA
--session.keys.nwk-s-key.key B7F3E161BC9D4388E6C788A0C547F255

??

Um dispositivo multicast registrado em lorawan-stack pode representar um número arbitrário de dispositivos físicos.
Então, digamos que você tenha 5 dispositivos que deseja operar no modo Multicast - então você provisionaria todos os 5 dispositivos físicos para usar:

• DevAddr idêntico (por exemplo 00E4304D )
• chaves de sessão idênticas (por exemplo A0CAD5A30036DBE03096EB67CA975BAA e A0CAD5A30036DBE03096EB67CA975BAA para AppSKey e NwkSKey respectivamente).

Então você registraria um único dispositivo em lorawan-stack com o DevAddr e as chaves de sessão que você escolheu e o conjunto de sinalizadores multicast .
Digamos que você chamou o dispositivo que acabou de criar dev1 e o nome do aplicativo é app1 .
Digamos que você continue a enviar um downlink por dev1 no aplicativo app1 (consulte a documentação sobre várias maneiras de fazer isso), então o lorawan-stack agendaria um único downlink para dispositivo com DevAddr 00E4304D .
O downlink único seria recebido por todos os dispositivos correspondentes a DevAddr 00E4304D , ou seja, todos os 5 (idealmente) dispositivos que você provisionou acima.

Observe que alguns dispositivos físicos podem realmente participar de várias sessões simultaneamente.
Vamos supor que você tenha 5 desses dispositivos e queira que eles operem como OTAA, além de fazer parte do grupo multicast:

1. Você registraria cada dispositivo como um dispositivo OTAA separado, cada um com seu próprio ID de dispositivo. (então, registre 5 dispositivos - 1 por cada dispositivo físico)
2. Você registraria um único dispositivo como um dispositivo multicast com um ID de dispositivo distinto (assim, registre 1 dispositivo - 1 por cada grupo multicast)

A chave para entender aqui é que o dispositivo multicast registrado pode representar vários dispositivos físicos, no entanto, todos esses dispositivos físicos precisam compartilhar o DevAddr e as chaves de sessão.

@rvolosatovs muito obrigado pela explicação "passo a passo" muito boa, que elimina a maioria das suposições

Acho que vale a pena copiar para o manual de introdução ou a documentação multicast, pois isso não é tão óbvio na prática

Cumprimentos,

Roberto

@ecities de nada, fico feliz em poder ajudar!
@adriansmares você pode pegar isso?

@adriansmares sugerindo que expliquemos um pouco mais detalhadamente o que são dispositivos OTAA, ABP e Multicast, especialmente este último.

Estou tentando criar --multicast device (comando copiado do exemplo de introdução)

dispositivos finais ttn-lw-cli criam ap3 lldv3 \
--frequency-plan-id EU_863_870 \
--lorawan-versão 1.0.2 \
--lorawan-phy-versão 1.0.2-b \
--abp \
--session.dev-addr 11E4304D \
--session.keys.app-s-key.key A0CAD5A30036DBE03096EB67CA975BAA \
--session.keys.nwk-s-key.key B7F3E161BC9D4388E6C788A0C547F255 \
--multicast

e recebi uma mensagem:
sinalizador desconhecido: --multicast

versão ttn-lw-cli
Interface de linha de comando da Things Network: ttn-lw-cli
Versão: 3.0.3
Versão Go: go1.12.5
SO/Arch: linux/amd64

Por favor, aguarde v3.1.0 ou construa master partir da fonte, veja DEVELOPMENT.md .