N7 SBI解析 — URI / HTTP/2 / ProblemDetails を4層で切り分ける¶

学習目標¶

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

• N7上の Service Consumer（SMF）/ Service Producer（PCF） の関係と、HTTPのClient / Serverの向きを説明できる
• 3GPP APIの URI構造（{apiRoot}/{apiName}/{apiVersion}/{resource}）から、どのNF・どのServiceへのRequestかを読み取れる
• Npcf_SMPolicyControl の Create / Update / Delete が、どのMethod・URI・Status Codeになるかを説明できる
• HTTP/2 Stream ID でRequestとResponseを対応付け、HPACK と TLS による「見えない」原因を区別できる
• ProblemDetails の status / cause / invalidParams を読み、「N7 Failure」を 4層 + 前後の段階 に細分化して報告できる
• N7 → N4 → N2 を SUPI・PDU Session ID・時刻で相関させ、Policyがどこで変わったかを特定できる

前提知識¶

• PCF / SM Policy Association / PCC Rule — SM Policy Association と PCC Rule の中身
• N7 — N7がSBIであり、実体が Npcf_SMPolicyControl であること
• 補助: 5GC概要（SBA / SBI / NRF） / PCF / NRF / HTTP API辞典 / パケット解析のTips / PFCP と PDR / FAR / QER / URR

Why — 「N7 Failureです」では何も分からない¶

障害報告で「N7 Failure」とだけ書かれていても、原因の候補は大きく異なります。

• PCFの宛先が分からない（NRF Discovery の問題）
• TCP / TLS が張れない（Transport の問題）
• HTTP/2 の Stream がリセットされた（HTTP/2 の問題）
• PCFが 4xx を返した（3GPP API の問題）
• 201 Created は返ったが、5QI が期待と違う（Policy Logic の問題）

N7は N2（NGAP over SCTP）や N4（PFCP over UDP）のような専用プロトコルではなく、Web技術（TCP / TLS / HTTP/2 / JSON）を重ねたSBI です（N7）。層が多いぶん、どの層で失敗したかを言えないと、誰が直すべきかも決まりません。

例え話: N7は「現場担当（SMF）が規約部門（PCF）へ社内Webシステムで問い合わせる」ことに似ています。返事が来ないとき、原因は「社内ネットワークにつながらない」「システムがエラー画面を返した」「申請書の書式が違った」「回答は来たが内容が想定と違った」のどれかです。「問い合わせ失敗」とだけ言われても、情報システム部門・規約部門・申請者のどこへ相談すべきか分かりません。

What — Service Consumer と Service Producer¶

SMFがConsumer、PCFがProducer¶

SBAでは、サービスを提供するNFを NF Service Producer、利用するNFを NF Service Consumer と呼びます（TS 23.501 §7.1、要確認）。Npcf_SMPolicyControl では次の関係になります（TS 23.502 §5.2.5.4、要確認）。

通知（UpdateNotify）では向きが逆になる¶

PCFが自発的にPolicyを変える場合（例: AFからの要求、加入者データ変更）、PCFはSMFへ Npcf_SMPolicyControl_UpdateNotify を送ります。このときHTTP上は PCFがClient、SMFがServer です。宛先は、SMFがCreate時に渡した notificationUri（Callback URI）です。

flowchart LR
    SMF["SMF
Consumer"] -- "Create / Update / Delete
SMF = HTTP Client" --> PCF["PCF
Producer"]
    PCF -- "UpdateNotify / Terminate通知
PCF = HTTP Client" --> SMF

What — 3GPP API の URI 構造¶

{apiRoot}/{apiName}/{apiVersion}/{resource}¶

3GPPのSBI APIは、共通のResource URI構造を持ちます（TS 29.501 §4.4.1、要確認）。

{apiRoot}/{apiName}/{apiVersion}/{apiSpecificResourceUriPart}

例（概念）:
https://pcf1.example.net:443/npcf-smpolicycontrol/v1/sm-policies/abc123
└────────── apiRoot ────────┘└──── apiName ──────┘└v1┘└── resource ──────┘

Captureでは HTTP/2 の :authority（apiRoot の authority部分）と :path（apiPrefix があればそれを含み、apiName 以降）に分かれて見えます（RFC 9113 §8.3.1）。:path に npcf-smpolicycontrol が含まれていれば、PCFのSM Policy Control Serviceへの Request だと判断できます。

Npcf_SMPolicyControl の Resource と Operation¶

TS 29.512 では、SM Policy Association を sm-policies Collection 配下の個別Resource として表現し、Update / Delete は個別Resource配下の custom operation（POSTで呼ぶ動詞的なURI）として定義しています（TS 29.512 §5.3、枝番は要確認）。

Create は Location で smPolicyId を返す¶

SMF → PCF   POST /npcf-smpolicycontrol/v1/sm-policies
            Body: SmPolicyContextData（supi, pduSessionId, dnn, sliceInfo, notificationUri, ...）

PCF → SMF   201 Created
            location: https://pcf1.example.net/npcf-smpolicycontrol/v1/sm-policies/abc123
            Body: SmPolicyDecision（sessRules, pccRules, qosDecs, ...）

以後の Update / Delete の URI には smPolicyId（例: abc123）しか出てきません。SUPI や PDU Session ID は Body に毎回入るわけではないため、後続Transactionを加入者と結び付けるには、Create の Location ヘッダ を控えておくことが重要です。smPolicyId の形式はPCFが決める 実装依存 の値です。

What — Method と Status Code の意味¶

Method だけで Operation を決めつけない¶

Npcf_SMPolicyControl では Create / Update / Delete がすべて POST です。「POSTだからCreate」とは言えず、Method + :path + Body をセットで見ます。なお PATCH は他のSBI API（例: Nnrf_NFManagement の NF Profile 更新、TS 29.510 §5.2.2.3、要確認）では使われますが、Npcf_SMPolicyControl の主要Operationには現れません（要確認）。

Status Code の読み方¶

SBIで使うStatus Codeの一般規定は TS 29.500 §5.2.7 にあります（要確認）。

What — JSON Body の主要属性¶

属性名は TS 29.512 §5.6（Data Model、枝番は要確認）と、3GPPが公開する OpenAPI 定義（TS29512_Npcf_SMPolicyControl.yaml）で確認します。以下は主要属性の抜粋で、網羅ではありません。必須 / 任意の区別は Release により異なり得るため、本ページでは断定しません（要確認）。

SmPolicyContextData（Create Request: SMF → PCF）¶

SmPolicyDecision（Create / Update Response: PCF → SMF）¶

PCC Rule は refQosData で qosDecs 内の QoS Data を ID参照 します。Captureでは「PCC Rule に 5QI が直接書いてある」のではなく、参照先の QoS Data を引いて読む 点に注意してください。

How — Call Flow¶

PDU Session確立時の SM Policy Association¶

SMFは PDU Session Establishment の途中で、動的PCCを使う場合に SM Policy Association を確立します（TS 23.502 §4.3.2.2.1、§4.16.4）。

sequenceDiagram
    participant AMF
    participant SMF
    participant NRF
    participant PCF
    AMF->>SMF: Nsmf_PDUSession_CreateSMContext Request
    opt PCFの宛先が未知
        SMF->>NRF: Nnrf_NFDiscovery Request
target-nf-type=PCF
        NRF-->>SMF: 200 OK（PCFのNF Profile一覧）
    end
    Note over SMF,PCF: TCP / TLS / HTTP/2 Connection（既存なら再利用）
    SMF->>PCF: POST sm-policies
SmPolicyContextData
    PCF->>PCF: UDR等の加入者Policyと照合してPolicy決定
    PCF-->>SMF: 201 Created + Location
SmPolicyDecision
    Note over SMF: この後 N4 Session Establishment（SMF⇔UPF）が続くが図では省略
    Note over SMF: Policyを N1 QoS Rule / N2 QoS Profile / N4 QER へ展開
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer

Signal Flow 表¶

手続きとしての SM Policy Association の Establishment / Modification / Termination は TS 23.502 §4.16.4 / §4.16.5 / §4.16.6 で規定されています（枝番は要確認）。

PCFの選択とNRF¶

SMFがどのPCFを使うかは、AMFから渡されたPCF情報、NRF Discovery、ローカル設定などで決まります（TS 23.501 §6.3.7.1、要確認）。どれを優先するかは構成・実装依存です。NRF Discovery の結果に含まれる NF Profile（FQDN / IP Endpoint / apiPrefix / 対応API Version）から apiRoot が組み立てられるため、NRFに登録された情報が古い・誤っていると、PCFが正常でも404や接続失敗になります。

How — 4層で切り分ける¶

flowchart TD
    L0["⓪ 宛先の決定
NRF Discovery / PCF Selection"] --> L1["① IP / TCP / TLS
到達性・Handshake・証明書"]
    L1 --> L2["② HTTP/2
Connection Preface・SETTINGS・Stream・GOAWAY"]
    L2 --> L3["③ 3GPP API
Method・path・Status・ProblemDetails"]
    L3 --> L4["④ Policy Logic
SmPolicyContextData と SmPolicyDecision"]
    L4 --> L5["⑤ SMFによる展開
N1 QoS Rule・N2 QoS Profile・N4 QER"]

本章の主題は ①〜④ の4層ですが、実務では ⓪（NRF） と ⑤（SMFの展開） を前後に足すと漏れがなくなります。

Layer 1: IP / TCP / TLS¶

SBIのTLS利用は TS 33.501 で規定されますが、信頼できるドメイン内での運用条件（TLSを使うか、NDS/IP等で保護するか）は 運用ポリシー依存 です（要確認）。待受ポートも NRF 登録で解決され、固定値ではありません（N7）。

Layer 2: HTTP/2¶

HTTP/2 は1本のTCP Connection上で複数の Stream を多重化します（RFC 9113 §5）。

TCP Connection（SMF → PCF）
├─ Stream 1   POST sm-policies             （UE-A のCreate）
├─ Stream 3   POST sm-policies/aaa/update  （UE-B のUpdate）
├─ Stream 5   POST sm-policies             （UE-C のCreate）
└─ Stream 1 の Response が Stream 3 より後に来ることもある

HPACK — ヘッダが見えないのはネットワークのせいとは限らない¶

HTTP/2 のヘッダは HPACK で圧縮され、Encoder と Decoder は Connection の 方向ごとに独立した Dynamic Table を保持します（RFC 7541 §2.2 / §2.3.2）。Connection の途中からCaptureを始めると、それ以前に Dynamic Table へ登録されたヘッダを参照できず、Wireshark が :path や :status を正しく表示できないことがあります。

「ヘッダがUnknown / 復号エラー」= NFが壊れたヘッダを送った、とは限りません。 まず Capture が Connection の開始（Connection Preface と最初の SETTINGS）から取れているかを疑ってください。

TLS — 中身を見るには鍵が要る¶

TLSで保護されたN7は、鍵が無ければ tls の Application Data としてしか見えません。

• Wireshark で復号するには、NFまたはTLS終端点から TLSセッション鍵（Key Log ファイル） を取得して読み込ませる必要があります。TLS 1.3 や (EC)DHE では サーバの秘密鍵だけでは復号できません。
• 鍵を出力できるかどうか、どこでTLSを終端しているか（NF本体、Sidecar、LB 等）は 実装依存 です。
• TLSを使わない検証環境（平文HTTP/2）では、待受ポートが Wireshark の既定と違うと HTTP/2 と認識されないため、「Decode As」で HTTP2 を指定します（Wiresharkの操作、版依存）。

Layer 3: 3GPP API¶

HTTP/2 が正常なら、Npcf_SMPolicyControl として正しい Request / Response か を見ます。

ProblemDetails¶

SBIのError Responseは、Bodyに ProblemDetails を入れて返すのが基本です（TS 29.500 §5.2.7.1、要確認）。データ型は TS 29.571 §5.2.4.1（要確認）で定義され、IETFの Problem Details 形式に3GPP独自の属性を加えたものです。

ProblemDetails（主要属性）
├─ type / title / instance   ← IETF Problem Details 由来
├─ status                    ← HTTP Status Code と同じ値
├─ detail                    ← 人間向けの説明（実装依存の文言）
├─ cause                     ← 3GPPのApplication Error（機械判定に使う）
├─ invalidParams             ← どの属性が不正か（param / reason）
└─ supportedFeatures 等

cause の値は2系統あります。

detail の文言は実装依存です。判定には status と cause を、原因箇所の特定には invalidParams を使います。

403 と 404 の典型¶

OAuth 2.0 では、Token無効は 401、scope不足は 403 が典型です（RFC 6750 §3.1、SBIでの利用は TS 29.500 §6.7.3 / TS 33.501 §13.4.1、いずれも要確認）。

Layer 4: Policy Logic¶

APIが成功していれば、ようやく Policyの中身 を見ます。

flowchart TD
    W["5QI / Bit Rate が期待と違う"] --> Q1{"SmPolicyContextData の
DNN・S-NSSAI・RAT等は正しい?"}
    Q1 -- "No" --> S["SMF側の問題
Context生成・加入者データ"]
    Q1 -- "Yes" --> Q2{"SmPolicyDecision の
qosDecs・sessRules は期待どおり?"}
    Q2 -- "No" --> P["PCF側の問題
Policy設定・UDRのPolicy Data"]
    Q2 -- "Yes" --> E["SMFの展開以降を疑う
N1・N2・N4 と比較"]

Wrong Policy = PCF bug とは限りません。PCFは受け取った Context に対して判断するため、必ず Request と Response を対で 見ます。

また、SMFが受け取ったPCC Ruleを適用できなかった場合、SMFは Update の中で Rule Report（ruleReports、適用失敗の理由付き）としてPCFへ報告できます（TS 29.512 §4.2.4、属性名・値は要確認）。「PCFは正しく返したが、SMFが適用できなかった」はここに現れます。

「N7 Failure」を細分化する¶

報告では、少なくとも次のどれかまで特定します。

この粒度で報告するだけで、関係チーム間の切り分けが大きく速くなります。

Packet Analysis (Wireshark)¶

Display Filter¶

フィールド名はWiresharkの版で異なる場合があります（要確認）。Response側には :path が無いため、:path で絞ると Response が落ちる点にも注意します（Stream ID で拾い直す）。

Decode例（概念表現）¶

以下は表示構造の概念表現で、値はテスト用PLMN（001-01）の架空例です（要キャプチャ）。

Stream 21  HEADERS  (SMF → PCF)
 ├─ :method: POST
 ├─ :scheme: https
 ├─ :authority: pcf1.example.net
 ├─ :path: /npcf-smpolicycontrol/v1/sm-policies
 └─ content-type: application/json
Stream 21  DATA
 └─ JSON: SmPolicyContextData
     ├─ supi: imsi-001010000000001
     ├─ pduSessionId: 1
     ├─ dnn: internet
     ├─ sliceInfo: { sst: 1, sd: 010203 }
     ├─ pduSessionType: IPV4
     ├─ ratType: NR
     └─ notificationUri: https://smf1.example.net/cb/pdu-1

Stream 21  HEADERS  (PCF → SMF)
 ├─ :status: 201
 ├─ location: https://pcf1.example.net/npcf-smpolicycontrol/v1/sm-policies/abc123
 └─ content-type: application/json
Stream 21  DATA
 └─ JSON: SmPolicyDecision
     ├─ sessRules: { sr1: { authSessAmbr: { uplink: 100 Mbps, downlink: 200 Mbps },
     │                      authDefQos: { 5qi: 9, arp: { priorityLevel: 8, ... } } } }
     ├─ pccRules:  { pcc1: { flowInfos: [...], precedence: 100, refQosData: [ qos1 ] } }
     └─ qosDecs:   { qos1: { 5qi: 7, maxbrUl: 10 Mbps, maxbrDl: 10 Mbps } }

Error の例（概念表現）:

Stream 23  HEADERS  (PCF → SMF)
 ├─ :status: 400
 └─ content-type: application/problem+json
Stream 23  DATA
 └─ JSON: ProblemDetails
     ├─ status: 400
     ├─ cause: MANDATORY_IE_MISSING
     ├─ detail: (実装依存の文言)
     └─ invalidParams: [ { param: /sliceInfo, reason: ... } ]

見る順番¶

flowchart LR
    A["① Src / Dst
SMF→PCFか"] --> B["② tcp.stream と
Stream ID"]
    B --> C["③ :method
④ :path"]
    C --> D["⑤ :status"]
    D --> E["⑥ Request JSON
⑦ Response JSON"]
    E --> F["⑧ ProblemDetails
status・cause"]

その後、SUPI・PDU Session ID・DNN・S-NSSAI など利用できる相関キーで、他Interfaceと結び付けます。

N7 → N4 → N2 を相関させる¶

N4にはSUPIが通常現れないため、時刻 + UE IPアドレス + SMFログ で PFCP Session（F-SEID）を特定するのが実務的です。PFCP の User ID IE などで加入者情報を運べる場合もありますが、使うかどうかは構成依存です（TS 29.244 §8.2.101、要確認）。

N7の値と N4 / N2 の値が違えば、PCFより後ろ（SMFのPolicy処理） を重点的に疑えます。N4・N2 の読み方は PFCP と PDR / FAR / QER / URR と PDU Session Establishment 深掘り を参照してください。

Trouble Shooting¶

PCFがHTTP 500を返したときにSMFが何回・どの間隔でRetryするか、別PCFへ切り替えるかは 実装依存 です（代替PCFの選択や NF Set の考え方は NF Set / Binding Indication を参照）。

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

N7で問題が出たら、3GPPのAPI動作の問題か / Transport・基盤の問題か / Vendor実装の問題か を分けて考えます。

EPC（4G）との比較¶

Gx の Diameter メッセージ対応は概念的な対応付けです（手続きは TS 29.212 §4.5、メッセージ定義は §5.6、いずれも要確認）。最大の違いは、結果判定が「HTTP Status」と「3GPP cause」の2段になった ことと、宛先がNRFで動的に決まる ことです。

3GPP Specification¶

Summary¶

• N7の実体は Npcf_SMPolicyControl。SMF = Consumer（HTTP Client）、PCF = Producer（HTTP Server）。通知（UpdateNotify）では向きが逆になり、Connectionも別になる
• URIは {apiRoot}/npcf-smpolicycontrol/v1/sm-policies...。Create は POST → 201 + Location、Update / Delete は POST の custom operation（/update、/delete）
• 後続Transactionは smPolicyId でしか識別できないので、Create の Location を控える
• HTTP 2xx ≠ 正しいPolicy。Request（SmPolicyContextData）と Response（SmPolicyDecision）を対で見る
• 切り分けは ⓪ NRF → ① IP/TCP/TLS → ② HTTP/2 → ③ 3GPP API → ④ Policy Logic → ⑤ SMFの展開
• Request / Response は TCP Connection + Stream ID で対応付ける。ヘッダが見えないときは HPACK文脈 と TLS鍵 を疑う
• Errorは status と cause で判定し、invalidParams で箇所を特定する。403 / 404 は「PCF Down」ではない
• N7 → N4 → N2 を SUPI・PDU Session ID・時刻で相関させ、単位をそろえて 値を比較する

理解度チェック¶

Next Step¶

• AFがPCFへQoSを要求する流れ → AF / N5 / Application Session
• PCFが返すPolicyの中身 → PCF / SM Policy Association / PCC Rule / QoS Flow / QFI / 5QI / GFBR / MFBR / AMBR / ARP
• Policyが UPF / gNB へ届く先 → PFCP と PDR / FAR / QER / URR / PDU Session Establishment 深掘り
• PCFの選び方と冗長 → BSF / PCF Binding / NF Set / Binding Indication / SBI Communication Model
• 基礎の確認 → N7 / PCF / NRF / HTTP API辞典 / パケット解析のTips