Понял. Спасибо! Я так и делал, я просто думал может есть какой-то другой еще путь.
Хотя у меня там были некоторые "нюансы", которые нужно исправить и без них думаю будет работать боле корректно.

Только что делал обзор по этой тематике для руководства.

Из уже зарекомендовавших себя в разработках клиентов модулей:

Есть целая серия ZigBee модулей от Telit на различные дельности связи.
Под эту задачу подходит.

ZE61
Частота: 2.4-2.483 ГГц.
Дальность до 4000 м.
– 40 … +85ОС (industrial).
Выходная мощность 100 мВт (встроенный усилитель), чувствительность -99 дБм и улучшенная RF часть.
На основе чипа CC2430 от TI.
Стоимость - примерно 27 USD.
Дилер в РФ - ATOMA.

Что ещё... Тщательный анализ новостей и обновлённых даташитов производителей просто умилил. У многих вендоров, спустя года два-три (было и 4 года спустя), вдруг появляется радостный вопль в новостях "Теперь наш модуль ПОЛНОСТЬЮ соответствует стандарту
IEEE 802.15.4 / ZigBee !!!" О чём идёт речь? Как раз о том, что до этого момента сеть не поддерживала алгоритмы оптимизации своей связности и живущей на ней маршрутизации+алгоритмы безызбыточного повышения вероятности доставки сообщений в сторону "Мастера" и от него. И тут, наконец, стала это делать. Речь о том, куда были вынесены алгоритмы всех этих дел: на плечи конкретных разработчиков конкретных конечных устройств или же уже зашиты в самом модуле и используется по умолчанию, и для их активации нужны лишь небольшие настройки - мощность устройств, предпочтительная топология, скоростные ограничения, подчинённость (master/slave). Т.е. до этого момента шла речь о неких изделиях, которые лишь МОГУТ быть использованы в сетях ZigBee, при должных наворотах в обвязке этих модулей (включая управляющее ПО).

Это какие-то домыслы, за последние несколько лет ничего кардинально в имплементациях ZigBee не менялось.

Более того модулей и стеков "полностью соответствующих" стандарту нет в принципе. В настоящее время в тестовой спецификации есть пункты, которые выполнять не имеет смысла (очень много сервисов ZDO, которые сначала пихали в стек, а потом одумались и растащили по профилям, где они нужны).

Но это не страшно. Сертификация ZigBee построена по очень интересному принципу - производитель заявляет какие функции поддерживаются и потом только эти функции тестируются. Стек получатся сертифицированным только по этим пунктам. Так что просто "сертифицированного стека" не существует, есть только стеки сертифицированные по соответствующим PICS (Protocol Implementation Conformance Statement).

Уже сам понял. Когда создается запрос RouteDiscoveryRequest, то обнуляются reverseLinkQuality и forwardLinkQuality и когда пришел ответ, то его lqi не должно быть равно нулю.

entry->reverseLinkQuality содержит лучшее значение из тех, что мы видели. Какой смысл доставлять его, если заведомо известно, что мы уже отправили лучший маршрут?

Спасибо! Уже понял. Я в частности рассматривал случай когда координатор принял ответ, то у него по умолчанию записан ноль в lqi.


Т.е. получается что мы удаляем запись в RouteDiscoveryTable только по таймауту в независимости от того прошел через наш узел уже ответ RREP на этот RREQ или нет, и пока не удалили то сверяем лучше ли пришедший маршрут чем пропущенный ранее и если лучше то ретранслируем его?

Да. Нет гарантии, что первый прошедший ответ самый хороший. К моменту его прохождения еще не все узлы получили запрос обычно.

Спасибо!
да уж...с точки зрения логики тут все классно продумано и получается что один из самых важных моментов(даже скорее самый важный) для работы всей системы это именно правильный LQI, правильное его вычисление.
Т.е. фактически получается что как ни крути все-таки упираюсь в железо, в то что оно долно быть заточено под работу с подобными алгоритмами.

Программно можно накапливать статистику потерь и вычислять LQI исходя из них. Это не легко, но реализуемо. Так даже спецификация ZigBee предлагает делать если другие метрики работают плохо.

Т.е. что-то наподобии того чтобы на каждом из участков вести статистику по количеству принятых-битых пакетов от соседних узлов и исходя из статистики этой расчитывать LQI?

Да, LQI - это вероятность доставки кадра до узла.

Понял. спасибо! Буду думать в этом направлении