3GPP Release 19における衛星通信ネットワーク向け5GC高度化技術

01. まえがき

Release 15（以下，Rel-15）で開始された第5世代移動通信システム（5G）は，都市および郊外のカバレッジ*1を超えた，グローバルでユビキタスなカバレッジを目標に，無線接続の範囲を拡大した．この拡大における重要な発展は，地上の5Gインフラストラクチャへの非地上ネットワーク（NTN：Non-Terrestrial Network）*2の統合であった．
Rel-17でNTNに関する仕様検討が開始され，衛星をリピータ*3として扱う透過型衛星アーキテクチャが導入された．このとき，基地局（gNB（gNodeB）*4）やコアネットワーク*5機能は地上に配備される．Rel-17では，衛星固有の伝搬遅延の処理，衛星軌道種別に応じた展開シナリオ，および，衛星を用いるIoT（Internet of Things）*6やマルチキャストサービスのサポートなどの基本的な要素が定義された[1]．
Rel-18では，SA（Service and System Aspects） WG2（Working Group 2）*7において，衛星で信号処理を行う再生型衛星アーキテクチャが導入された．このとき，gNBに加えて，ユーザプレーン*8にかかわるコアネットワーク機能も衛星に搭載された．ただし，本機能の導入は，静止軌道（GEO：Geostationary Earth Orbit）*9衛星に限定されていた[2]～[4]．
Rel-19では，RAN（Radio Access Network） WGにおいても，再生型衛星アーキテクチャが導入された[1]．またSA WG2においては，ユーザプレーンにかかわるコアネットワーク機能を低軌道（LEO：Low Earth Orbit）*10衛星に搭載するシナリオを仕様化した．本シナリオにおいては，特に，LEO衛星を介したIMS（IP Multimedia Subsystem）*11音声／ビデオのUE（User Equipment）*12-Satellite-UE通信*13を扱った．この新機能により，衛星あるいは衛星コンステレーション*14内でのセッション*15の処理，スイッチングが可能になり，遅延削減，通信効率向上，および地上網への依存軽減が実現された[2]～[5]．
UE-Satellite-UE通信では，2つの端末が地上網を通過せずに衛星を介して通信する．これは，地上インフラストラクチャが十分に使用できない場合，あるいは，緊急時において特に役立つ．また通信時には，衛星もしくは衛星コンステレーション内ルーティングを使用してメディア送受信経路を最適化すると，遅延やフィーダリンク*16の消費が減少する．
前述したRel-17からRel-19に至る発展を図1に示す．
本稿では，Rel-19におけるUE-Satellite-UE通信のアーキテクチャについて，SA WG2が仕様化した内容に基づいて解説する．

02. UE-Satellite-UE通信の設計原則

Rel-19で導入されたUE-Satellite-UE通信機能は，NTNトラフィックの処理方法に大きな変化をもたらす．従来，NTNが提供する2つの端末間の通信では，両方の端末が同じ衛星カバレッジ内に配置されている場合でも，地上コアネットワークを介したパケットのルーティングが含まれる．この「最適化されていない」ルーティングには，衛星と地上との間の経路を複数回通過することによる長い伝搬遅延が含まれ，これは，数百ミリ秒程度の合計エンド・ツー・エンド遅延に繋がる可能性がある．
最適化されていないUE-Satellite-UE通信経路と最適化されたUE-Satellite-UE通信経路の違いについて，一例を図2および図3に示す．
最適化されていないUE-Satellite-UE通信の場合，その経路は，図2に赤色で示されているとおり，端末2に到達する前に地上のコアネットワークを通過する．その際，地上の5GC（5G Core network）*17を介した端末1から端末2への経路は，図中の番号のようになる．なお，最適化されていない経路は，図に示すように地上のNTNゲートウェイ*18を介して地上の5GCに到達する．
一方，図3に示す最適化UE-Satellite-UE通信において，端末1からのユーザプレーントラフィックは，端末1に対応する衛星搭載コアネットワーク機能を経由し，その後，端末2に対応するコアネットワーク機能を経由し，端末2に送信される．この経路は図中に緑色で示されている．
なお，Rel-19のUE-Satellite-UE通信では，両方の端末が同じ移動通信網の加入者である場合のみを扱い，加えて，ローミング*19は扱わないことにしている．さらに，検討対象の通信ユースケースはIMSベースの音声およびビデオサービスに限定されている．

03. アーキテクチャと呼設定手順

3.1 アーキテクチャ

IMSにおけるUE-Satellite-UE通信のためのRel-19拡張機能では，各衛星に重要な機能エンティティ*20が搭載されている．具体的にはIMSアクセスゲートウェイ（IMS-AGW：IMS Access Gateway）*21，アップリンク分類ノード（UL-CL：UpLink CLassifier）*22，および，ローカルPDU（Protocol Data Unit）セッション*23アンカー（L（Local）-PSA（PDU Session Anchor）*24）が衛星に搭載される．PSA UPF（User Plane Function）*25は，衛星移動時にも端末のIPアドレスの維持を保証するために地上に配置される．これによりセッションが固定され，モビリティとセッション管理のシームレスなサポートが保証される．なお，IMSコントロールプレーン*26（P-CSCF（Proxy-Call Session Control Function）*27，S-CSCF（Serving-CSCF）*28など）も地上のネットワークに残る[5]．

3.2 呼設定手順

呼設定手順は，図4に示すように，衛星対応ルーティングに対応するための拡張機能を備えた通常のIMS呼設定手順に従う．なお，図は呼設定手順全体の主要な手順のみを示している[5]．図の各ステップは以下のとおり．
①発端末は通常どおり，SIP（Session Initiation Protocol）*29 INVITE*30を送信する．
②発P-CSCFは，地上5GCから発端末を収容する衛星の識別子を取得する．
③発P-CSCFは，地上IMS-AGWを設定する．
④発P-CSCFは，発側の衛星の識別子を含むSIP INVITEを着側に送信する．なお，本ステップ以降，発側と着側との間のSIPメッセージの交換は地上経路で行われる．
⑤着P-CSCFは，地上IMS-AGWを設定する．
⑥着P-CSCFは，着端末に対してSIP INVITE，およびその応答を送受信する．
⑦着P-CSCFは，地上5GCから着端末を収容する衛星の識別子を取得する．
⑧着P-CSCFは，発側衛星識別子と着側衛星識別子とから，衛星上での最適化ルーティングが可能と判定する．着P-CSCFは，衛星搭載IMS-AGWを設定する．
⑨着P-CSCFは，地上IMS-AGWを解放する．
⑩着P-CSCFは，地上5GCに指示し，衛星上のUL-CL/L-PSAを設定させる．
⑪着P-CSCFは，着側の衛星の識別子を含む応答メッセージを発側に送信する．
⑫発P-CSCFは，発側衛星識別子と着側衛星識別子とから，衛星上での最適化ルーティングが可能と判定する．発P-CSCFは，衛星搭載IMS-AGWを設定する．
⑬発P-CSCFは，地上IMS-AGWを解放する．
⑭発P-CSCFは，地上5GCに指示し，衛星上のUL-CL/L-PSAを設定させる．
⑮発P-CSCFは，発端末に応答メッセージを送信し，次のメッセージを受信する．
⑯発P-CSCFは，衛星搭載IMS-AGWの設定情報を含むメッセージを着側に送信する．
⑰着P-CSCFは，衛星搭載IMS-AGWの設定を更新する．
⑱着P-CSCFは，衛星搭載IMS-AGWの設定情報を含むメッセージを着端末に送信する．

この呼設定の後，発信側端末および着信側端末からの音声などのメディアは，遅延とリソース使用量を最小限に抑えて衛星上で転送される．

04. モビリティ処理：衛星の変更・端末のモビリティ

NTN環境，特にLEO衛星を利用している環境では，衛星の動的な性質と高速性から，モビリティには固有の課題がある．衛星は地球の周りを継続的に周回しているため，端末が地理的に静止している場合でも，頭上の衛星は高速に移動する可能性がある．これにより，端末にサービスを提供する衛星が頻繁に変更される．研究によると，LEO接続は通常，衛星がカバレッジから外れるまで5～15分続くことが示されている[6]．これは，端末が静止している場合でも，特定の衛星から最大で15分程度のカバレッジしか期待できないことを意味する．
従って，シームレスなサービス継続性を確保し，進行中の通話が切断されることを防ぐことが最も重要になる．この点が，UE-Satellite-UE通信の検討における重要なポイントである．具体的には，衛星がカバレッジ外に移動した場合でも，特定の要件が満たされていれば，進行中の通話が（端末がカバレッジ内にある）別の衛星に引き渡されることで，通話の継続性が保証されることが求められる．
Rel-19では，衛星移行中にメディア継続性を維持するために，継続最適化メディアルーティング手順と地上フォールバック*31手順という2つの相互補完的な手順が導入されている[5]．地上5GCは，端末を収容している衛星が移動し，端末が衛星基地局間でハンドオーバ*32すると，移動先基地局が所在する衛星の衛星識別子をP-CSCFへ通知する（「EARLY」通知）．P-CSCFは，移動先衛星においても引き続きユーザトラフィックを衛星上でルーティングできると判断した場合は，継続最適化メディアルーティング手順を起動する．また，継続不可能と判断した場合は，いったん地上局に接続する地上フォールバック手順を起動する．
なお，これら2つの手順は，前半部分は異なるが，後半部分は多くの部分が共通である．以下では各手順の前半部分を示し，後半の共通部分をSIP RE-INVITE手順として解説する．

4.1 継続最適化メディアルーティング手順

継続最適化メディアルーティング手順の前半部分を図5に示す．図の各ステップは以下のとおり．
①P-CSCFは，地上5GCから移動先衛星識別子を含む「EARLY」通知を受信する．
②P-CSCFは，移動先衛星識別子と対向端末を収容する衛星の識別子とから，衛星上での最適化ルーティングの継続が可能と判定する．P-CSCFは，移動先IMS-AGWを設定し，端末向けのメディア通信用のIPアドレスを取得する．
③P-CSCFは，上記IPアドレスを含むメッセージを地上5GCに送信する．地上5GC内のSMF（Session Management Function）*33は，上記IPアドレスを用いて，移動先衛星上の通信振分け（UL-CL/L-PSA）を設定する．移動元衛星も設定する．SMFは端末にも上記IPアドレスを通知する．端末は，当該IPアドレスをメディア用のQoS（Quality of Service）*34フローに括り付ける．

4.2 地上フォールバック手順

地上フォールバック手順の前半部分を図6に示す．図の各ステップは以下のとおり．
①P-CSCFは，5GCから移動先衛星識別子を含む「EARLY」通知を受信する．
②P-CSCFは，移動先衛星識別子と対向端末を収容する衛星の識別子とから，衛星上での最適化ルーティングが継続できないと判定する．P-CSCFは，地上IMS-AGWを設定し，端末向けのメディア通信用のIPアドレスを取得する．
③P-CSCFは，上記IPアドレスを，5GC経由で端末に通知する．端末は，当該IPアドレスをメディア用のQoSフローに括り付ける．

4.3 SIP RE-INVITE手順

継続最適化メディアルーティング手順と地上フォールバック手順が共通にもつ後半部分を示す．どちらの手順においても新しいIMS-AGWが設定されたため，発信側と着信側の間でメディア転送アドレスの再交渉が必要になる．また地上フォールバック手順の場合は，対向網で地上IMS-AGWを設定することも必要である．これらは，SIP RE-INVITE手順を介して処理される．
SIP RE-INVITE手順を図7に示す．図の各ステップは以下のとおり．
①前述の2つの手順のいずれかの後，P-CSCFはIMS-AS（Application Server）*35に，新規IMS-AGWで割り当てられた対向網向けのメディア通信用のIPアドレスを含むメッセージを送信する．継続最適化メディアルーティング手順が実行された場合は，移動先衛星識別子も含める．
②IMS-ASは上記の情報を含むSIP RE-INVITEを対向網に送信する．対向網のP-CSCFは，移動先衛星識別子があれば継続最適化メディアルーティング手順と判断し，設定済みのIMS-AGWを使い続け，なければ，地上フォールバック手順と判断し，地上のIMS-AGWを設定する．いずれにせよ，IMS-AGWの設定が行われる．後者の場合，端末の設定も行う．
③端末からの応答を受けたP-CSCFは，地上のIMS-AGWを設定する場合は，引き続き当該IMS-AGWの設定を行う．その後，IMS-ASに向けて応答する．
④IMS-ASは，上記SIP RE-INVITEの応答を受信すると自網の端末に向けて，SIP RE-INVITEを送信する．地上フォールバック手順が実行された場合は，地上IMS-AGWの設定を継続する．
⑤端末はIMS-ASに応答する．

これにより，パケットを損失することなく，メディアの経路切替が完了する．

05. 未解決の問題と今後の方向性

Rel-19でUE-Satellite-UE通信の仕様化が完了したことは，NTNを介した直接ユーザ通信を可能にするための重要なステップであった．しかし，いくつかの重要な課題は未解決のままとなっている．
・IMS音声／ビデオ以外のサービス：Rel-19の範囲はIMSベースの音声およびビデオサービスに限定された．今後は，ミッションクリティカル*36なアプリケーション，直接データ交換，IMS以外のサービスなどの追加サービスのサポートを拡張する必要がある．
・PLMN（Public Land Mobile Network）*37間およびローミングのサポート：Rel-19では，両方の端末が同じPLMNに属しているという制約があり，ローミングは考慮されていない．なお，この観点は，Rel-20で具体的な検討が開始されている．
一方で，Rel-19にて導入したUE-Satellite-UE通信は，「ユビキタス接続の6Gビジョン」への足がかりとして機能し，完全に統合された地上／非地上の6Gネットワークへの進化の基盤を設定したと考えられる．

06. あとがき

本稿では，NTNの進化におけるマイルストーンである，Rel-19で仕様化されたUE-Satellite-UE通信機能について解説した．具体的には，衛星上に配置したIMSのゲートウェイとユーザプレーン機能が最適化されたメディアルーティングを実現し，IMSベースの音声およびビデオ通信のエンド・ツー・エンド遅延を大幅に削減する方法について説明するとともに，関連するセッション確立手順，モビリティ管理を詳述した．
本稿では，加えて，NTNの分野におけるさらなる標準化を必要とする領域を特定した．ドコモは，3GPPにおける5Gや6G標準化の推進に寄与しており，今後も5Gや6Gの標準仕様のさらなる発展に貢献していく．