ZigBee: взгляд вглубь
В предыдущем номере журнала мы начали рассказ о новом перспективном
и набирающем все большую популярность беспроводном стандарте связи ZigBee.
В материале были подробно освещены самые интересные с точки зрения разработчиков
электронных систем особенности и технические характеристики этого, пожалуй,
самого экономичного с точки зрения энергопотребления беспроводного стандарта.
Сегодняшний материал является продолжением начатой темы и более подробно
познакомит читателей с самой основой ZigBee — стандартом IEEE 802.15.4,
регламентирующим самый нижний физический уровень передачи данных (PHY)
и уровень управления доступом к беспроводной среде (MAC).
Для начала кратко напомним об основных осо
бенностях и назначении ZigBee. Этот беспро
водной стандарт предназначен для организа
ции низкоскоростных беспроводных персональных
сетей, так называемых LRWPAN (lowrate wireless
personal area network). Основное применение — раз
нообразные датчики, промышленное и медицинское
оборудование, «умные» дома и т. п. На фоне своих
конкурентов ZigBee выделяет, прежде всего, ориен
тация на следующие важнейшие моменты: простая
инсталляция, высокая надежность передачи данных,
сверхнизкая стоимость беспроводного решения
и особый упор на экономичное потребление. Крат
кие характеристики стандарта приведены в таблице 1.
Предполагается, что читатели уже знакомы с ос
новами ZigBee: организация сети, виды устройств
и т. д. Если же нет, то рекомендуем предварительно
почитать материал, опубликованный в журнале
«Компоненты и технологии», № 3’2005.
Итак, начнем. Как известно, любой популярный
стандарт обычно имеет в своей основе другой, часто
сокрытый от глаз постороннего наблюдателя. Напри
мер, в случае с Bluetooth это IEEE 802.15.1. Здесь мы на
блюдаем аналогичную ситуацию. «Фундамент» ZigBee
составляет спецификация IEEE 802.15.4. Именно она
отвечает за реализацию всех основных функций —
от физической передачи данных и объединения в сеть
до шифрования данных современными криптогра
фическими алгоритмами.
Для того чтобы понять, что же представляет собой
ZigBee, как такая беспроводная сеть функциониру
ет, как «дышит», что на самом деле передается по воз
духу помимо данных, как организуется доступ уст
ройств к сети и прочие тонкости, нам как раз и помо
жет IEEE 802.15.4.
Архитектура IEEE 802.15.4
Архитектура LR-WPAN сети, в общем, стандарт
на и очень схожа с классическими компьютерными
сетями. LR-WPAN состоит из набора «кирпичиков»,
слоев или уровней, соединенных между собой логи
ческими связями. Каждый слой отвечает за выпол
нение набора каких-то конкретных функций, а так
же предоставляет сервисы для вышестоящих уров
ней. Структура слоев IEEE 802.15.4 соответствует
стандартной общепринятой модели OSI (Open
Systems Interconnection).
Основным используемым методом доступа к фи
зической среде, предлагаемым стандартом, является
случайный доступ с контролем несущей и предот
вращением конфликтов — CSMA-CA (Carrier Sense
Multiple Access with Collision Avoidance). Здесь также
реализованы и такие дополнительные функции, как
детектирование энергии (ED — Energy detection)
и индикатор качества соединения (LQI — Link quality
indication). Для передачи могут использоваться 16 ка
налов в диапазоне 2450 МГц, 10 каналов в диапазоне
915 МГц и 1 канал на частоте 868 МГц.
Стандарт IEEE 802.15.4 реализует два важнейших
уровня сети — физический уровень передачи данных
(PHY — Physical Layer), описывающий низкоуровне
вый механизм управления радиочастотным приемо
передатчиком, и уровень управления доступом к бес
проводной среде (MAC — Medium Access Control),
отвечающий за доступ к физическим каналам всех
типов обращений вышестоящих уровней (рис. 1).
Уровень LLC (Logical Link Control) отвечает за управ
ление логическим соединением — это верхний под
уровень канального уровня, который позаимствован
из IEEE 802.2. Уровень SSCS (Service Specific Convergence
Sublayer) — промежуточный сервис, обеспечивающий
доступ LLC к уровню MAC. К вышележащим слоям так
же относятся сетевой уровень, обеспечивающий кон
фигурацию сети, управление и маршрутизацию дан
ных, а также уровень пользовательских приложений,
реализующий доступ к основным функциям устрой
ства. Регламентирование работы этих слоев находится
вне спецификации IEEE 802.15.4 и ложится на плечи
разработчиков конкретных устройств стандарта ZigBee.
Одной из отличительных особенностей се
ти IEEE 802.15.4 является поддержка так назы
ваемой «суперфреймовой» структуры. Формат
суперфрейма определяется координатором сети.
Напомним, координатор — это главное сете
вое устройство, которое управляет передачей
всех потоков данных. Суперфрейм начинает
ся с передачи специального фрейма — «сете
вого маркера» (Network Beacon), который по
сылает сам координатор (рис. 2). «Маркер»
предназначен, в первую очередь, для синхро
низации и управления работой всех активных
в сети устройств. После отправки «маркера»
координатор самоотстраняется от управления
сетью, предоставляя устройствам самостоя
тельно «разбираться», кто главнее.
Для этого в суперфрейме предназначен
специальный отрезок времени — период
конкурентного доступа устройств к радио
каналу (Contention Access Period), который
разбит на фиксированные временные участ
ки — так называемые временные слоты (time
slots). В то же время для приложений, кри
тичных к скорости и темпу передачи данных,
после участка конкурентного доступа могут
идти дополнительные временные слоты
(Contention Free Period), в течение которых
они гарантированно смогут отправить или
получить срочную информацию.
В отличие от рабочего цикла, приведенно
го на рис. 2, который предполагает непрерыв
ную передачу суперфреймов, возможен и бо
лее экономичный режим работы, при котором
после периода гарантированного доступа сле
дует период «неактивности», и никакие дан
ные в сети не передаются до появления оче
редного «маркера».
Использование в конкретной сети супер
фреймовой структуры и, в частности, «мар
керных» фреймов не является обязатель
ным — обмен данными может осуществлять
ся и обычными способами. Другое дело, что
часто такое применение дает определенную
выгоду (об этом будет рассказано ниже).
В спецификации IEEE 802.15.4 разрешены
только три формата обмена данными. Воз
можность использования того или иного
из них определяется топологией сети и под
держкой маркерных фреймов. Например, в то
пологии «звезда» возможны только два пер
вых вида транзакций. Но давайте рассмотрим
их подробнее.
1. Устройство передает данные координатору
сети.
В этом случае, вне зависимости от того, ис
пользуются в сети «маркеры» или нет, обмен
происходит в целом одинаково. Если «маркер
ные фреймы» используются, то устройство
сначала ожидает его, обнаружив — синхрони
зируется и в подходящий момент передает
свой фрейм данных.
В случае с сетью без маркеров все еще проще.
Устройство просто передает фрейм данных
в произвольный момент времени. В обоих слу
чаях координатор сообщает об успешном за
вершении транзакции опциональным фрей
мом-уведомлением (Acknowledgment).
2. Устройство получает данные от координа
тора сети.
В сети, поддерживающей «маркерные»
фреймы, этот формат обмена реализуется сле
дующим образом. Когда координатору необ
ходимо передать данные в устройство, он со
общает во время передачи сетевого маркера
о том, что готовится передача сообщения.
В свою очередь, устройство просматривает се
тевой «маркер» и при обнаружении метки о го
товности сообщения передает МАС-команду
запроса данных. Координатор сообщает об ус
пешном получении запроса данных и переда
ет (опционально) фрейм подтверждения, по
сле чего посылает и сами данные. Транзакция
заканчивается фреймом с подтверждением по
лучения пакета данных от устройства.
В сети без «маркерных» фреймов обмен про
исходит по другому сценарию. Устройство
получатель в произвольный момент передает
МАС-команду запроса данных. Координатор
в ответ посылает подтверждение получения
запроса и, если данные готовы, передает их.
Если данные еще не готовы, координатор по
сылает фрейм данных нулевой длины, сообщая
об их отсутствии. Устройство подтверждает по
лучение данных фреймом уведомления.
3. Данные передаются между двумя устройст
вами (peer-to-peer), минуя координатор.
При таком виде транзакций устройство мо
жет обмениваться данными с любыми анало
гичными модулями в пределах досягаемости.
Для того чтобы делать это эффективно, уст
ройства, которые хотят обмениваться инфор
мацией, должны либо постоянно находиться
в режиме «приема», либо каким-то образом
синхронизироваться с остальными. Причем
в последнем случае должен применяться не
кий особый механизм синхронизации, не опи
сываемый стандартом, который разработчи
ки ZigBeeсовместимых устройств будут изо
бретать самостоятельно.
Простой анализ рассмотренных выше фор
матов обмена данными приводит к логично
му выводу: в целом скорость передачи данных
в сети без использования сетевых «маркеров»
должна быть выше— в первую очередь пото
му, что не требуется ожидать передачи коор
динатором сети этого самого «маркера». С другой стороны, очевидно, например, что при за
просе данных из координатора применение
маркерных фреймов позволит избежать «пу
стых» циклов запроса данных. Чтобы понять,
какой способ организации беспроводной сети
все-таки лучше, давайте подробнее рассмот
рим виды передаваемых в сети фреймов, вклю
чая и «маркерный».
Фреймовая структура
Фреймовая структура, используемая
в IEEE 802.15.4, была разработана для макси
мального упрощения и одновременно повы
шения надежности передачи в условиях за
шумленного радиоэфира. Каждый вышесто
ящий протокольный уровень добавляет
к структуре собственные специфические мет
ки и разделы. В рассматриваемой нами сего
дня сети определены четыре фреймовые
структуры:
- маркерный фрейм, передаваемый координатором сети;
- фрейм данных для всех видов передачи информации;
- фрейм уведомления (подтверждения), используемый для подтверждения успешного получения какого-то фрейма;
- фрейм МАС-команды, предназначенный для управления всеми передачами данных. Каждый фрейм проходит две степени формирования, за которые отвечают уровни МАС и PHY. На МАС-уровне формируется содержание фрейма, PHY-уровень отвечает за синхронизацию. Рассмотрим структуру самого объемного фрейма — «маркерного» (рис. 3). Для начала определимся с полями, формируемыми на МАС-уровне, что позволит полу чить наглядное представление о задачах, которые здесь решаются. Сначала идут поля заголовка (MHR — MAC header):
- Поле «frame control» содержит информацию о типе фрейма (маркерный, данные, подтверждение, МАС-команда), о битах, отвечающих за наличие включенной криптографической защиты, о подготовленных для передачи данных, о принадлежности фрейма (для внутренней или для внешней соседней сети), о типе адресации в сети (16 или 64 разрядов).
- Поле «sequence number» — уникальный 8-разрядный номер фрейма, который используется для дополнительной идентификации пакетов в сети. Например, получив пакет с данными, устройство должно послать фрейм подтверждения с точно таким же идентификационным номером.
- Поле «addressing fields» определяет 4 — и 10-байтовый адрес устройства, отправившего данный фрейм. Первые два байта поля — это 16-разрядный уникальный идентификатор самой сети, причем адрес 0xFFFF
обозначает широковещательный запрос, который воспримут как запрос своей сети все
устройства, «слушающие» данный канал.
Оставшиеся 2 или 8 байт — это адрес самого устройства: 16-разрядный — короткий
адрес, 64-разрядный — длинный адрес.
Следом идут поля, отвечающие за данные
(MSDU — MAC service data unit): - Поле «superframe» specification оговаривает
различные параметры суперфрейма: интервал передачи «маркера», разрешено ли в данный момент присоединение новых устройств к сети, кто передает сетевой «маркер»
(координатор сети или кто-то другой) и т. д. - Поле «GTS fields» активирует режим предоставления гарантированных временных слотов устройствам, чувствительным ко времени передачи данных, позволяет выбрать
до семи адресов таких устройств с указанием, сколько временных слотов требуется каждому из них, а также выбрать номер устройства, которое будет опрошено в данном «маркерном» интервале. Здесь же устанавливается
направление передачи данных — только
от устройства или только к устройству. - Поле «pending address fields» описывает количество, а также список коротких и длинных адресов устройств, для которых координатор сети готов передать данные. Число таких адресов ограничено семью, 16-разрядные
адреса должны идти по списку первыми. - Поле «beacon payload» представляет собой
последовательность, предназначенную для
передачи в «маркерном» фрейме данных
вышележащего слоя. Это поле присутствует здесь опционально. При получении
произвольным устройством «маркерного» фрейма с непустым полем beacon
payload сначала происходит передача этих
данных на вышележащий уровень, а только потом обработка полей superframe
specification и pending address. Если поле
beacon payload пустое, то обработка полей
superframe specification и pending address
начинается сразу.
В конце части фрейма, формируемой
на МАС-уровне, идет окончание фрейма
(MFR — MAC footer), здесь содержатся 16 про
верочных разрядов FCS (frame check sequence),
представляющих собой обычную CRC (cyclic
redundancy check) сумму основных полей.
Вышеперечисленные модули MHR, MSDU
и MFR формируют так называемый модуль
протокола данных МАС (MPDU — MAC
protocol data unit). MPDU затем проходит об
работку на PHY-уровне, где он превращается
в модуль сервиса данных физического уров
ня (PSDU — PHY service data unit), к которо
му добавляются в начале еще две компонен
ты: блок SHR, который используется для син
хронизации принимающего устройства
с передающим, и блок PHR, содержащий ин
формацию о длине фрейма.
Рассмотрим подробнее их содержимое:
- Поле «Preamble Sequence» — это «преамбула» для синхронизации устройств, состоящая из 32 двоичных нулей и используемая ередатчиком как идентификатор начала пакета.
- Поле «start-offrame delimiter» (SFD) — это 8 разрядов (содержащих число 0хА7), которые означают окончание полей «преамбулы» и начало пакета данных.
- Поле «frame length» — это 7-разрядное число, содержащее информацию о длине пакета PSDU.
Сформированный таким образом пакет на
зывается физическим пакетом данных
(PPDU — PHY data packet) и напрямую транс
лируется в физическую среду.
Теперь кратко рассмотрим остальные виды
фреймов. Они имеют более простую структуру, чем «маркерный», причем отличия наблюдаются только на МАС-уровне, физический
уровень не затрагивается. Часть полей, присущих «маркерному» фрейму, у остальных видов либо отсутствует, либо заменяется на другие. Ниже приведены их краткие отличия.
Фрейм данных отличает от «маркерного»,
в первую очередь, содержимое блока MSDU.
В нем находится только одно поле — Data
payload, в котором располагаются данные, затребованные вышестоящим слоем для передачи через МАС-уровень.
Фрейм «подтверждения» — самый простой
по структуре. Он содержит всего два поля в заголовке MHR: frame control с идентификатором типа фрейма «подтверждение» и sequence
number с номером фрейма, получение которого подтверждается. После чего сразу идет
окончание фрейма MFR.
Фрейм МАС-команды, как и фрейм данных,
отличается только содержимым блока MSDU.
Здесь присутствуют два новых поля: тип команды (Command type) и сама команда.
Сама по себе фреймовая структура, используемая в IEEE 802.15.4, не очень сложна. К сожалению, она не дает представления обо всех
возможностях устройств при работе в сети,
а только регламентирует виды и формат пе
редающихся сообщений. Наибольшей наглядностью в этом отношении обладают команды, предназначенные для передачи во фрейме
МАС-команды.
Команды сети ZigBee
Обзор разрешенных для передачи в сети команд (в количестве девяти) позволит составить представление как о возможностях самой
сети ZigBee, так и о функционирующих в ней
устройствах. Итак, перечислим их:
-
«Association request» — запрос на присоединение к существующей сети. Данный запрос
- «Association response» — ответ координатора сети устройству, запросившему присоединение к сети. При этом координатор может: подключить это устройство к сети
с присвоением адреса, сообщить, что свободных мест нет, или отказать в доступе без
объяснения причин. - «Disassociation notification» — команда отключения от сети. Может посылаться координатором, при этом он сообщает адрес
устройства, которое из сети исключается.
Команда также может посылаться и любым
устройством в сети, при этом оно сообщает координатору свой адрес. - «Data request» — команда, которую посылает устройство при запросе данных от координатора.
- «PAN ID conflict notification» — команда, которую посылает устройство координатору
сети, когда оно обнаруживает конфликт
идентификаторов сети. - «Orphan notification» — команда, которую
посылает включенное в сеть устройство при
потере синхронизации с координатором. - «Beacon request» — команда, которую посылает устройство для выявления в пределах дальности своей работы всех координаторов сетей.
- «Coordinator realignment» — команда ресинхронизации сети, которую посылает координатор либо в ответ на команду потери синхронизации (Orphan notification), либо если
какие-то атрибуты сети претерпели изменения. В первом случае команда отправляется
конкретному устройству, испытывающему
проблемы с синхронизацией, во втором случае отправляется широковещательная команда всем доступным устройствам. - «GTS request» — команда, которая предназначена для управления гарантированными
временными слотами, предоставляемыми некоторым устройствам для передачи данных
в пределах маркерного фрейма. GTS request
позволяет устройствам как запрашивать выделение таких слотов, так и освобождать уже
выделенные. Гарантированные слоты предоставляются только устройствам с короткими
адресами, в запросе указывается число требуемых или высвобождаемых слотов времени,
направление передачи данных (только прием или только передача относительно запрашивающего устройства) и 1 разряд — собственно просьба (выделить или освободить указанные временные слоты).
устройство посылает координатору, когда
хочет подключиться к сети. В запрос включается информация о характеристиках устройства — способно ли оно выполнять
функции координатора сети, тип устройства (полнофункциональное устройство или
устройство с ограниченными возможностями), способ питания (от обычной сети или
иной), отключает ли устройство радиоприем, когда находится в «спящем» режиме,
поддерживается ли криптозащита, 16- или
64-разрядный адрес хочет иметь устройство.
Запрос на подсоединение могут посылать
только те устройства, которые к данной сети еще не подключались.
При рассмотрении действующих в сети
ZigBee команд обращает на себя внимание сле
дующий факт. Устройства с ограниченными
возможностями могут не поддерживать по
давляющее большинство из них. Причем, что
характерно, в спецификации про эти коман
ды говорится по-разному. Некоторые являют
ся «необязательными», другие могут присут
ствовать «опционально». В чем конкретно раз
ница между этими двумя случаями —
непонятно, скорее всего, это одно и то же.
Надежность
Вернемся к возможностям IEEE 802.15.4.
Как вы помните, одной из заявленных харак
теристик беспроводных сетей, строящихся
на базе этого стандарта, является высокая на
дежность передачи данных. Какие механизмы
применяются для этого на уровнях PHY
и МАС, нам и предстоит сейчас разобраться.
В данной LR-WPAN применяются различ
ные механизмы для обеспечения надежности
и достоверности передаваемой информации.
Эти методы включают в себя использование
механизма передачи CSMA-CA, фреймы под
тверждения получения и верификации дан
ных. Рассмотрим их подробнее.
В IEEE 802.15.4 используется два типа до
ступа к каналам передачи, зависящие от кон
фигурации сети. В сетях, где «маркерные»
фреймы не используются (Nonbeacon-enabled
networks) и доступ к каналу происходит слу
чайным образом, задействуется механизм, на
зываемый «unslotted CSMA-CA channel access
mechanism». Каждый раз, когда устройству
требуется передать фрейм данных или МАС
команду, оно должно сначала выждать неко
торый промежуток времени (его длитель
ность выбирается случайным образом). Если
канал после этого окажется свободным (idle),
устройство передает свои данные. Если же ка
нал оказывается занятым (busy) после этой
произвольной задержки, устройству следует
подождать еще один случайный отрезок вре
мени и потом опять попытаться получить до
ступ к каналу.
В сетях с «маркерными» фреймами исполь
зуется механизм с фиксированными времен
ными слотами ожидания передачи «slotted
CSMA-CA», идущими сразу после «маркерно
го» фрейма. Каждый раз, когда устройство за
хочет передать данные в период конкурент
ного доступа к каналу, оно должно сначала
определить границу ближайшего слота ожи
дания и отсчитать от него случайное число
подобных слотов. Если канал окажется занят
после этой паузы, устройству предстоит по
дождать следующее случайное число фикси
рованных временных слотов, перед тем как
попытаться получить доступ к каналу снова.
Если канал свободен, устройство может на
чать передачу сразу с границы ближайшего
слота ожидания.
Случайный доступ с контролем несущей
и предотвращением конфликтов (CSMA-CA)
не используется в следующих случаях:
- При отправке фреймов подтверждения, ко
торые отправляются тут же, без ожидания
освобождения канала в течение случайных
промежутков или слотов времени. - При передаче «маркерного» фрейма. Его отправка происходит уже после того, как завершаются периоды конкурентного и гарантированного доступа устройств к каналу,
все разрешенные транзакции закончены
и радиоканал гарантированно свободен. - При передаче данных в течение периода гарантированного доступа. Тут все понятно
по определению. Гарантированные слоты
доступа предоставляются в фиксированном
объеме и конкретным устройствам. Никакого случайного доступа к каналу тут не предусмотрено, поэтому он и не применяется.
Вторым уровнем обеспечения надежной до
ставки данных, как мы уже говорили, являют
ся фреймы подтверждения успешного приема
и достоверности полученных данных или
МАС-команды. Алгоритм работы прост —
если принимающее устройство не смогло
по каким-либо причинам получить данные,
то ответное уведомление не посылается. Если
инициатор отправки сообщения не получает
в течение какого-то времени подтверждения
доставки, он считает данную транзакцию не
успешной и снова пытается повторить пере
дачу. Если подтверждение не приходит и по
сле нескольких повторов, то инициатор мо
жет по своему выбору либо прекратить
транзакцию, либо пытаться отсылать данные
до бесконечности.
Последний «столп» обеспечения надежнос
ти — верификация данных, которая обеспе
чивается с помощью 16разрядных контроль
ных сумм CRC. Контрольная сумма выполня
ется только над полями заголовка MAC header
и содержимым, передаваемым из вышестоя
щих слоев через МАС-уровень.
Энергопотребление
Как неоднократно говорилось выше, одним
из главных достоинств стандарта ZigBee явля
ется ориентация на малое энергопотребление
беспроводных устройств. Не зря ведь в анон
сах и рекламных проспектах одним из первых
оговаривается именно этот немаловажный па
раметр. На деле, как обычно, все оказывается
немного сложнее. Дело в том, что в основе
ZigBee — стандарте IEEE 802.15.4 — о низком
потреблении говорится совсем немного. Здесь,
например, оговаривается следующий момент:
данный стандарт разработан, в принципе,
с возможностями применения в условиях ог
раниченного питания. Однако физическое
применение стандарта требует дополнитель
ных изысканий в этом направлении, а это уже
выходит за рамки IEEE 802.15.4.
При всем этом разработчики дают общие
указания о том, как уменьшить энергопотреб
ление устройств, которым это действительно
необходимо. В аппаратуре подобного типа,
использующей в качестве элементов питания
батареи или аккумуляторы, предлагается в обя
зательном порядке применение циклическо
го режима работы. Большую часть времени
такие устройства должны проводить в «спя
щем» режиме. Причем им следует периодиче
ски включать радиотракт и прослушивать
эфир на случай готовящихся для передачи
сообщений. Этот простой и в то же время гиб
кий механизм, прежде всего, позволит разра
ботчикам программных приложений на вы
соком уровне соблюдать баланс между эконо
мией электроэнергии и задержкой в передаче
сообщений.
Понятно, что для устройств, имеющих ис
точник постоянного питания, например,
«от сети», применение циклического режима
лишено всякого смысла. Решениям такого
класса разработчики IEEE 802.15.4 рекоменду
ют постоянно оставаться на связи.
Еще одним наиважнейшим параметром,
характеризующим любую сеть, а тем более
беспроводную, является безопасность переда
ваемых данных и защита их от несанкциони
рованного доступа. В привычных для нас ло
кальных проводных сетях эта проблема на ап
паратном уровне обычно не решается,
безопасность передаваемых данных обеспечи
вается сервисами и службами более высокого
программного уровня.
Точно так же могли поступить и создатели
IEEE 802.15.4, однако они все же ввели в стан
дарт некоторый набор базовых функций, обес
печивающих начальный уровень безопаснос
ти на МАС-уровне. Базисными сервисами
в этом направлении стали: поддержка списков
контроля доступа ACL (access control list)
и криптографическое шифрование передава
емых данных.
Способность выполнять простейшие дей
ствия по обеспечению безопасности не явля
ется обязательной, однако разработчики на
стоятельно рекомендуют использовать эти
функции постоянно и во всех устройствах.
Механизм шифрования, задействованный
в данном стандарте, основан на применении
симметричного ключа, который поставляет
ся «сверху». Это значит, что вышележащие
слои должны уметь определять, когда исполь
зуются режимы безопасности на МАС-уров
не, и формировать все основные параметры
(в том числе и ключи) для работы сервисов за
щиты. Задачи создания и управления симме
тричными ключами ложатся на плечи разра
ботчиков конкретных беспроводных чипов.
Перечислим основные сервисы защиты,
предусмотренные в IEEE 802.15.4:
- Управление доступом с помощью списков
контроля доступа ACL. Если устройство поддерживает данный сервис, оно должно
иметь в своем ACL-списке перечень всех устройств, от которых оно ожидает получения данных. - Шифрование данных для защиты от несанкционированного доступа. Для обеспечения
криптозащиты используются симметричные ключи. Данные могут шифроваться как
с использованием ключа, общего для группы устройств, так и с помощью отдельных
ключей для каждой пары устройств (при
этом ключ хранится также в ACL-списке). - Контроль целостности фрейма. Данный сервис использует специальный код целостности сообщения (MIC — Message Integrity
Code) для защиты передаваемых данных от
возможных изменений их устройствами,
не «знающими» криптографического ключа. Код этот также может быть общим для
группы устройств или личным для пар устройств. - Sequential freshness— специальный сервис,
предназначенный для обновления рассылаемых устройствам в сети симметричных
ключей.
В зависимости от режима, в котором работает беспроводное устройство, и выбранного
режима безопасности, МАС-уровень обеспечивает различные сервисы защиты. В режиме с отключенной защитой (unsecured mode) они
не задействованы вообще. В режиме ACL mode
обеспечиваются совместными усилиями надлежащих над МАС-уровнем слоев и сервисом
управления доступом с помощью списков ACL.
В третьем режиме — режиме защиты (secured
mode) — могут быть активированы любые
из вышеописанных сервисов, в зависимости
от выбранного стандарта криптования.
В таблице 2 приведены все поддерживаемые
в IEEE 802.15.4 стандарты 32-, 64- и 128-разрядного шифрования с указанием поддержиаемых сервисов защиты. Все алгоритмы обеспечения безопасности соответствуют стандарту AES (Advanced Encryption Standard). AES—
это спецификация шифрования электронных
данных, в том числе финансовой, телекоммуникационной и правительственной информации, предложенная Национальным институтом стандартов и технологий США (National
Institute of Standards and Technology). AES пришел на замену морально устаревшему DES—
самому распространенному криптоалгоритму в мире и сейчас уже заложен, например,
в последних спецификациях семейства беспроводных стандартов IEEE 802.11 (Wi-Fi).
Все чипы, соответствующие IEEE 802.15.4
и поддерживающие функции защиты данных,
должны в обязательном порядке поддерживать стандарт AES-CCM-64. Поддержка всех
остальных стандартов осуществляется опционально. Это, в свою очередь, означает, что
разработчикам беспроводных устройств на базе ZigBee, а особенно комплексных решений,
следует внимательно относиться к выбору элементной базы и заранее справляться о поддержке тех или иных модификаций AES.
Заключение
Надеемся, что наш краткий экскурс в глубины IEEE 802.15.4 оказался достаточным для
того, чтобы читатели смогли понять общие
принципы и задачи, решаемые на двух основополагающих «китах» этого стандарта, — уровнях PHY иMAC. Спецификация 802.15.4
довольно сложна, поскольку синтезировала
все последние достижения в области беспроводных технологий и средств передачи данных. То, что рассмотрено в данной статье —
лишь самая верхушка огромного айсберга под
аббревиатурой IEEE 802.15.4.
Что же касается практического воплощения,
то, как легко заметить, рассмотренная нами спецификация предусматривает огромное ко-
личество нюансов и вариантов реализации тех
или иных возможностей, обозначенных в тексте фразами «являются необязательными» или
«присутствует опционально». Поддержка
функций такого рода определяется целиком
производителем, что, несомненно, приведет
к выпуску довольно большой номенклатуры
ZigBee-совместимых устройств, обладающих
незаметными на первый взгляд отличиями.
Именно эти отличия разработчики, внедряющие новые технологии в жизнь, должны прекрасно себе представлять и, только определившись с собственными требованиями к будущим беспроводным устройствам, приступать
к выбору элементной базы.
В следующей статье, посвященной ZigBee,
мы затронем вопросы, касающиеся конкретных беспроводных чипов, представленных
флагманом рынка решений ZigBee— компанией Freescale Semiconductor. В этом материале на конкретных примерах будут рассмотрены как оригинальные классы выпущенных
платформ, так и особенности реализации
МАС-уровней. Кроме того, будет проведен
анализ их возможностей и оценка целевого
назначения, одним словом, все то, что позволит нам наглядно продемонстрировать практический потенциал этой беспроводной технологии.
Литература
- Скуснов А. ZigBee: обзор технологии // Компоненты и технологии. 2005. № 3.
- www.cec-mc.ru.
- www.ZigBee.org.