Baru Tahu RB util tinggi dan Congestion Itu berbeda dan Cara Deteksinya

 RB Util tinggi tidak otomatis congestion

Congestion terjadi jika RB habis di TTI tertentu dan user tidak kebagian resource

Congestion

Masalah jangka pendek & dinamis

Ciri-ciri:

• RB utilization spike

• Terjadi di jam sibuk

• Banyak user aktif bersamaan

• KPI terdampak:

  • Throughput drop

  • Latency naik

  • BLER / retransmission naik

Analogi:

Jalan tol lancar, tapi tiap jam 5 sore macet total

---

Capacity Issue

Masalah struktural / desain jaringan

Ciri-ciri:

• RB utilization tinggi terus

• Hampir selalu >80–90%

• Cell tidak punya headroom

• Masalah muncul saat traffic naik sedikit saja

Analogi:

Jalan tol sudah penuh 24 jam, tapi masih jalan

Kalau yang terjadi :

Congestion → Optimization problem, maka atur ini

• load balancing

• traffic steering

• parameter tuning

Capacity issue → Planning problem, maka atur ini

• tambah carrier

• tambah spectrum

• small cell / new site

Cara Mendeteksi Congestion dari OSS Data

A. KPI Utama yang Wajib Dicek

1. PRB / RB Utilization (%)

KPI paling dasar tapi sering disalahartikan

Indikasi congestion:

• PRB DL > 80–85% secara konsisten

• Ada spike ke 95–100% di jam sibuk (busy hour)

• Pola tidak stabil (fluktuatif)

📌 Catatan penting:
PRB tinggi tanpa KPI lain memburuk ≠ congestion

---

2. DL Throughput per User

Ini KPI yang langsung dirasakan user

Indikasi congestion:

• Cell throughput tinggi

• Tapi average UE throughput turun

• Contoh:

  • Cell DL throughput: 150 Mbps

  • UE throughput: 2–5 Mbps

➡️ Artinya RB habis dibagi terlalu banyak user

---

3. Active User / RRC Connected UE

Congestion sering dipicu jumlah user

Indikasi:

• Active UE tinggi di jam sibuk

• UE meningkat → throughput per user drop

Rule kasar:

• LTE 20 MHz mulai kritis di >80–100 UE aktif

• 5G tergantung bandwidth & MIMO, tapi prinsip sama

---

4. Scheduling / Resource Rejection KPI

Tergantung vendor (nama beda-beda):

Contoh:

• DL Scheduling Fail

• DL Resource Allocation Fail

• PRB Exhaustion Counter

Jika ada counter “resource denied” → itu congestion nyata

---

5. Latency & HARQ Retransmission

Congestion tidak selalu kelihatan di PRB saja

Ciri:

• DL latency naik

• HARQ retransmission rate naik

• BLER meningkat

➡️ Scheduler terpaksa kirim ulang karena resource sempit

Workflow Deteksi Congestion (Step by Step)

Step 1

Ambil OSS KPI Busy Hour (BH)
➡️ jangan average harian

Step 2

Filter cell:

• PRB DL > 80%

• UE aktif tinggi

Step 3

Cross-check:

• UE throughput turun?

• Scheduling fail ada?

• Latency naik?

➡️ Jika iya semua → congestion confirmed

---

Cara Mengatasi Congestion (Berjenjang)

A. Solusi Cepat (Optimization – Tanpa CAPEX)

1️⃣ Load Balancing

• Arahkan user ke neighbor yang lebih kosong

• Adjust:

  • Cell reselection

  • HO offset

  • MLB parameter

📌 Cocok jika:

• Ada cell tetangga low load

---

2️⃣ Traffic Steering / Carrier Load Sharing

• Dorong UE ke:

  • Band lebih tinggi

  • 5G NR

  • Secondary carrier (CA)

📌 Contoh:

• Dari LTE 1800 → LTE 2100

• Dari LTE → NR NSA

---

3️⃣ Scheduler & Feature Optimization

• Adjust:

  • Proportional Fair

  • QoS prioritization

  • MIMO layer usage

📌 Dampak cepat, tapi ada limit

---

B. Solusi Menengah (Semi-CAPEX)

4️⃣ Carrier Aggregation

• Gabungkan 2–3 carrier

• Naikkan bandwidth efektif

📌 Sangat efektif untuk hotspot area

---

5️⃣ Antenna Optimization

• Tilt optimization

• Azimuth adjustment

• Reduce overshooting cell

📌 Kurangi user “jauh” yang makan resource

---

C. Solusi Permanen (CAPEX)

6️⃣ Tambah Bandwidth / Spectrum

• Dari 10 → 20 MHz

• Dari 40 → 100 MHz (5G)

📌 Solusi paling clean tapi mahal

---

7️⃣ Small Cell / New Site

• Untuk hotspot:

  • Mall

  • Stadium

  • CBD

📌 Turunkan UE per cell

---

Kaitan dengan Planning Tool (Planet / ACP)

OSS dipakai untuk:

• Deteksi congestion area

• Validasi hasil planning

Lalu:

• ACP → optimasi parameter otomatis

• Planet → simulasi coverage & capacity impact