5G NR Numerologyの真髄：なぜ「サブキャリア間隔」が通信の現場を支配するのか
現場でトラブルシューティングをしていると、「5Gなのに思ったより遅延が減らない」「特定のエリアでハンドオーバーが頻発する」といった相談をよく受けます。そんな時、物理層の泥臭い仕様に目を向けると、意外とあっさり原因が見えてくるものです。
今回は、5G NR（New Radio）の柔軟性を司る心臓部、Numerology（μ）について、エンジニアの視点で深掘りしていきます。教科書的なスペック表を眺めるのはもう終わりにして、この数値がなぜWeb APIの応答速度やインフラの安定性に直結するのか、一緒に紐解いていきましょう。
—
5G NRにおける「スケーラビリティ」の正体：Numerology (μ)
4G LTEまでの世界は、サブキャリア間隔（SCS: Subcarrier Spacing）は15kHz固定という「決め打ち」の世界でした。しかし、5G NRではこの間隔を 2^μ × 15kHz という数式で可変させるスケーラブルなOFDMを採用しています。
この μ こそが、ネットワークの「性格」を決めるスイッチです。
| μ | SCS (kHz) | 主なユースケース |
| :— | :— | :— |
| 0 | 15 | 広域カバレッジ（低周波数帯、遠距離） |
| 1 | 30 | 一般的な都市部（中周波数帯） |
| 2 | 60 | 高スループット・低遅延（URLLC） |
| 3 | 120 | ミリ波（超高速・広帯域） |
| 4 | 240 | 特殊用途（極限の低遅延） |
なぜ間隔を広げるのか？
ここが実務的なポイントです。サブキャリア間隔を広げる（μ を大きくする）と、1シンボルあたりの時間が短縮されます。これにより、「送信タイミングを細かく刻める＝低遅延になる」というメリットが生まれる反面、周波数オフセットの影響を受けやすくなるため、高度な同期技術が求められます。
—
インフラエンジニアが知るべき「遅延」のリアル
Web APIを設計する際、ネットワークのレイテンシを考慮することは不可欠です。5Gの低遅延性を活かしたい場合、アプリケーション側でもパケットのバースト性や、TCP/UDPの挙動を意識する必要があります。
例えば、PythonでRTT（Round Trip Time）を計測し、通信経路の遅延を可視化するコードは、現場のデバッグで非常に重宝します。
import time
import requests
# APIエンドポイントへの遅延を計測するシンプルなロジック
def check_network_latency(url):
try:
start_time = time.perf_counter()
# 5G環境下ではこの往復時間がサブキャリア間隔の影響を受ける
response = requests.get(url, timeout=5)
end_time = time.perf_counter()
latency = (end_time - start_time) * 1000
print(f"Latency: {latency:.2f} ms | Status: {response.status_code}")
except requests.exceptions.RequestException as e:
print(f"Connection Error: {e}")
# 実行
check_network_latency("https://api.example-5g-service.com/v1/ping")—
現場で使えるTips：ミリ波とSub6の使い分け
運用において、ミリ波（μ=3）エリアでのインフラ構築は「シビア」の一言に尽きます。ミリ波は直進性が非常に強く、障害物に弱いため、コネクションの維持が困難です。
もしあなたがインフラ設計者なら、特定の環境下で通信が途切れる際、curl コマンドでTCP接続の開始時間を詳細に追跡してみてください。
# TCP接続からレスポンス開始までの時間を詳細にダンプする
# 5Gのハンドオーバー時やセルの切り替わり時に遅延がどう変化するかを確認するのに便利
curl -w "TCP Connection: %{time_connect}s\nTime to First Byte: %{time_starttransfer}s\n" \
-o /dev/null -s "https://api.example-5g-service.com"time_connect: TCPハンドシェイクの完了時間。μが適切に設定されていないと、ここが不安定になります。time_starttransfer: サーバーがパケットを送り出すまでの時間。5Gのスケジューリングの恩恵を最も受けます。
—
結論：ネットワークは「生き物」である
5G NRの Numerology は、単なる規格上の数字ではありません。電波が飛び交う物理層から、私たちが叩くAPIのレスポンスに至るまで、全てがこの μ によって制御されています。
広域カバレッジを求めるなら μ=0（15kHz）の安定性を信じ、超高速・低遅延を追求するアプリケーションなら μ=2 や μ=3 が提供する短いフレーム構造を前提に設計する。この「物理的な文脈」を理解した上でインフラを組むことが、シニアエンジニアとして一歩先へ行くための鍵です。
もし現場で「なぜか不安定」という事象に遭遇したら、まずは基地局のセルの構成や、現在の周波数帯がどの Numerology を優先しているのか、思いを馳せてみてください。きっと、解決の糸口が見えてくるはずです。
ネットワークの泥臭い世界へようこそ。また次回の現場でお会いしましょう。
コメント