Стек IP-протоколов ZigBee

Редакция

Дуглас Коумер (Douglas Comer), Университет Пердью

Рождается огромная область сетевых технологий: коммуникация среди интеллектуальных встроенных систем. Идея заключается в том, что вычислительные системы могут быть встроены во множество устройств, и эти системы смогут использовать Интернет для коммуникации с другими устройствами. Конечно, некоторые устройства будут предоставлять информацию для людей, и люди могут пользоваться приложениями, контролирующими встроенные устройства. Следовательно, новая сетевая парадигма частично включает взаимодействие с человеком. Однако основной акцент при этом делается на системы, которые могут взаимодействовать с окружающей средой и друг с другом, а не на традиционные компьютеры, которые хранят данные и выполняют приложения. Исследователи и специалисты ввели в употребление термины «интернет вещей» (Internet of Things, IoT или iThings) и «M2M (межмашинные) приложения» (Machine-to-Machine Applications), которые отражают смысл этой идеи. Несмотря на довольно неуклюжую формулировку, термин «интернет вещей» стал общепринятым.
Эта статья начинается с нескольких примеров интеллектуальных встроенных систем и способов, с помощью которых они обмениваются информацией. Затем идет подробное обсуждение одной из технологий: стека протоколов для беспроводных полносвязных сетей, разработанных для приложений, управляющих интеллектуальными сетями электроснабжения (Smart Grid). Статья анализирует этот стек протоколов, использование IPv6 и некоторые последствия таких конструктивных решений.

Приложения для зондирования, мониторинга и контроля
Мы используем термин «встроенные системы» в отношении вычислительных систем, которые являются составной частью другого механизма или устройства. Главное различие между встроенной системой и обычной компьютерной системой следует из их внешних соединений. Обычная компьютерная система имеет дело с информацией: компьютер способен хранить и преобразовывать данные, а также обеспечивать к ним доступ. В отличие от этого, встроенная система способна воспринимать и контролировать физический мир вокруг себя. В качестве примера можно рассмотреть термостат, используемый для управления системой отопления и кондиционирования. Современный термостат (называемый «умным» термостатом) представляет собой встроенную систему: такой термостат содержит встроенный процессор, работающий под управлением программного обеспечения и выполняющий все необходимые функции.
Пользователь может сконфигурировать термостат таким образом, чтобы параметры настройки менялись в зависимости от времени дня. Термостат подключен к целому набору датчиков, который может включать датчик температуры помещения, датчик, обнаруживающий потоки воздуха (т.е. работает ли вентилятор), и датчик, подключенный к нажимным кнопкам (кнопкам-переключателям), который позволяет пользователю задать требуемую температуру. Более совершенные системы имеют в своем составе датчики относительной влажности воздуха. Кроме того, термостат подключен к элементам управления, которые позволяют процессору включать и выключать нагреватель или кондиционер, регулировать скорость вращения вентилятора, а также управлять функциями увлажнителя и влагопоглотителя.
Большинство компьютерных пользователей уже знакомы со встроенными системами. Например, подключенный к компьютеру принтер имеет в своем составе встроенную систему. После отправки компьютером документа на печать встроенная система принтера управляет двигателями и механизмами принтера, заставляя их подавать листы бумаги, перемещать механизм струйной печати и распылять капельки чернил (тонера).
Принтер также имеет в своем составе датчики, которые способны обнаруживать заторы при подаче бумаги и низкий уровень тонера.
General Electric (GE) – крупнейшая промышленная компания США – производит продукты, которые выходят далеко за пределы потребительского рынка. GE производит двигатели для самолетов, турбины для электростанций, локомотивы для железных дорог, медицинское оборудование для создания изображений и рассчитанные для тяжелых условий работы машины, которые обеспечивают транспортировку людей, обогрев домов и электроснабжение заводов. Используя термин «Промышленный интернет» (Industrial Internet), компания GE ввела в действие крупную инициативу, направленную на объединение обменивающихся данными встроенных систем для использования как на заводах, так и в продуктах компании.

Сбережение и сбор энергии
Некоторые встроенные системы, например, встроенная система управления принтера, подключены к надежному источнику питания. Однако многие встроенные системы полагаются на временные источники энергии и сконструированы таким образом, чтобы ее сберегать. Например, сотовые телефоны работают от батарей (аккумуляторов), а датчики состояния окружающей среды, размещенные в удаленных местах (например, в пустыне), могут использовать фотоэлементы.
Как особый случай, некоторые встроенные системы способны собирать энергию из окружающей среды вокруг них. Например, размещенный в океане датчик может использовать движение волн для генерации электроэнергии, а датчик, расположенный рядом с горячим источником, использовать тепловую энергию. Сбор энергии даже включает использование кинетической энергии, которую генерируют люди при открывании двери или при нажатии на выключатель освещения. Возможна ситуация, когда встроенная система, использующая сбор энергии, вынуждена работать периодически – для аккумулирования достаточного заряда (например, при эксплуатации радиопередатчика).
Мир интеллектуальных встроенных систем
Для того, чтобы понять будущее интернета вещей, мы должны представить, что мощные встроенные системы появятся везде – дома, в офисе, в автомобиле, в торговом центре и на улице. Например, рассмотрим автомобили. В дополнение к навигационным и развлекательным системам конструкторы работают над системами, которые позволят автомобилю вычислять расстояние до соседних машин, обнаруживать объекты на дороге, предупреждать об изменении дорожного покрытия (например, в результате строительства), а также обнаруживать дорожные полосы и предупреждать водителя о заносе автомобиля. Автомобиль с интеллектуальной встроенной системой может обмениваться данными с соседними автомобилями и координировать торможение. Интеллектуальная встроенная система может использовать средства для распознавания лиц с целью идентификации водителя при посадке в автомобиль, регулировки параметров настройки в соответствии с предпочтениями водителя, отслеживания индивидуальных привычек управления автомобилем и наблюдения за необычной манерой вождения, адаптации предупреждений в соответствии со временем реакции конкретного водителя.
В офисных зданиях встроенные системы уже обнаруживают присутствие людей и соответствующим образом регулируют освещение и отопление/кондиционирование. Система может использовать датчики для изменения режима работы систем отопления и кондиционирования при открытых окнах. Что более важно, интеллектуальные встроенные системы смогут использовать алгоритмы обучения для накопления закономерностей. Например, если некоторые сотрудники часто входят и выходят из своего офиса в течение рабочего дня, то система может научиться не выключать отопление до тех пор, пока эти сотрудники не будут отсутствовать в течение более длительного времени. Аналогично, если сотрудник имеет обыкновение работать спозаранку, система может изучить эту закономерность и соответствующим образом управлять офисной средой. Таким образом, если сотрудник обычно приходит на работу рано и каждый день уходит домой в 15.00, то интеллектуальная система может выучить эту закономерность и ожидать прибытия и отбытия сотрудника в соответствующее время.

Важность коммуникации
Почему же акцент смещается на интеллектуальные системы, способные обмениваться между собой данными? Они имеют множество преимуществ. Например, в дополнение к локальной координации, коммуникация позволяет системам использовать облачные вычисления[10, 11] для анализа данных, полученных от набора встроенных устройств. Коммуникация означает, что встроенные системы могут иметь меньший объем памяти и менее мощные процессоры, что ведет к снижению энергопотребления. Короче говоря, небольшие встроенные системы могут выполнять сложные функции благодаря совместной работе с соседними встроенными системами либо за счет доступа к удаленной информации.
В качестве примера можно рассмотреть набор датчиков, используемых для оценки механического напряжения в таких объектах гражданской инфраструктуры, как мосты. Измерение напряжения важно для того, чтобы понять, сможет ли мост выдержать определенную нагрузку, требуется ли его укрепить и когда его необходимо заменить. Для измерения механического напряжения инженеры размещают небольшие, питающиеся от батареи датчики в различных точках по всему мосту. Без возможности обмена данными каждый датчик должен располагать собственным локальным хранилищем для хранения измерений вместе с соответствующей отметкой времени для каждого из них. Если каждый датчик имеет в своем составе средства радиосвязи, то набор датчиков способен сформировать беспроводную сеть, по которой данные измерений передаются в точку сбора, а сама эта точка может располагаться где-то в Интернете, далеко от моста. В контексте измерений это важное различие обусловлено координацией и быстротой анализа. Коммуникация позволяет сенсорным узлам использовать протокол, который снимает показания одновременно. Сбор данных в реальном времени делает возможным быстрое обнаружение опасных ситуаций и принятие мер до того, как произойдет авария.
Кроме того, коммуникация позволяет снизить издержки. Возьмем для примера умные счетчики, которые используются компаниями, предоставляющими коммунальные услуги. Традиционный подход к оценке расхода заключается в размещении счетчика за пределами того места, где располагается клиент, и в ежемесячной отправке сотрудника для снятия показаний счетчика. Умный счетчик имеет в своем составе средства беспроводной коммуникации, а это означает, что коммунальная компания может считывать его показания удаленно. Даже если умный счетчик использует радиопередатчик, диапазон действия которого охватывает только ближайшую улицу, его показания можно снять с помощью проезжающего по этой улице автомобиля, а не посредством прямого обхода сотрудником компании, что позволяет резко сократить расходы на снятие показаний счетчиков.

Встроенные системы в торговых центрах
В дополнение к вышеописанным сенсорным системам интернет вещей включает весьма неожиданные области применения. Например, многие торговые центры теперь располагают крупными видеоэкранами, показывающими рекламные ролики. Магазины используют эти экраны для рекламы продуктов и услуг, а также скидок и специальных акций. Коммуникация необходима для динамической загрузки этих рекламных роликов, поскольку их контент и графики показа могут измениться в любой момент – менеджменту требуется способность контролировать, какая реклама показывается на данном экране и как долго она остается видимой.
Где расположена система управления видеоэкранами и какие сетевые технологии необходимы для подключения этой системы управления к отдельным экранам? Ответ на этот вопрос довольно интересен и немного удивителен: в рамках современной реализации каждый экран имеет в своем составе стек протоколов TCP/IP и подключение к глобальной сети Интернет. Интернет-соединение позволяет размещать систему управления в любом месте. В частности, торговый центр может прибегнуть к аутсорсингу IT-функций, разместив систему управления в «облаке». Что более важно, оснащение каждого экрана интернет-соединением и программным обеспечением протоколов означает, что контент не обязательно должен размещаться на том же физическом хосте, что и управляющая система.
Возможность отделить контент от управляющей системы очень важна, поскольку это позволяет отделить информацию, которой владеет розничный торговец, от системы управления конкретного торгового центра. В результате, розничная торговая компания может направлять свой контент сразу в несколько торговых центров. Например, такой торговец, как Apple, может разместить видеоконтент для рекламных роликов в облачном сервере и затем передавать команды котроллерам каждого торгового центра, задавая график показа вместе с URL-ссылкой на каждый ролик. Поскольку они имеют доступ к Интернету, отдельные экранные системы способны загрузить копию запланированного к показу ролика (возможно, через локальный кэш для повышения производительности).
Сбор данных из интернета вещей
Экраны в торговых центрах иллюстрируют еще одно важное преимущество сетевых систем – их способность передавать данные для сбора. Хотя клиенты это не всегда замечают, но размещенные в торговых центрах экраны оснащены камерами. При приближении человека к экрану система использует камеру для обнаружения его присутствия. Система идентифицирует человеческие лица и применяет алгоритмы анализа, которые используют такие особенности, как расстояние между глазами, для того, чтобы охарактеризовать человека. Программное обеспечение такого экрана способно с высокой точностью определить, является ли стоящий перед камерой человек мужчиной или женщиной, а также приблизительно оценить возрастную группу человека. Таким образом, вместо того, чтобы просто следовать предопределенному графику показа рекламных роликов, система может использовать эти характеристики человека для выбора соответствующей рекламы. Например, мужчине среднего возраста можно показать рекламу спортивного автомобиля вместо рекламы женской одежды.
В дополнение к использованию видеоинформации для выбора рекламных роликов системы торговых центров также собирают и передают данные о взаимодействии. Например, система предоставляет статистику о том, сколько людей наблюдали определенную рекламу, их пол и возраст, а также сколько времени каждый человек или группа людей оставались перед экраном при показе определенного набора рекламных роликов. Продуктовые магазины используют точно такой же подход: они устанавливают камеры со встроенными средствами обработки данных над холодильниками и в других местах магазина. Эти камеры записывают, останавливались ли клиенты у данного прилавка с продуктами, сколько времени каждый покупатель смотрел на прилавок и сколько клиентов, в конечном счете, выбрали продукт или просто двинулись дальше. После передачи данных на сервер информация с конкретного места может быть объединена с данными из других точек. Ключевая идея заключается в том, что объединение данных из нескольких мест обеспечивает повышение точности анализа.
Беспроводная сетевая коммуникация и IEEE 802.15.4
Каким образом следует подключать устройства к Интернету? Беспроводные сетевые технологии являются популярным выбором даже в случае полупостоянных развертываний в рамках небольшой области. Рассмотрим для примера электронные экраны в торговых центрах. Хотя они являются полупостоянными (т.е. экраны размещаются стационарно на несколько недель), беспроводная сеть означает, что экран можно перемещать без создания нового сетевого соединения.
Какие беспроводные сетевые технологии следует использовать для подключения интеллектуальной встроенной системы? Ответ зависит от нескольких факторов, включая физическое расстояние между узлами сети, необходимые скорости передачи данных и требования к электропитанию. Электропитание влияет двумя способами. В случае встроенных сенсорных систем, которые работают от батарей, общее энергопотребление должно быть сведено к минимуму с целью максимального увеличения времени работы батарей. Хотя мощность, потребляемая радиопередатчиком, занимает львиную долю в расходе энергии батареи, использование меньшего объема памяти или снижение частоты процессора может также понизить требования к общей мощности. В случае встроенных систем, которые обладают постоянным источником электропитания (например, подключены к сетевой розетке), может возникнуть необходимость в ограничении передачи радиосигналов с тем, чтобы избежать помех, связанных с работой других устройств или передачей иных радиосигналов.
В настоящее время стандартизированы несколько беспроводных сетевых технологий с низким энергопотреблением. Данная статья рассматривает сетевую технологию, определенную стандартом IEEE 802.15.4[1]. Существуют различные версии 802.15.4; они отличаются между собой по используемым частотным диапазонам и методам модуляции, а также по максимальному передаваемому размеру данных (MTU, Maximum Transmission Unit). Стандарт IEEE определяет физический уровень сети и уровень управления доступом к среде передачи (MAC, MediaAccess Control), при этом другие группы определили протоколы верхнего уровня для использования в беспроводных сетях с низким энергопотреблением. Для целей настоящей статьи необходимо знать только общие характеристики технологии 802.15.4:

• относительно низкая скорость передачи данных (максимум 250 кбит/с);
• чрезвычайно малый размер MTU (127 октетов);
• ограниченное расстояние (максимум 10 метров с обычной антенной и питанием от батареи).

Многосвязная сеть (mesh network) для датчиков интеллектуальной энергосистемы
Одна из областей применения беспроводной технологии 802.15.4 является результатом инициативы по внедрению интеллектуального компьютерного управления в системы распределения электроэнергии. Известный под названием «интеллектуальная сеть электроснабжения» (Smart Grid), подход включает размещение датчиков во всех устройствах, использующих электроэнергию. В дополнение к крупным системам, используемым для отопления и охлаждения, конструкторы предусмотрели установку датчиков в кухонных бытовых приборах (например, электропечи, холодильники, посудомоечные машины и даже тостеры), компьютерных и развлекательных системах (например, телевизоры и стереосистемы), в небольших портативных приборах. Компании, предоставляющие коммунальные услуги, хотят взимать более высокую плату в часы пиковых нагрузок, и датчики будут обмениваться данными с такой компанией с целью определения ценовых условий и предупреждения пользователей о времени дня, когда взимается более высокая плата. Как альтернативный вариант, датчики будут способны заблокировать определенные варианты использования в течение пиковых часов.
Наиболее очевидная конструкция системы датчиков для жилища включает размещение базовой станции в жилом помещении и использование беспроводной технологии, позволяющей базовой станции обмениваться данными с каждым датчиком. Этот подход известен как «звездообразная» топология. Например, системы Wi-Fi (802.11) используют звездообразную топологию. Однако такой подход недостаточно хорошо работает во всех ситуациях. В частности, металлические трубы и другие находящиеся внутри здания препятствия могут помешать распространению беспроводных сигналов и сделать невозможным охват всего жилища из одной точки, особенно в случае портативных приборов, которые могут быть перемещены из одной комнаты в другую. Поэтому разработчики интеллектуальных электросетей предусмотрели адаптивную систему, в рамках которой набор сенсорных узлов автоматически формирует самоорганизованную многосвязную сеть или просто меш. Каждый узел такой сети выполняет две задачи: обмен данными для устройства, к которому он прикреплен, и переадресация для других узлов.
В жилище будет установлен граничный маршрутизатор, который соединит между собой многосвязную сеть и внешний мир. При инициализации узла он присоединяется к мешу и пытается установить соединение с граничным маршрутизатором. Если узел может напрямую «дотянуться» до граничного маршрутизатора, то он обменивается данными непосредственно с граничным маршрутизатором. Если узел не может напрямую «дотянуться» до граничного маршрутизатора, то он ищет ближайший соседний узел, имеющий путь к граничному маршрутизатору. По сути, соседний узел соглашается действовать в качестве маршрутизатора и перенаправлять пакеты. Если путь к граничному маршрутизатору существует у нескольких соседних узлов, то первоначальный узел выбирает один из них с помощью алгоритма выбора. Алгоритм выбора может принимать во внимание несколько показателей, включая качество радиосигнала (т.е. уровень помех), задержку, пропускную способность узла и пропускную способность промежуточных узлов. После того, как узел выберет путь до граничного маршрутизатора, он информирует соседние узлы и соглашается передавать их пакеты. Таким образом, если существует возможность создать сеть, которая обеспечивает связность для каждого узла, то узлы автоматически сформируют такую многосвязную сеть. Позднее в данной статье мы вернемся к вопросу о том, каким образом соседний узел делает свой выбор.
Дерево переадресации для многосвязной сети
Данное выше описание превращает выбор пути в меше в нечто тривиальное. На самом деле, меш может предлагать большое количество возможных путей. Различие между маршрутизацией (выбор пути среди сетей) и переадресацией (выбор пути внутри сети) довольно расплывчато, поскольку каждое радиосоединение можно представить в виде сети. Что более важно, путь с наименьшим количеством хопов (промежуточных сегментов) может оказаться неоптимальным, поскольку связность между узлами является попарной, и низкая мощность сигнала между конкретной парой узлов может сделать этот путь ненадежным. Более того, если узлы меша являются мобильными (портативными), либо если среда затрудняет прохождение сигнала (например, люди движутся через комнату), то переадресация должна динамически изменяться. Несмотря на потенциальную сложность маршрутизации в меше, уже созданы решения, способные справиться с базовыми случаями. В частности, были созданы протоколы, обрабатывающие переадресацию между граничным маршрутизатором и отдельными узлами в топологии полустатического меша.
Ключевая идея, которая позволяет упростить переадресацию в меше, заключается в следующем наблюдении: если главной целью является установление коммуникации датчиков с удаленным сервером, то каждому сенсорному узлу требуется выбрать только один способ для соединения с граничным маршрутизатором. Трафик от удаленного сервера до узла меша может передаваться по тому же пути, но в обратном направлении. Иными словами, пути переадресации в сети формируют дерево в графо-теоретическом смысле (т.е. граф без циклов), при этом граничный маршрутизатор является корнем такого дерева. Рис. 1 показывает набор сенсорных узлов и одно возможное дерево переадресации.
Рис. 1. Пример дерева переадресации, накладываемого на набор сенсорных узлов. Дерево будет образовано в том случае, если каждый узел – один путь до граничного маршрутизатора.

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

• Mesh–under: меш действует как единая сеть, протоколы уровня 2 управляют широковещательной и групповой адресацией;
• Route–over: меш действует как набор двухточечных соединений, протоколы уровня 3 управляют всей переадресацией.

В рамках подхода mesh-under, в пользу которого склоняется IEEE, узел использует протоколы уровня 2 для формирования дерева переадресации. Идея аналогична мосту и протоколам связующих деревьев, используемых в Ethernet. Например, узел использует широковещательную адресацию уровня 2 для того, чтобы обнаружить, какие соседние узлы находятся в пределах досягаемости радиосвязи. Каждый соседний узел отвечает, позволяя паре узлов узнать, что они находятся в пределах досягаемости, а также определить качество сигнала. Граничный маршрутизатор также использует широковещательную трансляцию уровня 2 для объявления о себе. Узлы меша передают друг другу информацию о том, какие узлы находятся в пределах их досягаемости. В конечном счете каждому узлу меша станет известно о других узлах и о том, как до них добраться, а также каким образом переадресовывать широковещательные пакеты. Таким образом, задавшись адресом уровня 2 граничного маршрутизатора, узлы меша узнают, куда следует направлять пакеты (т.е. они сформируют дерево переадресации).
В рамках подхода route–over, в пользу которого склоняется IETF (Internet Engineering Task Force), узел использует протоколы уровня 3 для идентификации соседних узлов и формирования дерева переадресации. Конечно, базовое аппаратное обеспечение не понимает IP-адресов или формата IP-датаграмм. Таким образом, пакеты уровня 3 переносятся внутри фреймов (кадров) уровня 2. Например, для того, чтобы найти соседние узлы, программное обеспечение уровня 3 генерирует датаграмму IPv4 с локальным широковещательным адресом (broadcast address) или датаграмму IPv6 с локальным для соединения групповым адресом (link-local multicast address). Такая датаграмма отправляется посредством аппаратного широковещания.
В рамках любого из этих подходов при вводе в меш нового узла он должен выбрать, каким образом подключить себя к дереву. Используются два шага. На первом шаге узел должен обнаружить набор соседних узлов, которые находятся в пределах его прямой досягаемости, и оценить качество радиосоединения с каждым соседним узлом. На втором этапе узел должен выбрать, будет ли он осуществлять коммуникацию с граничным маршрутизатором напрямую, либо он будет использовать один из соседних узлов при переадресации пакетов. Обратите внимание, что качество сигнала имеет важнейшее значение – даже если узел способен напрямую «дотянуться» до граничного маршрутизатора, он может выбрать непрямой путь, если качество сигнала при прямом соединении достаточно низкое.

В контексте стека IP-протоколов основное различие между подходами mesh-under и route-over проявляется в IP-пересылке (IP forwarding). Подход mesh-under следует традиционной парадигме, обращаясь со всем мешем как с отдельной сетью со знакомыми характеристиками единого широковещательного домена и способностью произвольной пары узлов осуществлять коммуникацию.
IP присваивает единый префикс всему мешу, и любая датаграмма, адресованная узлу сети, будет cначала передана базовому аппаратному интерфейсу для осуществления доставки. После принятия исходящей датаграммы от IP-уровня сетевой интерфейс использует информацию, собранную протоколами маршрутизации уровня 2, для выбора следующего хопа (промежуточного сегмента), в который будет направлена датаграмма. По мере того, как пакет перемещается по мешу, в каждом промежуточном узле он обрабатывается только средствами уровня 2. После прибытия в пункт назначения датаграмма передается на уровень 3. Таким образом, вся детальная информация меша остается скрытой от уровня 3.
Подход route-over требует знания топологии меша на уровне IP. Другими словами, IP известно, что некоторых узлов сети можно достичь напрямую, а других нет. В частности, использование подхода route-over нарушает стандартное допущение IP-протоколов о том, что если два хоста коллективно используют один IP-префикс, то они подключены к сети, которая позволяет им напрямую обмениваться пакетами. В рамках меша route-over все узлы меша коллективно используют один префикс, несмотря на то, что конкретный узел способен напрямую обмениваться данными только с ближайшими соседями. Используя терминологию IPv6, мы говорим, что узел либо «на соединении» (on link), либо «вне соединения» (off link). Для работы с узлами, до которых нельзя добраться напрямую, IP использует маршрутизацию по источнику (source routing). IP должен понимать топологию меша и быть способен задать путь через меш до пункта назначения (например, перейти к узлу 9, затем к узлу 5, затем к узлу 1 и, наконец, к граничному маршрутизатору). Приведенные ниже разделы описывают стек протоколов ZigBee, который использует подход route-over, а следующие за ними разделы анализируют некоторые возникающие проблемы.
Стек протоколов IPv6 для ZigBee
Альянс ZigBee[2] и IETF[3] сотрудничают между собой с тем, чтобы определить методы использования IPv6 в многосвязных топологиях, реализующих подход route-over. Альянс ZigBee определил открытый стандарт, известный под названием ZigBee IP[4]. В таблице 1 перечислены три ключевые рабочие группы IETF, связанные с инициативой ZigBee. Последующие разделы описывают разрабатываемые протоколы.
Таблица 1. Рабочие группы IETF, связанные с инициативой ZigBee Effort.
Name Main Contribution
6LoWPAN       IP-over-802.15.4 Shim Layer
ROLL RPL – протокол маршрутизации для многосвязных сетей
CoRE CoAP – ограниченный прикладной протокол
Основная идея конфигурации route-over для ZigBee заключается в использовании IPv6 во всех возможных случаях и во внесении изменений по мере необходимости. Для сжатия датаграмм IPv6 и отправки их по радиоканалу 802.15.4 был создан специальный протокол. Для обнаружения соседних узлов, находящихся в пределах прямой досягаемости, используется модифицированная форма технологии IPv6 Neighbor Discovery (Обнаружение соседей). Кроме того, особый протокол был разработан для обмена характеристиками между соседними узлами.
В дополнение к этому для сбора информации о возможности соединения (связности) в рамках всего меша и расчета данных пересылки используется новый протокол маршрутизации. И наконец, заголовок исходного маршрута IPv6 используется для «похоповой» (посегментной) пересылки каждой датаграммы через весь меш. Следующие разделы содержат описание некоторых базовых протоколов.
Протокол IPv6 over Low-Power Wireless Networks
Протокол IPv6 over Low-power Wireless Personal Area Networks (6LoWPAN) определяет транспортировку IPv6 через радиоканал 802.15.4. Главная проблема заключается в конфликте между требованием IPv6 к длине MTU – не менее 1280 октетов[5] – и особенностями протокола 802.15.4, который требует, чтобы максимальная длина не превышала 127 октетов. Фактически, если используется шифрование AES-CCM-128, то доступная полезная нагрузка снижается до 81 октета. Для того, чтобы отправить датаграмму IPv6 через такой канал, протокол 6LoWPAN вводит дополнительный «промежуточный» уровень, который осуществляет сжатие и передачу данных. Промежуточный уровень принимает исходящую датаграмму IPv6, сжимает заголовок, разделяет датаграмму на ряд сегментов, называемых «фраглетами» (fraglet), и отправляет каждый фраглет внутри отдельного пакета. На приеме промежуточный уровень 6LoWPAN принимает входящие фраглеты, объединяет и восстанавливает их в единую датаграмму, распаковывает заголовок и передает результат уровню IP. Это значит, что IPv6 конфигурируется таким образом, чтобы отправлять и получать законченные датаграммы, не зная о том, что промежуточный уровень разбивает датаграмму на фраглеты для последующей передачи. Существуют две причины, по которым 6LoWPAN не использует обычную фрагментацию IPv6. Первая причина: протокол 6LoWPAN работает только через единичный канал. В результате этот протокол гораздо проще, поскольку все фраглеты датаграммы должны прибывать в определенном порядке. Вторая причина: фрагментация IPv6 не способна обрабатывать MTU, состоящие из 127 октетов.
Протокол 6LoWPAN Neighbor Discovery

Традиционный протокол IPv6 Neighbor Discovery (IPv6-ND) предоставляет механизм определения адресов, который можно использовать, помимо прочего, для обнаружения дублирования адреса (DAD, Duplicate Address Detection). К сожалению, IPv6-ND содержит фундаментальное допущение о том, что префикс IPv6 устанавливает соответствие с широковещательным доменом. Поэтому узел может использовать широковещание IPv6, преобразуемое в аппаратное широковещание, для охвата всех узлов, которые имеют один и тот же префикс. Однако в рамках многосвязной топологии широковещательная передача может достигнуть только некоторых узлов меша, оставляя часть узлов вне соединения. В результате обычная функция DAD будет работать неправильно.
Протокол 6LoWPAN Neighbor Discovery (6LoWPAN-ND) вносит в IPv6-ND несколько изменений и оптимизаций, которые специально предназначены для маломощных беспроводных сетей с потерями, имеющих ограниченный диапазон. В общем случае 6LoWPAN-ND исключает все механизмы, которые «наводняют» меш пакетами. Вместо того, чтобы требовать от отдельных узлов участия в DAD, 6LoWPAN-ND использует регистрационный подход, в рамках которого каждый узел меша регистрирует свой адрес на граничном маршрутизаторе.
По мере того, как узлы регистрируют свои адреса, программное обеспечение, работающее на граничном маршрутизаторе, помечает все адрес-дубликаты (напоминаем, что граничный маршрутизатор располагает вычислительной мощностью и памятью, которые необходимы для работы с такими общесетевыми сервисами, как регистрация адресов). И наконец, 6LoWPAN-ND позволяет узлам спать (т.е. переходить в состояние покоя для экономии энергии). После пробуждения такой узел должен возобновить регистрацию своего адреса на случай, если некий другой узел зарегистрировал адрес-дубликат в течение его сна.
Протокол MLE (Mesh Link Establishment)
При разработке IPv6 было принято допущение о том, что базовые аппаратные соединения сконфигурированы до выполнения программного обеспечения IP. В частности, IPv6 ожидает, что обмен данными был аутентифицирован, т.е. соединения уже должны существовать. Для меша 802.15.4 узел должен выбрать, каким образом следует подключиться к дереву пересылки. Конфигурирование соединений является довольно сложным делом, поскольку передача радиосигналов может быть асимметричной. Узел не может просто «прослушать» передаваемые соседями сигналы и выбрать из них узел с самым сильным сигналом, поскольку возникает вопрос о том, насколько хорошо его сигнал принимается этим соседним узлом. Давайте рассмотрим случай граничного маршрутизатора, обладающего мощным передатчиком и большой антенной. Возможна ситуация, когда узел получает сильный сигнал от граничного маршрутизатора, даже если его передатчик слишком слаб, чтобы «дотянуться» до граничного маршрутизатора. Таким образом, перед тем, как использовать IPv6 в меше route-over, необходимо добавить низкоуровневый протокол, который позволит узлу узнать уровень сигналов, наблюдаемых соседями при получении данных от этого узла.
ZigBee использует протокол Mesh Link Establishment (MLE) для конфигурирования соединений. MLE прибегает к помощи двустороннего обмена пакетами: один узел передает сообщение, а принимающий узел отправляет ответ. В ответе содержится информация о наблюдаемом качестве сигнала. После получения узлом MLE-ответа от каждого соседнего узла этот узел будет знать о том, насколько хорошо каждый из его соседей может принимать передаваемые данные. Конечно, сила сигнала может меняться по прошествии времени, если происходит перемещение узлов или появляются электрические помехи (например, начинает работать мощный электродвигатель). Поэтому такие измерения необходимо периодически повторять.
MLE включает не только средства, которые оценивают силу сигнала. В ходе передачи пакета MLE позволяет узлам обмениваться конфигурационной информацией. Два узла обмениваются адресной информацией и выбирают тип защиты для своего соединения. Самое важное, MLE позволяет узлу информировать соседа о том, что он может «дотянуться» до граничного маршрутизатора. Таким образом, после присоединения к мешу новый узел запускает MLE, собирает информацию о том, какие из его соседей имеют путь до граничного маршрутизатора, и использует силу сигнала для выбора одного из таких соседей в качестве родительского узла в дереве пересылки.
Интересно отметить, что не все протоколы ZigBee учитывают асимметричную силу сигнала. В частности, при построении дерева пересылки протокол RPL (Routing Protocol for Low-Power and Lossy Networks) выбирает соединения, которые являются двунаправленными; если коммуникация может осуществляться только от узла А к узлу Б, то RPL не включает такое соединение.
Однако способность осуществлять обмен данными не означает, что его качество одинаково в обоих направлениях. В случае граничного маршрутизатора, обменивающегося данными с другим узлом, кажется разумным допустить, что сигнал, отправленный граничным маршрутизатором, может быть сильнее, чем сигнал, отправленный узлом. Даже в случае двух узлов, ни один из которых не является граничным маршрутизатором, возможна ситуация, когда сигнал, полученный в одном направлении, гораздо сильнее, чем сигнал, полученный в обратном направлении. Несмотря на это, после завершения выбора пути RPL отправляет по нему трафик в обоих направлениях.
Пересылка данных в меше ZigBee Route–Over
Обычная IP-пересылка использует префикс IP при выборе следующего хопа. Однако, как это уже указывалось ранее, некоторые узлы сети будут «на соединении» (т.е. их можно достичь напрямую), а остальные «вне соединения» (т.е. их можно достичь только опосредованно). Поэтому при решении вопроса о том, каким образом переслать датаграмму, IP должен иметь в своем распоряжении больше информации, чем только префикс сети. Проблема может быть решена двумя способами, и ZigBee IP использует термины «режим с хранением» (storing mode) и «режим без хранения» (non-storing mode) для того, чтобы охарактеризовать эти два подхода.
Как это подразумевает термин «режим с хранением», каждый узел сети хранит значительный объем информации. В дополнение к хранению адреса родительского узла (т.е. адреса следующего хопа по направлению к граничному маршрутизатору) каждый узел узнает и сохраняет адрес следующего хопа для каждого узла, расположенного «ниже по течению». В терминах теории графов это значит, что узел дерева хранит следующий хоп для каждого узла в своем поддереве. Наихудший сценарий возможен в сети, в которой единственный узел N соединяет все другие узлы с граничным маршрутизатором. В таком случае узел N хранит следующий хоп для всех остальных узлов сети.
Если возникает необходимость в отправке датаграммы, то работающее на узле программное обеспечение IP запрашивает информацию о пересылке, которая хранится локально (на том же узле). Если место назначения расположено в нисходящем направлении, то эта информация указывает следующий хоп, который нужно использовать. Если место назначения не расположено в нисходящем направлении, то узел направляет датаграмму вдоль пути, ведущего к граничному маршрутизатору.

Требования к памяти для режима с хранением превышают те, которые подразумевает предыдущее описание. После того, как RPL рассчитает маршруты, узел должен хранить в памяти только следующий хоп для мест назначения, расположенных в его поддереве (в худшем случае N – 1 пунктов назначения). Однако в ходе расчета маршрутов необходима дополнительная память, RPL использует алгоритм маршрутизации с учётом состояния каналов. Поэтому узел должен собрать попарные анонсы соединений для всех каналов поддерева, а затем запустить и выполнить алгоритм поиска кратчайшего пути для расчета следующих хопов. Требуемый объем памяти по-прежнему пропорционален количеству узлов в поддереве, однако расчет может потребовать вдвое больше памяти, чем необходимо для хранения информации о следующих хопах.
Хотя режим с хранением и решает задачу по передаче данных вдоль границ дерева пересылки, он не обеспечивает оптимальную маршрутизацию во всех случаях. Рассмотрим для примера два узла, которые расположены близко друг от друга, но не на одном и том же поддереве пересылки.
Если один из этих узлов отправляет данные другому, то пакет направляется вверх по дереву в направлении граничного маршрутизатора. Когда пакет достигнет узла, который является общим для обоих поддеревьев маршрутизации, направление его движения изменится на нисходящее вдоль по другому поддереву до пункта назначения. Худший сценарий реализуется в том случае, когда единственным общим узлом обоих поддеревьев является граничный маршрутизатор: пакет должен быть транспортирован на максимальное расстояние вверх вдоль одного из поддеревьев до граничного маршрутизатора, после чего он перемещается вниз вдоль другого поддерева до пункта назначения. IETF разрабатывает протокол, который сможет обнаруживать и использовать маршруты, расположенные вне дерева пересылки.
Концепция дерева пересылки и протокола маршрутизации, такого как RPL, который рассчитывает и обслуживает дерево, обусловлена тремя допущениями: топология остается относительно статичной, узлы часто обмениваются данными между собой и задержка при коммуникации должна быть минимизирована. Благодаря предварительному расчету дерева пересылки узлы меша готовы к перенаправлению любого пакета в любое время. В ситуациях, когда топология меняется либо трафик становится редким (например, сенсорный меш, в котором показания датчиков собираются раз в неделю), накладные расходы на поддержание маршрутов могут быть неоправданными. Вместо этого более эффективным способом может оказаться использование подхода «по запросу», в рамках которого узлы меша ждут получения пакета, осуществляют поиск маршрута, отправляют пакет и затем удаляют маршрут.
Режим без хранения предназначен для сетей, в которых узлы имеют ограниченный объем памяти и процессорных ресурсов. Для того, чтобы минимизировать локальное хранение и обработку данных, каждый узел должен знать только две вещи: набор соседних узлов в пределах его прямой досягаемости и идентификатор того соседнего узла, который ведет к граничному маршрутизатору. Предполагается, что граничный маршрутизатор располагает существенными объемами памяти и большой процессорной мощностью, которые позволяют ему выполнять все необходимые расчеты пути. Граничный маршрутизатор знает полную топологию меша и обрабатывает всю маршрутизацию по источнику. Когда у узла появляется датаграмма для отправки, он направляет ее граничному маршрутизатору. Если датаграмма предназначена для сайта в Интернете, то граничный маршрутизатор перешлет ее. Если датаграмма предназначена другому узлу меша, то граничный маршрутизатор «инкапсулирует» ее во внешней датаграмме, использует копию топологической информации для вставки заголовка исходного маршрута во внешнюю датаграмму и направляет инкапсулированную датаграмму через меш. На каждом шаге узел меша находит адрес соседнего узла в заголовке исходного маршрута и использует этот адрес для отправки датаграммы указанному соседу. Пожалуй, наиболее серьезное последствие использования IPv6 для реализации меша route-over проистекает из требования к маршрутизации по источнику для режима без хранения и требования к размеру заголовка исходного маршрута IPv6.
Может показаться, что режим без хранения напрасно растрачивает сетевые ресурсы, поскольку датаграмма, отправленная от одного узла другому, приходит сначала в граничный маршрутизатор и только затем в пункт назначения. Наихудший сценарий реализуется в том случае, когда пакет отправляется между парой узлов, которые находятся на расстоянии двух хопов, но деревья пересылки которых пересекаются только в граничном маршрутизаторе – вместо двух хопов пакет может быть транспортирован через N хопов, где N – количество узлов.
Несмотря на это, Альянс ZigBee выбрал режим без хранения с тем, чтобы позволить отдельным узлам иметь чрезвычайно малый объем памяти и низкую частоту процессора, сводя к минимуму как издержки, так и энергопотребление.
Важное соображение относительно режима с хранением является результатом ограничений на масштабирование: в наихудшем случае для хранения информации о связности меша требуется объем памяти пропорциональный N – количеству узлов в сети. Хотя большинство многосвязных сетей ZigBee имеют меньше 24 узлов, некоторые такие сети содержат тысячи узлов. Следовательно, режим с хранением для крупного меша означает, что каждый узел должен хранить таблицы, которые довольно велики по сравнению с объемом памяти, доступным в небольших устройствах (например, 64 или 128 килобайт ОЗУ). Использование режима без хранения позволяет узлам, работающим от небольшой батареи, хранить в памяти лишь следующую информацию:

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

Следует отметить, что объем памяти, требуемый для использования режима без хранения, пропорционален количеству соседних узлов, находящихся в пределах прямой досягаемости, и это число обычно значительно меньше, чем количество узлов меша. Фактически, даже находясь в плотном меше, узел может ограничить этот список верхними K узлами (т.е. K соседей, которые сообщили о самом сильном сигнале).
Протокол RPL
В IETF был разработан протокол маршрутизации, который может использоваться вместе с IPv6 в многосвязных сетях route-over. Этот протокол, известный под именем Routing Protocol for Low–Power and Lossy Networks (RPL), позволяет узлам объявлять прямые соединения и узнавать о других соединениях в меше. RPL определяет заголовок IPv6, позволяя датаграмме переносить информацию RPL в дополнение к полезной нагрузке. Стандарт ZigBee IP определяет использование режима без хранения. В рамках режима без хранения RPL распространяет информацию о соединениях вверх до граничного маршрутизатора. На граничном маршрутизаторе выполняется специальная версия программного обеспечения RPL, которая собирает информацию, т.е. оно строит топологию всего меша.
После построения топологии граничный маршрутизатор вычисляет дерево пересылки. Вместо наложения дерева на ненаправленный граф, RPL делает каждое соединение направленным – в сторону корня (т.е. в сторону граничного маршрутизатора). Граф топологии меша, создаваемый RPL, называется DODAG (Destination-Oriented Directed Acyclic Graph). Рис. 2 показывает DODAG в форме дерева, представленного на рис. 1.
Хотя соединения в DODAG направлены в сторону корня, такое представление является лишь особенностью протокола, оно не навязывает направление потока пакетов. В частности, в тех случаях, когда граничному маршрутизатору требуется отправить датаграмму одному из узлов, он использует DODAG в обратном направлении, создав заголовок исходного маршрута, в котором узлы перечислены вниз по дереву (т.е. в обратном порядке относительно стрелок на рисунке).

RPL разделяет узлы дерева на три типа: корень (граничный маршрутизатор действует в качестве корня DODAG), лист (т.е. узел, который имеет только одно соединение) и промежуточный узел (узел, который имеет не менее двух соединений, и который пересылает датаграммы). Поскольку промежуточные узлы перенаправляют пакеты, стандарт ZigBee IP использует термин «маршрутизатор ZigBee IP» или более коротко «маршрутизатор ZIP». Узлы-листья не выполняют протокол RPL. Вместо этого каждый узел-лист подключен к маршрутизатору ZIP, который выполняет все его функции по пересылке. Т.е. маршрутизатор ZIP информирует граничный маршрутизатор о каждом узле-листе, с которым он соединен.
Протокол RPL устроен гораздо сложнее, чем это здесь описывается. Например, RPL можно использовать вместе с режимом «с хранением»; сообщения должны задавать используемый режим. Кроме того, RPL способен распространять информацию вниз по дереву. Например, существует возможность использовать RPL для информирования узлов об используемых IP-префиксах.
Другие протоколы в спецификации ZigBee IP
Помимо основных протоколов, которые были определены выше, спецификация ZigBee IP включает многие другие протоколы. ZigBee IP использует IPv6, Internet Control Message Protocol Version 6 (ICMPv6), TCP, User Datagram Protocol (UDP), Protocol for carrying Authenticationfor Network Access (PANA), multicast DNS (mDNS), DNS Service Discovery (DNS-SD) и Transport Layer Security (TLS), который используется в сочетании с PANA, Extensible Authentication Protocol (EAP) и Extensible Authentication Protocol Transport Layer Security (EAP-TLS) для аутентификации. Приложения, соответствующие требованиям Smart Energy Profile 2.0[6], используют в качестве коммуникационного протокола традиционный HTTP. В качестве альтернативы группа IETF разрабатывает новый протокол, известный как Constrained Application Protocol (CoAP)[7], который предназначен для ограниченных сетей, включая меш 802.15.4. На рис. 3 представлены основные протоколы

Анализ использования IPv6 Route–Over для меша
Существует много вопросов относительно использования IPv6 и подхода route-over в меше, состоящем из энергосберегающих, беспроводных сенсорных узлов. Какой подход лучше – route-over или mesh-under? Как много дополнительных протокольных накладных расходов требуется для route-over? Будет ли реализация route-over требовать больше памяти, чем mesh-under? Если да, то насколько? Имеет ли смысл использовать IPv6 в многосвязной сети, которая имеет очень малый размер MTU и чрезвычайно медленные соединения? Если RPL использует режим без хранения, то каковы накладные расходы в контексте дополнительной пересылки пакетов? Насколько необходимо изменить IPv6 и протоколы поддержки IPv6 для того, чтобы они работали в многосвязной топологии?
Как отмечалось выше, стандарт IPv6 определяет, что протокол IPv6 нельзя использовать в сети с размером MTU меньше, чем 1280. Таким образом, 6LoWPAN добавляет промежуточный уровень, который делит датаграмму на фраглеты для последующей передачи. Транспортировка фраглетов имеет преимущество по сравнению с обычной фрагментацией: все фраглеты должны прибывать последовательно и в определенном порядке. Т.е. после того, как первый фраглет достигнет получателя, последующие фреймы (кадры), поступающие от отправителя, должны содержать остальные фраглеты – без присутствия фраглетов из других датаграмм. Таким образом, если входящий фрейм не содержит ожидаемого фраглета, то получатель отбрасывает всю датаграмму. Преимущество фраглетов по сравнению с традиционной фрагментацией заключается в пониженном использовании памяти: получателю не требуется хранить буферы для набора частичных датаграмм.
Главный недостаток фраглетов является результатом комбинации трех факторов: большой размер датаграммы, чрезвычайно малый размер MTU и более высокая вероятность потери. Особенно большим размером отличаются датаграммы, отправляемые из граничного маршрутизатора в адрес отдельного узла меша, поскольку дополнительный уровень инкапсуляции приводит к добавлению базового заголовка IPv6 и заголовка исходного маршрута.
В результате датаграмма минимального размера (1280 октетов) будет разделена на 11 фраглетов. Если вероятность потери конкретного пакета равна p (0 <p ≤ 1), то вероятность потери всей датаграммы гораздо выше, чем p. Хотя спецификация 6LoWPAN распознает поведение с потерями, активное использование транспортировки фраглетов увеличивает повторную передачу данных (и задержку).
Еще одна проблема, связанная с MTU, возникает из-за того, что граничный маршрутизатор должен выбрать MTU для датаграмм, поступающих извне меша. Стандарт IPv6 определяет MTU для соединения равным 1280 октетов. Если граничный маршрутизатор принудительно использует MTU размером 1280 октетов для внешних соединений, то прибывающая извне датаграмма должна быть дополнительно инкапсулирована перед ее последующей передачей в меш. К сожалению, дополнительный заголовок увеличивает размер датаграммы до 1280 + δ, что делает ее размер больше, чем 1280 октетов MTU протокола 6LoWPAN. Одно из решений определяет размер MTU протокола 6LoWPAN как 1280 + δ, но требует от граничного маршрутизатора принудительного ограничения на размер MTU (1280 октетов) для внешних источников. К сожалению, введение такого специального ограничения в код IPv6 ведет к снижению универсальности протокола – применение нестандартных методов для работы с мешем делает стек протоколов неустойчивым. Например, если кто-нибудь изобретет новый механизм обнаружения MTU для пути, то этот новый механизм нельзя интегрировать в граничный маршрутизатор до тех пор, пока он не будет адаптирован в соответствии со специальными правилами MTU.
Разработчикам было понятно, что обычные протоколы IPv6 нельзя использовать для конфигурирования радиоканала либо для двусторонней оценки сигнала. Поэтому они создали протокол MLE. Кроме того, им пришлось заменить протокол IPv6 Neighbor Discovery, поскольку хотя узлы меша используют единый IP-префикс, они не принадлежат к единому широковещательному домену. На первый взгляд, кажется, что MLE и IPv6-ND могут быть модифицированы для совместной работы: MLE обнаруживает соседние узлы, а IPv6-ND использует информацию, полученную от MLE, для ведения списка MAC-адресов соседей. Однако IPv6-ND также решает другие задачи. Например, IPv6-ND использует сообщения ICMPv6 для распространения сетевой информации, включая сетевые префиксы. К сожалению, RPL также предоставляет способ для распространения сетевого префикса вниз (по дереву) от граничного маршрутизатора до узлов меша. Следует ли использовать IPv6-ND или RPL? Каков бы ни был выбор, один из этих двух протоколов должен быть изменен с тем, чтобы избежать «гонки», в рамках которой оба протокола пытаются одновременно распространять префиксы адресов. ZigBee IP решает эту проблему, определив, что только 6LoWPAN-ND следует использовать для распространения информации о конфигурации сети.
В статье утверждалось, что для экономии электроэнергии узлы меша ZigBee могут переходить в режим сна. Интересно отметить, что механизм обнаружения адреса может потребовать, чтобы узел потратил дополнительную энергию. Для того, чтобы увидеть, почему это происходит, необходимо знать два факта. Первое, при регистрации адреса присваивается интервал времени действия, в течение которого эта регистрация остается действительной. Второе, ради экономии энергии режим сна останавливает работу максимального количества аппаратных средств. Таким образом, возможна ситуация, когда часы (тактовый генератор) энергосберегающего узла не работают в течение цикла сна.

А теперь представьте, что произойдет при пробуждении узла. Если цикл сна был достаточно длительным, либо если часы (тактовый генератор) не работали, то узел не может знать о возможном прибытии нового узла и о возможной регистрации дублирующего IP-адреса в граничном маршрутизаторе. Таким образом, после пробуждения узел должен отправить сообщение о перерегистрации и получить ответ до того, как он сможет использовать свой адрес. В рамках обычной сети использование протоколом IPv6 адресного префикса /64 и встроенных MAC-адресов делает маловероятным дублирование адресов. Однако стандарт 802.15.4 включает 16-битовый MAC-адрес, и это означает, что узлы должны выполнять требования протокола во избежание дублирования адресов.
Другое неожиданное осложнение является результатом маршрутизации в меше. Используемые в обычных сетях протоколы маршрутизации выбирают кратчайшие пути (за исключением случаев, когда политика определяет иное). Протоколы маршрутизации меша должны иметь дело с несколькими независимыми переменными: сила радиосигнала вдоль пути, длина пути и вероятность помех. Таким образом, кратчайший путь через меш может быть неоптимальным. Что более важно, не существует простого способа оценить вероятность помех или количественно оценить обратную зависимость между длиной пути и качеством сигнала. На самом деле возможны трудности даже при расчете зависимости эффективной пропускной способности от качества сигнала. Источники электропитания могут еще больше усложнить маршрутизацию. Например, можно представить систему маршрутизации, которая предпочитает узлы, получающие питание от непрерывного источника, узлам, получающим питание от батареи. В результате того, что приходится осуществлять оптимизацию по многим параметрам и без очевидной целевой функции, протоколы маршрутизации меша могут оказаться более сложными и менее поддающимися настройке, чем обычные протоколы маршрутизации.
Частично неэффективность меша ZigBee является результатом фундаментального решения, принятого при разработке IPv6: заголовок датаграммы IPv6 нельзя изменять после того, как датаграмма окажется в пути. Для того, чтобы перемещаться по мешу, датаграмма должна включать заголовок исходного маршрута и заголовок RPL. Однако эти дополнительные заголовки имеют смысл только внутри меша и должны быть удалены после выхода из него. Если разрешить дополнительным заголовкам остаться, то датаграмма может пересечь еще один меш ZigBee, в котором его информация может быть неправильно интерпретирована, что приведет к ошибочному перенаправлению датаграммы. Аналогичным образом, если датаграмма поступает в меш извне, то к ней необходимо добавить соответствующие заголовки. В результате решений, принятых при разработке IPv6, заголовки нельзя удалять или добавлять. Поэтому единственной приемлемой опцией остается инкапсуляция: каждая датаграмма IPv6, пересылаемая через меш, должна быть инкапсулирована внутри другой датаграммы IPv6, имеющей соответствующие заголовки. Для сети с MTU большого размера инкапсуляция IP-in-IP добавляет лишь небольшой объем служебной информации. Однако для сети 802.15.4 размер аппаратного MTU составляет только 127 октетов. Таким образом, единственная пара адресов IPv6 (источник и пункт назначения) занимает более 25% объема MTU. Для сравнения, пара адресов IPv4 занимает немногим более 6% MTU. В отличие от протокола IPv4, который разрешает вставлять опции в существующий заголовок, IPv6 требует инкапсуляции заголовка для вставки опции исходного маршрута. Такой подход требует добавления нескольких IPv6-адресов, что легко приводит к генерированию одного или нескольких дополнительных фраглетов. В результате выбор IPv6 вместо IPv4 ведет к значительному увеличению накладных расходов и делает получившуюся сеть менее эффективной.
На основе вышеприведенного обсуждения мы делаем следующий вывод:
Хотя использование парадигмы route-over и стандарта IPv6 для меша ZigBee 802.15.4 и является возможным, реализация такого подхода потребует разработки альтернативных протоколов, создания специальных исключений и значительных дополнительных расходов.

Резюме
Новая тенденция концентрирует внимание на интернете вещей, в рамках которого интеллектуальные встроенные системы, воспринимающие и контролирующие свою среду, используют IT для обмена информацией. Примеры таких встроенных систем включают датчики в автомобилях, офисах, торговых центрах и гражданской инфраструктуре.
Консорциум производителей, известный как Альянс ZigBee, определяет стандарты для сетевых технологий, использующих беспроводное сетевое аппаратное обеспечение IEEE 802.15.4 для создания многосвязной сети (меша) датчиков интеллектуальной энергосистемы. Сеть ZigBee имеет в своем составе граничный маршрутизатор, который соединяет ее с внешним миром; другие узлы меша самоорганизовываются для формирования соединений и пересылки.
В контексте протоколов Альянс ZigBee работает совместно с IETF над реализацией подхода route-over, который использует IPv6. По сути дела, система route-over использует IP для любой переадресации. На практике IPv6 и стандартных протоколов поддержки IPv6 недостаточно для реализации энергосберегающей, беспроводной технологии меша с потерями, которая имеет небольшой размер MTU и низкую скорость передачи данных. Из этого следует, что работа была сконцентрирована на замене многих элементов IPv6, на добавлении промежуточного уровня, адаптирующего к небольшому размеру MTU, на разработке нового протокола, который тестирует силу сигнала и устанавливает соединения, и на построении нового протокола маршрутизации, формирующего дерево переадресации. Даже с учетом этих изменений конструктивные элементы IPv6 не очень хорошо вписываются в технологию IEEE 802.15.4.
Благодарность
Содержащиеся в настоящей статье материалы были взяты с разрешения.
Источник: ZigBee IP Protocol Stack, The Internet Protocol Journal Vol 17, No 2
Перечень ссылочных документов
[1] Стандарт IEEE 802.15.4 можно пробрести по адресу:
http://webstore.ansi.org/RecordDetail.aspx?sku=IEEE%20802.15.4-2011
[2] Информацию об Альянсе ZigBee можно найти на сайте:
http://www.zigbee.org/
[3] Информацию о группе IETF (Internet Engineering Task Force) можно найти на сайте: http://www.ietf.org/
[4] Информация о спецификации ZigBee IP:
http://zigbee.org/zigbee–for–developers/networkspecifications/zigbeeip/
[5] Stephen E. Deering and Robert M. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, RFC 2460, December 1998.
[6] Полный список спецификаций ZigBee можно найти по адресу:
http://zigbee.org/zigbee–for–developers/applicationstandards/
и:
http://zigbee.org/zigbee–for–developers/networkspecifications/
[7] Спецификацию протокола CoAP (Constrained Application Protocol) можно найти по адресу:
http://datatracker.ietf.org/doc/draft–ietf–corecoap/
[8] Douglas E. Comer, Internet working with TCP/IP Volume 1: Principles, Protocols, and Architecture, sixth edition, Prentice Hall, ISBN 0-13-608530-X.
[9] David Lake, Ammar Rayes, and Monique Morrow, “The Internet of Things”, The Internet Protocol Journal, Volume 15, No. 3, September 2012.
[10] T. Sridhar, “Cloud Computing — A Primer: Part One”, The Internet Protocol Journal, Volume 12, No. 3, September 2009.
[11] T. Sridhar, “Cloud Computing — A Primer: Part Two”, The Internet Protocol Journal, Volume 12, No. 4, December 2009.

Дуглас Коумер является заслуженным профессором компьютерных наук в университете Пердью. Ранее он работал в качестве вице-президента по исследованиям и совместным исследованиям в компании Cisco Systems. Являясь участником первоначального состава группы IAB, он участвовал в ранних разработках в области Интернета. Он получил международную известность как один из авторов протоколов TCP/IP и интернет-технологий. Дуглас Коумер написал целый ряд бестселлеров в области технической литературы, его трехтомная серия Internet working признана как авторитетная работа по интернет-технологиям. Его книги, которые были переведены на 16 языков, широко используются в отрасли и в академических кругах многих стран. Коумер консультирует отраслевые организации, его лекции прослушали тысячи профессиональных инженеров и студентов со всего мира. В течение 20 лет он был главным редактором журнала Software-Practice and Experience. Он является членом ассоциации ACM (Ассоциация по вычислительной технике США) и обладателем многочисленных наград за преподавательскую деятельность. Электронная почта: comer@cs.purdue.edu