Всем привет
Мне предстоит сделать сеть девайсов на CC430. Самих мартышек ещё нет, пока только въезжаю в тему, поэтому вопрос совсем нубский
Питание у девайсов батарейное, большую часть времени проводят в спячке, территориально разнесены могут быть далеко от точки доступа (вне досягаемости), но в то же время ретрансляторы нельзя использовать (как пишут в мануале, потому как они должны быть включены всегда). Там же пишут что нет возможности store-and-forward для p2p соединений и explicit routing shall not be supported. Собственно вопрос: можно ли программно реализовать динамическую маршрутизацию на p2p соединениях чтобы девайсы вне досягаемости точки доступа всё же могли до неё достучаться по цепочке p2p соединений?

Сколковец?
На динамической маршрутизации и сложных топологиях в западных университетах делают ученые степени.
Общий принцип такой: для маршрутизации нужна энергия на транзитных узлах. Либо ваши узлы экономят энергию в спячке и вы забываете про маршрутизацию либо они все время работают на прием и/или посылают зондирующие пакеты чтобы оперативно перестраивать таблицы маршрутизации. Вы хотите чтобы все узлы были с батарейным питанием. Транзитный узел святым духом будет уведомляться что ему нужно принять пакет от узла вне досягаемости базы ??? Прчем дальний узел может еще и не быть синхронизирован с остальной частью сети.

ОК, а если забыть про батарейное питание. Сам протокол теоретически позволит реализовать это при условии что все всегда включены но без range extender-ов?

Делать свою хопинговую сеть.

Возможен компромис.Вся система должна работать по жестким таймингам и соответственно ретрансляция возможна только во время активного состояния.Это приведет к бОльшим затратам энергии и сложностям с синхронизацией.Но компромис он на то и компромис....

Сообщение отредактировал PlainUser - Feb 16 2012, 10:50

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

Добрый день!
Скажите пожалуйста Вам удалось реализовать динамическую маршрутизацию на симплисити?

Нет, от симплисити отказались. Помучившись в итоге реализовали AODV протокол.

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

В симплисити хаб должен быть включен постоянно. Нам же требовалась mesh-сеть со спящими узлами

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

Сообщение отредактировал Pasha_a13 - Mar 25 2013, 08:42

Да я тоже далеко не супер спец чтобы советовать что-то конкретное. Начал самостоятельно с нуля, сейчас напарник тянет этот проект.
Мы использовали AODV протокол маршрутизации, про него pdf в аттаче. Он же используется в ZigBee так что можно про них почитать для ознакомления.
Вам конкретнее что требуется? Может и симплисити достаточно. Mesh сети сложнее. Если допустимо иметь выделенные ретранляторы, то симплисити вполне подойдёт

Я почитал про AODV и очень Вам благодарен за то что "ткнули носом" в него, потому что протоколов большое множество, я сначала углубился в протоколы типа RIP и т.п., а по самому ZigBee не нашел доходчивой спецификации или описания по самой маршрутизации.
Нашел документик от Freescale, они там описывают в общих чертах работу ZigBee, но хотелось бы поподробнее понять именно то что связано с маршрутизацией.
А почитав про AODV и понял что он близок к тому что мне нужно, довольно хорошо описаны общие принципы маршрутизации.
По поводу выделенных ретрансляторов в том то и дело что нужно чтобы все узлы сети были одинаковые, т.е. каждый совмещал в себе функции как конечного устройства так и ретранслятора.
У меня имеется беспроводная сеть датчиков охранные-умный дом и главный коммуникатор который подключен к главному управляющему блоку. Я использую топологию звезда и все работает.
Проблема возникает в том случае когда некоторые датчики по дальности не достают до коммуникатора.
Добавлять второй коммуникатор или выбирать место для его установки не всегда удобно, потому необходимо чтобы промежуточные датчики, которые находятся невдалеке от коммуникатора, взяли на себя роль ретрансляторов.
Плюс есть еще в системе беспроводные узлы которые обеспечивают удаленный 485-й для управления камерами, подключения клавиатур и других блоков, рассчитанных на работу по 485-му интерфейсу.
Пока не учитываю питание датчиков, спящие режимы, пока считаю что питать их буду постоянно от внешнего источника.
Важным нюансом является то что события от датчиков должны доставляться до коммутатора в наиболее короткие сроки, т.е. насколько много времени нужно датчику чтобы послать сообщение исходное на расчет маршрута (считаю что маршрут неизвестен пока), дождаться прихода ответа и послать тревожное сообщение...


Спасибо за документ приложенный!

Сообщение отредактировал Pasha_a13 - Mar 25 2013, 12:17

Это не совсем так. Для спящего режим возможна другая дисциплина обмена. Нужно чтобы на Join нашелся ответивший. Т.е. не спать должен тот, кому нужно передать - хаб очнулся, передал свой Join, а желающий(EP) тут же ему свой и понеслась. Пока передавать не нужно - EP спит и иногда выдает Join (для хаба, у которого вдруг найдётся что ему передать), как только нужно передать что-то важное - становится в приём и ждёт Join от хаба. В рамках SimpliciTI это реализуемо.

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