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

5Gの「速さ」を支える主役：PDSCHの深淵とエンジニアが知るべき最適化の勘所

こんにちは。ネットワークの現場でパケットの挙動を追いかけて数十年、現場の泥臭いトラブルと格闘し続けてきた筆者です。

今日は、5G（5G NR）の性能を語る上で避けては通れない、まさに「ユーザーデータの通り道」である PDSCH（Physical Downlink Shared Channel）について深掘りします。「5Gは速い」と一口に言いますが、その背後でQAM（直交振幅変調）がどう切り替わり、どうやってパケットロスを補完しているのか。このメカニズムを知っているか否かで、アプリケーション側の設計、特に「Web APIのタイムアウト設定」や「高負荷時の挙動理解」の解像度が段違いに変わります。

PDSCHとは：ただのパイプラインではない「動的な適応体」

PDSCHは、基地局（gNB）から端末（UE）へ、ユーザーのトラフィック（WebのHTMLデータやストリーミングのパケットなど）を運ぶ物理層のチャネルです。

ここが面白いのは、単にデータを流すだけではなく、その時の電波環境（SINR：信号対干渉雑音比）に合わせて、瞬時に「変調方式」と「符号化率」を最適化する点です。これを「適応変調符号化（AMC）」と呼びます。

変調方式の限界に挑む：256QAMの世界

4Gから続く技術ですが、5Gではこの変調方式の精度が極限まで高められています。

QPSK (2bit/symbol): 電波状況が最悪でも繋ぐ「生存優先」モード。
16QAM (4bit/symbol): 都市部でよく見る標準的な速度。
64QAM (6bit/symbol): 安定した通信環境でのベースライン。
256QAM (8bit/symbol): 5Gの真骨頂。ノイズのないクリーンな環境で、極めて高いスループットを叩き出す。

エンジニアとして意識すべきは、「256QAMは、少しのノイズでパケットロスに転落する諸刃の剣である」という事実です。API設計時に、不安定な回線を想定した「再送アルゴリズム」や「コネクション維持設定」が重要なのは、まさにこの物理層の変動がアプリ層にまで波及するからです。

HARQとTBS：パケットを「捨てない」仕組み

物理層でエラーが起きても、TCPまでエラーを波及させないのが HARQ（Hybrid Automatic Repeat Request）の役割です。

PDSCHでは、基地局が送ったデータの「パケットブロック（トランスポートブロック）」に対して、端末が ACK/NACK を即座に返します。NACK（エラー検出）が飛ぶと、即座に再送が行われます。このプロセスは非常に高速で、ミリ秒単位で完結します。

また、一度に送るデータ量である TBS（Transport Block Size）は、無線リソースの割り当て数と変調方式から動的に算出されます。3GPPの仕様（TS 38.214）に基づき、以下のパラメータを組み合わせて算出されます。

# TBS決定のための主要パラメータ例
- MCS Index (0-28): 変調方式と符号化率を決定する指標
- Number of PRBs: 割り当てられたリソースブロック数
- Target Code Rate: 目標とする符号化率

実務に活かす：通信品質とAPI開発の繋がり

我々アプリケーションエンジニアが curl や Fetch API を叩くとき、裏側ではこの PDSCH が必死に空気を読んで調整を繰り返しています。以下のサンプルは、通信状態を考慮したタイムアウト設計の考え方です。

Pythonによるリトライ制御の例

ネットワークが不安定な際、物理層の再送（HARQ）が追い付かない場合があります。アプリケーション側でこれを補う実装が必要です。

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

def create_resilient_session():
    # 物理層の再送待ち時間を考慮し、指数バックオフでリトライする
    retry_strategy = Retry(
        total=3, # リトライ回数
        backoff_factor=1, # 次のリトライまでの待機時間（1s, 2s, 4s...）
        status_forcelist=[502, 503, 504],
        allowed_methods=["GET", "POST"]
    )
    adapter = HTTPAdapter(max_retries=retry_strategy)
    session = requests.Session()
    session.mount("https://", adapter)
    return session

# 5G環境下で遅延やロスが発生しやすいAPI呼び出しに利用
api_client = create_resilient_session()
response = api_client.get("https://api.example.com/data")

トラブルシューティングの現場から：デバッグTips

現場で「なぜか特定場所で速度が出ない、パケットロスが激しい」という相談を受けた際、私はまず以下の点を疑います。

1. CQI（Channel Quality Indicator）の変動: 端末が報告する電波品質が悪化していないか。
2. BLER（Block Error Rate）: PDSCHの再送が多発していないか。
3. MTUサイズ: モバイルネットワーク特有のパケットサイズ制限に引っかかってフラグメンテーションが起きていないか。

curl でテストする際は、--trace-time をつけて詳細な挙動を確認するのが鉄則です。

# タイムスタンプ付きで詳細な通信ログを取得し、レイテンシの揺らぎを可視化する
curl -v --trace-time https://api.example.com/v1/health-check

最後に：ネットワークを「透明」にするために

5Gは、魔法のような技術ではありません。物理的な電波の性質と、それを制御する緻密なアルゴリズムの積み重ねです。

我々エンジニアが「なぜ通信が遅いのか」を論理的に説明できることは、プロダクトの信頼性に直結します。「とりあえず繋がればいい」という設計から、「物理層の変動すら許容する強靭なアプリケーション」へ。この記事が、皆さんの設計思想を一段引き上げるヒントになれば幸いです。

次回の記事では、PDCCH（制御チャネル）のスケジューリングと、それがWebのレスポンス時間に与える影響について深掘りしていきます。それでは、現場のエンジニアの皆さん、引き続き良いネットワークライフを！