Real-time charging works by holding a session open between the network and the charging system for its entire life. Diameter accounting and credit control – chiefly the Gy interface between the AAA/enforcement layer and the Online Charging System (OCS) – reserve quota before service is delivered, report usage as it happens, and cut off or redirect the session the moment credit runs out. In 5G, the same job moves to the Charging Function (CHF) over service-based interfaces, but most operators will run Diameter and 5G converged charging side by side for years.
Every prepaid session is a small act of trust. The network delivers service now; the charging system settles the account in real time or revenue leaks. For revenue assurance and charging engineers, the mechanics of that settlement live in two places: Diameter accounting and credit control on the network side, and the AAA (Authentication, Authorization, and Accounting) platform that anchors session state. This post walks through how the pieces fit – from the Gy interface to quota management to what changes (and what doesn’t) with the 5G Charging Function (CHF).
This is the architecture companion to our earlier post on quota management. Here the focus is the charging chain itself: which element talks to which, over what interface, and where the failure points hide.
How Real-Time Charging Works in Telecom
Real-time charging – formally online charging – means credit is checked and reserved before service is delivered, and usage is settled while the session runs. Contrast that with offline charging, where the network simply records what happened (Charging Data Records, or CDRs, and Diameter accounting records over Rf) and billing catches up later. Offline charging can tolerate delay. Online charging cannot: a prepaid subscriber with an empty balance must be stopped mid-session, not billed next month.
The online charging loop has three repeating steps. First, the network element that controls the session asks the Online Charging System (OCS) for a quota – an allowance of units (bytes, seconds, events) drawn against the subscriber’s balance. Second, the network delivers service and counts consumption against that quota. Third, when the quota nears exhaustion or a timer expires, the network reports usage and requests more. The loop repeats until the subscriber disconnects or the balance runs dry.
Two things make this loop hard at carrier scale. Latency: the credit check sits in the session-setup path, so a slow OCS answer delays every prepaid attach. And state: someone has to keep an accurate, crash-proof record of every open session and every outstanding reservation. That state-keeping is where AAA and Diameter accounting earn their place in the architecture.
Diameter Accounting and Credit Control: The Gy Interface
Diameter is the successor to RADIUS, defined in RFC 6733, built for exactly this class of problem: reliable, stateful, high-volume signaling between core network elements. On top of the base protocol, the Diameter Credit-Control Application (RFC 4006, since updated by RFC 8506) defines how a network element requests, consumes, and returns credit in real time.
The Gy interface is where that application meets packet data charging. Gy connects the traffic enforcement point – the Policy and Charging Enforcement Function (PCEF) inside a Packet Data Network Gateway (PGW) in mobile networks, or the AAA/Broadband Network Gateway (BNG) chain in fixed broadband and Wi-Fi – to the OCS. Its 3GPP profile is specified in TS 32.299, alongside the Ro interface used for IP Multimedia Subsystem (IMS) and event-based services; the two share the same credit-control machinery.
A useful distinction for revenue assurance teams: Diameter accounting in the strict sense (ACR/ACA messages over Rf) is offline – it records usage for later billing and reconciliation. Gy is credit control – it authorizes usage before it happens. Mature charging architectures run both, because Rf records are what you reconcile Gy sessions against when the numbers don’t add up. If you only have one, you can bill; you can’t audit.
AAA Role in Real-Time Charging
The AAA server sits upstream of charging, and everything downstream depends on it getting three things right.
It establishes who is being charged. Authentication (Extensible Authentication Protocol methods EAP-SIM/AKA/AKA’ for mobile and Wi-Fi, PAP/CHAP or certificate-based for broadband) binds a session to a subscriber identity. Every quota request the OCS ever sees traces back to this binding. A mis-mapped identity is not a security bug alone – it is a billing error on every byte of the session.
It owns session state. The AAA tracks session start, interim updates, and stop; detects duplicates; and persists state across failovers. In fixed-line and Wi-Fi networks especially, the AAA is the element that knows a session exists at all – the BNG enforces, but the AAA accounts. RADIUS accounting records and Diameter accounting flows both originate from this state.
It enforces the charging decision. When the OCS says “out of credit,” someone has to act on the live session. The AAA does this through Dynamic Change-of-Authorization (CoA) on RADIUS sessions or re-authorization on Diameter sessions – throttling, redirecting to a top-up portal, or disconnecting. Real-time charging without a real-time enforcement path is just fast reporting.
This is also why AAA matters in 5G and IoT architectures: as session counts multiply, the charging chain is only as accurate as the session layer beneath it.
Gy Interface: AAA to OCS Communication
On the wire, a Gy session is a conversation in three message types, all variants of the Credit-Control-Request (CCR) answered by a Credit-Control-Answer (CCA).
CCR-Initial opens the charging session. It carries the subscriber identity, the rating context, and a first quota request. The OCS rates the request, reserves balance, and returns Granted-Service-Units (GSU) in the CCA – say, 500 MB or 1,800 seconds. Service starts only after this answer arrives. This is the latency-critical message: it sits between “subscriber connects” and “subscriber gets data.”
CCR-Update keeps the session honest. The client sends it when granted quota nears exhaustion, when a Validity-Time timer expires, or when the rating context changes (new rating group, QoS change, location change). Each update reports Used-Service-Units (USU) and requests the next grant. The OCS deducts, re-rates if needed, and grants again.
CCR-Terminate closes the session, reports final usage, and releases any unused reservation back to the balance. Missed or lost terminates are a classic revenue assurance leak: reservations that never settle, balances that drift from reality.
Failure handling deserves its own line item in any charging audit. The Credit-Control-Failure-Handling (CCFH) AVP tells the client what to do when the OCS stops answering: terminate the session (revenue-safe, subscriber-hostile), continue (subscriber-safe, revenue-exposed), or retry and terminate. Which setting your network runs – per service, per Access Point Name (APN) – is a commercial policy decision that too often ships as a vendor default.
Real-Time Quota Management with Diameter
Quota is how the architecture buys itself breathing room. Authorizing every packet against a central balance would melt any OCS; instead, credit control hands out quota in slices and trues up at each report. Getting the slicing right is a tuning exercise with real money on both sides of the dial.
The core mechanisms, all carried inside the CCR/CCA exchange:
Multiple-Services-Credit-Control (MSCC) lets one Gy session manage several quota buckets at once, keyed by rating group – video rated differently from general data, a zero-rated partner service kept separate from both. One session, many meters.
Thresholds and Validity-Time control when the client comes back. A quota threshold triggers the CCR-Update before units hit zero, so the next grant arrives while service continues uninterrupted. Validity-Time forces a report even on idle sessions, capping how stale the OCS’s view can get.
Final-Unit-Indication (FUI) handles the end of the balance gracefully. With the last grant, the OCS attaches an instruction: when these units are gone, terminate, redirect (to a top-up page – the difference between a churn event and a recharge), or restrict access to a whitelist of services.
The tuning trade-off: large grants reduce signaling load but increase exposure – quota reserved to a session that dies ungracefully is balance a subscriber can’t spend, and usage inside an oversized grant is money the OCS hasn’t seen yet. Small grants keep the ledger tight but multiply CCR volume. Charging engineers revisit these values as traffic mixes change; the numbers that suited a 4G smartphone base rarely suit fixed wireless access or IoT fleets.
5G Charging: CHF and Legacy Diameter
5G standalone reorganizes the charging plane. 3GPP Release 15 (TS 32.290 and TS 32.291) replaces the OCS/OFCS split with a single Charging Function (CHF) offering converged charging over the service-based Nchf interface – HTTP/2 REST APIs instead of Diameter AVPs. The Session Management Function (SMF) acts as the charging trigger function, and the old online/offline distinction collapses into one converged flow that can operate in either mode per session.
The logic, though, survives the protocol change almost untouched. Nchf’s ChargingDataRequest Initial/Update/Release maps cleanly onto CCR Initial/Update/Terminate. Quota, thresholds, validity time, and final-unit handling all reappear with new encodings. An engineer who understands Gy credit control already understands 5G converged charging; what changes is the transport, not the model.
What does not change quickly is the installed base. Every 4G session still charges over Gy. Non-standalone 5G – the way most subscribers get 5G today – anchors in the Evolved Packet Core (EPC) and charges over Diameter too. Fixed broadband and Wi-Fi never spoke Nchf at all. The realistic architecture for the rest of this decade is dual-stack: Diameter accounting and Gy credit control running alongside CHF-based converged charging, ideally against a single balance so a subscriber’s prepaid account doesn’t fragment by access type. The practical question for charging teams is not “when do we switch?” but “how do we keep one coherent ledger across both stacks while they coexist?”
Alepo AAA and Real-Time Charging
This coexistence problem is where Alepo AAA is built to sit. The platform terminates RADIUS, Diameter, and TACACS+ on a single stack, with Diameter coverage spanning eleven 3GPP interfaces – including Gy to the OCS for real-time credit control, Gx to the PCRF/PCF for policy, and S6b/SWx/SWm for subscriber data – plus the full EAP family for authentication across fixed, Wi-Fi, and mobile access.
In practice, that means one session layer feeding one charging chain regardless of access type. A fixed-broadband session authenticated over RADIUS, a Wi-Fi offload session on EAP-AKA’, and a 4G data session on Diameter can all resolve to the same subscriber, the same balance, and the same enforcement path – with CoA and re-authorization available when the OCS calls time. Session persistence, duplicate detection, and quota state survive failover on active-active geo-redundant pairs engineered for 99.999% availability.
The operational layer matters to charging teams too. The Alepo AI Agent for AAA reads RADIUS and Diameter flows in real time – surfacing error-pattern root causes and decoding Diameter result codes in plain language – which shortens the path from “prepaid attach failures are spiking” to knowing whether the fault is auth, policy, or the charging interface. Alepo AAA runs in production at Tier-1 operators worldwide, with more than ten AAA deployments globally. The platform deploys as containerized (Kubernetes), VM, bare-metal, cloud, on-premises, or a fully managed service – the same platform whether your charging estate is Gy today, Nchf tomorrow, or both for the foreseeable future.
FAQs
Q1. What is Diameter accounting?
Diameter accounting is the recording and transfer of session usage data using the Diameter protocol. In the strict 3GPP sense it refers to offline charging over the Rf interface (ACR/ACA messages), while real-time credit control runs over Gy. Operators run both: Gy authorizes usage as it happens; Rf records provide the audit trail for reconciliation.
Q2. What is the Gy interface used for?
Gy connects the network’s traffic enforcement point – a PGW/PCEF in mobile networks, or the AAA/BNG chain in fixed and Wi-Fi networks – to the Online Charging System. It carries Diameter Credit-Control messages (CCR/CCA) that reserve quota before service delivery, report usage during the session, and settle the balance at session end.
Q3. How does AAA participate in real-time charging?
The AAA server authenticates the subscriber (establishing who is billed), maintains authoritative session state (start, interim, stop), and enforces charging decisions on live sessions through Change-of-Authorization or Diameter re-authorization – disconnecting, throttling, or redirecting subscribers when the charging system requires it.
Q4. Does 5G still use Diameter for charging?
5G standalone introduces the Charging Function (CHF) with converged charging over the HTTP/2-based Nchf interface, replacing Diameter for 5G SA sessions. But 4G, 5G non-standalone, fixed broadband, and Wi-Fi continue to charge over Diameter Gy, so most operators will run both stacks in parallel for years.
Q5. What happens when a prepaid subscriber runs out of credit mid-session?
The OCS attaches a Final-Unit-Indication to the last quota grant. When those units are consumed, the network executes the instructed action: terminate the session, redirect the subscriber to a top-up portal, or restrict access to selected services until the balance is recharged.
Next steps:
Request a demo – see Gy credit control, CoA enforcement, and converged session management live with an Alepo engineer.
