Lorawan-stack: ネットワークサーバーメッセージに基づいてエンドデバイスセッションを確認します

すでに説明したように、私はこれに賛成です。
アプリケーションサーバーは、デバイスセッションに関する最新のデータを常に保持しているため、常にネットワークサーバーを信頼する必要があります。

• エンドデバイスはFPort = 0アップリンクを送信します-ASはこのアップリンクを受信しません

NSがこれを送信するようにこれを変更する必要がありますが、ペイロードが空でFPort 0を使用して、アップストリームに送信されないようにしますか？

• エンドデバイスはFPort = 0アップリンクを送信します-ASはこのアップリンクを受信しません

NSがこれを送信するようにこれを変更する必要がありますが、ペイロードが空でFPort 0を使用して、アップストリームに送信されないようにしますか？

NS-> ASメッセージングは​​非同期であるため、セッションを確認するためにFPort==0アップリンクがASに送信される前にキューの無効化が到着する可能性があるため、冗長です。とにかくこれを行う必要があります。 NSへのFPort==0アップリンクに応答してASにアップリンクを送信する唯一の理由は、ASにセッション変更ができるだけ早く通知されるようにするためですが、そのような必要はありません。 それでも、NSがFPort 0アップリンクの代わりにASに送信するSessionSwitchメッセージを導入する方が理にかなっています。

v3.11.1展開に影響しているため、優先度をprio/highアップグレードしました。

変更は次のようになります。

• SessionKeyIDをDownlinkQueueInvalidation追加します。 キューが空の場合、ASは現時点でどのキューが無効にされたかを知ることができません。

次のproto追加（フィールド3 ）で十分です。

message ApplicationInvalidatedDownlinks {
  repeated ApplicationDownlink downlinks = 1;
  uint32 last_f_cnt_down = 2;
  bytes session_key_id = 3 [(gogoproto.customname) = "SessionKeyID", (validate.rules).bytes.max_len = 2048];
}

• ASは、無効化が約dev.Sessionであると常に想定するのではなく、正しいセッションのキュー+ FCntを更新する必要があります。

https://github.com/TheThingsNetwork/lorawan-stack/blob/e2fa6c085eaaf1a0b70939020244875bd01e5857/pkg/applicationserver/applicationserver.go#L1020 -L1038

常にdev.Sessionを使用する代わりに、使用するセッションを確立するためにSessionKeyIDをオンにします。 必要に応じて、現在のdev.Session更新します。

• ASは、 nackedメッセージがどのセッションからのものかを確認する必要があります- nackedメッセージが保留中のセッションからのものである可能性があるため（ASの観点から）、FCntの更新は正しいセッション。

https://github.com/TheThingsNetwork/lorawan-stack/blob/e2fa6c085eaaf1a0b70939020244875bd01e5857/pkg/applicationserver/applicationserver.go#L1060 -L1073

前と同じように、使用するセッションを決定するためにSessionKeyIDをオンにします。 必要に応じて、現在のdev.Session更新します。

• （オプション）最小FCntでDownlinkQueue{Push|Replace}エラーの詳細を返し、常にLastAFCntDownをこの値に更新します。 これにより、何らかの理由でASとNSの間で同期がとれていない場合に、システムが確実に収束します。

次のproto追加を入力し、エラーの詳細としてNSのerrFCntTooLowに追加する必要があります。

message UpdateDownlinkQueueErrorDetails {
  bytes session_key_id = 1 [(gogoproto.customname) = "SessionKeyID", (validate.rules).bytes.max_len = 2048];
  uint32 last_f_cnt_down = 2;
}

ASはこれらの詳細を取得し、現在のセッションを更新できます。

変更には下位互換性があり、NS側では最小限であることが望まれます。 魔神はすでにボトルから出ています-ASとNSの間のプロトコル全体がゆっくりと非同期になり、 FPort=0変更を元に戻すだけでは十分ではありません。 結局のところ、この変換が間違っていたとは思いませんが、セッションの双模倣に関するこれらの癖を修正する必要があります。

cc @ johanstokking 、 @ rvolosatovs

私にはいいですね！

ここでできることはありますか？ もしそうなら、私を再割り当てして、私に何を知らせてください。

ここでできることはありますか？ もしそうなら、私を再割り当てして、私に何を知らせてください。

私はすでにこれに取り組んでおり、次の点に非常に重点を置いています。

* (Optional) return error details on `DownlinkQueue{Push|Replace}` with the minimum `FCnt` and always update the `LastAFCntDown` to this value. This would ensure that the system converges if at any point we're for some reason out of sync between AS and NS.

これは、キューの一部としてNSから受信したイベントに基づいてアクションを実行するだけでは、基本的に十分ではないためです。

• メッセージは古い可能性がありますが、キューを修正したいと思います_now_
• メッセージが失われる可能性があります-キューは無限ではありません
• メッセージは並べ替えられる場合があります-メッセージは非同期でキューにプッシュされ、並べ替えられる可能性のある方法でポップされます

これらの特性を考えると、2つのオプションがあります。

• キューの計算をバッチ処理の最後まで遅らせます（基本的に、10個のダウンリンクキューの無効化を受け取った場合は、最後にのみキューを再計算します）。 次の理由により、これでは不十分です。
  
  
  
  • ASがメッセージのバッチを処理するとき、キューの最後にいるのか、途中でバッチを処理しているのかはまだわかりません。
  
  
  • メッセージは依然として失われる可能性があり、メッセージの順序を決定することは簡単ではありません。
  
  
• ただ_NSを信頼する_。 これが意味するのは、プッシュ/置換操作は、エラーの詳細の一部として、 dev.Session.SessionKeyID 、 dev.PendingSession.SessionKeyID 、およびLastAFCntDown返すということです。 次に、エラーの詳細を使用して、ASでセッションを再構築します。 基本的に、これは、古いデータ（おそらく古いセッション、おそらくFCntが低すぎる）を使用してダウンリンクキュー操作を実行しようとすると、最終的にNS状態に収束することを意味します。 1、2、3回の試行が必要になる場合があります。無限に回転するのを避けるために制限を設けますが、少なくともアップリンクメッセージキューからの情報よりも大幅に新しい情報で動作しています。

• ただ_NSを信頼する_。 これが意味するのは、プッシュ/置換操作は、エラーの詳細の一部として、 dev.Session.SessionKeyID 、 dev.PendingSession.SessionKeyID 、およびLastAFCntDown返すということです。 次に、エラーの詳細を使用して、ASでセッションを再構築します。 基本的に、これは、古いデータ（おそらく古いセッション、おそらくFCntが低すぎる）を使用してダウンリンクキュー操作を実行しようとすると、最終的にNS状態に収束することを意味します。 1、2、3回の試行が必要になる場合があります。無限に回転するのを避けるために制限を設けますが、少なくともアップリンクメッセージキューからの情報よりも大幅に新しい情報で動作しています。

これが最良の選択肢だと思います。