【テクニカル・上級編】 物理アップリンク制御チャネル（PUCCH）の構造とフィードバック伝送 – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

5G無線区間の心臓部を暴く：物理アップリンク制御チャネル（PUCCH）の深層と極限パフォーマンスチューニング

パケットキャプチャの画面を眺めながら、TCPのSYNが送信されてから最初のデータセグメントが返ってくるまでのラウンドトリップタイム（RTT）に一喜一憂するインフラエンジニアなら、一度は無線レイヤの底流で何が起きているのか気になったことがあるはずだ。

Wi-Fiのキャリアセンス（CSMA/CA）の泥臭い世界から、ミリ波やSub-6が織りなす5G NR（New Radio）のスケジュール制御の世界に足を踏み入れると、そこには周波数と時間のグリッドを極限まで効率化するための数学的とも言える美しさがある。

今回は、その5Gのアップリンク（端末から基地局へ向かう通信）において、制御情報の命綱となるPUCCH（Physical Uplink Control Channel）の内部構造に深く切り込む。ACK/NACK、SR（スケジューリングリクエスト）、そしてCSI（チャネル状態情報）という極小かつ極めてクリティカルなパケットが、どのように空を駆け巡り、上位レイヤのパフォーマンスやTLSハンドシェイクのレイテンシに影響を与えているのか。インフラアーキテクトやテックリードが知るべき実践的な知見を紐解いていこう。

—

1. PUCCHの基本構造とFormat 0〜4のアーキテクチャ

無線区間において、下りリンク（DL）のデータに対する「ちゃんと届いたよ」という応答や、「もっとリソースをくれ」という叫びは、すべてアップリンクの制御プレーンであるPUCCHに載せて基地局（gNB）へと運ばれる。

LTE時代にも似たようなチャネルはあったが、5G NRでは多様なユースケース（URLLC、eMMB、mMTC）をミリ秒単位の遅延でさばくため、PUCCHにはFormat 0からFormat 4までの5つのフォーマットが用意されている。それぞれの設計思想は、運ぶ情報量と無線環境（遅延分散の大きさ）によって鮮やかに色分けされている。

PUCCH Format 0：超低遅延を極める1〜2シンボルのショートバースト

  • 運ぶ情報量: 1〜2ビット（主にACK/NACKや短いSR）
  • 時間領域: 1〜2 OFDMシンボル
  • 特徴: 周波数軸上でいくつかのリソースブロック（PRB）を占有し、シーケンス変調（Zadoff-Chuシーケンスの巡回シフト）を用いる。データを復調するための専用参照信号（DMRS）を別途送る必要がないため、オーバーヘッドが極限まで削ぎ落とされている。URLLC（超高信頼・低遅延通信）の命綱だ。

PUCCH Format 1：カバレッジの限界に挑むロングフォーマット

  • 運ぶ情報量: 1〜2ビット
  • 時間領域: 4〜14シンボル
  • 特徴: スロットの時間方向に長く広がり、DMRSと変調シンボルが交互に配置される。セル境界など電波状況が劣悪な環境下で、エネルギーを時間積分して確実に情報を届けるために設計されている。

PUCCH Format 2：大量のCSIを詰め込むマルチPRB構造

  • 運ぶ情報量: 2ビット超（CSIレポートなど）
  • 時間領域: 1〜2シンボル
  • 特徴: 周波数軸上で複数のPRBを使い、QPSK変調で比較的多くの制御情報を一度に送る。チャネル状態情報（CSI）のフィードバックに多用される。

PUCCH Format 3 & 4：大規模データとマルチユーザ多重の要

  • 運ぶ情報量: 11ビット超（多数のCCのACK/NACKや、重厚なCSI）
  • 時間領域: 4〜14シンボル
  • 特徴: Format 3は広い周波数リソースを使い、Format 4はOCC（Orthogonal Cover Code）を用いて同一時間・周波数リソース上で複数の端末（UE）のPUCCHを直交多重する。キャリアアグリゲーション（CA）環境で真価を発揮する。

—

2. 上位レイヤへの波及：TCP RTT、TLSハンドシェイク、ヘッダー圧縮の相関

「無線物理層の制御チャネルが、なぜTCPやTLSに影響するのか？」と疑問に思うかもしれない。しかし、パケットの挙動をレイヤ横断で追うと、その因果関係は非常にクリアになる。

ACK/NACKの遅延が引き起こすTCPの「見せかけの輻輳」

TCPの信頼性を担保する上で、ACKの返送速度はスループットの天井を決定づける。下りリンクで大量のデータセグメントを受信した端末は、その受信確認を上りリンクのPUCCH（Format 0や1）に乗せてgNBに返さなければならない。

もし、PUCCHの送信タイミング（SR配置やスロットフォーマット）が適切にスケジューリングされていない、あるいは無線品質の悪化によって再送が発生した場合、端末側のアップリンク送信待ち（L2バッファでの滞留）が発生する。結果として、下り方向のTCP ACKが遅延し、送信側（サーバー）のトランスポート層は「パケットがロスした」と誤認して輻輳ウィンドウ（cwnd）を急激に縮小させる。これが、見かけ上のスループット急低下のメカニズムだ。

TLSハンドシェイクの往復とPUCCHスケジューリング

HTTPS通信を開始する際、Client Helloから始まり、鍵交換、暗号化通信の確立に至るまでには複数のTCPセグメントとTLSレコードの往復（RTT）が必要になる。特にTLS 1.3であっても1-RTTまたは0-RTTのやり取りにおいて、アップリンクのSR（スケジューリングリクエスト）が迅速に処理されないと、端末が「データを送りたい」と主張してからgNBが上りリソースを割り当てるまでの数ミリ秒の遅延（Scheduling Delay）が積み重なる。

このミリ秒単位の遅延の積み重ねが、Webページの読み込み開始時間（First Contentful Paint: FCP）を押し上げ、エンドユーザー体験を大きく損なう原因となる。

ヘッダー圧縮（ROHC）とアップリンクの同期

モバイル回線では、IPv6/UDP/RTPやTCP/IPヘッダーのオーバーヘッドを削減するため、ROHC（Robust Header Compression）が適用される。制御情報のフィードバックが不安定になると、ROHCのコンテキスト（状態同期）が崩れ、ヘッダーの完全再送（Full Header）が必要になる。これが無線リソースを無駄に消費し、さらなるPUCCHの枯渇を招くという悪循環を生む。

—

3. 実務で直面するトラブルとセキュリティ、脆弱性回避策

インフラエンジニアやセキュリティスペシャリストの視点から見ると、PUCCHをはじめとする物理層・MAC層の制御シグナリングは、DDoS攻撃やリソース枯渇攻撃のターゲットになり得る極めて重要なアタックサーフェスでもある。

SR（スケジューリングリクエスト）枯渇攻撃と対策

悪意あるマルウェアや、設定不備に陥ったIoTデバイスが、意図的かつ継続的に無駄なSRをPUCCH上で爆撃（SR Storm）した場合、gNB側のアップリンク制御リソースが慢性的に枯渇する。結果として、正当なトラフィック（緊急性の高い音声通話やクリティカルなIoTデータ）がスケジュールされなくなる。

対策としてのリソース設定例（gNBベンダ固有設定の概念）

基地局のスケジューラポリシーにおいて、特定の端末が過剰なSRを送信した際のペナルティ設定や、PUCCHリソースの動的割り当て制限（BWP: Bandwidth Partの適切な分割）を施すことが不可欠だ。

{
  "pucch_config_dedicated": {
    "resourceSetToAddModList": [
      {
        "pucchResourceSetId": 0,
        "resourceList": [0, 1, 2, 3],
        "maxPayloadSize": 2
      }
    ],
    "schedulingRequestResourceConfig": [
      {
        "sr_ResourceConfigId": 1,
        "sr_ProhibitTimer": "ms8", // 連続するSR送信間に8ミリ秒の禁止期間を設け、暴走を防ぐ
        "sr_TransMax": "n4"         // 最大再送回数を4回に制限
      }
    ]
  }
}

物理層のなりすましと無線アクセスセキュリティ

無線区間は空気がメディアである以上、盗聴や干渉攻撃（ジャミング）、さらには偽基地局（Rogue gNB）によるアプローチが存在する。PUCCH自体の暗号化は直接的には行われないが、上位のMAC/RRCレイヤにおける完全性保護（Integrity Protection）が厳密に有効化されていることが前提となる。

特に、5Gセキュリティアーキテクチャでは、NAS（Non-Access Stratum）およびRRCレイヤにおけるシグナリングの暗号化と完全性保護（例: NEA2 / NIA2 や 128-NEA3 / 128-NIA3）のアルゴリズム選定が、不正な制御情報の注入を防ぐ最後の砦となる。

—

4. 極限のパフォーマンスチューニング：Linuxカーネルと無線パラメータの調律

最後に、端末側（LinuxベースのルーターやCPE、あるいはテスト用UE）からパケットの挙動を最適化し、PUCCHに起因する遅延を最小化するための実践的なアプローチを見ていこう。

BBR輻輳制御アルゴリズムの適用

前述の通り、PUCCHの遅延揺らぎ（Jitter）はTCPの挙動に直結する。従来のCUBICのような損失ベースの輻輳制御よりも、RTTと帯域のボトルネックをリアルタイムで測定するGoogle BBR（Bottleneck Bandwidth and RTT）を使用することで、無線区間の揺らぎに対して強靭な通信を実現できる。

以下のカーネルパラメータ設定により、TCPの振る舞いを最適化する。

# /etc/sysctl.d/99-5g-network-tuning.conf
# BBR輻輳制御アルゴリズムの有効化
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# TCPウィンドウサイズの動的チューニング範囲の拡大（高スループット環境向け）
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# ネットワークバッファのキュー長を最適化し、バッファブロート（Bufferbloat）を抑制
net.core.netdev_max_backlog = 10000

パケットキャプチャとレイヤ横断解析のすすめ

無線区間の詳細なPUCCHフォーマットの変化やリソース割り当てを直接パケットアナライザ（Wireshark等）で覗くことはできないが、gNB側のログや、端末の診断インターフェース（Qualcomm QXDMやオープンソースのsrsRAN等のシミュレータ環境）を用いることで、物理層の振る舞いと上位レイヤのパケットロスを突き合わせることが可能だ。

例えば、tcpdumpで取得したpcapを分析する際、ACKの遅延（Delta Time）が特定の周期で跳ね上がっている場合、それは無線側のDRX（Discontinuous Reception）サイクルや、PUCCHの送信機会（PRACH/PUCCH occasion）のミスマッチに起因している可能性が高い。

# 特定のサーバーとの通信におけるTCP ACKの遅延を解析するためのtsharkコマンド例
tshark -r capture.pcap -Y "tcp.flags.ack == 1 && tcp.len == 0" -T fields -e frame.time_relative -e tcp.stream -e tcp.analysis.ack_rtt

—

結びにかえて

PUCCHというたった数ビットの制御情報を運ぶチャネルの仕様を深く理解することは、一見すると泥臭い物理レイヤの底を覗くことに思えるかもしれない。しかし、その挙動が上位のトランスポート層（TCP/UDP）、さらにはTLSハンドシェイクやアプリケーションの体感速度（RTT）にまで一本の糸で繋がっていることを知れば、インフラエンジニアとしての視座は一段と高まるはずだ。

パケットが電波に乗るその瞬間、目に見えないグリッドの中で繰り広げられる制御の妙技。これらを自在にコントロールし、極限まで無駄を削ぎ落としたネットワークを構築することこそ、真の技術スペシャリストの醍醐味である。

スポンサーリンク

コメント

タイトルとURLをコピーしました