The Charging Function (CHF): How 5G Decides What a Session Costs
The Charging Function (CHF) is the network function in the 5G Core that decides what a session may cost and whether it may continue. It grants a quota to the Session Management Function, receives usage reports back, and either grants more or stops the session. Combining the online and offline charging that 4G split between the OCS and the OFCS.
The Charging Function (CHF) is a critical and foundational network function within the 5G Core (5GC) architecture, defined by 3GPP as the unified charging entity that consolidates both online and offline charging into a single, converged service. Understanding its purpose is essential for any Full MVNO, IoT operator, or mobile brand that is building or migrating toward a native 5G core network. The CHF replaces the separate Online Charging System (OCS) and Offline Charging System (OFCS) that existed in 4G architectures, merging their functions into a single cloud-native network function that communicates over a modern HTTP/2-based API. Every prepaid balance deduction, every postpaid usage record, every data session charge, and every roaming charging event in a native 5G network flows through the CHF. It is the financial engine of your 5G core, and owning or selecting the right CHF is one of the most commercially consequential decisions you will make when building a 5G-ready mobile brand. If you are evaluating your charging architecture for a 5G launch, migrating from a legacy 4G Evolved Packet Core, or simply seeking to understand where charging fits in the 5G Core, this page provides the complete, authoritative reference you need.
On this page
- History and Evolution of the Charging Function
- Core Utility and Functionality of the CHF
- What is the CHF Used For?
- Key Functions of the Charging Function
- Technical Integration and Data Model
- Integration with Other Systems
- Technical Data Model and Key Interfaces
- CHF Ownership for MVNOs and IoT Companies
- Why Own a CHF?
- Advantages and Disadvantages of CHF Ownership
History and Evolution of the Charging Function
The CHF was introduced by 3GPP in Release 15 as part of the foundational 5G Core Service-Based Architecture (SBA). It was designed to address a core architectural limitation of the 4G charging model: the separation of online charging (handled by the OCS via the Diameter Gy interface) and offline charging (handled by the OFCS via the Diameter Rf interface) into two distinct systems with separate protocols, separate integration points, and separate operational teams. The CHF converges both into a single network function exposing a unified HTTP/2-based Nchf API, reflecting the cloud-native, microservices-oriented philosophy that defines the entire 5G Core architecture. Its design continues to evolve in 3GPP Releases 16, 17, and 18, adding support for more complex charging scenarios, network slicing, and advanced roaming charging models.
Core Utility and Functionality of the CHF
What sits inside the CHF
| Component | What it does | Why it matters to you |
|---|---|---|
| ABMF: Account Balance Management Function | Holds the balance a prepaid subscriber actually has | This is the number your subscriber sees in the app |
| Rating Function | Turns a unit of usage into an amount | Where your price list becomes real |
| CDF: Charging Data Function | Produces the charging records | Feeds billing and revenue assurance |
| CGF: Charging Gateway Function | Collects and forwards those records to the BSS | The hand-off point to your own systems |
| Converged charging | Prepaid and postpaid through one function | One set of rules instead of two |
What is the CHF Used For?
The Charging Function (CHF) is the definitive charging authority in a native 5G Core network. Its primary purpose is to receive charging requests from all relevant 5G Network Functions (NFs), apply the correct charging logic for each subscriber and service, and generate the appropriate charging output, whether that is an immediate balance deduction for a prepaid subscriber or a charging data record (CDR) for postpaid billing. When a 5G subscriber initiates a data session, a voice call, or uses any network service, the responsible NF, typically the Session Management Function (SMF), sends a charging request to the CHF over the Nchf interface. The CHF queries the subscriber's charging profile, applies the relevant tariff and policy, and responds with an authorization to proceed, a granted service unit (for prepaid), or an instruction to terminate if credit is exhausted.
This makes the CHF the single point of truth for all charging decisions in the 5G core. Owning and controlling a CHF gives a Full MVNO complete authority over its revenue assurance, its prepaid and postpaid product design, its real-time balance management, and the quality and granularity of the usage data it feeds into its BSS for billing and analytics.
Key Functions of the Charging Function
Examine the core functions of the CHF to understand its pivotal role in 5G network operations:
- Converged Online Charging: The CHF performs real-time credit control for prepaid subscribers, granting service units (data volume, time, events) based on available balance and applying immediate deductions as services are consumed, equivalent to the OCS Gy function in 4G.
- Converged Offline Charging: The CHF generates Charging Data Records (CDRs) for postpaid subscribers, recording detailed usage information for each session that is subsequently fed into the operator's rating and billing systems via the BSS.
- Nchf Service-Based Interface: The CHF exposes two primary services over the Nchf API: Nchf-SpendingLimitControl for budget and spending limit enforcement, and Nchf-ConvergedCharging for all session and event-based charging interactions. These services are consumed by NFs such as the SMF, AMF, and application functions.
- Session Charging: For data sessions managed by the SMF and User Plane Function (UPF), the CHF authorizes session establishment, monitors consumption against granted quotas, and triggers re-authorization or termination based on quota exhaustion or policy changes.
- Event Charging: For non-session-based services such as SMS, the CHF handles event-based charging, deducting or recording the appropriate charge for each discrete event.
- Spending Limit Control: The CHF enforces subscriber-level or service-level spending limits, integrating with the Policy Control Function (PCF) to notify it when a subscriber approaches or reaches a defined threshold, triggering policy actions such as speed throttling or service suspension.
- Roaming Charging: The CHF handles charging for roaming subscribers, applying home-network tariffs to visited-network usage data and generating the appropriate inter-operator charging records for roaming settlement.
- Network Slice Charging: In advanced 5G deployments, the CHF supports per-slice charging, enabling operators to apply differentiated tariffs to services delivered over specific network slices, a capability critical for enterprise 5G monetization.
- Re-authorization and Quota Management: As a subscriber consumes their granted service units, the CHF manages re-authorization cycles, granting additional units when a subscriber still has credit or triggering termination or policy enforcement when credit or quota is exhausted.
- Charging Data Record Generation: The CHF produces detailed, standards-compliant CDRs for every chargeable event, providing the granular usage data that feeds into rating, billing, and revenue assurance processes in the BSS.
Technical Integration and Data Model
Integration with Other Systems
The Charging Function is a central network function in the 5G SBA, and it integrates with a wide range of other NFs and external systems. Understanding these integration points is essential before you plan a CHF deployment.
Within the 5G core, the CHF's primary consumer is the SMF, which sends charging requests for every PDU session it manages. The AMF may also interact with the CHF for event-based charging related to mobility and registration events. The CHF integrates with the PCF for spending limit notifications, ensuring that policy actions are triggered in real time as subscribers approach their usage thresholds. It queries the Unified Data Management (UDM) and Unified Data Repository (UDR) to retrieve subscriber charging profiles, tariff class assignments, and active service configurations. The Network Repository Function (NRF) is used for service discovery, enabling NFs to locate the correct CHF instance for a given subscriber or network slice. The Service Communication Proxy (SCP) may be deployed as an intermediary to route Nchf messages between NFs and the CHF, providing load balancing, topology hiding, and resilience.
Outside the 5G core, the CHF's most critical integration is with the operator's BSS. The CDRs generated by the CHF are delivered to the BSS for rating, billing, and subscriber account management. For prepaid services, the CHF integrates with the balance management and top-up systems within the BSS to retrieve and update subscriber credit in real time. This CHF-to-BSS integration is one of the most commercially sensitive integrations in the entire 5G stack, because any failure or latency in this path directly impacts revenue collection and subscriber experience. Careful design of this interface, with appropriate buffering, retry mechanisms, and reconciliation processes, is a prerequisite for a production-grade CHF deployment.
Technical Data Model and Key Interfaces
Quota size is the design decision
| Service | Suggested quota approach | Why |
|---|---|---|
| Voice | Time-based, short grants | Overspend is visible and disputed quickly |
| Data, consumer | Volume-based, moderate grants | Balance between signalling load and overspend |
| Data, high speed | Larger grants, tighter reporting triggers | A 5G session can spend a quota in seconds |
| IoT, low bandwidth | Large grants, infrequent reporting | Devices wake rarely; signalling costs battery |
| Roaming | Small grants regardless of service | You are exposed to another operator's rates |
The CHF maintains a structured charging data model that maps each subscriber (identified by SUPI or GPSI) to a charging profile containing their tariff class, quota assignments, spending limits, and active service parameters. Key interfaces and protocols used by the CHF include:
How the CHF charges a 5G session: quota out, usage back, quota again
- Nchf-ConvergedCharging (HTTP/2, JSON): The primary service interface through which NFs such as the SMF submit charging requests, receive quota grants, and report usage. This replaces the Diameter Gy and Rf interfaces of the 4G OCS and OFCS.
- Nchf-SpendingLimitControl (HTTP/2, JSON): Used by the PCF to subscribe to spending limit notifications, enabling real-time policy reactions when a subscriber's usage approaches or reaches a defined threshold.
- Nudr (HTTP/2): Used to retrieve subscriber charging data and tariff profiles from the UDR.
- Nudm (HTTP/2): Used to query subscriber-level data from the UDM relevant to charging decisions.
- CDR Export Interface: A northbound interface used to deliver generated CDRs to the BSS mediation layer or billing system. This may be implemented as a file-based transfer (e.g., ASN.1-encoded CDR files) or a real-time streaming interface depending on the BSS platform.
- Diameter (Gy/Rf) Interworking: Many CHF implementations include a backward-compatible Diameter interface to support interworking with legacy 4G NFs or third-party systems that still use OCS/OFCS-style Diameter charging protocols during a migration period.
CHF Ownership for MVNOs and IoT Companies
Why Own a CHF?
For a Full MVNO deploying a native 5G Core, owning a dedicated Charging Function (CHF) is essential for commercial independence and financial control. The CHF is the node that decides, in real time, whether a subscriber's service continues or stops, how much of their balance is consumed, and what usage data is recorded for billing. Owning it means you control every dimension of your charging model: your tariff structures, your prepaid quota management, your spending limit policies, and the granularity and quality of the CDRs that feed your billing system.
For IoT operators managing large device fleets, the CHF is the tool that enables sophisticated, device-level charging models. You can define per-device quotas, enforce spending caps at the device, group, or customer account level, and generate the granular usage data needed for IoT service billing and SLA reporting. For operators building data-centric MVNO or Business MVNO products, the CHF's network slice charging and spending limit capabilities are the technical foundation for differentiated, premium service tiers that command higher ARPU. Without owning your CHF, all of these capabilities depend on the willingness and roadmap of your host operator or MVNE.
Advantages and Disadvantages
Advantages:
- Complete Charging Control: Full ownership of tariff logic, quota management, and CDR generation, enabling rapid product iteration without dependency on a third party.
- Converged Architecture: A single CHF replaces both the legacy OCS and OFCS, simplifying your charging infrastructure, reducing integration complexity, and lowering operational overhead compared to maintaining two separate systems.
- Cloud-Native Scalability: Designed as a microservice, the CHF scales horizontally to handle growing subscriber volumes and peak usage events without the capacity constraints of legacy Diameter-based charging nodes.
- Real-Time Revenue Assurance: Direct ownership of the CHF gives you immediate visibility into charging failures, quota anomalies, and revenue leakage, enabling proactive revenue assurance rather than reactive reconciliation.
- Advanced Monetization: Native support for network slice charging, spending limit control, and event-based charging enables monetization of 5G capabilities that legacy OCS/OFCS architectures cannot support without costly customization.
- BSS Integration Flexibility: You control the CDR format, delivery mechanism, and frequency, allowing tight integration with your chosen BSS platform.
Disadvantages:
- High initial investment in IMS-capable, carrier-grade application server software and infrastructure.
- Operational complexity requiring deep expertise in SIP, IMS architecture, and VoLTE/VoWiFi protocol stacks.
- Ongoing maintenance and upgrade costs for a mission-critical, real-time system in the direct path of every voice call.
- Interworking complexity when integrating with legacy PSTN and interconnect partners via the SBC.
- Requires tightly coordinated integration with the HSS/UDM, OCS, and CSCF nodes, demanding significant network integration expertise.
Organizational Impact of CHF Ownership
Deploying and operating a CHF has wide-ranging consequences across your commercial, technical, and financial operations:
-
Operational Impact: Requires engineering and operations teams with expertise in 5G SBA, HTTP/2 protocol behavior, and real-time charging system operations. CDR delivery pipelines to the BSS must be monitored continuously, with alerting on delivery failures or volume anomalies that could indicate revenue leakage. Balance management processes for prepaid subscribers must be automated and reconciled in real time, with clear escalation procedures for charging failures that could inadvertently deny service to subscribers with valid credit. The operations team must also maintain tariff configuration discipline, ensuring that changes to product plans in the BSS are reflected accurately and promptly in the CHF's charging profiles.
-
Financial Impact: CHF ownership involves CapEx for cloud infrastructure and software licensing, plus OpEx for specialist 5G charging engineers and platform operations. The direct financial benefit is the ability to build and price innovative 5G products, including network-sliced enterprise services, IoT usage-based billing models, and converged prepaid and postpaid products, without paying a third party for access to charging functionality. Accurate financial planning should account for the full cost of ownership against the revenue uplift from differentiated charging capabilities. Effective Telecom Expense Management processes depend heavily on the quality and completeness of the CDR data the CHF produces.
-
Security Impact: The CHF handles real-time financial transactions and subscriber balance data. It is a target for manipulation attempts, charging bypass attacks, and fraudulent quota exploitation. Access control to the Nchf API must be enforced through mutual TLS authentication and OAuth 2.0 token-based authorization as defined in the 5G security architecture. All CHF API interactions should be logged for audit purposes, and anomaly detection should be applied to charging request patterns to identify potential fraud or misconfiguration before it impacts revenue.
-
Technical Impact: The CHF must be deployed as a horizontally scalable, stateless or state-resilient microservice with sub-second response times for all charging authorization requests. It must integrate bidirectionally with the BSS mediation layer, the UDM/UDR for subscriber profile data, and the PCF for spending limit notifications. A robust testing and staging environment is essential to validate tariff changes, quota management logic, and CDR formats before they are applied in production. Integration testing with the SMF is particularly critical, as the SMF-CHF interaction is the highest-volume charging interface in the 5G core.
Redundancy and High Availability
The Charging Function (CHF) is in the direct transaction path of every chargeable service event in your 5G network. A CHF failure means prepaid subscribers cannot receive service authorization, CDR generation halts, and revenue recording stops. Redundancy and High Availability (HA) are therefore absolute requirements for any production CHF deployment.
Deploy the CHF in a fully redundant, active-active cluster configuration, distributing charging requests across multiple CHF instances using load balancing at the SCP or directly via the NRF service discovery mechanism. Geographic redundancy across two or more data centers is standard practice, with session state synchronization between sites ensuring that an active charging session is not disrupted if one node or site fails. For prepaid charging, subscriber balance state must be continuously replicated across all CHF instances and sites, because balance inconsistency during a failover event can result in either double-charging or unauthorized service continuation, both of which carry serious commercial and regulatory consequences.
Implement rigorous health monitoring with automated failover, and define recovery time objectives that align with your revenue assurance and service level commitments. For a Full MVNO committed to carrier-grade service, a five-nines (99.999%) availability target for the CHF is the industry benchmark to design toward.
Impact of 4G, 5G, and IoT on CHF
The CHF's Predecessors in the 4G Core
In the 4G Evolved Packet Core, charging was split between two separate systems. The Online Charging System (OCS) handled real-time prepaid credit control via the Diameter Gy interface, interacting with the Policy and Charging Rules Function (PCRF) and the Packet Data Network Gateway (PGW) to enforce quota and balance limits. The Offline Charging System (OFCS) collected CDRs from network elements via the Diameter Rf interface for postpaid billing. These two systems required separate integrations, separate operations teams, and separate protocol expertise. The CHF was specifically designed to eliminate this dual-system complexity.
The evolution of charging across generations follows a clear pattern:
| Generation | Charging Function | Protocol |
|---|---|---|
| 2G/3G | Separate OCS and OFCS | SS7/CAP, RADIUS |
| 4G (LTE) | Separate OCS and OFCS | Diameter Gy/Rf |
| 5G | Converged CHF | HTTP/2 (Nchf) |
The CHF in the Native 5G Architecture
In the 5G Core, the CHF is a native SBA network function. It is discovered via the NRF, communicates over the Nchf HTTP/2 API, and integrates with the SMF, AMF, PCF, UDM, UDR, and SCP as part of a fully cloud-native, microservices-oriented charging architecture. Advanced 5G features including network slicing, edge computing monetization, and API-based service exposure all route their charging requirements through the CHF, making it the financial backbone of the entire 5G value chain.
6G and the Future of Charging
In the 6G era, the CHF is expected to evolve toward an AI-driven, intent-based charging engine capable of dynamically constructing tariff models in real time based on network conditions, subscriber behavior, and service quality delivered. Real-time charging convergence with billing, autonomous fraud detection, and API-exposed charging primitives for third-party service monetization are among the capabilities being explored in early 6G research. The foundational principle of the CHF, a single converged function that controls all charging decisions in the network, will remain the cornerstone of mobile monetization architecture for all future generations.
Frequently Asked Questions
What is the main function of the CHF?
The CHF is the converged charging entity in the 5G Core that handles both online (real-time, prepaid) and offline (CDR-based, postpaid) charging for all network services, replacing the separate OCS and OFCS used in 4G networks.
How does the CHF differ from the OCS?
The OCS handled only real-time online charging in 4G networks using the Diameter Gy interface. The CHF converges both online and offline charging into a single function using the HTTP/2-based Nchf API, as part of the 5G Service-Based Architecture.
Which 5G network functions interact with the CHF?
The primary consumer of the CHF is the SMF. The AMF may interact for event charging, the PCF subscribes to spending limit notifications, and the UDM and UDR provide subscriber charging profile data.
Do MVNOs need their own CHF?
Full MVNOs with their own 5G core infrastructure need a CHF to manage charging independently. Lighter MVNOs hosted on an MVNE platform can use a shared CHF provided by the MVNE, but they surrender direct control over charging logic and CDR data.
What is the Nchf interface?
The Nchf interface is the HTTP/2-based, JSON-encoded service interface exposed by the CHF in the 5G SBA. It consists of two primary services: Nchf-ConvergedCharging for session and event charging interactions, and Nchf-SpendingLimitControl for budget threshold notifications to the PCF.
Can the CHF support both prepaid and postpaid subscribers simultaneously?
Yes. The converged design of the CHF means it handles real-time online charging for prepaid subscribers and CDR generation for postpaid subscribers within the same function, using the same Nchf interface. The charging behavior for each subscriber is determined by their charging profile retrieved from the UDR.
What is the relationship between the CHF and the PCF?
The PCF and CHF work in close coordination. The CHF notifies the PCF when a subscriber approaches or reaches a spending limit via the Nchf-SpendingLimitControl service, enabling the PCF to apply policy actions such as throttling or service modification in real time.
Summary
The Charging Function (CHF) is the converged, cloud-native financial engine of the 5G Core, consolidating the real-time credit control of the legacy OCS and the record generation of the legacy OFCS into a single, standards-defined network function built for the HTTP/2-based 5G Service-Based Architecture. For a Full MVNO or IoT operator deploying a native 5G core, owning and operating a CHF is essential for complete commercial independence, precise revenue assurance, and the ability to build and monetize differentiated 5G products including network slicing, per-device IoT billing, and converged prepaid and postpaid services.
This decision demands investment in cloud-native infrastructure, deep 5G charging specification expertise, and a tightly engineered integration with your BSS. The CHF is in the critical path of every revenue-generating event in your network, and its reliability, scalability, and accuracy directly determine the financial health of your mobile brand. As the industry moves toward 6G, the converged charging model pioneered by the CHF will only become more central to how operators monetize increasingly complex, AI-driven, and application-specific network services. If you are evaluating solution providers for your 5G core charging architecture, explore the Core Network Elements and BSS solution providers listed on MVNO Index to identify the right CHF and billing platform partners for your business.
5G Core (5GC)
