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

[galjoen]

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

[Pasha_a13]

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

Я прочитал документацию по Atmel Lightweight Mesh и у меня возникли пару вопросов.

Первый вопрос - я не совсем понял как ведет себя координатор после того как он инициировал route discovery, сколько времени он ожидает route reply от узла назначения и если route reply не пришел(узел назначения вне зоны досягаемости сети либо выключен), то делает ли он повторные попытки поиска узла назначения?

Второй вопрос - "4. If native route discovery is used and received frame had a unicast network address and broadcast MAC address (route discovery). In this case acknowledgment is used to facilitate discovery of the reverse route."(стр.20, вверху) - здесь под acknowledgment понимается пакет route reply или есть еще какие-то другие acknowledgment сообщения? Я просто не совсем понял какие есть acknowledgment пакеты в сети, т.е. в каких случаях они посылаются и понимаются ли под acknowledgment пакеты route reply и route error?

Я просто смотрю что в составе пакета есть бит Ack Request, который вроде как говорит узлу назначения нужен ли acknowledgment или нет. Какие именно пакеты и в каких случаях он отключает. Поясните пожалуйста, если можно.

Спасибо!

Сообщение отредактировал Pasha_a13 - Jul 30 2013, 19:57

[ataradov]

Первый вопрос - я не совсем понял как ведет себя координатор после того как он инициировал route discovery, сколько времени он ожидает route reply от узла назначения и если route reply не пришел(узел назначения вне зоны досягаемости сети либо выключен), то делает ли он повторные попытки поиска узла назначения?

Все ответы ожидаются NWK_ROUTE_DISCOVERY_TIMEOUT мс.
По истечении этого времени если не было принято ни одного ответа, то запрос подтверждается со статусом NWK_NO_ROUTE_STATUS. Никаких попыток повторно послать запрос не производится - приложение само может это сделать если хочет.
Так же можно раскомментировать строку 353 в nwkRouteDiscovery.c, тогда первый же принятый маршрут будет использован для отправки данных, но остальные ответы все-равно будут приняты для поиска более оптимального пути. Недостаток - пакету придется пробиваться сквозь тучу броадкастов от route discovery.

Второй вопрос - "4. If native route discovery is used and received frame had a unicast network address and broadcast MAC address (route discovery). In this case acknowledgment is used to facilitate discovery of the reverse route."(стр.20, вверху) - здесь под acknowledgment понимается пакет route reply или есть еще какие-то другие acknowledgment сообщения? Я просто не совсем понял какие есть acknowledgment пакеты в сети, т.е. в каких случаях они посылаются и понимаются ли под acknowledgment пакеты route reply и route error?

В native route discovery нет route request и route reply кадров. Каждый кадр сам себе пробивает дорогу - если маршрут не известен, то он просто отправляется с MAC Dst = 0xffff (broadcast). Таким образом когда кадр доходит до назначения маршрут в одну сторону известен. И чтобы завершить поиск маршрута (найти маршрут назад) отправляется обычное сетевое подтверждение, даже если подтверждение не запрашивали. Так как к подтверждениям применяются те же правила, оно самим фактом доставки прокладывает маршрут.

[Pasha_a13]

Все ответы ожидаются NWK_ROUTE_DISCOVERY_TIMEOUT мс.

Спасибо за такой быстрый ответ!

Тоесть NWK_ROUTE_DISCOVERY_TIMEOUT это фиксированная величина (1000мс) независимо от количества узлов и скорости передачи данных между узлами? Просто ведь если в сети например 300 узлов, задержка перед ретрансляцией пакета в диапазоне 1..32 мс....пусть мы берем плохой вариант - например средняя задержка 20 мс+5мс(сам пакет)=25 мс. Пусть топология сети выстроена таким образом что она растянута вдоль одной какой-то оси, т.е. узлы выстроены практически в линию. При этом даже если узел назначения будет находиться на расстоянии 50 узлов от координатора, то задержка от момента отправки запроса координатором до момента получения route reply составит 50*25мс*2(туда-обратно)=2500мс.
Или подразумевается что пользователь при настройке системы сам устанавливает NWK_ROUTE_DISCOVERY_TIMEOUT исходя из топологии сети и приблизительно оценив возможную задержку?

По истечении этого времени если не было принято ни одного ответа, то запрос подтверждается со статусом NWK_NO_ROUTE_STATUS. Никаких попыток повторно послать запрос не производится - приложение само может это сделать если хочет.

Запрос подтверждается это имеется ввиду что уровень приложения получит ответ от более низкого уровня а не от другого устройства?

Так же можно раскомментировать строку 353 в nwkRouteDiscovery.c, тогда первый же принятый маршрут будет использован для отправки данных, но остальные ответы все-равно будут приняты для поиска более оптимального пути. Недостаток - пакету придется пробиваться сквозь тучу броадкастов от route discovery.

Я понял что узел назначения приняв пакет route discovery от одного из узлов ожидает некоторое время других пакетов, тем самым во первых имея альтернативу для выбора пути с лучшими показателями качества, а во вторых за время ожидания большая часть броадкастов перестанет бегать по сети и пакету route reply(unicast)(либо просто пакет подтверждения) проще будет вернуться к кооординатору. Пакет route reply идет без всяких подтверждений? Просто ж во время движения если он наткнется на остатки броадкастов, то координатор его никогда не получит.....

В native route discovery нет route request и route reply кадров. Каждый кадр сам себе пробивает дорогу - если маршрут не известен, то он просто отправляется с MAC Dst = 0xffff (broadcast).

Я уже перечитал первый абзац и понял что недопонял сходу по поводу отсутствия отдельной процедуры поиска пути - подвело мое не сильно хорошее знание английского
Из каких соображений было выбрано именно чтобы целый пакет пробивал себе путь? Ведь в таком случае пакет может быть довольно большой(много данных) и в процессе пробивания дороги больше вероятность что он побьеться да и больше ж времена передачи пакета. Ведь вроде как удобнее чтобы сначала найти путь а потом юникастом отправить данные к назначению.

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

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

Сообщение отредактировал Pasha_a13 - Jul 30 2013, 20:48

[ataradov]

Или подразумевается что пользователь при настройке системы сам устанавливает NWK_ROUTE_DISCOVERY_TIMEOUT исходя из топологии сети и приблизительно оценив возможную задержку?

Именно это и подразумевается. Поэтому оно и вынесено в конфигурационный параметр, а не упрятано в исходниках.

Запрос подтверждается это имеется ввиду что уровень приложения получит ответ от более низкого уровня а не от другого устройства?

Нет. На уровне приложения есть возможность запросить подтверждение (NWK_OPT_ACK_REQUEST). Если оно запрошено, то принимающая сторона всегда посылает ответ. Если не запрошено, то ответ будет все-равно послан если nwkDst==<адрес устройства назначения>, а macDst= 0xffff (эта комбинация означает Native Route Discovery). В этом случае запрашивающая сторона ждать ответа не будет, и он просто будет проигнорирован, но как результат его прохождения будет найден маршрут.

Я понял что узел назначения приняв пакет route discovery от одного из узлов ожидает

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

Из каких соображений было выбрано именно чтобы целый пакет пробивал себе путь?

Из опыта. На практике кадры почти не бьются никогда, не зависимо от их размера.

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

Нет. Бит подтверждения - это именно бит подтверждения. Тот факт, что Ack используется для прокладки маршрута - это просто для удобства. Это могла быть совершенно независимая команда, но весь код для отправки Ack-ов и так есть, почему бы его не использовать?

[Pasha_a13]

Из опыта. На практике кадры почти не бьются никогда, не зависимо от их размера.

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

Сообщение отредактировал Pasha_a13 - Jul 30 2013, 21:01

[ataradov]

Подскажет пожалуйста как на нижнем уровне происходит отправка-ретрансляция броадкаст(либо других) пакетов?

Atmel-овские радио в соответствующем режиме всегда слушают канал, делают небольшую (порядка десятков мкс, единиц мс, прогрессивно увеличивающуюся с числом повторов) задержку если занято пробуют снова. Если за несколько повторов (4 по-умолчанию) не получилось отправить, то они сдаются и устанавливают соответствующий статус.

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

Если радио так не может, то нужно то же самое делать программно. Но тут есть туча тонкостей по времянкам и порогам наличия сигнала, которые в IEEE 802.15.4 хорошо выглажены, так что настройки по-умолчанию отлично работают в большинстве случаев.

Сообщение отредактировал Taradov Alexander - Jul 30 2013, 21:10

[Pasha_a13]

Александр, спасибо Вам большое! Понял свои ошибки, буду пытаться их исправлять.

По поводу порогов наличия сигнала вот тут действительно проблема получается когда есть например три устройства, одно из которых находиться далеко а два других не особо далеко друг от друга. Получается что когда уровень сигнала от дальнего устройства таков что на более ближнем к нему устройстве RSSI показывает лишь маленькую "надстройку" на уровне шумов, то другое(более дальнее) устройство вообще не видит ничего на RSSI и считает что канал свободен. тем самым получается что моментами пересекаются пакеты от крайних устройств(они просто не видят друг друга) и то устройство что находиться посредине нормально не принимает пакеты. Получается проблема скрытых узлов в чистом виде. Но я почитал, написано что проблему эту при броадкаст рассылке никак особо не решить, нужны именно пакеты с подтверждением, либо добавление в алгоритм предварительных запросов на передачу - но это опять таки юникаст пакеты уже получаются. Вообщем буду еще бороться с этим, эксперементировать.

[ataradov]

Опять-же при рассылке unicast-ов аппаратный Ack используется всегда и радио будет автоматически ждать этого Ack-а и пробовать пересылать если он не принят. При броадкасте - Ack не запросить, естественно.

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

А что за радио у вас используются?