5Gの「上り」で何が起きているのか？PUSCHが握るパフォーマンスの核心
現場でインフラを触っていると、「ダウンロード速度は出るのに、なぜかAPIのレスポンスが妙に遅い」「アップロード時のレイテンシが安定しない」といった壁にぶつかることはないだろうか？
その原因、実は端末と基地局の間で繰り広げられる「PUSCH（Physical Uplink Shared Channel）」の制御に隠されていることが多い。今回は、5G NR（New Radio）において、ユーザーデータが空を飛ぶための心臓部であるPUSCHについて、現場視点で深掘りしていこう。
—
PUSCH：アップリンクの「物流網」を最適化せよ
PUSCHは、言わば端末から基地局へデータを送るためのメインロードだ。しかし、ただデータを流せばいいわけではない。5Gのミリ波やSub6といった過酷な環境下で、いかに効率よく、かつ確実にパケットを届けるか。そこで重要になるのが「プリコーディング」と「電力制御」という2つのチューニング項目だ。
1. プリコーディングの選択：コードブック vs 非コードブック
基地局とのMIMO通信において、端末がどの「アンテナの組み合わせ（空間レイヤ）」を使うかを決めるのがプリコーディングだ。
- コードブックベース (Codebook-based):
基地局が事前に決めた「型」の中から最適なものを端末が選ぶ方式。端末の能力が分かっている場合に効率的で、制御オーバーヘッドが低い。
- 非コードブックベース (Non-codebook-based):
端末が自身のチャネル状態（SRS: Sounding Reference Signal）に基づき、基地局に「これで行く」と提案する方式。動的な環境変化に強く、高精細なビームフォーミングが可能だが、計算コストは高い。
実務でAPIの通信品質を最適化する際、インフラ側がこのプリコーディングをどう制御しているかは、特に広帯域な通信において重要な指標となる。
2. TPC（Transmission Power Control）：無駄なく、かつ力強く
アップリンクの電力制御、つまり TPC は、近隣のセルへの干渉を防ぎつつ、自セルのS/N比を最大化するための調整弁だ。TPC コマンドが DCI（Downlink Control Information）を介して端末に飛ぶことで、端末の送信電力が動的に決定される。
ここでのパラメータ調整を誤ると、基地局側で BLER（Block Error Rate）が急上昇し、再送制御（HARQ）が頻発して、結果としてTCPスループットがガタ落ちする。
—
開発現場からの視点：通信ログとパラメータの読み解き
さて、インフラエンジニアやバックエンドエンジニアとして、この「PUSCHの挙動」をどう捉えるべきか。Web APIのレスポンスが遅延する際、まずは端末側（またはエッジデバイス）のログから PUSCH 関連のパラメータを追ってみよう。
運用デバッグの勘所：Pythonでのログ解析イメージ
もし、端末の diag ログ（通信トレース）を解析できる環境にあるなら、TPC の値と MCS（Modulation and Coding Scheme）の相関を見てほしい。
# 端末ログから取得したTPC積算値とMCSの推移をプロッドする簡易ツール
import matplotlib.pyplot as plt
def analyze_uplink_performance(log_data):
# log_data: [{"timestamp": "...", "tpc_gain": 2, "mcs": 22}, ...]
tpc_values = [d['tpc_gain'] for d in log_data]
mcs_values = [d['mcs'] for d in log_data]
# 電力制御が効きすぎて送信制限がかかっていないか確認
# MCSが急落しているタイミングでTPCが下がっていれば、無線環境の悪化が確定
plt.plot(tpc_values, label='TPC Gain (dB)')
plt.plot(mcs_values, label='MCS Index')
plt.legend()
plt.show()
# 現場でのトラブルシューティング：MCSが低迷し続けていないか？を確認するインフラ設計者が知っておくべきTCPチューニング
PUSCHが最適化されていない環境（例えば、基地局側で TPC が過剰に絞られている環境）では、どんなに高性能なAPIサーバーを立ててもスループットは出ない。
特に、curl や Fetch API を使った疎通試験で、アップロード時にパケットロスが発生する場合は、以下のようなOSレベルのTCPバッファ設定の見直しが必要になる。
# Linux環境でのTCP送受信バッファの最適化（アップリンクの詰まり対策）
# 5Gの高速・広帯域を活かすため、バッファを広めに確保する
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"
# 設定を反映
sysctl -p—
まとめ：ネットワークとアプリケーションの境界を埋める
5Gにおける PUSCH の挙動は、単なる物理層の仕様ではない。それは、皆さんが書くコードがインターネットという大海原へ漕ぎ出すための「第一歩」だ。
もし、クライアント側のアプリで「アップロードが遅い」「APIのPOSTがタイムアウトする」という相談を受けたら、単にサーバーサイドのログを見るだけでなく、その端末がどのような MCS で PUSCH を送ろうとしているのか、電波環境の裏側にある「制御信号の駆け引き」に思いを馳せてみてほしい。
ネットワークエンジニアの仕事は、パケットを流すことではない。そのパケットが、最高の環境で届くように道を整えることだ。現場からは以上だ。また次の深い技術解説で会おう。
コメント