Kasus Penggunaan dan Pertimbangan untuk LoRaWAN

Catatan Penting: Link Labs adalah pembuat Symphony Link, protokol alternatif untuk LoRa yang berfokus pada kasus penggunaan industri dan perusahaan dengan keandalan tinggi. Selengkapnya di bawah.

Saat ingin memahami LoRaWAN dan kasus penggunaan idealnya, serta batasannya, penting untuk memahami sedikit sejarahnya. LoRaWAN (kemudian disebut LoRaMAC) dikembangkan oleh Semtech (pemilik tunggal IP PHY LoRa) bekerja sama dengan IBM Research (mereka kemudian meninggalkan proyek). Asumsi ketika protokol dirancang adalah:

• Untuk digunakan oleh Jaringan Operator Seluler
• Dalam Satu Jaringan Terkoordinasi
• Di Pita Tanpa Izin Frekuensi 868 MHz

Ini adalah asumsi penting, karena protokol yang dihasilkan memiliki:

• Batas Siklus Tugas 1% (untuk semua pemancar DAN gateway)
• Peta saluran frekuensi umum
• Pemrosesan MAC (Layer 2) hanya di awan

Untuk mendukung batasan siklus tugas 1% untuk gateway, khususnya, banyak pengorbanan yang diperlukan:

• Hampir semua pesan uplink tidak diakui
• Semua gateway dalam jangkauan melihat semua lalu lintas uplink
• Semua enkripsi ditangani menggunakan kunci statis

Karena semua pesan uplink tidak diakui dan tidak terkoordinasi, LoRaWAN dianggap sebagai skema "murni-aloha". Jaringan seperti itu memiliki efisiensi sekitar 18%. Ini berarti bahwa 82% paket hilang ketika jaringan LoRaWAN digunakan sepenuhnya. Karena sebagian besar pesan tidak diakui, simpul akhir tidak tahu bahwa pesannya tidak terjawab. Untuk mencegah hal ini, beberapa pengguna mungkin mengirimkan lebih sering, sehingga menambah masalah. Baca posting yang mudah dipahami ini tentang Aloha Networks.

Jika pengakuan ditambahkan ke sistem ini, efisiensi akan semakin gagal. Ini karena setiap kali base station melakukan transmisi, ia tidak dapat mendengarkan. Node akhir tidak tahu bahwa gateway tidak dapat mendengarnya. Karena gateway hanya dapat mengirimkan 1% dari waktu, ini hanya menghasilkan sekitar 1,65% kehilangan paket tambahan.

Selain itu, jika orang lain menggunakan jaringan LoRaWAN, semua lalu lintas mereka juga diperhitungkan terhadap kapasitas Anda. Ini karena semua gateway disetel ke frekuensi umum yang sama.

Pertimbangan penting lainnya untuk LoRaWAN adalah masalah dekat/jauh. Karena LoRa hanya memiliki rentang dinamis saluran bersama 20-30dB, node yang dekat dengan gateway menenggelamkan node yang jauh. Ini kurang menjadi perhatian di jaringan MNO besar, karena idealnya beberapa gateway berada dalam jangkauan.

Teman-teman kami di The Things Network juga telah menyusun bagian ini di Batasan LoRaWAN.

Semua yang dikatakan, kasus penggunaan yang ideal untuk LoRaWAN adalah:

• Sensor sederhana yang jarang dikirim
• Kehilangan 5-85% data terkadang tidak masalah
• Kemampuan kecil untuk mengontrol perangkat ini
• Tidak ada kemampuan untuk memperbarui firmware perangkat melalui udara
• Diterapkan dalam puluhan hingga ratusan
• Dapat menerapkan beberapa gateway untuk mencakup setiap node

Beberapa Pembacaan Meter Otomatis adalah contoh yang bagus dari kasus penggunaan yang baik untuk LoRaWAN. Untuk meter yang memperbarui pembacaan, katakanlah sekali per jam, tidak masalah jika beberapa pembacaan terlewatkan, selama beberapa berhasil melewatinya.

Symphony Link memecahkan banyak masalah ini. Secara singkat, begini caranya:

1. Pembingkaian: Gateway mengirimkan header frame setiap 2 detik, yang berisi informasi tentang saluran uplink mana yang tersedia dan kapan jendela uplink terbuka.

2. Pengakuan terkompresi: Di Symphony Link, secara default, semua pesan uplink diakui. Untuk mencapai hal ini, semua pengakuan digabungkan menjadi satu pesan terkompresi yang diterima oleh semua node (yang baru saja dikirim).

3. Variabel slot waktu uplink/downlink: Gateway memutuskan berapa lama waktu yang dibutuhkan untuk mengirimkan berdasarkan lalu lintas downlink yang antri. Ini memberitahu node ketika jendela downlink selesai, sehingga node tidak pernah mengirimkan ketika gateway tidak mendengarkan

4. Penempatan waktu uplink: Karena pembingkaian sinkron, jendela uplink ditempatkan yang menambah kapasitas sekitar 100% lebih banyak. Ini lebih ditingkatkan dengan menambahkan jendela CSMA variabel sebelum setiap transmisi.

5. Daya variabel dan faktor penyebaran: Node akhir menerima RSSI dari pesan pembingkaian gateway dan secara dinamis menyesuaikan kekuatan dan faktor penyebarannya agar sesuai dengan tautan ditambah faktor margin yang dapat diatur. Ini memaksimalkan kapasitas, mengurangi pemudaran cepat, dan mencegah masalah dekat/jauh yang disebutkan di atas.

6. Kualitas layanan: Node mendaftarkan faktor QOS (0-15) dengan gateway, dan ini membatasi kemampuannya untuk mengakses saluran di setiap frame. Ini juga menyediakan cara bagi gateway untuk membatasi uplink selama masa kemacetan.

7. Multicasting: Dengan menetapkan grup node ke dalam grup multicast, jumlah downlink yang diperlukan untuk kontrol dan streaming file menjadi terbatas.

8. Memperbaiki 256 byte MTU: 12 byte terlalu kecil untuk sebagian besar aplikasi. Symphony Link menyediakan 256 byte MTU tetap, dan menangani semua sub-paket (oleh SF) dan mencoba lagi di lapisan MAC.

9. Firmware melalui udara: Karena fitur multicast yang kuat di Symphony Link, file firmware dapat dikukus ke node.

10. Kunci AES sesi berbasis PKI: Symphony Link tidak menggunakan enkripsi kunci tetap. Setiap node membuat sesi AES yang aman menggunakan Diffie-Helmann, dengan kunci publik node yang disediakan oleh server. Ini dikenal di seluruh industri sebagai skema enkripsi saluran paling aman.

Ingin belajar lebih banyak? Hubungi kami.