Ilmu Planning Optim Telekomunikasi
رفتن به کانال در Telegram
membahas segala ilmu radio planning dan optim jaringan telekomunikasi. https://lynk.id/npotelekom
نمایش بیشتر1 542
مشترکین
اطلاعاتی وجود ندارد24 ساعت
-17 روز
-1330 روز
در حال بارگیری داده...
کانال‌های مشابه
ابر برچسب‌ها
هیچ داده‌ای
مشکلی وجود دارد؟ لطفاً صفحه را تازه کنید یا با مدیر پشتیبانی ما تماس بگیرید.
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
ژوئن '25ژوئن '25
ژوئن '25
+7
در 0 کانال‌ها
مه '25
+12
در 0 کانال‌ها
Get PRO
آوریل '25
+63
در 0 کانال‌ها
Get PRO
مارس '25
+9
در 0 کانال‌ها
Get PRO
فوریه '25
+11
در 0 کانال‌ها
Get PRO
ژانویه '25
+7
در 0 کانال‌ها
Get PRO
دسامبر '24
+10
در 0 کانال‌ها
Get PRO
نوامبر '24
+12
در 0 کانال‌ها
Get PRO
اکتبر '24
+10
در 0 کانال‌ها
Get PRO
سپتامبر '24
+13
در 0 کانال‌ها
Get PRO
اوت '24
+13
در 0 کانال‌ها
Get PRO
ژوئیه '24
+12
در 0 کانال‌ها
Get PRO
ژوئن '24
+16
در 0 کانال‌ها
Get PRO
مه '24
+25
در 0 کانال‌ها
Get PRO
آوریل '24
+10
در 0 کانال‌ها
Get PRO
مارس '24
+12
در 0 کانال‌ها
Get PRO
فوریه '24
+17
در 0 کانال‌ها
Get PRO
ژانویه '24
+31
در 0 کانال‌ها
Get PRO
دسامبر '23
+16
در 0 کانال‌ها
Get PRO
نوامبر '23
+12
در 0 کانال‌ها
Get PRO
اکتبر '23
+17
در 0 کانال‌ها
Get PRO
سپتامبر '23
+9
در 0 کانال‌ها
Get PRO
اوت '23
+15
در 0 کانال‌ها
Get PRO
ژوئیه '23
+11
در 0 کانال‌ها
Get PRO
ژوئن '23
+10
در 0 کانال‌ها
Get PRO
مه '23
+16
در 0 کانال‌ها
Get PRO
آوریل '23
+15
در 0 کانال‌ها
Get PRO
مارس '23
+16
در 0 کانال‌ها
Get PRO
فوریه '23
+14
در 0 کانال‌ها
Get PRO
ژانویه '23
+31
در 0 کانال‌ها
Get PRO
دسامبر '22
+9
در 0 کانال‌ها
Get PRO
نوامبر '22
+19
در 0 کانال‌ها
Get PRO
اکتبر '22
+41
در 0 کانال‌ها
Get PRO
سپتامبر '22
+23
در 0 کانال‌ها
Get PRO
اوت '22
+32
در 0 کانال‌ها
Get PRO
ژوئیه '22
+18
در 0 کانال‌ها
Get PRO
ژوئن '22
+18
در 0 کانال‌ها
Get PRO
مه '22
+14
در 0 کانال‌ها
Get PRO
آوریل '220
در 0 کانال‌ها
Get PRO
مارس '22
+5
در 0 کانال‌ها
Get PRO
فوریه '22
+10
در 0 کانال‌ها
Get PRO
ژانویه '22
+19
در 0 کانال‌ها
Get PRO
دسامبر '21
+13
در 0 کانال‌ها
Get PRO
نوامبر '21
+13
در 0 کانال‌ها
Get PRO
اکتبر '21
+27
در 0 کانال‌ها
Get PRO
سپتامبر '21
+16
در 0 کانال‌ها
Get PRO
اوت '21
+20
در 0 کانال‌ها
Get PRO
ژوئیه '21
+28
در 0 کانال‌ها
Get PRO
ژوئن '21
+30
در 0 کانال‌ها
Get PRO
مه '21
+16
در 0 کانال‌ها
Get PRO
آوریل '21
+33
در 0 کانال‌ها
Get PRO
مارس '21
+39
در 0 کانال‌ها
Get PRO
فوریه '21
+40
در 0 کانال‌ها
Get PRO
ژانویه '21
+40
در 0 کانال‌ها
Get PRO
دسامبر '20
+2 063
در 0 کانال‌ها
| تاریخ | رشد مشترکین | اشارات | کانال‌ها | |
| 23 ژوئن | 0 | |||
| 22 ژوئن | 0 | |||
| 21 ژوئن | +1 | |||
| 20 ژوئن | 0 | |||
| 19 ژوئن | 0 | |||
| 18 ژوئن | 0 | |||
| 17 ژوئن | +2 | |||
| 16 ژوئن | 0 | |||
| 15 ژوئن | 0 | |||
| 14 ژوئن | +1 | |||
| 13 ژوئن | +3 | |||
| 12 ژوئن | 0 | |||
| 11 ژوئن | 0 | |||
| 10 ژوئن | 0 | |||
| 09 ژوئن | 0 | |||
| 08 ژوئن | 0 | |||
| 07 ژوئن | 0 | |||
| 06 ژوئن | 0 | |||
| 05 ژوئن | 0 | |||
| 04 ژوئن | 0 | |||
| 03 ژوئن | 0 | |||
| 02 ژوئن | 0 | |||
| 01 ژوئن | 0 |
پست‌های کانال
Semua yang dibagikan di channel ini dari Z-score, CDF, scatter plot SINR vs throughput, sampai multi-vendor data processing ada versi lengkapnya di ebook "Network Optimization dengan Python".
Bukan teori...
Script Python-nya sudah siap dijalankan, data simulasinya sudah disertakan, dan penjelasannya dalam Bahasa Indonesia.
baca detailnya di sini https://knowledge.myscalev.com/p/network-optimization-dengan-python
| 2 | 💬 Pendapat pribadi yang mungkin tidak populer:
Skill paling underrated untuk engineer telko saat ini bukan 5G NR, bukan Open RAN, bukan AI/ML.
Tapi kemampuan mengolah data sendiri, tanpa bergantung ke tim IT atau vendor untuk buatkan laporan.
Kenapa? Karena data ada di mana-mana. Setiap NMS menghasilkan ribuan baris KPI setiap jam. Setiap drive test menghasilkan ratusan ribu titik pengukuran.
Engineer yang bisa mengolah data itu sendiri , cepat, akurat, dan menghasilkan insight yang bisa langsung ditindaklanjuti , punya posisi yang jauh lebih kuat dibanding yang hanya bisa menunggu laporan dari orang lain.
Python bukan satu-satunya jalannya. Bisa SQL, bisa R, bisa Power BI. Yang penting: kemampuan untuk bertanya ke data dan mendapatkan jawaban sendiri, tanpa perantara.
Di industri telko Indonesia, kemampuan ini masih langka di level engineer lapangan. Justru itu yang membuatnya berharga. | 65 |
| 3 | 🐍 Tips Python untuk Engineer Telko #12
Menghitung jarak antar cell dari koordinat latitude/longitude , berguna untuk missing neighbor audit, coverage overlap analysis, atau cari candidate site terdekat, bisa dilakukan tanpa MapInfo atau ArcGIS.
import numpy as np
def haversine(lat1, lon1, lat2, lon2):
R = 6371 # radius bumi dalam km
lat1, lon1, lat2, lon2 = map(np.radians,
[lat1, lon1, lat2, lon2])
dlat = lat2 - lat1
dlon = lon2 - lon1
a = (np.sin(dlat/2)**2
+ np.cos(lat1) * np.cos(lat2) * np.sin(dlon/2)**2)
return 2 * R * np.arcsin(np.sqrt(a))
# Contoh: cari semua cell dalam radius 1.5 km dari cell target
target_lat, target_lon = -6.2146, 106.8452
df["jarak_km"] = df.apply(
lambda row: haversine(
target_lat, target_lon,
row["lat"], row["lon"]
), axis=1
)
kandidat = df[df["jarak_km"] <= 1.5].sort_values("jarak_km")
print(kandidat[["cell_name", "jarak_km"]])
Hasilnya bisa langsung dipakai untuk flag missing neighbor , cell dalam radius tertentu yang belum masuk di neighbor list. | 83 |
| 4 | 🐍 Tips Python untuk Engineer Telko
Skenario yang sering terjadi di proyek multi-vendor: data KPI dari Huawei U2020, Ericsson OSS, dan Nokia NetAct punya format kolom yang berbeda-beda. Menggabungkannya manual di Excel adalah pekerjaan yang memakan waktu dan rawan error.
Solusinya: standardisasi nama kolom sebelum di-concat.
import pandas as pd
# Mapping kolom tiap vendor ke nama standar
MAPPING = {
"huawei": {
"eNodeB Name": "cell_name",
"RRC.ConnEstabSucc": "rrc_succ",
"RRC.ConnEstabAtt": "rrc_att",
},
"ericsson": {
"Cell Name": "cell_name",
"pmRrcConnEstabSucc": "rrc_succ",
"pmRrcConnEstabAtt": "rrc_att",
},
"nokia": {
"Object": "cell_name",
"RRC_CONN_SUCC": "rrc_succ",
"RRC_CONN_ATT": "rrc_att",
}
}
def baca_dan_standarisasi(file, vendor):
df = pd.read_csv(file)
df = df.rename(columns=MAPPING[vendor])
df["vendor"] = vendor
return df[["cell_name","rrc_succ","rrc_att","vendor"]]
df_gabungan = pd.concat([
baca_dan_standarisasi("huawei.csv", "huawei"),
baca_dan_standarisasi("ericsson.csv", "ericsson"),
baca_dan_standarisasi("nokia.csv", "nokia"),
])
Dari sini semua vendor bisa dianalisis dalam satu dataframe yang seragam. | 103 |
| 5 | ⚖️ Python vs Excel untuk analisis KPI : perbandingan jujur:
Pakai Excel kalau:
→ Data < 50.000 baris dan tidak akan bertambah besar
→ Hanya butuh pivot table atau chart sederhana sekali pakai
→ Hasilnya perlu diedit manual oleh orang lain yang tidak coding
→ Deadline dalam 10 menit dan tidak ada script yang sudah siap
Pakai Python kalau:
→ Data dari banyak file yang perlu digabungkan otomatis
→ Proses yang sama diulang setiap hari/minggu/bulan
→ Perlu alert otomatis, scheduling, atau integrasi dengan API
→ Data > 100.000 baris (Excel mulai lambat dan tidak stabil)
→ Butuh visualisasi yang lebih dari sekedar chart bawaan Excel
Kesimpulan yang sering diabaikan: keduanya tidak saling menggantikan. Workflow terbaik untuk engineer telko justru kombinasi keduanya , Python untuk proses dan kalkulasi, output-nya dikirim ke Excel yang sudah diformat rapi untuk dikonsumsi tim.
Yang salah adalah kalau masih pakai Excel untuk pekerjaan yang jelas-jelas lebih efisien dengan Python , dan sebaliknya, memaksa Python untuk tugas sederhana yang 2 menit selesai di Excel. | 126 |
| 6 | ❌ Asumsi yang sering muncul saat analisis drive test:
"SINR-nya sudah bagus, harusnya throughput juga bagus."
Tidak selalu.
SINR mengukur kualitas sinyal relatif terhadap interferensi, tapi throughput dipengaruhi oleh lebih banyak faktor :
→ Load cell: SINR 20 dB di cell yang overloaded tetap menghasilkan throughput rendah karena resource block sudah terbagi ke banyak user
→ Scheduler priority: user di edge cell bisa dapat SINR bagus tapi PRB allocation-nya sedikit
→ Backhaul bottleneck: air interface bagus, tapi transport ke core lambat
→ UE capability: tidak semua handset support 4x4 MIMO atau 256QAM
Cara diagnosa cepat: plot scatter chart SINR vs throughput per titik drive test. Kalau korelasinya lemah (R² rendah), masalahnya bukan di RF, cari di load, scheduler, atau backhaul.
import matplotlib.pyplot as plt
plt.scatter(df["sinr"], df["tput"], alpha=0.4, s=10)
plt.xlabel("SINR (dB)")
plt.ylabel("Throughput (Mbps)")
plt.title("SINR vs Throughput — Scatter Plot")
plt.savefig("sinr_vs_tput.png", dpi=150) | 118 |
| 7 | 📡 Kenapa Data Jaringan Pasif Sering "Tidak Sesuai Lapangan"?
Banyak operator dan ISP punya masalah yang sama: data di sistem bilang A, kondisi di lapangan ternyata B.
Port PON tercatat kosong, padahal sudah terpakai. Jalur fiber tidak jelas ke mana arahnya. Label di ODP hilang, pudar, atau ditulis tangan. Akibatnya, setiap kali ada gangguan atau pemasangan baru, teknisi harus mengecek ulang dari awal.
Kelihatannya sepele, tapi dampaknya besar:
🔸 Waktu penanganan gangguan jadi lama
🔸 Teknisi bolak-balik ke lokasi untuk pekerjaan yang sama
🔸 Kapasitas port terbuang karena datanya tidak akurat
🔸 Biaya maintenance terus membengkak
Akar masalahnya ada di identifikasi dan verifikasi aset
Jaringan pasif seperti fiber, ODP, ODC, splitter, dan port tidak bisa "melapor" sendiri seperti perangkat aktif. Karena itu, akurasi datanya sangat bergantung pada dua hal:
1️⃣ Identifikasi fisik yang jelas. Setiap kabel, port, dan perangkat harus punya label standar yang tahan lama dan mudah dibaca.
2️⃣ Verifikasi langsung di lapangan. Data dicek dan dikonfirmasi di lokasi, lalu disinkronkan ke sistem. Jangan hanya mengandalkan catatan lama.
Kalau dua hal ini tidak berjalan, sebagus apa pun sistem manajemen jaringannya, data di dalamnya tetap tidak bisa dipercaya.
Apa yang bisa dilakukan?
✅ Gunakan label industrial yang standar dan konsisten, bukan tulisan tangan
✅ Lakukan verifikasi port PON secara berkala tanpa mengganggu layanan pelanggan
✅ Pastikan hasil pengecekan lapangan langsung masuk ke sistem, jangan tertahan di catatan teknisi
✅ Biasakan budaya "label saat pasang", jangan menunda dokumentasi
Solusi
Info solusi dari masalah ini :
Jalur fiber yang sulit dilacak,
Port PON yang tidak terdokumentasi, dan
Data lapangan yang tidak sinkron dengan sistem masih menjadi tantangan besar dalam mengelola jaringan pasif.
MakeID, penyedia solusi identifikasi industrial dan verifikasi lapangan untuk infrastruktur telekomunikasi. Melalui solusi FTTH PON Resource Digital Management, tim Anda dapat :
✅ Melacak jalur fiber dengan lebih cepat
✅ Memverifikasi port PON tanpa mengganggu layanan
✅ Melabeli aset langsung di lapangan
✅ Menyinkronkan data lapangan yang sudah terverifikasi ke sistem manajemen Anda
Hasilnya: data aset lebih akurat, penanganan gangguan lebih cepat, dan biaya maintenance lebih efisien.
Cek lebih detailnya di sini https://s.shopee.co.id/905krZJZle | 143 |
| 8 | 📡 RF OPTIMIZATION: Sinyal Kuat Belum Tentu Jaringan Bagus
Dalam optimasi jaringan 4G dan 5G, mendapatkan RSRP yang bagus bukan berarti pekerjaan sudah selesai. Bisa saja sinyal kuat, tetapi internet tetap lambat, video buffering, atau handover sering gagal.
Karena itu, RF Optimization harus memperhatikan tiga aspek utama: Coverage, Quality, dan Capacity.
Ada beberapa parameter penting yang perlu dianalisis:
📶 RSRP: Mengukur kekuatan sinyal yang diterima UE.
📶 RSRQ: Menggambarkan kualitas sinyal dengan mempertimbangkan kondisi interferensi dan beban jaringan.
📶 SINR: Mengukur perbandingan sinyal yang diinginkan terhadap interferensi dan noise.
📶 CQI: Indikator kualitas kanal yang dilaporkan UE untuk membantu pemilihan modulasi dan coding.
📶 BLER: Persentase transport block yang gagal diterima dengan benar.
📶 Throughput: Kecepatan transfer data yang benar-benar diperoleh pengguna.
Lalu, bagaimana proses optimasinya?
Dimulai dari pengumpulan data melalui drive test, MDT, OSS counter, dan laporan pelanggan. Setelah itu, engineer menganalisis KPI untuk menemukan akar masalah sebelum melakukan perubahan pada jaringan.
Beberapa tindakan optimasi yang umum dilakukan antara lain penyesuaian antenna tilt dan azimuth, pengaturan transmit power, optimasi neighbor relation, PCI planning, serta tuning parameter handover dan load balancing.
Namun, setiap perubahan harus divalidasi. Menambah transmit power mungkin memperbaiki coverage di satu lokasi, tetapi juga berpotensi meningkatkan interferensi di area lain. Begitu pula perubahan tilt yang dapat mengatasi overshooting, tetapi berisiko menciptakan coverage hole jika tidak diperhitungkan dengan benar.
Intinya, RF Optimization bukan sekadar membuat sinyal semakin kuat, melainkan memastikan coverage, kualitas, kapasitas, dan mobilitas bekerja secara seimbang.
Ukur → Analisis → Temukan akar masalah → Optimasi → Verifikasi → Monitoring.
#RFOptimization #Telecommunication #4G #5G #NetworkOptimization | 225 |
| 9 |  بدون متن... | 272 |
| 10 | • Komponen RF yang bermasalah
PIM dapat menghasilkan produk intermodulasi yang masuk ke band receiver dan menyebabkan degradation terutama pada sisi UL.
━━━━━━━━━━━━━━━━━━
🧩 8. Kelompokkan suspect
Secara praktis, suspect interference bisa dikelompokkan menjadi:
A. Internal network
• Overshooting
• Neighbor interference
• PCI/SSB pollution
• Antenna issue
• Power terlalu tinggi
• Tilt problem
B. External interference
• External transmitter
• Illegal repeater
• Faulty RF equipment
• Narrowband interferer
• Wideband interferer
C. Hardware / passive
• PIM
• Connector
• Feeder
• Antenna
D. TDD-specific
• Cross-Link Interference
• TDD pattern mismatch
• Synchronization problem
• Timing misalignment
━━━━━━━━━━━━━━━━━━
🛠️ 9. Workflow sederhana
Gunakan alur berikut:
KPI degradation
⬇️
Cek RSRP & SINR
⬇️
RSRP buruk?
→ cek coverage terlebih dahulu.
RSRP bagus + SINR buruk?
→ investigate interference.
⬇️
Pisahkan DL vs UL
⬇️
Cek RSSI / Noise Floor
⬇️
Spectrum Scan
⬇️
Untuk TDD:
cek korelasi dengan UL/DL slot
⬇️
Identifikasi frequency + time + direction
⬇️
Direction Finding
⬇️
Temukan source
⬇️
Mitigasi
⬇️
Re-measure & validate
━━━━━━━━━━━━━━━━━━
💡 Intinya:
Jangan mencari interference hanya dengan melihat:
❌ "SINR jelek."
Yang harus dicari adalah fingerprint-nya:
WHERE → terjadi di mana?
WHEN → terjadi kapan?
WHAT FREQUENCY → muncul di frekuensi mana?
HOW STRONG → seberapa kuat?
DL atau UL?
CONTINUOUS atau INTERMITTENT?
DIRECTION FROM WHERE?
Untuk FDD, fokus pada pemisahan DL/UL dan analisis frequency domain.
Untuk TDD, tambahkan satu dimensi penting:
⏱️ TIME DOMAIN
Karena interference bisa terjadi akibat ketidaksesuaian waktu DL dan UL antar cell/network.
📡 RF troubleshooting yang baik bukan hanya menemukan "ada interference", tetapi membuktikan fingerprint → menemukan source → melakukan mitigation → membuktikan bahwa KPI kembali normal.
#TelcoExplained #5G #5GNR #TDD #FDD #Interference #RFEngineering #RAN #TelecomEngineer #5GEngineering #NetworkOptimization | 245 |
| 11 | 📡 TELCO ENGINEERING : Cara Mencari Suspect Interference pada 5G TDD & FDD
Pernah menemukan kondisi:
RSRP bagus, tapi SINR jelek dan throughput turun?
Jangan langsung menyimpulkan coverage problem. Salah satu suspect yang perlu diperiksa adalah interference.
Berikut metode praktis untuk melakukan interference hunting pada jaringan 5G FDD maupun TDD.
━━━━━━━━━━━━━━━━━━
🔎 1. Mulai dari KPI
Perhatikan kombinasi parameter:
• SS-RSRP
• SS-SINR
• SS-RSRQ
• RSSI
• CQI
• BLER
• MCS
• PRB Utilization
• UL SINR
• UL RSSI / Noise Floor
• UE Tx Power
Rule of thumb:
🟢 RSRP bagus + SINR bagus
→ RF condition relatif sehat.
🟡 RSRP bagus + SINR buruk
→ Interference menjadi salah satu suspect utama.
🔴 RSRP buruk + SINR buruk
→ Jangan langsung menyalahkan interference. Periksa dulu coverage, path loss, antenna, tilt, dan kondisi serving cell.
━━━━━━━━━━━━━━━━━━
📶 2. Bedakan DL dan UL
Ini sangat penting.
FDD
Pada FDD, DL dan UL menggunakan frekuensi yang berbeda.
Jadi troubleshooting bisa dipisahkan:
DL interference
→ co-channel interference, overshooting, PCI/SSB pollution, adjacent-channel interference, external transmitter, intermodulation.
UL interference
→ perhatikan UL RSSI / noise floor, UL SINR, UL BLER dan UE Tx Power.
Jika UL noise floor tiba-tiba naik sementara RSRP tetap normal, interference pada sisi UL menjadi suspect yang kuat.
━━━━━━━━━━━━━━━━━━
⏱️ 3. Kalau TDD, perhatikan WAKTU
Ini bagian yang paling penting pada 5G TDD.
TDD menggunakan frekuensi yang sama untuk DL dan UL, tetapi dipisahkan berdasarkan slot/symbol waktu.
Contoh:
Cell A → DL
sementara
Cell B → UL
Jika transmisi DL Cell A masuk ke receiver UL Cell B, maka terjadi:
⚠️ Cross-Link Interference (CLI)
Konsep sederhananya:
Cell A DL ─────────►
Cell B UL ◄────
Akibatnya UL Cell B bisa mengalami kenaikan noise/interference dan penurunan SINR.
Cross-link interference memang merupakan salah satu isu penting pada jaringan TDD, terutama ketika jaringan tidak memiliki sinkronisasi atau menggunakan pola DL/UL yang berbeda.
━━━━━━━━━━━━━━━━━━
🕐 4. Cari korelasi dengan TDD slot
Ini salah satu trik yang sangat berguna.
Jika degradation terjadi:
hanya pada UL slot tertentu
dan waktunya berulang mengikuti pola TDD,
maka suspect TDD CLI semakin kuat.
Yang perlu dicek:
• TDD pattern
• DL/UL slot configuration
• Switching point
• Frame timing
• Synchronization status
• Timing offset
• Neighboring cell TDD configuration
Pada jaringan TDD yang berdekatan, perbedaan konfigurasi atau kurangnya sinkronisasi dapat menyebabkan DL satu jaringan mengganggu UL jaringan lain.
━━━━━━━━━━━━━━━━━━
📊 5. Gunakan Spectrum Analyzer
KPI saja belum cukup untuk menemukan siapa sumber interferencenya.
Gunakan spectrum analyzer/scanner untuk melihat:
• Frequency
• Interference power
• Bandwidth
• Peak level
• Duty cycle
• Periodicity
• Narrowband / wideband
• Continuous / intermittent
• Waterfall pattern
Contohnya:
Continuous signal
→ kemungkinan interferer yang selalu aktif.
Periodic signal
→ cari pola waktunya.
Muncul hanya ketika UL
→ sangat menarik untuk investigasi TDD CLI.
Narrowband
→ kemungkinan interferer pada frekuensi tertentu.
Wideband
→ perlu investigasi lebih lanjut, termasuk kemungkinan external transmitter atau masalah RF tertentu.
━━━━━━━━━━━━━━━━━━
🧭 6. Setelah ketemu signal-nya → cari arahnya
Jangan berhenti pada:
"Ada interference."
Target akhirnya adalah:
"Interference berasal dari mana?"
Gunakan:
📡 Directional antenna
📡 Spectrum analyzer/scanner
📡 Drive test
📡 Measurement dari beberapa lokasi
📡 Triangulation / direction finding
Misalnya:
Location A → signal -65 dBm
Location B → -58 dBm
Location C → -48 dBm
Semakin kuat signal ketika mendekati suatu arah/lokasi, semakin kecil area suspect-nya.
━━━━━━━━━━━━━━━━━━
⚠️ 7. Jangan lupa PIM
Kalau masalah terutama terjadi di UL, jangan hanya mencari external interference.
Periksa juga:
PIM — Passive Intermodulation
Sumbernya bisa berasal dari:
• Connector
• Jumper
• Feeder
• Antenna
• Mechanical connection | 172 |
| 12 | 📡 Kenapa Tambah Bandwidth Belum Tentu Membuat Throughput 2x Lipat?
Ada anggapan sederhana:
Bandwidth 10 MHz → 20 MHz
berarti throughput harusnya 2x.
Secara teori memang bandwidth lebih besar memberi lebih banyak resource.
Tapi di network nyata, hasilnya tidak sesederhana itu.
Misalnya sebuah cell:
10 MHz → 20 MHz
Namun setelah bandwidth ditambah, throughput hanya naik sekitar 40–60%.
Kenapa?
Karena throughput tidak ditentukan bandwidth saja.
Masih ada:
• SINR : seberapa bersih radio signal yang diterima
• CQI/MCS : kualitas modulasi yang bisa digunakan
• PRB utilization : apakah resource sudah penuh
• User distribution : berapa banyak user berbagi resource
• MIMO layer : apakah UE bisa memanfaatkan spatial layer
• Backhaul : apakah transport mampu membawa tambahan traffic
• UE capability : perangkat pelanggan juga punya batas
Contoh sederhana:
Cell A punya bandwidth besar, tetapi SINR buruk.
Cell B bandwidth lebih kecil, tetapi SINR bagus dan MIMO berjalan optimal.
Bisa saja Cell B memberikan throughput user yang lebih tinggi.
Jadi ketika ada pertanyaan:
"Kenapa bandwidth sudah ditambah tapi throughput masih segitu?"
Jangan langsung menyalahkan RF.
Coba urutkan:
Bandwidth → PRB → SINR/CQI → MCS → MIMO → Transport → UE
Dari situ biasanya kita mulai bisa menemukan bottleneck sebenarnya ada di mana.
📌 Bandwidth menambah kesempatan.
Radio quality dan network condition menentukan seberapa banyak kesempatan itu bisa dimanfaatkan.
Ini juga alasan kenapa capacity optimization tidak cukup hanya melihat jumlah MHz yang tersedia.
happy Friday | 214 |
| 13 | 📡 TELCO EXPLAINED
Pernah masuk basement atau lift terus tiba-tiba “No Service”? 📵
Kenapa sinyal bisa hilang padahal di luar gedung masih full bar?
Di postingan terbaru Telco Explained, kita bahas dari sisi teknologi: mulai dari struktur bangunan, frekuensi, jarak BTS, sampai desain coverage jaringan.
👉 Cek postingan lengkapnya di Instagram:
https://www.instagram.com/p/DdTCLe6yf8X/
Kalau kamu suka konten yang membongkar teknologi di balik jaringan telekomunikasi dengan bahasa yang gampang dipahami, jangan lupa follow Instagram-nya ya. 🚀
📲 Follow: https://www.instagram.com/belajartelekomunikasi?stkn=MTNxcDVuam41YTlxZA==
Signal terlihat sederhana. Teknologinya luar biasa kompleks. | 266 |
| 14 |  tetapi ketika membuat dengan python terpisah dari qgis, hasilnya keluar cuma 5 detik.
Itulah kekuatan python. | 344 |
| 15 |  gokil sih python ini, bahkan mencoba di qgis untuk mencari ISD 10ribu site saja hang. Misalnya memakai distance matrix atau bahkan memakai python dari Qgisnya sekalipun. Berjam2 error tidak jelas. | 336 |
| 16 | 📡 Telkomsel dan XLSMART Kaji Perlindungan Sisa Kuota Pelanggan
Isu kuota internet yang hangus mulai kembali menjadi perhatian.
Telkomsel dikabarkan sedang mengkaji penyesuaian layanan terkait sisa kuota, sementara XLSMART juga menyatakan kesiapan mengikuti ketentuan perlindungan sisa kuota pelanggan.
Menariknya, bagi engineer telko, isu ini bukan hanya soal produk atau marketing.
Jika mekanisme rollover atau perlindungan sisa kuota diterapkan lebih luas, ada kemungkinan pola penggunaan data pelanggan ikut berubah.
Artinya, yang perlu dipantau bukan hanya:
📊 Total traffic
⏰ Busy Hour
📍 Area congestion
👥 Pola konsumsi pelanggan
Karena perubahan sederhana di sisi produk bisa menghasilkan efek berantai:
Regulasi → Produk → Customer Behavior → Traffic Pattern → Capacity Planning → Network Optimization
📡 Pada akhirnya, apa pun yang mengubah cara pelanggan menggunakan kuota, berpotensi mengubah cara operator merencanakan kapasitas jaringan.
Menarik untuk melihat apakah nanti pola Busy Hour dan traffic distribution operator juga ikut berubah.
#Telecom #Telkomsel #XLSMART #NetworkPlanning #NetworkOptimization #Telecommunication | 383 |
| 17 | 📐 Konsep: CDF dalam laporan drive test
CDF (Cumulative Distribution Function) adalah grafik yang menunjukkan berapa persen sampel pengukuran berada di bawah nilai tertentu.
Cara membaca grafik CDF RSRP:
Sumbu X: nilai RSRP (dari buruk di kiri ke baik di kanan)
Sumbu Y: persentase sampel (0% di bawah, 100% di atas)
Titik di grafik CDF yang menunjukkan Y=10% pada X=-102 dBm artinya: 10% sampel pengukuran punya RSRP di bawah -102 dBm. Itu yang disebut P10.
Kenapa CDF lebih informatif dari histogram:
→ Langsung bisa baca P10, P50, P90 secara visual
→ Perbandingan before-after terlihat jelas: kurva after harus bergeser ke kanan (nilai lebih baik)
→ Standar pelaporan yang diakui oleh operator dan vendor internasional
Dalam laporan drive test yang profesional, CDF RSRP dan CDF throughput selalu ditampilkan berdampingan antara before dan after , satu grafik sudah mewakili ribuan titik pengukuran. | 291 |
| 18 | 📡 Di balik satu KPI yang merah, kadang ada puluhan signalling message yang sedang bekerja.
#Telekomunikasi #RFEngineer #RAN #LTE #5G #NetworkOptimization #TelecomKnowledge #Signalling #UECapability #RadioNetwork | 344 |
| 19 | 📡 Kenapa UE Capability Enquiry Bisa 2x atau 3x? Dan Apa Dampaknya ke Network Performance?
Pernah memperhatikan signalling saat proses UE Context Setup, kemudian menemukan UE Capability Enquiry dilakukan beberapa kali?
Contohnya:
UE Capability Enquiry #1
↓
UE Capability Information
UE Capability Enquiry #2
↓
UE Capability Information
UE Capability Enquiry #3
↓
UE Capability Information
Pertanyaannya:
🤔 Kenapa tidak cukup 1 kali saja?
📱 UE Capability itu apa?
Secara sederhana, network perlu mengetahui kemampuan perangkat UE.
Misalnya apakah smartphone mendukung:
• LTE band tertentu
• Carrier Aggregation
• 4x4 MIMO
• 256QAM
• 5G NSA
• EN-DC
• Berbagai band combination
Semakin modern smartphone, semakin banyak capability dan band combination yang perlu diinformasikan ke network.
Masalahnya, informasi capability tersebut bisa cukup besar.
Karena ada batas ukuran message, capability UE dapat dikirim dalam beberapa enquiry bundle.
Misalnya:
Bundle 1 → LTE Capability
Bundle 2 → CA Combination
Bundle 3 → 5G / EN-DC Combination
Jumlah enquiry bisa berbeda tergantung implementasi dan pengaturan vendor.
⏱ Kenapa jumlah enquiry menjadi perhatian?
Karena setiap signalling exchange membutuhkan waktu.
Secara sederhana:
Jika 3 kali:
Network → Enquiry 1 → UE Response
Network → Enquiry 2 → UE Response
Network → Enquiry 3 → UE Response
Jika bisa disederhanakan menjadi 2 kali:
Network → Enquiry 1 → UE Response
Network → Enquiry 2 → UE Response
Secara teori, semakin sedikit signalling round-trip, semakin kecil potensi delay.
Pada observasi tertentu, perbedaan proses ini dapat mencapai puluhan milidetik.
Misalnya:
2x Enquiry ≈ 80 ms
3x Enquiry ≈ 130 ms
Potensi gain:
🎯 ±50 ms
Angka ini mungkin terlihat kecil.
Tetapi dalam network optimization, puluhan milidetik bisa menjadi menarik jika terjadi pada proses connection setup dalam jumlah besar.
📶 Bagaimana jika kondisi RF buruk?
Di sinilah diskusinya menjadi lebih menarik.
Pada kondisi RF bagus:
Signalling → sukses → selesai
Namun pada poor RF:
Signalling
↓
Error / BLER
↓
Retransmission
↓
Delay bertambah
Jika signalling exchange lebih banyak, maka kemungkinan total delay juga bisa meningkat.
Karena itu, optimasi jumlah UE Capability Enquiry berpotensi memberikan dampak lebih terasa pada kondisi radio yang tidak ideal.
💾 Tapi bukankah capability UE bisa di-cache?
Betul.
Dalam beberapa kondisi, informasi capability UE dapat disimpan oleh network sehingga UE Capability Enquiry tidak selalu dilakukan setiap kali UE connect.
Secara sederhana:
First Connection
UE Capability Enquiry
↓
Network stores capability
↓
Cache
Pada connection berikutnya, network mungkin dapat menggunakan informasi yang sudah tersedia.
Karena itu, dampak optimasi ini terhadap overall user experience perlu dilihat berdasarkan:
• Vendor implementation
• Core network behaviour
• UE behaviour
• Cache mechanism
• Frequency UE Capability Enquiry triggered
• Radio condition
🔍 Jangan langsung lihat parameter, lihat prosesnya
Diskusi seperti ini mengingatkan kita bahwa performance network tidak selalu hanya dipengaruhi oleh:
❌ RSRP
❌ SINR
❌ Throughput
❌ Tilt
❌ Power
Kadang improvement datang dari detail signalling seperti:
UE Context Setup
↓
UE Capability Exchange
↓
Bearer Setup
↓
Connection Established
Jika salah satu tahap bisa dipercepat, KPI seperti connection setup delay juga berpotensi membaik.
💡 Insight untuk RF Engineer
Saat melihat perbedaan performance antar vendor, jangan hanya bertanya:
"Coverage-nya beda berapa?"
atau:
"Throughput-nya lebih tinggi berapa Mbps?"
Kadang pertanyaan yang lebih menarik adalah:
"Apa yang sebenarnya terjadi di dalam signalling flow?"
Karena perbedaan implementasi vendor, message bundling, capability handling, atau cache mechanism dapat menciptakan gap performance yang tidak langsung terlihat dari KPI RF biasa. | 323 |
| 20 | 🐍 Tips Python untuk Engineer Telko #8
PCI collision dan confusion adalah masalah yang sering luput dari audit manual karena jumlah relasi neighbor bisa ribuan. Python bisa scan seluruh neighbor list dalam hitungan detik.
import pandas as pd
df = pd.read_csv("neighbor_list.csv")
# PCI Collision: dua neighbor berbeda punya PCI sama
collision = df[
df.duplicated(subset=["Source_Cell","PCI"], keep=False)
]
# PCI Confusion: source cell punya dua neighbor
# dengan PSS yang sama (PCI % 3 sama)
df["PSS"] = df["PCI"] % 3
confusion = df[
df.duplicated(subset=["Source_Cell","PSS"], keep=False)
]
print(f"Collision : {len(collision)} relasi")
print(f"Confusion : {len(confusion)} relasi")
print(collision[["Source_Cell","Neighbor_Cell","PCI"]])
Output langsung menunjukkan cell mana yang punya masalah PCI bisa langsung dipakai sebagai bahan rekomendasi ke tim planning. | 306 |
