QoS GPON End-to-End: Mengapa Speedtest Tembus tapi Aplikasi Tetap Lag

Pendahuluan

Dalam banyak implementasi GPON, performa jaringan sering dinilai hanya dari satu indikator: speedtest. Selama angka unduh dan unggah sesuai paket, jaringan dianggap sehat. Namun realitas di lapangan sering berbicara lain. Pelanggan mengeluh Zoom tersendat, suara VoIP terputus, atau IPTV membeku—padahal bandwidth masih tersedia.

Fenomena ini menunjukkan satu hal penting: QoS di GPON tidak berhenti pada bandwidth. Ia bekerja secara end-to-end, melewati beberapa lapisan teknis dari OLT hingga perangkat pelanggan. Jika satu lapisan gagal bekerja dengan benar, seluruh pengalaman pengguna akan ikut terganggu.

QoS GPON Bukan Satu Titik, tapi Rantai

GPON bukanlah jalur point-to-point biasa. Ia adalah sistem shared medium dengan mekanisme penjadwalan yang kompleks. Di sinilah QoS berperan sebagai pengatur prioritas—bukan hanya soal “berapa besar”, tetapi siapa yang dilayani lebih dulu.

Kesalahan paling umum adalah menganggap bahwa pengaturan QoS selesai ketika T-CONT sudah dibuat. Padahal, T-CONT hanyalah satu bagian dari rantai panjang QoS GPON.

Awal QoS: Kebijakan di OLT

Semua keputusan QoS dimulai dari OLT. Di sinilah layanan pelanggan “didefinisikan” melalui service profile. Profil ini menentukan bagaimana trafik diperlakukan: apakah ia berhak mendapat bandwidth minimum, seberapa besar burst yang diizinkan, dan bagaimana prioritasnya dibanding layanan lain.

Masalah muncul ketika semua layanan—internet, IPTV, dan VoIP—dimasukkan ke dalam satu profil yang sama. Bagi OLT, trafik tersebut menjadi tidak terbedakan. Akibatnya, saat jaringan sibuk, trafik sensitif delay akan diperlakukan sama dengan trafik unduhan besar.

GEM Port: Identitas dan Prioritas Layanan

Setelah kebijakan ditetapkan, trafik dibungkus dalam GEM Port. Di sinilah identitas layanan seharusnya dipisahkan. GEM Port memungkinkan OLT mengenali mana trafik suara, mana video, dan mana data biasa.

Namun dalam banyak jaringan, pemisahan ini tidak dilakukan. Semua layanan berjalan di satu GEM Port demi kesederhanaan konfigurasi. Dampaknya baru terasa saat jaringan padat: VoIP ikut antre di belakang download besar, dan video IPTV kehilangan prioritasnya.

Di titik ini, speedtest masih bisa terlihat bagus, tetapi pengalaman aplikasi mulai memburuk.

T-CONT: Mengatur Nafas Upstream

Masalah QoS sering kali lebih parah di upstream. Tidak seperti downstream yang bersifat broadcast, upstream GPON dikontrol ketat oleh mekanisme Dynamic Bandwidth Allocation (DBA). Di sinilah T-CONT menentukan bagaimana ONU mendapat giliran berbicara.

Jika semua trafik upstream ditempatkan pada T-CONT best effort, maka tidak ada jaminan waktu kirim untuk paket kecil dan sensitif. Trafik video call atau VoIP bisa tertunda hanya karena ada upload besar di latar belakang.

Inilah sebabnya banyak kasus di mana download cepat, tetapi suara patah-patah.

Scheduler OLT: Siapa Didahulukan Saat Padat

Saat banyak ONU aktif bersamaan, OLT menggunakan scheduler untuk menentukan urutan layanan. Scheduler ini bekerja berdasarkan kebijakan prioritas yang telah ditentukan sebelumnya.

Jika scheduler tidak dirancang dengan baik, trafik prioritas rendah bisa “rakus” dan memonopoli waktu transmisi. IPTV yang seharusnya stabil justru mengalami freeze, meskipun bandwidth total belum habis.

Masalah ini sering disalahartikan sebagai gangguan jaringan, padahal akarnya ada pada kebijakan penjadwalan.

ONU: Titik yang Sering Diremehkan

ONU bukan sekadar konverter optik ke Ethernet. Di dalamnya terdapat buffer, antrian, dan logika penjadwalan sendiri. Kualitas implementasi ini sangat bergantung pada vendor dan kelas perangkat.

ONU dengan buffer kecil atau QoS internal yang lemah akan menjadi bottleneck baru. Di sinilah sering terjadi kondisi paradoks: OLT dan jaringan optik sehat, tetapi aplikasi tetap tidak stabil.

Lapisan Terakhir: Ethernet dan WiFi

QoS sering “hilang” di lapisan terakhir—WiFi dan port Ethernet ONU. Tanpa mekanisme seperti WMM atau pemisahan trafik, semua paket kembali masuk satu antrian.

Akibatnya, meskipun GPON bekerja sempurna hingga ONU, trafik sensitif tetap kalah oleh trafik besar di sisi lokal pelanggan.

Mengapa Speedtest Selalu Terlihat Baik?

Speedtest menggunakan trafik besar, agresif, dan toleran terhadap delay. Ia dirancang untuk menghabiskan bandwidth, bukan menguji kualitas antrian atau jitter.

Aplikasi seperti Zoom, VoIP, dan IPTV justru sebaliknya. Mereka sensitif terhadap latency, jitter, dan packet loss, bukan sekadar throughput.

Inilah sebabnya speedtest sering memberi rasa aman palsu.

Penutup

QoS GPON adalah sistem berlapis yang harus dipahami secara utuh. Ia tidak berhenti di T-CONT, tidak selesai di OLT, dan tidak bisa diabaikan di ONU maupun WiFi pelanggan.

Jaringan GPON yang benar-benar berkualitas bukan yang mencetak angka speedtest tertinggi, tetapi yang mampu menjaga konsistensi pengalaman aplikasi nyata.

👉 Jika speedtest bagus tapi aplikasi lag, hampir pasti masalahnya ada pada QoS end-to-end.