【実務・中級編】直交周波数分割多重（OFDM）とDFT-s-OFDM（アップリンク用波形選択）の仕組み – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

5Gの「波形」を読み解く：なぜアップリンクにはDFT-s-OFDMが選ばれるのか？

現場でネットワークのトラブルシュートをしていると、ふと「なぜこのモバイル通信は、特定の条件下でこうも挙動が変わるのか」と頭を抱える瞬間があるはずだ。5Gの無線物理層は、まさにその複雑さの塊。しかし、その根底にある「変調の仕組み」を理解していれば、パケットロスやレイテンシの増大という怪奇現象に対する解像度が劇的に変わる。

今回は、5G（NR: New Radio）のキモとも言えるOFDM（直交周波数分割多重）と、アップリンクで採用されるDFT-s-OFDMの住み分けについて、現場目線で深掘りしていこう。

—

1. なぜ「波形」が違うのか？：ダウンリンクとアップリンクの非対称性

まず前提として、5Gのダウンリンク（基地局→端末）では主に CP-OFDM が使われる。これに対し、アップリンク（端末→基地局）では環境によって CP-OFDM と DFT-s-OFDM を切り替える。なぜわざわざ別の波形を用意するのか。答えはシンプルで、「バッテリー寿命」と「カバレッジ」のトレードオフだ。

CP-OFDM（Cyclic Prefix OFDM）

マルチパス環境（電波がビルに反射して届く状況）に強く、周波数利用効率が高い。しかし、信号の振幅変動が激しいため、送信機のパワーアンプ（PA）を線形領域で駆動させるために大きな「バックオフ」が必要になる。つまり、電力を無駄に食うのだ。

DFT-s-OFDM（Discrete Fourier Transform-spread OFDM）

これこそが SC-FDMA の進化系だ。信号を送信する前にDFT処理を行い、周波数領域で拡散させることで、時間領域での信号のピーク電力比（PAPR: Peak-to-Average Power Ratio）を低減できる。これにより、送信機のアンプをより効率的に（飽和領域近くまで）駆動できるため、バッテリー消費を抑えつつ、より遠くの基地局まで電波を飛ばせる。

—

2. エンジニアが意識すべき「PAPR」の影響

Web APIの設計やインフラ運用において、無線区間の波形を直接制御することはできない。しかし、この波形特性の違いは、アプリケーションの「体感品質」に直結する。

例えば、IoTデバイスが大量のデータを一斉にアップロードする場合、基地局側は DFT-s-OFDM を指定して、端末の送信電力を節約しようとする。逆に、広帯域が必要な動画配信などでは CP-OFDM が選ばれる傾向がある。

診断のためのチェックポイント

インフラエンジニアとして、端末の挙動を追う際は以下のパラメータを意識してほしい。

PAPR (Peak to Average Power Ratio): これが高いと、送信機はアンプの歪みを避けるために出力を絞る必要があり、結果としてスループットが低下する。
MCS (Modulation and Coding Scheme): DFT-s-OFDM を使用している際、MCSインデックスが低いにもかかわらずパケットロスが頻発する場合、無線環境のノイズ耐性の限界に達している可能性がある。

—

3. 実務で役立つ：モバイル回線経由のAPI負荷テストTips

開発環境でモバイル回線を通したAPIの挙動を検証する際、curl や python を使って、あえてバースト的なトラフィックを生成し、ネットワークの変化を追うのが有効だ。

以下のPythonコードは、モバイル回線のアップリンク帯域を意識した、シンプルなPOSTリクエストのベンチマーク例である。

import requests
import time

# モバイル端末からのアップロード負荷をシミュレート
def simulate_uplink_load(api_url, payload_size_mb=1):
    data = '0' * (payload_size_mb * 1024 * 1024)
    headers = {'Content-Type': 'application/octet-stream'}
    
    start_time = time.time()
    try:
        # タイムアウトを短めに設定し、無線区間の不安定さを検知しやすくする
        response = requests.post(api_url, data=data, headers=headers, timeout=5)
        duration = time.time() - start_time
        print(f"Status: {response.status_code}, Time: {duration:.2f}s")
    except requests.exceptions.Timeout:
        print("モバイル回線の不安定により、アップロードがタイムアウトしました。")

# 連続で叩いて、基地局側のリソース制御によるスループット変動を確認する
for _ in range(5):
    simulate_uplink_load("https://api.example.com/v1/upload")
    time.sleep(1) # 基地局側のスケジューリング間隔を考慮して少し待つ

また、Linuxベースのゲートウェイ等で運用している場合、ethtool や tc コマンドで無線インターフェースのキュー制御を確認するのも重要だ。

# インターフェースのバッファ状況を確認（パケットドロップの兆候を探る）
ethtool -S wwan0 | grep drop

# tcコマンドでアップリンクの帯域制限をかけ、波形選択にどう影響するか検証する
# (※実機で試す際はネットワーク管理者に許可を得ること)
sudo tc qdisc add dev wwan0 root tbf rate 1mbit burst 32kbit latency 400ms

—

4. 最後に：現場の知見が「安定」を作る

CP-OFDM と DFT-s-OFDM のどちらが採用されるかは、基地局のスケジューラが端末の電波状況（RSRP / RSRQ）を元に動的に決定している。つまり、「アプリケーションからは見えないところで、ネットワークは常に最適化を繰り返している」という事実を忘れてはならない。

大規模なIoTシステムや、モバイル環境でのAPI運用を行う際は、「ネットワークは常に変動する生き物である」という前提に立ち、指数バックオフを伴うリトライ戦略や、パケットサイズを極力小さく抑える設計を心がけてほしい。

物理層の挙動を知れば、トラブルシュートの際、「あ、今のアンプ飽和かも？」といった鋭い仮説が立てられるようになるはずだ。現場の泥臭い経験こそが、最高のエンジニアリングを生む。次回の現場でも、この視点をぜひ活かしてほしい。