Lorawan-stack: Multicast-Registrierung und Multicast-Downlink

Erstellt am 30. Okt. 2020  ·  7Kommentare  ·  Quelle: TheThingsNetwork/lorawan-stack

Hallo an alle,

Zusammenfassung

Probleme bezüglich _MULTICAST DEVICES REGISTRATION_ und _MULTICAST DOWNLINK_ über die Konsole und CLI

Schritte zum Reproduzieren der Multicast-Registrierung über die Konsole

  • Ich habe ein Endgerät mit folgendem Parameter hinzugefügt:

    • Aktivierungsmodus: Multicast
    • LoRaWAN-Version: MAC V1.0.3
    • DevEUI: nichts
    • Frequenzplan: SF12 für RX2
    • Bildzähler: 32bit
    • Multicast-Adresse: 00 00 00 01
    • Multicast-NwkSKey: B1-D1-03-3E-FD-AA-C8-D9-1B-C0-D0-F0-F9-C0-07-98
    • Multicast-AppSKey: 0D-81-06-99-B2-B5-4A-42-18-53-B1-B0-66-1B-27-24

  • Ich habe einen Multicast-Downlink über die Konsole geplant

  • _Beobachtung:_ Multicast-Adresse, Multicast-NwkSKey und Multicast-AppSKey sind die gleichen Setup-Multicast-Parameter, die ich in meinen physischen OTAA-Endgeräten gemäß dem von der Lora Alliance veröffentlichten Protokoll " _LoRaWAN® Remote Multicast Setup Specification v1.0.0_ (https:/ /lora-alliance.org/resource-hub/lorawanr-remote-multicast-setup-specification-v100)".

Was sehe ich jetzt?

Die Registrierung geht gut und der Downlink wurde erfolgreich geplant

Was ist das Problem?

Nach der Registrierung ist mir aufgefallen, dass das registrierte Multicast-Gerät nicht als _Aktivierungsmodus Multicast_, sondern als _Aktivierungsmodus ABP_ angezeigt wird. Warum ist das so? Kann ich einen gültigen Multicast-Downlink über die Konsole planen, selbst wenn sich das Gerät im _Aktivierungsmodus ABP_ befindet?

Schritte zum Reproduzieren der Multicast-Registrierung über CLI

Befolgen Sie die Anweisungen von The Things Stack (https://thethingsstack.io/devices/class-c-multicast/):

  • Multicast-Gerät hinzufügen:
    $ ttn-lw-cli Endgeräte erstellen app1 mc1
    --frequency-plan-id EU_863_870
    --lorawan-version 1.0.3
    --lorawan-phy-version 1.0.3-a
    --session.dev-addr 00000001
    --session.keys.app-s-key.key 0D810699B2B54A421853B1B0661B2724
    --session.keys.nwk-s-key.key B1D1033EFDAAC8D91BC0D0F0F9C00798
    - Multicast
    --supports-class-c

  • Geplanter Multicast-Downlink mit MQTT (Moskito)

_Mosquitto-Befehl:_ C:Programmimosquitto>mosquitto_pub -h movexxxx.xxx.xxxx.xxxx.xxxx.com -t "v3/ app1@movexxxx/devices/ mc1 /down/push" -u " app1@movexxxx " -P "NNSXS .YNQ5LIW5SExxxx" -m '{"downlinks":[{"frm_payload":"ciao","f_port":42,"priority":"NORMAL","class_b_c":{"gateways":[{"gateway_ids": {"gateway_id":" gtwid "}}],"absolute_time":"2020-10-28T20:20:00Z"}}]}' -d

  • _Beobachtung:_ Multicast-Adresse, Multicast-NwkSKey und Multicast-AppSKey sind die gleichen Setup-Multicast-Parameter, die ich in meinen physischen OTAA-Endgeräten gemäß dem von der Lora Alliance veröffentlichten Protokoll " _LoRaWAN® Remote Multicast Setup Specification v1.0.0_ (https:/ /lora-alliance.org/resource-hub/lorawanr-remote-multicast-setup-specification-v100)".

Was sehe ich jetzt?
Das hinzugefügte Multicast-Gerät wird als _Aktivierungsmodus Multicast_ angezeigt, wie es sollte.
Die Antwort des Moskito-Downlinks lautet wie folgt:

_Mosquitto-Antwort:_ Client mosqpub|23216-LAPTOP-OE sendet CONNECT
Client mosqpub|23216-LAPTOP-OE hat CONNACK empfangen
Client mosqpub|23216-LAPTOP-OE sendet PUBLISH (d0, q0, r0, m1, 'v3/ app1@movexxxxx/devices/ mc1 /down/push', ... (154 Byte))
Client mosqpub|23216-LAPTOP-OE sendet DISCONNECT

Was ist das Problem?

Wenn ich versuche, eine Multicast-Downlink-Nachricht von der Plattform zu senden, treten Fehler auf: „kein Downlink-Pfad verfügbar“ .

Ist stattdessen die Downlink-Antwort von mosquitto_pub richtig? Weil ich auf meinen physischen OTAA-Endgeräten nichts gesehen habe.

Was fehlt?

Ich verstehe nicht, wie ich meine OTAA-Geräte über die Konsole mit meiner Multicast-Gruppe korrelieren soll. Ich würde zum Beispiel gerne eine Multicast-Gruppe (mit seiner McAddress und McKeys) sehen, wo ich meine OTAA-Geräte hinzufügen kann, weil nicht klar ist, wie der Multicast-Downlink meine OTAA-Geräte erreichen kann.

needdetails
Quelle
picture MatteMoveSRL

Hilfreichster Kommentar

Nein, ich sehe keinen Downlink, der in meinem Gateway "Live-Daten" ankommt, aber stattdessen sah ich einige Daten, die im Abschnitt "Live-Daten" meiner Anwendung "foo" ankamen:

Bitte abonnieren Sie das Gateway-Ereignisprotokoll mit;

$ ttn-lw-cli events --gateway-id gtw-test

Aktivieren Sie auch Debug-Protokolle ( log.level: debug ).

Planen Sie dann die Downlink-Nachricht und beobachten Sie Protokolle und Gateway-Ereignisse.

Meinen Sie also, dass die Downlink-Nachricht wie eine Broadcast-Nachricht bei allen OTAA-Geräten ankommt, die mit dem Gateway verbunden sind, und nicht bei einer bestimmten Gruppe von OTAA-Geräten?

Ja, so funktioniert LoRaWAN. Jedes Gerät der Klasse C, das auf dieser Frequenz mit dieser spezifischen Datenrate lauscht, empfängt die Nachricht. Sie sehen sich die DevAddr der Nachricht an, um zu sehen, ob sie mit einer (Multicast-)Sitzung übereinstimmt, für die sie Sitzungsschlüssel haben. Wenn ja, verarbeiten sie die Nachricht und prüfen, ob der NwkSKey mit dem MIC übereinstimmt usw.

Apropos; Sind Sie sicher, dass Frequenz und Datenrate stimmen? Klasse C verwendet dafür die RX2-Parameter. Die Endgeräte sollten diese Parameter für die Multicast-Downlink-Frames abhören.

picture johanstokking am 9. Nov. 2020
❤1 👍1

Alle 7 Kommentare

@MatteMoveSRL danke für dein Problem. Wenn Sie ein TTI-Kunde mit einem Support-Plan sind, nutzen Sie am besten den Support-Kanal.

Wir verwenden hier Issue-Templates, um strukturiert an Informationen zu kommen.

Mir ist aufgefallen, dass das Enroll Multicast Device nicht als _Activation Mode Multicast_, sondern als _Activation Mode ABP_ ausgegeben wird. Warum ist das so?

Dazu benötigen wir Reproduktionsschritte, bitte bearbeiten Sie Ihren Beitrag, um der Problemvorlage zu folgen.

Ich kann keine Downlink-Nachrichten von der Plattform senden, weil Fehler "kein Downlink-Pfad verfügbar" auftreten. Ich habe auch versucht, einen Downlink mit MQTT unter Windows wie folgt zu senden, aber auf meinem Endgerät kommt nichts an.

Siehe https://thethingsstack.io/devices/class-c-multicast/ , dann den zweiten Hinweis unter Multicast Group und das Beispiel unten mit dem Planen von Downlinks.

johanstokking picture johanstokking am 5. Nov. 2020

@johanstokking Vielen Dank für die Antworten!

Ich habe meine Probleme aktualisiert, um die Informationen wie von Ihnen vorgeschlagen strukturiert zu erhalten. Ich hoffe, dass es verständlich ist

Diese zwei Punkte verstehe ich immer noch nicht:

Ist stattdessen die Downlink-Antwort von mosquitto_pub richtig? Weil ich auf meinen physischen OTAA-Endgeräten nichts gesehen habe

Ich verstehe nicht, wie ich meine OTAA-Geräte über die Konsole mit meiner Multicast-Gruppe korrelieren soll. Ich würde zum Beispiel gerne eine Multicast-Gruppe (mit seiner McAddress und McKeys) sehen, wo ich meine OTAA-Geräte hinzufügen kann, weil nicht klar ist, wie der Multicast-Downlink meine OTAA-Geräte erreichen kann

Vielen Dank im Voraus für Ihre Zeit und Ihre Antwort.

MatteMoveSRL picture MatteMoveSRL am 5. Nov. 2020

@MatteMoveSRL Ist stattdessen die Downlink-Antwort von mosquitto_pub richtig? Weil ich auf meinen physischen OTAA-Endgeräten nichts gesehen habe

Abgesehen von der absoluten Zeit, die in der Vergangenheit liegt, sieht es nicht verkehrt aus.

Aber ist gtwid ein verbundenes Gateway? Sehen Sie den in der Konsole geplanten Downlink, wenn Sie sich den Gateway-Datenverkehr ansehen?

@MatteMoveSRL Ich verstehe nicht, wie ich meine OTAA-Geräte über die Konsole mit meiner Multicast-Gruppe korrelieren soll. Ich würde zum Beispiel gerne eine Multicast-Gruppe (mit seiner McAddress und McKeys) sehen, wo ich meine OTAA-Geräte hinzufügen kann, weil nicht klar ist, wie der Multicast-Downlink meine OTAA-Geräte erreichen kann

Wir haben das Remote Multicast Setup-Protokoll noch nicht im Application Server implementiert. Also korrelieren wir das nicht. Das Multicast-Gerät ist ein virtuelles Gerät. Wenn Ihr Endgerät Downlink sowohl auf dem Unicast- als auch auf dem Multicast-Kanal versteht, sollten Sie in Ordnung sein.

johanstokking picture johanstokking am 6. Nov. 2020

@johanstokking Danke für die schnelle Antwort

Aber ist gtwid ein verbundenes Gateway?

Ja, das Gateway ist verbunden und ich habe "gw-test" anstelle von "gtwid" im mosquitto-Befehl verwendet.

gateway1

Sehen Sie den in der Konsole geplanten Downlink, wenn Sie sich den Gateway-Datenverkehr ansehen?

Nein, ich sehe keinen Downlink, der in meinem Gateway "Live-Daten" ankommt, aber stattdessen sah ich einige Daten, die im Abschnitt "Live-Daten" meiner Anwendung "foo" ankamen:

downlink2
downlink1

Wenn Ihr Endgerät Downlink sowohl auf dem Unicast- als auch auf dem Multicast-Kanal versteht, sollten Sie in Ordnung sein.

Meinen Sie also, dass die Downlink-Nachricht wie eine Broadcast-Nachricht bei allen OTAA-Geräten ankommt, die mit dem Gateway verbunden sind, und nicht bei einer bestimmten Gruppe von OTAA-Geräten?

MatteMoveSRL picture MatteMoveSRL am 6. Nov. 2020

Nein, ich sehe keinen Downlink, der in meinem Gateway "Live-Daten" ankommt, aber stattdessen sah ich einige Daten, die im Abschnitt "Live-Daten" meiner Anwendung "foo" ankamen:

Bitte abonnieren Sie das Gateway-Ereignisprotokoll mit;

$ ttn-lw-cli events --gateway-id gtw-test

Aktivieren Sie auch Debug-Protokolle ( log.level: debug ).

Planen Sie dann die Downlink-Nachricht und beobachten Sie Protokolle und Gateway-Ereignisse.

Meinen Sie also, dass die Downlink-Nachricht wie eine Broadcast-Nachricht bei allen OTAA-Geräten ankommt, die mit dem Gateway verbunden sind, und nicht bei einer bestimmten Gruppe von OTAA-Geräten?

Ja, so funktioniert LoRaWAN. Jedes Gerät der Klasse C, das auf dieser Frequenz mit dieser spezifischen Datenrate lauscht, empfängt die Nachricht. Sie sehen sich die DevAddr der Nachricht an, um zu sehen, ob sie mit einer (Multicast-)Sitzung übereinstimmt, für die sie Sitzungsschlüssel haben. Wenn ja, verarbeiten sie die Nachricht und prüfen, ob der NwkSKey mit dem MIC übereinstimmt usw.

Apropos; Sind Sie sicher, dass Frequenz und Datenrate stimmen? Klasse C verwendet dafür die RX2-Parameter. Die Endgeräte sollten diese Parameter für die Multicast-Downlink-Frames abhören.

johanstokking picture johanstokking am 9. Nov. 2020
❤1 👍1

@johanstokking Danke für deine Antwort.

Ja, so funktioniert LoRaWAN. Jedes Gerät der Klasse C, das auf dieser Frequenz mit dieser spezifischen Datenrate lauscht, empfängt die Nachricht. Sie sehen sich die DevAddr der Nachricht an, um zu sehen, ob sie mit einer (Multicast-)Sitzung übereinstimmt, für die sie Sitzungsschlüssel haben. Wenn ja, verarbeiten sie die Nachricht und prüfen, ob der NwkSKey mit dem MIC übereinstimmt usw.

Danke, ich habe es. Du warst wirklich klar.

Apropos; Sind Sie sicher, dass Frequenz und Datenrate stimmen? Klasse C verwendet dafür die RX2-Parameter. Die Endgeräte sollten diese Parameter für die Multicast-Downlink-Frames abhören.

Ich bin mir ziemlich sicher, dass ich die richtigen Parameter eingestellt habe. Meiner Meinung nach könnte das Problem sein, wie ich den Downlink mit MQTT oder etwas in Bezug auf das Gateway plane. Ich werde es diese Woche nach deinen guten Tipps versuchen und mich bei dir melden.

MatteMoveSRL picture MatteMoveSRL am 9. Nov. 2020

Bitte nutzen Sie die Foren für weitere Fragen; Wir beantworten keine Fragen zu GitHub-Problemen. Bitte beachten Sie dazu auch die Problemvorlagen.

johanstokking picture johanstokking am 12. Nov. 2020
👍1
War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

kschiffer picture kschiffer  ·  7Kommentare
adamsondelacruz picture adamsondelacruz  ·  7Kommentare
johanstokking picture johanstokking  ·  5Kommentare
htdvisser picture htdvisser  ·  4Kommentare
johanstokking picture johanstokking  ·  3Kommentare