An Online Charging System (OCS) is the real-time billing engine inside a telecom network. It authorizes a service, deducts balance or quota as the service is used, and updates the subscriber’s account instantly — before the next session starts. It is what makes prepaid, postpaid, and 5G services chargeable in real time, and it is the difference between charging a customer accurately in the moment and discovering a revenue gap days later.
Introduction
When the online charging system a telecom operator relies on goes down, the visible failure is small: a top-up does not reflect, a data session keeps running after the balance hits zero, a subscriber is charged twice. The invisible failure is larger. Every minute of inaccurate charging is either lost revenue or an unhappy customer. That is why real-time charging sits at the center of every prepaid and digital service an operator runs.
This guide explains what an OCS does, how it works inside the network, how online charging differs from offline charging, and what operators evaluating a charging platform should look for in 2026. It is written for technical and commercial readers who know prepaid billing but may not work with the underlying interfaces every day.
What does an Online Charging System actually do?
An OCS does three things, in real time, for every chargeable event:
- Authorize — before a session starts, it checks whether the subscriber has the balance, quota, or entitlement to use the service.
- Deduct — as the service is used, it draws down balance or quota against the rate that applies.
- Update — it writes the new balance back instantly, so the next authorization request sees an accurate figure.
The closest everyday parallel is a prepaid SIM top-up. You add credit, you use data, and your remaining balance reflects the moment you check it — not at the end of the month. An OCS performs that authorize-deduct-update loop for millions of subscribers and sessions at once, across data, voice, SMS, and digital services.
This is what separates online charging from offline charging. Offline charging records usage first and rates it later, in batch. That is fine for postpaid invoicing, but it cannot stop a session when credit runs out. Online charging decides before and during the session, which is what prepaid, real-time quota control, and fraud prevention require.
How does OCS work inside a telecom network?
The OCS does not sit alone. It talks to the data plane, the policy layer, and the IMS core through standard interfaces, and it runs several internal functions that turn raw usage into a charged event.
The Gy interface — how OCS talks to the network
The Gy interface is the Diameter credit-control link between the OCS and the packet gateway (the PGW or PCEF). When a subscriber starts a data session, the gateway sends a credit-control request over Gy; the OCS grants a quota; the gateway reports usage back; the OCS grants more or terminates the session. This Gy interface charging loop is what enforces a prepaid data plan in real time.
Alepo’s OCS — and the Alepo AAA Server it integrates with — support charging over the Diameter Gy interface using Diameter Credit-Control (DCCA), so an operator can run real-time data charging against a single subscriber balance. (See Gy interface and OCS–AAA integration.)
OCS internal components — RF, ABMF, and CGF
In a standards-based OCS, two functions do the core work, supported by a third on the charging-record path. The Rating Function (RF) calculates what a chargeable event costs, applying the right rate, tariff, or discount. The Account Balance Management Function (ABMF) holds the subscriber’s real-time balance and reservations. Sitting alongside, the Charging Gateway Function (CGF) aggregates charging records (CDRs) for downstream settlement and reporting. Most public explanations stop at “the OCS charges in real time.” Understanding RF, ABMF, and the CGF is what lets an operator reason about where rating logic lives, where balance is reserved, and how records flow out for reconciliation.
The Ro interface — OCS for IMS voice and SMS
Gy handles data; the Ro interface handles IMS-based voice and SMS. Ro is the Diameter credit-control interface between the IMS core and the OCS. If you run VoLTE or VoIP over an IMS core, Ro is how those calls get charged against the same real-time balance as data.
How OCS interacts with PCRF for policy-aware charging
Charging and policy are separate functions, but they work together. The PCRF (Policy and Charging Rules Function) decides what a subscriber is allowed to do — speed tier, fair-use throttling, zero-rated apps. The OCS decides what it costs. The two coordinate over the Sy interface for spending-limit control, so a policy decision — for example, restricting service once a subscriber reaches a spending limit — can be driven by a real-time charging condition. This is the basis of policy-aware charging — offers where the network behavior changes based on what the subscriber has spent or consumed.
Online charging vs offline charging — what’s the difference?
| Online charging | Offline charging | |
|---|---|---|
| Timing | Real time — before and during the session | After the fact — usage rated in batch |
| Can it stop a session? | Yes, when balance or quota is exhausted | No |
| Primary use | Prepaid, real-time quota, hybrid plans | Postpaid invoicing, reconciliation |
| Fraud / leakage risk | Low — the window for unbilled usage is near zero | Higher — usage can run ahead of billing |
A useful refinement most explanations skip: online charging can be event-based or session-based. Event-Based Charging (EBCF) charges discrete events — one SMS, one content purchase, one API call. Session-Based Charging (SBCF) charges continuous usage with reservation and reauthorization — a data session that grants quota in increments. Operators need both, because a modern plan mixes one-off events with metered sessions.
The practical reason this matters is revenue protection. With offline charging, usage can run for hours or days before it is rated. That delay is a window where unbilled usage and fraud accumulate. A real-time charging system closes that window because it rates and reserves as usage happens, not afterward.
Why does OCS matter for 5G and IoT monetization?
Two shifts make real-time charging harder — and more important.
5G. A 5G core supports network slicing and per-session differentiation, where a single subscriber may consume several service profiles at once with different rates and quotas. Batch billing cannot keep up with that granularity. In a 5G standalone core, the charging role is defined by the CHF (Charging Function), reached over the service-based Nchf interface. An online charging system for 5G must either expose the CHF/Nchf service natively or interwork with the 5G core, so that per-slice, per-session charging happens in real time.
IoT. IoT monetization is a problem of scale and size: millions of devices generating very small, very frequent sessions. Rating those events in real time, without letting unbilled usage accumulate, is exactly what an OCS is built to do and what offline batch billing is not.
For a CFO, the throughline is simple. Real-time charging shrinks the gap between service delivered and service billed. That gap is where revenue leakage and fraud live, and in 5G and IoT it grows faster than it does on legacy networks.
What should telecom operators look for in an OCS platform?
Six criteria separate a charging platform that will carry an operator forward from one that will need replacing again soon:
- Convergent — one engine that charges prepaid, postpaid, and hybrid against a single balance, rather than separate stacks per payment type.
- Policy-aware — native coordination with PCRF (4G) and the Policy Control Function (PCF) in 5G, so charging and policy decisions stay consistent.
- 5G-ready — support for CHF/Nchf, or proven interworking with a 5G core, plus the Gy interface for existing 4G data charging.
- Scalable — designed to grow with the subscriber base and with high-frequency IoT and 5G session volumes.
- BSS-native integration — charging that connects cleanly to billing, product catalog, CRM, and self-care, instead of bolting on through custom integration.
- Deployment flexibility — the option to run as SaaS, private cloud, on-premise, or managed service, chosen by the operator’s regulatory and scale needs.
On the last two points, Alepo’s OCS is a native module of the Alepo Digital BSS stack rather than a standalone product an operator has to integrate. It is available through Alepo’s BSSNow SaaS deployment, which lets a Mobile Virtual Network Operator (MVNO) or Internet Service Provider (ISP) add charging as a modular component instead of running a multi-year program. OCS for MVNO and ISP buyers in particular tends to favor this modular, lower-effort path.
How OCS fits into the broader BSS stack
Charging is one function in a larger Business Support System. In a convergent BSS, the OCS connects to convergent billing, the PCRF/PCF policy layer, the CRM, the product catalog, and the customer self-care channels. A rate defined in the catalog, a policy set in the PCRF, a balance held in the OCS, and a view shown in self-care all have to agree — in real time — or the customer experience breaks.
Within Alepo Digital BSS, the OCS is one native module among many, including convergent billing, product catalog, order management, self-care, and Voucher Management for prepaid top-up via vouchers and USSD — useful for prepaid-heavy markets. Real-time charging data also feeds Alepo’s AI CX layer, which uses billing and usage signals for analytics and revenue-protection. Because the modules are native to one platform, an operator can run the full stack or swap in charging alone. For a deeper view of how charging connects to the rest of the stack, see the related guide to the telecom billing system (link to be added once that page is live).
Frequently asked questions:
No. An OCS charges in real time — it authorizes and deducts as a service is used. A billing system produces invoices, applies taxes, and manages payment, usually for postpaid. In a convergent BSS the two work together against shared subscriber data.
The CHF (Charging Function) is the 5G standalone core’s charging role, reached over the Nchf interface. The OCS is the broader real-time charging system, historically tied to 4G’s Gy interface. A modern charging platform supports both so an operator can charge across 4G and 5G consistently.
An MVNO needs real-time charging, but it does not need to build and run a full charging stack itself. Many MVNOs adopt charging as part of a SaaS or modular BSS, which gives real-time control without a large integration project.
By charging in real time. Because the OCS authorizes and deducts before and during each session, the window in which usage goes unbilled is near zero — unlike offline batch billing, where usage can run ahead of charging for hours or days.
The main ones are Gy (Diameter credit-control for data, to the PGW/PCEF), Ro (Diameter credit-control for IMS voice and SMS), Sy (spending-limit coordination with the policy layer), and Nchf (the 5G CHF service-based interface).
See how Alepo OCS works inside a full convergent BSS stack — Book a demo.
