Lorawan-stack: マルチキャスト登録とマルチキャストダウンリンク

@MatteMoveSRL問題をありがとう。 サポートプランのあるTTIのお客様の場合は、サポートチャネルを使用するのが最善です。

ここでは問題テンプレートを使用して、構造化された方法で情報を取得します。

登録マルチキャストデバイスは、_Activation mode multicast_としてではなく、_Activation modeABP_として生成されることに気付きました。 なんでそうなの？

このための複製手順が必要です。問題のテンプレートに従うように投稿を編集してください。

「ダウンリンクパスがありません」というエラーが発生したため、プラットフォームからダウンリンクメッセージを送信できません。 また、次のようにWindowsでMQTTを使用してダウンリンクを送信しようとしましたが、エンドデバイスに何も届きません。

https://thethingsstack.io/devices/class-c-multicast/を参照してから、マルチキャストグループの下の2番目のメモ、およびダウンリンクをスケジュールする方法を示す以下の例を参照してください。

@johanstokking回答ありがとうございます！

私はあなたが提案したように構造化された方法で情報を取得するために私の問題を更新しました。 理解できるといいのですが

私はまだこの2つのポイントを理解していません：

代わりに、mosquitto_pubダウンリンクの回答は正しいですか？ 物理的なOTAAエンドデバイスに何も到着していないので

コンソールを介してOTAAデバイスをマルチキャストグループに関連付ける方法がわかりません。 たとえば、マルチキャストダウンリンクがOTAAデバイスに到達する方法が明確でないため、OTAAデバイスを追加できるマルチキャストグループ（McAddressとMckeysを含む）を確認したいと思います。

お手数をおかけしますが、よろしくお願いいたします。

@MatteMoveSRL代わりに、mosquitto_pubダウンリンクの回答は正しいですか？ 物理的なOTAAエンドデバイスに何も到着していないので

過去の絶対時間は別として、それは間違いではありません。

しかし、 gtwidは接続されたゲートウェイですか？ ゲートウェイトラフィックを見ると、コンソールでダウンリンクがスケジュールされていることがわかりますか？

@MatteMoveSRLコンソールを介してOTAAデバイスをマルチキャストグループに関連付ける方法がわかりません。 たとえば、マルチキャストダウンリンクがOTAAデバイスに到達する方法が明確でないため、OTAAデバイスを追加できるマルチキャストグループ（McAddressとMckeysを含む）を確認したいと思います。

アプリケーションサーバーには、リモートマルチキャストセットアッププロトコルはまだ実装されていません。 したがって、これを相関させることはありません。 マルチキャストデバイスは仮想デバイスです。 エンドデバイスがユニキャストチャネルとマルチキャストチャネルの両方でダウンリンクを理解している場合は、問題ないはずです。

@johanstokking迅速な返信ありがとうございます

しかし、gtwidは接続されたゲートウェイですか？

はい、ゲートウェイが接続されており、mosquittoコマンドで「gtwid」の代わりに「gw-test」を使用しました。

ゲートウェイトラフィックを見ると、コンソールでダウンリンクがスケジュールされていることがわかりますか？

いいえ、ゲートウェイの「ライブデータ」にダウンリンクが到着していませんが、代わりに、アプリケーション「foo」の「ライブデータ」セクションにデータが到着しています。

エンドデバイスがユニキャストチャネルとマルチキャストチャネルの両方でダウンリンクを理解している場合は、問題ないはずです。

つまり、ダウンリンクメッセージは、OTAAデバイスの特定のグループではなく、ブロードキャストメッセージのようにゲートウェイに接続されているすべてのOTAAデバイスに到着するということですか？

いいえ、ゲートウェイの「ライブデータ」にダウンリンクが到着していませんが、代わりに、アプリケーション「foo」の「ライブデータ」セクションにデータが到着しています。

でゲートウェイイベントログをサブスクライブしてください。

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

また、デバッグログを有効にします（ log.level: debug ）。

次に、ダウンリンクメッセージをスケジュールし、ログとゲートウェイイベントを監視します。

つまり、ダウンリンクメッセージは、OTAAデバイスの特定のグループではなく、ブロードキャストメッセージのようにゲートウェイに接続されているすべてのOTAAデバイスに到着するということですか？

はい、それがLoRaWANの仕組みです。 その特定のデータレートでその周波数をリッスンしているすべてのクラスCデバイスがメッセージを受信します。 メッセージのDevAddrを調べて、セッションキーがある（マルチキャスト）セッションと一致するかどうかを確認します。 もしそうなら、彼らはメッセージを処理し、NwkSKeyがMICなどと一致するかどうかを確認します。

そういえば; 頻度とデータレートが正しいことを確認しますか？ クラスCは、このためにRX2パラメーターを使用します。 エンドデバイスは、マルチキャストダウンリンクフレームのこれらのパラメータをリッスンする必要があります。

@johanstokkingお返事ありがとうございます。

はい、それがLoRaWANの仕組みです。 その特定のデータレートでその周波数をリッスンしているすべてのクラスCデバイスがメッセージを受信します。 メッセージのDevAddrを調べて、セッションキーがある（マルチキャスト）セッションと一致するかどうかを確認します。 もしそうなら、彼らはメッセージを処理し、NwkSKeyがMICなどと一致するかどうかを確認します。

おかげで私はそれを手に入れました。 あなたは本当に明確でした。

そういえば; 頻度とデータレートが正しいことを確認しますか？ クラスCは、このためにRX2パラメーターを使用します。 エンドデバイスは、マルチキャストダウンリンクフレームのこれらのパラメータをリッスンする必要があります。

私は正しいパラメータを設定したと確信しています。 私の意見では、問題はMQTTまたはゲートウェイに関する何かでダウンリンクをスケジュールする方法である可能性があります。 今週はあなたの良いヒントに従って試して、あなたに戻ってきます。

追加の質問については、フォーラムを使用してください。 GitHubの問題に関する質問には回答しません。 そのための問題テンプレートも参照してください。