Release 19におけるNTN進化のためのRAN4主導の非スペクトル優先事項
3GPP TSG RAN Meeting #103 RP-240506
著者: Inmarsat, Viasat, Omnispace, Hughes/EchoStar, Terrestar Solutions, Ligado Networks
項目 内容
NR NTN Operator Priorities
  1. NR less than 5 MHz – NR_FR1_lessthan_5MHz_BWですでに指定されているように、NTNバンドに対しても少なくとも3 MHzのチャネル帯域幅と12 PRBの伝送をサポートすること。これは、既存の非3GPPサービスのコンテキストでNR NTNの展開を可能にし、EIRP制限のある衛星をサポートし、周波数再利用効率を最大化するために重要。
  2. HPUE for NR NTN – すべてのFR1 NTNバンドについて、PC2(+26 dBm)、PC 1.5(+29 dBm)、PC1(31 dBm)をサポートし、FDD HPUEの既存のTN仮定を再利用する。
  3. NTN-NTN intra-SAN Carrier aggregation (CA) - ユーザーあたりのスループットの改善と、同じSAN内の異なるNTN周波数ブロック(例:帯域内およびL + S帯域間)にわたる帯域幅の集約に重点を置く。
  4. Better Support of Fragmented Spectrum - 既存のレガシーサービスが5G NRチャネル割り当てを中断する可能性があり、より大きなシステム帯域幅で5G NR NTNサービスをスケジュールする必要がある状況に対応するため。
  5. 4RX for NR NTN – 受信性能を向上させ、最大4つのLおよびSバンドアンテナを搭載できるデバイスのNR NTN UEをTN仕様および要件に合わせるため。
IoT NTN Operator Priorities
  1. HPUE for IoT NTN - 特にNB-IoT NTNを含むすべてのFR1 IoT NTNバンドに対して、PC2(+26 dBm)とPC1(31 dBm)をサポートする。
  2. In-Band NB-IoT NTN with NR NTN in same SAN – 現在、地上ネットワークではRel-16以降、5G NRキャリア内でのNB-IoTの展開がすでにサポートされており、スペクトル使用効率と展開の柔軟性を大幅に向上させるのに役立っている。これはNTNにとって重要な欠落機能であり、手の届きやすい成果である。
NR NTN less than 5 MHz

背景:

  • 初期のNR NTN展開では、既存の非3GPP衛星サービスと共存する必要がある。
  • さらに、衛星はまだ電力が制限されており、主にEIRP制限される。
  • 必要な最小帯域幅を削減することで、既存のサービスを中心とした初期のNR NTN展開、EIRP制限のある衛星資産のサポート、周波数リソース管理と再利用の容易化が可能になる。

提案:

  • NR NTNバンドn255、n256、n254、および今後のExtended L-band [n253]に対して、12および15 PRBの動作と新しい3 MHz NRチャネル帯域幅のサポートを指定する。
  • 12 PRBと15 PRBのサポートには、3 MHzより大きいシステム/チャネル帯域幅での展開を含める必要がある。
  • 最低限、PSS/SSS と PBCHへのパンクチャに影響を与えることなく、12 PRBまでのサポートの既存のTN仮定を再利用する。
  • パンクチャによって最大5 dBのPBCHリンクバジェット損失が特定されている。
  • NTNのリンクバジェット損失を明確にし、PBCHのパフォーマンス損失を回復するための技術を検討する。
  • 特定の物理レイヤチャネル(PSS/SSSへの影響なし)については、さらなる削減が可能かどうかを検討する。
HPUE support for NR NTN

背景:

  • 現在のNTNシステムでは、特に現実的なアンテナゲイン仮定(例:-5.5 dBiゲイン)を考慮すると、ULでのカバレッジとキャパシティの両方に課題がある。
  • カバレッジを改善するための現在のソリューションは、主に繰り返しに基づいており、システムの容量に深刻な影響を与える。
  • この問題はRAN#97とその後のRAN#99で提起され、Rel-19に先送りされた。
  • 衛星UE送信規制では、ハンドヘルド型端末(例:衛星電話)の送信電力を最大15 dBWまで、非ハンドヘルド型端末の送信電力をさらに高く許可している。3GPPは、現在の衛星規制の枠組み内で許可されているものとより良く一致させるべきである。
  • この機能がないと、今後のNR NTN展開における多くのユースケースが大幅に制限される。

目的:

  • 参照NTNバンドn255、n256、n254、および今後のExtended L-band [n253]を考慮して以下を行う。
    • NR NTN UEの場合:スマートフォンのフォームファクタにPC2(+26 dBm)を指定し、少なくともスマートフォン以外のフォームファクタにPC1.5(+29 dBm)とPC1(+31 dBm)を指定する。
    • 必要に応じて、スマートフォンアプリケーションの比吸収率(SAR)を制御するためのデューティサイクルに関する側面を検討する。
HPUE support for IoT NTN

背景:

  • 現在のNTNシステムでは、特に現実的なアンテナゲイン仮定(例:-5.5 dBiゲイン)を考慮すると、ULでのカバレッジとキャパシティの両方に課題がある。
  • カバレッジを改善するための現在のソリューションは、主に繰り返しに基づいており、システムの容量に深刻な影響を与える。
  • この問題はRAN#97とその後のRAN#99で提起され、Rel-19に先送りされた。
  • 衛星UE送信規制では、ハンドヘルド型端末(例:衛星電話)の送信電力を最大15 dBWまで、非ハンドヘルド型端末の送信電力をさらに高く許可している。3GPPは、現在の衛星規制の枠組み内で許可されているものとより良く一致させるべきである。
  • この機能がないことは、NB-IoTから始まっている現在のNTN展開とユースケースを大幅に制限している。

目的:

  • 参照NTNバンド255、256、254、253を考慮して以下を行う。
    • eMTC IoT NTN UE(Cat M1)の場合:スマートフォンのフォームファクタにUE Power class 2(+26 dBm)のサポートを指定し、少なくともスマートフォン以外のフォームファクタに Power class 1.5(+29 dBm)UE Power class 1(+31 dBm)を指定する。
    • NB-IoT NTN UE(Cat NB1、NB2)の場合:MOPが+26 dBmの新しいUEパワークラスのサポートと、MOPが+31 dBmの新しいパワークラスを指定する。
    • 必要に応じて、スマートフォンアプリケーション(NB-IoTがスマートフォンで使用される可能性がある)の比吸収率(SAR)を制御するためのデューティサイクルに関する側面を検討する。
In-Band NB-IoT NTN with NR same SAN

背景:

  • 現在、地上ネットワークではRel-16以降、5G NRキャリア内でのNB-IoTの展開がすでにサポートされており、スペクトル使用効率と展開の柔軟性を大幅に向上させるのに役立っている。NTN NB-IoTの成長をサポートするには、NTN-NR運用でのネットワーク展開をさらに改善し、奨励する必要がある。
  • これはNTNにとって重要な欠落機能であり、手の届きやすい成果である。

目的:

  • NRガードバンドでのNB-IoT運用では、これを帯域内展開と同様に扱うTR 37.824の結論を再利用することがベースライン仮定である。RF要件は規定されない。
  • NB-IoT対NRの共存仮定(TR 37.824)に変更はない。
  • RAN4#110アテネ会合ですでに議論された。
NTN-NTN Intra-SAN Carrier Aggregation (CA)

背景:

  • LバンドとSバンドの間では、NR NTNに利用可能なスペクトルが比較的大量になると予想されるが、少なくともサービス寿命の初期段階では、スペクトルの異なるブロックが必ずしも連続しているとは限らない。
  • NTNオペレーターは、LバンドとSバンドの両方のスペクトルブロック(例:n256とn255)にアクセスできる可能性があり、同じSANから展開できる。スペクトルバンドを組み合わせると、ユーザー体験スループットが大幅に向上する可能性がある。
  • NR NTNリンクバジェットは、特にハンドヘルドUEからのULで非常に困難である。同じUE内の異なるPA(同じバンドまたは異なるバンド)へのUL CCの割り当ては、利用可能な帯域幅と結果として得られるULユーザースループットを大幅に改善する可能性がある。

目的:

  • NTN-NTNのSAN内キャリアアグリゲーション(CA)をサポートするために必要な要件を特定し、必要に応じて指定する。これには、バンド内およびバンド間の両方が含まれ、最初はバンドn255とn256に重点を置く。
  • DLとULの両方のCAをサポートする必要がある。ULは、UE上で2つのTX PAを独立して活用する。
  • 優先的に考慮すべきCA組み合わせは以下の通り(UL CAの組み合わせを含めて指定される)。
    1. バンド内非連続(DLとUL)
      • CA_n255(2A)
      • CA_n256(2A)
    2. バンド間(DLとUL)
      • CA_n255A-n256A
      • CA_n256A-n255A
Support for fragmented spectrum

背景:

  • 現在のNTNスペクトルバンドは、多くの場合、すでに何らかのレガシーサービスをホストしている(程度は異なる)。
  • NTNで利用可能な潜在的なスペクトルの合計は非常に大きいが、一部のレガシーサービスによって中断される可能性がある。
  • 完全なNRチャネル帯域幅よりもわずかに小さいチャンクが利用可能な場合があり、親チャネルと集約するのが最善の方法となる。
  • NTNオペレーターは、より広いNRシステム帯域幅を指定し、既存のレガシーサービスを中心にシグナリングとユーザーデータをスケジュールできるが、現在のところ、これは主に実装に任されており、この動作モードを容易にする明示的なメカニズムはない。
  • 断片化されたスペクトルのNTNシナリオはTNとは異なるが、TNとNTNの両方に利益をもたらす多くの共通点と作業がある。

目的:

  • 単一の広いコンポーネントキャリアを介した、より広い周波数帯域全体での断片化されたスペクトルブロックのスペクトル利用を容易にするために必要な拡張機能を検討する。ここでは、NTNまたは他のレガシーサービス用の他の割り当てによって周波数割り当てが中断される可能性がある。
  • 最小NRチャネル帯域幅よりも小さい可能性のあるスペクトルブロックを、他の割り当てられたチャネルとグループ化することを含める。
  • 断片化されたスペクトルの使用に関するNTNシナリオは、断片化されたスペクトルの使用の改善に関するTNの研究と組み合わせることができる。