Автоорганизующаяся радио сеть

xelos · 17.02.2006, 14:05

Вобщем новый проектик на работе подкинули...

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

Kabron · 17.02.2006, 18:32

Сообщение от xelos

Вобщем новый проектик на работе подкинули...

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

Поищи по теме Intel Radio

17.02.2006, 18:54

Ключевое слово: ZigBee

xelos · 17.02.2006, 20:36

дальность известна?

Timoshenko · 18.02.2006, 11:16

Напиши лучше те требования к твоей сети (дальность, частоты, число абонентов(с учетом числа ретрансляторов), скорость передачи данных, шифрование и др.). Это раз.
Второе: ZigBee, как мне кажется, не самый лучший вариант, хотя опять же все зависит от конкретного применения, и тут тоже надо смотреть, кто из ZigBee альянса является поставщиком продукции

Третье: можешь поискать TINI OS - ребята из Беркли делают самоконфигурируемую сеть датчиков, но и тут возникают проблемы:
Восновном это деньги на разработку, то есть конечно можно купить приблуды tini os, только всеравно прийдется самим разрабатывать протокол маршрутизации (кстати, для зиг би, также можно разработать такой протокол), а вот сама разработка протокола стоит дорого и в России я знаю только одну группу, которая занимается разработкой протаколов маршрутизации беспроводных сетей связи (это не означает, что их нет совсем - это значит только то, что я знаю только одну группу, и то, которая ещё ничего не производит, и протокол у них, на сколько мне известно, ещё пока не отработан полностью, но общее програмное описание протокола и все его алгоритмы уже есть

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

И ещё вопрос:

Цитата:

суть такая. есть куча радио девайсов

Они уже имеются или предполагаются к закупке?

П.С. xelos, а если не секрет, как называется фирма? (

Цитата:

Вобщем новый проектик на работе подкинули...

)

Да, забыл сказать, дальность зигби можно до 800 метров в поле точно поднять, а в городе

xelos · 18.02.2006, 23:50

Сообщение от Timoshenko

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

требуемая дальность - от 500 м в открытом поле, желательно 1 км, частота из разрешенных для свободного пользования в Европе (860 MHz, 2,4GHz). Число ретрансляторов - максимум 15. Девайсы опрашиваются центральным компом, у них свой протокол, дальность 100 м. Ретрансляторы будут реализовывать, скорее всего, дополнительный протокол. Т.е. между собой ретрансляторы общаются по протоколу Ad-hoc и со второго передатчика, после преобразования сообщения, выдают данные по протоколу первичных девайсов. Пакет запроса - порядка 30 байт, пакет ответа, порядка 50 байт. Со скоростью особых проблем быть не должно.

Цитата:

И ещё вопрос:

Цитата:

суть такая. есть куча радио девайсов

Они уже имеются или предполагаются к закупке?

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

Цитата:

П.С. xelos, а если не секрет, как называется фирма?

фирма в Европе, девайс не для России. FENZY называется фирма. Специализированное профессиональное оборудование.

Timoshenko · 19.02.2006, 15:53

Тогда я не понимаю в чем заключается вообще твоя задача и проблема

Просто в софтварном описании преобразования данных? в этом вообще никаких проблем не должно быть

Под Ad-hoc, вообще сейчас понимается практически любая реализация сети с возможностью ретрансляции, поэтому зацикливаться на создании непременно разных протоколов не стоит. Кроме того, у меня вопрос: это на сколько я понял сенсорная сеть? (не большая скорость передачи данных, небольшое растояние)
На счет частоты, девайсы уже существуют, но вот непонятно, они одновременно с 2-я частотами работают (в режиме либо 860 либо 2.4 или в режиме и 860 и 2.4) или просто есть девайсы и на 860 и на 2.4 ? Просто для дальности 1 км мне кажется вполне хватит и пары приборов на 860 при не особо большой мощности передатчика, хотя мб я ошибаюсь, и вам надо по уровню сигнала быть тише воды ниже травы

Да, и ещё, разделение каналов какое предполагается?

xelos · 20.02.2006, 14:43

Сообщение от Timoshenko

Под Ad-hoc, вообще сейчас понимается практически любая реализация сети с возможностью ретрансляции, поэтому зацикливаться на создании непременно разных протоколов не стоит.

созданный девайс (датчики), сам по себе реализовать сеть AdHoc не сможет - памяти для реализации протокола нет.
Поэтому и требуется ретрансляция сигнала. На девайс общее ограничение по мощности (для использования в Hazardous areas), на передатчик осталось совсем ничего.

Цитата:

Кроме того, у меня вопрос: это на сколько я понял сенсорная сеть? (не большая скорость передачи данных, небольшое растояние)
На счет частоты, девайсы уже существуют, но вот непонятно, они одновременно с 2-я частотами работают (в режиме либо 860 либо 2.4 или в режиме и 860 и 2.4) или просто есть девайсы и на 860 и на 2.4 ? Просто для дальности 1 км мне кажется вполне хватит и пары приборов на 860 при не особо большой мощности передатчика, хотя мб я ошибаюсь, и вам надо по уровню сигнала быть тише воды ниже травы

девайсы могут работать только на 860МГц. Ретрансляторы должны принимать этот сигнал, а потом как угодно (можно 2 передатчика установить в ретранслятор на 860МГц и на 2,4ГГц).
Структура мне видится такая: Центральный комп отправляет запрос на 860МГц (в запросе 30 байт - адрес девайса, команда, доп информация и все), ретрансляторы принимают его и отправляют дальше с двух передачтиков (на 860МГц в формате, где датчик его понять может и ответить, если он в пределах досягаемости или 2,4ГГц(или другой частоте) с преобразованием протокола для динамической маршрутизации). Датчик, когда получает запрос по своему протоколу отвечает на своем же протоколе. Ретранслятор получает ответ и отсылает его по AdHoc. Чтобы ответ дошел до компа (на комп, возможно, придется ставить тоже передатчик AdHoc).

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

Цитата:

Да, и ещё, разделение каналов какое предполагается?

2 датчика одновременно отвечать не могут (типа Master/Slave на радиоконале). Все управляется с компа. Комп отсылает запрос и ждет ответ. Между ретрансляторами как угодно может быть.

Вобщем, есть входной/выходной протокол (формат запроса с компа и ответ датчика - пакеты 30-50 байт). Ретрансляторы реализуют передачу этих данных, с условием динамической маршрутизации. Т.е. преобразование протокола необходимо и это делает ретранслятор (ПК тоже может реализовать протокол динамической маршрутизации).

Уфф, не знаю понятно ли объясняю. Проблема - в выборе протокола с динамической маршрутизацией.

Timoshenko · 21.02.2006, 00:54

Все, теперь понял - временное разделение канала и сеть строится по запросу

Вообще в данном случае наиболее выгодный механизм широковещательной отправки сообщения (broadcasting): когда сначала на датчики с компа отсылается информация (через ретрансляторы), о готовности принять данные, и составляется пакет маршрута, по которому прошёл широковещательный сигнал, для наглябности рассмотрим систему:

А-компьютер
Вi-i-ый ретранслятор
Сk-k-ый датчик
Допустим компьютеру надо добраться до 4 датчика (С4), тогда в сеть выкидывается запрос на 4 датчик
т.е. из А информация попадает на В1 и например В5
следующий шаг, В1 и В5 повторяют запрос, но при этом у них хранится инфа откуда пришел запрос (что-бы знать куда его возвращать)
Дальше инфа попадает на В3 и В4 (например при распрастранениеии с В1)
Соответсвенно дальше её получит датчик по тому же механизму, и ответит, этот ответ услышит В3, по запомненному предыдущему пути отправит назад (на В1) а тот в свою очередь на А.

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

По поводу частот тут вообще на усмотрение реализатора системы, можно например на 2,4 организовать пакетный трафик между ретрансляторами, а на 860 опрос датчиков, причем датчик выдает о себе информацию раз в несколько например секунд, тогда можно "вести" датчик от одного ретранслятора к другому, и всегда любой ретранслятор будет знать де находится тот, или иной датчик и какой до него наименьший путь (частично реализация механизма по требованию, частично табличный метод маршрутизации)
А вообще, с компом конечно легче связываться по 2,4, а общаться на 860

Но всеравно, надо точно расписать временной интервал

Тут на картинке внизу попробовал изобразить, конечно не в масштабе, но поясняет, что вообще происходить должно, и примерно в какой последовательности

Надеюсь пока все понятно

-- Прилагается рисунок: --

xelos · 21.02.2006, 12:31

ура, проблема понята

для ретранслятора посмотрел, у чипкона есть серия СС24хх - ZigBee трансиверы. в 20 числах марта будет выставка с конференцией по теме:
http://www.rfhyper.com/eng/v_conf.htm
21 марта в 15-30. думаю съездить, послушать, что умные люди говорят.

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