🧭

[詳解] NTN(非地上ネットワーク) - デバイス直接通信編(2) - 3GPP NTNの技術

2024/04/13に公開

3gpp

ntn

tech

この記事は、NTN(非地上ネットワーク)のデバイス直接通信における3GPP標準仕様を詳しく見ていきます。デバイス直接通信編の中編の位置付けです。前編は以下を参照下さい。

はじめに

前編ではデバイス直接通信を大まかに4つの分類で分けました。

表：周波数と技術によるデバイス直接通信の分類（著者が独自作成）再掲

	1. MSS独自技術	2. 3GPP基地局独自拡張	3. IoT-NTN(GEO)	3'. IoT-NTN(NGSO)	4. NR-NTN
無線技術	独自プロトコル	LTE	NB-IoT/LTE-M	NB-IoT/LTE-M	NR
3GPPリリース	無関係	任意のLTEリリース	Rel-17以降	Rel-17以降	Rel-17以降
衛星タイプ	GEO/NGEO	LEO	GEO	NGSO	LEO
周波数	L/Sバンド	IMTバンド	L/Sバンド(b25x)	L/Sバンド(b25x)	L/Sバンド(n25x)
想定オペレータ	Globalstar(iPhone) Iridium	Starlink&T-Mobile, KDDI AST&楽天	EchoStar Viasat/Inmarst TerreStar	EchoStar OmniSpace Viasat/Inmarsat Sateliot	EchoStar OmniSpace Viasat/Inmarsat SES OneWeb
商用実現時期	2022年～	2024年～	2023年～	2024年～	2026年～
端末対応	独自対応端末	既存端末で対応可能(基地局側で補償)	対応チップセットが必要	対応チップセットが必要	対応チップセットが必要

この記事では、デバイス直接通信を支える技術として、3GPPの技術仕様を細かく見ていきたいと思います。特に、NTN向けの機能追加が多数追加されている分類「4. NR-NTN」について見ていきます。

3GPPでのデバイス直接通信の標準化

3GPPでは5Gの初期リリースであるリリース15から地上系ネットワークと衛星ネットワークの統合の重要性が認識されており、リリース17でNTNの初期フェーズの仕様が完成しています。2024年1月現在では、リリース18でのフェーズ2の仕様はほぼ完成し、リリース19でもNTNの拡張の継続検討が合意されており検討スコープが確定しています。
標準化活動は、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を示しています。

NTNの技術の中心はRANで検討されています。この記事では、先ずは全体の構成を把握するためにRANのアーキテクチャを見た上で、RANで策定された仕様をリリース17から18までの進化の過程を見ていくとともに、最近合意されたリリース19での検討項目についても紹介します。
RANと一括りに行っても、レイヤー毎にだいぶ毛色が違うため低いレイヤーから順に見ていきたいと思います。

NTNアーキテクチャと基礎用語

RANアーキテクチャ
NTNのRANアーキテクチャはTS 38.300に以下のように定義されています。

ここで、登場するNTN Gateway、NTN payload、Feeder link、Service linkは3GPP TS 38.300で用語が定義されています。

非地上ネットワーク（Non-terrestrial network）： gNBで構成されるNG-RAN。gNBは、空中または宇宙空間のNTNビークル（衛星本体に相当）に搭載されたNTNペイロードとNTNゲートウェイにより、UEに地上波以外のNRアクセスを提供する。
NTNゲートウェイ（NTN Gateway）：地表に位置する地球局で、フィーダリンクを使用してNTNペイロードへの接続を提供する。NTNゲートウェイはTNL(Transport Network Layer)ノードである。
NTNペイロード（NTN payload）：衛星または高高度プラットフォーム局（HAPS）に搭載され、サービスリンクとフィーダリンクの間の接続機能を提供するネットワークノード。本仕様書の現バージョン（リリース17）では、NTNペイロードはTNLノードである。
フィーダリンク（Feeder link）： NTNゲートウェイとNTNペイロード間の無線リンク。
サービスリンク（Service link）： NTNペイロードとUE間の無線リンク。

「デバイス直接通信で、スマートフォンと衛星が直接通信するのはわかるが、衛星のその先はどうなっているのか？」 と前回の記事で疑問に思った方もいるかもしれません。
上の図を使って答えると、衛星に搭載されるNTNペイロードはNTNゲートウェイという地球局に接続されて、その先のコアネットワーク（5GCなど）を経由してインターネットやSMS、緊急機関などの外部ネットワークに抜けていきます。
UEとNTNペイロード間のリンクはサービスリンク、NTNペイロードとNTNゲートウェイ間のリンクはフィーダリンクです。フィーダ（feeder）には供給するなどの意味があるので分かりやすいですね。
多数のサービスリンクに対して、1本（もしくは数本の）フィーダリンクという関係性になります。フィーダリンクには大容量が求められるため、デバイス直接通信に使う周波数よりも一般に高い周波数帯が利用されます。

NTNペイロードの種類には透過型（transparent） と再生中継型（regenerative） があります。透過型はNTNペイロードは単にNR Uuを中継のみ行いますが、再生中継型ではgNodeBがNTNペイロードに搭載されます。

出典：3GPP TR 38.821

透過型：NTNペイロードには、アップリンクとダウンリンクの両方向で周波数変換と電力増幅器が実装されます。透過型はフィーダリンクからのNR-Uu無線インタフェースをサービスリンク（その逆も含む）に対してリピートすることになります。

再生中継型：再生中継型ペイロードでは、gNBがNTNペイロードに搭載されます。そのため、地上から受信した信号を復調します。再生衛星型には、gNBの機能分離(CU/DU)を考慮して、full gNB搭載型か、gNB-DU搭載型の2種類に分けられます。

full gNB：サービスリンクはNR Uuで接続される一方で、フィーダリンクは衛星のgNBと5GCとの接続となるためNG IFになります。また、gNBは衛星間のISL(Inter Satellite Link)を提供することもでき海上などでフィーダリンクを確保できない場合でもサービスリンクの提供を可能にします。（ただ、ISLはトランスポートの位置付けなので3GPPの標準化範囲外です）
gNB-DU搭載型：NTNペイロードのgNB-DUと地上gNB-CUがNTNゲートウェイ経由で接続されるため、フィーダリンクはF1 IFになります。

リリース16の初期検討（スタディーアイテム）では透過型と再生中継型の両方が検討され、リリース17では透過型のみ標準化されました。再生中継型はリリース19で標準化予定です。

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

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

（図：著者作成）

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

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

3GPPリリース17

3GPPリリース17でのNR NTNへの対応では、レイヤーが低い順に大きく以下の4つの仕様が規定されました。順番に見ていきたいと思います。

変動する遅延とドップラーシフトへの対応
スケジューリングとHARQ
モビリティ管理

変動する遅延とドップラーシフトへの対応

まず最初は遅延とドップラーシフトへの対応です。これは物理現象に起因する課題のため一番最初にあげています。
（前回の記事の繰り返しにはなりますが）スマートフォンなどのデバイスは基地局と通信するために非常に高い精度で時刻的な同期を取り合っています。これが衛星通信、特にLEO衛星との通信となると、LEO衛星は毎秒8km近い速度で飛行していることからデバイスとLEO衛星間の距離が大きく変化していきます。また距離の変化量も一定ではありません。このような環境下ではデバイスと基地局間でタイミング（つまじ時間軸での）同期を取ることが困難です。さらに、ドップラーシフト（ドップラー効果）によって波長も変化していくので周波数軸での同期をとることも困難です。

つまり、課題をまとめると、伝搬遅延が大きくかつ変動するため「時間の同期」が崩れ、ドップラーシフトにより「周波数の同期」も崩れてしまうことが問題になります。

3GPPではこの問題を解決するために3GPPの標準技術としてUEと基地局が衛星の軌道情報（エフェメリス）を使いながら時間・周波数の同期をとる技術を開発しました。

変動する遅延への対応（時間の同期）

まずこの問題を考える前に、LTE/NRでの時間同期の重要な技術であるTA(Timing Advance) を理解する必要があります。（もともと無線の素養がない私にはTAはとても難しく感じました…）

これはとても重要なので、独立した記事にしました。NTNにおけるTAの説明をこれからしていきますが、「そもそもTAとは？」という方はぜひこちらをご確認下さい。

TAはUEとgNB間の伝搬遅延の2倍とし、gNBにおいてgNB ULとgNB DLのフレームタイミングが一致するようにTAを設定するのが原則でした。NTNでは大きな伝搬遅延のためUEは非常に大きなTA値を適用することになります。この関係はTR 38.821図6.2.1-1の下図のように示されます。UEが大きなTAを適用し、gNBのDL フレームとULフレームのタイミングが揃うシナリオを示しています。

NRでは、Uplink直交性の保持のために、異なるUEから送信された周波数リソースが異なる信号がgNBにほぼ同じ時間に到着することが必要ですが、NTNではgNBを基準にTAを定義することは必須ではないと思われます。なぜなら、NTNにおけるフィーダーリンクでのRTTは同じ衛星にサービングされているUEにとって同じになるからです。そのため、NTNではUplinkとDownlinkのタイミングの同期がとれる場所としてRP(Reference Point) - 参照点を定義することにしました。このRPはNTNペイロード(衛星中継局)とgNB(NTNゲートウェイ)との間の任意の点を取ることができます。

上記のRPを踏まえたNTNにおけるTAの考え方は下図で示されています。

出典：TS 38.300 Figure 16.14.2.1-1

NTNにおけるTAの計算方法も具体的に見ていきましょう。TAはTS 38.211 4.3.1 "Frames and subframes"で以下のように計算式が定義されています。

修正前（Rel-17以前）

修正後（Rel-17以降）

N_TAとN_TA,offsetは従来からある項で、TS 38.213 4.2節で説明されています。TAの別記事でも解説しているように、N_TAは地上のセルを想定した項のためNTNで使うには値が小さすぎます。続く、N_common_TA,adjとN_UE_TA,adjの2つの項がNTNが標準化されたリリース17で追加されています。

このような説明が書いてあるものの、これを読んだだけで理解できる方はまずいないと思います。そこで、下のような図で表してみました。

NTNにおけるTAはUEからNTNペイロードまでのサービスリンクのRTT（これをUE固有TA(UE Specific TA)）と、NTNペイロードからRP（参照点）までのRTT（これを共通TA(Common TA)とよぶ）の和で表現されます。UE固有TAがN_UE_TA,adjで、共通TAがN_common_TA,adjに対応します。
サービスリンクのRTTはUEの位置によって異なるのでUE固有TAが必要である一方、共通TAはUEの位置によらずビーム内の全てのUEで一定となるため共通TAとよばれます。
UE固有TAと共通TAはどのように計算されるのでしょうか？

UE固有TA
UEの現在地と衛星の現在地が分かれば計算ができます。衛星の現在地を知るのに利用する情報はgNB側からブロードキャストされます。衛星が通る軌道は既に決まっているにも関わらず逐一衛星の現在地を受信することは無駄です。そのため、衛星のエフェメリス情報をgNBはブロードキャストしています。この情報のフォーマットはNIMA TR 8350.2で定義されているものを使用しています。この衛星エフェメリスとエポックタイム、現在時刻が分かれば衛星の現在地が正確に計算できるというわけです。この情報はNTN用に新たに定義されたシステム情報ブロックであるSIB19でブロードキャストされます。なお、具体的な計算式は定義されておらず実装依存になります。

共通TA
UE固有TAと同じくgNBからブロードキャストされるSIB19の情報を利用します。gNBからはta-Common、ta-CommonDrift、ta-CommonVariantという3つのパラメータが提供されます。
NGSOを想定した場合、共通TAの値は常に変動します。言い換えれば、SIB19を受信した瞬間からt秒経過した後は共通TAの値は変化します。これを時間の関数として表すために、テイラー級数展開した際の2次の係数までをta-CommonDrift、ta-CommonVariantで渡しています。これさえあればUE側では簡単に現在時刻の共通TAを計算できるというわけです！
TS 38.213 4.2節では、共通TAの計算式として以下を与えています。

SIB19
TAの計算のために出てきたSIB19ですが、3GPP NTNのサポートには必須のSIBであり、TAの計算以外にも色々な用途で利用されます。SIB19のフォーマットはTS 38.331 (RRC spec)で規定されています。
SIB19のフィールドには以下のようなものがあります。

TAの計算のために必要な衛星エフェメリス情報やエポック時間、共通TA関係パラメータはntn-Configに格納されています。

赤枠で囲っているところが、上記のUE固有TAと共通TAの計算で説明したパラメータのフィールドになっています。

SIB19の取得と更新
UEは電源を入れたらSSBを受信して同期してMIB/SIB1の受信・デコードを行います。ここまでの動作は（私があまり詳しくないということもありますが）以下のブログを参考にして下さい。

SIB1はSIBの中でもネットワークへアクセスするために必須となる極めて重要なSIBのため、定期的にブロードキャストされています。一方、SIB1以外のSIBに関しては、オペレータの運用ポリシー次第で定期的にブロードキャストするか、要求があったときのみブロードキャストするかのどちらかになります。後者の場合、ブロードキャストされるSIBはOn-demand SIBとよばれます。
定期的にSIBをブロードキャストする場合は不必要な場合でも常に無線リソースを一定量専有してしまうので、あるSIBを必要とするUEが少ないときにこれをすると非効率な運用につながってしまいます。そのため、オペレータとしては、どのSIBをOn-demandにするか慎重に決定しなければなりません。
SIB19に関しては、TS 38.331でSIB19のsi-BroadcastStatusがbroadcastingと設定されているため、常に報知する想定のようです。

ドップラーシフトへの対応（周波数の同期）

ドップラーシフトへの対応として周波数の同期（補償）が必要になります。時間の同期と同様に、UEの位置情報と衛星の位置情報からどれだけの補償が必要かを算出して適用します。ただし、これをどのように行うかは実装依存になっています。

なお、時間の同期はGSOとNGSOの両方で必要になり、特にNGSOでは随時更新を行うのに対し、周波数の補償はドップラーシフトが発生しないGSOでは不要でNGSOでのみ必要になると想定されます。

スケジューリング（無線リソースの割り当て）

K0,K1,K2について
NRではデータのスケジューリングはスロット単位で行われます。スロットはSCS(SubCarrier Spacing)に関わらず14個のOFDMシンボルで構成されます。例えば、SCSが15kHzの場合は1スロットは1msになります。物理レイヤの時間領域（スロットレベル）リソース割り当て手順はTS 38.214に規定されています。
物理レイヤにおけるリソース割り当ての仕組みは下図のようになっています。（ここでは詳しく解説しないので、出典のレポートの5章を参照にしてください。）

出典：NTTドコモテクノロジーレポート 5GにおけるNR物理レイヤ仕様著者が上部赤字を追記

TS 38.214では、gNBがUEごとにタイムドメインリソースを割り当てる際に、UEがK値をどのように扱うかを規定しています。
PDCCH/DCIでスケジューリング情報が格納されています。UEはDCIを受け取ってから、（DLの場合）PDSCHを受信してPUCCHでHARQ ACK/NACKを送ったり、（ULの場合）PUSCHを送ります。その際に、DCIを受信してからUE内で待ち受けたりデータ処理をするために僅かな時間(数ms程度)が必要になりますので、数スロット分のオフセットが設定されます。このオフセットには以下の3つがあります。

K0: ダウンリンク・スケジューリング用のPDCCH（DCI）を受信するDLスロットと、PDSCHデータをスケジューリングするDLスロット間のオフセット
K1：PDSCHでデータがスケジューリングされるDLスロットと、スケジューリングされたPDSCHデータに対するHARQ ACK/NACKフィードバックを送信するULスロットとの間のオフセット
K2: アップリンクスケジューリング用のPDCCH(DCI)を受信するDLスロットと、PUSCHでULデータを送信するULスロット間のオフセット

これらは上の図の上部赤字でも示されている通りです（図で見ると案外単純ですね！）。

遅延がある時のスケジューリング
現実のネットワークでは必ず伝搬遅延があるので、以前説明したTAも分かるように図を作ると以下のようになります。なお、データ受信(PDSCH)からのHARQ ACK/NACK(PUCCH)のシナリオを想定しています。

地上モバイルで利用する時の遅延はとても小さいため、僅かなズレしか生じていないのがわかります。

非常に大きな遅延がある時のスケジューリング
一方これが、NTNの場合、TAが数msから百数msまで非常に大きな値になりえます。あまりに大きな値にしすぎると図が収まらないので9msのRTTがあるとしたときは、以下の図のようになります。ここでK1は本来はPUSCHを送るための処理準備時間として設けられているのに、このようにあまりにも遅延が大きくなってしまうと、その遅延を考慮したK1の設定をする必要になり、本来の使い方から外れてしまいます。（また、仕様を確認したわけではないですが、Kの値の上限値を超えてしまう、という可能性もあると思います）

そこで、NTNにおいては、大きな遅延に対応するため、Koffsetの仕組みが導入されました。以下の図のように9msのRTTに対応するKoffset=9を設定しておくことにより、K1に本来の意図の値を設定できるようになりました。

モビリティ管理

NTNではいくつかのモビリティ管理機能も強化されています。先ずは、（意外と正しく知られていないと感じる）3GPPの5Gシステムにおける「モビリティ管理の基礎」について解説します。基礎的な内容なので、既に知ってるよという方は読み飛ばしてください。

モビリティ管理の基礎

NRでは、RRS Statusとして、RRC_CONNECTED、RRC_IDLE、そしてRRC_INACTIVEが定義されています。

RRC_CONNECTED

UEとgNB間の接続状態です。UEがランダムアクセスを行い、RRC Setup messageを受信し、SRB1 を確立し、UEがRRC SetupComplete messageを送信した後の接続状態です。あくまでRRCの接続状態なのでコアネットワークへの登録状態とは独立しています。なお、UEからgNBに送られるRRC SetupComplete は、NASメッセージ(Registration RequestやService Request等）をpiggy-backさせる事が出来ます。シグナリング量の削減のために、RRCの完了と同時にNASでコアネットワークへの登録を試みる（Registration Request）のが普通です。

RRC_CONNECTEDでは、UE に占有資源 (dedicated resource) が割り当てられデータ送受信を行う事が出来ます。データ送受信を問題なく行える無線リンクを維持するために以下の動作を行っています。

– Radio Link Monitoring（無線リンク監視）: 無線リンクの品質を監視しin-sync/out-of-sync を見極める。

Measurements（測定）: 現在のサービングセルの電波強度/品質を計測しつつ、隣接セルの計測も行う。例えば、隣接セルの電波強度/品質がサービングセルより良い場合、測定レポート（Measurement Report）でgNB にそのイベントを通知する。gNB は電波強度/品質の計測結果を見て、データ送受信サービスを維持したままサービングセルを入れ替えるハンドオーバー手順きを実施し、より良い品質のセルでの無線通信サービスの提供を続ける。

RRC_IDLE

ユーザーデータの送受信が発生していない時に用いられる電力消費を抑えたステートです。
RRC_IDLE状態で端末が移動した場合、ネットワーク側からの制御信号に頼る事無く自律的に最適なサービングセルを選択する動作を行うことができます。具体的には、近隣セルの計測を行い、サービングセルと近隣セルの計測結果を見比べてサービングセルを切り替えることができます。
これをセル再選択(Cell reselection)といいます。
よく用語が混同されがちなので、以下の点はよく意識して覚えておくとよいでしょう。

ハンドオーバー
- RRC_CONNECTED状態でのサービングセルの切り替え
- UEからのレポートに基づきgNBがトリガーする
セル再選択
- RRC_IDLE状態でのサービングセルの切り替え
- UEが自律的に再選択し、RRC_CONNECTEDに遷移するときに使う

RRC_IDLEではユーザーデータ送受信不可なので、ユーザーデータの送受信が必要な際には通信可能モードである RRC_CONNECTEDに遷移します。
なお、端末からのデータ送信がトリガーされた場合は、MO call（Mobile Originated call)、一方で、NWから特定端末に対して接続を要求する場合は、MT call（Mobile Terminated call)と言われます。後者はpagingと言われます。

CHO (Conditional Handover)

基礎の最後にNTNで利用されているCHOについても簡単に述べておきます。
Release-15でのハンドオーバーではハンドオーバーの実行はgNBの判断に基づき、gNBはUEにハンドオーバーコマンドを送信し、UEは即座にハンドオーバーを開始しなければなりませんでした。ハンドオーバーの成功率を上げるために、Release-16では特定の条件が満たされた場合にUEがハンドオーバーを実行するか決める条件付きハンドオーバ（Conditional Handover - CHO）が導入されています。CHOではターゲットセル毎に最大2つの実行条件を設定することができます。

NTNにおけるモビリティ管理

ここから、NTN特有のモビリティ管理について解説していきます。モビリティ管理は以下の記事の「2.3 Mobility Management (RAN2)」でも十分書いていたので、それを若干読みやすく修正したものになります。内容はほぼ同じです。

スコープ
LEOのようなNGSOでは頻繁に接続する衛星が切り替わるためサービス継続性のためにはモビリティの提供が不可欠です。また、UEの移動のよるNTNセルの切り替えであったり、異なる軌道（高度が異なるGSO、NGSO）間の切り替えもスコープに入っています。
3GPPのNTNサポートするUEは、地上ネットワーク（TN）への接続機能もあります。そのため、NTNと地上ネットワーク間のモビリティ（NTN から地上ネットワーク（ハンドイン）、地上ネットワークから NTN（ハンドアウト））もサポートされます。

CHO
NTNでのモビリティを可能にするため、ネットワークはハンドオーバーコマンドでターゲットとなるNTNセルへのアクセスに必要なサービングセルと隣接セルの衛星エフェメリスが提供されます。

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

そこで、UE が候補セルへの条件付きハンドオーバ（Conditional Handover - CHO）を実行するためのトリガ条件として、時間ベースのトリガ条件（time-based trigger condition）、位置ベースのトリガ条件（location-based trigger condition）が導入されています。この2つの条件は、測定に基づくトリガ条件（measurement-based trigger conditions）の 1 つと一緒に設定されます。

これらの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で報知されます。

これでデバイス直接通信の中編は終わりになります。NTNの仕様については以下の記事でも詳しく解説していますが、この記事では仕様解説の中では不十分だった「変動する遅延とドップラーシフトへの対応」について内容を拡充させてみました。その他のパートでは、以下の記事に詳しくかいてあるのでぜひ御覧ください。