Belajar Telecom Engineer - Telecom Capacity & Dimensioning

#Pendahuluan

Setelah di episode 11 kita menguasai siklus optimasi — KPI, drive test, dan countermeasure berbasis data — ada batas yang tidak bisa diatasi tuning apa pun: kapasitas. Ketika semua cell di satu area sudah penuh, optimasi hanya memindahkan kemacetan; yang dibutuhkan adalah dimensioning — ilmu menghitung seberapa besar jaringan harus dibangun.

Mengapa dimensioning krusial? Karena ia adalah pertemuan antara teknik dan uang. Terlalu kecil → pelanggan marah karena sibuk/lambat. Terlalu besar → operator membakar CAPEX untuk resource yang tidur. Engineer yang bisa menunjukkan dengan angka "site X butuh carrier tambahan pada Q3" memberi nilai bisnis langsung.

#Busy Hour dan Erlang

#Trafik Tidak Merata

Trafik telekomunikasi punya pola harian: lembah dini hari, puncak malam (untuk residential) atau tengah hari (business district). Semua perencanaan dilakukan terhadap busy hour — jam tersibuk. Mengukur rata-rata harian untuk dimensioning adalah kesalahan fatal: jaringan hidup atau mati di jam puncaknya.

#Erlang: Unit Trafik

Satu Erlang = satu sirkuit/sumber daya dipakai penuh selama satu jam. Rumus dasarnya:

A [Erlang] = λ [panggilan/jam] × h [durasi rata-rata dalam jam]

Contoh: 300 panggilan per jam × 120 detik (0,0333 jam) = 10 Erlang offered traffic.

#Erlang B: Sistem Tanpa Antrian

Untuk suara (panggilan ditolak jika penuh — bukan antri), probabilitas blocking dihitung formula Erlang B:

B(A, N) = (A^N / N!) / Σ(k=0..N) A^k / k!

dengan N = jumlah channel. Grade of Service (GoS) tipikal: blocking ≤ 2% (suara). Mari kita hitung dengan Python:

import math
 
def erlang_b(a: float, n: int) -> float:
    inv_b = 1.0
    for k in range(1, n + 1):
        inv_b = 1.0 + k / a * inv_b
    return 1.0 / inv_b
 
# Kasus: BTS GSM 2 TRX (15 TCH), target blocking <= 2%
channels, gos_target = 15, 0.02
 
a_low, a_high = 0.1, 30.0
for _ in range(100):                      # binary search offered traffic
    mid = (a_low + a_high) / 2
    if erlang_b(mid, channels) > gos_target:
        a_high = mid
    else:
        a_low = mid
 
print(f"{channels} channel @ GoS {gos_target:.0%} → {a_low:.1f} Erlang")

Hasilnya sekitar 9,4 Erlang: 15 channel melayani ±282 panggilan busy-hour (9,4 × 3600/120 detik) dengan blocking maksimum 2%. Inilah cara engineer menjawab "berapa pelanggan muat di satu TRX?" dengan angka, bukan firasat.

#Erlang C: Sistem Dengan Antrian

Untuk call center atau data buffering (paket menunggu slot), pakai Erlang C: probabilitas caller harus menunggu. Prinsip pentingnya: sistem antrian membuang lebih sedikit kapasitas daripada sistem blocking — intuisi kenapa packet switching menang efisiensi atas circuit switching.

#Dimensioning Cell LTE/5G

Radio modern tidak lagi pakai channel tetap, melainkan resource block dinamis. Pendekatan dimensioning-nya:

Kapasitas cell = BW × throughput_spectral × efisiensi_load
Demand         = subscribers × penetration_busy × avg_demand_user

Langkah konkret contoh: satu sector LTE 20 MHz, MIMO 2×2:

Jika cluster punya 600 subscriber aktif busy hour di area itu... hitungan cepat: dibutuhkan ±46 "slot" — artinya minimal 4 carrier/sector gabungan antar-band. Kesimpulan engineering: tambah carrier band lain, atau small cell, atau offload.

#Praktik: Dimensioning Cluster dengan Python

Mari bungkus logika dimensioning jadi skrip yang bisa dipresentasikan ke manajemen:

def cell_capacity_mbps(bw_mhz: float, sp_eff: float, load: float) -> float:
    return bw_mhz * 1e6 * sp_eff * load / 1e6
 
def demand_users(active_subs: int, share_busy: float,
                 avg_mbps: float) -> float:
    return active_subs * share_busy * avg_mbps   # total Mbps diminta
 
# Input cluster: 3 site × 3 sector, LTE 20 MHz + NR n78 60 MHz TDD
sectors          = 9
cap_lte          = cell_capacity_mbps(20, 1.8, 0.70)
cap_nr           = cell_capacity_mbps(60 * 0.74, 4.0, 0.70)  # DL duty ~74%
total_capacity   = sectors * (cap_lte + cap_nr)
 
active_subs      = 4200
demand           = demand_users(active_subs, 0.35, 2.0)
 
print(f"Kapasitas cluster : {total_capacity:,.0f} Mbps")
print(f"Demand busy hour  : {demand:,.0f} Mbps")
print(f"Headroom          : {(1 - demand/total_capacity)*100:.1f}%")
 
# Trigger ekspansi industri umum: PRB util > 70% atau headroom < 25%
print("PERLU EKSPANSI" if demand / total_capacity > 0.75 else "AMAN")

Skrip semacam ini — dengan asumsi tertulis jelas — adalah artefak yang benar-benar dipakai tim planning operator saat menyusun budget tahunan.

#Backhaul & Core Ikut Di-dimensioning

Kapasitas tidak berhenti di udara:

• Backhaul: agregasi peak site × koefisien statistik (~0.7-0.8 karena tak semua site peak bersamaan).
• Core/UPF: throughput session + signaling rate (registrasi/paging) — signaling sering jadi bottleneck lebih dulu di event masif (stadion, new year).
• Interconnect internet: provision berdasar 95th percentile billing, bukan peak sesaat.

#Common Pitfalls

• Dimensioning dari average, bukan busy hour: hasilnya jaringan "cukup" 23 jam dan kolaps 1 jam — persis jam keluhan melimpah.
• Memakai peak rate marketing sebagai demand: paket 100 Mbps ≠ demand 100 Mbps per user; gunakan data pemakaian aktual (median biasanya 2-5 Mbps).
• Lupa growth curve: rencana tanpa proyeksi 24-36 bulan akan usang sebelum ramp-up selesai; sertakan CAGR trafik historis.

#Penutup

Inti yang harus dibawa pulang:

• Semua perhitungan kapasitas dilakukan terhadap busy hour, dengan unit Erlang.
• Erlang B untuk sistem blocking (suara), Erlang C untuk antrian — dan kalian bisa menghitung keduanya dengan Python.
• Dimensioning radio modern = BW × throughput spectral × load vs demand pengguna nyata.
• Kapasitas harus konsisten di tiga titik: udara, backhaul, core.

Di episode 13 kita masuk fitur paling ikonik 5G: network slicing & QoS — bagaimana satu jaringan fisik melayani banyak jaringan virtual dengan SLA berbeda, dan cara mengkonfigurasinya. Sampai jumpa!