スマートフォンが空を見上げるだけで衛星につながり、登山中の遭難者がメッセージを送れる — Appleの「衛星緊急SOS」やQualcommの「Snapdragon Satellite」、AST SpaceMobileやStarlink Directが切り拓いた世界は、もはやSFではなく日常のインフラに組み込まれつつあります。さらに地震や台風で地上基地局が壊滅した直後でも、上空のLEO衛星が即座にバックホールを担い、IoTセンサが海洋ブイから直接5Gコアにつながる時代が来ています。これらすべてを支えるのが、3GPPが標準化したNTN（Non-Terrestrial Network、非地上系ネットワーク）です。
NTNは「地上の3GPPセルラーシステムを、衛星・HAPS（成層圏プラットフォーム）・高高度UAVといった非地上ノードに拡張する」一連の技術群を指します。応用範囲は驚くほど広く、(1) スマートフォン直接接続（D2D: Direct-to-Device）による全球カバレッジ、(2) 海洋・航空・砂漠・極地のIoTセンサからのデータ収集、(3) 災害時の通信レジリエンス、(4) 自動車・列車・船舶への高速ブロードバンド、(5) 6Gで本格化する空・宇宙・地上の統合ネットワーク（SAGIN: Space-Air-Ground Integrated Network）へとつながります。
本記事の内容
- なぜ地上の3GPPでは足りず、NTNが必要になったのかというモチベーション
- GEO/MEO/LEO/HAPSの4つの非地上プラットフォームの特性比較
- 3GPP標準化の歩み（Rel-15スタディ → Rel-17で初導入 → Rel-18で拡張 → Rel-19以降）
- NR-NTN（5G NR系）とIoT-NTN（LTE-M/NB-IoT系）の使い分け
- 透過型（transparent / bent-pipe）と再生型（regenerative）ペイロードの違い
- NTN特有の技術課題（伝搬遅延・ドップラー・移動セル・電源制約）
- TA（Timing Advance）の拡張、ドップラー事前補償、HARQ設計の変更
- Pythonによる軌道高度別RTT・最大ドップラー・可視時間の比較
前提知識
この記事を読む前に、以下の概念に馴染みがあると理解がスムーズです。
- 衛星通信の基本（軌道・周波数・トランスポンダ）
- ドップラー効果の物理的意味
- セルラー通信のフレーム構造（OFDMサブキャリア、TDDスロット）
関連する既存記事として以下を参照すると、本記事のNTN特有の議論がより立体的に理解できます。
なぜNTNが必要か — カバレッジ・災害・IoTの3つの動機
最初に押さえておきたいのは、「地上の3GPPがすでにここまで普及しているのに、なぜわざわざ宇宙の衛星まで巻き込んで標準を作るのか」という問いです。これには大きく3つの動機があります。
まずカバレッジの根本的限界です。GSMA等の統計によると、地球の陸地のうち携帯電話が使える面積はおおむね20%程度にすぎず、海洋まで含めれば地表の5%以下しかセルラーで覆われていません。地上基地局は鉄塔・電源・光ファイバ・許認可・人口密度に依存するため、海洋・砂漠・山岳・極地・紛争地帯では原理的に展開できません。世界の人口の約30億人が、いまもブロードバンドにアクセスできていないと推定されています。LEOコンステレーションを1機の打ち上げで数十機ずつ展開できる時代になり、「衛星で地表全部を覆う」現実的なコストラインがついに見えてきたのです。
次に災害・緊急時のレジリエンスです。能登半島地震や東日本大震災で経験したように、地上の基地局は停電・倒壊・回線断で容易に機能を失います。Starlinkが災害支援で投入されたケースが象徴的ですが、衛星側のリンクは地上インフラに依存しないため、被災直後から即座にバックホールを担えます。Apple Emergency SOSが既に多くの遭難者を救助した実績も、緊急通信におけるNTNの価値を裏付けています。
最後にmassive IoTとの親和性です。海洋ブイ、農業センサ、コンテナトラッキング、パイプライン監視といったIoTデバイスは、地上カバレッジから外れた場所にも数百万台規模で散在します。1回の送信が数十〜数百バイト、送信頻度も1時間〜1日に1回程度であれば、衛星でも十分にカバーできます。3GPPはNB-IoT/LTE-Mをそのまま空に持ち上げるIoT-NTNを標準化することで、地上IoTのエコシステムを衛星に拡張しました。
このように、カバレッジ・レジリエンス・IoTという3つの大きな圧力が、3GPPに「NTNを正式な仕様として取り込まざるを得ない」決断をさせたのです。次に、NTNとは何を指すのかを正確に定義しましょう。
NTNの定義と4つのプラットフォーム
3GPP TR 38.811とTR 38.821では、NTNを次のように定義しています。「非地上ノード（衛星またはエアボーン・プラットフォーム）を、無線アクセスネットワーク（RAN）の一部として利用する通信ネットワーク」。ここで重要なのは、NTNが単独の独立技術ではなく、地上の5G NR/4G LTEと同じコアネットワーク（5GC/EPC）に統合される点です。ユーザーから見れば、つながっているのが地上基地局なのか衛星なのかを意識する必要はありません。
NTNを担うプラットフォームは大きく4種類に分類されます。それぞれ高度・遅延・可視時間が桁違いに異なり、ユースケースの選択を支配します。
GEO（Geostationary Orbit、静止軌道）: 高度約35,786 kmの赤道上空。地上から見ると静止しているため固定アンテナで追従不要、1機で地球表面の約1/3をカバーできるのが最大の強みです。一方で片道伝搬遅延が約120 msと長く、自由空間損失も巨大なため、低遅延サービスやスマートフォン直接接続には不向きです。放送・海事・航空ブロードバンドが主戦場です。
MEO（Medium Earth Orbit、中軌道）: 高度8,000〜20,000 km。GEOより低遅延でカバレッジも広く、SES O3bやO3b mPOWERが代表例です。アンテナの追従が必要ですが、LEOほどは速くないので追従系の負荷が中庸という、バランス型のプラットフォームです。
LEO（Low Earth Orbit、低軌道）: 高度500〜2,000 km。Starlink、OneWeb、Amazon Kuiperなどメガコンステレーションの主戦場です。片道遅延が数 msと地上光ファイバに匹敵し、自由空間損失も小さいため、ハンドヘルド端末でつなげる現実解として最有力です。ただし1機あたりの可視時間が約10分以下と短く、数百〜数千機の衛星が必要になります。
HAPS（High Altitude Platform Station、成層圏プラットフォーム）: 高度約20 km（成層圏）に滞空する飛行船や太陽電池UAV（Loon、HAPSMobile、Stratospheric Platforms等）。1機で半径数百 kmのエリアをカバーでき、遅延もmsオーダーと小さく、緊急展開や離島カバレッジに親和性があります。打ち上げではなく離陸で展開でき、メンテナンスも空中→地上の運用が可能というロジスティクスの利便性が独自の優位点です。
GEOからLEO、そしてHAPSへと高度を下げるにつれ、遅延と自由空間損失は減少しますが、必要機数とハンドオーバ頻度は増加します。この基本トレードオフを念頭に、次節では3GPPがどのように歴史的にこれを規格化してきたかを追います。
3GPP NTN標準化の歩み
3GPPがNTNに本格着手したのは2017年のRelease 15で、SI（Study Item）として研究フェーズに入りました。標準化の流れを年表的に整理します。
Rel-15（2017〜）— スタディアイテム: TR 38.811「Study on New Radio (NR) to support non-terrestrial networks」で、衛星・HAPS等の非地上シナリオが5G NRに導入された場合に何が問題になるかを徹底分析。シナリオA/B/C/D（透過/再生、ハンドヘルド/VSAT、GEO/LEO等の組み合わせ）が定義されました。
Rel-16（2019〜）— WIDに向けた追加スタディ: TR 38.821「Solutions for NR to support non-terrestrial networks」で、TA、ドップラー、HARQ、ランダムアクセス、ハンドオーバなどの具体的な解決策候補を検討。並行してIoT-NTN側ではTR 36.763でNB-IoT/LTE-MのNTN対応スタディも進行しました。
Rel-17（2022年6月凍結）— NTN初導入: ここが歴史的なマイルストーンです。NR-NTNとIoT-NTNが正規仕様として標準化され、初の「3GPP NTN準拠」のシステムが構築可能になりました。主な新機能は次の通りです。
- 拡張TA（タイミングアドバンス）: 上限値を数100 msまで拡張
- UE側ドップラー事前補償: 端末がGNSS位置とエフェメリスから自分でドップラーを補償
- 長HARQ RTT対応: HARQフィードバックを無効化／一部停止できるオプション
- 衛星エフェメリス放送: 衛星位置情報をシステム情報ブロック（SIB19）で配信
- セル切替（Earth-moving cell, Quasi-Earth-fixed cell）: LEOの高速移動への対応
Rel-18（2024年6月凍結）— 5G-Advanced NTN拡張: 性能改善とユースケース拡大が主軸です。
- 上りデータ・ボイス通話品質向上（Voice over NTN）
- モビリティ強化（衛星間ハンドオーバの低遅延化、条件付きハンドオーバの拡張）
- カバレッジ拡張（リピート送信、PUSCH/PUCCH強化）
- スマートフォン直接接続（D2D）の本格対応
- IoT-NTNの追加バンドと電源効率改善
Rel-19/20（2025〜）— 6G NTNへの橋渡し: 再生型ペイロード、衛星間リンク（ISL）の標準サポート、より高い周波数帯（Ka/Q-V）、SAGIN統合、ネットワーク内AI/MLによるドップラー予測などが議題に挙がっています。これらは6Gの空・宇宙・地上統合ネットワークへの基盤となります。
この標準化の歩みからわかるのは、3GPPがNTNを「5Gの拡張機能」ではなく「6Gコアの一部」として位置づけ始めている、という戦略的方向性です。次に、Rel-17で同時導入されたNR-NTNとIoT-NTNの違いを整理しましょう。
NR-NTN と IoT-NTN の違い
NTNには2つの系統があり、ユースケースに応じて使い分けます。
NR-NTNは5G NR（Rel-15以降）をベースに拡張した規格で、広帯域・高スループット用途が主戦場です。FR1（Sub-6 GHz）の一部とFR2-NTN（Ka帯等）が対象で、スマートフォンや車載端末、VSAT、機内Wi-Fiのバックホール等を想定しています。OFDMサブキャリア間隔は15/30/60/120 kHzが利用可能で、ドップラーシフトに対しては大きなサブキャリア間隔が有利です。
IoT-NTNはLTE-M（eMTC）とNB-IoTをベースに拡張した規格で、低消費電力・小データ・大量端末（massive IoT）用途を狙います。物理層は地上のLTE-M/NB-IoTとほぼ共通で、NTN特有の長伝搬遅延と大ドップラーを吸収する仕組みだけを追加しました。バッテリー駆動のセンサが10年以上動作する設計が可能で、コンテナ追跡・農業・海洋ブイなどに最適です。
両者の主な違いを表で整理します。
| 項目 | NR-NTN | IoT-NTN（NB-IoT/LTE-M） |
|---|---|---|
| ベース規格 | 5G NR | LTE-M / NB-IoT |
| 周波数帯 | FR1（S/L帯）+ FR2-NTN（Ka） | L/S帯中心 |
| サブキャリア間隔 | 15〜120 kHz | 3.75/15 kHz（NB-IoT） |
| 主な用途 | スマホ直接接続・広帯域 | 低速IoT・センサ |
| 端末電力 | 通常〜中 | 超低電力（10年電池） |
| データレート | Mbps級 | kbps〜数10 kbps |
| 主な対象LEO | Starlink Direct, AST SpaceMobile | Skylo, OQ Technology |
NR-NTNとIoT-NTNはいずれもRel-17で同時に標準化されており、3GPPは「広帯域とIoTを片方ずつ標準化する」のではなく、最初から両者をパッケージで提供することにこだわった点が興味深いところです。次に、衛星に搭載されるペイロードのアーキテクチャに目を移します。
透過型ペイロード vs 再生型ペイロード
NTNの衛星に搭載するペイロードには、大きく2つのアーキテクチャがあります。3GPPの用語でtransparent payload（透過型／bent-pipe）とregenerative payload（再生型）です。両者の違いを正確に理解することは、NTNシステム設計の核心です。
透過型ペイロードは、衛星を「空に浮かぶ周波数変換中継器」として使う方式です。地上のgNB（基地局）と地上のUE（端末）の間に衛星が物理的に挟まり、衛星は受信信号を周波数変換・増幅して、もう一方のリンクに送出するだけ。L1/L2のプロトコル処理は地上のgNBが担い、衛星は搬送波の中継器として振る舞います。設計が単純で、衛星側のSWaP（Size, Weight, Power）が小さく済むため、現行のStarlink初期世代もこの方式です。
再生型ペイロードは、衛星にgNBの機能（Layer 1/2の処理、変調・復調、誤り訂正、ルーティング）を実装する方式です。衛星はもはや「中継器」ではなく「軌道上の基地局」となります。これにより、(1) 衛星間リンク（ISL）でユーザデータをそのままルーティング可能、(2) 雑音の累積がない、(3) 周波数効率が向上、といった大きなメリットが得られますが、衛星側の処理負荷・消費電力・耐放射線設計が一気に複雑化します。Rel-17では透過型のみが標準化され、再生型はRel-19以降で本格対応される見込みです。
両ペイロードの違いを式で表現すると、たとえばエンドツーエンドのSNRは透過型では次のように2区間の合成になります。
$$ \frac{1}{\mathrm{SNR}_{e2e}} \approx \frac{1}{\mathrm{SNR}_{UL}} + \frac{1}{\mathrm{SNR}_{DL}} $$
これは「直列接続された通信路の雑音は加算的に劣化する」という古典的な関係で、フィーダリンクとユーザリンクの両方の品質が悪化を引き起こすことを意味します。一方で再生型では衛星上で復調・再変調が行われるため、上りで一旦ビット列に戻されてから新しい変調で送出され、雑音の累積がリセットされます。
$$ \mathrm{SNR}_{e2e}^{regen} \approx \min(\mathrm{SNR}_{UL}, \mathrm{SNR}_{DL}) $$
つまり再生型では「より悪い方の区間が支配的」になるだけで、加算劣化はありません。LEOコンステレーションでマルチホップを多用する場合、この差は累積して大きな性能差を生みます。
ペイロード方式の選択は、衛星の電力・質量予算とミッション寿命を直接左右します。次に、NTN特有の物理的課題に深入りしていきましょう。
NTN特有の技術課題
NTNが地上の3GPPに比べて根本的に難しいのは、衛星の物理的状況が地上基地局と全く違うためです。代表的な4つの技術課題を整理します。
1. 巨大な伝搬遅延
地上のセルラーでは基地局と端末の距離はせいぜい数km、遅延は数〜数十μsです。これがNTNでは桁が3〜5桁跳ね上がります。光速 $c = 3 \times 10^8$ m/s で割れば、高度 $h$ の衛星と地上の片道遅延 $\tau_{ow}$ は最小（直下視）で:
$$ \tau_{ow} = \frac{h}{c} $$
LEO（550 km）で約1.8 ms、MEO（8,000 km）で約27 ms、GEO（35,786 km）で約120 ms。実際には仰角 $\epsilon$ が低くなるほど経路長が伸びるため、スラントレンジ $d$ は次のようになります。
$$ d(\epsilon, h) = \sqrt{R_E^2 \sin^2\epsilon + 2 R_E h + h^2} – R_E \sin\epsilon $$
ここで $R_E = 6,378$ km は地球半径です。仰角が10度なら、LEOでもスラントレンジが1,900 km近くになり遅延も6 ms程度まで増えます。
2. ドップラーシフト
LEOは秒速約7.6 km/sで移動するため、ユーザリンクの相対視線速度は瞬時に1〜2 km/sに達します。搬送波周波数 $f_c$ におけるドップラーシフト $f_d$ は:
$$ f_d = \frac{v_r}{c} f_c $$
ここで $v_r$ は視線速度（接近で正）。S帯（2 GHz）でLEOの場合、最大ドップラーは約±50 kHz、Ka帯（20 GHz）では約±500 kHzにもなり、地上LTEのサブキャリア間隔（15 kHz）を遥かに超えます。さらにドップラー変化率（フェロドップラー）も無視できず、
$$ \dot f_d = \frac{1}{c} \frac{dv_r}{dt} f_c $$
これがOFDMサブキャリア間直交性を破壊します。
3. セルの移動と頻繁なハンドオーバ
LEO衛星のフットプリント（地上の照射エリア）は秒速約7 kmで地表を流れていきます。地上UEから見れば「セルが動いている」ことになり、地上のような「UEが動いて新セルに入る」ハンドオーバとは逆の現象が生じます。3GPPはこれをEarth-moving cell（セルが動く）とQuasi-Earth-fixed cell（衛星はビームを地上に固定追尾して見かけ上のセル位置を固定）の2モードで定義しています。
4. 電源・冷却・耐放射線の制約
地上基地局は商用電源と冷却インフラが使えますが、衛星は太陽電池とバッテリー、ヒートパイプとラジエータだけが頼り。1機あたりの送信電力は限られ、夜間（地球の影に入る周回）にはバッテリーで運用する必要があります。さらに宇宙放射線でICが劣化するため、地上の最新プロセスをそのままは使えません。これらが「衛星側ではどこまで処理を載せられるか」のハード制約になります。
これら4つの課題は互いに絡み合います。次節では、特にRel-17で重要な制度変更となった「TA拡張」と「HARQ設計」を取り上げます。
TA補償とHARQの設計変更
3GPPがNTNを既存のLTE/NRに接ぎ木するうえで、最も大きく書き換えなければならなかったのがTA（Timing Advance）とHARQの取り扱いです。
TA（Timing Advance）の拡張
地上セルラーでは、各UEの上り送信タイミングを基地局側の受信フレームに揃えるために、TAという補正値が使われます。地上ではセル半径が最大100 km程度なので、TA上限は約0.67 ms（200 μsオーダーを少し超える程度）で十分でした。
ところがNTNではUEから衛星までの片道遅延が、LEOで数 ms、GEOで100 ms超。UEは「自分の信号が衛星に届いて、その後さらに地上ゲートウェイのgNBに届く」までの遅延を見込んで送信せねばならず、TA上限を数十〜数百msまで広げる必要が生じました。Rel-17では具体的に、UE側で自律的にTAを計算する仕組みが導入されました。UEはGNSSで自位置を知り、SIB19で配信される衛星エフェメリス（軌道情報）から衛星位置を計算、視線距離 $d$ から自分でTAを推定します。
$$ TA_{UE} = 2 \cdot \frac{d(t)}{c} + TA_{common} $$
ここで $TA_{common}$ は衛星〜地上ゲートウェイ間の共通遅延で、SIBで配信されます。UEが自分で計算する部分（UE-specific TA）とネットワークが配信する共通部分（common TA）を組み合わせる、というのがRel-17のエレガントな解決策です。
HARQの設計変更
HARQ（Hybrid Automatic Repeat reQuest）は、地上のLTE/NRで再送制御を素早く回す要の機能で、典型的なRTTは4 ms前後を想定しています。ところがNTNでは、
- LEO（550 km）: RTT ≈ 4 ms（運がよければギリギリ）
- MEO（8,000 km）: RTT ≈ 54 ms
- GEO（35,786 km）: RTT ≈ 240 ms
となり、特にGEOではHARQバッファのストールが致命的になります。地上のHARQプロセス数は最大16ですが、GEOで4 msに1回パケットを送出するとフィードバックが返ってくる前に60プロセスが詰まる、という計算になります。
3GPPはこれを次の2方針で吸収しました。
- HARQプロセス数の拡張: NR-NTNではプロセス数を最大32に拡張
- HARQフィードバックの無効化: 特定プロセスについて「ack/nackを返さない（disable）」モードを許可
HARQを無効化すると再送はRLC層（より高位のレイヤ）でカバーされます。これにより物理層は「フィードバック待ち」のストールから解放され、GEOでも実用的なスループットが出るようになりました。
TAとHARQの両方が、地上の前提（数msのRTT、200μsのTA）を根本から書き換える必要があり、NTNが単なる「衛星にgNBを置くだけ」では済まない理由がここにあります。次節では、これら理論的議論をPythonで定量的に体験してみましょう。
Pythonで軌道高度別の往復遅延・ドップラー比較
ここまでの理論を、軌道高度別に数値で確認します。GEO/MEO/LEO/HAPSのそれぞれで、(1) 仰角ごとのスラントレンジ、(2) 往復遅延、(3) 最大ドップラー、(4) 1機あたりの可視時間、を可視化してみましょう。
import numpy as np
import matplotlib.pyplot as plt
# 定数
c = 3e8 # 光速 [m/s]
R_E = 6378e3 # 地球半径 [m]
mu = 3.986e14 # 地心重力定数 [m^3/s^2]
# プラットフォーム定義（名前, 高度[m]）
platforms = [
("HAPS", 20e3),
("LEO", 550e3),
("MEO", 8000e3),
("GEO", 35786e3),
]
# 仰角を 10〜90 度で振る
elev_deg = np.linspace(10, 90, 81)
elev_rad = np.deg2rad(elev_deg)
def slant_range(h, eps):
"""高度h, 仰角epsからスラントレンジを計算"""
return np.sqrt(R_E**2 * np.sin(eps)**2 + 2*R_E*h + h**2) - R_E*np.sin(eps)
fig, ax = plt.subplots(1, 2, figsize=(12, 4))
for name, h in platforms:
d = slant_range(h, elev_rad)
rtt = 2 * d / c * 1e3 # 往復遅延 [ms]
ax[0].plot(elev_deg, d/1e3, label=name)
ax[1].plot(elev_deg, rtt, label=name)
ax[0].set_xlabel("Elevation angle [deg]")
ax[0].set_ylabel("Slant range [km]")
ax[0].set_yscale("log")
ax[0].set_title("Slant range vs elevation")
ax[0].legend(); ax[0].grid(True, which="both", alpha=0.3)
ax[1].set_xlabel("Elevation angle [deg]")
ax[1].set_ylabel("Round-trip delay [ms]")
ax[1].set_yscale("log")
ax[1].set_title("Round-trip propagation delay")
ax[1].legend(); ax[1].grid(True, which="both", alpha=0.3)
plt.tight_layout()
plt.show()
上のグラフから3つの重要な特徴が読み取れます。第1に、仰角が低いほどスラントレンジは急増することで、特にHAPSは仰角10度と90度で20倍近く差が出ます。第2に、RTTは軌道高度で4桁ものレンジを持ち、HAPSの0.1 ms台からGEOの250 ms近くまで広がります。これがHARQ設計を高度ごとに切り替えなければならない根拠です。第3に、LEOでも仰角10度では往復で約13 msに達するため、3GPPがHARQプロセス数を増やしたのは妥当な選択だとわかります。
次に、ドップラーシフトを軌道高度・搬送波周波数で比較します。
def orbital_velocity(h):
"""高度hの円軌道速度 [m/s]"""
return np.sqrt(mu / (R_E + h))
# 衛星の地心速度（HAPSは便宜上 50 m/s の対地速度として扱う）
def platform_velocity(name, h):
if name == "HAPS":
return 50.0
return orbital_velocity(h)
# 搬送波周波数 [Hz]
freqs = {"S-band (2 GHz)": 2e9, "L-band (1.5 GHz)": 1.5e9, "Ka-band (20 GHz)": 20e9}
print(f"{'Platform':<6} {'V [m/s]':>9} {'Max Doppler @ S':>17} {'Max Doppler @ Ka':>20}")
for name, h in platforms:
v = platform_velocity(name, h)
fd_S = v/c * freqs["S-band (2 GHz)"]
fd_Ka = v/c * freqs["Ka-band (20 GHz)"]
print(f"{name:<6} {v:>9.1f} {fd_S/1e3:>14.2f} kHz {fd_Ka/1e3:>17.2f} kHz")
このコードを実行すると、LEOではS帯で約±50 kHz、Ka帯で約±500 kHzという巨大なドップラーが見えてきます。LTEのサブキャリア間隔15 kHzを軽く超えることが定量的に確認でき、なぜNR-NTNでサブキャリア間隔を15〜120 kHzから選べるよう拡張したかが体感できます。MEO/GEOではプラットフォーム自身の対地速度が小さく、ドップラーも小さいため、UEが動いていない限り問題になりません。
最後に、1機あたりの可視時間（パス長）をシミュレートします。LEO衛星はわずか数分から十数分で頭上を通り過ぎるため、ハンドオーバ周期が支配的になります。
# 簡易: 円軌道で衛星が天頂を通る場合の可視時間
def visibility_pass(h, elev_min_deg=10.0):
"""仰角elev_min以上で見える時間 [s] を概算"""
eps_min = np.deg2rad(elev_min_deg)
# 中心角 (地心) ベース
# cos(central_angle) = (R_E/(R_E+h)) * cos(eps_min)
central = np.arccos((R_E / (R_E + h)) * np.cos(eps_min)) - eps_min
# 周回角速度
omega = np.sqrt(mu / (R_E + h)**3)
# 天頂通過時の可視区間（地球自転は無視）
return 2 * central / omega
for name, h in platforms[1:]: # HAPSは静止扱いなので除外
t = visibility_pass(h)
print(f"{name}: visibility pass ≈ {t:.1f} s ({t/60:.2f} min)")
実行結果は概ね、LEO（550 km）で約10分、MEO（8,000 km）で約1時間40分、GEO（35,786 km）で実質的に永続的に可視となります。LEOの10分というのは、ハンドオーバを少なくとも10分以内に1回行う必要があることを意味し、3GPPがRel-17でConditional Handover（条件付きハンドオーバ）をNTN向けに大幅拡張した理由が直接見えてきます。逆にGEOではハンドオーバはほぼ発生せず、衛星サービスの設計思想が根本から異なる点も腑に落ちます。
これらPython実験を通じて、軌道高度の選択が遅延・ドップラー・ハンドオーバ周期というシステム設計上の3大パラメータを支配することが定量的に理解できました。次に、これらが実際にどのようなユースケースを生んでいるかを見ていきます。
ユースケース — D2D・IoT・海洋・航空
NTNの規格がそろってきたことで、ようやく現実のサービスが立ち上がりつつあります。代表的な4つのユースケースを整理します。
スマートフォン直接接続（D2D）: AppleのEmergency SOS via Satellite（GlobalstarのLEO衛星と連携）、Snapdragon Satellite、AST SpaceMobileの「BlueWalker 3」、Starlink Directなど。3GPP Rel-17/18のIoT-NTN/NR-NTNが規格的な後ろ盾を提供し、Rel-18からはVoice over NTNも視野に入っています。緊急SOS、テキストメッセージ、低速データから始まり、6G時代には音声・低レートビデオまで広がるロードマップです。
massive IoT: コンテナトラッキング、農業センサ、海洋ブイ、パイプライン監視、野生動物GPSカラーなど。Skylo、OQ Technology、Sateliotといったオペレータが、NB-IoT/LTE-Mのチップセットそのままを衛星対応化することで、地上IoTのエコシステムを宇宙に拡張しています。電力制約が厳しい用途では、衛星側ではなく端末側の省電力化が決定的に重要です。
海洋・航空ブロードバンド: 船舶・航空機の通信は従来、Inmarsat等のGEO衛星のVSATが主役でした。NTN準拠のLEO/MEOサービスが入ってくることで、低遅延・高スループットなブロードバンドが期待でき、機内Wi-Fi品質の劇的改善や、洋上クルーズ船での4K配信が現実的になっています。
自動車・コネクテッドカー: トヨタ・BMW・GMがLEO衛星を経由した車両通信に投資しており、地上カバレッジが切れる山間部・砂漠・海底トンネル直後等での「途切れない接続」がNTNの提供価値です。eCallのようなセーフティクリティカルな用途では特にNTNが効きます。
これらユースケースの共通点は、「地上3GPPだけでは原理的に届かないエリア」を埋める補完的役割と、「地上3GPPと完全シームレスに統合される」両立性です。NTNが単独サービスではなく、地上ネットワークのエコシステム拡張として位置づけられている理由が、ユースケースを見ても明確になります。
まとめ — 6G NTNへの展望
本記事では、3GPP NTNの全体像をRel-17の初導入からRel-18拡張、4つのプラットフォーム比較、ペイロード方式、技術課題、そして実装上のTA・HARQ設計まで、体系的に俯瞰しました。要点を改めて整理します。
- NTNは5G/6Gの正規構成要素: 3GPP Rel-17で標準化され、地上の5GCと完全統合される
- 4つのプラットフォーム: GEO/MEO/LEO/HAPSが用途別にすみ分け
- 2系統の規格: 広帯域のNR-NTNと低電力IoTのIoT-NTNが同時に立ち上がった
- 2方式のペイロード: 透過型（Rel-17）と再生型（Rel-19以降）でアーキテクチャが大きく変わる
- 4つの技術課題: 巨大遅延・ドップラー・移動セル・電源制約が地上規格を根本から書き換える要因
- 設計変更の核: TA上限の数100ms拡張、HARQプロセス数拡張・フィードバック無効化
6GのNTNはここからさらに飛躍します。再生型ペイロードと衛星間リンク（ISL）の標準化により、衛星単体ではなく軌道上ネットワーク全体が3GPPコアの一部として動くSAGINが見えてきます。AI/MLによるドップラー予測やビームフォーミング最適化、量子鍵配送（QKD）との統合、月・火星通信への拡張（CCSDS連携）も6G NTNの射程に入ってきました。
次のステップとして、以下の関連記事もぜひ参照してください。
NTNはまだ規格的にも実装的にも進化の途上にありますが、地上の3GPPがそうであったように、これから10年で社会インフラの一部として深く根付いていくはずです。本記事がその全体像をつかむ最初の一歩になれば幸いです。