N40 — SMF ⇔ CHF（統合課金 / Converged Charging）¶

難易度: 中級／想定学習時間: 15分／接続点: SMF ⇔ CHF ／ Protocol: SBI (HTTP/2 over TLS) ／関連Interface: N4, N7, N11

学習目標¶

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

N40が SMFがCHFへ課金を要求するSBI（Service Based Interface） であることを説明できる。
CHFの Converged Charging が、オンライン課金（与信/クォータ制御）とオフライン課金（課金レコード生成）を統合したものであることを説明できる。
N40の実体が、CHFの提供するサービス Nchf_ConvergedCharging（TS 32.290） であることを説明できる。
SMFが N4 の使用量計測（URR/Usage Report）を基に、CHFで課金セッションを管理する流れを説明できる。
4G(EPC)の OCS（Gy/Ro）＋ OFCS（Gz/Rf） が5Gで CHF/N40に統合された対応関係を説明できる。

前提知識¶

先に以下を理解しておくとスムーズです。

SBA / SBI と HTTP/2・TLS の位置づけ → Protocol辞典
N40の両端のNF → SMF / CHF
UPFの使用量計測（URR/Usage Report）とSMFの役割 → N4
PDUセッションのライフサイクル → PDU Session
Interfaceと参照点の考え方 → Interface辞典

Why — なぜ必要なのか¶

事業者にとって「使った分だけ課金する」ことは事業の根幹です。SMFはPDUセッションを制御しますが、そのセッションで加入者がどれだけデータを流したかを料金に結びつけるには、課金を専門に扱う機能へ「これだけ使った」と報告し、必要なら「まだ使ってよいか（残高はあるか）」を確認する道が要ります。

そこで、課金の元締めである CHF（Charging Function）に対し、SMFが課金を要求する道が必要になります。これがN40です。SMFはN40でCHFに課金セッションを開き、利用量を報告し、プリペイド（オンライン）ならCHFに残高を確認してクォータ（使ってよい上限）を受け取ります。N40が無ければ、SMFはデータ利用量を料金へ反映できず、従量課金もプリペイドの与信制御も成り立ちません。

例え話: N40は、従量課金メーターと料金センターを結ぶ報告回線です。土管（UPF）を流れたデータ量をSMFが集計し、料金センター（CHF）へ「これだけ使った」と報告します。プリペイド（オンライン）なら「あといくら使える?」を先に確認し、ポストペイド（オフライン）なら明細（課金レコード）を記録してもらいます。

Overview — 概要¶

N40は SMF ⇔ CHF を結ぶ参照点で、SBI（Service Based Interface） です。SBIとはNF同士がWeb API（HTTP）でサービスを呼び合う仕組みで、共通の転送として HTTP/2 + JSON（RESTful）over TLS を用います。

N40の実体は、CHFが提供するサービス Nchf_ConvergedCharging（TS 32.290） です。「Converged（統合）」の名のとおり、このサービスは次の2つを1つの枠組みに統合しています。

オンライン課金: 通信を許す前に残高/与信を確認し、使ってよい量（クォータ）を割り当てる。プリペイドや与信制御に対応。
オフライン課金: 通信後に利用実績を課金レコード（CDR）として生成・記録する。ポストペイド（事後精算）に対応。

SMFは、N4 経由でUPFに計測させた使用量（URR: Usage Reporting Rule に基づくUsage Report）を基に、N40でCHFの課金セッションを開始・更新・解放します。

参照点N40とサービスNchf_ConvergedChargingは同じものの2つの見方

3GPPのアーキテクチャ図では 参照点として N40（SMF⇔CHF） が示されますが、SBA（サービス化）ではこれが実体として CHFのサービス Nchf_ConvergedCharging として実装されます。つまり「N40」と「Nchf_ConvergedCharging」は、同じSMF⇔CHF間の課金連携を、参照点の視点／サービスの視点で見たものです。どちらも指しているものは同一で、呼び方（視点）が違うだけ、と捉えてください（本サイトでN7=Npcf_SMPolicyControlを扱うのと同じ二重性 → N7）。

Basic Concept — 初心者向け説明¶

N40を、従量課金メーターと料金センターに例えます。

あなたのスマホがデータ通信をすると、その通信は土管（UPF）を流れます。UPFは「どれだけ流れたか」をメーターのように計測し、その結果をSMFへ報告します（N4 の Usage Report）。SMFはこの計測値を集計し、料金センターであるCHFへ「この客はこれだけ使った」と報告します。これがN40です。

料金プランには2種類あります。プリペイド（前払い）なら、通信を許す前に「あといくら使える?」を料金センターに確認し、使ってよい量（クォータ）を先にもらいます。クォータを使い切りそうになったら、また追加を要求します。これがオンライン課金です。一方ポストペイド（後払い）なら、使った実績を明細（課金レコード）として記録してもらい、後でまとめて精算します。これがオフライン課金です。5GではこのCHFが両方を1つにまとめて扱うので Converged（統合）Charging と呼びます。

この料金センターへの報告は、専用の電話回線ではなく、社内Webシステム（HTTP）でリクエストを投げて回答をもらうイメージです。これが SBI＝NF同士がWeb API（HTTP/2）で会話する仕組みで、要求も応答も人間に読みやすい JSON でやり取りされます。

Protocol / Transport¶

項目	内容
Protocol	HTTP/2 + JSON（RESTful）— SBI（Service Based Interface）の共通スタック
サービス	Nchf_ConvergedCharging（CHFが提供）— TS 32.290 / TS 32.291
SBI framework	TS 29.500 / TS 29.501 系（SBIの共通規約・OpenAPI定義）
下位Transport	TCP、TLS で保護（機密性・完全性・認証）— TS 33.501
ポート	SBIの待受ポートは実装依存（NRF登録のエンドポイントで解決）。特定番号は断定しない
特徴	専用L4プロトコルではなくWeb技術ベース。HTTPメソッド＋リソースURIで操作。RESTful

N40はSBI。専用L4プロトコルではない

N2は NGAP over SCTP、N4は PFCP over UDP という専用の下位プロトコルを持ちますが、N40にはそれらは当てはまりません。N40はSBIなので、他のSBI（N7/N8/N10/N11 等）と同じく HTTP/2 over TLS を共通の土台とします。したがってN40の解析にSCTP固有のフィルタやポート番号を流用してはいけません。

Architecture¶

N40がSMFとCHFを結び、SMFがそのインプットとして N4 でUPFから使用量報告を得る文脈を示します。

flowchart LR
  UPF["UPF (転送)"]
  SMF["SMF"]
  CHF["CHF (課金)"]

  UPF -. "N4 (Usage Report)" .- SMF
  SMF == "N40 (Nchf: ConvergedCharging)" ==> CHF

  classDef ctrl fill:#efe,stroke:#3a3,stroke-width:2px;
  class SMF,CHF ctrl;

図の読み方: 点線のN4でUPFがデータ利用量（Usage Report）をSMFへ報告し、SMFがそれを集計します。太い線(==>)のN40が、SMFからCHFへの課金要求（SBI/HTTP2、Nchf_ConvergedCharging）です。N4が「どれだけ使ったかの計測」、N40が「その利用量に基づく課金」という役割分担に注目してください。UPFはあくまで計測とデータ転送を担い、料金判断はCHFが行います。

利用Procedure¶

N40は PDU Session のライフサイクルの中で、SMFがCHFへ課金を要求する際に使われます（オンライン/オフラインの構成に応じて動作が異なります）。

課金セッション開始（Create）: PDUセッション確立時、SMFがN40でCHFに課金セッションを開始する。オンライン課金なら、この時点で初期クォータ（使ってよい量）をCHFから取得する。
使用量計測（N4）: SMFはUPFに URR（Usage Reporting Rule） を設定し、UPFがデータ利用量を計測する。UPFは N4 Usage Report で利用量をSMFへ報告する。
使用量報告 / クォータ再取得（Update）: SMFは受領した利用量をN40でCHFへ報告する。オンライン課金でクォータが枯渇しそうな場合、追加のクォータをCHFに要求する。
課金セッション終了（Release）: PDUセッション解放時、SMFは最終的な利用量を報告し、N40の課金セッションを終了する。

各オペレーションの正確なメソッド・リソースURI・呼び出しシーケンス・タイマ等の細部は要確認です。手順の全体像は PDU Session を、UPF計測の詳細は N4 を参照してください。

主なMessage¶

N40はSBIなので、メッセージはHTTPメソッド + リソース操作の形を取ります（NGAPのようなprocedureCodeではなくRESTful操作）。代表的なサービスオペレーションは次のとおりです。

サービスオペレーション	HTTP操作(概念例)	用途
Nchf_ConvergedCharging_Create	POST（リソース生成）	課金セッション開始、オンラインなら初期クォータ取得
Nchf_ConvergedCharging_Update	POST（更新オペレーション呼び出し）	使用量報告、クォータ再取得（追加要求）
Nchf_ConvergedCharging_Release	POST/DELETE（終了・削除）	課金セッション終了、最終利用量の確定

HTTP操作・オペレーション名の対応は概念整理です: 上表の「HTTP操作」およびオペレーション名は理解のための対応づけであり、各オペレーションの正確なメソッド・リソースURI・呼び出し方向はTS 32.290 / TS 32.291のOpenAPI定義に従います。厳密なメソッド割り当てやオペレーションの細目は要確認とします。各メッセージの詳細は Message辞典を参照してください。

Packet Analysis (Wireshark)¶

N40はSBIなので、キャプチャ上は HTTP/2 として観測されます（NGAP/SCTPのようなL4専用プロトコルは現れません）。

目的	Display Filter
HTTP/2メッセージを抽出	`http2`
ヘッダのパスで絞る（概念）	`http2.headers.path`（`:path` に `nchf-convergedcharging` を含む）
JSONボディを見る	`json`（復号後）

Decodeの見どころ:

N40は TLSで暗号化されます。中身（HTTP/2ヘッダやJSONボディ）を見るには復号鍵（TLSセッションキー等）が必要です。鍵が無ければ tls の暗号化ペイロードとしてしか見えません。
復号できれば、HTTP/2の ヘッダ（:method = POST等、:path に .../nchf-convergedcharging/... を含むリソースパス）でオペレーションを識別できます。
ボディは JSON（利用量、クォータ、課金データ等）で、人間に読みやすい構造で入っています。
N2のNGAP（バイナリ、SCTP上）と違い、N40はWeb的（HTTP/JSON）である点が観察の要です。SCTP固有のフィルタ（sctp.port 等）は使いません。

EPCとの比較¶

4Gでは: 課金は2つの系統に分かれていました。オンライン課金は OCS（Online Charging System） が担い、PGW等とは Gy（Diameter）/ Ro で連携（与信・クォータ制御）。オフライン課金は OFCS（Offline Charging System） が担い、SGW/PGW等とは Gz / Rf（Diameter） で連携（課金レコード生成）。オンラインとオフラインは別システム・別インターフェースでした。
5Gでは: OCSとOFCSの役割を CHF が 1つに統合（Converged Charging） し、SMFとの連携は N40（Nchf_ConvergedCharging） に SBI化されました。Diameterベースの複数IF（Gy/Ro + Gz/Rf）が、HTTP/2 + JSONの単一SBIに置き換わっています。

4G (EPC)	5G (5GC)
Gy/Ro（SGW/PGW ⇔ OCS, オンライン） + Gz/Rf（⇔ OFCS, オフライン）	N40（SMF ⇔ CHF, 統合）
Diameter（専用L4上）	SBI: HTTP/2 + JSON over TLS
—（課金系Spec）	TS 32.290（Nchf_ConvergedCharging）
OCS + OFCS（オンライン/オフライン別システム）	CHF（Converged Charging に統合）

統合がN40の要点: 4Gで別々だった OCS（Gy/Ro, オンライン）と OFCS（Gz/Rf, オフライン） が、5Gでは CHFに統合され、SMFとの連携がN40（単一SBI）に集約されました。これが「Converged（統合）Charging」の意味です。

3GPP Specification¶

3GPP TS 32.290 — Nchf_ConvergedCharging サービス（5G課金のサービス化）。個別章番号は要確認
3GPP TS 32.291 — 5Gシステム課金サービスの詳細（オペレーション・API）。個別章番号は要確認
3GPP TS 32.240 — 課金アーキテクチャと原則（Charging architecture）
3GPP TS 29.500 / TS 29.501 — SBI framework（技術規約 / 設計原則・OpenAPI）。個別章番号は要確認
3GPP TS 23.501 §6.2 — ネットワーク機能の記述。CHFは§6.2に独立節を持たず、課金機能の定義はTS 32.290等の課金系Specに置かれる点に注意
3GPP TS 33.501 — SBIのセキュリティ（TLS等）。個別章番号は要確認

注記（要確認）: N40の実体が Nchf_ConvergedCharging（TS 32.290/32.291）であること、Converged Chargingがオンライン+オフラインの統合であることは3GPPの一般的整理です。各サービスオペレーション（Create/Update/Release等）の正確な名称・メソッド・リソースURI・タイマは Release により差異があるため個別には要確認とします。なお、PCF連携の与信制御に関わる SpendingLimitControl は別サービス（Nchf_SpendingLimitControl）であり、N40の主役である ConvergedCharging とは区別されます。

Summary¶

N40は SMF ⇔ CHF を結ぶ参照点で、SBI（HTTP/2 + JSON over TLS） である。
実体はCHFの提供する Nchf_ConvergedCharging（TS 32.290）。Converged Charging＝オンライン課金（与信/クォータ制御）とオフライン課金（課金レコード生成）を統合したもの。
SMFは N4 のUPF使用量計測（URR/Usage Report）を基に、N40でCHFの課金セッションを開始・更新・解放する。
参照点N40 = サービスNchf_ConvergedCharging は同じSMF⇔CHF連携の2つの見方（本サイトでN7=Npcf_SMPolicyControlを扱うのと同じ二重性）。
4Gの OCS（Gy/Ro, オンライン）＋ OFCS（Gz/Rf, オフライン） に相当し、5Gでは CHFに統合・SBI化（N40）された。

Next Step¶

CHF — N40の相手側。Converged Chargingを提供する課金の中枢
SMF — N40を利用して課金を要求し、N4の使用量計測を集計するNF
N4 — 課金のインプットとなるUPF使用量計測（URR/Usage Report）
PDU Session — 課金セッションが紐づくPDUセッションのライフサイクル
Interface辞典 — N7/N11 ほか参照点・SBIの確認