Traffic Intensity: Erlangs, CCS, and Minutes Explained

> **Quick Answer:** Traffic intensity measures circuit utilization. One Erlang = one circuit continuously occupied for one hour. Calculate it as: A = (Calls per hour × Average duration in seconds) / 3600.


Traffic intensity is the single most important number in telecom capacity planning. Get it right and every other calculation — trunk lines, agent count, Grade of Service — follows. Get it wrong and your entire network plan is built on a flawed foundation.

Here's a thorough explanation of what traffic intensity is, how it's measured, and what the different units mean.

What Is Traffic Intensity?

Traffic intensity (also called traffic load or offered traffic) measures how busy a group of circuits or servers is during a given period. It represents the average number of concurrent calls or sessions that are in progress at any moment.

If your office has 10 phone lines and they're all busy 30% of the time on average, your traffic intensity is 3 Erlangs. If they're all busy all the time, you have 10 Erlangs. Traffic intensity is dimensionless — it's a ratio of actual usage to maximum possible usage.

The Erlang: The Standard Unit

The **Erlang** (abbreviated E or erl) is named after Agner Krarup Erlang, the Danish mathematician who developed traffic engineering theory while working at the Copenhagen Telephone Exchange in the early 1900s. His 1917 paper established the mathematical framework that still underpins modern telecom capacity planning.

**One Erlang = one circuit occupied continuously for one hour.**

More precisely, it's the occupancy that would result from one continuous call lasting one full hour. Since real calls are shorter, you reach one Erlang when enough shorter calls collectively occupy a circuit for the full hour.

**The formula:**

**A = (λ × h) / 3600**

Where:

- A = traffic intensity in Erlangs

- λ = call arrival rate (calls per hour)

- h = average call duration (seconds)

- 3600 = seconds in one hour

**Example:** 720 calls per hour, average duration 150 seconds:

A = (720 × 150) / 3600 = **30 Erlangs**

Other Traffic Intensity Units

CCS — Centum Call Seconds

CCS (Centum Call Seconds) is a unit used primarily in North American telephony, especially in older carrier documentation and some PBX systems. "Centum" means 100, so 1 CCS = 100 call-seconds of traffic.

**Conversion:** 1 Erlang = 36 CCS

The relationship: 1 Erlang = 1 circuit busy for 3600 seconds = 3600 call-seconds = 36 × 100-second units = 36 CCS.

If a trunk group carries 18 Erlangs, that's also 648 CCS.

CCS was the dominant unit in Bell System documentation and remains common in legacy PBX systems, older tariff structures, and some CDR reports from equipment made before 2000. If you see traffic reported in CCS, divide by 36 to get Erlangs.

Minutes of Use (MOU)

Telephone carriers often report traffic in Minutes of Use — the total minutes of calls carried in a period. This is not the same as traffic intensity, because it doesn't account for concurrency.

**Conversion from MOU to Erlangs:**

If a trunk group carries 1,800 minutes of use in one hour, that's 1,800/60 = **30 Erlangs**.

MOU is useful for billing and capacity invoicing but doesn't directly answer "how many circuits do I need?"

Busy Hour Traffic vs. Total Traffic

Traffic intensity is always measured over a specific time period. For capacity planning, you use **busy hour traffic** — the intensity during the single highest-traffic hour.

Total daily traffic in Erlangs is meaningless for sizing circuits. A system that carries 8 Erlangs on average over 10 hours has handled 80 Erlang-hours of total traffic, but if the busy hour hit 20 Erlangs, you'd need circuits to handle that peak, not the average.

Why Traffic Intensity Alone Isn't Enough

Knowing you have 30 Erlangs of traffic doesn't tell you how many circuits you need. That depends on your Grade of Service target — how much blocking or delay you're willing to accept.

At 30 Erlangs with a P.02 (2% blocking) target using Erlang B, you need **38 trunk lines**.

But if your Grade of Service target is P.01 (1% blocking), you need **40 trunk lines**.

And if you're using Erlang C for a call center with 30 Erlangs of traffic and a 80/20 service level target, you need **38–40 agents** depending on your AHT.

Traffic intensity is the input; the Erlang formulas take it from there. Use our [Erlang calculator](/erlang-calculator) to run any of these scenarios. Our [grade of service standards guide](/blog/grade-of-service-standards) explains how to pick the right blocking probability target for your application.

Interpreting Traffic Intensity Reports from Your PBX

Most modern PBX systems and CDR (Call Detail Record) analyzers can report traffic intensity. Here's how to read the numbers:

**Average busy circuits:** This is your traffic intensity in Erlangs for the measurement interval. If your system shows "average busy circuits: 12.4" during the 10 AM hour, your busy-hour traffic intensity is 12.4 Erlangs.

**Peak concurrent calls:** This is the maximum number of simultaneous calls observed, not the average. Peak concurrent calls are always higher than Erlangs. With 12.4 Erlangs, you might see a peak concurrency of 18–20 calls. Don't size your trunks to the peak concurrent number — that would massively overprovision. Use Erlangs.

**Offered vs. carried traffic:** Offered traffic is what callers try to send; carried traffic is what your circuits actually handled. If you're already blocking calls, offered > carried. Your Erlang calculations should be based on **offered** traffic — what customers are attempting — not carried traffic, which is limited by your current capacity.

Practical Rule of Thumb

For initial estimates, a simple rule: you need roughly **20–30% more circuits than your traffic intensity in Erlangs** to achieve a 2% blocking rate. So 30 Erlangs needs roughly 37–39 trunks. The exact number depends on your Grade of Service target — always run the Erlang B formula for accurate results rather than relying on rules of thumb.

For more on how this feeds into full network planning, our [peak hour traffic planning guide](/blog/peak-hour-traffic-planning) covers how to extract and use busy-hour data from real systems.