5Gアップリンクの隠れた主役：DFT-s-OFDMとCP-OFDMの物理層からTCPスタックまでの深層最適化
モデムが拾う電波のアンテナピクトが最高潮に達していても、なぜかTLSハンドシェイクの初回RTT（Round Trip Time）でパケットロスが起き、APIレスポンスが妙にもたつく。インフラエンジニアやテックリードであれば、こうした「無線区間特有の不可解な遅延」に一度は頭を悩ませたことがあるはずです。
多くのエンジニアは、パケットがルーターを通過した後のレイヤー3やレイヤー4のチューニング、例えばBBR混雑制御アルゴリズムの適用やTLS 1.3の0-RTT（Zero-RToT）有効化に終始しがちです。しかし、そのパケットがまさに「空中を飛ぶ瞬間」、物理層（Layer 1）でどのような変調波形が使われ、それがハードウェアの電力増幅器（PA: Power Amplifier）にどのような負荷をかけているかまで目を向けている人はどれほどいるでしょうか。
今回は、5G NR（New Radio）のダウンリンクで標準採用されるCP-OFDMと、アップリンクで省電力・カバレッジ拡張のために選択されるDFT-s-OFDM（Discrete Fourier Transform-spread OFDM）の内部挙動を徹底解剖します。単なる無線理論の解説にとどまらず、それがLinuxカーネルのTCPバッファ、ROHC（Robust Header Compression）、そして実際のTLSハンドシェイクのパフォーマンスにどう直結するのか、現場のインフラ設計に即して深掘りしていきます。
—
1. 物理層の根本思想：なぜアップリンクだけ波形が変わるのか
まずはパケットがベースバンドプロセッサからRF（高周波）フロントエンドへ送られる直前のレイヤー、物理層の泥臭い現実から始めましょう。
5G NRのダウンリンク（基地局から端末へ向かう通信）では、マルチパス耐性が高く、周波数利用効率に優れる CP-OFDM（Cyclic Prefix – Orthogonal Frequency Division Multiplexing） が採用されています。数百から数千の直交するサブキャリアにデータを分散させ、シンボル間にガードインターバル（サイクリックプレフィックス）を挿入することで、都市部のビル群で発生するマルチパス干渉（遅延波）をきれいに相殺します。
しかし、このCP-OFDMには致命的な弱点があります。それは、多数のサブキャリアがランダムな位相で重なり合った瞬間に、平均電力に対して瞬間的なピーク電力が跳ね上がるという性質です。これを電気通信の世界では PAPR（Peak-to-Average Power Ratio：ピーク対平均電力比）が高い と表現します。
PAPRが引き起こすハードウェアの悲劇
基地局側は無尽蔵に近い電力供給と強靭な冷却機構を備えているため、高いPAPRを持つCP-OFDMを増幅しても問題ありません。しかし、バッテリー駆動で熱排熱の制限が厳しいスマートフォンやIoTデバイス（アップリンク）で高いPAPRの信号を送信しようとすると、大変な事態が発生します。
送信機の電力増幅器（PA）が非線形領域（サチュレーション領域）に突入し、信号がクリッピングされてしまうのです。これを避けるためには、PAを常に本来の能力よりも大幅に低い出力電力（バックオフ）で動作させる必要があり、結果として：
1. 電力効率（Power Efficiency）の著しい低下：バッテリーが凄まじい勢いで消耗する。
2. 送信電力の頭打ちによるカバレッジの縮小：基地局へ届く電波の到達距離が短くなり、セルエッジでのスループットが急落する。
この課題を解決するために、アップリンク（端末から基地局へ向かう通信）では、従来型のSC-FDMA（Single Carrier Frequency Division Multiple Access）の概念を拡張した DFT-s-OFDM が選択肢として浮上します。
—
2. DFT-s-OFDMとCP-OFDMの内部挙動：パケットからシンボルへの変換プロセス
では、DFT-s-OFDMは内部でどのような魔法を使っているのでしょうか。パケットデータが物理層で変調されるプロセスを追ってみましょう。
[MAC/RLC層 パケット]
↓
[変調 (QPSK / 16QAM / 64QAM / 256QAM)]
↓
[DFT (離散フーリエ変換) 処理] ← ★ここが肝（時間領域へ一度マッピングし直す）
↓
[サブキャリアマッピング (リソースグリッドへの配置)]
↓
[IFFT (逆高速フーリエ変換)]
↓
[CP (サイクリックプレフィックス) 付加] → [RF送信 (低PAPRでPAに優しい)]DFT-s-OFDMの最大の特徴は、IFFT（逆高速フーリエ変換）の「手前」に DFT（離散フーリエ変換）ブロック が挿入されている点です。これにより、周波数領域の信号を一度時間領域的な特性を持つ信号に変換してからサブキャリアにマッピングします。
結果として、見かけ上はマルチキャリア伝送でありながら、実質的に単一キャリア（Single-Carrier）に近い波形特性を維持でき、PAPRを劇的に引き下げることが可能になります。
どっちを使うべき？ 動的波形切り替えの判断基準
5G NRの仕様では、ネットワークの状態や端末の能力、カバレッジに応じて、アップリンクの波形をCP-OFDMとDFT-s-OFDMの間で動的に切り替える（Transform precodingの有効/無効）ことができます。
| 評価軸 | CP-OFDM (アップリンク利用時) | DFT-s-OFDM (SC-FDMA派生) |
| :— | :— | :— |
| PAPR / パワー効率 | 高い（PAのバックオフが必要、バッテリー消費大） | 低い（PAを高効率に駆動可能、省電力） |
| カバレッジ (セル端) | 不利（送信電力が制限される） | 有利（電波が遠くまで届きやすい） |
| 周波数スケジューリング | 柔軟（非連続なリソース割当が可能） | 制限あり（基本的に連続したリソース割当が必要） |
| 最大変調次数 | 最大256QAM（高スループット向き） | ネットワーク実装や端末能力により制限される場合あり（※最新規格では256QAM対応も進行中） |
| 最適なユースケース | 基地局近傍での大容量ファイルアップロード、超低遅延が必須の高負荷セッション | セルエッジでの安定通信、IoTデバイス、常時接続のバックグラウンド同期 |
インフラエンジニアとして注目すべきは、「スループットを極限まで追求するのか、それともパケットロスのリスクを減らしてハンドシェイクの安定性を担保するのか」というトレードオフが、まさにこの物理層の波形選択に依存しているという点です。
—
3. ネットワークスタックとトランスポート層への影響：RTT、TCP、TLSの最適化
物理層でDFT-s-OFDMが選ばれ、セルエッジや電波干渉環境下でも安定したリンクが維持されるとき、上位レイヤー（トランスポート層およびアプリケーション層）ではどのような恩恵を受けるのでしょうか。ここが本記事の核心です。
無線区間の不安定さは、そのままTCPの再送制御やTLSハンドシェイクの遅延に直結します。特にIoTデバイスやモバイルアプリからのアップリンク通信（POSTリクエストやデータ送信）において、パケットがドロップした際のコストは計り知れません。
TLS 1.3ハンドシェイクとアップリンクバーストの挙動
セキュアな通信の確立において、TLS 1.3は1-RTT（早期データの場合は0-RTT）でハンドシェイクを完了させます。しかし、Client Helloの送信時、アップリンクの物理層でパケットロスや再送が発生すると、TCPの初期スロースタートや再送タイマー（RTO: Retransmission Timeout）が発動し、レイテンシが跳ね上がります。
ここでDFT-s-OFDMによるカバレッジ拡張と低PAPRのメリットが効いてきます。電波状況が劣悪な環境であっても、送信電力の限界によるクリッピングが防がれ、変調エラー（EVO/EVM悪化）が抑制されるため、アップリンクのパケットドロップ率が物理層の段階で大幅に低下します。
結果として、TCPの輻輳ウィンドウ（cwnd）が安全に拡大し、TLSハンドシェイクの完了から最初のHTTPリクエスト送信までのRTTが極限まで短縮されるのです。
LinuxカーネルにおけるTCPおよびバッファチューニングの実践
モバイル通信の変動しやすい帯域幅と遅延（BDP: Bandwidth-Delay Productの変動）に対応するため、Linuxサーバー側のネットワークスタックは適切にチューニングされていなければなりません。以下に、モバイル網を収容するエッジサーバーやAPIサーバーで適用すべき、実用的なsysctl設定のサンプルを示します。
# /etc/sysctl.d/99-mobile-network-optimization.conf
# モバイルネットワーク（5G/LTE）のエッジサーバー向け最適化設定
# 1. 混雑制御アルゴリズムに BBR を採用
# 損失ベースのCUBICではなく、ボトルネック帯域とRTTを動的に計測するBBRにより、
# 無線区間のパケットロスを「輻輳」と誤認してスループットを落とす挙動を防ぎます。
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
# 2. TCPバッファの動的チューニング範囲の拡大 (最小, デフォルト, 最大 [bytes])
# 変動するBDP（Bandwidth-Delay Product）に追従し、高スループットを維持します。
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 3. ウィンドウのスケーリングを有効化
net.ipv4.tcp_window_scaling = 1
# 4. 早期再送（TLP: Tail Loss Probe / F-RTO）の最適化
# アップリンクでの突発的なロスに対して、RTO（数秒の待機）を発生させる前に
# 迅速にパケットを救出するための設定
net.ipv4.tcp_sack = 1
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_fin_timeout = 15この設定を適用することで、物理層（DFT-s-OFDM等による安定したリンク）とトランスポート層（BBRによる賢い輻輳制御）が噛み合い、モバイル端末からのアップリンク性能が劇的に安定します。
—
4. ヘッダー圧縮（ROHC）とパケットオーバヘッドの極限削減
モバイル通信、特にアップリンクにおいてもう一つ見落とせないのが パケットオーバヘッドの比率 です。
5GやIoTのユースケースでは、センサーデータやGPS位置情報など、ペイロード（実際のデータ本体）が数十バイトしかない小さなパケットが大量に飛び交います。このとき、IPヘッダー（20バイト）、UDP/TCPヘッダー（20〜32バイト）、そしてTLSレコードヘッダー（5バイト）が合わさると、「中身よりヘッダーの方が大きい」という本末転倒な状態になり、限られた無線リソースが無駄に消費されます。
ここで登場するのが ROHC（Robust Header Compression：RFC 3095 / RFC 4995など） です。
ROHCの仕組みとネットワークへのインパクト
ROHCは、パケットヘッダーのフィールド（IPアドレス、ポート番号、シーケンス番号など）の中で、パケットごとに変化するものと、セッションを通じて静的なものを動的に分離し、静的な部分は通信開始時に一度だけ共有して、変化する部分のみをわずか数ビット〜数バイトに圧縮して無線区間（PDCPレイヤー）を流します。
[通常パケット]
+-------------------+-------------------+-------------------+-----------------+
| IP Header (20B) | TCP Header (32B) | TLS Header (5B) | Payload (20B) | (合計 77Bytes)
+-------------------+-------------------+-------------------+-----------------+
[ROHC圧縮後 (無線区間)]
+-------------------+-----------------+
| ROHC Context (3B) | Payload (20B) | (合計 23Bytes) ★劇的な帯域削減
+-------------------+-----------------+インフラアーキテクトやセキュリティ専門家が留意すべき点は、このROHCやセキュアなトンネリング（IPsecやWireGuardなど）を設計する際、「暗号化がヘッダー圧縮の効率にどう影響するか」という点です。
トラフィックがエンドツーエンドで完全にTLSやIPsecで暗号化されている場合、パケットのトランスポートヘッダーやペイロードが暗号化されるため、中継するキャリアの基地局（PDCP層）でROHCが正常に機能しなくなる、あるいは適用範囲が制限されるジレンマが生じます。そのため、モダンな5Gコアネットワーク（5GC）アーキテクチャでは、ユーザープレーンのトンネリング（GTP-Uなど）と無線区間の最適化が緻密に設計されています。
—
5. 重大なネットワーク脆弱性とセキュリティの落とし穴
ガジェットやIoTデバイスがモバイルネットワークに接続する際、物理層の波形選択やプロトコルの最適化だけではなく、セキュリティの観点から絶対に避けるべき重大な罠があります。
1. プロトコルダウングレード攻撃と無線干渉インジェクション
攻撃者が基地局と端末の間の無線区間（またはフェムトセル/ローグ基地局を偽装した環境）で意図的に電波干渉を引き起こし、物理層の変調方式やアップリンクの波形選択（CP-OFDM ⇄ DFT-s-OFDM）において、エラーレートの悪化を誘発する手法が研究されています。これにより、端末を非力なモードや特定の脆弱なスロットリング状態へ強制的に落とし、上位レイヤーでのセッションハイジャックやDoSを引き起こすリスクが存在します。
【回避策】：
- コアネットワーク側および端末のモデムファームウェアにおいて、最新の3GPPリリース仕様に準拠したセキュアなRRC（Radio Resource Control）シグナリングの整合性検証を厳格に行う。
- アプリケーション層では無線区間のステータスに依存せず、常時トランスポート層の暗号化（TLS 1.3必須、Certificate Pinningの徹底）を維持する。
2. モバイルバックホールにおけるバッファブロート（Bufferbloat）の悪化
アップリンクでDFT-s-OFDMによりセルエッジの通信が無理に維持される結果、無線区間の実効スループットが低下しているにもかかわらず、端末側が大量のデータを送信し続けようとすると、基地局の手前のキューやルーターのバッファにパケットが溢れ返る「バッファブロート」が発生します。これが原因で、インタラクティブなトラフィック（SSHやリアルタイム制御信号）に数百ミリ秒から数秒の遅延ジッターが混入し、セキュリティ監視システムのアラート遅延や、認証タイムアウトを引き起こす温床となります。
【回避策】：
- 前述のLinuxカーネル設定のように、適切なAQM（Active Queue Management、例: FQ-CoDelやBBR）をルーターおよびサーバーのエッジに導入し、無駄なキューイング遅延を即座に破棄・制御する。
—
6. まとめ：パケットの旅路を見据えたインフラ設計へ
CP-OFDMが持つ圧倒的なスループット性能と、DFT-s-OFDMが持つ堅牢なカバレッジ・省電力性能。これら5Gアップリンクの物理層の選択は、単に「バッテリーを長持ちさせるための省エネ技術」という枠にとどまりません。
物理層の波形が電波の波を整え、それが無線リンクのパケットロスを抑え、さらにLinuxカーネルのBBRやTCPバッファ、TLSハンドシェイクの高速化、そしてROHCによるヘッダー最適化へと、すべてのレイヤーは一本の糸で繋がっています。
「なぜかこのAPIのレイテンシが不安定だ」と感じたとき、その原因はコードの非効率さでもクラウドの負荷でもなく、数メートル離れた端末の電力増幅器が発する波形の歪みにあるかもしれません。パケットがベースバンドチップのデジタル信号から電磁波へと変わり、空を駆け抜けてサーバーのNICに到達するまでの全プロセスを俯瞰すること――それこそが、真のインフラアーキテクトに求められる視座なのです。
コメント