Перейти к содержанию
    

Нет никаких кластерных деревьев в ZigBee.

Есть только иерархическая маршрутизация и сеточная.

MAC уровень вообще не поддерживает никакой маршрутизации.

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

 

А вот как у них с поддержкой ZigBee 2006?

Зато обещают открыть исходники под MAC-уровень. Там и формочка соотвествующая имеется. А Freescale - это для "толстых клиентов" больше.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Нет никаких кластерных деревьев в ZigBee.

Есть только иерархическая маршрутизация и сеточная.

MAC уровень вообще не поддерживает никакой маршрутизации.

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

Видимо, вы что-то попутали. В самом Zigbee действительно нет понятия "кластерное дерево" (оно есть в IEEE 802.15.4), в Zigbee структура сети называется просто "дерево", но суть та же самая.

Второй вопрос заключается в том, как выполняется маршрутизация пакетов в сети с такой структурой. В Zigbee есть 2 варианта маршрутизации:

  • маршрутизация по дереву (или иерархическая, как вы ее назвали)
  • реактивная маршрутизация
Вы правы в том, что MAC-уровень не имеет отношения к маршрутизации.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

http://www.meshnetics.com/downloads/MAC/

В общем-то ничего и не изменилось, по-прежнему только обещание.

Но в принципе исходники сейчас не проблема, в том или ином виде их дают многие производители.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Реактивная маршрутизация это тоже термин мало уместный.

С понятием кластер вы сами запутались.

Термин "кластер" в ZigBee определяет набор аттрибутов и ни в каком другом значении не применяется.

Кластеры в 802.15.4 остались только на бумаге. ZigBee многи положения 802.15.4 просто игнорирует.

Видов маршрутизация в ZifBee 2006 будет поболее чем вы перечислили, но иерархическая среди них всегда основная поскольку остальные только опциональные и могут в принципе не быть реализоваными или не работать из-за отсутствия ресурсов.

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

А вот "реактивной" маршрутизации нигде не описано.

 

 

Нет никаких кластерных деревьев в ZigBee.

Есть только иерархическая маршрутизация и сеточная.

MAC уровень вообще не поддерживает никакой маршрутизации.

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

Видимо, вы что-то попутали. В самом Zigbee действительно нет понятия "кластерное дерево" (оно есть в IEEE 802.15.4), в Zigbee структура сети называется просто "дерево", но суть та же самая.

Второй вопрос заключается в том, как выполняется маршрутизация пакетов в сети с такой структурой. В Zigbee есть 2 варианта маршрутизации:

  • маршрутизация по дереву (или иерархическая, как вы ее назвали)
  • реактивная маршрутизация
Вы правы в том, что MAC-уровень не имеет отношения к маршрутизации.

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

 

 

Очень интересно, кто дает? Кроме Microchip-а, конечно.

 

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

http://www.meshnetics.com/downloads/MAC/

В общем-то ничего и не изменилось, по-прежнему только обещание.

Но в принципе исходники сейчас не проблема, в том или ином виде их дают многие производители.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Реактивная маршрутизация это тоже термин мало уместный.

С понятием кластер вы сами запутались.

Термин "кластер" в ZigBee определяет набор аттрибутов и ни в каком другом значении не применяется.

Кластеры в 802.15.4 остались только на бумаге. ZigBee многи положения 802.15.4 просто игнорирует.

Видов маршрутизация в ZifBee 2006 будет поболее чем вы перечислили, но иерархическая среди них всегда основная поскольку остальные только опциональные и могут в принципе не быть реализоваными или не работать из-за отсутствия ресурсов.

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

А вот "реактивной" маршрутизации нигде не описано.

Что будет в Zigbee 2006 представляю только в общих чертах, поэтому говорить буду только о Zigbee 2004.

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

Действительно, основым методом маршрутизации является иерархическая (в стандарте она также называется маршрутизация по дереву).

Я не помню, чтобы второй способ маршрутизации имел какое-то явное название в стандарте. В нем используются таблицы маршрутизации, но называть его маршрузацией на основе таблиц маршрутов неправильно. Согласно действиям, которые выполняются в этом способе маршрутизации, его следует отнести к классу алгоритмов, которые обычно называются on-demand или reactive. Так что не знаю почему вас смущает термин "реактивная маршрутизация".

Очень интересно, кто дает? Кроме Microchip-а, конечно.

Извиняюсь за то, что в вел в заблуждение, но я имел в виду, что многие производители дают в том или ином виде реализацию стека. В большинстве случаев предоставляется объектый код. Например, maxstream и jennic. Насколько их реализация полная и соответствует стандарту не знаю, т.к. не рассматривал.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Не подскажете ли источник где используется термин "реактивная" маршрутизация.

Очень необычный термин, предпологаю что там будут и другие необычные идеи.

 

Слово "кластер" по отношению к структуре сети я бы предложил не использовать чтобы не вводить неопределенность при обсуждении спецификации (всетаки он там используется по другому назначению).

Кластер у вас как я понял будет соответствовать термину "звезда" в спецификации.

Но звезды может и не быть, если в сети все дивайсы роутеры (или как говорят FFD дивайсы)

Я думаю, что так даже удобнее делать сеть, во всяком случае многие производители в свои Starter KIT-ы вкладывают только FFD дивайсы. Реально дивайс использующий батарейное питание т.е. RFD дивайс в сети ZigBee наверно будет только пульт дистанционного управления. Ко всем остальным легче провести 220, чем обслуживать смену батареек у них в самые неподходящие моменты.

 

Насчет маршрутизации.

 

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

 

Что будет в Zigbee 2006 представляю только в общих чертах, поэтому говорить буду только о Zigbee 2004.

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

Действительно, основым методом маршрутизации является иерархическая (в стандарте она также называется маршрутизация по дереву).

Я не помню, чтобы второй способ маршрутизации имел какое-то явное название в стандарте. В нем используются таблицы маршрутизации, но называть его маршрузацией на основе таблиц маршрутов неправильно. Согласно действиям, которые выполняются в этом способе маршрутизации, его следует отнести к классу алгоритмов, которые обычно называются on-demand или reactive. Так что не знаю почему вас смущает термин "реактивная маршрутизация".

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Не подскажете ли источник где используется термин "реактивная" маршрутизация.

Очень необычный термин, предпологаю что там будут и другие необычные идеи.

 

Слово "кластер" по отношению к структуре сети я бы предложил не использовать чтобы не вводить неопределенность при обсуждении спецификации (всетаки он там используется по другому назначению).

Кластер у вас как я понял будет соответствовать термину "звезда" в спецификации.

Но звезды может и не быть, если в сети все дивайсы роутеры (или как говорят FFD дивайсы)

Я думаю, что так даже удобнее делать сеть, во всяком случае многие производители в свои Starter KIT-ы вкладывают только FFD дивайсы. Реально дивайс использующий батарейное питание т.е. RFD дивайс в сети ZigBee наверно будет только пульт дистанционного управления. Ко всем остальным легче провести 220, чем обслуживать смену батареек у них в самые неподходящие моменты.

 

Насчет маршрутизации.

 

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

Источников с термином reactive очень много, можете просто набрать в гугле что-то типа "on demand reactive". Просто раньше было принято очень грубо разделять алгоритмы маршрутизации на proactive и reactive по тому в какие моменты времени происходит создание маршрутов.

 

По поводу терминологии. Согласен, что есть некоторая путаница в терминах, в том числе и по вине самого альянса.

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

 

Ну в принципе вам никто не мешает построить сеть из одних FFD, но это все равно не решает всех проблем.

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Опять мне двусмысленность кажется в ваших рассуждениях.

 

В спецификации ZigBee обычно не объясняется откуда ноги растут, и интересно что думает народ познакомившейся с ней. Но некоторые вещи мне кажется там разжеваны достаточно.

 

Всетаки сеть ZigBee по типу построения это иерархическое дерево которое может иметь звезды на концах а может и не иметь если состоит из одних FFD.

И вот в сети с такой организацией возможна сеточная маршрутизация, или наверно вернее маршрутизация по произвольному пути. Так что, назовем от этого эту сеть mesh сетью?

Так сеть ZigBee это дерево или mesh-сеть?

А ведь в ZigBee 2006 есть еще маршрутизация сразу к группе узлов и маршрутизация типа все к одному.

Мне кажется ZigBee сеть в любом случае является деревом.

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

 

Источников с термином reactive очень много, можете просто набрать в гугле что-то типа "on demand reactive". Просто раньше было принято очень грубо разделять алгоритмы маршрутизации на proactive и reactive по тому в какие моменты времени происходит создание маршрутов.

 

По поводу терминологии. Согласен, что есть некоторая путаница в терминах, в том числе и по вине самого альянса.

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

 

Ну в принципе вам никто не мешает построить сеть из одних FFD, но это все равно не решает всех проблем.

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Опять мне двусмысленность кажется в ваших рассуждениях.

 

В спецификации ZigBee обычно не объясняется откуда ноги растут, и интересно что думает народ познакомившейся с ней. Но некоторые вещи мне кажется там разжеваны достаточно.

 

Всетаки сеть ZigBee по типу построения это иерархическое дерево которое может иметь звезды на концах а может и не иметь если состоит из одних FFD.

И вот в сети с такой организацией возможна сеточная маршрутизация, или наверно вернее маршрутизация по произвольному пути. Так что, назовем от этого эту сеть mesh сетью?

Так сеть ZigBee это дерево или mesh-сеть?

А ведь в ZigBee 2006 есть еще маршрутизация сразу к группе узлов и маршрутизация типа все к одному.

Мне кажется ZigBee сеть в любом случае является деревом.

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

Давайте по порядку.

 

Во-первых, FFD и RFD - это понятия стандарта 802.15.4, в Zigbee же устройства бывают ZC, ZR и ZED, т.е. Zigbee-координатор, маршрутизатор и оконечное устройство. ZC может быть PAN-координатор 802.5.14. А FFD устройство может быть как оконечным устройством, так и маршрутизатором, это зависит от вашего желания.

 

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

 

Так вот в Zigbee процесс маршрутизации выглядит следующим образом:

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

Таким образом, основным методом является реактивная маршрутизация. Естественно, если ресурсов для нее нет, то возможна только маршрутизация по дереву.

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

 

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

 

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

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

 

Таково мое мнение.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В ZigBee явно не хватает раздела "Лучшие практики", где говорилось бы как планировать и развертывать сеть для конкретных применений.

 

А так приходится спорить.

 

Понятия FFD и RFD на самом деле используются в ZigBee, а именно в таблице NodeDescriptor Т.е. на уровне приложения мы можем и должны ориентироваться с кем имеем дело. Поскольку никто не запрещает устройствам мимикрировать (т.е. прикидываться конечным узлом когда он на самом деле может быть роутером). Это может понадобится в ситуациях когда устройство как роутер не может подключиться к сети из-за ограничеий профиля и присоединяется как конечное устройство, и такие ситуации надо распознавать считая их ошибками планирования сети.

Далее.

Да, параметр nwkUseTreeRouting может принимать значение FALSE, но по умолчанию он TRUE и нет примитивов которые с уровня приложения могли бы его изменить, т.е. юзер не может решать на каждом конкретном узле использовать или нет иерархическую маршрутизацию.

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

И еще совсем не ясно сможет ли вообще быть осуществлен сервис связывания и сервис центров доверия без иерархической маршрутизации.

 

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

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

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

 

 

Давайте по порядку.

 

Во-первых, FFD и RFD - это понятия стандарта 802.15.4, в Zigbee же устройства бывают ZC, ZR и ZED, т.е. Zigbee-координатор, маршрутизатор и оконечное устройство. ZC может быть PAN-координатор 802.5.14. А FFD устройство может быть как оконечным устройством, так и маршрутизатором, это зависит от вашего желания.

 

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

 

Так вот в Zigbee процесс маршрутизации выглядит следующим образом:

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

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

 

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

 

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

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

 

Таково мое мнение.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В ZigBee явно не хватает раздела "Лучшие практики", где говорилось бы как планировать и развертывать сеть для конкретных применений.

 

А так приходится спорить.

 

Понятия FFD и RFD на самом деле используются в ZigBee, а именно в таблице NodeDescriptor Т.е. на уровне приложения мы можем и должны ориентироваться с кем имеем дело. Поскольку никто не запрещает устройствам мимикрировать (т.е. прикидываться конечным узлом когда он на самом деле может быть роутером). Это может понадобится в ситуациях когда устройство как роутер не может подключиться к сети из-за ограничеий профиля и присоединяется как конечное устройство, и такие ситуации надо распознавать считая их ошибками планирования сети.

Далее.

Да, параметр nwkUseTreeRouting может принимать значение FALSE, но по умолчанию он TRUE и нет примитивов которые с уровня приложения могли бы его изменить, т.е. юзер не может решать на каждом конкретном узле использовать или нет иерархическую маршрутизацию.

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

И еще совсем не ясно сможет ли вообще быть осуществлен сервис связывания и сервис центров доверия без иерархической маршрутизации.

 

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

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

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

 

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

 

Теперь к практике.

 

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

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

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

 

С моей точки зрения, количество маршрутизаторов следует минимизировать не потому что они сами по себе дороги. Между оконечным устройством и маршрутизатором разница заключается по сути в требуемом объеме памяти программ и ОЗУ. Сегодня на себестоимость железа это влияет мало, а в дальнейшем разница будет только уменьшаться.

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

О! Тут я с вами согласен. Спорить больше не о чем.

Жалко только профилей. Они были единственной зацепкой через которую можно было подключиться к чужим дивайсам.

Из спецификации 2006 выкинули даже те крохи про профили которые были в 2004.

Теперь видимо это секретная информация. Придется ждать утечек из Альянса или платить бабки за кота в мешке.

 

 

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

 

Теперь к практике.

 

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

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

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

 

С моей точки зрения, количество маршрутизаторов следует минимизировать не потому что они сами по себе дороги. Между оконечным устройством и маршрутизатором разница заключается по сути в требуемом объеме памяти программ и ОЗУ. Сегодня на себестоимость железа это влияет мало, а в дальнейшем разница будет только уменьшаться.

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

О! Тут я с вами согласен. Спорить больше не о чем.

Жалко только профилей. Они были единственной зацепкой через которую можно было подключиться к чужим дивайсам.

Из спецификации 2006 выкинули даже те крохи про профили которые были в 2004.

Теперь видимо это секретная информация. Придется ждать утечек из Альянса или платить бабки за кота в мешке.

Рад, что взаимопонимание найдено.

 

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

Да и вообще любое коммерческое использование Zigbee требует вступления в альянс.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Хм... Видел черновики по двум новым профилям из Z2006. Толстые профили, скажу я вам. (Home automation и Commercial automation). Имхо HA мнооого проще чем CA.

Про маршрутизацию - просвещаемся, господа:

http://en.wikipedia.org/wiki/Ad_hoc_routing_protocol_list

ZigBee2004 использует алгоритм Ad-hoc On-demand Distance Vector (AODV). У данного протокола много недостатков, которые описаны на указанном ресурсе.

Про "деревья": Та реализация "дерева", которая есть в Z2004 плоха тем, что "вытянутые" деревья (много ретрансляций) там не поддерживаются (адресов не хватит). Изменения сетевого уровня в Z2006 достаточны для ухода от этих недостатков.

 

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

Да и вообще любое коммерческое использование Zigbee требует вступления в альянс.

 

В общем-то так во всех _стандартных_ системах принято. И в Bluetooth денег надо платить (кстати больше, чем в ZigBee Alliance) и в WiFi...=)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вот еще своих 5копеек вставлю=)...

Провели испытания отладочного набора 1321XNSK от Freescale. Интересные результаты- модули прошли испытания на температурный диапазон на ура. В диапазоне от -40 до +85С при мощности 0dBm отклонение LQI составляло максимум 4-5dBm. Што касается дальности то тут канешно результаты похуже - при мощности передатччика в 3dBm устоичивый конект был лишь при прохождении сигнала через 1 етаж железобетонных перекрытий. Смещение (максимальное) по оси Х не больше 20 метров (учитывая что модуль был в металической коробке), отклонение по оси Y на втором етаже не больше 5м для устоичивого сигнала. Тест на открытой местности показал максимум 300м без выносных антен...

 

Результаты делайте сами....

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...