PCF / SM Policy Association / PCC Rule — PolicyはどうやってUE・gNB・UPFに届くのか¶

学習目標¶

この章を読み終えると、次のことができるようになります。

• SM Policy Association が PDU Session ごとに SMF⇔PCF 間で作られる関係であり、Npcf_SMPolicyControl_Create で確立されることを説明できる
• PCFの判断材料（SMFからの入力 / UDRのPolicy Data / AF要求 など）を挙げられる
• PCC Rule の構成要素（SDF template、Precedence、QoS parameters、Charging、Gate status）を説明できる
• PCFはUE・gNB・UPFを直接設定しないこと、SMFが PCC Rule を QoS Rule（N1）/ QoS Flow Level QoS Parameters（N2）/ PDR・QER・URR（N4） に翻訳することを図で説明できる
• PCF-initiated SM Policy Association Modification から Network requested PDU Session Modification へつながる流れを説明できる
• 「Policyが来ない」「PCFは正しいのにUPFが違う」「RANだけ違う」を、Interfaceを横断して切り分けられる

前提知識¶

• GFBR / MFBR / AMBR / ARP / QoS Flow / QFI / 5QI — PCC Rule が指定する QoS の中身
• PFCP と PDR / FAR / QER / URR / PDR / PDI / SDF Filter / Precedence — SMFが翻訳した結果がUPFでどう使われるか
• PDU Session Establishment 深掘り — N1 SM / N2 SM 情報を AMF が運ぶ仕組み
• 補助: Policy / PCF / N7 / QoS / PDU Session Modification / Release

Why — QoSの「値」を決める人と「実行する」人は別¶

前章までで、5QI・GFBR・MFBR・Session-AMBR・ARP といった QoSの値 を見てきました。では、ある加入者のある通信に、その値を 誰が決め、誰が各ノードに設定する のでしょうか。

• 値を決めるには、加入者契約（UDR）・接続先（DNN / S-NSSAI）・アプリの要求（AF）・事業者ポリシー を総合的に見る必要があります。これは個々のノードではなく、Policy専門のNFに集約した方が一貫します → PCF。
• 一方で、UE・gNB・UPF はそれぞれ 別のプロトコル（NAS / NGAP / PFCP）と別の情報形式 で設定されます。この3者すべてと会話できるのは、PDU Session を管理する SMF です。

そこで 5GC は、PCFが判断し（Policy Decision）、SMFが翻訳・展開する（Policy Enforcement の制御） という分業を採っています（TS 23.503 §4.2 / §6.2.1、要確認）。

例え話: PCFは「本社の料金・サービス企画部」、SMFは「現場の工事責任者」です。企画部は「この顧客の動画は最大10 Mbps」という 方針書（PCC Rule） を書きますが、配線工事はしません。工事責任者が方針書を読み、端末向けの説明書（QoS Rule）、基地局向けの指示書（QoS Profile）、交換機向けの設定（PDR / QER）に 書き分けて 配ります。

What — SM Policy Association¶

PCFが持つ Policy Association の種類¶

PCFは相手NFごとに Policy Association を持ちます。本章が扱うのは SM Policy Association です。

SM Policy Association は PDU Session 1つにつき1つ 作られ、PDU Session の確立で生まれ、Release で終わります（TS 23.502 §4.16.4 / §4.16.6）。

SM Policy Association のライフサイクル¶

What — PCFは何を材料にPolicyを決めるのか¶

PCFがPCC判断に使える入力は TS 23.503 §6.2.1.2（Input for PCC decisions、要確認）に列挙されています。代表的なものを、どこから来るか で整理します。

flowchart LR
    SMF["SMF
Npcf_SMPolicyControl_Create / Update"] -->|"SUPI, DNN, S-NSSAI,
RAT/Access Type, ULI,
UE IP, 加入Session-AMBR,
加入default QoS"| PCF["PCF
Policy Decision"]
    UDR["UDR
Policy Data"] -->|"N36 / Nudr
SM Policy Data,
Usage Monitoring Data"| PCF
    AF["AF
(直接 or NEF経由)"] -->|"N5 / Npcf_PolicyAuthorization
メディア・アプリ情報"| PCF
    CHF["CHF"] -->|"N28 Spending Limit
(Policy Counter状態)"| PCF
    OP["事業者ポリシー
(PCFローカル設定)"] --> PCF
    PCF -->|"SmPolicyDecision
PCC Rule / Session Rule / PCRT"| SMF

ここで重要なのは、加入者の「契約上の」Session-AMBR / default QoS は UDM → SMF → PCF と流れ、PCFが「認可済み（authorized）」の値として SMF に返す ことです（TS 23.503 §6.4、要確認）。PCFがいる構成では、SMFが最終的に使うのは PCF が認可した値です。

What — PCFの出力: SmPolicyDecision¶

PCFの判断結果は、N7上では SmPolicyDecision というデータ構造で SMF に渡されます（TS 29.512 §5.6.2.4、要確認）。中身は大きく次の3種類です。

PCC Rule の構成（TS 23.503 §6.3.1）¶

TS 23.503 §6.3.1 の表（PCC rule information、要確認）を、用途別にまとめます。

PCC Rule
├─ Rule identifier                 ← PDU Session内で一意
├─ Service data flow detection     ← どのトラフィックか
│   ├─ Precedence                  ← 複数ルールが重なったときの評価順
│   └─ SDF template                ← 次のいずれか
│       ├─ SDF filter のリスト      ← Packet Filter（IP 5-tuple 等）の集合
│       └─ Application identifier  ← アプリIDで検出
├─ Policy control                  ← どう扱うか
│   ├─ Gate status                 ← 通す / 止める
│   ├─ 5QI / ARP                   ← QoSクラスと優先・横取り
│   ├─ UL / DL Maximum bitrate     ← SDF単位の上限
│   ├─ UL / DL Guaranteed bitrate  ← GBRの場合
│   └─ QoS Notification Control 等
├─ Charging                        ← どう課金するか
│   ├─ Charging key（Rating Group）
│   ├─ Service identifier
│   ├─ Charging method / Measurement method
│   └─ ...
├─ Usage monitoring control        ← 使用量の監視
└─ Traffic steering 関連（AF influence 等）

How — SM Policy Association の確立¶

Call Flow（PDU Session Establishment の中で）¶

TS 23.502 §4.3.2.2.1 では、SMFは PCF Selection の後に SM Policy Association を確立し（step 7a / 7b）、UE IPアドレス割当後に SMF-initiated Modification で情報を補います（step 9）。いずれも step番号は版により異なるため要確認です。§4.16.4 の中身と合わせて簡略化すると次のとおりです。

sequenceDiagram
    participant UE
    participant AMF
    participant SMF
    participant PCF
    participant UDR
    participant UPF
    UE->>AMF: PDU Session Establishment Request (N1)
    AMF->>SMF: Nsmf_PDUSession_CreateSMContext
    Note over SMF: UDMから SM加入データ取得
(加入Session-AMBR / default QoS)
    Note over SMF: PCF Selection (NRF Discovery 等)
    SMF->>PCF: Npcf_SMPolicyControl_Create
(SUPI, DNN, S-NSSAI, RAT, ULI, 加入QoS 等)
    PCF->>UDR: Nudr_DM_Query (SM Policy Data)
    UDR-->>PCF: Policy Data
    PCF->>UDR: Nudr_DM_Subscribe (変更通知の購読)
    Note over PCF: Policy Decision
    PCF-->>SMF: 201 Created + SmPolicyDecision
(Session Rule, PCC Rule, PCRT)
    Note over SMF: UPF Selection・UE IP割当
    SMF->>PCF: Npcf_SMPolicyControl_Update
(PCRT条件成立 例: UE IP割当)
    PCF-->>SMF: 更新されたPolicy (あれば)
    Note over SMF: QoS Flow binding・QFI割当
(PCC Rule を翻訳)
    SMF->>UPF: PFCP Session Establishment
(PDR / FAR / QER / URR)
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer
(N1: QoS Rules 等 / N2: QoS Flow情報)

Signal Flow¶

BSFを配置している場合、PCFは SM Policy Association に対応する Binding 情報を BSF に登録します（Nbsf_Management_Register。TS 23.502 §5.2.13.2.2。登録の契機（UE IP / MAC 確定時。§4.16.4 / §4.16.5.1）は要確認）。AFが「このUEのセッションを担当するPCF」を見つけるための仕組みで、詳細は BSF / PCF Binding で扱います。

How — 最重要図: PCFは直接設定しない。SMFが翻訳する¶

PCFは UPFへPFCPを送らず、gNBへNGAPを送らず、UEへ5GSMメッセージを送りません。PCFの出力はあくまで N7 上の SmPolicyDecision で、それを各ノードの言語に翻訳するのは SMF です。

flowchart TD
    PCF["PCF
SmPolicyDecision
PCC Rule + Session Rule"] -->|"N7
Npcf_SMPolicyControl"| SMF["SMF = 翻訳者
QoS Flow binding
QFI割当"]
    SMF -->|"N4 PFCP
PDR / QER / URR / FAR"| UPF["UPF
検出・Gate・帯域・計測"]
    SMF -->|"Namf_Communication_N1N2MessageTransfer
N1 SM container + N2 SM information"| AMF["AMF
中継のみ"]
    AMF -->|"NAS 5GSM
QoS Rules / QoS Flow Descriptions / Session-AMBR"| UE["UE
ULパケット → QFI"]
    AMF -->|"NGAP
QFI + QoS Flow Level QoS Parameters"| GNB["gNB
QoS Flow → DRB"]

PCF ──X──► UPF     PFCPは話さない（N4の制御側はSMF）
PCF ──X──► gNB     NGAPは話さない（N2の相手はAMF）
PCF ──X──► UE      SMのQoS Ruleは送らない（N1 SMの相手はSMF）

SMFは何をしているのか — QoS Flow binding と翻訳¶

TS 23.501 §5.7.1.5（QoS Flow mapping、要確認）は、SMFの役割を次のように整理しています。

1. QoS Flow binding: 各 PCC Rule を、既存の QoS Flow に入れるか、新しい QoS Flow を作るかを決める。判断に使う binding parameter は 5QI と ARP（ほかに QNC、Priority Level、Averaging Window、MDBV が設定されていればそれらも）です（TS 23.503 §6.1.3.2.4、要確認）。binding parameter が同じ PCC Rule は同じ QoS Flow にまとめられます。
2. QFI の割当: QoS Flow ごとに SMF が QFI を割り当てる。
3. 翻訳: QoS Flow / PCC Rule の情報を、UE・gNB・UPF のそれぞれに必要な形へ分解する。

（N1: TS 24.501 §9.11.4.12 QoS flow descriptions / §9.11.4.13 QoS rules / §9.11.4.14 Session-AMBR、N2: TS 38.413 §9.3.1.12 QoS Flow Level QoS Parameters、N4: TS 29.244 §7.5.2.2 / §7.5.2.5。いずれも節番号は要確認）

例え話: 同じ「動画は最大10 Mbps」という方針でも、端末への説明書には「この宛先へのパケットにはこの番号札（QFI）を付けて」、基地局への指示書には「番号札xの荷物はこの優先度で」、交換機への設定には「この条件に合うパケットは10 Mbpsで絞り、量を数えて」と、相手が理解できる言葉だけ が書かれます。

How — Policy は Session 確立後にも変わる¶

PCF-initiated SM Policy Association Modification（TS 23.502 §4.16.5.2）¶

PCFは、確立済みの SM Policy Association に対して Policy を変更できます。代表的な契機は次のとおりです（TS 23.502 §4.16.5.2、要確認）。

Network requested PDU Session Modification（TS 23.502 §4.3.3.2）¶

PCFからの UpdateNotify を受けた SMF は、必要に応じて PDU Session Modification を起動します。TS 23.502 §4.3.3.2 では、PCF起点の場合が step 1b として位置付けられています（step番号は要確認）。

sequenceDiagram
    participant UE
    participant gNB
    participant AMF
    participant SMF
    participant PCF
    participant UPF
    Note over PCF: 契機: AF要求 / Policy Data変更 等
    PCF->>SMF: Npcf_SMPolicyControl_UpdateNotify
(PCC Rule の追加 / 変更 / 削除)
    SMF-->>PCF: 204 No Content 等
    Note over SMF: QoS Flow binding を再評価
既存Flowへ追加 or 新Flow作成
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer
(N1: PDU Session Modification Command
N2: PDU Session Resource Modify Request Transfer)
    AMF->>gNB: NGAP PDU Session Resource Modify Request
    gNB->>UE: RRC Reconfiguration (NAS: Modification Command)
    gNB-->>AMF: PDU Session Resource Modify Response
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext (N2 SM情報)
    SMF->>UPF: PFCP Session Modification
(Create/Update PDR, QER, URR)
    UPF-->>SMF: PFCP Session Modification Response
    UE->>AMF: PDU Session Modification Complete (N1)
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext (N1 SM情報)
    Note over SMF: 必要なら UPF を再更新し
PCF へ結果を報告 (Npcf_SMPolicyControl_Update)

• UE が CM-IDLE の場合、N1/N2 を届ける前に Network Triggered Service Request（Paging）が必要になります（TS 23.502 §4.2.3.3、§4.3.3.2 内の条件は要確認）。
• 図は TS 23.502 §4.3.3.2 の基本フロー（N2 の応答を受けた後に N4 を更新）に沿った代表例です（step番号は要確認）。N4 を先に事前設定する実装もあります（実装依存）。全体像は PDU Session Modification / Release を参照してください。
• 変更が UPFだけで完結する 場合（後述のパターンA）、SMFは N1 / N2 を送らないことがあります。どこまで送るかは変更内容と SMF実装 によります。
• PDU Session Modification の NAS 側は TS 24.501 §6.3.2（Network-requested PDU session modification、要確認）、NGAP 側は TS 38.413 §8.2.3（PDU Session Resource Modify）です。

SMF-initiated と PCRT¶

逆方向の SMF-initiated SM Policy Association Modification（TS 23.502 §4.16.5.1）は、PCFが事前に指定した Policy Control Request Trigger の条件が成立したときに使われます。たとえば「RAT Typeが変わったら報告」「UE IPが割り当てられたら報告」です。PCFは報告を受けて Policy を見直し、応答で新しい PCC Rule を返すことができます。

How — 実務例: Video だけ帯域制御する¶

「特定の動画配信サービスのトラフィックだけ、DL最大10 Mbpsに制限したい」という要件を考えます。PCC Rule の作り方によって、SMFが更新する範囲が変わる点に注目してください。

パターンA: 既存の Non-GBR QoS Flow に入れて、SDF単位で絞る¶

PCC Rule "video-limit"
├─ Precedence: 100（default ルールより優先）
├─ SDF template: DL  from 203.0.113.0/24 port 443 to UE   ← 架空例
│                UL  from UE to 203.0.113.0/24 port 443
├─ 5QI / ARP: default QoS Flow と同じ値（Non-GBR）
└─ DL Maximum bitrate: 10 Mbps

• binding parameter（5QI / ARP）が default QoS Flow と同じなので、新しい QoS Flow は作られず、既存の QFI にまとめられます（TS 23.503 §6.1.3.2.4、要確認）。
• SMF は UPF に、SDF Filter 付きの PDR（Precedence 100）と、DL MBR = 10 Mbps の QER を追加します。
• gNB の QoS Flow パラメータは変わらないため、N2 には何も流れない ことがあり得ます。UE に QoS Rule を追加するかどうか（UL分類を変える必要があるか）は SMF の判断です（実装依存／要確認）。

パターンB: 専用の GBR QoS Flow を作る¶

AF からの要求（例: ライブ配信の品質確保）で、GBR を持つ専用 QoS Flow を作る場合は、binding parameter（5QI / ARP）が異なるため 新しい QFI が割り当てられ、N4・N2・N1 のすべて が更新されます。

flowchart LR
    A["PCC Rule 追加"] --> B{"binding parameter
(5QI, ARP 等) が
既存Flowと同じ?"}
    B -- "Yes (パターンA)" --> C["既存QFIへbinding
主に N4 だけ更新
(N1は SMF判断)"]
    B -- "No (パターンB)" --> D["新QFIを割当
N4 + N2 + N1 を更新
(PDU Session Modification)"]

実際の商用網では、動画の識別を IP 5-tuple だけでなく Application identifier（UPFのアプリ検出。PFD は NEF 経由で提供され得る。TS 23.502 §4.18、要確認）で行うこともあり、検出精度や方式は 実装依存 です。

How — AF が関わる場合（概略）¶

アプリ側が QoS を要求する場合、AF が PCF に要求し、PCF がそれを PCC Rule に変換します。

AF ──N5: Npcf_PolicyAuthorization_Create──► PCF
                                             │ (加入者・事業者ポリシーで承認 / 変更 / 拒否)
                                             ▼
                          Npcf_SMPolicyControl_UpdateNotify
                                             ▼
                                            SMF ──► N4 / N2 / N1

• AF の要求は「要求」であり、そのまま通るとは限りません（Policy）。
• AF が対象UEのセッションを担当する PCF を見つけるには BSF を使います（BSF / PCF Binding）。
• N5 の詳細は次々章 AF / N5 / Application Session、外部AFの NEF 経由は NEF / N33 で扱います。

Packet Analysis (Wireshark)¶

Policy の問題は 1つのInterfaceだけを見ても解けません。N7 → N4 → N2 → N1 → N3 を同じ PDU Session について横断します。

Display Filter¶

SBI の TLS サポートは必須ですが、PLMN 内での適用はオペレータ判断です（TS 33.501 §13.1、要確認）。Open5GS / free5GC 等のラボでは平文 HTTP/2 で構成されることもあります（設定依存）。HTTP/2 / JSON の詳細な読み方は次章 N7 SBI解析 で扱います。

Decode例（概念表現）¶

以下は TS 29.512 の OpenAPI 定義に沿った 概念表現 で、属性名は要確認、値は架空例です（要キャプチャ）。

POST /npcf-smpolicycontrol/v1/sm-policies  →  201 Created
SmPolicyDecision
├─ sessRules
│   └─ "sess-1"
│       ├─ authSessAmbr: { uplink: "100 Mbps", downlink: "200 Mbps" }
│       └─ authDefQos:   { 5qi: <Non-GBR値>, arp: { ... } }
├─ pccRules
│   └─ "video-limit"
│       ├─ pccRuleId:  "video-limit"
│       ├─ precedence: 100
│       ├─ flowInfos:
│       │   └─ flowDescription: "permit out 6 from 203.0.113.0/24 443 to assigned"
│       │      flowDirection:   BIDIRECTIONAL
│       └─ refQosData: [ "qos-video" ]
├─ qosDecs
│   └─ "qos-video"
│       ├─ 5qi:    <default QoS Flowと同じ値>
│       └─ maxbrDl: "10 Mbps"
└─ policyCtrlReqTriggers: [ ... ]

• flowDescription は RFC 6733 の IPFilterRule 形式を流用した表現です（TS 29.512 から TS 29.214 §5.4.2 Flow-Description AVP を参照する形、要確認）。
• PCC Rule は QoS の値を直接持たず、refQosData で qosDecs を 参照 する構造です。Trace では参照先まで追います。

対応する N4 側（概念表現、要キャプチャ）:

PFCP Session Modification Request
├─ Create PDR
│   ├─ PDR ID: 10
│   ├─ Precedence: 100
│   ├─ PDI: Source Interface = Core, UE IP Address, SDF Filter (203.0.113.0/24 443)
│   ├─ FAR ID: 2
│   └─ QER ID: 10, 1           ← SDF用QER と Session-AMBR用QER
└─ Create QER
    ├─ QER ID: 10
    ├─ Gate Status: UL OPEN / DL OPEN
    ├─ MBR: DL 10 Mbps
    └─ QFI: (default QoS Flow と同じ)

見る順番¶

flowchart LR
    A["① N7
Create / UpdateNotify
PCC Rule と qosDecs"] --> B["② N4
PDR の SDF Filter・Precedence
QER の MBR・Gate・QFI"]
    B --> C["③ N2
QFI と
QoS Flow Level QoS Parameters"]
    C --> D["④ N1
QoS Rules・
QoS Flow Descriptions"]
    D --> E["⑤ N3
GTP-U の QFI"]

比較表を作る¶

PCFは QFIを知らない（QFIを割り当てるのはSMF）ことに注意してください。N7とN4を相関させる第一の鍵は SDF（Packet Filter） です。Precedence の値は SMF が変換し得る（N1 の QoS rule precedence は1オクテット等。変換方法は実装依存）ため、値の一致ではなく 順序関係 で比べます。

Trouble Shooting¶

① Policy が来ない（期待したQoSにならない）¶

UPFを見る前に、上流から順に確認します。

① PCF Selection は成功した？（NRF Discovery、SMFのPCF設定）
② Npcf_SMPolicyControl_Create は 201 Created？（4xx / 5xx ではない？）
③ SmPolicyDecision に期待した PCC Rule / Session Rule が入っている？
④ PCC Rule が Predefined（Rule ID だけ）なら、SMF（Activate Predefined Rules を使う構成では UPF も）に同名ルールが設定されている？
⑤ SMF は PCC Rule を受け入れた？（SMF ログ、Update での失敗報告）
⑥ N4 / N2 / N1 へ正しく展開された？

② PCFは正しいのに UPF が違う¶

N7 の SmPolicyDecision と N4 の Create / Update QER・PDR を SDF をキーに 並べ、Precedence は順序関係で比べます。差があれば、原因は SMF の翻訳（binding・単位変換・ルール統合） か、UPFが Request を受理していない（PFCP Cause）かのどちらかです。

③ UPF は正しいが RAN だけ違う¶

N2 の PDU Session Resource Setup / Modify Request Transfer 内の QoS Flow Setup Request List / QoS Flow Add or Modify Request List、その中の QFI と QoS Flow Level QoS Parameters を確認します（TS 38.413 §9.3.4.1 / §9.3.4.3、要確認）。N2 には SDF 情報が無いため、「UPFでは SDF ごとに違う扱いなのに gNB では同じ QoS Flow」は、パターンAの binding では 正常 です。

3GPP仕様とVendor実装の境界¶

「PCFから受けた Policy を SMF のどの Pod / DB にキャッシュするか」は3GPPの規定外です。

EPC（4G）との比較¶

PCC Rule という考え方は TS 23.203 §6.3（要確認）から継承されています。ただし PCRF = PCF、PGW = SMF という単純な1対1置換で考えると誤解します。4G の PCEF は PGW 内で「受け取って実施」まで担いましたが、5G では SMF が翻訳し、UPF・gNB・UE がそれぞれ実施する 構造に分かれています。Gx の Bearer binding は TS 23.203 §6.1.1.4（要確認）です。

3GPP Specification¶

Summary¶

• SM Policy Association は PDU Session ごとの SMF⇔PCF の関係。Create で確立、Update（SMF起点）/ UpdateNotify（PCF起点）で変更、Delete で終了
• PCFは SMFからの入力（DNN・S-NSSAI・RAT・位置・加入QoS）、UDRの Policy Data、AF要求、CHF の状態 を材料に判断する
• 出力は Session Rule（Session-AMBR・default QoS）、PCC Rule（SDF template・Precedence・QoS・Gate・Charging）、PCRT
• PCFは UE・gNB・UPF を直接設定しない。SMF が QoS Flow binding と QFI 割当を行い、QoS Rule（N1）/ QoS Flow Level QoS Parameters（N2）/ PDR・QER・URR（N4） に翻訳する
• gNB は SDF を知らない。N7 と N4 は SDF（Precedence は順序関係）で、N4 と N2 / N1 は QFI で相関させる
• 確立後の Policy 変更は PCF-initiated Modification（§4.16.5.2）→ Network requested PDU Session Modification（§4.3.3.2）。binding 次第で N4 だけ、または N4 + N2 + N1 が更新される

理解度チェック¶

Next Step¶

• N7 を HTTP/2・JSON・ProblemDetails のレベルで解析する → N7 SBI解析
• AF が Policy に影響を与える仕組み → AF / N5 / Application Session / NEF / N33
• AF が担当 PCF を見つける仕組み → BSF / PCF Binding
• SMF が翻訳した結果の UPF 側 → PFCP と PDR / FAR / QER / URR / PDR / PDI / SDF Filter / Precedence
• Policy 変更を反映する手続き → PDU Session Modification / Release
• 全体像の復習 → Policy / PCF / N7 / QoS / Charging