5Gの「一瞬」を支える泥臭い技術：HARQとRV制御がパケットロスを無効化する仕組み
こんにちは。現場で叩き上げられてきたネットワークエンジニアなら、一度は「なぜ、この通信はこんなに不安定な無線環境でも切れないのか？」と不思議に思ったことがあるはずです。
Web APIの設計やクラウドのインフラ運用をしていると、TCPの再送制御（Retransmission）には馴染みがあるでしょう。しかし、モバイル通信、特に5G（NR）の世界では、TCPの再送を待っていては遅延の嵐に飲み込まれてしまいます。そこで登場するのが、物理層（L1）でパケットを救い出す「HARQ（Hybrid ARQ）」という名の守護神です。
今日は、教科書的な説明をすっ飛ばして、現場のエンジニアが知っておくべき「HARQの深淵」と、その制御を支える「RV（Redundancy Version）」の仕組みを解剖していきます。
—
1. なぜ上位レイヤーの再送では間に合わないのか
TCPの再送は、数ミリ秒から数百ミリ秒の単位でRTO（Retransmission Timeout）を判断します。しかし、Sub6やミリ波が飛び交う空中で、そんな悠長なことをしていたら、ビデオ会議はカクつき、リアルタイムゲームは破綻します。
HARQは、この再送を「物理層のスケジューリング」の中に組み込んでいます。パケットが破損したとき、受信側（UE：端末）が「ACK/NACK」を即座に送り返し、送信側（gNB：基地局）が同じデータを再送する。このサイクルを数ミリ秒以内で完結させる。これが5Gの低遅延の正体です。
—
2. HARQの核心：「ソフト結合」とRVの魔法
HARQのすごいところは、単なる「取り直し」ではない点です。受信したパケットが破損していた場合、それを捨てずにメモリ（ソフトバッファ）に保持します。そして、次に送られてきた再送データと、以前の失敗したデータを「合成（Soft Combining）」して、正しいパケットを復元しようと試みます。
ここでキーマンとなるのが RV（Redundancy Version） です。
RVは、再送のたびに「どのビットを重点的に送るか」というパターンの指針です。例えば、以下の4つのパターン（RV0, 1, 2, 3）を使い分けます。
- RV0: 最初の一投。すべての情報を含む。
- RV1, 2, 3: データのパンクチャリング（間引き）パターンを変える。
受信側は、たとえ1回目が失敗しても、2回目に異なるRVで送られてきたパケットを合成することで、情報量が補完され、CRCエラーを突破できる確率が劇的に高まります。これが「Chase Combining」や「Incremental Redundancy」と呼ばれる技術の泥臭い実態です。
—
3. Webエンジニアが意識すべき「HARQ」の影
皆さんがWebアプリ開発で curl や Fetch API を叩くとき、その裏でHARQがどう動いているかを想像したことはありますか？
例えば、Pythonで不安定なLTE/5Gネットワークをシミュレートしながら通信テストを行う場合、以下のコードのようにタイムアウト設定を極端に短くすると、HARQの再送制御が間に合わず、アプリケーション層でエラーが頻発する様子を観察できます。
import requests
from requests.adapters import HTTPAdapter
# 実務Tips: 物理層のHARQ限界を考慮したタイムアウト設計
# 物理層のHARQで解決できないパケットロスが続くと、
# アプリ層でTCP再送が走り、さらに遅延が悪化する
session = requests.Session()
adapter = HTTPAdapter(max_retries=3) # TCPレベルの再送回数
session.mount("https://", adapter)
try:
# 5G環境での低遅延レスポンスを期待したタイムアウト値
response = session.get("https://api.example.com/data", timeout=(1.0, 3.0))
print(f"ステータスコード: {response.status_code}")
except requests.exceptions.Timeout:
# HARQが追いつかず、無線環境が悪化した時の挙動をログへ
print("無線区間のパケットロスがHARQの再送限界を超えました")—
4. デバッグの現場から：なぜ「無線は水物」なのか
ネットワークエンジニアとして現場に立つと、特定エリアでパケットロスが多発するというクレームによく遭遇します。パケットキャプチャ（tcpdump）を見ると、確かにTCPの重複ACKが並んでいる。
ここで重要なのは、「それは無線区間のHARQが失敗しきった結果なのか？」を切り分けることです。
- HARQの失敗: gNBとUE間の物理的な信号強度不足（RSRP/RSRQ低下）。
- スケジューリングの競合: セルの混雑により、再送用のリソースが割り当てられていない。
curl でデバッグする際は、-w オプションで詳細なタイミングを確認しましょう。
# 接続時間と転送時間を分解して観察する
curl -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nStartTransfer: %{time_starttransfer}s\nTotal: %{time_total}s\n" \
-o /dev/null -s https://api.example.com/healthもし time_starttransfer が極端に大きい場合、無線区間でのHARQ再送が頻発し、物理層でパケットの滞留が起きている可能性が極めて高いです。
—
最後に：ネットワークを「透明」にするために
HARQやRVといった物理層の制御は、普段のWeb開発では「隠された世界」です。しかし、この数ミリ秒の駆け引きが、私たちのサービスを「サクサク動く」ものにしています。
インフラエンジニアやSREは、時には物理層の挙動まで想像を巡らせる必要があります。「なぜ今、この遅延が起きているのか？」という問いに対して、無線区間のHARQ再送まで遡れる視点を持つこと。それが、単なるオペレーターと、真のネットワーク・アーキテクトを分ける境界線です。
皆さんのサービスが、どんな過酷な電波状況でも届くことを願っています。現場からは以上です。
コメント