Metode deteksi kegagalan tautan otomatis di jaringan ZigBee


8

Diberikan jaringan mesh ZigBee dengan beberapa node di dalamnya. Ada tautan yang dibuat antara setiap node melalui node router.

Jika Node A ingin mengirim pesan ke Node Z untuk pertama kalinya maka Node A harus melakukan Penemuan Rute untuk menentukan node perantara mana yang akan meneruskan pesannya.

Mekanisme Rute Penemuan dijelaskan di sini . Menurutnya rute dengan biaya terendah akan disimpan dalam Tabel Routing dari node.

Sejauh ini semuanya baik-baik saja, setiap node tahu apa yang harus dilakukan, mereka dapat saling menjangkau.


Sekarang, simpul perantara, antara Node A dan Node B rusak, sehingga rute yang saat ini disimpan menjadi tidak dapat digunakan.

Apa yang terjadi dalam kasus ini? Saya membayangkan bahwa ketika Node A ingin mengirim pesan, ia akan melakukan perjalanan ke tautan yang rusak di mana ia akan macet. Node terakhir dalam rute akan mengirim kembali pesan tentang kegagalan yang akan memicu Penemuan Rute baru oleh Node A , kemudian rute baru akan ditemukan dan semuanya akan baik-baik saja lagi.

Secara umum baik-baik saja (mengingat saya benar); jaringan pulih. Tetapi saya bertanya-tanya apakah ada algoritma atau metode yang menyediakan fitur pemantauan jaringan yang terus-menerus memeriksa status tautan yang disajikan dalam Tabel Routing. Jadi Node A dapat diberitahu tentang kegagalan sebelum ingin mengirim pesan lain ke Node Z , dan alih-alih menemui jalan buntu, ia dapat memulai dengan Penemuan Rute sekaligus. Jadi pada dasarnya yang saya pikirkan adalah layanan yang memeriksa tautan secara berkala.


Saya mengerti bahwa karena ZigBee biasanya digunakan pada baterai, perangkat berdaya rendah seperti mekanisme tidak akan hemat energi.

Jadi secara umum, apa yang sekarang merupakan mekanisme pendeteksian kegagalan tautan yang paling efektif yang dapat digunakan pada jaringan sensor nirkabel berdaya rendah, terutama di jaringan mesh ZigBee?

Jawaban:


4

Dari apa yang saya temukan, tampaknya beberapa implementasi (mis. TI Z-STACK ) merekomendasikan penyegaran tabel routing setiap kali untuk menghindari node 'mati' :

Ya, saya menunggu 5 hingga 10 menit. Apa itu "waktu"? Saya telah melihat kasus di mana dibutuhkan beberapa menit untuk pulih. Sebagai contoh, jika saya memutarkan daya pada gateway, mungkin diperlukan satu atau dua menit untuk menghubungkan node terdekat, lalu satu atau dua menit lagi untuk setiap tingkat berturut-turut. Tapi saya menunggu lebih lama dari ini agar mesh pulih dari perubahan rute ini.


Ya, mungkin butuh beberapa menit. Jadi, jika Anda ingin 5 atau menit, apakah perangkat Anda akan kembali? Disarankan untuk memanggil NLME_RouteDiscoveryRequest () secara berkala untuk mempertahankan tabel routing.

Anda dapat membaca lebih lanjut tentang apa yang NLME_RouteDiscoveryRequest()ada di panduan pengembang (lihat halaman 11/12):

Gambar berikut menunjukkan contoh prosedur penemuan rute banyak ke satu. Untuk memulai pencarian rute banyak-ke-satu, konsentrator menyiarkan permintaan rute banyak-ke-satu ke seluruh jaringan. Setelah menerima permintaan rute, setiap perangkat menambahkan entri tabel rute untuk konsentrator dan menyimpan tetangga satu hop yang menyampaikan permintaan sebagai alamat hop berikutnya. Tidak ada balasan rute yang akan dihasilkan.

Perintah permintaan rute banyak-ke-satu mirip dengan perintah permintaan rute unicast dengan ID perintah dan format bingkai payload yang sama. Kolom opsi dalam permintaan rute banyak-ke-satu dan alamat tujuan adalah 0xFFFC. Z-Stack API berikut dapat digunakan untuk konsentrator untuk mengirimkan permintaan rute banyak-ke-satu. Silakan lihat dokumentasi ZStack API untuk detail penggunaan tentang API ini.

ZStatus_t NLME_RouteDiscoveryRequest( uint16 DstAddress, byte options, uint8 radius )

Toleransi Kesalahan dalam Jaringan Sensor Nirkabel ZigBee adalah makalah yang menarik dengan beberapa informasi lebih lanjut tentang bagaimana jaringan ZigBee mentolerir kegagalan simpul. Tampaknya implementasi yang digunakan di sana merekonstruksi jaringan ketika salah satu node telah dihapus (sayangnya, metode ini tidak jelas), sehingga simpul yang tidak berfungsi tidak lagi termasuk dalam mesh. Dalam beberapa kasus, ini menyebabkan sensor menjadi 'yatim piatu' sebelum meminta untuk bergabung kembali dengan jaringan mesh melalui rute yang berbeda.

Singkatnya, dari sumber yang saya temukan: itu tergantung pada implementasi Anda, tetapi sebagian besar akan mengevaluasi ulang tabel routing cukup sering untuk menghindari node yang rusak dari merusak jaringan . Saya menduga Anda akan bisa mendapatkan respons yang lebih akurat jika Anda bertanya kepada vendor implementasi ZigBee spesifik Anda, karena operasi yang tepat akan bervariasi.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.