lamone.my.id

Off-Grid Communication • Panduan Teknis

Arsitektur Jaringan Komunikasi Darurat LoRa Multi-Hop: Desain Node, Routing, dan Store-and-Forward

Ketika jaringan seluler dan internet terputus akibat bencana, komunikasi antarposko, relawan, dan warga dapat ikut terhenti. Radio komunikasi konvensional tetap berguna, tetapi tidak selalu menyediakan pencatatan pesan, pengiriman data sensor, atau mekanisme penerusan otomatis antarwilayah. Jaringan LoRa multi-hop menawarkan pendekatan berbeda: sejumlah node radio membentuk jalur komunikasi bertahap sehingga pesan dapat diteruskan melalui node perantara menuju titik tujuan. Namun, menambah jumlah node tidak otomatis membuat jaringan lebih andal. Desain harus memperhitungkan topologi, kualitas link, kapasitas kanal, energi, antrean pesan, dan perilaku jaringan ketika sebagian node gagal.

Daftar Isi

1. Memahami kebutuhan komunikasi sebelum memilih topologi
2. Peran node dalam jaringan multi-hop
3. Memilih topologi: rantai, pohon, atau mesh terbatas
4. Rancang paket pesan dan identitas node
5. Routing dan Store-and-Forward
6. Mengendalikan loop, duplikasi, dan kemacetan
7. Keamanan dan kepercayaan pesan
8. Menentukan perangkat dan sumber energi
9. Rencana pengujian dan metrik evaluasi
10. Kesimpulan: desain untuk kondisi gagal, bukan kondisi ideal
11. Pertanyaan yang Sering Diajukan

1. Memahami kebutuhan komunikasi sebelum memilih topologi

Mulailah dari skenario operasi, bukan dari daftar modul. Tentukan siapa yang berkomunikasi, informasi apa yang dikirim, seberapa sering pesan dibuat, berapa lama keterlambatan masih dapat diterima, dan siapa yang bertugas menerima pesan. Pesan teks singkat, koordinat lokasi, status posko, dan telemetri sensor memiliki kebutuhan berbeda. Pesan darurat berprioritas tinggi tidak boleh tertahan di belakang data rutin.

Petakan lokasi posko, titik pengungsian, area blank spot, jalur evakuasi, dan kemungkinan lokasi node relay. Peta awal dapat memakai koordinat GPS, tetapi keputusan penempatan tetap perlu survei lapangan. Bukit, lembah, bangunan, vegetasi, ketinggian antena, dan orientasi perangkat dapat mengubah kualitas link secara signifikan.

2. Peran node dalam jaringan multi-hop

Arsitektur sederhana dapat terdiri atas node sumber, node relay, dan node tujuan atau gateway. Node sumber membuat pesan dari pengguna atau sensor. Node relay menerima paket, memeriksa identitas dan nomor urut, menyimpan pesan bila jalur berikutnya belum tersedia, lalu meneruskannya sesuai kebijakan routing. Node tujuan menerima pesan dan meneruskannya ke aplikasi lokal, layar posko, atau server ketika koneksi tersedia.

Pisahkan fungsi perangkat secara logis meskipun beberapa fungsi dapat berjalan pada perangkat keras yang sama. Misalnya, satu node dapat menjadi endpoint sekaligus relay. Untuk area dengan pasokan listrik terbatas, node relay yang selalu aktif perlu dirancang berbeda dari node pengguna yang hanya aktif saat mengirim pesan.

3. Memilih topologi: rantai, pohon, atau mesh terbatas

Topologi rantai mudah dipahami dan cocok untuk jalur komunikasi yang mengikuti koridor geografis. Kelemahannya, kegagalan satu relay dapat memutus jalur seluruh node di belakangnya. Topologi pohon membagi jaringan menjadi cabang, tetapi titik percabangan menjadi elemen penting yang perlu redundansi.

Mesh memungkinkan lebih dari satu jalur menuju tujuan. Ketika satu link memburuk, pesan dapat dialihkan melalui tetangga lain. Konsekuensinya adalah kebutuhan pengelolaan rute, pencegahan loop, pengendalian duplikasi, dan penggunaan kanal yang lebih disiplin. Untuk prototipe lapangan, mesh terbatas dengan jumlah tetangga dan hop yang dikendalikan sering lebih realistis daripada membangun routing dinamis kompleks sejak awal.

4. Rancang paket pesan dan identitas node

Setiap paket sebaiknya memiliki message_id unik, source_id, destination_id atau alamat grup, sequence_number, timestamp, priority, hop_count, time_to_live (TTL), payload_length, dan pemeriksaan integritas. Identitas pesan diperlukan agar penerima dapat mengenali duplikasi ketika relay mengirim ulang paket yang sama.

Jangan memasukkan data berlebihan. LoRa dirancang untuk komunikasi berdaya rendah dengan payload relatif kecil. Kirim ringkasan status atau koordinat yang dibutuhkan, bukan aliran video atau data besar. Jika data panjang harus dikirim, pecah menjadi fragmen dengan nomor bagian, batas ukuran, timeout, dan mekanisme pemulihan yang jelas.

5. Routing dan Store-and-Forward

Routing menentukan node berikutnya yang dipilih untuk mencapai tujuan. Untuk sistem awal, tabel tetangga dapat menyimpan node yang terdeteksi, kualitas link, waktu terakhir terlihat, dan estimasi biaya rute. Biaya rute tidak harus hanya berdasarkan RSSI. Pertimbangkan packet delivery ratio, jumlah hop, tingkat antrean, dan energi node.

Store-and-forward menangani situasi ketika jalur tidak tersedia. Node menyimpan pesan dalam antrean persisten, lalu mencoba mengirim ulang ketika kondisi memungkinkan. Gunakan TTL agar pesan kedaluwarsa tidak memenuhi memori, batas kapasitas antrean agar perangkat tidak kehabisan ruang, serta kebijakan prioritas agar pesan darurat didahulukan. Penyimpanan nonvolatile lebih aman daripada hanya mengandalkan RAM karena perangkat dapat restart atau kehilangan daya.

Tambahkan acknowledgement pada tingkat aplikasi bila pengirim perlu mengetahui bahwa pesan telah diterima tujuan, bukan hanya diterima relay pertama. Bedakan status queued, forwarded, delivered, expired, dan failed. Tanpa pembedaan ini, indikator 'terkirim' dapat menyesatkan operator.

6. Mengendalikan loop, duplikasi, dan kemacetan

Setiap relay harus memeriksa apakah message_id sudah pernah diproses. Paket duplikat tidak perlu diteruskan berulang kali. TTL atau batas hop mencegah pesan berputar tanpa akhir. Terapkan backoff acak untuk mengurangi tabrakan ketika beberapa node mencoba mengirim bersamaan.

Gunakan jadwal akses kanal atau aturan prioritas yang sederhana dan terdokumentasi. Terlalu banyak ACK, beacon, dan retransmisi dapat memenuhi kanal. Catat alasan paket dibuang, antrean penuh, atau kedaluwarsa agar masalah dapat dianalisis setelah simulasi maupun uji lapangan.

7. Keamanan dan kepercayaan pesan

Jaringan darurat tidak boleh menganggap semua paket yang diterima pasti sah. Minimal, autentikasi pesan dan pemeriksaan integritas perlu dipertimbangkan agar node palsu tidak mudah menyisipkan instruksi. Untuk komunikasi yang memuat identitas atau lokasi warga, batasi data pada yang benar-benar dibutuhkan dan tentukan siapa yang boleh membaca informasi tersebut.

Gunakan kunci yang dikelola secara terencana, prosedur penggantian perangkat, dan pencatatan node yang diizinkan. Enkripsi tidak mengatasi seluruh risiko: perangkat yang dicuri, kunci yang bocor, atau pesan palsu dari pengguna sah tetap memerlukan mitigasi operasional.

8. Menentukan perangkat dan sumber energi

Prototipe dapat menggunakan mikrokontroler seperti ESP32 yang terhubung ke transceiver LoRa, antena yang sesuai, catu daya stabil, dan enclosure lapangan. GPS dapat ditambahkan pada node bergerak atau node yang perlu melaporkan koordinat. Gateway dapat dilengkapi penyimpanan lokal dan antarmuka ke server, tetapi fungsi komunikasi inti sebaiknya tetap berjalan ketika server tidak tersedia.

Untuk node off-grid, hitung konsumsi energi pada mode transmit, receive, idle, dan sleep. Jangan memakai angka deep-sleep mikrokontroler sebagai estimasi konsumsi keseluruhan karena modul radio, regulator, GPS, indikator, dan kebocoran rangkaian juga memakai energi. Ukur arus pada kondisi kerja sebenarnya, lalu tentukan kapasitas baterai dan panel surya dengan margin untuk cuaca buruk dan hari tanpa pengisian.

9. Rencana pengujian dan metrik evaluasi

Uji sistem secara bertahap: komunikasi satu hop, dua hop, beberapa relay, putusnya satu relay, node mati mendadak, antrean penuh, dan pemulihan setelah daya kembali. Uji pula pesan prioritas tinggi ketika kanal sibuk. Catat kondisi lokasi, tinggi antena, konfigurasi radio, cuaca, dan waktu pengujian agar hasil dapat diulang.

Gunakan packet delivery ratio, end-to-end latency, hop count, packet loss, jumlah retransmisi, waktu pemulihan rute, umur antrean, konsumsi energi, dan keberhasilan pengiriman setelah koneksi pulih. Jangan hanya melaporkan jarak terjauh. Jarak tanpa data reliabilitas tidak cukup untuk menyimpulkan jaringan layak digunakan dalam keadaan darurat.

10. Kesimpulan: desain untuk kondisi gagal, bukan kondisi ideal

Jaringan LoRa multi-hop yang berguna bukan sekadar kumpulan radio yang dapat saling mendengar. Ia membutuhkan identitas pesan, routing terkendali, penyimpanan persisten, pengendalian duplikasi, prioritas, keamanan, dan prosedur operasi. Mulailah dari topologi sederhana, ukur performanya, lalu tambahkan redundansi berdasarkan bukti lapangan. Sistem harus tetap dapat menjelaskan status pesan ketika jalur terputus, bukan hanya menampilkan ikon sinyal.

Pertanyaan yang Sering Diajukan

Apakah LoRa multi-hop sama dengan LoRaWAN?

Tidak. LoRa adalah teknologi lapisan fisik/modulasi, sedangkan LoRaWAN adalah protokol jaringan dengan arsitektur umumnya star-of-stars. Multi-hop yang meneruskan paket antarnode memerlukan mekanisme routing dan forwarding tersendiri, kecuali memakai sistem yang memang mendukungnya.

Berapa jumlah hop yang ideal?

Tidak ada angka universal. Jumlah hop harus ditentukan melalui pengujian latency, reliabilitas, airtime, kapasitas kanal, dan energi pada kondisi lokasi yang dituju.

Apakah relay harus selalu terhubung ke internet?

Tidak. Relay dapat meneruskan pesan secara lokal. Gateway internet hanya diperlukan jika data akan disinkronkan ke layanan jarak jauh ketika koneksi tersedia.

Apakah RSSI cukup untuk memilih rute?

Tidak. RSSI berguna, tetapi perlu dilengkapi packet delivery ratio, SNR, tingkat antrean, jumlah hop, dan kondisi energi.

Artikel Terkait di Lamone

• LoRa Mesh dan LoRaWAN untuk Off-Grid Communication
• Store-and-Forward: Cara Mengirim Pesan Tanpa Internet
• Komunikasi Darurat Tanpa Internet: Membangun Jaringan Off-Grid
• Cara Menguji Jangkauan LoRa di Pegunungan: LOS vs NLOS

Referensi dan Dokumentasi Teknis

• LoRa Alliance - What is LoRaWAN?
• Semtech - SX1278 LoRa Transceiver
• LoRa Alliance - LoRaWAN Specification v1.1

Catatan teknis: Artikel ini merupakan panduan desain dan pengujian. Parameter radio, frekuensi, daya pancar, dan tata cara penggunaan harus diverifikasi terhadap regulasi yang berlaku serta datasheet perangkat. Hasil jangkauan dan keandalan tidak dapat dijamin tanpa pengujian pada lokasi sebenarnya.

Terakhir ditinjau: November 2026. Perbarui tautan internal dan parameter teknis jika ada perubahan standar, firmware, perangkat, atau regulasi.