5G/LTEのQoSは「魔法の杖」ではない：QCI/5QIの深淵とパケット最適化の極意
ネットワークエンジニアとして現場に立つと、たびたび耳にするのが「5Gになったのに、なぜか動画がカクつく」「特定アプリのレイテンシが安定しない」という嘆きです。通信事業者が提示する「理論上の最大速度」という甘い蜜に惑わされ、実際のトラフィックがどのように無線区間（Uuインターフェース）を通過し、ベアラ制御されているかを理解していないケースが多々あります。
今回は、QCI（4G）および5QI（5G）というQoS制御の心臓部を紐解き、トランスポート層で我々が何をすべきか、その「泥臭い最適化の術」を共有しましょう。
—
QCI/5QIが制御する「パケットの優先順位」という現実
LTE時代から続く QCI（QoS Class Identifier）と、5Gの 5QI。これらは単なる優先度タグではありません。パケットが無線基地局（gNB/eNB）のスケジューラーに到達した際、そのパケットを「どのキューに突っ込むか」「パケットドロップのしきい値はどうするか」を決定する、いわば通信の背骨です。
特に、ARP（Allocation and Retention Priority）は重要です。これはリソースが枯渇した際、誰を切り捨て、誰を維持するかを決める「生存権」です。インフラ設計において、ミッションクリティカルなIoTデバイスには高い優先度を与えつつ、ベストエフォート型のトラフィックをいかに隔離するかが、システム全体の安定性を左右します。
パケットロスを極小化するトランスポート層のチューニング
QoSタグを信じすぎるのは危険です。無線区間は常に変動する不安定なメディアです。TCPの挙動を調整し、無線環境特有の「バースト的なパケットロス」に備える必要があります。
LinuxカーネルのTCPスタックをチューニングする際、デフォルトの cubic アルゴリズムでは、無線環境特有の瞬断によるウィンドウサイズの急激な縮小が問題になります。ここは bbr (Bottleneck Bandwidth and Round-trip propagation time) への切り替えを推奨します。
# 現在の輻輳制御アルゴリズムを確認
sysctl net.ipv4.tcp_congestion_control
# BBRを有効化するための設定（/etc/sysctl.confに追記）
# 無線区間の帯域とRTTを動的に推定し、ロスを「輻輳」と誤認させない
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr—
TLSハンドシェイクとRTTの削減：モバイル通信のボトルネックを潰す
モバイル環境において、RTT（Round Trip Time）は最大の敵です。3G/4G/5Gの切り替わりやハンドオーバーが発生するたび、RTTは数ミリ秒から数百ミリ秒単位で跳ね上がります。TLS 1.3の導入は必須ですが、それだけでは足りません。0-RTT (Zero Round Trip Time) を活用しつつ、セキュリティを担保する設計が必要です。
また、HTTP/3 (QUIC) の採用により、UDPベースで多重化されたストリームを制御することで、1つのパケットロスが全ストリームを停止させる「Head-of-Line Blocking」を回避できます。
TCP/QUICバッファの最適化（受信ウィンドウの拡大）
モバイルの広帯域（Sub6/ミリ波）をフル活用するには、tcp_rmem と tcp_wmem のチューニングが不可欠です。
# 受信バッファの最小、デフォルト、最大値を調整
# 高速なモバイル回線では、ウィンドウサイズを大きくしてスループットを稼ぐ
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"
# TCPウィンドウの自動調整を強制
sysctl -w net.ipv4.tcp_window_scaling=1—
現場で直面する「ヘッダー圧縮」とセキュリティのジレンマ
モバイルネットワークでは、ROHC（RObust Header Compression）がIPヘッダーを極限まで削ぎ落としています。しかし、我々がセキュリティのために導入するVPNや強固なTLSトンネルは、このヘッダー圧縮の効果を無効化してしまうことがあります。
- VPN利用時の注意点: MTUサイズを低めに設定（例:
1350バイト程度）し、フラグメンテーションによるパケットロスを防ぐことが、通信安定性の鍵です。 - 脆弱性回避:
5QIが低い（優先度が低い）トラフィックに対しては、攻撃者がDoSを仕掛けやすい傾向があります。アプリケーション層でのレートリミットだけでなく、インフラ側でARP値を適切に設定し、重要度の低いフローがシステム全体を巻き込まないような「隔離」を徹底してください。
—
最後に：数字の裏側にある「パケットの息遣い」を感じる
「5Gだから速い」という過信を捨て、パケットが無線基地局のスケジューラーでどのように評価され、カーネルがTCPウィンドウをどう制御しているか。この「スタックの深部」を想像できるエンジニアだけが、過酷なモバイル環境で真の安定したサービスを提供できます。
マニュアル通りの設定を疑い、tcpdump や tshark でパケットの再送率を追いかけ、ミリ秒単位の揺らぎを可視化する。その泥臭い作業の先にしか、最適化の解はありません。
次回の記事では、ミリ波（mmWave）におけるビームフォーミングの物理的な制約と、それがTCPの再送制御に与える影響について、さらに深く掘り下げていこうと思います。現場からは以上です。
コメント