セクション |
詳細な要約 |
1. 序論 |
- 本寄書では、Rel-19 NR NTN WID [1]に含まれる再生ペイロードのサポートについて議論する
- 前回の会議では、R18 NTNの機能(特に再同期を伴う衛星切り替え)が再生ペイロードに適用可能かどうかが議論され、次回の会議で議論を継続することが合意された [2]
- 本寄書では、この問題に関する見解を提供する
|
2. 議論 |
- 前回の会議では、RA-SDT、再同期を伴う切り替え、ネットワーク検証済みUE位置ソリューションについて議論された。3番目については透過型ペイロードと再生ペイロードで違いがないため、他の2つ(RA-SDTと再同期を伴う切り替え)について議論する
- 2.1 再生ペイロードにおけるRA-SDT
- [2]では、RA-SDT手順でMsg4(RRC Release)とともに地上のCNからDLパケットが常に送信されると仮定し、競合解決MACCEのACKを送信した後にMsg4のPDCCHモニタリングを遅らせることが期待されている
- しかし、UL SDT送信に関連するDL SDTパケットが常に存在するとは限らず、ULでの非アクティビティによってSDT手順がネットワークによって終了される可能性がある。その結果、UEは競合解決MACCEのACKを送信した後にPDCCHのモニタリングを停止し、RRCReleaseメッセージを見逃す可能性がある
- さらに、MACCEとMsg4の間のオフセットをどのように設定するかが不明確である。Uuインターフェースの往復遅延(RTT)のみを考慮する場合、透過型ペイロードのシナリオと変わりがない。UuインターフェースとバックホールのRTTの両方を考慮することは、特にマルチホップシナリオで衛星間リンクが考慮される場合、バックホールの遅延が不確定であるため困難と思われる
- 2.2 再生ペイロードにおける再同期を伴う衛星切り替え
- Rel-18ではL3ハンドオーバーシグナリングを削減するために再同期メカニズムを伴う衛星切り替えが導入された。Rel-18では2つの透過型衛星が地上の同じgNBから同じセルを転送できるため、PCIを変更せずに済む
- gNBが変更された場合はキーの更新が必要。TS 38.331によると、ターゲットgNBはRRCReconfigurationメッセージを使用してUEにNCCを通知するが、再同期を伴う衛星切り替えの利点は、切り替え時にRRCReconfigurationメッセージを送信しないことにある
- 再生ペイロードではRel-19で再同期機能を伴う切り替えがサポートされないことをステージ2で明確化する説明を追加することができる
- 2.3 ステージ3への影響
- 上記の分析に基づき、RAN2ステージ3への影響は見られない
|
3. 結論 |
- 本寄書は、既存の重要な機能が再生ペイロードの影響を受けるかどうか、再生ペイロードに拡張が必要かどうかを分析し、以下を提案する:
- RA-SDT
- 観測1: UL SDT送信に関連するDL SDTパケットが常に存在するとは限らず、ULでの非アクティビティによってSDT手順がネットワークによって終了される可能性がある。その結果、UEは競合解決MACCEのACKを送信した後にPDCCHのモニタリングを停止し、RRCReleaseメッセージを見逃す可能性がある
- 再同期を伴う切り替え
- 提案1: 再生ペイロードでは再同期を伴う衛星切り替えがサポートされないことをステージ2で明確化する説明を追加する
- ステージ3への影響
- 提案2: 再生ペイロードに関連するRAN2ステージ3への影響はない
|