Mesh сеть между подвижными объектами., Подходит ли ZigBee? Опции

[galjoen]

Задача передачи телеметрии от экскаваторов/бульдозеров/самосвалов в карьере в диспетчерскую. Сразу скажу, что GSM там нет, иначе было бы просто, а Ирридиум дорог.
Вот подумываю о ZigBee, прочитал описание XBee. Но, насколько я понимаю, это не совсем то, т.к. сеть должна постоянно перенастраиваться - никаких роутеров, закреплённых в фиксированном месте, там быть не должно.
Так же подумываю использовать только физику ZigBee, а всё остальное сделать самому (на базе готового стека, конечно). Получается, что в сети должны быть только broadcast сообщения т.к. маршруты будут постоянно меняться. И наличие координатора тут не имеет смысла.
Понравился вариант на ATmega128RFR2, смущает только низкая максимальная выходная мощность передатчика. Какая реально дальность связи достижима? Или можно усилить?
Про ограничения в курсе.

[Pasha_a13]

Добрый вечер!
Возник такой вопрос связанный с маршрутизацией пакетов.
Например у нас узлы расположены как показано на рисунке:

Штриховкой показаны зоны покрытия узлов.
Узел 0 начинает искать узел 4. При этом он посылает броадкаст.
Его слышит только узел 1, который в свою очередь ретранслирует этот броадкаст дальше.
Далее ретранслированный узлом 1 пакет принимают узлы 2 и 3, которые в свою очередь ретранслируют пакет дальше.
Однако нюанс в зонах покрытия - узлы 1 и 3 находятся на краях зон покрытия друг друга и соответственно качество этого участка варьируется довольно сильно от окружающей радиочастотной обстановки, т.к. уровень приема на границе шумов фактически.
Однако броадкаст от узла 1 доходит до узла 3 быстрее, т.к. узел 2 ретранслирует пакет, а следовательно вносит задержку.
По принципам маршрутизации броадкаст пакетов узел 3 ретранслирует броадкаст полученный от узла 1 и дальше отсекает все остальные броадкасты, в том числе и от узла 2.
В итоге путь от узла 0 до узла 4 выстраивается по цепочке 0-1-3-4, хотя с точки зрения качества связи пожалуй лучше было бы выстроить по пути 0-1-2-3-4...хоть узел 2 и увеличивает путь, однако обеспечивает более качественную связь.
Как решаются подобного рода проблемы в беспроводных сетях?
Дело в том что у меня фактически именно топология где нет возможности размещать большое количество узлов чтобы у пакета была большая вариативность маршрута(т.к. каждый узел это деньги), а в основном узлы расположены по цепочке.

[ataradov]

Однако броадкаст от узла 1 доходит до узла 3 быстрее, т.к. узел 2 ретранслирует пакет, а следовательно вносит задержку.
По принципам маршрутизации броадкаст пакетов узел 3 ретранслирует броадкаст полученный от узла 1 и дальше отсекает все остальные броадкасты, в том числе и от узла 2.
В итоге путь от узла 0 до узла 4 выстраивается по цепочке 0-1-3-4, хотя с точки зрения качества связи пожалуй лучше было бы выстроить по пути 0-1-2-3-4...хоть узел 2 и увеличивает путь, однако обеспечивает более качественную связь.

Тут много не верных предположений.
1. Для поиска маршрута используется не настоящий броадкаст, а локальный, который принимактся только узлами, которые в непосредственной зоне слышимости.
2. Каждое принимающее устройство генерирует новый Route Discovery Request, так как в нем меняется полезная нагрузка - суммарный LQI или число хопов через которые прошел пакет или любая другая метрика показывающая качество связи. Для фиксации повторов используется Route Discovery Table, из которой по адресу источника и назначения ясно участвуем мы уже в этом поиске или еще нет.
3. Устройство назначения принимает все ответы не зависимо от времени их прихода (в переделах максимального времени поиска маршрута, конечно).
4. Устройство назначения отвечает только если у нового пакета показатель качества (всего маршрута) лучше чем у того, на который ответили ранее. Таким образом ответ на самый лучший маршрут уйдет последним.

[Pasha_a13]

Тут много не верных предположений.
1. Для поиска маршрута используется не настоящий броадкаст, а локальный, который принимактся только узлами, которые в непосредственной зоне слышимости.
2. Каждое принимающее устройство генерирует новый Route Discovery Request, так как в нем меняется полезная нагрузка - суммарный LQI или число хопов через которые прошел пакет или любая другая метрика показывающая качество связи. Для фиксации повторов используется Route Discovery Table, из которой по адресу источника и назначения ясно участвуем мы уже в этом поиске или еще нет.

я наверное просто неправильно сформулировал по поводу route request.
Узел 0 шлет RREQ, его принимает узел 1, изменяет в нем число хопов, фиксирует качество связи, фиксирует этот пакет в своей таблице маршрутизации и сам снова генерирует RREQ с тем же порядковым номером и тем же NWKsrc, однако с новым числом хопов.
Далее этот пакет принимают узлы 2 и 3, каждый из которых так же в свою очередь изменяет пакет, фиксируют в таблицах и отправляют далее.
Однако узел 3 приняв пакет от узла 1 запомнил комбинацию "номер пакета+NWKsrc" и уже не пропустит пакет от узла 2, т.к. у него будет такая же комбинация "номер пакета+NWKsrc" как и у пакета от узла 1, да и в таблице узел 3 зафиксирует что когда нужно будет пересылать пакет с NWKdst=0, то его нужно отправлять узлу 1....а если он примет и перешлет еще пакет от узла 2, то тогда затрется эта запись.
Наверное я тут немного не до конца понял процесс фиксации записей в таблице...

Для фиксации повторов используется Route Discovery Table, из которой по адресу источника и назначения ясно участвуем мы уже в этом поиске или еще нет.

Я не понял что Вы имеете ввиду под тем участвуем ли мы уже в поиске или нет. Если можно, опишите пожалуйста поподробнее.

Я просто не соображу как фиксируются повторы в таблице. Ведь вроде бы в таблице фиксируется узел источник NWKsrc и NextHop к этому узлу.

[ataradov]

Узел 0 шлет RREQ, его принимает узел 1, изменяет в нем число хопов, фиксирует качество связи, фиксирует этот пакет в своей таблице маршрутизации и сам снова генерирует RREQ с тем же порядковым номером и тем же NWKsrc, однако с новым числом хопов.

Нет, так делать нельзя ни в коем случае. Если содержимое изменилось - это новый кадр с новым порядковым номером.

Я не понял что Вы имеете ввиду под тем участвуем ли мы уже в поиске или нет. Если можно, опишите пожалуйста поподробнее.

Теперь, так как номер изменился, все остальные устройства тоже примут этот запрос еще раз. Чтобы его не передавать еще раз на время поиска маршрута в Route Discovery Table (это не тоже самое что Routing Table и Dplicate Rejection Table) создается запись, ключом в этой таблице является пара (NwkSrc, NwkDst), где NwkSrc - адрес запрашивающего узла, NwkDst - адрес узла до которого ищем маршрут. Причем такая запись будет всегда уникальна, так как запрашивающее устройство не будет слать повторный запрос пока на нем самом есть запись в Route Discovery Table о том, что оно уже ищет этот маршрут.

Я просто не соображу как фиксируются повторы в таблице. Ведь вроде бы в таблице фиксируется узел источник NWKsrc и NextHop к этому узлу.

Уже как минимум 3 таблицы, уточняйте какая имеется в виду.

[Pasha_a13]

Я делал так что узел 0 шлет RREQ: (NWKsrc=0, MACsrc=0, NumberPacket=1, NWKdst=4, MACdst=0xFF, hop_cnt=0 )
принял узел 1, сделал у себя запись (destination = NWKsrc(из пакета=0), nextHop = MACsrc(из пакета=0)),
посылает дальше RREQ: (NWKsrc=0, MACsrc=1, NumberPacket=1, NWKdst=4, MACdst=0xFF, hop_cnt=1 ),
принял узел 2 сделал у себя запись (destination = NWKsrc(из пакета=0), nextHop = MACsrc(из пакета=1)),
посылает дальше RREQ: (NWKsrc=0, MACsrc=2, NumberPacket=1, NWKdst=4, MACdst=0xFF, hop_cnt=2),
в это же время пакет принял и узел 3, сделал у себя запись (destination = NWKsrc(из пакета=0), nextHop = MACsrc(из пакета=1)),
посылает дальше RREQ: (NWKsrc=0, MACsrc=3, NumberPacket=1, NWKdst=4, MACdst=0xFF, hop_cnt=2),
просто дальше в моем варианте получается если узел 3 принял ретранслированный пакет от узла 2, то фактически ему нужно затереть запись (destination (=0), nextHop (=1)) и вместо нее будет запись (destination(=0), nextHop (=2)).
Однако когда будет идти RREQ от узла 4 через узел 3, то он пойдет только по последнему пути, т.к. через 2, а не через 1.

Теперь, так как номер изменился, все остальные устройства тоже примут этот запрос еще раз. Чтобы его не передавать еще раз на время поиска маршрута в Route Discovery Table (это не тоже самое что Routing Table и Dplicate Rejection Table) создается запись, ключом в этой таблице является пара (NwkSrc, NwkDst), где NwkSrc - адрес запрашивающего узла, NwkDst - адрес узла до которого ищем маршрут. Причем такая запись будет всегда уникальна, так как запрашивающее устройство не будет слать повторный запрос пока на нем самом есть запись в Route Discovery Table о том, что оно уже ищет этот маршрут.

Начинаю понимать что я упустил основной момент - именно что есть 3 таблицы а не одна....

Александр, посоветуйте пожалуйста хороший источник где было бы подробно описано по поводу этих трех таблиц, потому что из оригинального описания AODV маршрутизации я так до конца и не понял по поводу этих таблиц.

[ataradov]

Александр, посоветуйте пожалуйста хороший источник где было бы подробно описано по поводу этих трех таблиц, потому что из оригинального описания AODV маршрутизации я так до конца и не понял по поводу этих таблиц.

AODV - это только поиск маршрута, к нему относится только одна таблица - Route Discovery Table.

Независимо от способа поиска маршрута (хоть руками вбивайте) для маршрутизации необходима Routing Table. AODV в эту таблицу заносит информацию о найденном маршруте.

И независимо даже от наличия маршрутизации требуется Duplicate Rejection Table - для удаления повторных кадров.

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