[ataradov 0]

Так а на сетевом уровне задержка все равно остается 10-50 мс или в случае ответа на броадкаст без этой большой задержки нужно передавать?

Все с задержками.

 

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

Времена очень приблизительные и верны для 2.4 ГГц. В IEEE 802.15.4 все задержки описаны в символах, так как длительность символа зависит от вида модуляции. В этом очень сильное преимущество использования стандартных радио - все это уже было посчитано и смоделировано умными дядями из IEEE. Для 2.4 GHz O-QPSK модуляции один символ = 16 мкс.

 

[User1285 0]

Добрый день, Александр!

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

Пока что работает нестабильно, но все равно это уже лучше чем то что было :)

Спасибо Вам за помощь! :)

[User1285 0]

Добрый вечер!

Возник такой вопрос связанный с маршрутизацией пакетов.

Например у нас узлы расположены как показано на рисунке:

Штриховкой показаны зоны покрытия узлов.

Узел 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 0]

Однако броадкаст от узла 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. Устройство назначения отвечает только если у нового пакета показатель качества (всего маршрута) лучше чем у того, на который ответили ранее. Таким образом ответ на самый лучший маршрут уйдет последним.

[User1285 0]

Тут много не верных предположений.

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]

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

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

 

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

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

 

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

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

 

[DASM 0]

Например ZigBee хорош для небольшой группы летательных аппаратов - типа стая. Которой можно управлять.

ОФФ - скоро уже пора будет делать ракеты самонаведения по таким стаям ;)

[User1285 0]

Я делал так что узел 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 0]

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

 

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

 

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

 

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

 

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

[User1285 0]

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

 

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

 

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

 

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

Теперь мне понятно почему я нашел информацию только относительно одной таблицы. У Перкинса в RFC3561 было написано что-то по поводу того что seq# отвечает за свежесть маршрута и т.п., что нужно следить за этим, но как именно и что делать я так толком и не понял.

а в самом zigbee при поиске маршрута эти все вещи учитываются? там тоже 3 таблицы используются?

Хотя чипы для zigbee вроде как только физический уровень обеспечивают типа задержек при передаче и т.п., а остальное программист должен делать?

Изменено 5 августа, 2013 пользователем Pasha_a13

[ataradov 0]

У Перкинса в RFC3561 было написано что-то по поводу того что seq# отвечает за свежесть маршрута и т.п., что нужно следить за этим, но как именно и что делать я так толком и не понял.

Версия в RFC включает последовательный номер в каждый поиск (это не имеет отношения к номерам из заголовков пакетов, они живут своей жизнью и по своим правилам).

 

а в самом zigbee при поиске маршрута эти все вещи учитываются? там тоже 3 таблицы используются?

В ZigBee Duplicate Rejection Table разделена на две - Duplicate Rejection Table для дубликатов и Broadcast Transaction Table для отслеживания состояния броадкастов, так как там для них сложные правила пересылки (некоторые повторяются 3 раза, некоторые повторяются 2 раз, некоторые совсем не повторяются, и есть еще Passive Ack). В ZigBee есть еще туча других таблиц (Neighbour Table, например).

 

Lightweight Mesh - это попытка объединить функции всех этих таблиц в абсолютно минимальный набор.

 

 

Хотя чипы для zigbee вроде как только физический уровень обеспечивают типа задержек при передаче и т.п., а остальное программист должен делать?

Да, для этого производители и выпускают стеки.

 

Чипы реализуют физический уровень IEEE 802.15.4. ZigBee - это один из многих протоколов использующих этот уровень.

 

[User1285 0]

Lightweight Mesh - это попытка объединить функции всех этих таблиц в абсолютно минимальный набор.

Читаю документацию по lightweight mesh и вспоминаю что я когда начинал заниматься этой темой то именно рисунки 4-8...4-13 из множества литературы по маршрутизации самым доходчивым образом показывали как заносить данные в таблицу.

Завтра постараюсь понять как в lightweight mesh решается проблема на которую я наткнулся(имею ввиду ту картинку с 5-ю узлами), потому что уже понял что сделать полноценную маршрутизацию со всеми таблицами, оптимальными путями и т.п. будет для меня явно неподъемно.

А у меня еще такой вопрос - а как во всех этих протоколах беспроводных передаются длинные пакеты?

я наткнулся на проблему что у меня скорость передачи порядка 19кБит, при этом у меня есть длинные пакеты с информацией длиной порядка 40 байт. При этом по времени эта посылка занимает где-то около 40мс(между соседними узлами, а если с ретрансляцией то до 200мс и больше). И получается что короткие посылки(порядка 15 байт) проходят практически все, а вот длинные посылки бьются. Мне просто нужно передавать массив данных порядка 200-300 байт и разбивать их на пакеты по 5-10 байт вроде как-то не хочется.

Или в таком случае для таких объемов данных нужно поднимать скорость передачи?

Изменено 5 августа, 2013 пользователем Pasha_a13

[ataradov 0]

В IEEE 802.15.4 довольно навороченный способ определения наличия несущей на канале, там пакеты просто так не бьются.

 

Ограничение на физический размер кадра - 127 байт (1 байт на размер). После заголовков в LwMesh остается 109 байт полезной нагрузки.

 

Для передачи больших объемов данные разбиваются на мелкие куски и передаются отдельно.

[User1285 0]

В IEEE 802.15.4 довольно навороченный способ определения наличия несущей на канале, там пакеты просто так не бьются.

я просто сегодня занимался с радиосистемой, пакеты бегали, изредка бились, но черед некоторое время по соседству включили пилораму. После ее включения длинные пакеты у меня перестали проходить в большинстве случаев :(. Частоты у меня 300-400МГц. Вроде как не должна пилорама влиять на это все, но видать где-то всетаки какие-то проблемы возникают(устройства питались от батарей, потому на помехи по сети не могу грешить).

 

 

Дело в том что я так понял получается проблема другого вида - у меня узел смотрит уровень сигнала относительно уровня шума(который постоянно отслеживается), и когда канал свободен то начинает передачу. И по всей видимости помеха ловит пакет где-то во время передачи. При этом я не контролирую саму передаваемую информацию на предмет коллизии, у меня нет такой возможности. И избыточности у меня тоже нет. Принятый пакет просто отбрасывается принявшим узлов ввиду того что не сходиться CRC.

[ataradov 0]

я просто сегодня занимался с радиосистемой, пакеты бегали, изредка бились, но черед некоторое время по соседству включили пилораму. После ее включения длинные пакеты у меня перестали проходить в большинстве случаев :(. Частоты у меня 300-400МГц. Вроде как не должна пилорама влиять на это все, но видать где-то всетаки какие-то проблемы возникают(устройства питались от батарей, потому на помехи по сети не могу грешить).

На диапазон 2.4 GHz некоторые микроволновки влияют, но та, что у нас в офисе никакого значительного влияния не оказывает. Вообще на 2.4 обычно сравнительно чисто, только Wi-Fi в непосредственной близости уровень шумов поднимает, но на качество связи это мало влияет.

 

Но если в используемом диапазоне есть сильные помехи, то софтом дело не решить особо, только выкручиваться мелкими кадрами, подтверждениями и переповторами.

 

 

И по всей видимости помеха ловит пакет где-то во время передачи.

Чудес не бывает и ZigBee тоже можно убить такими помехами, другой вопрос, что их просто нет в нормальных условиях.

 

У нас клиенты использовали 900 MHz радио на стройке для автоматизации всего и вся - полет нормальный, хотя и сварка рядом и много железа ездит.