RADIUS accounting is how your network access equipment tells the AAA server who connected, for how long, and how much data they used. Defined in RFC 2866, it runs on three packet types – Start, Interim-Update, and Stop – and the records it produces feed billing, troubleshooting, and revenue assurance. If those records are wrong, everything downstream is wrong too.
If you work in a NOC, you deal with RADIUS accounting whether you think about it or not. Every stale session you clear, every “customer says they didn’t use 300 GB” ticket, every usage report the billing team questions – the trail leads back to accounting packets. This radius accounting telecom guide covers how the protocol actually behaves on the wire, where it breaks, and what that means for the numbers your operator bills against.
What is RADIUS Accounting?
RADIUS handles the three functions in AAA: authentication (is this subscriber who they claim to be?), authorization (what are they allowed to do?), and accounting (what did they actually do?). The first two happen before a session starts. Accounting is the record of what happened during and after it.
The accounting side of the protocol is defined in RFC 2866, separate from the authentication spec. It runs over UDP, on port 1813 (you’ll still see the legacy port 1646 on older gear). The client is your network access server – a BNG or BRAS in broadband, a wireless LAN controller in Wi-Fi, a gateway in mobile data – and the server is your AAA platform.
The division of labor is simple: the access equipment enforces the session and counts the traffic; the AAA server receives, deduplicates, and stores the records. The NAS knows what’s happening on its own ports right now. The AAA server is the only element that knows what’s happening across all of them – which is why it’s the system of record for session state, not the NAS.
One thing RADIUS accounting is not: real-time credit control. It reports usage after the fact; it doesn’t authorize usage before it happens. Prepaid enforcement needs a charging interface on top (more on that in the broadband vs mobile section). Accounting is the audit trail, and audit trails are only useful if they’re complete.
How RADIUS Accounting Works
The sequence starts where authentication ends. Once the NAS receives an Access-Accept and brings the session up, it sends an Accounting-Request packet with Acct-Status-Type set to Start. The AAA server writes the record and replies with an Accounting-Response. That response is a delivery receipt, nothing more – it acknowledges the packet arrived and was stored, not that its contents make sense.
While the session runs, the NAS can send Interim-Update packets at a configured interval, each carrying a cumulative snapshot of usage so far. When the session ends – subscriber disconnects, idle timeout, admin reset – the NAS sends a Stop packet with final counters and a termination cause. Start, interims, Stop: that’s the full lifecycle of one session’s accounting.
Because this all rides on UDP, delivery is not guaranteed. The NAS retransmits until it gets an Accounting-Response, and the Acct-Delay-Time attribute tells the server how long a packet sat in the retry queue – so the server can work out the true event time even when the packet arrives late. Retransmission creates a second problem: duplicates. A server that isn’t deduplicating on Acct-Session-Id and event time will happily store the same session twice, and your usage reports will be inflated by exactly the amount of your packet loss.
Two special packet types cover equipment restarts. Accounting-On says “this NAS just booted – any sessions you have open from me are dead.” Accounting-Off is the graceful version, sent at shutdown. A AAA server that handles these correctly closes stale sessions the moment a NAS reboots. One that ignores them leaves ghost sessions on the books until someone notices.
RADIUS Accounting Packets: Start, Interim, Stop
The three main radius accounting packets all use the same message type – Accounting-Request – distinguished by the Acct-Status-Type attribute. What differs is when they’re sent and what they carry.
Start (Acct-Status-Type = 1). Sent when the session is established. It carries identity and context – username, session ID, calling station ID, the NAS and port involved, the framed IP address assigned – but no usage counters, because nothing has happened yet. The Start record is what lets you answer “who had this IP address at 02:14 on Tuesday?”, which makes it as much a security artifact as a billing one.
Interim-Update (Acct-Status-Type = 3). Sent periodically during the session, at the interval set by the Acct-Interim-Interval attribute or NAS configuration. Each interim carries cumulative totals since session start – not deltas. This trips people up in mediation logic: to compute usage between two interims, you subtract, and if the counters ever go backwards you’re looking at a NAS restart or a counter reset, not negative traffic.
Stop (Acct-Status-Type = 2). Sent at session teardown with final cumulative counters, total session time, and an Acct-Terminate-Cause explaining why the session ended – user request, idle timeout, lost carrier, admin reset, NAS reboot. Terminate causes are an underused troubleshooting signal: a spike in Lost-Carrier on one OLT tells you something an averaged dashboard won’t.
The interim interval is a genuine engineering trade-off. Set it too short – say, 60 seconds across half a million broadband sessions – and you generate an accounting flood that loads the NAS, the network, and the AAA database for little gain. Set it too long, and a lost Stop packet costs you hours of billable usage, because your last known counter is hours old. Most fixed-line operators land somewhere between 15 minutes and an hour, tuned to what a lost Stop actually costs them.
What Data Is Captured
A radius accounting record is a bundle of attributes. These are the ones a NOC engineer reads most, grouped by what they answer:
| Question | Attributes | What they tell you |
| Who? | User-Name, Calling-Station-Id | Subscriber identity and the MAC/line ID behind the session |
| Which session? | Acct-Session-Id, Event-Timestamp | Unique session key and true event time (dedup depends on both) |
| Where? | NAS-IP-Address, NAS-Identifier, NAS-Port | Which access element and port carried the session |
| What address? | Framed-IP-Address | The IP assigned to the subscriber — the IP-to-subscriber mapping |
| How much? | Acct-Input-Octets, Acct-Output-Octets, Acct-Input/Output-Packets | Traffic volume in each direction |
| How long? | Acct-Session-Time | Session duration in seconds |
| Why did it end? | Acct-Terminate-Cause | Disconnect reason (Stop packets only) |
One attribute pair deserves special attention: Acct-Input-Gigawords and Acct-Output-Gigawords. The standard octet counters are 32-bit, which means they wrap at 4 GiB – a threshold a single broadband session crosses before breakfast. The gigawords attributes (added in RFC 2869) count how many times the 32-bit counter has wrapped. Any element in your chain that ignores gigawords – an old NAS build, a hand-rolled mediation script – will report a 200 GB session as whatever’s left after the last wrap. If your heavy users mysteriously show light usage, check this first.
RADIUS Accounting in Broadband vs Mobile
In fixed broadband, RADIUS accounting is the primary usage record.
Every PPPoE or IPoE session on the BNG authenticates via RADIUS and is accounted via RADIUS. Those records drive usage-based billing, fair-usage policy triggers, and the subscriber-session visibility your NOC works from. There is no parallel charging stack quietly keeping a second copy – if the RADIUS record is wrong, the bill is wrong. That’s why broadband operators care about accounting integrity in a way that surprises engineers coming from the mobile core.
In mobile packet core, accounting largely moved on.
4G and 5G charging runs over Diameter (Rf for offline records, Gy for real-time credit control), and 5G standalone shifts to HTTP/2-based service interfaces. But RADIUS accounting hasn’t left the mobile operator’s estate – it moved to the edges. Carrier Wi-Fi and Wi-Fi offload sessions (EAP-SIM/AKA authenticated) are accounted over RADIUS. Enterprise APNs often hand off to a RADIUS server on the Gi/SGi side for per-session IP accounting. MVNO platforms frequently take RADIUS feeds for data usage.
The practical consequence: most operators run both, and the subscriber doesn’t care which stack recorded their usage. A converged AAA server that terminates RADIUS and Diameter on one platform means a fixed-line session, a Wi-Fi offload session, and a mobile data session can resolve to the same subscriber record – one place to look when the usage question comes in, instead of three.
Troubleshooting Accounting Issues
Accounting problems rarely announce themselves. They surface as billing disputes weeks later. Here are the failure patterns worth knowing before that happens, roughly in order of how often they appear:
- Stale or ghost sessions.
The Stop packet was lost, or the NAS died without sending one, and the AAA server still shows the session open. Symptoms: subscribers who can’t reconnect because they’ve hit a simultaneous-session limit, or session counts that only ever go up. Fixes: make sure Accounting-On/Off handling is actually closing sessions on NAS reboot, and run an orphan sweep that closes sessions with no interim update inside a defined window.
- Duplicate records.
UDP retransmission means duplicates are normal on the wire; they should never be normal in the database. If usage reports run consistently high, check that deduplication keys on Acct-Session-Id plus event time – not on packet arrival.
- Silently missing records.
A shared secret mismatch is the nastiest version of this: per the RFC, a packet that fails authenticator validation is dropped without a response. No error is returned to anyone. The NAS retries until it gives up, and the records simply never exist. After any secret rotation, confirm accounting is still flowing from every NAS – don’t assume.
- Backlog storms after an outage.
When a AAA server comes back after downtime, every NAS flushes its buffered accounting queue at once. If the server can’t absorb the burst, packets are dropped and retried into a spiral. Know your platform’s queue depth and ingest ceiling before you need them.
- Counters that go backwards between interims.
Almost always a NAS restart or line-card failover that reset counters mid-session. Mediation logic should treat a counter decrease as a reset event, not compute negative usage.
Three metrics catch most of this early: the start/stop ratio per NAS (should hover near 1 over time), accounting response latency, and the retransmission rate. A start/stop ratio drifting above 1 means you’re leaking Stops somewhere – and leaked Stops are leaked revenue.
RADIUS Accounting and Revenue Assurance
For usage-billed services, accounting records are the source of truth the invoice is built on. That gives every failure mode in the previous section a currency value. A lost Stop with no interims behind it is unbillable usage. Duplicate records are over-billing, which costs less in revenue than it costs in the credibility of every future bill. Under-reporting from a gigawords gap is revenue that leaks silently, on your heaviest – and often highest-value – subscribers first.
Interim updates are the cheapest revenue insurance available. If the Stop never arrives, you bill to the last interim and lose only the tail of the session, not all of it. That’s the real answer to “what interval should we set?” – work out what an average lost session-tail costs at each candidate interval, and weigh it against the accounting load. It’s a business calculation wearing an engineering hat.
Beyond billing, accounting records are the reconciliation layer. Pairing Starts with Stops per NAS, comparing RADIUS usage totals against mediation output, and auditing terminate-cause distributions will surface leakage that neither the billing team nor the NOC would find alone. Operators that treat accounting as a billing input only, rather than an auditable dataset, find discrepancies at invoice time – the most expensive possible moment.
The platform matters here too. Accounting integrity at carrier scale needs duplicate detection built in, session state that survives failover on geo-redundant pairs, and headroom for interim floods and post-outage bursts. This is the problem Alepo AAA is built for – one platform terminating RADIUS, Diameter, and TACACS+, running in production with operators including STC, Etisalat, and Telefónica. Its AI operations layer reads accounting flows in real time and flags the patterns above – start/stop drift, error spikes, backlog buildup – in plain language, before they age into billing disputes.
FAQs
Q1. What port does RADIUS accounting use?
UDP port 1813, per RFC 2866. Authentication uses 1812. Older equipment may still use the legacy ports 1646 (accounting) and 1645 (authentication) – worth checking when integrating aging NAS gear.
Q2. What’s the difference between RADIUS authentication and RADIUS accounting? Authentication decides whether a subscriber may connect and happens before the session starts. Accounting records what the subscriber did – duration, data volume, disconnect reason – during and after the session. They’re separate message flows and can even be served by different servers.
Q3. What is an interim accounting update?
A periodic Accounting-Request sent during a live session carrying cumulative usage counters. If the final Stop packet is lost, the last interim is your fallback billing record – which is why the interim interval is a revenue decision, not just a config value.
Q4. Why do long sessions show incorrect usage totals?
Usually the gigawords problem: standard octet counters are 32-bit and wrap at 4 GiB. True usage requires combining Acct-Input/Output-Gigawords with the octet counters. If any system in the chain ignores gigawords, large sessions under-report.
Q5. Is RADIUS accounting still used in 5G networks?
The 5G packet core charges over service-based interfaces and Diameter, not RADIUS. But RADIUS accounting remains standard in fixed broadband, carrier Wi-Fi, Wi-Fi offload, and many enterprise and MVNO integrations – so operators run it alongside newer stacks rather than instead of them.
Conclusion
Pull last month’s start/stop ratio per NAS. If it’s drifting above 1, you’re leaking Stop packets, and unbilled sessions with them.
RADIUS accounting is the foundation of accurate billing. Alepo’s carrier-grade AAA server captures every session record in real time and syncs it with your BSS, policy, and quota systems – no leakage, no reconciliation headaches.
Book a demo now.
