QoS pada Tautan Satelit: Traffic Shaping, Latensi, dan Performa Aplikasi

Pendahuluan

Setiap jaringan mendapat manfaat dari kebijakan Quality of Service. Namun pada tautan satelit, QoS bukan sekadar praktik terbaik — ini adalah kebutuhan bertahan hidup. Kombinasi bandwidth terbatas, latensi tinggi, throughput yang bervariasi, dan kapasitas bersama berarti bahwa tautan satelit tanpa QoS akan mengecewakan penggunanya pada momen terburuk: saat panggilan VoIP dengan pelanggan, video conference dengan kantor pusat, sesi VPN ke sistem ERP, atau transaksi aplikasi SaaS yang timeout dan memaksa percobaan ulang yang memperparah kemacetan.

Jaringan terestrial sering kali dapat menutupi ketiadaan QoS melalui kelimpahan bandwidth semata. Koneksi fiber 1 Gbps jarang memaksa tim TI untuk memilih aplikasi mana yang mendapat prioritas. Tautan VSAT 10 Mbps yang melayani 40 pengguna di platform lepas pantai harus memilih. Terminal LEO 50 Mbps yang dibagi antara kesejahteraan kru dan sistem operasional di kapal harus memilih. Tautan cadangan satelit 25 Mbps yang baru saja menjadi WAN utama setelah pemutusan fiber harus memilih.

Panduan ini memberikan kerangka kerja praktis bagi engineer jaringan enterprise, arsitek SD-WAN, dan manajer TI untuk mengimplementasikan QoS pada tautan satelit. Panduan ini mencakup gangguan spesifik satelit yang membuat QoS esensial, komponen dasar kebijakan QoS satelit, pola traffic shaping untuk skenario penerapan umum, akselerasi TCP, integrasi SD-WAN, dan daftar periksa konfigurasi untuk penerapan produksi. Untuk gambaran umum konektivitas satelit enterprise yang lebih luas, lihat Panduan Internet Satelit Enterprise.

---

Gangguan Satelit yang Membuat QoS Esensial

Sebelum merancang kebijakan QoS, engineer harus memahami gangguan spesifik yang ditimbulkan tautan satelit pada lalu lintas aplikasi. Gangguan ini berbeda secara fundamental dari tantangan jaringan terestrial dan secara langsung menentukan bagaimana kebijakan QoS seharusnya disusun.

Latensi dan Bandwidth-Delay Product

Tautan satelit GEO menimbulkan latensi round-trip 480–600 ms — konsekuensi fisik dari ketinggian orbit 35.786 km. Konstelasi LEO menguranginya menjadi 20–40 ms, tetapi bahkan latensi LEO melebihi apa yang dialami sebagian besar aplikasi enterprise pada jalur terestrial. Untuk perbandingan terperinci lintas rezim orbit, lihat Perbandingan Latensi Satelit.

Bandwidth-delay product (BDP) — hasil kali kapasitas tautan dan waktu round-trip — menentukan seberapa banyak data yang dapat "dalam perjalanan" pada satu waktu. Tautan GEO 10 Mbps dengan RTT 600 ms memiliki BDP sebesar 750 KB. Congestion window TCP harus mencapai nilai ini sebelum tautan dimanfaatkan sepenuhnya. Implementasi TCP standar memerlukan banyak round trip untuk meningkat ke ukuran window ini, membuat tautan kurang terpakai selama beberapa detik pertama setiap koneksi. Inilah mengapa akselerasi TCP (dibahas di bawah) merupakan pendamping kritikal QoS pada tautan GEO.

Jitter dan Packet Loss

Tautan satelit menunjukkan pola jitter yang berbeda dari jaringan terestrial. Tautan GEO memiliki jitter yang relatif stabil (biasanya 5–15 ms) tetapi dengan latensi dasar yang tinggi. Tautan LEO dapat mengalami lonjakan jitter selama handover satelit — periode singkat di mana latensi berfluktuasi saat terminal beralih dari satu satelit ke satelit lain. Peristiwa jitter akibat handover ini biasanya di bawah 100 ms tetapi dapat berdampak pada aplikasi real-time jika jitter buffer tidak diukur dengan tepat.

Packet loss pada tautan satelit berasal dari dua sumber: kemacetan (terlalu banyak pengguna bersaing untuk kapasitas bersama) dan degradasi lapisan fisik. Rain fade adalah gangguan lapisan fisik utama untuk layanan Ka-band, mengurangi rasio signal-to-noise dan memaksa modem beralih ke skema modulasi yang lebih tahan namun throughput-nya lebih rendah — lihat Rain Fade dalam Komunikasi Satelit. Adaptive Coding and Modulation (ACM) menangani degradasi lapisan fisik secara otomatis, tetapi pengurangan throughput yang ditimbulkannya dapat memicu kemacetan jika kebijakan QoS tidak memperhitungkan kapasitas yang tersedia yang berkurang. Untuk informasi lebih lanjut tentang bagaimana ACM menyesuaikan throughput secara dinamis, lihat Panduan Modulasi dan Coding Satelit.

Kemacetan vs Degradasi Lapisan Fisik

Perbedaan kritikal untuk desain QoS: kemacetan dan degradasi lapisan fisik terlihat serupa bagi protokol lapisan atas (keduanya menyebabkan packet loss dan peningkatan latensi) tetapi memerlukan respons yang berbeda. Kemacetan memerlukan traffic shaping — mengurangi beban yang ditawarkan agar sesuai dengan kapasitas yang tersedia. Degradasi lapisan fisik memerlukan waktu tunggu hingga kondisi membaik sambil melindungi kelas lalu lintas dengan prioritas tertinggi. Kebijakan QoS yang dirancang dengan baik menangani kedua skenario, dan modem satelit yang terinstrumentasi dengan baik menyediakan telemetri untuk membedakan keduanya.

Memahami rantai sinyal dasar membantu menjelaskan di mana gangguan ini terjadi — lihat Cara Kerja Internet Satelit untuk konsep dasarnya.

---

Komponen Dasar QoS

Mekanisme QoS inti yang digunakan pada tautan satelit sama dengan jaringan terestrial, tetapi konfigurasinya memerlukan penyetelan spesifik satelit. Komponen dasar berikut membentuk fondasi kebijakan QoS satelit apa pun.

Klasifikasi dan Penandaan

Klasifikasi lalu lintas mengidentifikasi aplikasi atau jenis lalu lintas yang dimiliki setiap paket. Penandaan menempelkan klasifikasi tersebut ke header paket — biasanya menggunakan nilai DSCP (Differentiated Services Code Point) di byte ToS header IP — sehingga setiap perangkat di jalur forwarding dapat menerapkan perlakuan yang benar tanpa memeriksa ulang payload paket.

Pada jaringan satelit, klasifikasi biasanya terjadi di router edge pelanggan atau appliance SD-WAN sebelum lalu lintas memasuki modem satelit. Metode klasifikasi umum meliputi:

• Penandaan DSCP: Standar industri. Aplikasi enterprise dan voice gateway sering menandai lalu lintas mereka sendiri. Router edge mempercayai atau menandai ulang sesuai kebutuhan.
• DPI berbasis kesadaran aplikasi: Platform SD-WAN dan appliance optimasi WAN dapat mengidentifikasi aplikasi melalui deep packet inspection, bahkan ketika lalu lintas terenkripsi (menggunakan SNI, metadata sertifikat, atau fingerprinting perilaku).
• Kebijakan sumber/tujuan: Aturan statis berdasarkan alamat IP, subnet, VLAN, atau port — sederhana tetapi efektif untuk jaringan yang terstruktur dengan baik.

Penerapan QoS satelit tipikal menggunakan 4–6 kelas lalu lintas. Lebih dari 8 kelas jarang meningkatkan performa dan menambah kompleksitas operasional. Bandwidth satelit bersama dalam Arsitektur Jaringan VSAT membuat klasifikasi yang tepat sangat penting, karena beberapa situs mungkin berbagi kapasitas transponder yang sama.

Disiplin Queuing

Setelah lalu lintas diklasifikasikan, queuing menentukan urutan pengiriman paket. Disiplin queuing secara langsung mengontrol aplikasi mana yang mengalami delay dan mana yang mendapat akses prioritas ke tautan.

• Strict Priority Queue (PQ): Paket suara dan video real-time didequeue terlebih dahulu, selalu. Ini menjamin latensi minimum untuk kelas lalu lintas ini tetapi dapat membuat antrian lain kelaparan jika lalu lintas prioritas melebihi alokasinya. Pembatas rate (policer) pada antrian prioritas mencegah kelaparan — biasanya membatasi suara pada 10–15% kapasitas tautan.
• Weighted Fair Queuing (WFQ): Bandwidth yang tersisa didistribusikan di antara kelas lalu lintas non-prioritas sesuai bobot yang dapat dikonfigurasi. Aplikasi kritikal bisnis (ERP, CRM, replikasi database) menerima bobot lebih tinggi daripada lalu lintas best-effort (browsing web, media sosial, pembaruan perangkat lunak).
• Class-Based WFQ (CBWFQ): Menggabungkan strict priority untuk lalu lintas real-time dengan weighted fair queuing untuk yang lainnya. Ini adalah model queuing paling umum untuk penerapan satelit enterprise.

Shaping vs Policing

Shaping dan policing keduanya membatasi rate lalu lintas, tetapi berperilaku berbeda dan memiliki implikasi berbeda untuk tautan satelit.

• Shaping mem-buffer lalu lintas berlebih dan melepaskannya dengan rate terkontrol. Ini memuluskan pola burst dan mencegah buffer modem satelit dari overflow. Shaping lebih disukai pada sisi outbound (transmit) tautan satelit karena mencegah kemacetan di modem satelit.
• Policing langsung membuang atau menandai ulang lalu lintas berlebih tanpa buffering. Policing digunakan di batas kepercayaan (di mana lalu lintas tidak tepercaya memasuki jaringan) dan untuk menerapkan batas rate pada kelas lalu lintas tertentu.

Pada tautan satelit, shaping hampir selalu lebih disukai daripada policing untuk manajemen lalu lintas agregat. Latensi tinggi tautan satelit berarti bahwa paket yang dibuang memerlukan waktu lama untuk pulih (retransmisi TCP memerlukan RTT penuh), sehingga mem-buffer lalu lintas berlebih sebentar lebih murah daripada membuangnya. Namun, shaping menambahkan latensi tambahan (delay buffering), sehingga buffer shaping harus diukur untuk menyeimbangkan throughput dan delay — buffer yang dalam memaksimalkan throughput tetapi meningkatkan latensi untuk semua lalu lintas dalam antrian.

Active Queue Management

Algoritma Active Queue Management (AQM) mencegah penumpukan antrian dari mencapai titik di mana tail-drop menyebabkan retransmisi TCP tersinkronisasi — fenomena yang disebut "TCP global synchronization" yang menyebabkan osilasi throughput.

• RED (Random Early Detection): Secara acak membuang paket sebelum antrian penuh, memberi sinyal kepada pengirim TCP untuk mengurangi rate mereka secara bertahap daripada sekaligus.
• CoDel (Controlled Delay): Memantau berapa lama paket menghabiskan waktu di antrian dan membuang paket ketika waktu tinggal melebihi ambang batas. CoDel sangat efektif pada tautan satelit karena menargetkan delay daripada kedalaman antrian, membuatnya adaptif terhadap throughput variabel yang disebabkan ACM.

AQM paling efektif pada antrian shaping — titik di mana semua lalu lintas yang diklasifikasikan dan diprioritaskan bertemu sebelum memasuki modem satelit.

---

Pola Traffic Shaping untuk SATCOM

Pola-pola berikut mewakili konfigurasi QoS yang terbukti untuk skenario penerapan satelit umum. Setiap pola dapat diimplementasikan pada router enterprise, appliance SD-WAN, atau perangkat optimasi WAN khusus.

Prioritas Suara dan Video

Komunikasi real-time — VoIP, video conferencing, unified communications — adalah aplikasi paling sensitif terhadap latensi di jaringan mana pun dan yang pertama gagal pada tautan satelit yang tidak dikelola.

Pola konfigurasi:

• Klasifikasikan suara (RTP/SIP, DSCP EF) dan video interaktif (DSCP AF41) ke dalam strict priority queue.
• Batasi antrian prioritas pada 15–20% dari committed information rate (CIR) untuk mencegah kelaparan kelas lalu lintas lain.
• Terapkan jitter buffer di voice gateway: 60–80 ms untuk tautan LEO, 150–200 ms untuk tautan GEO.
• Aktifkan voice activity detection (VAD) untuk mengurangi konsumsi bandwidth selama periode hening.
• Gunakan codec G.729 atau Opus daripada G.711 — G.729 mengonsumsi 8 kbps per panggilan versus 64 kbps untuk G.711, perbedaan kritikal pada tautan satelit dengan bandwidth terbatas.

Tautan satelit 10 Mbps dengan alokasi antrian prioritas 15% mendukung sekitar 150 panggilan G.729 bersamaan — lebih dari cukup untuk sebagian besar situs enterprise. Tautan yang sama hanya mendukung 23 panggilan G.711.

Jaminan Aplikasi Kritikal Bisnis

Aplikasi enterprise — ERP (SAP, Oracle), CRM (Salesforce), replikasi database, cloud SaaS — memerlukan throughput konsisten dan latensi terbatas tetapi tidak memerlukan perlakuan strict priority yang dituntut suara.

Pola konfigurasi:

• Klasifikasikan lalu lintas kritikal bisnis ke dalam kelas CBWFQ dengan bandwidth minimum terjamin (misalnya, 40% dari CIR).
• Terapkan penandaan DSCP AF31 untuk aplikasi kritikal bisnis.
• Aktifkan akselerasi TCP untuk aliran ini guna mengatasi tantangan BDP pada tautan GEO.
• Pantau waktu respons aplikasi — jika aplikasi SaaS melebihi ambang batas yang dapat diterima, tingkatkan alokasi bandwidth terjamin.

Penjadwalan Transfer Massal

Transfer data besar — pekerjaan backup, distribusi perangkat lunak, upload file video, sinkronisasi database — dapat mengonsumsi semua bandwidth satelit yang tersedia jika dibiarkan tanpa pengelolaan. Transfer ini biasanya toleran terhadap delay, menjadikannya kandidat ideal untuk shaping terjadwal.

Pola konfigurasi:

• Klasifikasikan lalu lintas massal (diidentifikasi berdasarkan aplikasi, port, atau DSCP CS1/AF11) ke dalam antrian scavenger atau prioritas rendah.
• Terapkan batas rate maksimum (misalnya, 20% dari CIR selama jam kerja, 80% selama off-peak).
• Jadwalkan operasi intensif bandwidth (backup, pembaruan) untuk jendela off-peak — malam hari untuk situs tetap, jendela pemeliharaan yang ditentukan untuk operasi maritim dan terpencil.
• Gunakan optimasi WAN (deduplikasi, kompresi) untuk mengurangi volume transfer massal.

Maritim: Keadilan Kru vs Operasional

Penerapan satelit maritim — lihat Internet Satelit Maritim — menghadirkan tantangan QoS unik: lalu lintas operasional (navigasi, cuaca, manajemen armada, pelaporan regulasi) dan lalu lintas kesejahteraan kru (browsing web, streaming video, media sosial, pesan) berbagi tautan satelit yang sama.

Pola konfigurasi:

• Pisahkan lalu lintas operasional dan kru di tingkat jaringan (segmentasi VLAN atau SSID terpisah).
• Jamin alokasi bandwidth minimum untuk lalu lintas operasional (misalnya, 60% dari CIR) terlepas dari penggunaan kru.
• Terapkan pembatasan rate per-pengguna dalam VLAN kru untuk mencegah satu pengguna memonopoli bandwidth kru.
• Implementasikan pembatasan tingkat aplikasi pada aplikasi kru yang intensif bandwidth (streaming video dibatasi pada 480p, peer-to-peer diblokir sepenuhnya).
• Selama kondisi darurat atau cuaca buruk, kebijakan harus memungkinkan lalu lintas operasional mengklaim 100% kapasitas yang tersedia.

Untuk skenario satellite backhaul yang melayani menara seluler atau jaringan edge, prinsip keadilan serupa berlaku — lihat Satellite Backhaul Explained untuk arsitektur khusus backhaul.

---

Akselerasi TCP dan Optimasi WAN

Mengapa TCP Bermasalah pada Tautan Satelit

Algoritma congestion control TCP dirancang untuk jaringan terestrial di mana waktu round-trip diukur dalam milidetik. Pada tautan satelit GEO dengan RTT 600 ms, perilaku TCP menciptakan dua masalah signifikan:

1. Penalti slow start: TCP memulai setiap koneksi dengan congestion window kecil (biasanya 10 segmen) dan menggandakannya setiap RTT. Pada tautan GEO, mencapai utilisasi tautan penuh memerlukan banyak detik — tidak dapat diterima untuk transaksi HTTP berumur pendek yang mungkin selesai sebelum window terbuka sepenuhnya.
2. Delay pemulihan loss: Ketika sebuah paket hilang, TCP menunggu RTT penuh sebelum mendeteksi kehilangan tersebut (melalui duplicate ACK atau retransmission timeout). Pada tautan GEO, ini berarti 600 ms kapasitas terbuang per peristiwa loss. Pada tautan yang macet dengan 1% packet loss, throughput runtuh.

Apa yang Dilakukan Akselerasi TCP

Akselerasi TCP — juga disebut optimasi WAN, TCP spoofing, atau Performance Enhancing Proxy (PEP) — menempatkan perangkat proxy di kedua sisi tautan satelit. Proxy menghentikan koneksi TCP secara lokal dan meneruskan data melintasi tautan satelit menggunakan protokol yang dioptimalkan yang memperhitungkan karakteristik latensi tinggi dan BDP tinggi dari jalur satelit.

Teknik utama meliputi:

• Window scaling: Proxy menggunakan TCP window yang sudah dibuka terlebih dahulu berukuran sesuai BDP tautan satelit, menghilangkan slow start.
• Selective acknowledgment: Pemulihan berbasis SACK hanya mentransmisi ulang segmen yang hilang daripada seluruh window.
• Local acknowledgment: Proxy sisi dekat langsung meng-ACK pengirim, mencegah TCP pengirim terhenti sementara data melewati hop satelit.
• Kompresi dan deduplikasi: Deduplikasi tingkat byte dan kompresi mengurangi volume data yang melintasi tautan satelit — sangat efektif untuk pola lalu lintas enterprise yang berulang.

Kompromi

Akselerasi TCP bukan tanpa peringatan:

• Lalu lintas terenkripsi: Enkripsi TLS/SSL end-to-end mencegah proxy dari memeriksa header dan payload TCP. Solusinya meliputi konfigurasi VPN split-tunnel, manajemen sertifikat yang sadar proxy, atau akselerasi di tingkat tunnel daripada tingkat aliran.
• Kekhawatiran split-TCP: Beberapa arsitektur keamanan melarang split-TCP karena memecah model integritas end-to-end. Dalam lingkungan ini, akselerasi mungkin terbatas pada kompresi dan optimasi protokol tanpa terminasi TCP.
• Relevansi LEO: Pada tautan LEO dengan RTT 20–40 ms, akselerasi TCP memberikan manfaat marjinal untuk sebagian besar aplikasi. Manfaat utama beralih dari mitigasi latensi ke kompresi dan deduplikasi untuk penghematan bandwidth.

---

Integrasi SD-WAN dan Satelit

Platform SD-WAN modern — Cisco Viptela, Fortinet, VMware VeloCloud, Cradlepoint, Peplink — menyediakan integrasi native dengan transport satelit. SD-WAN menambahkan path steering cerdas ke perangkat QoS, memungkinkan keputusan lalu lintas real-time berdasarkan kualitas tautan yang terukur.

Path Steering

SD-WAN secara terus-menerus memprobe setiap jalur WAN yang tersedia (fiber, LTE, satelit) untuk latensi, jitter, packet loss, dan bandwidth yang tersedia. Kebijakan berbasis kesadaran aplikasi mengarahkan lalu lintas ke jalur optimal:

• VoIP → satelit LEO atau LTE (jalur latensi terendah)
• ERP/SaaS → fiber utama, LEO sekunder
• Transfer massal → satelit GEO (kapasitas tertinggi, toleran latensi)
• Kesejahteraan kru → satelit dengan pembatasan rate

Untuk penerapan multi-orbit yang menggabungkan LEO dan GEO, path steering SD-WAN memungkinkan pola arsitektur yang dijelaskan dalam Jaringan Satelit Hybrid & Multi-Orbit.

Active/Active Satelit dan Terestrial

Ketika tautan satelit dan terestrial tersedia bersamaan, SD-WAN dapat beroperasi dalam mode active/active — mendistribusikan lalu lintas di kedua jalur secara bersamaan. Konfigurasi ini memerlukan koordinasi QoS yang cermat untuk memastikan bahwa lalu lintas yang diklasifikasikan untuk perlakuan latensi rendah tidak diarahkan ke jalur satelit GEO berlatensi tinggi.

Praktik terbaik: Definisikan kebijakan SLA aplikasi yang mencakup latensi maksimum yang dapat diterima. Kontroler SD-WAN akan secara otomatis mengecualikan jalur yang melebihi ambang batas SLA untuk setiap kelas aplikasi, mencegah kesalahan routing bahkan dalam konfigurasi active/active.

Penanganan Failover dan Brownout

Tautan satelit paling berharga selama gangguan terestrial — momen ketika QoS paling penting. SD-WAN harus menangani dua skenario:

• Hard failover: Tautan terestrial mati sepenuhnya. Semua lalu lintas berpindah ke satelit. Kebijakan QoS harus segera membatasi lalu lintas agregat ke CIR tautan satelit untuk mencegah membanjiri modem satelit.
• Brownout: Tautan terestrial terdegradasi (peningkatan packet loss, lonjakan latensi) tanpa gagal sepenuhnya. SD-WAN harus secara selektif memindahkan aplikasi sensitif latensi ke satelit sambil mempertahankan lalu lintas massal di tautan terestrial yang terdegradasi, mengurangi beban pada satelit.

---

Daftar Periksa Konfigurasi Praktis

Daftar periksa berikut menyediakan kerangka kerja langkah demi langkah untuk mengimplementasikan QoS pada tautan satelit. Ini berlaku untuk penerapan baru maupun tautan yang sudah ada yang memerlukan peningkatan QoS.

Langkah 1: Baseline Tautan

• Ukur committed information rate (CIR) dan peak information rate (PIR) dari kontrak penyedia layanan satelit.
• Lakukan tes throughput selama jam puncak dan off-peak untuk menetapkan kapasitas dunia nyata.
• Ukur latensi, jitter, dan packet loss baseline.
• Identifikasi variasi throughput terkait ACM dengan memantau SNR modem dan perubahan modcod.

Langkah 2: Inventarisasi Aplikasi

• Katalogkan semua aplikasi yang menggunakan tautan satelit, kebutuhan bandwidth, sensitivitas latensi, dan kritikalitas bisnis mereka.
• Tetapkan setiap aplikasi ke kelas lalu lintas (biasanya 4–6 kelas).
• Tentukan penandaan DSCP untuk setiap kelas.

Langkah 3: Rancang Kebijakan QoS

• Alokasikan bandwidth ke setiap kelas lalu lintas sebagai persentase dari CIR (bukan PIR — PIR tidak dijamin).
• Konfigurasi strict priority queue untuk lalu lintas real-time dengan batas rate.
• Konfigurasi CBWFQ untuk kelas lalu lintas yang tersisa.
• Atur shaping rate ke CIR pada perangkat edge pelanggan.

Langkah 4: Implementasi dan Uji

• Terapkan kebijakan QoS pada antarmuka yang menghadap satelit.
• Hasilkan lalu lintas sintetis untuk setiap kelas dan verifikasi bahwa prioritas, jaminan bandwidth, dan batas rate berfungsi sesuai harapan.
• Uji dalam kondisi kemacetan — jenuhkan tautan dan verifikasi bahwa lalu lintas prioritas tinggi terlindungi.

Langkah 5: Pantau dan Setel

• Lacak utilisasi bandwidth per-kelas, drop antrian, dan latensi secara terus-menerus. Untuk praktik terbaik pemantauan dan rekomendasi alat, lihat Network Management.
• Tetapkan ambang batas peringatan untuk kedalaman antrian, tingkat drop, dan waktu respons aplikasi.
• Tinjau dan sesuaikan alokasi setiap kuartal atau ketika campuran aplikasi berubah.

---

Pertanyaan yang Sering Diajukan

Apa itu QoS pada satelit dan apa bedanya dengan QoS terestrial?

QoS pada satelit menerapkan mekanisme klasifikasi, queuing, dan shaping yang sama seperti jaringan terestrial, tetapi dengan penyetelan spesifik satelit untuk latensi tinggi, bandwidth terbatas, kapasitas bersama, dan throughput variabel yang disebabkan cuaca dan ACM. Perbedaan mendasar adalah bahwa jaringan terestrial sering kali dapat menghindari QoS melalui overprovisioning bandwidth — tautan satelit tidak bisa. Setiap megabit pada tautan satelit jauh lebih mahal daripada bandwidth terestrial, dan kapasitas tautan dapat berubah secara dinamis akibat rain fade atau kemacetan, menjadikan kebijakan QoS esensial daripada opsional.

Bagaimana latensi tinggi memengaruhi kualitas VoIP pada satelit?

Latensi satelit GEO (RTT 480–600 ms) terasa dalam percakapan suara dan melebihi rekomendasi ITU-T G.114 sebesar 150 ms delay satu arah. Pengguna mengalami percakapan tumpang tindih dan ritme percakapan yang tidak alami. Latensi LEO (20–40 ms) berada dalam batas yang dapat diterima untuk sebagian besar aplikasi suara. Pada tautan GEO, QoS harus menjamin strict priority untuk paket suara, dan jitter buffer harus dikonfigurasi pada 150–200 ms. Menggunakan codec bitrate rendah (G.729, Opus) esensial untuk meminimalkan bandwidth yang dikonsumsi lalu lintas suara pada tautan satelit yang terbatas.

Metode queuing mana yang paling cocok untuk satelit — priority queuing, WFQ, atau CBWFQ?

CBWFQ dengan strict priority queue untuk lalu lintas real-time adalah standar industri untuk tautan satelit. Priority queuing murni berisiko membuat lalu lintas non-real-time kelaparan selama periode puncak. WFQ murni tidak menyediakan jaminan latensi ketat yang dibutuhkan suara dan video. CBWFQ menggabungkan keduanya: strict priority untuk lalu lintas real-time (dengan batas rate untuk mencegah kelaparan) dan weighted fair queuing untuk semua kelas lalu lintas lainnya, menyediakan pendekatan seimbang yang melindungi baik aplikasi sensitif latensi maupun aplikasi sensitif throughput.

Apakah saya memerlukan akselerasi TCP pada tautan satelit LEO?

Pada tautan LEO dengan RTT 20–40 ms, akselerasi TCP memberikan manfaat latensi yang terbatas — TCP berkinerja cukup baik pada waktu round-trip ini. Namun, akselerasi TCP masih dapat memberikan nilai melalui kompresi, deduplikasi, dan optimasi protokol yang mengurangi volume data yang melintasi tautan satelit. Untuk tautan GEO, akselerasi TCP sangat direkomendasikan dan dapat meningkatkan throughput 2–10x tergantung pada jenis aplikasi dan pola lalu lintas.

Bagaimana cara menangani QoS selama peristiwa rain fade?

Rain fade mengurangi throughput yang tersedia saat modem beralih ke skema modulasi yang lebih tahan. Kebijakan QoS harus dirancang untuk berfungsi dengan benar pada throughput yang berkurang — yang akan terjadi jika shaping dikonfigurasi ke CIR (rate minimum yang dijamin). Jika CIR dipertahankan selama fade, kebijakan QoS terus beroperasi secara normal. Jika fade cukup parah untuk mengurangi throughput di bawah CIR, strict priority queue melindungi suara dan video sementara kelas prioritas lebih rendah mengalami peningkatan delay dan kemungkinan drop. Memantau SNR modem dan status modcod membantu operator mengantisipasi dan merespons peristiwa fade.

Bisakah SD-WAN menggantikan QoS tradisional pada tautan satelit?

SD-WAN melengkapi QoS tetapi tidak menggantikannya. SD-WAN menambahkan path steering — kemampuan untuk merutekan lalu lintas melintasi beberapa tautan WAN berdasarkan pengukuran kualitas real-time. Tetapi begitu lalu lintas berkomitmen ke jalur satelit, QoS di tingkat antarmuka (klasifikasi, queuing, shaping) tetap diperlukan untuk mengelola bagaimana lalu lintas tersebut bersaing untuk kapasitas terbatas tautan satelit. Penerapan terbaik menggunakan SD-WAN untuk keputusan antar-jalur dan QoS tingkat antarmuka untuk prioritas intra-jalur.

Berapa persentase bandwidth yang harus saya alokasikan untuk suara pada tautan satelit?

Titik awal umum adalah 10–15% dari CIR untuk lalu lintas suara. Menggunakan codec G.729 (8 kbps per panggilan ditambah header), tautan 10 Mbps dengan alokasi suara 15% mendukung sekitar 150 panggilan bersamaan. Alokasi sebenarnya tergantung pada jumlah pengguna suara bersamaan di situs. Mengalokasikan suara secara berlebihan membuang kapasitas yang bisa melayani aplikasi data; mengalokasikan terlalu sedikit menyebabkan degradasi kualitas suara. Mulai dengan 15%, pantau metrik kualitas panggilan (MOS, jitter, packet loss), dan sesuaikan berdasarkan penggunaan yang diamati.

Bagaimana cara mengimplementasikan pembagian bandwidth yang adil antara kru dan operasional di kapal maritim?

Pisahkan lalu lintas kru dan operasional ke VLAN atau SSID yang berbeda. Terapkan kebijakan QoS yang menjamin persentase bandwidth minimum (biasanya 50–60%) untuk lalu lintas operasional terlepas dari permintaan kru. Dalam VLAN kru, implementasikan pembatasan rate per-pengguna untuk mencegah pengguna individu memonopoli bandwidth. Batasi aplikasi intensif bandwidth (streaming video HD, unduhan besar) di jaringan kru. Selama operasi kritikal atau cuaca buruk, aktifkan override kebijakan yang mengalokasikan 100% kapasitas untuk lalu lintas operasional.

---

Poin-Poin Utama

• QoS wajib pada tautan satelit — kelangkaan bandwidth, latensi tinggi, dan kapasitas bersama membuat tautan tanpa pengelolaan tidak dapat digunakan untuk aplikasi enterprise.
• Lakukan shaping ke CIR, bukan PIR — kapasitas burst menghilang selama kemacetan, yang tepat ketika QoS paling penting.
• Gunakan CBWFQ dengan strict priority — suara dan video real-time mendapat perlakuan prioritas dengan batas rate; aplikasi bisnis mendapat bandwidth terjamin; lalu lintas massal mendapat sisanya.
• Akselerasi TCP esensial pada GEO — bandwidth-delay product dari tautan berlatensi tinggi mencegah TCP standar memanfaatkan kapasitas yang tersedia.
• SD-WAN melengkapi tetapi tidak menggantikan QoS — gunakan SD-WAN untuk path steering antar tautan dan QoS tingkat antarmuka untuk prioritas dalam tautan satelit.
• Rancang untuk kondisi terdegradasi — rain fade, kemacetan, dan skenario failover adalah saat kebijakan QoS membuktikan nilainya.
• Pantau secara terus-menerus — utilisasi per-kelas, drop antrian, waktu respons aplikasi, dan SNR modem menyediakan telemetri yang diperlukan untuk menyetel dan memvalidasi kebijakan QoS.
• Situs maritim dan terpencil memerlukan aturan keadilan eksplisit — tanpa kontrol per-pengguna dan per-aplikasi, lalu lintas kesejahteraan kru akan membanjiri sistem operasional.

---

Artikel Terkait

• Enterprise Satellite Internet Guide
• Satellite Latency Comparison
• Rain Fade in Satellite Communications
• Hybrid Satellite Network & Multi-Orbit
• Network Management
• Satellite Backhaul Explained
• VSAT Network Architecture
• Maritime Satellite Internet
• Satellite Modulation and Coding Guide
• How Satellite Internet Works