PFCP と PDR / FAR / QER / URR — UPFはパケットをどう判定して転送するのか¶

学習目標¶

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

• PFCP が User Packet を運ぶプロトコルではなく、UPFの処理ルールを設定するControl Protocol であることを説明できる
• PDR → FAR / QER / URR の参照関係（PDRが「どのPacketか」、他が「どう扱うか」）を説明できる
• UL と DL で PDR が何を見てMatchするか（F-TEID / UE IP Address / SDF Filter）が違う理由を説明できる
• FAR の Apply Action（FORW / DROP / BUFF / NOCP） と、CM-IDLE UEへのPaging の関係を説明できる
• PFCP Capture で PDR → FAR ID → FAR をたどり、TEID不一致などを見つけられる
• SMF が gNB 向けに送る N2 SM Information と、UPF 向けに送る N4（PFCP）ルール の違いを説明できる

前提知識¶

• PDU Session Establishment 深掘り — SMFが PFCP Establishment → Modification でUPFを設定する流れ
• Paging / Service Request / CM-IDLE / CM-CONNECTED と Service Request — CM-IDLE UEへのDL Data到着からの手続き
• 補助: N4 / N3 / N6 / QoS / Charging

Why — UPFは「Internetへ送る箱」ではない¶

UPFは、受け取ったPacketごとに次を判断しています。

Packet が来た
   ↓ これはどのPDU Session・どのTrafficのPacket？   ← PDR
   ↓ 転送する？ 捨てる？ 溜める？ どこへ？          ← FAR
   ↓ どの帯域・QoSで扱う？                          ← QER
   ↓ どれだけ使った？                               ← URR
送り出す（N3 / N6 / N9）

この判断のルールを UPF に設定するのが SMF で、そのためのプロトコルが PFCP（Packet Forwarding Control Protocol） です（TS 29.244 Clause 4.1 / Clause 5.1、要確認）。

例え話: UPFは「仕分けセンター」です。PDRは荷札の読み取り条件、FARは配送先と「保管 / 廃棄」の指示、QERは配送トラックの速度制限、URRは取扱量の帳簿。仕分けのルールブックを書いて渡すのが SMF です。

What — PFCP の位置づけ¶

       Control Plane                       User Plane
SMF ════════ UPF                    gNB ════════ UPF ════════ DN
      N4 / PFCP                           N3 / GTP-U       N6
  （ルールを設定する）                 （UEのPacketそのもの）

• PFCP は N4（SMF ⇔ UPF） の Control Protocol です（TS 29.244 Clause 4.1 / Clause 5.1、要確認）。UEのUser Packetそのものは運びません。SMFバッファリング等でUPF⇔SMF間にUser Packetを転送する場合も、PFCPではなくN4上のGTP-Uトンネルが使われます（TS 29.244 Clause 5.3、TS 23.501 Clause 5.8.3、要確認）。
• UEのData は N3 では GTP-U（TS 29.281 Clause 5、要確認）で、N6 ではDNのプロトコルで運ばれます。
• PFCP は UDP 上で動作し（PFCP の登録ポートは UDP 8805。TS 29.244 Clause 4.2.2、要確認）、Node 単位の手続き（Association Setup / Heartbeat 等）と Session 単位の手続き（Session Establishment / Modification / Deletion / Report）があります（TS 29.244 Clause 6 / Clause 7、要確認）。
• Session 単位の手続きは、SMF と UPF の間に PFCP Association が確立済みであることが前提です（TS 29.244 Clause 6.2.6、要確認）。

N2 SM Information と N4（PFCP）を混同しない¶

SMF は1つの PDU Session のために、宛先の違う3種類の情報 を作ります。

SMF ──N1 SM 情報──► AMF ──NAS (N1)──► UE    … UE向け（PDU Session Establishment Accept 等）
SMF ──N2 SM 情報──► AMF ──NGAP (N2)─► gNB   … RAN向け（UPF の N3 F-TEID、QoS Flow 設定 等）
SMF ──N4 / PFCP─────────────────────► UPF   … UPF向け（PDR / FAR / QER / URR）
gNB ══N3 / GTP-U════════════════════► UPF   … UEのUser Packetそのもの

PFCP と N2 SM 情報は、F-TEID を受け渡す両輪 の関係です。UPF側の N3 F-TEID は SMF が割り当てる（Create PDR に記載）か、UPF が割り当てる（CH フラグ → Created PDR で返却）かのいずれかで、どちらも PFCP 上で確定し、N2 SM 情報で gNB へ渡ります。逆に gNB側の F-TEID は N2 SM 情報（Response Transfer）で SMF に戻り、PFCP Session Modification で UPF の FAR に入ります。

例え話: N2 SM 情報は「支店（gNB）宛ての手紙」、PFCP は「倉庫（UPF）宛ての作業指示書」です。どちらも本社（SMF）が書きますが、届け先も届け方も違います。

What — Packet Forwarding Model¶

TS 29.244 では、UPF内のPacket処理を次のモデルで定義しています（TS 29.244 Clause 5.2.1、要確認）。

flowchart LR
    P[Incoming Packet] --> PDR{"PDR lookup
(PDI と Precedence)"}
    PDR -- "FAR ID" --> FAR["FAR
Apply Action / Forwarding Parameters"]
    PDR -- "QER ID(s)" --> QER["QER
Gate / MBR / GBR / QFI"]
    PDR -- "URR ID(s)" --> URR["URR
Volume / Time / Event 計測"]
    FAR -- "BAR ID（任意）" --> BAR["BAR
Buffering"]
    FAR --> OUT[N3 / N6 / N9 / CP-function]

図: TS 29.244 の Packet Forwarding Model を簡略化した概念図（TS 29.244 Clause 5.2.1、要確認）。Incoming Packet → PDR lookup は処理の流れ、PDR から各ルールへの矢印は IDによる参照関係 を表します（処理の時間順ではありません）。BAR は FAR の BAR ID から参照され、FAR が BUFF のときに意味を持ちます。CP-function 宛ては、SMF でバッファリングする場合などに N4 上の GTP-U トンネルで SMF へ送るケースです。

ATSSS 用の MAR（Multi-Access Rule）など、Releaseで追加されたルールもあります（本章では扱いません）。各ルールの5GS上のパラメータは TS 23.501 Clause 5.8.2.11 にも整理されています（枝番は要確認）。

What — PDR（Packet Detection Rule）¶

PDR は、受信したPacketがどのPDU Session・どのTrafficに該当するか を判定するルールです。

PDR の主な中身¶

Create PDR
├─ PDR ID
├─ Precedence                     ← 複数Matchしたときの優先度
├─ PDI（Packet Detection Information）
│   ├─ Source Interface           ← Access（N3側）/ Core（N6側）等
│   ├─ Local F-TEID               ← ULでは主にこれでMatch
│   ├─ Network Instance
│   ├─ UE IP Address              ← DLでは主にこれでMatch
│   ├─ SDF Filter                 ← 5-tupleなど
│   └─ QFI
├─ Outer Header Removal（任意）   ← ULでGTP-U/UDP/IPを外す
├─ FAR ID
├─ URR ID（0個以上）
└─ QER ID（0個以上）

（IE構成は TS 29.244 Clause 7.5.2.2、要確認）

Local F-TEID は誰が決めるか — CHOOSE（CH）フラグ¶

UL の Match に使う Local F-TEID（UPF側の N3 IP + TEID）は、SMF が割り当てる方式 と UPF が割り当てる方式 があります（TS 23.501 Clause 5.8.2.3、要確認）。

• UPF に割り当てさせる場合、SMF は Create PDR の PDI 内 F-TEID IE に CHOOSE（CH）フラグ を立て、具体的な TEID / IP を入れずに送ります（TS 29.244 Clause 8.2.3、要確認）。
• UPF は割り当てた値を、Session Establishment Response の Created PDR IE で返します（TS 29.244 Clause 7.5.3.2、要確認）。SMF はこの値を N2 SM 情報（UL NG-U UP TNL Information）に入れて gNB へ渡します。
• 複数の PDR に 同じ F-TEID を割り当てさせたいときは、CHOOSE ID（CHID） で同じ値を指定します。UPF は同じ Choose ID の PDR に同じ F-TEID を割り当てます（TS 29.244 Clause 8.2.3、要確認）。

どちらの方式を使うかは SMF / UPF の能力と設定によります（UPF側の対応は PFCP Association 時の UP Function Features の FTUP で示されます。TS 29.244 Clause 8.2.25、要確認）。

UL と DL で Match の手がかりが違う¶

UL:  gNB ──GTP-U (TEID=0x00000101)──► UPF
         PDR #1: Source=Access, F-TEID=198.51.100.20/0x00000101 → MATCH
         Outer Header Removal: GTP-U/UDP/IPv4 → 中身のIPをN6へ

DL:  DN ──IP (dst=10.45.0.3)──► UPF
         PDR #2: Source=Core, UE IP=10.45.0.3 (destination) → MATCH
         FAR → Outer Header Creation で GTP-U に包んで gNB へ

Precedence — 複数のPDRがMatchしたら¶

同じPacketに複数のPDRがMatchし得るため、PDRには Precedence があります。UPFは、Matchしたうち Precedence値が最も小さい（＝優先度が最も高い）PDR を選びます（TS 29.244 Clause 5.2.1 / Clause 8.2.11、要確認）。

DL Packet (dst=10.45.0.3, dst port=5060)
 ├─ PDR #2  Precedence=255  UE IP=10.45.0.3                  → match
 └─ PDR #3  Precedence=100  UE IP=10.45.0.3 + SDF(port 5060) → match
        ↓ 小さい方が優先
     PDR #3 を適用（例: IMS用の別QoS Flowへ）

複数QoS Flowや Traffic Steering では、このPDR選択が意図通りかどうかが重要になります。Precedence の値の付け方は仕様で一律には決まっておらず、SMF実装・運用依存 です。設計上の注意点は 次章 を参照してください。

What — FAR（Forwarding Action Rule）¶

PDRでMatchしたPacketを どうするか を決めるのが FAR です。中心は Apply Action IE です（TS 29.244 Clause 8.2.26、要確認）。

Apply Action は ビットフラグの集合 で、組み合わせて設定します（例: BUFF + NOCP、FORW + DUPL）。ただし DROP / FORW / BUFF（Release により IPMA / IPMD / MBSU 等を含む）は、そのうち 1つだけ を立てる規定です（TS 29.244 Clause 8.2.26、要確認）。

DUPL の仕様上の想定用途の例は Lawful Interception です（TS 29.244 Clause 7.5.2.3、要確認）。5GC における LI の構成は本章の範囲外で、複製先・方式の詳細は実装依存の部分を含みます。

Release によっては、ほかのフラグ（IP multicast 関連、DL Data通知の制御 等）も追加されています（要確認）。

Forwarding Parameters¶

Create FAR
├─ FAR ID
├─ Apply Action = FORW
└─ Forwarding Parameters
    ├─ Destination Interface      ← Access（N3へ）/ Core（N6へ）等
    ├─ Network Instance
    └─ Outer Header Creation（DLで使う）
        ├─ Description = GTP-U/UDP/IPv4
        ├─ TEID          = 0x12345678   ← gNB側 TEID
        └─ IPv4 Address  = 192.0.2.10   ← gNB側 N3 IP

Outer Header Creation — DLでGTP-Uに包む¶

DN から来たDL Packetは素のIPです。gNBへ送るには、UPFが GTP-U で包む（Encapsulation） 必要があり、そのための宛先 IP と TEID が FAR の Outer Header Creation です（TS 29.244 Clause 8.2.56、要確認）。

Inner:  IP(dst=UE IP) | payload
  ↓ Outer Header Creation
Outer:  IP(dst=gNB N3 IP) | UDP(2152) | GTP-U(TEID=gNB側) | IP(dst=UE IP) | payload

GTP-U のUDPポート 2152 は TS 29.281 Clause 4.4.2 によります（要確認）。

この値は gNB が NGAP PDU Session Resource Setup Response で返したものです（Response Transfer 内の DL QoS Flow per TNL Information。TS 38.413 Clause 8.2.1 / Clause 9.3.4.2、要確認）。前章で、SMF が PFCP Session Modification で gNB の F-TEID を UPF へ反映したのは、この Outer Header Creation を埋めるためです。

なお、gNB が受信するDL GTP-U には、QFI を運ぶ PDU Session Container 拡張ヘッダが付きます（TS 38.415 Clause 5.5.2.1、TS 29.281 Clause 5.2.2.7、要確認）。

How — BUFF / NOCP と Paging のつながり¶

AN Release（TS 23.502 Clause 4.2.6、要確認）やUP接続の非活性化で N3 トンネルが解放されると、UPFにはDLの送り先（gNB F-TEID）がありません。このときSMFは、DL FARを BUFF + NOCP にしておけます（UPFでバッファリングする場合。TS 23.501 Clause 5.8.3、要確認）。

sequenceDiagram
    participant DN
    participant UPF
    participant SMF
    participant AMF
    participant gNB
    participant UE
    DN->>UPF: DL Packet
    Note over UPF: DL PDR match → FAR: BUFF + NOCP
    UPF->>SMF: PFCP Session Report Request（Downlink Data Report）
    SMF-->>UPF: PFCP Session Report Response
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer
    AMF->>gNB: NGAP Paging
    gNB->>UE: Paging
    UE->>AMF: Service Request
    Note over AMF,SMF: N2 SM 情報で新しい gNB F-TEID が SMF へ
    SMF->>UPF: PFCP Session Modification（FAR: FORW + 新 Outer Header Creation）
    UPF->>gNB: バッファしていたDL Packetを送出

図: Network Triggered Service Request（TS 23.502 Clause 4.2.3.3）のうち、PFCP に関わる部分を抜き出した簡略図（UPF でバッファリングする場合）。N1N2MessageTransfer の応答、AMF の Paging 判定、Service Request 中の AMF ⇔ SMF 間の Nsmf_PDUSession_UpdateSMContext、gNB との PDU Session Resource Setup 等は省略しています。SMF でバッファリングする場合は、DL FAR の転送先が CP-function になり、DL Packet 自体が N4 の GTP-U で SMF へ送られます（TS 23.501 Clause 5.8.3、要確認）。

• バッファリングは UPFで行う方式 と SMFで行う方式 があり、どちらを使うかはSMFが決めます（TS 23.501 Clause 5.8.3、要確認）。
• DL Data 到着から Paging までの全体手順は TS 23.502 Clause 4.2.3.3（Network Triggered Service Request）です。
• Service Request（UP接続の再活性化）や Handover では gNB から新しい DL F-TEID が通知されるため（TS 23.502 Clause 4.2.3.2 / Clause 4.9.1、要確認）、SMFは PFCP Session Modification で FAR の Outer Header Creation を更新します。

つまり、Paging の出発点には、UPF内の DL PDR → FAR（BUFF + NOCP） が存在しています。

What — QER（QoS Enforcement Rule）¶

QER は、Matchしたトラフィックに QoSを適用 するルールです（TS 29.244 Clause 5.2 配下の QER handling / Clause 7.5.2.5、枝番は要確認）。

Create QER
├─ QER ID
├─ Gate Status        ← UL / DL それぞれ OPEN / CLOSED
├─ MBR                ← Maximum Bit Rate（UL / DL）
├─ GBR（任意）        ← Guaranteed Bit Rate
├─ QFI（任意）        ← DLでGTP-Uヘッダに付けるQFI
└─ RQI（任意）        ← Reflective QoS

• 1つのPDRから複数QERを参照でき、たとえば QoS Flow単位のMBR と PDU Session単位のSession-AMBR を別々のQERで表現できます（5GSでの対応は TS 23.501 Clause 5.8.2.11、要確認）。
• Gate Status = CLOSED だと、FAR が FORW でもそのトラフィックは通りません（TS 29.244 Clause 8.2.7 Gate Status、要確認）。「FORWなのに流れない」ときはQERも疑います。
• 具体的なRate制御方式（Token Bucket等）やHardwareへの実装は Vendor依存 です。

QoS Flow / 5QI / AMBR の概念は QoS を参照してください。

What — URR（Usage Reporting Rule）¶

URR は、トラフィックの 使用量を計測し、条件を満たしたらSMFへ報告 するルールです（TS 29.244 Clause 5.2.2 / Clause 7.5.2.4、要確認）。

Create URR
├─ URR ID
├─ Measurement Method   ← VOLUM（バイト数）/ DURAT（時間）/ EVENT
├─ Reporting Triggers   ← 閾値到達、Quota消費、周期 等
├─ Volume Threshold / Volume Quota（任意）
└─ Time Threshold / Time Quota（任意）

Usage Report は、PFCP Session Report Request（UPF起点）、Session Modification Response、Session Deletion Response などでSMFへ返ります（TS 29.244 Clause 7.5.8 / Clause 7.5.5 / Clause 7.5.7、要確認）。

UE Traffic → UPF (URR: 計測) ──Usage Report──► SMF ──Nchf──► CHF

How — PFCP の Session 手続き¶

SMF                                UPF
 │ Session Establishment Request    │
 │  Create PDR #1 (UL)  → FAR #1    │
 │  Create PDR #2 (DL)  → FAR #2    │
 │  Create FAR #1: FORW → Core      │
 │  Create FAR #2: (gNB F-TEID未定) │
 │  Create QER / URR                │
 │─────────────────────────────────►│
 │◄─────────────────────────────────│ Response: Created PDR (Local F-TEID)
 │                                  │
 │ Session Modification Request     │
 │  Update FAR #2: FORW +           │
 │    Outer Header Creation (gNB)   │
 │─────────────────────────────────►│

図: 前章の PDU Session Establishment（TS 23.502 Clause 4.3.2.2.1）で PFCP が送られる典型的な順序の概念図。Response の Created PDR に Local F-TEID が入るのは、UPF が F-TEID を割り当てる（CH フラグ）場合です。ID の値・ルールの数は SMF 実装依存です。

Establishment 時点の DL FAR の Apply Action をどう設定しておくか（例: gNB F-TEID が来るまで BUFF / DROP）は SMF実装依存 です。

PDU Session 確立時に、SMFがUPFのPacket Processing Pipelineをプログラムする と考えると理解しやすくなります。

Session Modification が必要になる典型場面¶

PDU Session の途中で gNB 側の Tunnel が変われば、UPF の DL FAR も追随しなければなりません。

UE が gNB-A 配下  : DL FAR  Outer Header Creation = gNB-A IP / TEID=0xAAAA0001
        ↓ Handover、または CM-IDLE → Service Request で gNB-B へ
UE が gNB-B 配下  : DL FAR  Outer Header Creation = gNB-B IP / TEID=0xBBBB0001
        ↑ SMF が PFCP Session Modification（Update FAR）で書き換える

TEID・IP の値は架空例です。Handover 全体の流れは Handover を参照してください。

Packet Analysis (Wireshark)¶

Display Filter¶

フィールド名はWiresharkの版で異なるため断定しません（要確認）。

Decode例（概念表現）— PDR → FAR ID → FAR をたどる¶

以下は表示構造の概念表現です（表示ラベルはWiresharkの版で異なります）。

PFCP Session Establishment Request
├─ Create PDR
│   ├─ PDR ID: 2
│   ├─ Precedence: 255
│   ├─ PDI
│   │   ├─ Source Interface: Core
│   │   └─ UE IP Address: 10.45.0.3 (destination)
│   ├─ FAR ID: 2          ─────┐
│   └─ QER ID: 1               │
└─ Create FAR                  │
    ├─ FAR ID: 2         ◄─────┘
    └─ Apply Action: ...

PFCP Session Establishment Response
├─ Cause: Request accepted
└─ Created PDR
    ├─ PDR ID: 1
    └─ Local F-TEID: TEID 0x00000101, 198.51.100.20   ← UL PDR に UPF が割り当てた値（CH の場合）

PFCP Session Modification Request
└─ Update FAR
    ├─ FAR ID: 2
    ├─ Apply Action: FORW
    └─ Update Forwarding Parameters
        ├─ Destination Interface: Access
        └─ Outer Header Creation: GTP-U/UDP/IPv4, TEID 0x12345678, 192.0.2.10

（値は架空例です。実キャプチャではありません）

Wireshark上でも、PDR の FAR ID と FAR の FAR ID をリンクさせて読む のが基本です。PFCP Response の Cause（例: Request accepted）も必ず確認します（TS 29.244 Clause 8.2.1、要確認）。

見る順番¶

flowchart LR
    A["① PFCP Association
Setup / Heartbeat"] --> B["② Establishment Request
Create PDR / FAR / QER / URR"]
    B --> C["③ Establishment Response
Cause / Created PDR"]
    C --> D["④ NGAP Setup Response
gNB の DL F-TEID"]
    D --> E["⑤ Modification Request
Update FAR の Outer Header Creation"]
    E --> F["⑥ GTP-U
実際の TEID / IP"]

①が無ければ Session 手続きは成立しません。③の Local F-TEID と⑥の UL GTP-U の TEID、④の gNB F-TEID と⑤・⑥の DL GTP-U の TEID が、それぞれ一致しているかを突き合わせます。

Trouble Shooting — PFCPは成功したのにPingが通らない¶

「PFCP Session Establishment / Modification が Request accepted」だけでは不十分です。次を順に確認します。

① UL PDR は存在する？（Source Interface = Access）
② UL PDR の Local F-TEID は、gNBが実際に使っている TEID と一致する？
③ UL PDR → FAR の参照（FAR ID）は正しい？
④ UL FAR は FORW？ Destination Interface = Core？
⑤ DL PDR は UE IP Address に Match する？（UE IPの割当値と一致？）
⑥ DL FAR は FORW？（BUFF / DROP のまま残っていない？）
⑦ DL FAR の Outer Header Creation の gNB IP は正しい？
⑧ DL FAR の TEID は gNB が通知した値と一致する？
⑨ QER の Gate Status が CLOSED / MBR が極端に低い、になっていない？
⑩ N3 / N6 の IP Routing は正常？

TEID mismatch を見つける¶

NGAP PDU Session Resource Setup Response   → gNB: DL TEID = 0x12345678
PFCP Session Modification (Update FAR)      → UPF: DL TEID = 0x87654321
                                               → mismatch

NGAP で gNB が通知した Tunnel 情報 と PFCP の FAR / Outer Header Creation を並べて比較するのが最も効率的です。

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

たとえば「FAR を Linux kernel、DPDK、SmartNIC、ASIC のどこにプログラムするか」は3GPPでは規定しません。

EPC（4G）との比較¶

PFCP は Rel-14 の CUPS（TS 23.214 Clause 4 / TS 29.244 Clause 4.1、要確認）で導入され、5GC の N4 でもそのまま使われています。

3GPP Specification¶

Summary¶

• PFCP は N4 で SMF が UPF に Packet処理ルールを設定する Control Protocol。User Packet は N3 の GTP-U で流れる
• PDR = どのPacketか、FAR = どうする・どこへ、QER = QoS、URR = 使用量計測。PDR が FAR / QER / URR を ID で参照する
• UL は主に Local F-TEID、DL は主に UE IP Address で PDR に Match。複数Matchは Precedence が小さい方 が優先
• FAR の Outer Header Creation が DL の宛先（gNB IP / TEID）。だから SMF は gNB F-TEID を PFCP Modification で反映する
• CM-IDLE では DL FAR を BUFF + NOCP にでき、Session Report → Paging につながる
• PFCP が Request accepted でも User Plane が通るとは限らない。NGAP の F-TEID と PFCP の値を突き合わせる
• N2 SM 情報（gNB向け）と PFCP（UPF向け）は別物。F-TEID は両者を行き来して UL / DL の Tunnel が完成する
• Apply Action はフラグの組み合わせ（BUFF + NOCP、FORW + DUPL 等）。UPF に F-TEID を割り当てさせるときは CH フラグ を使い、結果は Created PDR で返る

これまでの章とのつながり¶

CM-IDLE / Paging       DL Packet 到着 → DL FAR (BUFF + NOCP) → Session Report → Paging
Service Request        新しい gNB F-TEID → PFCP Modification で DL FAR を FORW へ
PDU Session 確立       PFCP Establishment で PDR / FAR / QER / URR を作成
本章                   UPF が PDR → FAR / QER / URR に従って Packet を処理
次章                   PDR が「何を見て」Match するか（PDI / F-TEID / SDF Filter / Precedence）

理解度チェック¶

Next Step¶

• 次章: PDR が何を見て Match するか（PDI / F-TEID / SDF Filter / Precedence の詳細）→ PDR / PDI / F-TEID / SDF Filter / Precedence
• PFCP がいつ送られるか → PDU Session Establishment 深掘り
• DL Data からの Paging / Service Request → CM-IDLE / CM-CONNECTED と Service Request / Paging / Service Request
• QER の QFI と QoS Flow → QoS Flow / QFI / 5QI / QoS
• UPF / SMF の全体像 → UPF / SMF
• 使用量の行き先 → Charging
• メッセージ・IE → PFCP辞典 / N4