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


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

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

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


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


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



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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

У меня используется TRC102 и диапазон 433МГц.
При таком желез все приходиться делать программно.
Т.е. я опытным путем подбирал минимальный порог RSSI при котором бы я не реагировал на шумы, но в то же время мог увидеть минимальный полезный сигнал чуть выше уровня шума и не передавать в это время, а ждать свободы канала. Потому получалось что когда я по логике ставил делать несколько попыток передать пакет а потом удалять его, то получилось что когда порог определения несущей низкий, то большая часть ретрансляторов получив пакет начинали пытаться через паузы прослушать канал, попадали на всякие помехи(а диапазон довольно грязный) и в результате после нескольких попыток передачи пакет просто удалялся даже не передавшись.

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

Сообщение отредактировал Pasha_a13 - Aug 1 2013, 16:09

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

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

я уже понял что как ни крути придется добавлять буфер принятых пакетов.
Я немного запутался с передачей пакета - ведь используется csma-ca алгоритм и перед передачей пакета сначала выдерживается пауза случайная а уже потом он передаеться. Или ответ на поиск маршрута узлом назначения передается без этой задержки как можно быстрее?

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

CSMA/CA - это не пауза, это то самое прослушивание канала в течение единиц мкс и быстрая передача если канал свободен. Паузы нужны для повторных попыток.

Так и нужно делать для AODV- маршрутизации.
Поля forwardLinkQuality, reverseLinkQuality в NwkRouteDiscoveryTableEntry_t в nwkRouteDiscovery.c - это накопленная прямая и обратная стоимость маршрута. Какой именно критерий брать за стоимость - это сами выбирайте. Это может быть уровень сигнала, число хопов, накопленная история по качеству связи или что-то еще.

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

Эти задержки тоже нужны.
Алгоритм передачи кадра:
1. Задержка на сетевом уровне (10-50 мс), можно только для броадкастов.
2. Задержка (10 мкс - 5 мс, причем верхняя граница плавно увеличивается с номером повтора начиная с совсем маленькой цифры, типа 20 мкс)
3. Слушаем канал как можно короче, но достаточно долго, чтобы определить наличие других передатчиков.
4. Если уровень ниже порога, то передаем кадр и выходим.
5. Если уровень выше порога: если число попыток < 4 то goto 2 иначе кадр не возможно отправить (Channel Access Failure).

ZigBee радио делают 2-5 автоматически.

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



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