Signaling Performance Under High Call Volume: Erlang C vs Erlang B
Signaling performance under heavy call volumes is a recurring concern for Australian carriers and contact-centre operators, especially around the AFL Grand Final and Boxing Day sales, when trunk groups across Sydney, Melbourne, and Brisbane see sudden spikes. Choosing between Erlang B and Erlang C is rarely a matter of preference — it depends on whether the system can queue calls or must reject them outright.
Both formulas trace back to the work of A. K. Erlang at the Copenhagen Telephone Company in the early 1900s and remain the starting point for traffic engineering today. They convert traffic intensity, measured in erlangs, into the number of circuits or agents needed to hit a target grade of service, and the distinction matters because call setups carried over SS7 or modern SIP trunks have different expectations for a busy signal versus a short hold-in-queue.
Foundations of Erlang's Traffic Models
A. K. Erlang, working at the Copenhagen Telephone Company, studied how a finite pool of circuits handled random call arrivals and derived two related but functionally distinct formulas from his observations: one for systems where excess calls are blocked, and another where excess calls wait in a queue. The maths behind each assumes Poisson-distributed arrivals and exponentially distributed holding times — assumptions that still hold well for voice traffic on PSTN switches and SS7-controlled trunk groups across regional Australian exchanges.
Erlang's assumptions are imperfect for data-heavy traffic, which behaves less predictably. Yet for circuit-switched voice and ISUP message flows the models remain dependable, which is why universities offering telecommunications degrees in Melbourne and Adelaide still cite Erlang when teaching fundamental capacity planning.
Erlang B and Trunk Blocking Behaviour
Erlang B describes a lost-call-cleared system: when all trunks in a group are busy, the next caller hears congestion tone and the call is dropped from the queue immediately. The formula expresses the probability of blocking as a function of offered traffic and the number of circuits. For a carrier provisioning a voice trunk group between two SS7-capable tandems in Brisbane and Sydney, Erlang B tells the planner how many DS0 or voice channels must be lit to keep blocking under one percent during a weekday morning rush.
The model assumes the caller retries later or abandons entirely, which makes it well suited to outbound PSTN gateways, emergency services interconnects, and signaling links where queueing would distort timing. Engineers studying ANSI vs ITU-T formats often find that national variants require tighter blocking targets because MTP3 retransmissions behave differently across the two standards.
Erlang C and Queue Waiting Behaviour
Erlang C is the choice when calls that arrive at a full trunk group are placed in an infinite queue and answered in order. It is the workhorse model for contact-centre staffing in Australian banks, government services such as the Services Australia hotline, and large retailers running campaigns out of Perth warehouses. The formula targets a service-level goal — typically the fraction of calls answered within a threshold such as 20 or 30 seconds.
The trade-off is that Erlang C assumes patient callers, which is rarely true during high-volume incidents such as a summer storm knocking out mobile coverage along the eastern seaboard. Practitioners address this by blending Erlang C with abandonment curves to model realistic behaviour. Its strength is sensitivity to agent count: small changes in headcount produce noticeable shifts in predicted wait times, which is why the model is so widely used in Australian outsourcers' weekly planning.
| Criterion | Erlang B | Erlang C |
|---|---|---|
| Behaviour on full system | Block (caller drops) | Queue (caller waits) |
| Typical application | PSTN trunk groups, SS7 interconnects, SIP trunk sizing | Contact-centre staffing, inbound service queues |
| Key input | Number of circuits, offered traffic | Agents, offered traffic, target service level |
| Output | Blocking probability (GoS) | Probability of waiting, average delay |
| Caller assumption | No retry or infinite patience | Patient, ordered handling |
| Sensitivity | Sharp rise near capacity | Smooth reduction in wait time as agents rise |
Combining Both Formulas in Signaling Design
Signaling engineers rarely treat the two formulas as rivals. Erlang B is more appropriate when sizing the bearer channels that carry voice, including ISUP circuits set up through MTP3 over an SS7 network. Erlang C is more appropriate when sizing the agents or automated attendants that answer inbound calls, which often sit behind a SIP gateway fronted by an SBC.
In a hybrid Australian deployment — a national retailer with a contact-centre hub in Sydney routing through an SBC in Melbourne, for example — both calculations feed the design. The bearer side is sized with Erlang B to meet an acceptable blocking target, while the agent side is sized with Erlang C to meet an average-speed-of-answer target. Mismatching them leads to familiar issues: queues forming on the bearer side because channels were under-provisioned, or trunks left idle because the agent pool was too small.
Modern IP Workloads and the Limits of Each Formula
Modern IP-based voice platforms complicate the picture. SIP trunks and WebRTC clients do not always respect the strict Poisson assumptions of either formula, and codecs such as Opus behave differently across nbn fibre, wireless, and satellite links servicing remote mines in Western Australia. Engineers continue to lean on Erlang B for SIP trunk sizing because congestion behaviour is acceptable to model as blocking once a carrier's core rejects the INVITE.
For interactive workloads such as IVR menus or AI-driven answering services, Erlang C remains useful even where calls originate over SIP. The model adapts well to mixed digital-and-voice queues, which is why Australian outsourcers serving major banks and telcos keep spreadsheets based on it. Where the two formulas converge is in hybrid cloud contact centres where the platform provider publishes results based on Erlang variants or on simulation; a pragmatic engineer reads both outputs and layers in real measurements from production logs.
Validating Outputs With Production Data
A reliable capacity plan rarely depends on one formula alone. Engineers validate Erlang B outputs against SS7 traffic traces drawn from the live network, while tuning Erlang C staffing tables with historic abandonment data captured from the same trunks. Documenting each assumption — particularly the assumed average holding time — keeps results honest when traffic shifts between school holidays and the lead-up to Christmas in Australian retail queues.
Comparing model output to actual busy-hour call records is the most reliable check available. Where the two diverge, planners usually revisit the offered-traffic figure before assuming the model itself is wrong. Teams that package their capacity rules into reusable templates — like the approach shown in Grails plugin references — make it easier to regenerate the plan whenever traffic assumptions shift.
The most useful point to take away is that the choice between Erlang B and Erlang C is dictated by what happens to the blocked call: dropped on a bearer trunk, or queued in front of an agent. Once that outcome is fixed, the formula follows naturally, and signalling performance under high call volume becomes a matter of clean arithmetic rather than guesswork.
