再生ペイロードに関する議論

著者: Qualcomm Incorporated

セクション	詳細な要約
序論	RAN2#125bis会議で以下の合意がなされた: RAN3の入力を待って、切り替えとNGインターフェースに関連するセクション16.14.4と16.14.6を更新するオンボードgNB再生ペイロードアーキテクチャをサポートするためのRAN2ディスカッションの可能なベースラインとして、R2-2403606のTS 38.300のテキスト提案を検討できるかどうかを今後の会議で確認する再生ペイロードアーキテクチャにおける再同期を伴う衛星切り替えのサポートに関する議論を次回の会議で継続する本文書では、再生ペイロード動作で機能させるために議論が必要となる可能性のある機能の詳細を提供する。
議論	再同期のサポートを伴う衛星切り替え透過型ペイロードと固定セルシナリオでは、このRel-18機能により、UEはL3ハンドオーバーなしで衛星を切り替えることができる。この場合、セルSSB、SIB、UEのRRC設定は、衛星切り替え後も同じままである。この機能は、固定セルシナリオでL3ハンドオーバーとシグナリングのオーバーヘッドを回避するために重要である。再生ペイロードの場合、gNBがオンボードにあると、衛星の切り替えはgNBの切り替えになる。再同期機能を伴う衛星切り替えが再生ペイロードアーキテクチャに適用可能かどうかが問題となる。理想的なISLバックホールを前提とすれば、ネットワークの実装により可能である。古い衛星は、同じエリアにサービスを提供する新しい衛星にすべてのデータ（gNBコンテキスト、すべてのUEコンテキストなど）を転送する。再同期を伴うHARD衛星切り替えと同様のデータ転送時間がかかる可能性がある。これによるRANまたはコアネットワークへの影響は予見されない。再同期機能を伴う衛星切り替えは、ミラー衛星のネットワーク実装により、再生ペイロードアーキテクチャでサポートされる可能性がある。ソフト切り替えは、t-ServiceStartがt-Serviceより前に発生できないため、切り替え時間により不可能かもしれない。しかし、ハード衛星切り替えは、ごくわずかな仕様変更で可能である。必要な変更は、再生アーキテクチャでは位置ギャップ（t-Service - t-ServiceStart）が可能であることを明確にすることのみ。正の切り替えギャップ中にRRM要件を定義する必要があるかどうかは、RAN4に確認できる。 RAN2の観点から、再生ペイロードに対する再同期を伴う衛星切り替えのサポートを示すかどうかは、ネットワーク実装に任せる。唯一のRAN2仕様への影響は、衛星切り替えの正のギャップを明確にすること。つまり、t-ServiceStartはt-Serviceの後に発生する可能性がある。 RA-SDTにおける消費電力 NTNではRRC_INACTIVE状態とSDTがサポートされている。RA SDTでは、Msg3で小さなデータが送信され、ネットワークはMsg4を介してUEをRRC_INACTIVEに戻したい場合がある。ただし、UEをRRC_INACTIVEに戻す前に、オンボード衛星のgNBは、地上のAMFからのDL応答または保留中のDLデータを取得する必要がある。これにより、gNBがUEにDL応答データを提供するためのフィーダーリンクRTT遅延が発生する。オンボードのgNBは、地上ネットワークからの応答を待つ間、競合解決MACCEをすぐに送信したい場合がある。これは、競合解決タイマーの期限切れの可能性を回避するためである。この場合、競合解決MACCEのHARQフィードバックを送信した後、UEが不必要にPDCCHを継続的にモニタリングするのは確かに電力効率が良くない。競合解決タイマーの開始遅延と同様に、競合解決MACCEのHARQフィードバックを送信した後、さらなるRRCメッセージのPDCCHモニタリングを遅らせることができる。再生ペイロードでRA SDTを使用する際のUE省電力のために、競合解決MACCEのHARQフィードバックを送信した後、UE-gNB RTTによってさらなるRRCメッセージのPDCCHモニタリングが遅延される。ネットワーク検証済みUE位置ソリューションにおける頻繁なハンドオーバー中断透過型ペイロードについて、RAN2はすでに、特に移動セルシナリオにおける頻繁な衛星切り替えが、頻繁なセル変更によるネットワーク検証の長い遅延につながる可能性があることを議論した。完全なgNBがオンボードにある再生ペイロードアーキテクチャでは、古いgNBが到達できなくなるため、この問題はさらに悪化する可能性がある。シンプルなアプローチの1つは、LMFで遅延なくTRP/gNB更新を完了する方法をシグナリングで調べることである。頻繁なgNB切り替えがネットワーク検証済みUE位置の問題になるかどうかをRAN2で検討する。
結論	以下の観察と提案がなされた。観察1. 再同期機能を伴う衛星切り替えは、t-Serviceでのミラー衛星のネットワーク実装により、再生ペイロードアーキテクチャでサポートされる可能性がある。提案1 RAN2の観点から、再生ペイロードに対する再同期を伴う衛星切り替えのサポートを示すかどうかは、ネットワーク実装に任せる。唯一のRAN2仕様への影響は、衛星切り替えの正のギャップを明確にすること。つまり、t-ServiceStartはt-Serviceの後に発生する可能性がある。提案2 再生ペイロードでRA SDTを使用する際のUE省電力のために、競合解決MACCEのHARQフィードバックを送信した後、UE-gNB RTTによってさらなるRRCメッセージのPDCCHモニタリングが遅延される。提案3 頻繁なgNB切り替えがネットワーク検証済みUE位置の問題になるかどうかをRAN2で検討する。

セクション

詳細な要約

序論

RAN2#125bis会議で以下の合意がなされた:

RAN3の入力を待って、切り替えとNGインターフェースに関連するセクション16.14.4と16.14.6を更新する
オンボードgNB再生ペイロードアーキテクチャをサポートするためのRAN2ディスカッションの可能なベースラインとして、R2-2403606のTS 38.300のテキスト提案を検討できるかどうかを今後の会議で確認する
再生ペイロードアーキテクチャにおける再同期を伴う衛星切り替えのサポートに関する議論を次回の会議で継続する

本文書では、再生ペイロード動作で機能させるために議論が必要となる可能性のある機能の詳細を提供する。

議論

再同期のサポートを伴う衛星切り替え

透過型ペイロードと固定セルシナリオでは、このRel-18機能により、UEはL3ハンドオーバーなしで衛星を切り替えることができる。この場合、セルSSB、SIB、UEのRRC設定は、衛星切り替え後も同じままである。この機能は、固定セルシナリオでL3ハンドオーバーとシグナリングのオーバーヘッドを回避するために重要である。
再生ペイロードの場合、gNBがオンボードにあると、衛星の切り替えはgNBの切り替えになる。再同期機能を伴う衛星切り替えが再生ペイロードアーキテクチャに適用可能かどうかが問題となる。
理想的なISLバックホールを前提とすれば、ネットワークの実装により可能である。古い衛星は、同じエリアにサービスを提供する新しい衛星にすべてのデータ（gNBコンテキスト、すべてのUEコンテキストなど）を転送する。再同期を伴うHARD衛星切り替えと同様のデータ転送時間がかかる可能性がある。これによるRANまたはコアネットワークへの影響は予見されない。
再同期機能を伴う衛星切り替えは、ミラー衛星のネットワーク実装により、再生ペイロードアーキテクチャでサポートされる可能性がある。
ソフト切り替えは、t-ServiceStartがt-Serviceより前に発生できないため、切り替え時間により不可能かもしれない。しかし、ハード衛星切り替えは、ごくわずかな仕様変更で可能である。必要な変更は、再生アーキテクチャでは位置ギャップ（t-Service - t-ServiceStart）が可能であることを明確にすることのみ。正の切り替えギャップ中にRRM要件を定義する必要があるかどうかは、RAN4に確認できる。
RAN2の観点から、再生ペイロードに対する再同期を伴う衛星切り替えのサポートを示すかどうかは、ネットワーク実装に任せる。唯一のRAN2仕様への影響は、衛星切り替えの正のギャップを明確にすること。つまり、t-ServiceStartはt-Serviceの後に発生する可能性がある。

RA-SDTにおける消費電力

NTNではRRC_INACTIVE状態とSDTがサポートされている。RA SDTでは、Msg3で小さなデータが送信され、ネットワークはMsg4を介してUEをRRC_INACTIVEに戻したい場合がある。ただし、UEをRRC_INACTIVEに戻す前に、オンボード衛星のgNBは、地上のAMFからのDL応答または保留中のDLデータを取得する必要がある。これにより、gNBがUEにDL応答データを提供するためのフィーダーリンクRTT遅延が発生する。

オンボードのgNBは、地上ネットワークからの応答を待つ間、競合解決MACCEをすぐに送信したい場合がある。これは、競合解決タイマーの期限切れの可能性を回避するためである。この場合、競合解決MACCEのHARQフィードバックを送信した後、UEが不必要にPDCCHを継続的にモニタリングするのは確かに電力効率が良くない。競合解決タイマーの開始遅延と同様に、競合解決MACCEのHARQフィードバックを送信した後、さらなるRRCメッセージのPDCCHモニタリングを遅らせることができる。
再生ペイロードでRA SDTを使用する際のUE省電力のために、競合解決MACCEのHARQフィードバックを送信した後、UE-gNB RTTによってさらなるRRCメッセージのPDCCHモニタリングが遅延される。

ネットワーク検証済みUE位置ソリューションにおける頻繁なハンドオーバー中断

透過型ペイロードについて、RAN2はすでに、特に移動セルシナリオにおける頻繁な衛星切り替えが、頻繁なセル変更によるネットワーク検証の長い遅延につながる可能性があることを議論した。完全なgNBがオンボードにある再生ペイロードアーキテクチャでは、古いgNBが到達できなくなるため、この問題はさらに悪化する可能性がある。シンプルなアプローチの1つは、LMFで遅延なくTRP/gNB更新を完了する方法をシグナリングで調べることである。
頻繁なgNB切り替えがネットワーク検証済みUE位置の問題になるかどうかをRAN2で検討する。

結論

以下の観察と提案がなされた。

観察1. 再同期機能を伴う衛星切り替えは、t-Serviceでのミラー衛星のネットワーク実装により、再生ペイロードアーキテクチャでサポートされる可能性がある。
提案1 RAN2の観点から、再生ペイロードに対する再同期を伴う衛星切り替えのサポートを示すかどうかは、ネットワーク実装に任せる。唯一のRAN2仕様への影響は、衛星切り替えの正のギャップを明確にすること。つまり、t-ServiceStartはt-Serviceの後に発生する可能性がある。
提案2 再生ペイロードでRA SDTを使用する際のUE省電力のために、競合解決MACCEのHARQフィードバックを送信した後、UE-gNB RTTによってさらなるRRCメッセージのPDCCHモニタリングが遅延される。
提案3 頻繁なgNB切り替えがネットワーク検証済みUE位置の問題になるかどうかをRAN2で検討する。