【実務・中級編】 5G NR 物理チャネル：PUCCH (Physical Uplink Control Channel) – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

5Gの「見えない絆」を紐解く：PUCCHが支える低遅延通信の現場的解釈

ネットワークエンジニアとして現場に立っていると、しばしば「5Gは速い」という言葉を耳にします。しかし、我々が本当に知りたいのは、その「速さ」を支える泥臭い制御信号のやり取りです。

Web APIの設計で HTTP/3 のストリーム制御に頭を悩ませるのと同じように、無線区間でも「確実にデータを届けるための制御」がミリ秒単位の攻防を繰り広げています。今回は、5G NR（New Radio）において、端末から基地局へ送られる制御情報の心臓部、PUCCH (Physical Uplink Control Channel) について深掘りしていきましょう。

PUCCHの役割：Webアプリで言えば「TCP ACK」のようなもの

PUCCH は、端末（UE）から基地局（gNB）へ向けて送信される制御情報の運び屋です。具体的には以下の3つを担っています。

ACK/NACK: 受信データが正しかったかどうかのフィードバック（HARQ）。
SR (Scheduling Request): 「アップリンクで送るデータがあるからリソースをくれ！」という叫び。
CSI (Channel State Information): 「今の回線品質はこんな感じだ」という基地局への報告。

これらは、Web APIにおける 200 OK のようなレスポンスや、通信経路の輻輳制御に近い役割を果たしています。PUCCH が不安定だと、どんなに物理帯域が広くても、TCPの再送制御が暴れてスループットはガタ落ちです。

PUCCHフォーマット0〜4：サイズと低遅延の最適化

PUCCH には5つのフォーマットがあり、運ぶ情報のビット数と、時間軸上のリソース割り当てによって使い分けられます。

| フォーマット | 特徴 | 用途 |
| :— | :— | :— |
| 0 | 短い（1-2シンボル） | 小容量のACK/NACKやSR |
| 1 | 長い（4-14シンボル） | 端末数が多い環境でのACK/NACK |
| 2 | 短い（1-2シンボル） | CSI報告など多ビット情報の伝送 |
| 3 | 長い（4-14シンボル） | 大容量のCSI報告など |
| 4 | 長い（4-14シンボル） | 多重化が必要な場合 |

現場で特に意識したいのは「低遅延」です。PUCCH フォーマット0や2のような「短い（Short PUCCH）」タイプは、送信機会が頻繁に訪れるため、無線区間の待ち時間を極限まで減らしたいリアルタイム通信には不可欠です。

インフラ運用・開発者が知っておくべき「現場の挙動」

アプリケーションエンジニアとして、Fetch API を使ったリクエストを投げる際、裏側で何が起きているか想像してみてください。

# Pythonで擬似的に表現する、アップリンク制御のイメージ
# 実際には物理層のシーケンスですが、論理的にはこのように動いています

class PUCCH_Simulator:
    def send_ack_nack(self, status):
        # ACK/NACKは非常に優先度が高い
        # 基地局からのPDSCH受信後、最短のタイミング（K1スロット）で送る
        payload = "1" if status == "SUCCESS" else "0"
        print(f"PUCCH フォーマット0で送信中... Payload: {payload}")

    def request_uplink_resource(self):
        # データ送信前にSRを投げて、スケジューリング許可をもらう
        print("SR (Scheduling Request) を送信。アップリンク許可待ち...")

Web APIで言えば、HTTP リクエストの前に TCP の3-way handshakeがあるように、PUCCH でリソース要求 (SR) を行い、基地局からの UL Grant（アップリンク許可）を待って初めて、実際のデータ（PUSCH）が流れるのです。

実務上のTips：パケットロスと再送のデバッグ

もしあなたがインフラ運用に携わっていて、「特定のエリアでアップリンクの速度が出ない」「APIのレスポンスが妙に遅い」という事象に遭遇したら、無線区間の PUCCH 再送率を疑うべきです。

curl などでエンドツーエンドの遅延を計測する際、もし TCP の再送が多発しているなら、それは無線区間での ACK/NACK が基地局に届いていない（＝PUCCH の品質不良）可能性を考慮しましょう。

# 現場でよく使う、HTTP応答速度のベンチマークコマンド
# 接続時間、最初のバイトまでの時間、合計時間を確認する
curl -w "Connect: %{time_connect}s, TTFB: %{time_starttransfer}s, Total: %{time_total}s\n" \
     -o /dev/null -s https://api.example.com/data

# 運用上の注意: 
# もしConnect時間は安定しているのにTTFBが跳ねるなら、
# 無線区間のSR/ACKハンドシェイクに問題がある可能性がある。

最後に：ネットワークを「生き物」として捉える

PUCCH のリソース設定は、基地局側の RRC (Radio Resource Control) 設定ファイルで厳密に制御されています。エンジニアとしては、単に「5Gがつながった」で終えるのではなく、その裏でミリ秒単位のパケットが PUCCH という細い道を通って、いかに効率的にやり取りされているかを想像してみてください。

この「制御信号の可視化」こそが、トラブルシューティングの現場で「勘」ではなく「論理」で障害を切り分けるための最強の武器になります。

次回は、この PUCCH をさらに効率化する「UCI (Uplink Control Information) の多重化」について、より深いレイヤーで触れていきたいと思います。現場からは以上です！