FL Summary #2 for IoT-NTN
3GPP TSG RAN WG1 #116bis R1-2403719
Source: Moderator (Sony)
項目 内容
Introduction

本文書はIoT-NTNの第2回目のFLSであり、4月18日木曜日のオフライン/オンライン議論の準備を目的としている。議論する課題は以下の通り。

  • シングルトーンとマルチトーンのOCCの選択/優先順位付け
    • シングルトーンの15kHz SCS、3.75kHz SCS、またはその両方のサポートの選択
    • 異なるSCS/トーン数に対して異なるスキーム(スロットレベルとシンボルレベル)をサポートするかどうか
  • DMRS: 提案されているスキームを明確にすることを目標とする
  • NPUSCHフォーマット1の評価における周波数誤差の一様ランダム分布の明確化

このFLSには一連の提案が含まれており、それらはオンラインミーティングで検討される可能性がある。また、一連の質問も含まれている。これらの質問は企業の見解を共有することを目的としている。十分な合意が得られれば、提案を生成することも可能かもしれない。

木曜日のオフラインセッションで議論される内容に関心のある代表者は、セクション7に直接進むことができる。

NPUSCH

NPUSCHについては以下の問題が議論されている。

  • 時間領域および周波数領域OCC。シングルトーンとマルチトーンNPUSCHにOCCを適用する方法。RAN1がシングルトーン送信に注力すべきかどうか。
  • シグナリングと設定。UEは複数のOCCスキームをサポートし、eNBがサポートされているスキームの1つを選択できるようにすべきか。
  • OCCシーケンスの設計と長さ。OCCシーケンスの最大長は何か。
  • 他の機能との互換性。OCCはEDT、PURなどで動作すべきか。
  • 更新された評価の仮定。RAN1#116で合意された評価の仮定の一部の小さな修正を検討する必要がある。

入力寄書で企業が提起した問題の全体的な要約は以下の通り。

  • DMRSの多重化方式: CDM [HW]、TDM [HW] (CDMよりもパフォーマンスが良い [HW])
  • OCCをサポートするためのDMRSシンボル数の増加 [LGE]
  • シングルトーンOCCのパフォーマンス
    • RV/repレベルのOCCはパフォーマンスが悪い[HW](repレベルのパフォーマンス損失はスロット/シンボルレベルと比較して有意ではない[ZTE] - 約0.7dBの追加の損失があるようだ)
    • シンボルレベルとスロットレベルのOCCは同等のパフォーマンスを示す[HW, ZTE](集約スループットが2倍[HW]、OCC2で集約スループットが2倍[QC])
    • スロットレベル以上ではCFOの問題が大きすぎるため、シンボルレベルが検討された[QC]
    • TDM DMRSはCDM DMRSよりもパフォーマンスが良い[HW]
  • マルチトーンのパフォーマンス
    • RV/repレベルのOCCはパフォーマンスが悪い[HW](repレベルのパフォーマンス損失はスロット/シンボルレベルと比較して有意ではない[ZTE])
    • OCC2の場合、シンボル、スロット、N_slotレベルのOCCは同等のパフォーマンスを示す[HW]
    • OCC4の場合、シンボル、スロットは同等のパフォーマンスを示す[HW](N_slotレベルはOCC4で低下[HW])
    • OCC4の送信が長いため、OCC4の方がOCC2よりもFO誤差が大きい[Xiaomi]
    • OCCスキームでより高い集約スループット[HW, ZTE]
    • 送信時間が短いため、シングルトーンよりもSNR劣化が少ない[ZTE]
  • 3.75kHzと15kHzのOCC多重化
    • サポートしない:eNBでの分離が難しすぎる/複雑すぎる[Len]
  • OCCの基本単位長の設定
    • 値Xで構成可能[Len]
  • OCCシーケンスのシグナリング
    • DCI、半静的(RRC)、またはC-RNTIに基づく
  • OCCシーケンスの種類
    • DFTコード[ZTE, Apple](TS38.211のPUCCHフォーマット1から[ZTE])
    • ウォルシュコード[CATT, Apple]
    • どのOCCシーケンスを使用するかを決定する前に、OCCの長さを決定すべき[FL]
  • OCCサイズ
    • 最大4 [Apple](OCC4以上をサポートするとNPDCCHシグナリングがボトルネックになる[Apple] - NPDCCHはNPUSCHだけでなくNPDSCHもスケジュールする必要がある[Apple])
    • 最大2 [Ericsson](OCC4の位相シフトが大きすぎる[Ericsson])
    • 2,4 [Apple]
    • 限られた数のOCC長さをサポート[Nokia](あまりにも多くのOCC長さをサポートすると複雑さが増す[Nokia])
  • NPUSCHのOCCスキームに関する見解
    • シンボルレベル
      • PhyCHマッピングを再定義する必要があるため、仕様への影響が大きい[ZTE, Apple, QC]
      • FOとTOに対してより弾力的[ZTE, QC]
      • 符号化率に影響し、それがパフォーマンスに影響する[vivo, OPPO, Sharp](OCC4の場合、繰り返し回数が多いため特に[vivo])
      • DMRSの問題[Apple, Sharp, QC](DMRSシンボルをペアで小さなギャップで分離し、ペアを大きなギャップで分離することで、DMRSシンボルを再配置することでDMRSの問題を解決できる[QC]。考慮すべき問題:プルイン範囲(あいまいさを回避する最大位相誤差)[QC]、DMRSの相対的なオーバーヘッド[QC])
      • 3.75kHzにはOCC2 [Ericsson]
    • スロットレベル
      • PhyCHマッピングを再定義する必要があるため、仕様への影響が大きい[ZTE]
      • FOとTOに対してより弾力的だが、シンボルレベルほどではない[ZTE]
      • 許容可能なパフォーマンスを示す[Xiaomi, CATT](OCC4がサポートされる。リンクレベルのパフォーマンス損失があるにもかかわらず、全体的なスループット利得はまだある[CATT])
      • 符号化率を増加させ、パフォーマンスに影響を与える[vivo, Sharp]
      • 実装が簡単(複雑さが少ない)[CATT]
      • パフォーマンスはOK(NR NTNでシミュレーション済み)[MTK]
      • 15kHzにはOCC2 [Ericsson]
    • 繰り返しレベル
      • 仕様への影響が少ない[ZTE, Sharp]
      • FOとTOのため、パフォーマンスが悪い[ZTE]
      • 時間スパンが長すぎるため、パフォーマンスが悪い[Spreadtrum]
      • パフォーマンスはOK [MTK]
    • RVレベル
      • FOとTOのため、パフォーマンスが悪い[ZTE]
      • 時間スパンが長すぎるため、パフォーマンスが悪い[Spreadtrum, Sharp]
      • デコード遅延[Apple]
    • シンボル内pre-DFT
      • 仕様の大幅な変更[ZTE]
      • 多重化の効果は、OCCを行わず、UEにより少ない量の周波数リソースを割り当てることで達成できる[ZTE]
      • 符号化率を増加[vivo]
      • 電力ブースト利得[vivo](しかし、同じ効果はサブキャリア数を減らすことで達成できないか?[FL, CATT])
      • 時間領域スキームのみを考慮[Xiaomi, Nokia, ETRI](TDスキームはマルチキャリアとシングルキャリアの両方に適用可能[Xiaomi, Nokia]、シングルトーンスキームとの共通設計[Ericsson])
      • マルチキャリアスキームは考慮しない[Sharp, MTK](eNBが容量を懸念しているのであれば、シングルキャリアを適用すべき[Sharp]、まずシングルトーンスキームを検討[Ericsson])
  • 異なるサブキャリア間隔(3.75kHz、15kHz)で異なるスキームをサポートするか?
    • Yes [Ericsson](3.75kHzでスロットレベルOCCの位相シフトが大きすぎるため、3.75kHzではシンボルレベルを使用)

評価の仮定に関する問題:

  • 評価では小さなデータとVoIPを考慮[CMCC]
  • DMRSの位置誤差を考慮するために、NPUSCH評価の仮定を更新[ETRI]
  • セル内の潜在的な経路損失の差を考慮して、電力不均衡は5.1dBとすべき[ETRI]