5Gの「裏番長」PCFを使い倒せ：動的QoS制御とSMF連携の深淵
ネットワークエンジニア諸君、今日もパケットの海を泳いでいるか？
最近、5Gの現場で「なぜか特定のアプリケーションだけ通信速度が出ない」「帯域制御のポリシーが正しく反映されない」といった泥臭いトラブルに頭を抱えてはいないだろうか。
5Gコアネットワーク（5GC）において、我々エンジニアが最も「直接触ることは少ないが、死ぬほど重要」な制御塔が、今回解説する PCF（Policy Control Function） だ。
PCFは単なる設定置き場ではない。加入者の契約情報、ネットワークの負荷状況、そしてアプリケーションからの要求を統合し、リアルタイムで通信の「格付け（QoS）」を決定する、いわば5GCの頭脳だ。
今日は、このPCFがSMF（Session Management Function）やAF（Application Function）とどう連携し、動的なQoSフローを制御しているのか、現場の視点から紐解いていく。
—
1. PCFが制御する「動的QoS」の仕組み
従来のLTE（EPC）におけるPCCアーキテクチャが、5GCではサービスベースアーキテクチャ（SBA）へと進化した。PCFは N7 インターフェースを介してSMFと通信し、ポリシーを押し付ける。
ここで重要なのが PCCルール（Policy and Charging Control Rule） だ。PCFがSMFに対して、「このセッションは動画配信だから優先度を上げろ」「このユーザーは月間通信量を超えたから帯域を絞れ」といった命令を下すための設計図だ。
QoSフロー制御の鍵となるパラメーター
実務で必ず意識すべきは、以下の 5QI と ARP だ。
- 5QI (5G QoS Identifier): パケットの優先順位や遅延バジェット（PDB）を定義するインデックス。
- ARP (Allocation and Retention Priority): リソースが枯渇した際、誰の通信を維持し、誰を切断するかの優先度。
- GBR / Non-GBR: 帯域保証が必要なストリームか、ベストエフォートか。
—
2. 実践：AFからPCFへのポリシー要求（REST API）
現代のインフラ運用では、AF（アプリケーションサーバー）から N5 インターフェースを通じてPCFにポリシーを動的に要求するケースが増えている。これは HTTP/2 ベースの REST API で行われる。
例えば、特定のユーザーの通信に対して、高画質配信のために「GBR（帯域保証）」を一時的に適用するリクエストは、以下のようなJSONを POST することで実現される。
// AFからPCFへ送信するポリシー制御要求（リクエスト例）
{
"afAppId": "VideoStreaming-Service-01",
"afStatus": "PRELIMINARY",
"medComponents": {
"1": {
"medCompN": 1,
"medSubComps": {
"1": {
"fNum": 1,
"fDescs": ["permit out ip from 192.168.1.10 8080 to assigned"],
"qos": {
"5qi": 2, // 映像配信に適した高優先度QoS
"gbrDl": "100Mbps", // ダウンリンク帯域保証
"gbrUl": "10Mbps" // アップリンク帯域保証
}
}
}
}
}
}このリクエストを受けたPCFは、N7 を介してSMFに対し、「このセッションの PDR (Packet Detection Rule) と QER (QoS Enforcement Rule) を更新せよ」という命令を投げつける。
—
3. インフラエンジニアのためのトラブルシューティングTips
現場でよくあるのは、「AFからリクエストを投げたはずなのに、端末側のスループットが変わらない」という事象だ。以下の手順で切り分けろ。
手順1：パケットキャプチャの基本
Wireshark で HTTP/2 の通信を追いかける際、N5 インターフェースでの 403 Forbidden や 400 Bad Request をまず確認しろ。AF側が渡している SUPI（加入者識別子）が間違っていないか、PCFのポリシーデータベースと照合するのが最初の一歩だ。
手順2：SMFのステータス確認
PCFからの命令がSMFに届いているかを確認するには、SMFのCLIで現在アクティブな QER をダンプするのが一番早い。
# SMFでのQoSポリシー適用状況を確認するイメージ（仮想コマンド）
smf-cli show session qer --ue-ip 10.10.0.5
# 出力例
# QER ID: 101, 5QI: 2, GBR-DL: 100Mbps, Status: ACTIVEもしここで Status: INACTIVE ならば、PCFからのポリシー適用に失敗しているか、無線区間（RAN）側で RRC のリソース確保が拒否されている可能性がある。
—
4. 最後に：エンジニアとしての心構え
PCFは「魔法の箱」ではない。あくまで、定義された契約とポリシーに基づいて動的にリソースを配分する管理機能だ。
Web API設計を行うエンジニアは、アプリケーションのトラフィック特性を理解し、適切な 5QI をAF側から指定する設計力を磨く必要がある。また、インフラ運用担当は、PCFとSMF間の N7 インターフェースの遅延が、ユーザー体験（QoE）に直結することを忘れてはならない。
「なぜこの設定が必要なのか？」
常に通信の挙動をパケットレベルで想像すること。その積み重ねが、5G時代のネットワークを支える力になる。
何か不明点や、「こんなパケット挙動で詰まった」というエピソードがあれば、いつでもコメント欄で共有してほしい。現場の知見こそが、最強のエンジニアリングだ。
コメント