【実務・中級編】 5G Sub6周波数帯(FR1: 410MHz〜7125MHz)の電波特性とカバレッジ設計 – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

「ミリ波の夢」より「Sub6の現実」を語ろう。5Gエンジニアが知るべき電波の「泥臭い」特性と現場の最適化術

こんにちは。ネットワークの現場でパケットの断末魔を何度も聞いてきたシニアエンジニアです。

世間では「5Gで爆速」なんて華やかなプロモーションが飛び交っていますが、実際にインフラ運用やモバイルアプリのAPI設計に携わっている皆さんは、そんな甘い言葉を鵜呑みにはしていないはずです。特に、モバイル通信の屋台骨を支える「Sub6（FR1）」は、エンジニアにとって最も「付き合い方が難しい」帯域と言えます。

今日は、教科書的な仕様書を脇に置いて、現場で直面するSub6の挙動と、それを考慮したシステム設計の勘所を共有しましょう。

—

1. Sub6（FR1）はなぜ「最強の妥協点」なのか

5Gには「ミリ波（FR2）」という夢がありますが、あちらは壁一枚あれば電波が死ぬほど繊細です。対して、410MHz〜7125MHzの範囲をカバーするSub6は、LTEの延長線上にある、非常に「人間臭い」電波です。

現場で感じるSub6の物理的特性

回折性と浸透性: LTEと近い周波数帯を使うため、建物の影や室内でも比較的安定して届きます。
帯域幅（Bandwidth）の広さ: LTEよりも広い帯域を確保できるため、実効スループットが明らかに向上します。
減衰のリアリティ: それでも高周波数帯であることには変わりなく、特に3.7GHz帯を超えてくると、窓際と部屋の奥ではRSSI（受信信号強度）が目に見えて変わります。

API設計者がこれを無視して「常に低遅延・高帯域」を前提にすると、圏外への切り替わりやハンドオーバー発生時にアプリの挙動が破綻します。

—

2. API設計とインフラ監視：現場の「作法」

クライアント側のモバイル通信環境が不安定であることは「前提」です。Web APIを設計する際、Sub6の電波特性に翻弄されないための実装を心がけましょう。

実践的なAPIリクエストのタイムアウトとリトライ

モバイル通信環境では、TCPハンドシェイクが完了する前にハンドオーバー（基地局の切り替え）が発生し、パケットが迷子になることが多々あります。以下のPythonコードのように、requestsライブラリ等でタイムアウトを適切に設定し、指数バックオフを伴うリトライを実装するのは「エンジニアの嗜み」です。

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

def get_session():
    session = requests.Session()
    # 5Gのハンドオーバーによる一時的なパケットロスを想定したリトライ設定
    retry_strategy = Retry(
        total=3,  # 最大リトライ数
        backoff_factor=1,  # 指数バックオフ
        status_forcelist=[502, 503, 504]
    )
    adapter = HTTPAdapter(max_retries=retry_strategy)
    session.mount("https://", adapter)
    return session

# 接続タイムアウト(connect)と読み込みタイムアウト(read)を厳格に指定
# Sub6の不安定なレイテンシを考慮し、短すぎず長すぎない設定が肝
response = get_session().get("https://api.example.com/data", timeout=(3.0, 10.0))

—

3. デバッグの現場：通信品質を「可視化」する

もし皆さんがモバイルアプリやIoTゲートウェイのエンジニアなら、端末のRSRP（基準信号受信電力）やRSRQ（基準信号受信品質）をログに仕込むことを強く推奨します。

CLIでのデバッグTips

Linuxベースの組み込みデバイスやAndroid端末であれば、mmcli（ModemManager）などを使って、現在のセル接続状態を確認できます。

# モデムの情報を取得し、現在の電波品質をチェックするコマンド例
# 現場で「通信が遅い」と言われたら、まずはこの値を見る
mmcli -m 0 --query-signal

# 出力例（概念的なイメージ）:
# 5G NR (Sub6)
# RSRP: -95 dBm  <- この値が -110 dBm を下回るとパケットロスが激増する
# RSRQ: -12 dB   <- 通信品質のバロメーター。-15以下は要注意

インフラエンジニアとしては、サーバー側の X-Forwarded-For ヘッダーからIPを特定し、特定の基地局配下のユーザーからのリクエストだけが極端に遅延していないか、Grafana等で監視するのも一手です。

—

4. 最後に：エンジニアへのメッセージ

Sub6の電波設計は、「完璧を求めず、変動を許容する」のが正解です。

API側: 冪等性を確保し、再送を恐れない。
通信側: TCPの初期ウィンドウサイズを調整したり、QUIC（HTTP/3）を採用して、ハンドオーバー時のコネクション維持能力を向上させる。

ネットワークの進化は速いですが、物理層の泥臭い課題はいつの時代も変わりません。Sub6という「広くて不安定な回線」とどう上手く付き合うか。それこそが、皆さんの腕の見せ所です。

何かトラブルが起きたら、まずはログを見て、パケットがどこで泣いているか（ドロップしているか）に耳を澄ませてみてください。現場からは以上です。