5G時代の「見えない交通整理」をハックする：RRMとスケジューリングの裏側
現場でインフラを叩いていると、「なぜか特定の時間帯だけAPIのレスポンスが跳ねる」「パケロスはないのにスループットが安定しない」といった怪奇現象に遭遇することがありますよね。
多くのエンジニアがアプリケーション層のボトルネックを疑いますが、実はその原因、基地局（gNB）が行っている「無線リソース管理（RRM）」と「スケジューリングアルゴリズム」の采配にあるかもしれません。今日は、物理層からアプリケーション層までを一気通貫で見ているシニアエンジニアの視点で、この「空中の交通整理」について深掘りしていきましょう。
—
1. 基地局は「空き状況」をどう見ているのか？
4G（LTE）から5G（NR）へ進化した最大の恩恵は、単なる速度向上ではありません。無線リソースブロック（RB: Resource Block）の動的割り当ての解像度が劇的に上がったことにあります。
基地局は、ミリ秒単位で「誰に」「どの周波数帯の」「どの時間スロットを」割り当てるかを決定しています。これを担当するのがMAC層の「スケジューラ」です。彼らは主に以下の要素を監視しています。
- CQI (Channel Quality Indicator): 端末が報告する電波品質。これに基づいて変調方式（QAM）や符号化率を決定します。
- Buffer Status Report (BSR): 端末側の送信バッファにどれだけデータが溜まっているか。
- QoS Class Identifier (QCI/5QI): 通信の優先順位（音声通話は遅延優先、ファイルDLはスループット優先など）。
この複雑なパズルを解くために、スケジューラは Proportional Fair（公平性とスループットのバランスをとるアルゴリズム）などの手法を用いて、無線リソースをパケット単位で切り刻んで割り当てています。
—
2. アプリ開発者が知っておくべき「無線品質の可視化」
サーバーサイドのAPI設計をしていると「無線環境」を無視しがちですが、実際にはクライアント側で取得できるメトリクスをログに含めるだけで、トラブルシュートの質が劇的に変わります。
例えば、Androidなら ConnectivityManager や TelephonyManager から取得できる値をAPIのヘッダーに付与してみましょう。
# 擬似的なPythonコード：モバイル端末側で電波状況を計測してヘッダーに含める例
import requests
def send_request_with_metrics(api_url, payload):
# 端末から取得したリアルタイムの無線品質パラメータ
# RSRP: 電波の強度, RSRQ: 電波の品質, CQI: 変調の適正値
headers = {
"X-Radio-RSRP": "-85", # -80dBm以上なら優秀
"X-Radio-CQI": "14", # 15段階評価で14なら最高に近い
"X-Radio-Band": "n78" # 使用中の周波数帯（Sub6）
}
response = requests.post(api_url, json=payload, headers=headers)
return response
# このようにヘッダーを付与すれば、サーバー側で「遅延の原因がサーバー負荷なのか、
# それとも端末がビル陰に入ってCQIが急落したからか」を一発で切り分けられます。—
3. インフラ運用における「スケジューリング制御」の落とし穴
Web APIの開発において、特に注意すべきは「TCPの輻輳制御」と「無線スケジューリング」のミスマッチです。
無線区間は環境によってスループットが激しく変動します。ここで TCP BBR などの輻輳制御アルゴリズムを使っていると、無線区間の瞬断を「ネットワーク全体の輻輳」と誤認し、送信レートを過剰に絞ってしまうことがあります。
運用時のチェックリスト
- MTUサイズの最適化: 無線区間でパケットが断片化（フラグメンテーション）されると、スケジューラのリソース割当効率が落ちます。基本は
1400〜1450バイト程度で調整を試みてください。 - TCP Keepaliveの調整: 無線環境ではセッションが切断されやすいため、サーバー側でのタイムアウト設定は少し長めに、かつクライアント側からの定期的な
heartbeatを実装するのが定石です。
# curlでパケットの到着間隔を計測し、ジッター（揺らぎ）を可視化するコマンド例
# 無線区間のスケジューリングが追いついていないと、到着時間に大きなバラつきが出ます
curl -w "Connect: %{time_connect} TTFB: %{time_starttransfer} Total: %{time_total}\n" \
-o /dev/null -s https://api.your-service.com/ping—
4. 現場のシニアからのアドバイス：泥臭い解決策
最後に、現場でよくある「無線リソースの奪い合い」に対する考え方をお伝えします。
5Gの「ミリ波」や「Sub6」は非常に高速ですが、物理的な遮蔽物や移動速度に非常に敏感です。もしアプリケーションのレスポンスが不安定なら、「無線リソースは最初から揺らぐもの」という前提で設計してください。
1. クライアント側でのリトライ制御: エクスポネンシャル・バックオフを必ず実装すること。基地局のスケジューラが空いた瞬間に再送をかけるのが最短の道です。
2. ペイロードの最小化: リソースブロックの占有時間を減らせば、それだけ「スケジューラから選ばれやすく」なります。
3. ログを信じるな、パケットを信じろ: Wireshark で無線区間を含むPCAPを解析する際、 RLC (Radio Link Control) 層の再送回数が増えていないかを確認してください。ここが伸びているなら、アプリケーション層のチューニング以前に、無線品質（RSRP/RSRQ）の改善が必要です。
ネットワークは「魔物」ですが、この挙動を理解すれば、あなたの作るアプリケーションはどんなに過酷な電波環境でも、しなやかに、かつ力強く通信できるようになります。
さあ、今日もコードとパケットを信じて、最高のユーザー体験を追求していきましょう！
コメント