Belajar Telecom Engineer - Network Management & OSS/BSS

#Pendahuluan

Setelah di episode 9 kita merancang jaringan FTTx sampai ke rumah pelanggan, muncul pertanyaan operasional besar: bagaimana operator mengelola ratusan ribu elemen jaringan — BTS, router, OLT, core nodes — plus jutaan pelanggan, setiap hari, tanpa chaos? Jawabannya adalah dua sistem kembar: OSS (Operations Support System) untuk jaringan, dan BSS (Business Support System) untuk pelanggan & uang.

Mengapa episode ini penting? Karena sebagian besar pekerjaan harian engineer operator berinteraksi dengan OSS/BSS: melihat alarm di NMS, memproses aktivasi pelanggan, menarik laporan KPI, atau mencari kenapa CDR pelanggan tidak cocok dengan pemakaian. Engineer yang paham alur data antar sistem ini bisa memecahkan masalah lintas domain — keterampilan yang membedakan senior dari junior.

#FCAPS: Kerangka Manajemen Klasik

ISO mendefinisikan lima fungsi manajemen jaringan yang masih dipakai sampai sekarang:

Fungsi	Pertanyaan Inti	Contoh Aktivitas
Fault	Apa yang rusak?	Alarm, event correlation, tiket gangguan
Configuration	Bagaimana disetel?	Provisioning, backup config, change management
Accounting	Siapa pakai apa?	CDR, metering, alokasi biaya
Performance	Seberapa baik?	KPI, trend kapasitas, SLA report
Security	Siapa boleh?	AAA, audit log, hardening akses NMS

Latihan membiasakan diri: saat kalian menghadapi insiden apa pun, klasifikasikan ke salah satu lima kotak ini. Cara berpikir terstruktur semacam ini yang dicari saat interview operasional.

#Arsitektur Berlapis: EMS → NMS → OSS

Manajemen jaringan tersusun bertingkat:

100%

EMS dikeluarkan vendor untuk produknya sendiri (misal EMS Huawei hanya bicara ke perangkat Huawei).
NMS menyatukan banyak vendor dalam satu peta & satu alarm view.
OSS adalah otak proses: inventory (aset & konektivitas), orchestrator (workflow aktivasi), assurance (korelasi fault → tiket).
BSS menyentuh pelanggan: CRM, rating & charging, billing, revenue assurance.

Interface antar lapis punya nama standar: southbound (ke elemen jaringan — SNMP, NETCONF, CLI), northbound (ke atas — API REST/SOAP), dan TMForum mendefinisikan model data seperti SID serta framework eTOM untuk proses bisnisnya.

#Fault Management: Dari Alarm Menjadi Aksi

Alur alarm yang sehat:

Lifecycle alarm

NE mendeteksi → trap/notification ke NMS → de-dup & korelasi
→ auto-ticket → dispatch teknisi → clear + RCA

Masalah dunia nyata bukan kurang alarm, melainkan banjir alarm: satu fiber putus memicu ratusan alarm turunan. Korelasi cerdas harus menyaring akar penyebab ("fiber cut segment X") dari gejala ("12 site unreachable"). Metrik keberhasilannya: MTTR (waktu pulih) dan alarm-to-ticket ratio.

#Praktik: Monitoring Mini dengan SNMP + Prometheus

Mari bangun fondasi NMS sendiri di lab (environment episode 0).

#Langkah 1 — Aktifkan SNMP di router lab

Pada router VyOS/FRR di GNS3:

Aktifkan SNMP agent

set service snmp community LabRO authorization ro
set service snmp contact noc@lab.local
commit ; save
snmpwalk -v2c -c LabRO 192.168.100.1 sysDescr.0     # uji dari host

#Langkah 2 — Tarik metrik ke Prometheus

Jalankan snmp-exporter dan daftarkan target:

prometheus.yml (cuplikan)

scrape_configs:
  - job_name: "snmp-routers"
    metrics_path: /snmp
    params:
      module: [if_mib]
    static_configs:
      - targets: ["192.168.100.1"]
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - target_label: __address__
        replacement: "127.0.0.1:9116"

#Langkah 3 — Query dan alert sederhana

Utilisasi interface tertinggi (indikasi link penuh) via PromQL:

PromQL: utilisasi egress %

rate(ifHCOutOctets[5m]) * 8 / ifHighSpeed * 100

Dan aturan alert ketik melewati 85% selama 10 menit:

alert_rules.yml

groups:
  - name: transport
    rules:
      - alert: LinkSaturation
        expr: link_utilization > 85
        for: 10m
        labels: {severity: warning}
        annotations:
          summary: "Utilisasi > 85% pada {{ $labels.ifDescr }}"

Tip

Pola in-band vs out-of-band: pastikan jalur manajemen (SNMP/SSH ke NE) tidak lewat jalur yang sedang mati. Operator serius menyediakan OOB network terpisah — tanpa itu, saat ring putus kalian juga kehilangan mata untuk melihat ke mana-mana.

#Provisioning & Billing: Jembatan OSS-BSS

Saat pelanggan baru memesan layanan, inilah rantai otomatis yang seharusnya terjadi:

CRM mencatat pesanan (BSS).
Inventory memilih port OLT/fiber yang tersedia (OSS).
Orchestrator mengirim konfigurasi ke elemen (aktivasi ONT, profil bandwidth).
Activation system memverifikasi sesi hidup (misal PPPoE/IPoE up).
Charging mulai merekam CDR; billing menggabungkan CDR + tarif menjadi tagihan.

Titik gagal favorit lapangan: mismatch data antara inventory dan kondisi nyata (port tercatat kosong padahal dipakai). Itulah kenapa disiplin update inventory — atau sinkronisasi otomatis via autodiscovery — adalah masalah serius, bukan urusan administrasi belaka.

#Common Pitfalls

Menganggap NMS = OSS: NMS hanyalah pandangan jaringan; OSS mengatur proses & data lintas sistem. Mengganti NMS tidak menyelesaikan kekacauan inventory.
Alarm tanpa severity yang bermakna: semua "critical" berarti tidak ada yang critical. Kalibrasi ulang threshold berkala.
Backup config manual: ratusan NE dikonfig manual tanpa versioning = bencana audit. Otomasikan (topik episode 15) bahkan jika masih sederhana.

#Penutup

Inti yang harus dibawa pulang:

FCAPS adalah kerangka berpikir manajemen: fault, configuration, accounting, performance, security.
Hierarki EMS → NMS → OSS dan pemisahan OSS (jaringan) vs BSS (pelanggan/uang).
Alur provisioning end-to-end: CRM → inventory → orchestrator → activation → charging.
Kalian sudah membangun monitoring ala-NMS: SNMP, Prometheus, alert utilization.

Di episode 11 kita turun ke lapangan lagi: optimasi jaringan radio — KPI RSRP/RSRQ/SINR, drive test, dan siklus optimization yang dipakai operator menjaga kualitas jutaan pengguna. Sampai jumpa!