1.2 Capacity Planning, Sizing & Bandwidth Considerations

1.2 Capacity Planning, Sizing & Bandwidth Considerations

Designing enterprise voice and video networks requires rigorous mathematical modeling of telecommunications traffic and granular analysis of packet-level encapsulation overhead. Collaboration engineers must accurately forecast concurrent session volume, determine PSTN and SIP trunk requirements, and allocate adequate Quality of Service (QoS) bandwidth across wide area network links.

---

1. Telephony Traffic Engineering: Erlang Models & BHCA

Telecommunications capacity planning quantifies user calling behavior during the most heavily utilized period of the business day: the Busy Hour.

Core Traffic Metrics

• Busy Hour Call Attempts (BHCA): The total number of call setup attempts (both answered and unanswered) initiated during the peak 60-minute traffic window.
• Holding Time ($H$): The average call duration in seconds, measuring the period a trunk or audio channel remains engaged.
• Erlang ($E$): The dimensionless international standard unit of telecommunications traffic intensity. One Erlang represents continuous utilization of one voice channel for one hour (3,600 call-seconds).
• Centum Call Seconds (CCS): Unit representing 100 call-seconds of traffic. Since one hour contains 3,600 seconds:

$1 \text{ Erlang} = 36 \text{ CCS}$

Traffic intensity in Erlangs is calculated using the formula:

$E = \frac{\text{BHCA} \times H}{3600}$

Example Calculation: If an office generates 1,200 BHCA with an average holding time of 180 seconds:

$E = \frac{1200 \times 180}{3600} = \frac{216000}{3600} = 60 \text{ Erlangs}$

Erlang B vs. Erlang C Traffic Models

Selecting the correct Erlang distribution model depends on how the underlying telecommunications system handles blocked traffic during peak hours:

Grade of Service (GoS)

Grade of Service expresses the probability ($P$) that a call attempt will be blocked due to insufficient trunk capacity during the busy hour. Common enterprise engineering thresholds include:

• P.01 (1% blocking): Standard commercial enterprise trunking design. Out of 100 call attempts, no more than 1 will encounter a busy tone.
• P.001 (0.1% blocking): Mission-critical or emergency response trunking design.

---

2. Voice Packet Overhead & Bandwidth Calculation

A Voice over IP (VoIP) stream consists of digitized voice samples packed into RTP packets, encapsulated across UDP, IP, and the underlying data link layer.

Protocol Encapsulation Breakdown

+-----------------------------------------------------------------------------------------+
|                                 ETHERNET VoIP PACKET                                    |
+-----------------------+-------------------+------------------+---------------+----------+
| Layer 2 Frame Header  | IPv4 Header       | UDP Header       | RTP Header    | Audio    |
| Dest MAC + Src MAC +  | 20 Bytes          | 8 Bytes          | 12 Bytes      | Payload  |
| Type + 4-byte FCS     | (40 B for IPv6)   |                  |               | (e.g.,   |
| = 18 Bytes            |                   |                  |               | 160 B)   |
+-----------------------+-------------------+------------------+---------------+----------+
|                       |<------------------ 40-BYTE L3/L4/RTP --------------->|          |
|<--------------------------- TOTAL PACKET SIZE: 218 BYTES ------------------------------>|

1. Layer 2 Ethernet Overhead: Ethernet II framing adds a 14-byte header (6-byte destination MAC + 6-byte source MAC + 2-byte EtherType) and a 4-byte Frame Check Sequence (FCS) trailer, totaling 18 bytes of data-link overhead. Where an 802.1Q VLAN tag is present (for example, on a trunk link), it adds 4 more bytes for 22 bytes; G.711 at 20 ms then needs 88.8 kbps instead of 87.2 kbps.
2. Layer 3 IPv4 Header: Standard IPv4 header without options consumes 20 bytes (IPv6 consumes 40 bytes).
3. Layer 4 UDP Header: User Datagram Protocol consumes 8 bytes.
4. Real-time Transport Protocol (RTP) Header: Standard RTP header consumes 12 bytes.

Total combined IP/UDP/RTP header overhead at Layer 3 and Layer 4:

$\text{Header Overhead} = 20 \text{ (IP)} + 8 \text{ (UDP)} + 12 \text{ (RTP)} = 40 \text{ bytes}$

Packetization Interval and Packet Rate

VoIP endpoints sample analog signals and package them at fixed transmission intervals (packetization intervals), most commonly 20 ms (50 packets per second), 10 ms (100 packets per second), or 30 ms (33.33 packets per second):

$\text{Packets Per Second (pps)} = \frac{1}{\text{Packetization Interval (seconds)}}$

$\text{Voice Payload (bytes)} = \frac{\text{Codec Bitrate (bps)} \times \text{Packetization Interval (s)}}{8 \text{ bits/byte}}$

Example (G.711 at 20 ms):

$\text{Voice Payload} = \frac{64000 \times 0.020}{8} = 160 \text{ bytes}$

Example (G.729 at 20 ms):

$\text{Voice Payload} = \frac{8000 \times 0.020}{8} = 20 \text{ bytes}$

Calculating Bitrates

• Layer 3 Packet Size: $\text{Payload Bytes} + 40 \text{ bytes}$
• Layer 3 Bandwidth (bps): $\text{L3 Packet Size (bytes)} \times 8 \text{ bits/byte} \times \text{pps}$
• Layer 2 Frame Size: $\text{L3 Packet Size} + 18 \text{ bytes}$ (untagged Ethernet; add 4 bytes for 802.1Q)
• Layer 2 Bandwidth (bps): $\text{L2 Frame Size (bytes)} \times 8 \text{ bits/byte} \times \text{pps}$

---

3. Audio Codec Bandwidth Comparison

The following table details packet dimensions and bandwidth requirements for prominent enterprise codecs across standard Ethernet infrastructure:

Header Compression Note: Compressed RTP (cRTP, RFC 2508) compresses the 40-byte IP/UDP/RTP header down to 2 or 4 bytes over point-to-point serial WAN links (such as T1/E1 PPP/HDLC). However, cRTP is CPU-intensive and is not supported across standard Ethernet, MPLS, or IPsec encapsulated tunnels.

---

4. Video Bandwidth Requirements: H.264 AVC vs. H.265 HEVC

Video endpoints generate variable bitrate (VBR) or constrained bitrate (CBR) RTP streams that consume significantly greater bandwidth than voice streams.

Video Resolution and Bandwidth Matrix

Architectural Efficiency: H.264 vs. H.265

High Efficiency Video Coding (H.265 / HEVC) delivers approximately 40% to 50% bandwidth savings over H.264 Advanced Video Coding (AVC) at equivalent subjective visual quality:

• Block Partitioning: H.264 relies on rigid $16 \times 16$ pixel macroblocks. H.265 replaces macroblocks with flexible Coding Tree Units (CTUs) ranging up to $64 \times 64$ pixels, allowing efficient compression of expansive background regions.
• Intra-Prediction Precision: H.264 uses up to 9 intra-prediction modes (for 4x4 luma blocks); H.265 defines 35 (33 angular plus planar and DC), which predicts detail more accurately and leaves less residual to encode.
• Network Impact: Upgrading video endpoints to H.265 enables enterprises to route 1080p30 video over WAN links provisioned for 1.8 Mbps rather than 3.5 Mbps.

---

5. Step-by-Step Worked Bandwidth Calculation

Problem Statement

An enterprise branch office connects to corporate headquarters across an MPLS WAN. The branch requires concurrent capacity for 100 active voice calls.

• Calculate the required Layer 2 Ethernet WAN bandwidth for 100 concurrent G.711 calls at 20 ms packetization.
• Calculate the required Layer 2 Ethernet WAN bandwidth for 100 concurrent G.729 calls at 20 ms packetization.
• Factor in a 5% signaling buffer (SIP and RTCP) and a 20% QoS Low Latency Queuing (LLQ) headroom reserve to determine the final provisioned Priority Queue size.

Step-by-Step Solution

Part A: Sizing for 100 G.711 Calls (20 ms)

1. Determine Payload: G.711 produces 64,000 bps. Over 20 ms, payload is: $\frac{64000 \times 0.020}{8} = 160 \text{ bytes}$
2. Calculate L3 Packet Size: Add 40 bytes for IP/UDP/RTP headers: $160 + 40 = 200 \text{ bytes}$
3. Calculate L2 Frame Size: Add 18 bytes of untagged Ethernet overhead: $200 + 18 = 218 \text{ bytes}$
4. Calculate Single Call L2 Bitrate: At 50 packets per second: $218 \text{ bytes} \times 8 \text{ bits/byte} \times 50 \text{ pps} = 87,200 \text{ bps} = 87.2 \text{ kbps}$
5. Aggregate Media Bandwidth (100 Calls): $100 \times 87.2 \text{ kbps} = 8,720 \text{ kbps} = 8.72 \text{ Mbps}$
6. Add 5% Signaling (SIP/RTCP): $8.72 \text{ Mbps} \times 1.05 = 9.156 \text{ Mbps}$
7. Apply 20% QoS Headroom Safety Margin: $9.156 \text{ Mbps} \times 1.20 = 10.987 \text{ Mbps} \approx 11.0 \text{ Mbps}$

Part B: Sizing for 100 G.729 Calls (20 ms)

1. Determine Payload: G.729 produces 8,000 bps. Over 20 ms, payload is: $\frac{8000 \times 0.020}{8} = 20 \text{ bytes}$
2. Calculate L3 Packet Size: Add 40 bytes for IP/UDP/RTP headers: $20 + 40 = 60 \text{ bytes}$
3. Calculate L2 Frame Size: Add 18 bytes of untagged Ethernet overhead: $60 + 18 = 78 \text{ bytes}$
4. Calculate Single Call L2 Bitrate: At 50 packets per second: $78 \text{ bytes} \times 8 \text{ bits/byte} \times 50 \text{ pps} = 31,200 \text{ bps} = 31.2 \text{ kbps}$
5. Aggregate Media Bandwidth (100 Calls): $100 \times 31.2 \text{ kbps} = 3,120 \text{ kbps} = 3.12 \text{ Mbps}$
6. Add 5% Signaling (SIP/RTCP): $3.12 \text{ Mbps} \times 1.05 = 3.276 \text{ Mbps}$
7. Apply 20% QoS Headroom Safety Margin: $3.276 \text{ Mbps} \times 1.20 = 3.931 \text{ Mbps} \approx 3.93 \text{ Mbps}$

Summary of Results

Transitioning 100 concurrent calls from G.711 to G.729 reduces the required priority queue allocation from 11.0 Mbps down to 3.93 Mbps, generating an immediate WAN bandwidth conservation of 64.2%.