【実務・中級編】モバイル回線におけるQoS制御とARP(Allocation and Retention Priority)・QCI/5QI – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

混雑したネットワークの「裏口」を通る技術：QCIと5QIが制御するパケットの優先度

エンジニアの皆さん、お疲れ様です。深夜のリリース作業中に「APIのレスポンスが妙に揺らぐな」と感じたことはありませんか？サーバーの負荷は正常、DBもクエリ効率は悪くない。なのになぜか、モバイル回線越しだとパケットロスが多発する。

その原因、もしかすると「パケットの優先度」という、普段はブラックボックス化されているレイヤーで起きているかもしれません。今日は、4Gの QCI から5Gの 5QI へと受け継がれた、モバイル回線におけるトラフィック制御の深淵を覗いてみましょう。

なぜパケットは「公平」ではないのか

モバイルネットワークは、無線リソースという「限られた資源」を奪い合う戦場です。全員が同じ優先度で通信していたら、VoLTEの通話がプツプツ切れたり、緊急地震速報が届かなかったりします。

ここで登場するのが、QoSクラス識別子（4Gでは QCI、5Gでは 5QI）です。これはパケットのヘッダーに付与される「身分証明書」のようなもので、基地局やコアネットワークのルーターに対し、「このパケットは遅延に敏感だから先に行かせてくれ」「こっちは多少遅れてもいいから確実に届けてくれ」と指示を出します。

4GのQCIから5Gの5QIへ：何が変わったか

4Gの QCI は1〜9の整数で定義されていました。例えば QCI 1 はVoLTE音声用で、帯域保証（GBR）があり、遅延が極めて厳格に制限されます。一方で QCI 9 はベストエフォート（Non-GBR）、つまり我々が普段使っているWebブラウジングなどの通信です。

5Gの 5QI では、さらに細分化されました。

GBR (Guaranteed Bit Rate): 帯域保証。特定の通信速度を維持する。
Non-GBR: 帯域保証なし。空いているリソースを柔軟に使う。

特に重要なのが ARP (Allocation and Retention Priority) です。これは通信の確立時や、リソースが枯渇した際、誰が生き残り、誰が切断されるかを決める「優先権」です。

実務で意識すべきパラメータ：ARPとQoSフロー

インフラエンジニアやSREがAPI設計で意識すべきは、「自分のトラフィックはどのクラスとして流れるべきか」という点です。例えば、社内IoTデバイスの遠隔操作APIと、単なるログ送信APIを同じ 5QI で流すべきではありません。

以下は、プライベート5G環境などで UPF（User Plane Function）のポリシーを設定する際のイメージです。

# 設定例: 5QI を指定したトラフィックフローのルール定義
# JSON形式のポリシー設定（イメージ）
{
  "qos_profile": {
    "5qi": 9,             # Web通信等のベストエフォート
    "arp": {
      "priority": 10,     # 数値が小さいほど高優先度
      "pre-emption-cap": "not-preempt", # 他の通信を追い出さない
      "pre-emption-vuln": "may-preempt"  # リソース逼迫時に追い出される可能性あり
    },
    "gbr": {
      "ul": "0",          # 上り帯域保証なし
      "dl": "0"           # 下り帯域保証なし
    }
  }
}

アプリケーション開発者ができる「デバッグ」のヒント

モバイル回線を通るWeb APIを叩くとき、サーバーサイドのログだけで原因が特定できない場合、クライアント側で TCP の挙動を追う必要があります。

Pythonの scapy 等を使って、特定のトラフィックがどの程度バーストしているか、あるいはパケットロスがどのタイミングで起きているかを可視化してみましょう。

# scapyを使用した簡易的なパケット監視スクリプト
from scapy.all import sniff

def analyze_packet(packet):
    # TCPヘッダーを解析し、フラグや再送をチェック
    if packet.haslayer('TCP'):
        # 再送フラグ(Retransmission)の兆候を確認
        if packet['TCP'].flags == 0x02: # SYNパケットなど
            print(f"Connection attempt to {packet['IP'].dst}")

# ネットワークインターフェースを監視
sniff(filter="tcp port 443", prn=analyze_packet, store=0)

モバイルネットワークでは、QCI/5QI の値が低い（優先度が高い）通信は ARP の値によって、混雑時に「優遇」されます。もし皆さんのAPIが、高負荷時に決まってタイムアウトするなら、それは無線区間での「格付け」によってドロップされている可能性を疑ってください。

最後に：泥臭い現場の教訓

私が経験した現場では、特定のキャリア回線でのみAPIのレスポンスが遅延する問題がありました。原因を突き詰めると、APIの通信が「低優先度のベストエフォート（Non-GBR）」として扱われ、基地局の混雑時にパケットの優先待ち（バッファリング）が発生していたのです。

解決策は、通信内容をアプリケーション層で最適化し、HTTP/3 (QUIC) を導入して「ヘッド・オブ・ライン・ブロッキング」を回避することでした。

モバイル通信は、決して「信頼できるパイプ」ではありません。ネットワークの優先度（QoS）という壁があることを前提に、APIの設計、タイムアウト値のチューニング、そしてリトライ戦略を組む。これが、モバイル時代を生き抜くシニアエンジニアのたしなみです。

次回は、5G NSA (Non-Standalone) 構成における、LTE と NR の二重接続（Dual Connectivity）がパケット順序制御に与える影響について深掘りしましょう。それでは、また現場で！