物理層の「叫び」を制御する：PUSCHと送信電力制御の深淵
Web APIの開発において、LatencyやThroughputのボトルネックがサーバーサイドやアプリケーションコードにあると信じて疑わないエンジニア諸君、一度立ち止まってほしい。我々が叩いているそのAPIリクエストは、電波という極めて不安定な物理メディアを通って基地局へ届いている。
特に5G時代において、我々の端末（UE：User Equipment）が基地局（gNB）に向けてデータを送る際の「物理アップリンク共有チャネル（PUSCH）」の挙動は、もはや魔法ではなく、精密な制御理論の塊だ。今日は、APIのレイテンシがなぜか急激に悪化する際、その裏で何が起きているのか、送信電力制御の泥臭い世界を紐解いていこう。
—
PUSCHとは何か：端末の「声」を届けるメインルート
PUSCH（Physical Uplink Shared Channel）は、端末から基地局へユーザーデータを運ぶためのメインストリームだ。Web APIのPOSTリクエストでJSONデータを送信する際、それはこのPUSCHという物理チャネルに乗って空を飛ぶ。
ここで重要なのは、「送信電力」の匙加減だ。もしすべての端末が全開で電波を飛ばせば、セル内は干渉だらけになり、通信は崩壊する。逆に弱すぎれば、基地局には届かない。このバランスを制御するのが、3GPP標準で規定された「送信電力制御（Transmit Power Control: TPC）」の役割だ。
—
閉ループと開ループ：電力制御の「二段構え」
通信エンジニアが現場でよく頭を抱えるのが、この電力制御の不整合だ。
1. 開ループ電力制御 (Open-loop Power Control)
端末が基地局からの報知信号（SIB）を元に、勝手に計算して送信電力を決める。「基地局がこれくらいで送れと言っているから、このくらいにしておこう」という推測に基づく制御だ。
2. 閉ループ電力制御 (Closed-loop Power Control)
基地局がリアルタイムで「もっと上げろ」「下げろ」と命令（TPC command）を送る。DCI（Downlink Control Information）という制御情報の中に含まれるこのコマンドにより、微調整を行う。
現場の障害で、特定のエリアだけ通信が不安定になる場合、このTPC commandが上手く反映されていない、あるいは過度な補正が裏目に出ているケースが多い。
—
現場で役立つ：送信電力制御のパラメーター確認
インフラ運用やモバイルSDKの開発に携わるエンジニアが知っておくべきパラメーターは、3GPP TS 38.213で定義されている以下の式に集約される。
P_PUSCH(i, j, q, l) = min{P_CMAX, P_O_PUSCH + alpha * PL + ... + f(i, l)}
ここで重要となるのが、alpha（パスロス補償係数）とPL（パスロス）だ。alphaが「1」に近いほど、パスロスを完全に補償するように電力を上げる。これが「1」より小さい場合、セルエッジ（基地局から遠い端末）に優しくない設定となり、APIのタイムアウトを引き起こす要因になる。
実務でのデバッグ：Pythonによる信号強度モニタリング
もしAndroid等の開発環境で直接RF信号にアクセスできるなら、以下のようなロジックで送信電力の推移を監視することも可能だ（※OSの権限に依存する）。
import subprocess
def check_uplink_status():
"""
端末側の送信電力や信号品質（RSRP/RSRQ）を簡易的に取得するシミュレーション
実務ではAndroidのTelephonyManager API経由で取得することが多い
"""
# 実際には dumpsys connectivity 等で無線情報を吸い上げる
try:
# PUSCHの送信電力が一定値を超えているか、不安定かを確認
result = subprocess.run(['dumpsys', 'telephony.registry'], capture_output=True, text=True)
# ログから 'txPower' や 'signalStrength' のキーワードを抽出
if "txPower" in result.stdout:
print("送信電力レベルは正常範囲内です")
else:
print("警告: 送信電力制御エラーの可能性あり")
except Exception as e:
print(f"デバッグ情報の取得に失敗: {e}")
# 実行
check_uplink_status()—
API設計への教訓
我々がWeb APIを設計する際、ネットワークが「ベストエフォート」であることを前提にする必要がある。
- 冪等性の担保:
PUSCHの制御がうまくいかず、TCPの再送が頻発すると、通信は目に見えて「詰まる」。POSTリクエストがサーバーに届いているのにACKが返らず、タイムアウトして再送されるケースを想定し、必ずIdempotency-Keyを付与すること。 - ヘッダーの軽量化:
PUSCHは限られたリソースブロック（RB）を奪い合う。不要なカスタムヘッダーを大量に積むことは、物理層でのパケット分割を招き、結果として送信電力制御のオーバーヘッドを増やす。
curlによる疎通確認のベストプラクティス
API運用中に「ネットワークが重い」と感じたときは、curlで応答時間だけでなく、TCPの接続フェーズごとの遅延を可視化しよう。
# 接続からレスポンスまでのタイムラインを細分化して計測
curl -w "DNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \
-o /dev/null -s "https://api.example.com/v1/data" \
--header "Content-Type: application/json" \
# 物理層の不安定さが影響している場合、TCP: の値が不自然に跳ね上がる—
最後に：見えないインフラを想像する
PUSCHの制御は、何千もの端末が秒単位で基地局と交わす「静かな対話」だ。コードを一行書くとき、それが電波の海を渡るパケットとして、送信電力を細かく調整されながら基地局へ届く姿を想像してみてほしい。
ネットワークエンジニアの仕事は、その「見えない叫び」を理解し、いかにアプリ側のレイヤーで優しく受け止めるかにある。技術の進化と共に、我々の設計思想もまた、物理層の泥臭い現実を包み込むほど柔軟であるべきだ。
明日、APIのレスポンスが遅いと文句を言われたら、まずは「今日は電波が叫んでいるのかな？」と疑ってみるのも、シニアへの第一歩かもしれない。
コメント