Lorawan-stack: 特定のTX電力のゲートウェイによって拒否されたダウンリンク

Lora-net/packet_forwarderエラーが発生したようです。 関連コード： https ：

TTN（https://github.com/TheThingsNetwork/gateway-conf/）を介して配布されたゲートウェイ構成では、次のTX電源がゲートウェイによって受け入れられます。

-6 、 -3 、 0 、 3 、 6 、 10 、 11 、 12 、 13 、 14 、 16 、 20 、 23 、 25 、 26 、 27

Things Stackでは、ゲートウェイの動的構成を構築するときに同じリストを使用します： https ：

これは、_ERROR：Packet REJECTED、TX-11_のサポートされていないRF電力がゲートウェイの設定ミスにすぎないことを意味しますが、他のレポートは有効です。

これらは、v3ゲートウェイサーバーがサポートされていないTX電力値を送信したことが原因であると思われます。 サポートされているTX電力のリストにある場合にのみ、GSがTX電力値をUDPゲートウェイに送信するようにする必要があります。

これに関する最近の更新や洞察はありますか？

https://status.thethings.network/にレポートを追加して

https://status.thethings.network/は、ネットワークインシデントを対象としています。 それはこのための場所ではありません。 サーバーが送信する前にサポートされているTXPowerをチェックする新しいアップデートをリリースします。

こんにちはKirshna、

このアップデートがいつリリースされるか、もう少し正確に教えてください。 この修正を待っている人はたくさんいます。

ちなみに、「送信する前にサポートされているTX電力をチェックする」とはどういう意味ですか？ サーバーはTX電力が「標準」であることを確認しますか、それともパケットをドロップしますか？

ご協力いただきありがとうございます

https://status.thethings.network/は、ネットワークインシデントを対象としています。

それを表現するだけで、それは非常に厳格だと感じています。 これは、一部の人にとっては運用上の問題ですよね？ 少なくとも一部のユーザーにとって、デバイスはADRダウンリンクを受信しないためにSF12にドロップし、他のユーザーは突然OTAAが失敗するのを目にします。 ゲートウェイログにアクセスできないと、原因について暗闇に包まれます。最近までV2トラフィックのルーティングに何かが変更されるまで、問題なく機能していたためです。 （またはそのようなもの。これらの変更についても明確なコミュニケーションはありません。）

@avbentem ：これはソフトウェアの動作に関連しており、接続性/スループット/可用性などに関連していないため、運用上の問題として分類されません。ただし、これを修正することが重要であることは理解しています。 今後数日で修正が期待できます。
PS：あなたは完全に正しいです。 この変更は適切に伝達されませんでした。

この変更は適切に伝達されませんでした。

余談ですが、少なくともそれを修正するのに遅すぎることはありませんか？ 何が変更されたのか、いつ、問題をデバッグするときにV2とV3のどちらを見る必要があるのか​​、 @ KrishnaIyerと@htdvisserは

たとえば、この変更と将来の変更についてのフォーラム投稿などhttps://www.thethingsnetwork.org/updatesを歓迎し

動作を元に戻すパッチをデプロイしました。 これを閉じる前に、いくつかのフィードバックを待ちます。

クリシュナに感謝します！
修正された内容の詳細を教えてください。 誰かを責めないでください。ゲートウェイとパケットフォワーダーで発生した問題をよりよく理解し、観察された動作がこの変更によって引き起こされたことを確認するのに役立つからです。

変更は基本的にこれでした：

サポートされているTX電力のリストにある場合にのみ、GSがTX電力値をUDPゲートウェイに送信することを確認してください

https://github.com/TheThingsNetwork/lorawan-stack/issues/2106#issuecomment -596502171

この変更に加えて、v2システムから受信したダウンリンクのTX電力の変換が正しく行われず、3 dBmの差が生じることがわかりました（11は14、17は20、24は20である必要があります）。 27）。 これも修正されました。

詳細をありがとう、「_ 24は27_だったはずです」がまさに私たちの問題を引き起こしたものです。 この詳細を知っていれば、現場でGWをデバッグする必要はありません。

私はもう問題を自分の側で再現することができませんでした。 更新していただきありがとうございます！

ありがとう、 @ htdvisserと@KrishnaIyer。 これはどういうわけかV2とV3の接続に関連しているので、コミュニティネットワークのために、今日の接続方法をどこかに文書化していただけますか？

どうやら、2020年1月下旬の会議で簡単に発表されたように、V2に設定されたゲートウェイのトラフィックはV3を経由してルーティングされていますか？ 何かを見逃したかもしれませんが、V2のどのコンポーネントがまだ使用されているのか、そして現在V3に何が委任されているのかは本当にはっきりしていません。 また、いつ変更が加えられたかは不明です。

（例：コミュニティネットワークは引き続きV2 TTNコンソールを使用しており、正常に機能します。https：//github.com/TheThingsNetwork/ttn/issues/767が引き続き報告されているため、ADRは引き続きV2によって処理されていると思います。 2019年10月より前に参加したOTAAデバイス。ただし、上記の問題がV3で修正されたことを考えると、V3でも何かが行われていますか？状況がいつ変更されたかを知ることは、将来のデバッグに役立つ可能性があります。）

@dermatthias

これ以上現場でGWをデバッグする必要はありません

ゲートウェイ側も修正して、将来の変更やV3の将来の使用のためにフォールバックメカニズムを実装することは、依然として良い考えであることに注意してください。 よくわかりません; https://www.thethingsnetwork.org/forum/t/error-packet-rejected-unsupported-rf-power-for-tx-24/34833/14のSlackからのコメントを参照して

誰かが（たとえば）ゲートウェイに5dBiアンテナを持っている場合、これがどのように問題を修正したのかわかりません。 構成ファイルのアンテナゲインを0dBiのままにすると、最大有効送信電力を超え、構成ファイルを5dBiに変更すると、ゲートウェイによってパケットが拒否される場合があります。

@avbentemに返信：

私たちのコミュニティネットワーククラスターはすべて異なって見え、物事は常に変化しているため、各地域で物事がどのように接続されているかについての最新の概要を維持するには時間がかかりすぎます。

以下の画像では、ゲートウェイがv2ネットワークに接続する方法を示しています。 古い状況（黄色）はゆっくりと新しい状況（緑色）に移行します。 これを行うには、最初に特定のゲートウェイプロトコルのトラフィックのごく一部を新しいコンポーネントにルーティングし、その割合を徐々に増やします。 他のゲートウェイプロトコルについても同じです。

@johanstokkingが会議でのプレゼンテーションで述べたように、多くのコミュニティネットワークゲートウェイはすでにv3ゲートウェイサーバーを介して接続しており、時間の経過とともにv3ゲートウェイサーバーを介してより多くのゲートウェイを徐々に接続しています。

これらのゲートウェイサーバーを除いて、パブリックコミュニティネットワーク全体が引き続きv2コンポーネントを実行します。

@ tonysmith55への返信：

これはそうではありません。 動作を以前の状態に戻すだけです。 はい。これらのゲートウェイが所有者によって正しく構成されていない場合、ゲートウェイが最大の有効な送信電力を超える可能性があります（常に可能です）。

これがあなたの質問に答えることを願っています。 ここでは少し話題から外れ、この問題の解決が確認されたので、問題を閉じます。