🛰️

3GPP NTN(非地上ネットワーク) 仕様解説

2022/09/08に公開

3gpp

ntn

tech

1 Introduction

この記事は、3GPP Release-17で策定されたNTN(Non-Terrestrial Network)の仕様について解説するものです。恐らく日本語で読める唯一の3GPP NTN仕様解説の記事かと思います。
3GPPでは5Gの初期リリースであるRelease-15から地上系ネットワークと衛星ネットワークの統合の重要性が認識されており、Release-17でNTNの初期フェーズの仕様が確定した。現在も、Release-18でフェーズ2、Release-18でフェーズ3の検討が継続して行われている。
標準化活動は、RAN(Radio Access Network - 無線アクセスネットワーク)、SA（Service & System Aspect - サービスとシステムアーキテクチャ）、CT（Core Network & Terminal - コアネットワークと端末）のTSG（Technical Specification Group - 技術仕様グループ）にわたり、複数のNTN関係のSI（Study Item - スタディアイテム）とWI（Work Item - ワークアイテム）が立ち上げられ、それぞれ研究及び仕様の標準化活動が行われてきた。
下図には、3GPP RAN/SA/CTにおけるNTN関係のSI及びWIを示している。なお、SIの目的は課題提起と解決策の検討であり、技術仕様の策定までは含まれないことに注意されたい。技術仕様の策定は通常SIでの検討結果を用いてWIの活動の中で行われる。

この記事では、Release-17までの検討で合意された技術仕様の概要に焦点を当てるため、上図で赤字ハイライトした2つのWIをRANパート、SAパートとして解説の対象としている。

RANパート：Solutions for NR to support non-terrestrial networks (NTN), NR_NTN_solutions, 860046, Rel-17, RP-210908
SAパート：(Stage 2 of) Integration of satellite components in the 5G architecture, 5GSAT_ARCH, 860005, Rel-17, S2, SP-191335

Abbreviation

本記事で利用される略語は3GPPに準拠する。以下は3GPPで定義されていないかもしれないが私がNTNの文脈でよく使う略語を列挙する。

BH: Backhaul
DA: Direct Access

2 RAN Part

RANの各WGで影響のあった仕様書、または新規に作成された仕様書の一覧を下に示す。本解説記事はこれらの仕様に基づいているが、仕様を規定した背景の解説のため、TR 38.821などの技術レポートも一部参照している。

RAN1
[1] TS 38.211 NR; Physical channels and modulation
[2] TS 38.213 NR; Physical layer procedures for control
[3] TS 38.214 NR; Physical layer procedures for data

RAN2
[4] TS 38.300 NR; Overall description; Stage-2:
[5] TS 38.304 NR; User Equipment (UE) procedures in idle mode and in RRC Inactive state
[6] TS 38.306 NR; User Equipment (UE) radio access capabilities
[7] TS 38.321 NR; Medium Access Control (MAC) protocol specification
[8] TS 38.322 NR; Radio Link Control (RLC) protocol specification
[9] TS 38.323 NR; Packet Data Convergence Protocol (PDCP) specification
[10] TS 38.331 NR; Radio Resource Control (RRC); Protocol specification

RAN3
[11] TS 38.401 NG-RAN; Architecture description
[12] TS 38.410 NG-RAN; NG general aspects and principles
[13] TS 38.413 NG-RAN; NG Application Protocol (NGAP)
[14] TS 38.423 NG-RAN; NG-RAN; Xn Application Protocol (XnAP)

RAN4
[15] TS 38.101-5 NR; User Equipment (UE) radio transmission and reception, part 5: Satellite access Radio Frequency (RF) and performance requirements
[16] TS 38.108 NR; Satellite Access Node radio transmission and reception
[17] TS 38.133 NR; Requirements for support of radio resource management
[18] TR 38.863 Non-terrestrial networks (NTN)related RF and co-existence aspects

[19] R2-2207097 Draft Summary for NR support for Non-Terrestrial Networks (NTN)
[20] TR 21.917 Summary of Rel-17 Work Items(Release 17)

2.1 Overall architecture

下図に示すように、NTNアクセスは、NTNペイロード、すなわち衛星に搭載されたネットワークノードと、フィーダーリンクによって相互接続された NTN ゲートウェイによって提供さる。UE はサービスリンクを介してNTNペイロードからNTNネットワークサービスにアクセスする。

TS 38.300 Figure 16.14.1-1

NTNペイロードを搭載する機体は衛星または航空機の使用が想定される。

衛星：GSO(Geosynchronous Orbit)衛星およびNGSO(Non Geosynchronous Orbit)衛星。
航空機：高高度プラットフォーム(High Altitude Platform)：高度8〜50kmで準定常的に運用される無人航空機

GSO衛星には、GEO(Geostationary Earth Orbit)衛星が含まれる。GEO、つまり静止軌道は、赤道上空の高度約36,000キロメートルの円軌道を周回する軌道であり、衛星の公転周期が地球の自転周期と一致するため、地上から見ると常に静止しているように見える。GEO衛星は静止衛星と呼ばれる。
NGSO衛星には、LEO(Low Earth Orbit)衛星とMEO(Medium Earth Orbit)衛星が含まれる。LEOは高度約300km~1500kmの低軌道であり、MEOは高度約7000~25000kmの中軌道である。StarlinkやOneWebなどの通信衛星はLEO衛星である。
GEOやLEOは本来は「軌道」を示す用語であるが、衛星業界では簡略化のためGEO衛星やLEO衛星のことを単にGEOやLEOを呼ぶこともあるため注意されたい。

参考として、TR 38.821に整理されているNTNプラットフォーム（NTNのペイロードを搭載する機体）の種類を示す。

リリース17でのNTNペイロードは、UEからサービスリンクを介して受信した無線プロトコルをNTNゲートウェイにフィーダリンクを介してへ透過転送する（逆方向も同様に透過転送する）。gNBは複数のNTNペイロードに対応し、NTNペイロードは複数のgNBによって提供されることもできる。

TR 38.821でのNTNアーキテクチャにおいては、NTNペイロードには透過中継型（Transparent）と再生中継型（Regenerative）の２つが検討されたが、リリース17での仕様では透過中継型のみサポートされることになった。再生中継型のサポート時期は現時点では不明であるが、リリース18か将来のリリースでサポートされる可能性がある。参考として、TR 38.821での透過中継型と再生中継型のアーキテクチャ図を下に示す。

透過中継型衛星アーキテクチャ

再生中継型衛星アーキテクチャ

サービスリンクは以下の３種類がサポートされている。

地球固定(Earth-fixed)：常に同じ地域をカバーするビームによって提供される（例：GSO衛星の場合）。
準地球固定(Quasi-Earth-fixed)：ある期間はある地域を、別の期間は別の地域をカバーするビームによって提供される（例えば、ステアラブルビームを生成するNGSO衛星の場合）。
地球移動型(Earth-moving)：地表を移動するビームを提供（固定ビームや非ステアラブルビームのNGSO衛星の場合）。

衛星観点では、サービスリンクは以下のように整理できる。

GSO衛星：地球固定(Earth-fixed)
NGSO衛星：準地球固定(Quasi-Earth-fixed)、地球移動型(Earth-moving)

2.2 Timing, Synchronization and HARQ enhancements（RAN1）

地上5Gでの伝搬遅延(propagation delay)は通常1msと小さい。対して、NTNではサービスリンクとフィーダリンクでの伝搬遅延とドップラー効果が地上ネットワークと比較して格段に大きくなるため既存のタイミングアドバンス(Timing Advance - TA)、同期、HARQを適用することができない。そのため、これらのメカニズムの多くが修正されている。

以下はNR物理レイヤーの解説として、参考となる記事、論文のリンクです。
5GにおけるNR物理レイヤ仕様, NTT DOCOMOテクニカル・ジャーナル Vol. 26 No. 3（Nov. 2018）
Synchronization Procedure in 5G NR Systems, IEEE Access

Timing Advance and Doppler shipt compensation

NTNにおける大きな伝搬遅延に対処するため、共通TA(Common Timing Advance)と2つのスケジューリングオフセットK_offsetとk_macが機能拡張された。

NRにおけるgNBとUEの送信タイミングの制御では、gNB(DL)は全てのgNBが同一のタイミングで送信し、UEが送信する信号をgNBの送信と同じタイミングで受信するように、UEはDL受信タイミングからTAを前倒したタイミングにUL送信する。TS 38.211 図4.3.1-1がその関係をしめしている。

TAはUEとgNB間の伝搬遅延の2倍となる。NTNでは大きな伝搬遅延のためDLとULのフレームタイミングの差が非常に大きくなり、また大きいTAの値が必要となる。この関係はTR 38.821の下図のように示される。

下図に示すように共通TA、K_offset、k_macは以下のように定義されている。

共通TA：参照点とNTNペイロード間のRRTに対応するオフセット "a configured offset that corresponds to the RTT between the Reference Point (RP) and the NTN payload"
K_offset：サービスリンクRTTと共通TAの和に対応するオフセット "a configured scheduling offset that approximately corresponds to the sum of the service link RTT and the common TA"
k_mac：参照点とgNB間のRTTに対応するオフセット "a configured offset that approximately corresponds to the RTT between the RP and the gNB"

DUとULフレームはUL時間同期(uplink time synchronization)参照点(RP - Reference Point)で整合する。

ネットワークは、各NTNセルで衛星エフェメリス情報と共通TAパラメータをSIB19で報知する。SIB19は衛星関連情報の報知のため新規追加されたSIBであり後で解説する。Release-17のNTN対応UEは全てGNSSをサポートしていることを前提としているため、NTNセルに接続する前に有効なGNSS位置情報と衛星エフェメリスおよび共通TAを取得する。アップリンクの同期を実現するために、UE はランダム・アクセスの前に、衛星エフェメリスを通じて共通TA、UE の位置、衛星の位置および速度を考慮し、同様にTAを自律的に事前補正する。周波数ドップラーシフトも同様に自立補正がなされる。
Connectedモードでは、UEはTiming Advanceとドップラーシフト補正を継続的に更新する。UEは、タイマーに基づき衛星エフェメリスの情報が古いと判断した場合は送信を実行しない。UEは、初期アクセス時またはConnectedモード時にTiming Advanceを報告するように指示することができる。Connectedモードでは、Timing Advanceのトリガーによる報告がサポートされる。

サービスリンクで発生する瞬間的なドップラーシフトの事前補正は、アップリンクではUEが実行するが、フィーダーリンクで発生するドップラーシフトの管理はネットワークの実装依存とされている。

HARQ

NTNにおけるHARQのストール(stall - 詰まり)の影響を軽減するために、RLC層におけるARQ再送信の存在下でHARQフィードバックを無効にすることができるようになった。さらに、MAC層における再送信のためのHARQプロセスの数を32まで増加させることができるようになった。

2.3 Mobility Management (RAN2)

UEはNTNと地上ネットワーク間のモビリティ（NTN から地上ネットワーク（ハンドイン）、地上ネットワークから NTN（ハンドアウト））をサポートする。NTNと地上ネットワークの両方に同時に接続する必要はない。また、異なる軌道（高度が異なるGSO、NGSO）に基づく無線アクセス技術間の移動もサポートすることができる。
NTNでのモビリティを可能にするため、ネットワークはハンドオーバーコマンドでターゲットとなるNTNセルへのアクセスに必要なサービングセルと隣接セルの衛星エフェメリスを提供する。
UE が候補セルへの条件付きハンドオーバ（Conditional Handover - CHO）を実行するためのトリガ条件として、時間ベースのトリガ条件（time-based trigger condition）、位置ベースのトリガ条件（location-based trigger condition）が導入された。最後の2つの条件は、測定に基づくトリガ条件（measurement-based trigger conditions）の 1 つと一緒に設定される。

ここで、CHOについて補足しておく。Release-15でのハンドオーバーではハンドオーバーの実行はgNBの判断に基づき、gNBはUEにハンドオーバーコマンドを送信し、UEは即座にハンドオーバーを開始しなければならなかった。ハンドオーバーの成功率を上げるために、Release-16では特定の条件が満たされた場合にUEがハンドオーバーを実行するか決める条件付きハンドオーバ（Conditional Handover - CHO）が導入された。CHOではターゲットセル毎に最大2つの実行条件を設定することができる。上記のように、NTNでのモビリティでは、測定に基づくトリガ条件は必ず用いられ、それに加えて時間ベースのトリガ条件と位置ベースのトリガ条件の何れかを用いることが可能である。

地上ネットワークで利用されているトリガ条件が不十分な理由は下図(TR 38.821)から説明できる。

地上ネットワークでは、セルの中心部と比較してセルのエッジではRSRP が顕著に低下するため、UE はセルのエッジ近傍にいると判断できる。この現象は、NTNではそれほど顕著ではなくセルの中心部とエッジでRSRPで有意な差が見られない場合がある。つまり、2つのセルでオーバーラップしている領域で2つのビームの信号強度にわずかしか差が生じない場合がある。そのため、既存のハンドオーバートリガであの測定イベント（A3 Eventなど、TS 38.331や記事を参照）では、UEはより良いセルを区別することが困難になる。その結果、セル間でUE ping-pong現象が発生しハンドオーバーのロバスト性を低下させる原因となってしまう。そこで、時間ベースのトリガ条件と位置ベースのトリガ条件が新たに追加された。

これらのCHOのトリガは、TR 38.821 7.3.2.2.2に以下のような説明がある。

測定に基づくトリガー（measurement-based trigger）：A4 Eventなどがベースラインとして使用される。例えば、NTN ではセル中心部とセル端部で測定されるセル品質のばらつきが小さいため、トリガーの閾値やどの測定イベントをトリガーとして使用するかは、NTN 環境を考慮した設定にする必要がある。
時間ベースのトリガ（time-based trigger）：ある地域がサービスを受ける時間を考慮したトリガ条件。独立または別のトリガ（測定ベースなど）と一緒に考慮することができる。UTC 時間に基づくか、またはタイマーベースのソリューションである。LEOシナリオにおける時間ベースのCHOは、決定論的な衛星の動き(deterministic satellite movement)を考慮する。
位置情報（UE および衛星）トリガ（location-based trigger）：UE および衛星の位置に基づく追加のトリガ条件。独立または別のトリガ（測定ベースなど）と一緒に考慮することができる。LEOシナリオにおける位置ベースのCHOは、決定論的な衛星移動を考慮する必要がある。例えば位置トリガー条件は、UEと衛星の間の距離として表現されることができる。
これら条件付きハンドオーバに必要となる衛星エフェメリスや閾値などはSIB19で報知されることとなった。

Multiple SMTC
LTEでは全基地局・全セルにおいて参照信号（CRS）が常時送信されていたため、UEは他セルの受信品質を容易に測定できていた。一方、5G NRではオーバーヘッド削減や他セル干渉低減のため、CRSのような常時送信される参照信号はなくしている。そのため、同期に用いられるSSB(SS/PBCH Block)を流用して他セルの測定も行うようになった。この際に、UEが測定に用いるSSBの測定周期やタイミングをセルからUEに通知する機能であるSMTC(SSB based RRM Measurement Timing Configuration)がRel-15から導入されている。

NTNにおいては、TNと異なり、衛星が異なると伝搬遅延差が大きく変化する可能性があり、既存のSMTCだけでは、SSBの測定ウィンドウを見逃してしまう課題があった。具体的には次のようなケースである。LEO衛星S1によってサービスを受けるUEが、新たに到来するLEO衛星S2のカバレッジ内にある場合で、UEは、UEに提供された測定設定に基づいて、モビリティのためにS2から発信される近隣セルの測定を実行する必要があるが、UEから衛星S1およびUEから衛星S2への伝搬遅延差は大きく変化する可能性がある。伝搬遅延差を考慮しない場合、UEはSSB測定ウィンドウを見逃す可能性があり、測定を行うことができなくなる。
この課題の解決策として、ネットワークは、伝搬遅延差とエフェメリス情報を使用して、キャリアごとに、また UEの能力に応じて所定のセルセットに対して、複数のSMTC(SS/PBCH Block Measurement Timing Configuration)を並行して構成することができるようになった。また、複数のSMTCに基づく測定ギャップを設定することも可能としている。

The network can configure:
- multiple SMTCs in parallel per carrier and for a given set of cells depending on UE capabilities using propagation delay difference calculated by UE;
- measurement gaps based on multiple SMTCs.

SMTCの調整は、CONNECTEDモードではUEアシステンス情報に基づきNW制御で可能であり、IDLE/INACTIVEモードではUE位置と衛星アシスタンス情報（エフェメリス、共通TAパラメータなど）に基づきUE制御で可能である。

準地球固定(quasi-earth fixed )セルシナリオでは、UEはRRC_IDLE/RRC_INACTIVEで時間ベースおよび位置ベースの測定を実行することができる。セルに関連するタイミング情報および位置情報は、システム情報（SIB19）で提供される。これらはそれぞれ、サービングセルが地理的なエリアへのサービスを停止する時刻（t-Service）と、サービングセルの基準位置（referenceLocation）を参照する。まとめると以下のような関係になります。

時間ベースの測位：サービングセルが地理的なエリアへのサービスを停止する時刻（t-Service）を参照
位置ベースの測位：サービングセルの基準位置（referenceLocation）を参照

トラッキングエリア(Tracking Area - TA)は、固定された地理的なエリアに対応する。

ネットワークは、特に地球移動セルカバレッジのために、セルのエッジでの信号負荷を低減するために、NR NTNセル内のPLMNごとに複数のTAC(Tracking Area Code)を報知することができる。SIBにおけるTACの変更はネットワークにより行われる。
下図は、TS 38.821 Figure 8.2.2-3では欧州の国ごとにTAを割り当てて、１つの衛星のビームが複数の国に跨るケースを示している。

UEの位置情報については、ネットワークの要求に応じて、ConnectedモードでASセキュリティが確立された後、UEは自身の粗い（coarse）UE位置情報（精度約 2km の粗い GNSS 座標）をNG-RAN に報告することができる。UEが粗いUE位置情報を提供できない場合、"no coarse GNSS location available"を報告する。

Network-assistance information for UE measurement and mobility

UEと異なる衛星に属するセルとは、タイミングやドップラーシフトの観点から時間的に変化する性質があるため、UEは近隣セルの測定前にセル検出を繰り返し行う必要がある場合がある。（一方、地上システムでは一度セルが検出されれば測定のためにセル検出を繰り返し行う必要はない。）UE の実装の影響と消費電力を低減するために、測定(measurement)用の情報セットがネットワークから提供されることが望ましい。同様に、UEが現在の衛星と異なる衛星内のセルにハンドオーバーを実行する場合、現在のサービングセルを介して、モビリティ用の情報セットがネットワークからUEに提供されることが望ましい。このような背景からそれぞれの用途に対して以下の情報セットが提供されるようになった。

近隣セル測定の補助に用いられる情報セット
- Ephemeris
- Epoch time
- Feeder link propagation delay
- Validity timers
- Downlink polarization information
モビリティ（ハンドオーバー）の補助に用いられる情報セット
- Ephemeris
- Epoch time
- Feeder link propagation delay
- Validity timer
- Downlink and uplink polarization
- K_offset
- K_mac

SIB19

これまで見てきたように、UEに対してはネットワークから様々なNTN関連情報を提供する必要がある。この情報を報知するためSIB19が新たに規定されている。SIBはTS 38.331で規定されSIB19で追加された各フィールドは以下の通りである。

distanceThresh: サービングセル基準位置からの距離であり、RRC_IDLEおよびRRC_INACTIVEにおける位置ベースの測定開始で使用されるものである。各ステップは50mを表す。
ntn-Config: エフェメリスデータ、共通TAパラメータ、k_offset、UL同期情報の有効期間、エポックなど、UEがNTNアクセスによりNRにアクセスするために必要なパラメータを提供する。有効期間（ntn-UlSyncValidityDuration）は、必須で存在する。
ntn-NeighCellConfigList: ntn-Config、キャリア周波数、PhysCellIdを含むNTNネイバーセルのリストを提供する。maxCellNTN-r17(=4)がRel-17で設定できる最大数となる。
referenceLocation: RRC_IDLEとRRC_INACTIVEにおけるロケーションベースの測定開始で使用される。
t-Service: NTN 準地球固定システムを介して提供されるセルが、現在カバーしているエリアでのサービスを停止する時刻情報を示す。グレゴリオ暦より 10ms 単位で経過した時刻を表す。このフィールドは、システム情報の変更を判断する際に除外される。すなわち、t-Service を変更しても、システム情報の変更通知や SIB1 の valueTag が変更されることはないはずである。正確な停止時刻は、本フィールドの値から 1 を引いた時刻と本フィールドの値で示される時刻の間とする。

例えば、ntn-Configには以下のようなパラメータが含まれている。

ntn-Configの中のEphemerisInfoには以下のようなパラメータが含まれている。

以下はTR 38.821に記載されている必須エフェメリスパラメータを図示したものである。

各フィールドの詳細についてはTS 38.331を参照されたい。

2.3a UE radio access capability

TS 38.306ではNRにおいてUEの無線アクセス能力のパラメータを定義している。このパラメータはRRCメッセージに格納されUEからgNBに送信される。Release-17ではNTNの能力を示すための各種パラメータが拡張された。
TS 38.306 4.2.2より抜粋

nonTerrestrialNetwork-r17: Indicates whether the UE supports NR NTN access. If the UE indicates this capability the UE shall support the following NTN essential features, i.e., timer extension in MAC/RLC/PDCP layers and RACH adaptation to handle long RTT, acquiring NTN specific SIB and more than one TAC per PLMN broadcast in one cell.（NTNの基本機能のサポートを示す）
ntn-ScenarioSupport-r17: Indicates whether the UE supports the NTN features in GSO scenario or NGSO scenario. If a UE does not include this field but includes nonTerrestrialNetwork-r17, the UE supports the NTN features for both GSO and NGSO scenarios, and also supports mobility between GSO and NGSO scenarios. (サポートする衛星軌道シナリオ（GSOかNGSOか）を通知できる)

TS 38.331 (RRC)の6.3.3 UE Capability information elementsのUE-NR-Capabilityから以下のように確認できる。

位置ベースと時間ベースのCHOの能力を示すパラメータとしてlocationBasedCondHandover-r17とtimeBasedCondHandover-r17も追加されている。

2.4 Switch-over (RAN3)

フィーダリンクのスイッチオーバーは、特定のNTNペイロードのためにフィーダリンクがソースNTNゲートウェイからターゲットNTNゲートウェイに変更される手順である。下図（TR 38.821 Figure 8.7.1.1-1）に示すように、LEOのような移動する衛星においては、フィーダーリンクのスイッチオーバーは必須の手順になる。NTNアーキテクチャの観点から、スイッチオーバーの前後でゲートウェイに接続されているgNBが異なるか同一かによりオプションが分かれるが下図ではgNBが異なるオプションについて図示している。

もし、NTNペイロードが単一のフィーダーリンクのみにサービングされている場合、GW1経由のgNB1と接続している全てのUEのRRCコネクションが切断されてしまう。GW2経由のgNB2と接続が回復してからUEは初期アクセスからやり直す必要がある。これはハードフィーダーリンクスイッチオーバーと呼ばれ、NTNペイロードが同時に1つのGWにしか接続出来ない時に発生する。NTNの研究段階において(TR 38.821 8.7.1)は、ハードフィーダーリンクスイッチオーバーを回避してサービス継続性(Service Continuity)を確保するための解決策として、ソフトフィーダーリンクスイッチオーバーが提案された。この方式では、NTNペイロードは同時に2つ以上のNTNゲートウェイとの接続を可能としてフィーダーリンク間の移行をシームレスに提供することを可能とする。NTN仕様化においては、ハードとソフトの両方がNTNに適用可能となった(TR 38.300 16.14.4)。
下図はソフトフィーダーリンクスイッチオーバーの挙動を表している。時刻T1.5はフィーダーリンクの切り替え期間であり、一時的にGW1とGW2の両方に接続している。GW1とGW2の両方のgNBから生成されるセルにカバーされるため、通常のハンドオーバー手順が適用可能となる。

TS 38.300 16.14.4.3のスイッチオーバーの動作手順の仕様では、NTN制御機能(NTN Control Function)のスイッチオーバーでの役割が説明されている。Annex B.4(Example implementation of Non-Terrestrial Networks)において、NTN制御機能は、NTNインフラストラクチャ（NTNペイロードとNTNゲートウェイ）の無線リソースと同様に、衛星を制御し、NTN以外のgNB機能に対して、エフェメリスなどの制御データを提供するとある。スイッチオーバーにおいては、このNTN制御機能が2つのgNB間でフィーダリンクの切り替えが実行される時点を決定する。フィーダリンクの切り替え時にはハンドオーバーが発生するため、影響を受けるUEのコンテキストの2つのgNB間でのコンテキスト転送が必要となる。ハンドオーバーは、NGベースまたはXnベースで実行される。NTN制御機能によってgNBに設定情報が提供されるが、この方法は実装依存としている。

2.5 NG-RAN signalling (RAN3)

Cell ID

地上ネットワークでは基地局が固定されている前提によりセルがカバーする範囲も固定されると扱ってよく、gNBからコアネットワークに通知されるUEが在圏するセルIDはULI(User Location Information)の一部として扱うことができていた。一方、NTNではNTNペイロードは常に移動する可能性があるため、地上ネットワークのセルの原則を適用するには、特定の地理に対してマッピングされたセルIDを使用する必要がある。そこで、RAN3ではMapped Cell IDが導入された。
Mapped Cell IDは、NTNペイロードの軌道やサービスリンクの種類に無関係に、特定地域を示すIDとして使用される。そのため、ULIの一部として使用してコアネットワークに通知し、ページングの最適化、AoI(Area of Interest)、PWS(Public Warning Safety)などに使用することができる。また、ハンドオーバーの際には、Mapped Cell IDはUEの位置情報の把握によりターゲットセルの選択に利用することができる。Cell IDと地理エリアとのマッピングはRANとコアネットワークに設定されておく必要がある。

Mapped Cell IDのマッピングは、事前に設定することもあれば（オペレータのポリシーによる）、実装によって設定、変更される場合もあります。例えば、gNBは、UEから受信したUE位置情報(GNSS?)がある場合、それに基づいてMapped Cell IDを作成、更新することもできる。

TAI (Tracking Area Identity)

上述したように、トラッキングエリア(Tracking Area - TA)は、固定された地理的なエリアに対応する。NTNセル内のPLMNごとに複数のTAC(Tracking Area Code)を報知することができる。

NGAPでは、NR NTN TAI Information IEが追加され、gNBは、報知されたTAC（複数可）をNR NTN TAI Informationに格納し以下のようにULIの一部としてAMFに報告する。なお、上述したMapped Cell IDはNR CGI(Cell Global Identity)として格納される。

このNR NTN TAI Information IEにおいて、特定セルで報知した複数TACはTAC List In NR NTN IEに格納される。

User Location Information IEは、NAS Transport MessageのInitial UE MessageやUplink NAS Transportで設定が必須となっている。また以下のように、Location Reportでの通知にも使用される。

RAT Information

TS 38.413ではRAT情報としてnR-LEO, nR-MEO, nR-GEO, nR-OTHERSATが流通できるように拡張された。RAT情報はTAC毎に設定でき、NG SETUP REQUESTでAMFに通知される。RAT情報はTS 23.501の手順で利用される。SAパートで後述する。

Signalling & Callflow

RAN3の仕様のまとめとして、NGAPのコールフローを作成しました。

2.6 AMF (Re-)Selection by gNB (RAN3)

NTNはセルのカバー範囲が広いことから、NTNペイロードに接続するgNBが複数の国のコアネットワークに接続しコネクティビティを提供するケースがある。国毎にレギュレーションは異なるため、gNBはUEが所在する国のコアネットワークのAMFを選択しなければならない。（38.410 5.7 NAS Node Selection Function）

2.7 O&M Requirements (RAN3)

O&AはNTN関連パラメータをgNBに提供する（2.9.Deployment Scenarioで詳細を記載する）。TS 38.300 16.14.7には必須で提供しなければならないNTN関連パラメータを以下のように整理している。

Ephemeris information for the NTN vehicles.
Two different sets of ephemeris format shall be supported:
- Set 1: Satellite position and velocity state vectors:
  - Position（位置）;
  - Velocity（速度）.
- Set 2: At least the following parameters in orbital parameter ephemeris format, as specified in NIMA TR 8350.2:
  - Semi-major axis（半長径）;
  - Eccentricity（離心率）;
  - Argument of periapsis（近地点引数）;
  - Longitude of ascending node（昇交点黄経）;
  - Inclination（軌道傾斜角）;
  - Mean anomaly（平均近点角） at epoch time（元期） to.
The explicit epoch time associated to ephemeris data;
The location of the NTN-Gateways;
Additional information to enable gNB operation for feeder/service link switch overs.

ここで、衛星のエフェメリスとNTNゲートウェイの位置は、少なくともアップリンクのタイミングと周波数同期のために使用される。また、ランダムアクセスやモビリティ管理の目的でも使用される可能性がある。また、O&MがgNBに提供するNTN関連パラメータは、地球固定ビーム、準地球固定ビーム、地球移動ビームなど、サポートするサービスリンクのタイプに依存する場合がある。

2.8 RF performances and RRM requirements (RAN4)

RAN4では、TR 38.863で行われた検討に基づき、NTNのNRダイレクトアクセスで利用する周波数バンドや、NTNで動作するUEとSAN(Satellite Access Node)に対して最小RF要件とパフォーマンス要件（Minimum RF and Performance requirement）を規定している。TS 38.101-5はUEに対して、TS 38.108はSANに対して規定している。
周波数バンドについては、FR1(Frequency Range 1)に対して、衛星通信で用いられるMSS(Mobile Satellite Service)の周波数帯である、SバンドとLバンドがそれぞれn256、n255として新たに追加された。

SAN(Satellite Access Node) type

TS 38.108では、SANは要件を定義する参照点(Reference point)によりSAN type 1-HとSAN type 1-Oの2つのタイプに分けられている。
SAN type 1-Hは放射特性(Radiated characteristics)と伝導特性(Conducted characteristics)を定義する2つの参照点がある。放射特性はOTA(Over The Air)として定義されRIB(Radiated Interface Boundary)と呼ばれる。伝導特性はTAB(Transceiver Array Boundary)として定義される。

SAN type 1-Oは1つの参照点のみであり、OTA、RIB(Radiated Interface Boundary)で定義される。

Operating Bands

リリース17のNTNでのオペレーションバンドはFR1(410～7125MHz)であり、新たにNTN用にn256とn255が追加された。NTN用のバンドはn256から降順で番号が振られているため、n256から記載している。

UE/SAT Channel Bandwidth

UEとSATのチャネル帯域幅はそれぞれの仕様書（TS 38.101-5、TS 38.108）の5.3節に規定されている。
UEチャネル帯域幅は、UEでのアップリンクまたはダウンリンクで単一のRFキャリアをサポートします。

SANの観点からは、SANに接続されたUEへの送信およびUEからの受信のために、同じスペクトル内で異なるUEチャネル帯域幅がサポートされる場合がある。
UEの観点からは、UEは1つまたは複数のBWP/キャリアで設定され、各々が独自のUEチャネル帯域幅を持つ。
下図にチャネル帯域幅、ガードバンドおよび送信帯域幅設定(Transmission Bandwidth Configuration)の関係を示す。

下図にUEチャネル帯域幅とSCS(Subcarrier Spacing)に対する最大送信帯域幅設定N_RBの関係示す。

下図にUEチャネル帯域幅とSCS(Subcarrier Spacing)に対する最小ガードバンドの関係示す。

RF Requirements

NTN 対応 UE（TS 38.101-5）の RF 要件は、地上波ネットワークで動作するUEと同じRF性能を要求している。これにより、NTN または地上波ネットワークの両方への接続を可能にしている。このRF要件は下記のNTN-TN Coexistenceの分析に基づいている。
TS 38.108 に定義される SAN のRF要件は、TS 38.104 に定義される地上波ネットワークのBS RF要件と比較すると低い。

UE Power ClassはNRキャリアのチャネル幅における最大出力(Maximum output power)を規定している。TS 38.101-5 6.2.1 UE maximum output powerでは、NR satellite bandのn256, n255ではClass 3が適用され23dBmが最大出力であることを規定している。

NTN-TN Coexistence

新たに規定されたn256(MSS Sバンド)は地上n1(FDD)とn34(TDD)に周波数帯が隣接することから、NTNとTNの共存シナリオがTR 38.863で研究されている。下図はn256に隣接する周波数帯である。

n256を利用する場合はn1とn36に影響を与えないように保護しなければならない。

共存シナリオので検討されるパラメータは、送信機要件となるACLR(Adjacent Channel Leakage Ratio)と受信機要件となるACS(Adjacent Channel Selectivity)に基づいて得られる。NTNにおいては、既存システムである地上BSとUEに対して影響を避けることを要件としているため、その制約条件下でSANとNTN UEのRF要件を定義することとなった。
TS 38.863に記載の地上2GHz帯でのACLR/ACS

SANとNTN UEのACLRとACSは、TR 38.863での分析の結果、下表のように合意された。
NTN UEは地上UEと同じACLR/ACS値となっており、これがNTN UEのRF要件となっている。SANのACLR/ACSはGEO/LEOの2つのクラスでそれぞれ規定されている。

Radio Resource Management

NTNにおけるRRM(Radio Resource Management)のための特定の要件は、TS 38.133で定義されている。これらの要件は主に、異なる手順におけるタイミングや周波数エラーと同様に、特定の遅延に関連している。

HAPS

HAPSのRF要件はTS 38.104で、追加変更なしにワイドエリアBSクラスを参照するHAPS BSクラスとして定義されています。また、HAPSの動作には FDDのn1(1920 -1989 MHz (Uplink) / 2110 - 2170 MHz (Downlink))を適用するとしています。

現行の TS 38.101-1 で定義されている NR UE は、TS 38.101-1 に追加変更を加えることなく、HAPSをサポートすることが可能です。

2.9 Deployment Scenario

TS 38.300のAnnex B(informative)- 仕様ではなく参考資料の位置づけ-ではいくつかのデプロイメントシナリオを提示しているが、NTN仕様化に伴い、Annex B.4 Example implementation of Non-Terrestrial Networksが追加された。TS 38.300 Figure 16.14.1-1より具体化されており理解の助けになるため解説する。

上図に示されるgNBは、NTNインフラストラクチャ部とnon-NTNインフラストラクチャ部に分割される。NTNインフラストラクチャ部はNTNペイロード、NTNゲートウェイ、NTN制御機能(NTN Control Function)で構成される。NTNペイロードは人工衛星やHAPSに搭載される。
NTN制御機能は、衛星やHAPSおよびNTNペイロード、NTNゲートウェイの無線リソースを制御する。また、non-NTNインフラストラクチャであるgNB機能対して、衛星軌道であるエフェメリスなど制御に必要なデータを提供する。

NTN制御機能はOAMを経由してgNBにNTN関連パラメータを提供する。少なくとも以下のNTN関連パラメータは、OAMからgNBの運用のため、NTNペイロードによって提供される各ビームに対して以下の情報が提供される必要がある。ビームの分類は上述したサービスリンクの分類と同じである。

地球固定(Earth-fixed)ビーム：
- The Cell identifier (NG and Uu) mapped to the beam
- The Cell's reference location (e.g. cell's center and range)
準地球固定(Quasi-Earth-fixed)ビーム：
- The Cell identifier (NG and Uu) and time window mapped to a beam
- The Cell's/beam's reference location (e.g. cell's center and range)
- The time window of the successive switch overs (feeder link, service link)
- The identifier and time window of all serving satellites and NTN-Gateways
地球移動型(Earth-moving)ビーム：
- The Uu Cell identifier mapped to a beam and mapping information to fixed geographical areas reported on NG, including information about the beams direction and motion of the beam's foot print on Earth
- Its elevation wrt NTN-payload
- Schedule of successive serving NTN-Gateways/gNBs
- Schedule of successive switch overs (feeder link, service link)

Annex NR_NTN_solutions Approved CRs

860046 NR_NTN_solutions

860146 NR_NTN_solutions-Core

860246 NR_NTN_solutions-Perf

なし

Annex NR_NTN_enhancements(Rel-18)

Rel-18ではNR NTNの拡張が検討されている。2023年3月時点ではまだ仕様化は開始されていない。RAN2に関して、Workplan(R2-2210766)によると、4月会合(R2-121-bis)までは議論中心、5月会合(R2-122)では残りの議論とCRの検討開始、8月会合でCR継続して、10月,11月でファイナライズしていく予定。

Coverage Enhancements

以下は検討状況であり仕様ではない。

Network verified UE location

以下は検討状況であり仕様ではない。

TN and NTN-NTN mobility and service continuity enhancements

Cell reselection enhancements

以下は検討状況であり仕様ではない。
RAN2-119bis
Intelの提案(R2-2209578)を元に議論。
地球移動セルでは、NTN-NTNセル再選択が頻繁に必要となるため、パワーセービングの方法が必要。NTNセルの直径が少なくとも50kmであり、典型的なLEO衛星の速度が7.56km/sであることを考慮すると、6.61秒以内にこのセル内のすべてのIdle/Inactive UEをハンドアウトし、キャンプオンしなければならない。(単純に、50/7.56=6.61の計算。かなり頻繁に切り替わるのがわかる。)
もしNTNセルセンター座標とセルカバレッジ半径が分かれば、軌跡の計算ができる。

NTNセルのサービスタイムが分かれば、その間、neighboring cell measurementをしなくてもすむ。下の図で、T0であるセルにキャンプオンして、T1でこのセルからハンドアウトしなければならないことがわかっているならば、T0.9まではこのセルを利用し続ける事ができるので、neighboring cell measurementを停止することができる。

NTNカバレッジは広いため、NTN onlyエリアが広く存在する。NTN onlyエリアでは、TNのneighboring cell measurementをすることは電池の無駄でしかない。

合意事項1

地球移動セルのNTN-NTNセル再選択について、UEにサービングセルのパラメータを提供することを検討する。UEはUE現在位置においてサービングセルがカバレッジを提供するのを停止する時間を推測する。
- このパラメータを使うことで、セル再選択のためUEがいつneighboring cell measurementを開始したら良いかが判断できる。「サービングセルのパラメータ」として「衛星軌道パラメータ（location coordinates of cell center and the radius of cell coverage）」が提案されていたが、エフェメリスとの違いは不明瞭としてパラメータの中身までは合意されていない。個人的に、タイムベースドで用いられるt-Serviceに停止時間は含まれるのでなぜ、新しい方法が必要なのかわかっていない。
NTN-TNセル再選択を拡張するために、UEがNTNネットワーク（地上移動または地上固定）のみでカバーされるエリアとTNネットワーク（複数可）も利用可能なエリアでキャンプする際に区別するための手段が定義される。
- TNの存在により、UEがTNのneighboring cell measurementをする必要があるかを判断できる。つまり、TNがないことが予め分かっていれば、セル再選択のときにneighboring cell measurementをオフにできる。NTNの方がカバーエリアが広いため、TNが存在するときにはNTNも存在するという前提の合意文になっている。
- "Cell type of a neighbour cell, i.e., TN cell or NTN cell"が提案されていたが、定義が不明確として合意はされていない。

"Geographical information"の提供も検討されている。
オプション１：各TNネイバーセルのセル中心と半径を提供する

オプション２：境界線を提供する

合意事項2

システム情報は、サービングセルが現在のUEの位置でカバレッジを提供しなくなるタイミングをUEが推定するのを支援するために必要なパラメータを提供する基本手段である。
UEは、TNネットワークのカバレッジがないエリアにおいて、TNネイバーセルに対するネイバーセル測定を行う必要はない。
UEが現在TNセルでキャンプしているときに、NTNカバレッジを決定するために送信エネルギーまたはSIB存在を検出する方法は追求されない。
- 基本、TNセルにキャンプしているときはNTNにキャンプする必要性がないという理解であっているか？TNセルにキャンプしているが、NTNセルにもデュアル接続してオフロードさせたいときはどうするのか（Rel-19の要件として検討か？）？
地球移動セルでは、サービングセルが現在のUEの位置でカバレッジを提供しなくなるタイミングを推定するために、ネットワークからUEにサービングセルのreference locationとdistance thresholdが提供されます。どのようにUEに提供されるかはFFS。

RAN2-120
R2-2211573 TN neighbour cell measurement relaxation, Qualcomm
TN coverage area: 1つのNTNカバレッジに複数のTNカバレッジがふくまれる。TNカバレッジエリアの情報をSIBで渡すとオーバーヘッドが大きくなってしまう。一つの解決策は、下図のようにNTNカバレッジを分割してそれぞれにTNが含まれるかビットマップで表すこと。
なお、SA2でもカバレッジ情報をUEに渡す検討がされている。つまり、解決策としては共通のものになり得る。

TN neighbor cell relaxation
UEは、必要なときに、すなわち、TNセルカバレッジがあるときでも、TN周波数を検索しないことがある。UEがNTNセルでキャンプしている場合、TN周波数は、現在のNTN周波数の再選択優先順位よりも高い再選択優先順位を持たせる必要があるかもしれない。

合意事項1

RAN2は、まず、TNカバレッジデータの詳細（TNネットワークが利用可能な場所を記述するための精度要件など）およびUEのストレージオーバーヘッドに関する調査を継続し、UEに情報を送信する方法を決定する予定。
周波数間リストおよびRAT間周波数リスト（粒度FFS）からTNセルを特定するための明示的な指示を導入するか、または暗黙の情報に依存するかについて議論を継続する。
- NARFCN情報で、TNと分かるのでは？という意見が出されたが、少なくともHAPSではTNと同じNR band情報を使う可能性があるので議論は引続き行われる事となった。

Handover enhancements

以下は検討状況であり仕様ではない。

R2-2209711

RAN2-119bis
LEOシナリオでは、同一セル内のほぼ全てのUEが、非常に短期間に頻繁にハンドオーバーを行う可能性がある。既存のハンドオーバー・コマンドを採用すると、信号のオーバーヘッドが多くなり、特にハンドオーバー・コマンドはRRCReconfigurationメッセージの形で専用のRRC信号で伝送されるため、これらの信号がバースト的に発生する可能性がある。
解決策の1つの方法は、ハンドオーバコマンドのサイズを小さくすること。例えば、ネットワークは、UEがそのターゲットセルに対してconditionalReconfigurationで構成されている場合に、ハンドオーバコマンドでターゲットセルを単に示すことができる。conditionalReconfigurationは即座に提供する必要がないため、問題を軽減することができる。ターゲットセルのコンフィギュレーションは、事前に設定されたCHOコンフィギュレーションを通じて取得することができる。ターゲットセルのID/indexのみを通知すればいいため、RAN2は、RRCメッセージの代わりにMAC CEオプションを考慮することもできる。
上記の解決策では、各UEにCHOコンフィギュレーションを提供する必要があり、オーバーヘッドは依然として大きい。各UEのCHOコンフィギュレーションまたはハンドオーバー・コマンドの間にSIBに入れることができる共通情報（t304やspCellConfigCommonなど）があれば、結果としてRRCメッセージのサイズが縮小される。

HO interruption time enhancement: RAN#95eでは、DAPS HOでNTN HO interruption timeを改善する提案があったがRel-18 NTNではサポートされない。そのため、RACHレスHOの検討をする。ハンドオーバー中のRACHスキップは、有効なタイマーが切れてSIB19を再取得した後にRACHをスキップする（またはRACHをトリガーしない）ケースと似ている。両方のケースに共通するのは、UEが再取得した衛星エフェメリスと共通TAを使用して、その後のUL送信のための実際のTA（RAN1定義のTTA式に従う）を計算できる点です。したがって、RACH-less HOはNTNで実現可能を考えられる。
RACHレスが実現可能かどうかは、シナリオによるとの見解が示された。intra-satelliteでは共通TAは同じだが、inter-satelliteでは共通TAが異なるだろう。RAN1へLSを送る。

合意事項1

RAN2は、すべてのUEに共通することができるハンドオーバーコマンドの一部の情報を、共通のシグナリングでUEに配信することができるかどうか、また、これによって（シグナリングのオーバーヘッドの削減という点で）実際に利点があるかどうかをさらに検討する。
- これはグループHOのことを指している。衛星切り替え時にはサービングセルに接続しているすべてのConnected UEがHOする必要が有る。HOコマンドを共通化することでシグナリングを大きく減らすことができる。
- 「CHOの再利用」の議論がされているが、関係性を理解できずにいる。
シナリオ（衛星内、衛星間、同一または異なるフィーダーリンク）を列挙した LS を RAN1 に送信し（cc RAN4）、どのシナリオで RACH レスが可能かを RAN1 に確認する（RAN2 の優先順位は示さず）。

合意事項2

グループHO、 “UE specific pre-configuration of the target cell + group HO”は継続議論とする。

合意事項3

3 SA Part

RANの各WGで影響のあった仕様書、または新規に作成された仕様書の一覧を下に示す。本解説記事はこれらの仕様に基づいているが、仕様を規定した背景の解説のため、TR 23.737などの技術レポートも一部参照している。

SA1
[1] TS 22.261 Service requirements for the 5G system; Stage 1
[2] TR 22.822 Study on using Satellite Access in 5G

SA2
[1] TS 23.501 System architecture for the 5G System (5GS); Stage 2
[2] TS 23.502 Procedures for the 5G System (5GS)
[3] TS 23.503 Policy and charging control framework for the 5G System (5GS); Stage 2
[4] TR 23.737 Study on architecture aspects for using satellite access in 5G

3.1 Service Requirements (SA1)

TS 22.261よりNTN関連の要件のみを抜粋。
TR 22.822ではユースケースとpotential requriementが検討された。

6.2.3 Service continuity requirements
For a 5G system with satellite access, the following requirements apply: The 5G system shall support service continuity between 5G terrestrial access network and 5G satellite access networks owned by the same operator or owned by different operators having an agreement.（5Gシステムは、同一の事業者が所有する、または契約を締結した異なる事業者が所有する5G地上アクセスネットワークと5G衛星アクセスネットワーク間のサービス継続性をサポートすること。）

6.2.4 Roaming related requirements
For a 5G system with satellite access, the following requirements apply:
A 5G system with satellite access shall enable roaming of UE supporting both satellite access and terrestrial access between 5G satellite networks and 5G terrestrial networks.（衛星アクセスを備えた 5G システムでは、衛星アクセスと地上アクセスの両方をサポートする UE が、5G 衛星ネットワークと 5G 地上ネットワークの間でローミングできるようにする必要があります。）
UEs supporting satellite access shall support optimized network selection and reselection to PLMNs with satellite access, based on home operator policy.（衛星アクセスをサポートする UE は、ホームオペレータのポリシーに基づいて、衛星アクセスを持つ PLMN への最適化されたネットワーク選択および再選択をサポートすること。）

6.3 Multiple access technologies
The 5G system shall be able to support mobility between the supported access networks (e.g. NG-RAN, WLAN, fixed broadband access network, 5G satellite access network).（5Gシステムは、サポートするアクセスネットワーク（NG-RAN、WLAN、固定ブロードバンドアクセスネットワーク、5G衛星アクセスネットワークなど）間のモビリティをサポートできる必要があります。）

6.3.2.3 Satellite access
The 5G system shall be able to provide services using satellite access.
A 5G system with satellite access shall support different configurations where the radio access network is either a satellite NG-RAN or a non-3GPP satellite access network, or both.（衛星アクセスを有する 5G システムは、無線アクセスネットワークが衛星 NG-RAN または非 3GPP 衛星アクセスネットワークのいずれか、またはその両方であるさまざまな構成をサポートする必要があります。）
A UE supporting satellite access shall be able to provide or assist in providing its location to the 5G network.（衛星アクセスをサポートするUEは、5Gネットワークにその位置を提供すること、または提供を支援することが可能でなければならない。）
A 5G system with satellite access shall be able to determine a UE's location in order to provide service (e.g. route traffic, support emergency calls) in accordance with the governing national or regional regulatory requirements applicable to that UE. （衛星アクセスを有する 5G システムは、UE に適用される国または地域の規制要件に従ってサービス（トラフィックのルーティング、緊急電話のサポートなど）を提供するために、 UE の位置を決定することができなければなりません。）
The 5G system with satellite access shall be able to support low power MIoT type of communications.（衛星アクセスを有する5Gシステムは、低電力MIoTタイプの通信をサポートすることができること。）

6.4 Resource efficiency
For a 5G system with satellite access, the following requirements apply:
The 5G system with satellite access shall support the use of satellite links between the radio access network and core network, by enhancing the 3GPP system to handle the latencies introduced by satellite backhaul.（衛星アクセスによる5Gシステムは、衛星バックホールによってもたらされる遅延を処理するために3GPPシステムを強化することによって、無線アクセスネットワークとコアネットワークの間の衛星リンクの使用をサポートすること。）
A 5G system with satellite access shall be able to support meshed connectivity between satellites interconnected with intersatellite links. （衛星アクセスを備えた5Gシステムは、衛星間リンクで相互接続された衛星間のメッシュ型接続をサポートできること。）

6.5 Efficient user plane
The 5G network may also support multiple wireless backhaul connections (e.g. satellites and/or terrestrial), and efficiently route and/or bundle traffic among them.（また、5Gネットワークは、複数の無線バックホール接続（例えば、衛星及び／又は地上）をサポートし、それらの間でトラフィックを効率的にルーティング及び／又はバンドルすることができる。）
For a 5G system with satellite access, the following requirements apply:
A 5G system with satellite access shall be able to select the communication link providing the UE with the connectivity that most closely fulfils the agreed QoS（衛星アクセスを有する5Gシステムは、合意されたQoSを最もよく満たす接続性をUEに提供する通信リンクを選択できること。）
A 5G system with satellite access shall be capable of supporting simultaneous use of 5G satellite access network and 5G terrestrial access networks.（衛星アクセスを有する5Gシステムは、5G衛星アクセス・ネットワークと5G地上アクセス・ネットワークの同時使用をサポートすることが可能であること。）
A 5G system with satellite access shall be able to support both UEs supporting only satellite access and UEs supporting simultaneous connectivity to 5G satellite access network and 5G terrestrial access network.（衛星アクセスを備えた 5G システムは、衛星アクセスのみをサポートする UE と、5G 衛星アクセス・ネットワークと 5G 地上波アクセス・ネットワークへの同時接続をサポートする UE の両方をサポートすることができるものでなければならない。）

6.6 Efficient content delivery
For a 5G system with satellite access, the following requirement applies.
A 5G system with satellite access shall be able to optimise the delivery of content from a content caching application by taking advantage of satellites in supporting ubiquitous service, as well as broadcasting/multicasting on very large to global coverages.（衛星アクセスによる5Gシステムは、ユビキタスサービスをサポートする衛星を活用し、コンテンツキャッシングアプリケーションからのコンテンツ配信を最適化することができ、非常に大規模からグローバルなカバー範囲での放送/マルチキャストを行うことができます。）

6.7 Priority, QoS, and policy control
The 5G system shall support a mechanism to determine suitable QoS parameters for traffic over a satellite backhaul, based e.g. on the latency and bandwidth of the specific backhaul. （5Gシステムは、特定のバックホールの遅延と帯域幅などに基づいて、衛星バックホール上のトラフィックに適したQoSパラメータを決定するメカニズムをサポートする必要があります。）

6.9 Connectivity models
For a 5G system with satellite access, the following requirements apply:
A 5G system with satellite access shall be able to support relay UE's with satellite access.（衛星アクセスを有する 5G システムは、衛星アクセスを有する中継 UE をサポートすることが可能であること。）
NOTE: The connection between a relay UE and a remote UE is the same regardless of whether the relay UE is using satellite access or not.
A 5G system with satellite access shall support mobility management of relay UEs and the remote UEs connected to the relay UE between a 5G satellite access network and a5G terrestrial network, and between 5G satellite access networks.（衛星アクセスを有する5Gシステムは、5G衛星アクセスネットワークと5G地上ネットワーク間、および5G衛星アクセスネットワーク間でのリレーUEおよびリレーUEに接続されたリモートUEのモビリティ管理をサポートしなければならない。）
A 5G system with satellite access shall support joint roaming between different 5G networks of a relay UE and the remote UEs connected to that relay UE.（衛星アクセスを有する5Gシステムは、リレーUEとそのリレーUEに接続されたリモートUEの異なる5Gネットワーク間での共同ローミングをサポートすること。）

6.13 Flexible broadcast/multicast service
The 5G system shall support multicast/broadcast via a 5G satellite access network, or via a combination of a 5G satellite access network and other 5G access networks.（5Gシステムは、5G衛星アクセスネットワーク経由、または5G衛星アクセスネットワークと他の5Gアクセスネットワークの組み合わせによるマルチキャスト／ブロードキャストをサポートすること。）

6.21 NG-RAN Sharing
A 5G satellite access network shall support NG-RAN sharing.（5G衛星アクセスネットワークは、NG-RANの共有をサポートしなければならない。）

6.27 Positioning services
The 5G system shall support mechanisms to determine the UE’s position-related data for period when the UE is outside the coverage of 3GPP RAT-dependent positioning technologies but within the 5G positioning service area (e.g. within the coverage of satellite access).（5G システムは、UE が 3GPP RAT 依存の測位技術の適用範囲外であるが、5G 測位サービスエリア内（例：衛星アクセスの適用範囲内）にいる期間、UE の位置関連データを決定するメカニズムをサポートする必要があります。）

6.42 Mobile base station relays
The 5G system shall be able to support mobile base station relays using 3GPP satellite NG-RAN (NR satellite access).（5Gシステムは、3GPP衛星NG-RAN（NR衛星アクセス）を用いた移動体基地局中継をサポートすることができること。）
The 5G system shall be able to support mobile base station relays accessing to 5GC via NR satellite access and NR terrestrial access simultaneously.（5Gシステムは、NR衛星アクセスとNR地上アクセスを同時に用いて5GCにアクセスする移動体基地局をサポートできること。）
The 5G system shall be able to support service continuity for mobile base station relays using at least one 3GPP satellite NG-RAN.（5Gシステムは、少なくとも1つの3GPP衛星NG-RANを使用する移動基地局中継のサービス継続性をサポートすることができること。）
NOTE 7: This requirement applies to scenarios where there is a transition between two 3GPP NG-RAN, operated by the same MNO, involving at least one 3GPP satellite NG-RAN.（この要件は、少なくとも 1 つの 3GPP 衛星 NG-RAN を含む、同じ MNO によって運用される 2 つの 3GPP NG-RAN 間で移行が行われるシナリオに適用されます。）

8.6 Regulatory
A 5G satellite access network connected to 5G core networks in multiple countries shall be able to meet the corresponding regulatory requirements from these countries (e.g. Lawful Interception). （複数の国の5Gコアネットワークに接続された5G衛星アクセスネットワークは、これらの国の対応する規制要件（例えば、通信傍受）を満たすことができなければならない。）

9 Charging aspects
The 5G core network shall support collection of charging information based on the access type (e.g. 3GPP, non-3GPP, satellite access).（5G コアネットワークは、アクセスタイプ（例：3GPP、非 3GPP、衛星アクセス）に基づく課金情報の収集をサポートすること。）
In a 5G system with satellite access, charging call records associated with satellite access(es) shall include the location of the associated UE(s) with satellite access（衛星アクセスを有する5Gシステムにおいて、衛星アクセスに関連する課金通話記録には、衛星アクセスを有する関連UEの位置が含まれること。）
The 5G system shall be able to support mechanisms to differentiate charging information for traffic carried over satellite backhaul.（5G システムは、衛星バックホールで伝送されるトラフィックに対する課金情報を区別するメカニズムをサポートできること。）

3.2 Periodic network selection attempts

TS 22.001 3.2.2.5
Periodic network selectionに関するTS22.011の既存の要件では、自動モードのUEは同じ国内でより高い優先度のPLMNを選択することのみが規定されている。このとき、国は単一のMCCとして解釈される。つまり、国固有のMCCを使用するUEは、共有MCC（MCC=901など）を使用する衛星ネットワークを選択することができない。逆に、MCC=901 のネットワークを使用するUEは、国固有のMCC を使用する優先度の高い地上ネットワークを選択することができない。
そこで、以下の要件が追加された。(SP-211487)

国固有MCCを使用している：共有MCCも考慮する（緑色）
共有MCCを使用している：他のすべてのMCCが考慮する（黄色）

また、PLMN選択の目的にいおては、the associated Access Technology using a Shared MCCはsatellite NG-RANに限定されている。(SP-220428)

3.3 Integrating NR satellite access into 5GS

TS 23.501 5.4.11 "Support for integrating NR satellite access into 5GS"

New RAT types

UEがNR衛星アクセス(NR satellite access)する際に、AMFで衛星の種別を識別できるようにするため以下のRAT Typeが新たに規定された。

"NR(LEO)"
"NR(MEO)"
"NR(GEO)"
"NR(OTHERSAT)"

このRAT TypeはN2を介してNG-RANからAMFに提供される。RAT TypeはNGAPでのRAT情報(RAT Information)に対応する。RAT情報はTAC毎に設定でき、NG SETUP REQUESTでAMFに通知される。
リリース17では、OTHERSATに何が含まれるかは明確にされておらず今後検討される予定となっている。

UE Location Verifications

NTNはセルのカバー範囲が広いことから、NR衛星アクセスを提供するgNBが複数の国のコアネットワークに接続しコネクティビティを提供するケースがある。国毎にレギュレーション（緊急通報や通信傍受）の要件は異なるため、モビリティ管理やセッション管理手順においてUEの位置を検証し、選択されたPLMNがUEの現在位置での利用可能か判断することが必要となる。
AMFは、NR衛星アクセスを使用するUEのNGAPメッセージに含まれるULI(User Location Information)を検証に利用する。AMFは、PLMN IDおよびULI（Cell ID を含む）に基づいて、UEの現在地で接続が許可されないと判断した場合、AMFは適切なcause値を指定してNAS要求を拒否する。UEが既にPLMNに登録されてしまっている場合、AMFはUEの登録解除を行うことができる。AMFは、PLMNへの接続が許可されていない地理的エリアにUEが位置していると判断できるほど正確なUE位置情報を持っていない限り、要求を拒否したりUEを登録解除すべきではない。

AMFがULIに基づいて、最終決定を下すのに十分な精度でUEの位置を決定できない場合、AMFはモビリティ管理またはセッション管理の手順を進め、TS 23.273の6.10.1節に規定されているように、モビリティ管理またはセッション管理の手順が完了した後にUE 位置決定手順を開始してもよい。

PLMNが現在のUEロケーションでの動作を許可されていないことを示すcause値のUE処理については、TS 23.122とTS 24.501を参照。

5GC-NI-LR Procedure

NR衛星アクセスでは位置要求(Location Request)に基づく位置の特定が行われる場合がある。位置要求には以下の種類がある。

Network Induced Location Request (NI-LR)：AMFが緊急通報またはNR衛星アクセスのために位置要求する
Mobile Terminated Location Request (MT-LR)：LCSクライアント/AFからサービングPLMNに位置要求する
Mobile Originated Location Request (MO-LR)：UEがサービングPLMNに対して位置要求する

この内、NR衛星アクセスで利用される手順はNI-LR(Network Induced Location Request) である。もともとは、UEが緊急通報を発信するときなど適切なルーティングのためにUEの位置情報を取得するための手順として存在していたが、NR衛星アクセスでUEが在圏する国を特定する手順としても利用される。

手順の詳細はTS 23.272 6.10.1を参照されたい。

Mobility Registration Update

UEがNWサービスを利用するには、まず登録(Registration)が必要になります。登録完了後、下記に該当する場合は5GCへの登録情報を更新する。

疎通維持のための定期的な登録更新（Periodic Registration Update）
移動時（Mobility Registration Update）
Capabilityの更新 or プロトコル・パラメータを再調整する時（Mobility Registration Update）

通常、セルに含まれるTACは1つだけですが、NR衛星アクセスのMovingセルでは、複数のTACを含めることができます。このとき、UEは自身のUE Registration Areaに受信したTACが含まれていなければMobility Registration Updateを行い、含まれていたらこの手順は行わない仕様となっています。

TS 23.501のRegistration managementに詳しくない方はこちらが参考になります。

Tracking Area handling

NR衛星アクセスのMovingセルでは、SIBでブロードキャストされるTACが移動とともに変更されていきます。
NG-RANは、TS 38.413に規定されるようにULIがNGAPメッセージに含まれるときはいつでも、単一のブロードキャストTAIまたは選択されたPLMNに対応するすべてのブロードキャストTAIのいずれかをULIの一部としてAMFに提供する。NG-RANは、既知の場合、UEが地理的に配置されているTAIも示す。

3.4 QoS Control

5QI Value 10が導入された。

NOTE 17: The worst case one way propagation delay for GEO satellite is expected to be ~270ms, ,~ 21 ms for LEO at 1200km, and 13 ms for LEO at 600km. The UL scheduling delay that needs to be added is also typically two way propagation delay e.g. ~540ms for GEO, ~42ms for LEO at 1200km, and ~26 ms for LEO at 600km. Based on that, the 5G-AN Packet delay budget is not applicable for 5QIs that require 5G-AN PDB lower than the sum of these values when the specific types of satellite access are used (see TS 38.300 [27]). 5QI-10 can accommodate the worst case PDB for GEO satellite type.

TS 23.501のQoSに詳しくない方はこちらが参考になります。

3.6 Policy Control

TS 23.503に規定。NTNではPCR Triggersが規定された。

Policy Control Request Triggers

Policy Control Request Triggers (PCR triggers) relevant for SMFはPDUセッション確立後にSMFが再びPCFとインタラクションしなければならない条件を定義している。Satellite backhaul category changeが追加された。(TS 23.503 6.1.3.5)

When the Satellite backhaul category change trigger is armed, the SMF reports to the PCF that the Satellite backhaul category change was met and the new satellite backhaul category (or that satellite backhaul is no longer used) when it becomes aware that there is a change of the backhaul which is used for the PDU Session between satellite backhaul categories, or between satellite backhaul and a non-satellite backhaul. The SMF determines whether or not a satellite backhaul is used and whether there is a change of backhaul based on signalling from the AMF as specified in TS 23.501 [2].
NOTE 12: As specified in clause 5.8.2.15 in TS 23.501 [2], satellite backhaul category refers to the type (i.e. GEO, MEO, LEO or OTHERSAT) of the satellite used in the backhaul. Only a single backhaul category can be indicated.

AFがPCFに変更を通知することを依頼することも規定している。

Policy Decision

23.503 6.1.3.6には、NR衛星アクセスまたは衛星バックホールではこばれるPDUセッションの場合、PCFはこれをポリシーの決定に使うことができると規定された。(S2-2104855) DAとBHの両方とも考慮できることに注意。ポリシーの決定とは例えば5QI valueの決定など。

If SMF indicates that a PDU session is carried over NR satellite access or satellite backhaul, the PCF may take this information into account for the policy decision, e.g. together with any delay requirements provided by the AF.

3.5 Satellite backhaul

衛星を用いたバックホールでは旧来から用いられてきたが5GSとの統合においてはいくつかの拡張がなされている。UEは地上の基地局gNBへ接続するためUEの無線IF観点では影響はないが5GCの観点では拡張がなされている。
衛星バックホールが使われている場合は衛星バックホールの種別をAMFからSMFに通知をすることができるようになった。これにより、SMFとPCFが連携して、PCFで衛星バックホールの種別（カテゴリ）に基づいたポリシー制御が可能となった。AMFが衛星バックホール種別を特定して、SMF経由でPCFへ通知するこで行われる(TS 23.501 5.8.2.15, TS 29.502)。この種別を流通するために"SatelliteBackhaulCategory"データタイプが定義され、"GEO" "MEO" "LEO" "OTHER_SAT" "NON_SATELLITE"の5つが設定可能となっている(TS 29.571)。

標準仕様に基づく具体的な動作は以下の通りである。

AMFはローカル設定（例えば、Global RAN Node IDに紐づく衛星バックホール）から衛星バックホール種別を特定する。AMFはPDUセッション確立リクエストなど、特定のメッセージをSMFへ送る際に、HTTPリクエストのbody部に衛星バックホール種別を"satelliteBackhaulCat"属性に含めて送信する。
SMFは、PCFとSM Policy Associationを確立する際など特定のメッセージを送る際に、HTTPリクエストのbody部に衛星バックホール種別を"satelliteBackhaulCat"属性に含めて送信する。
PFCは、受信した衛星バックホール種別からポリシー制御を行うことができる。例えば、衛星バックホール種別が"GEO"の場合、比較的低遅延の要求は満たすことができないため、低遅延に対応する5QI値を選択しないようにすることができる。

また、衛星バックホールの種別が変更された場合には、通信品質が大きく変更されるため、Policy Control Request Triggers (PCR triggers)により、衛星バックホール種別の変更をSMFが検知したらそれをPCFへ通知する仕様となっている。(TS 23.503 6.1.3.5)

3.6 Procedures

Registration

AMFでのUE location verification以外の差分はない。

PDU Session Establishment

TS 23.501のSession managementに詳しくない方はこちらが参考になります。

3.7 Satellite Backhaul enhancement

ここでは、Release-18の5GSATBについて解説する。2023年1月現在でFS_5GSATB(TR 23.700-27)の検討は完了しNormative phaseである5GSATBの検討は始まったばかりであるが既にTSG approvedとなった寄書が6件存在している。以下は、TRで検討された3つのKey issueを節名にしている。

PCC/QoS control enhancement considering dynamic satellite backhaul

Release-17では衛星BHを示すためにsatellite backhaul categoryが定義された。将来的には、衛星がISL(Inter Satellite Link)を持ち複数の衛星をまたぐマルチホップの構成が考えられるが、Rel-17の仕様では十分ではない。リリース17で導入された衛星バックホール種別では、衛星アクセスによる通信品質（パケット遅延等）は安定している前提だったが、実際には通信品質は変動する。例えば、衛星間でISL(Inter-Satellite Link)を確立できる場合、トポロジーが動的に変更され通信品質が変動することが予想される。

そこで、satellite backhaul categoryに動的に変更される可能性があることを示す４つのカテゴリーが追加された。AMFはSMFはこのカテゴリーを通知する。(S2-2211150 TS 23.501)

DYNAMIC_GEO
DYNAMIC_MEO
DYNAMIC _LEO
DYNAMIC _OTHERSAT

上記のdynamic satellite backhaulが使われる場合、パケット遅延を計測するためTS 23.501 5.33.3のQoS monitoringを使うことができる。SMFはPCFにdynamic satellite backhaulが使われることを通知し、PCFはそれに基づいてQoS monitoringを開始することができる。QoS monitoringはURLLCでパケット遅延を計測するために導入された機能で、UEからPSA UPFまでの遅延を計測することができる。

上記に合わせてTS 23.502 6.1.3.6 Policy controlにも規定が追加されている。dynamic satellite backhaulが使われる場合は、PCFからSMFにQoS monitoringをトリガーしパケット遅延を報告するように指示できるようになっています。ただ、BHだけでなくRAN partの遅延も含めるようにするかはFFSになっています。(S2-2210978 (TS 23.503))

Support of Satellite Edge Computing via UPF on board

BHでの遅延減少のため衛星上に搭載されたUPFを介して実行するEdge Computingをサポートする。
Release-18ではGEO衛星BHのみUPF経由ECはサポートされます。

UPFがPSAとして動作する場合：AMFからPCFにsatellite backhaul categoryをPCFに提供してPCFではURSPルール（Route Selection Descriptor）の生成にその情報を考慮に入れる。SMFはPSA UPF選択手順を実行する。
UPFがUL CL/BPとして動作する場合：SMFはAMFから提供されるGEO Satellite IDに基づいてUL CL/BP/local PSAの選択を実施する。AMFはGlobal RAN Node IDなどからGEO Satellite IDを決定することが想定される。(S2-2211151 (TS 23.501), S2-2301764(TS 23.502))

(S2-2211152 (TS 23.502))
(S2-2211132 (TS 23.503))

Support of Local Data Switching via UPF on-board

衛星に搭載されたUPFによるUE間の折り返し通信をサポートする。
UE間トラフィックは、地上の衛星ゲートウェイに戻ることなく、衛星上に配置されたUPFによって（すなわち、ローカルスイッチを介して）ターゲットUEにローカルにルーティングされる場合がある。衛星上に配置されたUPFによるローカルスイッチングは、GEO衛星バックホールの場合にのみ適用され、5G VN用のDNNおよびスライスのみを考慮する。
N19トンネルは、異なる衛星に配備された2つのUPF 間で確立され、UEからUEへのトラフィックをローカルに切り替えることができる。ローカル・スイッチングと N19 転送には、単一の SMF のみがサポートされる。また、異なるGEO衛星上のUPF間の衛星間N19によって得られる遅延の最適化は、配備された衛星の数に応じて衛星間の距離に依存することがNOTEに記載されています。(S2-2211434 (TS 23.501))

3.8 Integration of satellite components in the 5G architecture; Phase 2

ここでは、Release-18の5GSAT_Ph2について解説する。2023年1月現在でFS_5GSATB(TR 23.700-28)の検討は完了しNormative phaseである5GSATBの検討は始まったばかりであるが既にTSG approvedとなった寄書が5件存在している。

Support of discontinuous network coverage for satellite access

Support of discontinuous coverage (S2-2301769)

用語の定義

Satellite coverage information: this refers to location and time related coverage availability of satellite/satellite constellation that provides discontinuous coverage, which is different from satellite ephemeris data.
UE out-of-coverage period: The period that UE is out of coverage in case of NR satellite access that provides discontinuous coverage. The period is determined based on satellite coverage information and UE mobility pattern.

"Support of discontinuous network coverage for satellite access"節を導入。
UE
UEはunreachability periodに入る前にMobility Registration Update手順を行う。
UEはNWに対してUE out-of-coverage periodを通知する(can)。
AMF
AMFはsatellite coverage informationを取得してUE out-of-coverage periodを決定する(may)。
AMFで以下を決定する(may)。

timers(e.g. Periodic Registration Update timer),
extended DRX in CM-IDLE (see clause 5.31.7.2),
MICO mode configuration (see clause 5.4.1.3), and
Estimated Maximum Wait Time based on
- the UE out-of-coverage period,
- Expected UE behaviour (e.g. Stationary Indication, Expected UE moving trajectory),
- the UE current location and
- operator configuration.

これらのタイマーの通知には、既存の手順が使われる。
High latency communication(5.31.8 )が使われるかもしれない(may)。
Wait range during discontinuous coverage(S2-2301766)
Overload controlの節を導入。
Disco wait rangeを導入。
Transfer of Satellite Coverage Data to a UE and AMF (S2-2301767)
satellite coverage informationの提供方法を規定。
UE:外部サーバからU/C-Plane、C-Plane=NIDD NAS
AMF:O&MかAFから、NEFはFFS（NDWAF案は消えた？）

Power saving enhancement for UE in discontinuous coverage

Paging enhancement during satellite discontinuous coverage (S2-2301853)
AMFはsub-area paging (TS 23.502 4.2.3.3)を利用する。
AMFはpaging最適化に位置情報を利用する。

4 CT Part

CTの各WGで影響のあった仕様書の一覧を下に示す。本解説記事はこれらの仕様に基づいているが、仕様を規定した背景の解説のため、TR 24.821などの技術レポートも一部参照している。
なお、CT3,CT4の仕様書にも影響があるが省略している。

CT1
TS 23.122 Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode
TS 24.501 Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3
TS 24.571 5G System (5GS); Control plane Location Services (LCS) procedures; Stage 3
TR 24.821 Study on PLMN selection for satellite access (Release 17)

CT6
TS 31.102 Characteristics of the Universal Subscriber Identity Module (USIM) application
TS 31.111 Universal Subscriber Identity Module (USIM) Application Toolkit (USAT)

4.1 PLMN Selection (TS 23.122)

Higher priority PLMN search for MS in satellite NG-RAN access (C1-220742)

TR 24.821衛星アクセスでの高優先PLMN向けの周期サーチは必要という結論従い仕様化されている。
衛星NG-RANアクセスのMSの場合、より高い優先順位のPLMNの定期的な検索は、候補となるPLMNが共有MCCを持つPLMN IDを持っている場合は、現在のサービング PLMNと同じ国のPLMNに制限されません。

TS 23.122 4.4.3.3.1に、HPLMN/EHPLMNまたはhigher priority PLMNへのアクセスの試みについて、以下のEXCEPTIONが設定されることになった。

Interval of Time between Searches for Higher Priority PLMN via Satellite NG-RAN (C1-221735)

一般にSIMといわれるUSIMにはオペレータが書き込める様々なパラメータがあります（TS31.102）。UEはVPLMNにいるときに他に優先度の高いPLMNがないか定期的にサーチをしますが、そのサーチ周期の設定はUSIMのEF_HPPLMN (Higher Priority PLMN search period)というパラメータに書き込まれいています。例えば、このパラメータの値が0x02であれば、サーチ周期は12分であり、UEは12分ごとに全ての周波数帯を検索して、その国のより高い優先順位のPLMNを検索します。

NTNの衛星アクセスシナリオでは、Satellite NG-RANアクセスを介してVPLMNにいるMS(UE)は、地上アクセスを介してより優先度の高いPLMNを長い時間見つけられないと考えられます。この場合、地上アクセス向けに設定された、例えば12分という短いサーチ周期の単一パラメータを使用し続けることは、MSにエネルギー消費観点で非効率になります。
一方で、もし国固有PLMNのSatellite NG-RANアクセスを使う場合、国固有PLMNのSatellite NG-RANアクセスは地上アクセスに対して補完的に使われることが想定されるので、サーチ周期の延長は不要とも考えられます。
上記のような背景から、MSの実装オプションとして、MSはUSIMに現在格納されている時間値に整数Mを乗算することによって優先度の高いPLMNを検索するサーチ周期を適宜調整する仕様が合意されている。これを行うために、ネットワークオペレータは、SIMに整数Mを設定することができる。Mの値がSIMに設定されていない場合、Mは1に等しく、これは既存の時間間隔（前述の場合、12分）が変更されないことを示唆するものである。
TS 22.122 4.4.3.3.1に以下が追記されることになった。

"PLMNs not allowed to operate at the present UE location" (C1-221824)

PLMN選択においてsatellite NG-RANアクセスからの繰り返し再接続を防ぐために、cause value #78 "PLMNs not allowed to operate at the present UE location"が設定されたリジェクトメッセージを受信したら、一定期間は再接続を禁止する規定を導入している。なお、TS 23.122はStage 2の仕様なのでNASに言及していないがMM NASのREGISTRATION REJECT messageに対してcause #78は設定される。

興味深いのは黄色ハイライトしている部分。cause #78を受信したとしても、(a)または(b)を満たしていたら再度そのsatellite NG-RANアクセスのPLMNに接続を試みてもいいとしている。(a)は、UEの位置が既知であり、PLMNのエントリの地理情報も保存されており、その地理情報からUEの位置が一定以上離れていたら、このPLMNに接続を試みてもよいとしている。船舶や航空機など移動距離の大きなUEを考慮に入れた衛星アクセスならではの仕様かと思います。

4.2 NAS over NTN (TS 24.501 4.23)

TS 24.501 4.23節ではsatellite NG-RANアクセスをサポートする5GSのNAS特有について解説します。

List of PLMN not allowed to operate

3GPP satellite NG-RANの場合、UEは"PLMNs not allowed to operate at the present UE location"(PLMNは複数形)のリストを保存する必要がある。各エントリーは以下から構成される。

a) 5GMM cause value #78 "PLMN not allowed to operate at the present UE location"(PLMNは単数形) を含むメッセージをsatellite NG-RANアクセスで送信したPLMN ID
b) UEが知っている場合、satellite NG-RANアクセスで5GMM cause＃78を受信した地理的な場所
c) 地理的位置が存在する場合、UE実装固有の距離値

リストに新しいエントリを格納する前に、UEは同じPLMN IDを持つ既存のエントリをすべて削除する必要があります。新しいエントリを格納すると、UEはそのエントリに関連付けられたタイマーインスタンスを、実装固有の値で開始する。この値は、ネットワークがLower bound timer value IEで示したタイマー値よりも小さい値に設定されてはなりません。提供されなかったら実装依存。
UEは、以下の場合に限り、"PLMNs not allowed to operate at the present UE location"のリストに含まれるsatellite NG-RAN アクセス技術を介してPLMNにアクセスしようとすることが許可される。(TS 23.122のStage 2仕様に従っている)

a) 現在のUEの位置が分かっており、この PLMN のエントリのために地理的な位置が保存され、現在のUE の位置までの距離が UE 実装固有の値よりも大きい場合。
b) このPLMNのエントリに関連するタイマーが期限切れである。
c) 緊急サービスのためのアクセスである場合（詳細については3GPP TS 23.122 [5]を参照）。

"PLMNs not allowed to operate at the present UE location"リストの削除

UEのスイッチオフの場合：不揮発性メモリに保存する（消えない）
USIMが抜き取られた場合：削除する

5GS MM/SM NAS Timer

NG-RANアクセスのタイプ(GEO,MEO,LEO)に依存してNAS timer値を変えることができる。table 10.2.1(MM), 10.3.1(SM)が修正されている。仕様はC1-222030で導入された（Discussion PaperはC1-220286 ）

初期PLMN選択を行う前にEPLMNリストが存在するときはキープする。

Multiple Tracking Area

RAN2でOption 2 (AS indicates all received TAC(s) for one PLMN to NAS layer)が合意されたことに伴いNASの動作が規定された。

UEが下位レイヤーから複数TACを受信したらPLMNとTACからTAIを構築して、一つのTAIを選択する。以下のロジックになる。

if TAIが現在の登録エリア(current registration area)に属する
- if TAIが"non-allowed tracking areas"に属さない
  - if TAIが"allowed tracking area"リストに属する
    - "allowed tracking area"リストのTAIを選ぶ
    - 複数TAIが候補になる場合は等価を見なし選択方法は実装依存
  - else (TAIが"allowed tracking area"リストに属さない)
    - 任意のTAIを選ぶ
    - 複数TAIが候補になる場合は等価を見なし選択方法は実装依存
- else (TAIが"non-allowed tracking areas"に属する)
  - 未規定 (通常起こり得ないためと思われる)
else (TAIが現在の登録エリア(current registration area)に属さない)
- 複数TAIが候補になる場合は等価を見なし選択方法は実装依存

長々と書いてあったが結局は実装依存に落ちるので大したことは書いていなかった…

4.3 Signalling (CT4)

Nsmf(TS 29.502)

AMFが、衛星バックホールのカテゴリをSMFに通知できるように、Create SM Context Request, Update SM Context Request, Create Requestに設定可能なsatelliteBackhaulCat属性が定義されました。(C4-216556)
TS 29.502 POSTメッセージにsatelliteBackhaulCat属性が設定される。

NR DAのときのGEO,MEOなどを示すratType属性も合わせて以下に整理した。
なお、ratType属性のRatTypeデータタイプについてはTS 29.523のCommon Data Typesへの追加のみでTS 29.502への変更はない。

NTN関連のData Structure

Type	`ratType`	`satelliteBackhaulCat`
SmContextCreateData	C	O(5GSAT)
SmContextUpdateData	C	O(5GSAT)
PduSessionCreateData	C	O(5GSAT)
HsmfUpdateData	C	O(5GSAT)
SmContext	-	O(5GSAT)

カッコ内はApplicability
C: Condtional
O: Optional

SmContextCreateData
SmContextUpdateData
PduSessionCreateData
HsmfUpdateData
SmContext

Npcf_SMPolicyControl_Create Service

オプション機能はTS 29.500のネゴシエーションメカニズムで交換される。(6.1.8)
satelliteBackhaulCat属性はオプション機能の5GSATをサポートしてるときのみ設定できる。

satelliteBackhaulCat attribute
SatelliteBackhaulCategory DataType
5GSAT feature

Npcf(TS 29.512)

NTN関連のData Structure

Type	`ratType`	`satBackhaulCategory`
SmPolicyContextData	O	O(SatBackhaulCategoryChg)
SmPolicyUpdateContextData	O	O(SatBackhaulCategoryChg)
UeCampingRep	O	O(SatBackhaulCategoryChg)

カッコ内はApplicability
C: Condtional
O: Optional

オプション機能はTS 29.500のネゴシエーションメカニズムで交換される。(6.1.8)
satBackhaulCategory属性はオプション機能のSatBackhaulCategoryChgをサポートしてるときのみ設定できる。

satBackhaulCategory attribute
SatelliteBackhaulCategory DataType
SatBackhaulCategoryChg feature

If "SatBackhaulCategoryChg" feature is supported, and if "SAT_CATEGORY_CHG" is provisioned, the NF service consumer notifies the PCF when there is a change of the backhaul which is used for the PDU session between different satellite backhaul categories (i.e., GEO, MEO, LEO, or other satellite) or between a satellite backhaul and a non-satellite backhaul. The NF service consumer shall include the satellite backhaul category or non-satellite backhaul within the "satBackhaulCategory" attribute together with the "SAT_CATEGORY_CHG" policy control request trigger within the "repPolicyCtrlReqTriggers" attribute.

Common Data Types

Common Data type(TS 29.571)にもRAT Typeが追加された。
RatTypeはNR satellite accessのAccess Technologyの識別に用いられる。

一方、SatelliteBackhaulCategoryでは、gNBからCN間のバックホールに利用されている衛星の種別の識別に用いられる。(C4-216420)

以上です。これからもRel-18の仕様を反映したり継続的にメンテしていきます。

1 Introduction

Abbreviation

2 RAN Part

2.1 Overall architecture

2.2 Timing, Synchronization and HARQ enhancements（RAN1）

Timing Advance and Doppler shipt compensation

HARQ

2.3 Mobility Management (RAN2)

Network-assistance information for UE measurement and mobility

SIB19

2.3a UE radio access capability

2.4 Switch-over (RAN3)

2.5 NG-RAN signalling (RAN3)

Cell ID

TAI (Tracking Area Identity)

RAT Information

Signalling & Callflow

2.6 AMF (Re-)Selection by gNB (RAN3)

2.7 O&M Requirements (RAN3)

2.8 RF performances and RRM requirements (RAN4)

SAN(Satellite Access Node) type

Operating Bands

UE/SAT Channel Bandwidth

RF Requirements

NTN-TN Coexistence

Radio Resource Management

HAPS

2.9 Deployment Scenario

Annex NR_NTN_solutions Approved CRs

860046 NR_NTN_solutions

860146 NR_NTN_solutions-Core

860246 NR_NTN_solutions-Perf

Annex NR_NTN_enhancements(Rel-18)

Coverage Enhancements

Network verified UE location

TN and NTN-NTN mobility and service continuity enhancements

Cell reselection enhancements

Handover enhancements

3 SA Part

3.1 Service Requirements (SA1)

Satellite access related requirements

3.2 Periodic network selection attempts

3.3 Integrating NR satellite access into 5GS

New RAT types

UE Location Verifications

5GC-NI-LR Procedure

Mobility Registration Update

Tracking Area handling

3.4 QoS Control

3.6 Policy Control

Policy Control Request Triggers

Policy Decision

3.5 Satellite backhaul

3.6 Procedures

Registration

PDU Session Establishment

3.7 Satellite Backhaul enhancement

PCC/QoS control enhancement considering dynamic satellite backhaul

Support of Satellite Edge Computing via UPF on board

Support of Local Data Switching via UPF on-board

3.8 Integration of satellite components in the 5G architecture; Phase 2

Support of discontinuous network coverage for satellite access

Power saving enhancement for UE in discontinuous coverage

4 CT Part

4.1 PLMN Selection (TS 23.122)

Higher priority PLMN search for MS in satellite NG-RAN access (C1-220742)

Interval of Time between Searches for Higher Priority PLMN via Satellite NG-RAN (C1-221735)

"PLMNs not allowed to operate at the present UE location" (C1-221824)

4.2 NAS over NTN (TS 24.501 4.23)

List of PLMN not allowed to operate

5GS MM/SM NAS Timer

Multiple Tracking Area

4.3 Signalling (CT4)

Nsmf(TS 29.502)

Npcf(TS 29.512)

Common Data Types

Discussion