Skip to content

N40 — SMF ⇔ CHF (Converged Charging)

Difficulty: Intermediate / Estimated study time: 15 min / Connection points: SMF ⇔ CHF / Protocol: SBI (HTTP/2 over TLS) / Related interfaces: N4, N7, N11

Learning objectives

After reading this page, you will be able to:

  • Explain that N40 is the SBI (Service Based Interface) over which the SMF requests charging to the CHF.
  • Explain that the CHF's Converged Charging is the integration of online charging (credit/quota control) and offline charging (charging-record generation).
  • Explain that the actual form of N40 is the service Nchf_ConvergedCharging (TS 32.290) provided by the CHF.
  • Explain the flow by which the SMF manages charging sessions at the CHF based on the usage measurement (URR/Usage Report) of N4.
  • Explain the correspondence by which 4G (EPC) OCS (Gy/Ro) + OFCS (Gz/Rf) were integrated into the CHF/N40 in 5G.

Prerequisites

Understanding the following first will make this smoother:

  • The positioning of SBA / SBI and HTTP/2・TLS → Protocol dictionary
  • The NFs at both ends of N40 → SMF / CHF
  • UPF usage measurement (URR/Usage Report) and the SMF's role → N4
  • The PDU-session lifecycle → PDU Session
  • The concept of interfaces and reference points → Interface dictionary

Why — Why it is needed

For an operator, "charging exactly for what is used" is the foundation of the business. The SMF controls PDU sessions, but to link how much data a subscriber sent in that session to a fee, it needs a path to report "this much was used" to a function specialized in charging and, if necessary, to confirm "may I still use it (is there a balance)?"

Therefore, a path by which the SMF requests charging to the CHF (Charging Function), the master of charging, becomes necessary. This is N40. The SMF opens a charging session at the CHF over N40, reports usage, and — for prepaid (online) — confirms the balance with the CHF and receives a quota (the upper limit that may be used). Without N40, the SMF could not reflect data usage into fees, and neither usage-based charging nor prepaid credit control would hold.

Analogy: N40 is the reporting line connecting the usage-based meter and the billing center. The SMF tallies the volume of data that flowed through the pipe (UPF) and reports "this much was used" to the billing center (CHF). For prepaid (online), it first confirms "how much can still be used?"; for postpaid (offline), it has an itemized record (charging record) kept.

Overview

N40 is the reference point connecting SMF ⇔ CHF, and it is an SBI (Service Based Interface). SBI is a mechanism in which NFs invoke services from each other via web APIs (HTTP), using HTTP/2 + JSON (RESTful) over TLS as the common transport.

The actual form of N40 is the service Nchf_ConvergedCharging (TS 32.290) provided by the CHF. As the name "Converged" indicates, this service integrates the following two into a single framework:

  • Online charging: Confirm balance/credit before permitting communication, and allocate the amount that may be used (quota). Supports prepaid and credit control.
  • Offline charging: After communication, generate and record actual usage as charging records (CDRs). Supports postpaid (settlement after the fact).

Based on the usage measured by the UPF via N4 (Usage Report based on the URR: Usage Reporting Rule), the SMF starts, updates, and releases the CHF's charging session over N40.

The reference point N40 and the service Nchf_ConvergedCharging are two views of the same thing

In the 3GPP architecture diagrams, N40 (SMF⇔CHF) is shown as a reference point, but in the SBA (service-based) view this is implemented in practice as the CHF's service Nchf_ConvergedCharging. In other words, "N40" and "Nchf_ConvergedCharging" are the same SMF⇔CHF charging interworking seen from the reference-point view and the service view. Both point to the same thing; only the way of naming (the viewpoint) differs (the same duality as this site's treatment of N7 = Npcf_SMPolicyControl → N7).

Basic Concept — Beginner-friendly explanation

Let us liken N40 to a usage-based meter and a billing center.

When your smartphone does data communication, that traffic flows through the pipe (UPF). The UPF measures "how much flowed" like a meter and reports the result to the SMF (N4 Usage Report). The SMF tallies this measured value and reports to the CHF, the billing center, "this customer used this much." This is N40.

There are two kinds of pricing plan. For prepaid (pay in advance), before permitting communication it confirms with the billing center "how much can still be used?" and receives the amount that may be used (quota) up front. When it is about to run out of quota, it requests more. This is online charging. For postpaid (pay later), it has the actual usage recorded as an itemized record (charging record) and settles it in bulk afterward. This is offline charging. In 5G, this CHF handles both together, so it is called Converged Charging.

This reporting to the billing center is not over a dedicated telephone line; rather, it is like submitting requests and receiving answers over an internal web system (HTTP). This is the mechanism of SBI = NFs conversing via web APIs (HTTP/2), where both requests and responses are exchanged in human-readable JSON.

Protocol / Transport

Item Content
Protocol HTTP/2 + JSON (RESTful) — the common stack of SBI (Service Based Interface)
Service Nchf_ConvergedCharging (provided by the CHF) — TS 32.290 / TS 32.291
SBI framework TS 29.500 / TS 29.501 family (common SBI conventions and OpenAPI definitions)
Lower transport TCP, protected by TLS (confidentiality, integrity, authentication) — TS 33.501
Port The SBI listening port is implementation-dependent (resolved via the NRF-registered endpoint). No specific number is asserted
Characteristics Not a dedicated L4 protocol but web-technology based. Operated via HTTP methods + resource URIs. RESTful

N40 is SBI. Not a dedicated L4 protocol

N2 has NGAP over SCTP, and N4 has PFCP over UDP, as their dedicated lower protocols, but none of these apply to N40. Because N40 is SBI, it uses HTTP/2 over TLS as its common foundation, just like the other SBIs (N7/N8/N10/N11, etc.). Therefore, you must not reuse SCTP-specific filters or port numbers when analyzing N40.

Architecture

This shows the context in which N40 connects the SMF and the CHF, and the SMF obtains usage reports from the UPF over N4 as its input.

flowchart LR
  UPF["UPF (forwarding)"]
  SMF["SMF"]
  CHF["CHF (charging)"]

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

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

How to read the diagram: Over the dotted N4, the UPF reports data usage (Usage Report) to the SMF, and the SMF tallies it. The thick line (==>), N40, is the charging request from the SMF to the CHF (SBI/HTTP2, Nchf_ConvergedCharging). Note the role division: N4 is "measurement of how much was used," and N40 is "charging based on that usage." The UPF is solely responsible for measurement and data forwarding, while the CHF makes the fee judgment.

Usage Procedure

N40 is used within the lifecycle of a PDU Session when the SMF requests charging to the CHF (the behavior differs depending on the online/offline configuration).

  • Charging-session start (Create): At PDU session establishment, the SMF starts a charging session at the CHF over N40. For online charging, it obtains an initial quota (the amount that may be used) from the CHF at this point.
  • Usage measurement (N4): The SMF sets a URR (Usage Reporting Rule) on the UPF, and the UPF measures data usage. The UPF reports the usage to the SMF via an N4 Usage Report.
  • Usage reporting / quota re-acquisition (Update): The SMF reports the received usage to the CHF over N40. In online charging, when the quota is about to be depleted, it requests additional quota from the CHF.
  • Charging-session end (Release): At PDU session release, the SMF reports the final usage and ends the charging session over N40.

The exact methods, resource URIs, invocation sequences, timers, etc. of each operation are to be confirmed. For the overall picture of the procedure, see PDU Session; for the details of UPF measurement, see N4.

Main Messages

Because N40 is SBI, messages take the form of HTTP method + resource operation (RESTful operations rather than a procedureCode like NGAP). Representative service operations are as follows.

Service operation HTTP operation (conceptual example) Purpose
Nchf_ConvergedCharging_Create POST (resource creation) Start charging session; obtain initial quota if online
Nchf_ConvergedCharging_Update POST (update-operation invocation) Usage reporting, quota re-acquisition (additional request)
Nchf_ConvergedCharging_Release POST/DELETE (end/deletion) End charging session, finalize the final usage

The HTTP-operation and operation-name mappings are a conceptual arrangement: The "HTTP operations" and operation names in the table above are mappings for understanding; the exact methods, resource URIs, and invocation directions of each operation follow the OpenAPI definitions of TS 32.290 / TS 32.291. Strict method assignments and operation details are to be confirmed. For details of each message, see the Message dictionary.

Packet Analysis (Wireshark)

Because N40 is SBI, it is observed in captures as HTTP/2 (L4-dedicated protocols like NGAP/SCTP do not appear).

Purpose Display Filter
Extract HTTP/2 messages http2
Narrow by header path (conceptual) http2.headers.path (:path containing nchf-convergedcharging)
View the JSON body json (after decryption)

Points to watch when decoding:

  • N40 is encrypted with TLS. To see the contents (HTTP/2 headers and JSON body), a decryption key (TLS session key, etc.) is required. Without the key, it appears only as an encrypted tls payload.
  • Once decrypted, you can identify operations by the HTTP/2 headers (:method = POST, etc.; :path containing a resource path such as .../nchf-convergedcharging/...).
  • The body is JSON (usage, quota, charging data, etc.), laid out in a human-readable structure.
  • Unlike NGAP on N2 (binary, over SCTP), the key to observing N40 is that it is web-like (HTTP/JSON). SCTP-specific filters (sctp.port, etc.) are not used.

Comparison with EPC

  • In 4G: Charging was split into two systems. Online charging was handled by the OCS (Online Charging System), interworking with the PGW, etc. over Gy (Diameter) / Ro (credit and quota control). Offline charging was handled by the OFCS (Offline Charging System), interworking with the SGW/PGW, etc. over Gz / Rf (Diameter) (charging-record generation). Online and offline were separate systems and separate interfaces.
  • In 5G: The CHF integrated the roles of the OCS and OFCS into one (Converged Charging), and the interworking with the SMF was turned into an SBI as N40 (Nchf_ConvergedCharging). The multiple Diameter-based IFs (Gy/Ro + Gz/Rf) were replaced by a single SBI of HTTP/2 + JSON.
4G (EPC) 5G (5GC)
Gy/Ro (SGW/PGW ⇔ OCS, online) + Gz/Rf (⇔ OFCS, offline) N40 (SMF ⇔ CHF, integrated)
Diameter (over a dedicated L4) SBI: HTTP/2 + JSON over TLS
— (charging-system spec) TS 32.290 (Nchf_ConvergedCharging)
OCS + OFCS (online/offline separate systems) CHF (integrated into Converged Charging)

Integration is the essence of N40: The OCS (Gy/Ro, online) and OFCS (Gz/Rf, offline) that were separate in 4G are, in 5G, integrated into the CHF, with the interworking with the SMF consolidated into N40 (a single SBI). This is the meaning of "Converged Charging."

3GPP Specification

  • 3GPP TS 32.290 — Nchf_ConvergedCharging service (service-ization of 5G charging). Specific clause numbers are to be confirmed
  • 3GPP TS 32.291 — 5G system charging service details (operations, API). Specific clause numbers are to be confirmed
  • 3GPP TS 32.240 — Charging architecture and principles (Charging architecture)
  • 3GPP TS 29.500 / TS 29.501 — SBI framework (technical specification / design principles and OpenAPI). Specific clause numbers are to be confirmed
  • 3GPP TS 23.501 §6.2 — Description of network functions. Note that the CHF does not have an independent clause under §6.2; the definition of the charging function is placed in charging-system specs such as TS 32.290
  • 3GPP TS 33.501 — SBI security (TLS, etc.). Specific clause numbers are to be confirmed

Note (to be confirmed): That the actual form of N40 is Nchf_ConvergedCharging (TS 32.290/32.291), and that Converged Charging is the integration of online + offline, are general characterizations of 3GPP. Because the exact names, methods, resource URIs, and timers of each service operation (Create/Update/Release, etc.) differ by Release, they are individually to be confirmed. Note also that SpendingLimitControl, related to PCF-interworking credit control, is a separate service (Nchf_SpendingLimitControl) and is distinguished from ConvergedCharging, the protagonist of N40.

Summary

  • N40 is the reference point connecting SMF ⇔ CHF, and it is an SBI (HTTP/2 + JSON over TLS).
  • Its actual form is the CHF-provided Nchf_ConvergedCharging (TS 32.290). Converged Charging = the integration of online charging (credit/quota control) and offline charging (charging-record generation).
  • Based on the UPF usage measurement of N4 (URR/Usage Report), the SMF starts, updates, and releases the CHF's charging session over N40.
  • Reference point N40 = service Nchf_ConvergedCharging are two views of the same SMF⇔CHF interworking (the same duality as this site's treatment of N7 = Npcf_SMPolicyControl).
  • It corresponds to 4G OCS (Gy/Ro, online) + OFCS (Gz/Rf, offline), and in 5G it was integrated into the CHF and turned into an SBI (N40).

Next Step

  • CHF — The peer side of N40. The charging hub that provides Converged Charging
  • SMF — The NF that uses N40 to request charging and tallies the N4 usage measurement
  • N4 — The UPF usage measurement (URR/Usage Report) that is the input to charging
  • PDU Session — The lifecycle of the PDU session to which the charging session is tied
  • Interface dictionary — Confirming reference points and SBIs such as N7/N11 and others