Концепция Интернета вещей прошла большой путь от первоначальной идеи Кевина Эштона по созданию системы контроля цепочек поставок для компании Procter & Gamble на базе меток RFID (1999 год) и идеи умного дома, изложенной в журнале Scientific American в 2004 году, став сегодня наиболее обсуждаемой темой на ведущих международных конференциях. По классификации Gartner, Интернет вещей находится сейчас на пике ожиданий, и выход технологии на «плато продуктивности» ожидается не раньше, чем через пять-десять лет, — самое время подготовиться к падению интереса к идее, оптимизировав соответствующие технические решения с помощью открытых стандартов. Нельзя забывать, что Интернет стал всемирной Сетью в немалой степени именно благодаря тому, что в отрасли четко следовали существующим стандартам и уделяли серьезное внимание разработке новых открытых стандартов. Однако пока еще много разнобоя в осмыслении и тем более реализации концепции Интернета вещей. Например, в Google [1] считают, что сама концепция частично уже реализована и дело за малым — научиться ее применять для расширяющегося спектра бытовых устройств, объединяя их в сети.

На сегодня можно выделить ряд направлений развития технологий, связанных с Интернетом вещей, и главные из них — это идентификация, измерения, передача данных, обработка данных. Идентификация — наиболее обсуждаемый элемент в концепции. Действительно, любая вещь должна иметь уникальный идентификатор, и наиболее подходящим для этого принято считать IP-адрес стандарта IPv6. Остальные применяемые сегодня идентификаторы не позволяют поименовать все возможные «вещи» — им просто не хватает размерности, поэтому любому физическому идентификатору (RFID, QR-коду, штрихкоду и т. п.) должен быть поставлен в соответствие адрес в стандарте IPv6. Согласно определению аналитиков Gartner, Интернет вещей — это сеть физических объектов, которые содержат встроенные технологии для взаимной коммуникации, а также для определения или воздействия на внутреннее состояние этих объектов или внешнюю среду. В этом контексте измерения можно рассматривать как основу мониторинга состояния объектов и внешней среды. То же и с передачей данных — данные можно передавать в качестве команд, которые переводят объекты из одного состояния в другое, а можно и как потоки данных, считываемые с субъектов Интернета вещей. Обработка данных чаще всего рассматривается сегодня в традиционном ключе как функция систем сбора информации, однако для встроенных устройств речь скорее идет об исполнении команд, чем о сборе и хранении больших объемов информации.

Центром разработки стандартов для Интернета являются рабочие группы Internet Engineering Task Force, которые готовят и публикуют Request For Comments — серии документов, представляющих собой технические или организационные материалы о Сети, включая протоколы, процедуры, программы и концепции, а также материалы конференций, мнения, а иногда и юмор. В контексте Интернета вещей интерес представляют главным образом RFC и Drafts (прототипы предложений), выпущенные вслед за документом «The Internet of Things — Concept and Problem Statement», который уже ушел в архив, но представляет определенный интерес благодаря наличию ключевых определений.

Интернет вещей — сеть объектов/вещей/товаров повседневного спроса.

Вещь — объект физического (реальная «вещь») или информационного (виртуальная «вещь») мира. Данный объект должен быть уникально идентифицирован и интегрирован в сеть (должен иметь уникальный адрес и способность взаимодействовать с другими «вещами»). В качестве основных претендентов на роль «вещи» рассматриваются простые устройства типа сенсоров (sensors) и сервоприводов (actuators), которые обладают ограниченными возможностями по хранению и обработке информации и предъявляют особые требования к энергопотреблению.

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

Если рассматривать Интернет вещей через призму стека протоколов TCP/IP, то для каждого из уровней стека можно выделить свою задачу и, соответственно, попытаться предложить свой стандарт протокола. В качестве физической (физический/канальный уровни стека) основы для организации сетей Интернета вещей рабочей группой IETF «IPv6 over Networks of Resource-constrained Nodes» предложен стандарт IEEE Std 802.15.4-2011 (Low-Rate Wireless Personal Area Networks, LR-WPAN).

Для идентификации устройств и взаимодействия сетей устройств (сетевой уровень или уровень межсетевого обмена) предлагается использовать несколько специализированных протоколов, разрабатываемых в рамах рабочих групп IETF. Это, в частности: IPv6 over Low-Power Wireless Personal Area Networks (RFC 4919) [2] — для передачи IPv6-пакетов через беспроводные персональные сети; а также Routing Over Low Power and Lossy Networks (ROLL) — для маршрутизации IPv6 в беспроводных персональных сетях.

Для уровня приложений разрабатываются дополнительные средства интеграции данных, получаемых из беспроводных персональных сетей, — на решение этой задачи направлены усилия рабочей группы IETF Constrained RESTful Environments (CoRE).

В общем случае Интернет вещей может строиться на основе передачи данных в любой среде, однако наиболее интересны беспроводные сети, и именно на них сосредоточены усилия разработчиков стандартов для IoT. В качестве основы такой беспроводной среды выбраны сети стандарта IEEE Std 802.15.4-2011, предусматривающего низкую скорость передачи небольших объемов данных, малое расстояние передачи и низкое энергопотребление. В стандарте определены физический уровень (PHY) и уровень взаимодействия с сетью MAC (Medium Access Control). На физическом уровне устанавливаются способы активирования и деактивирования устройства, приема и передачи данных, производится выбор частоты передачи и определение занятости канала передачи — все это важно для устройств, которые могут находиться в «спящем» режиме и «просыпаться» по команде или по событию. Наиболее вероятная скорость передачи данных — 250–1000 Кбит/с. Максимальный размер фрейма данных (вместе с заголовками) — 133 байта. Возможно два формата адресов: 16-битовый и 64-битовый, как это определено в IEEE Std 802.15.4-2011. В любом случае это меньше 128 бит в адресе IPv6.

Согласно прогнозам игроков рынка ИТ, к 2020 году к сети будет подключено 50 млрд устройств. Считается, что примерно с этой отметки начинается Интернет вещей и для идентификации такого количества устройств и нужен IPv6. Однако два адреса формата IPv6 в заголовке IP-пакета — это 128*2=256 байт, что превышает заголовок фрейма для сетей стандарта IEEE Std 802.15.4-2011. Следовательно, IPv6-пакет нужно сжимать и/или фрагментировать, однако, кроме адресов, в нем должна присутствовать другая необходимая для межсетевого обмена информация. Именно эту задачу и решают протоколы семейства IPv6 over Low-Power Wireless Personal Area Networks.

Основным документом, определяющим передачу пакетов IPv6 в сетях стандарта IEEE Std 802.15.4-2011, является RFC 4944, который регламентирует формат фрейма для передачи пакетов через сети IEEE 802.15.4, а также автоконфигурирование локальных адресов для передачи данных в локальных сетях и вводит промежуточный уровень между уровнем IEEE 802.15.4 (сетевой и взаимодействия с сетью) и уровнем межсетевого обмена (IP). Методы компрессии заголовка IPv6 и трансформация пакета также описаны в RFC 4944, а способы маршрутизации пакетов разбираются в отдельных документах, например в RFC 6550. В первую очередь компрессии подвергаются заголовки узлов, связанные локально, — из адреса убираются общие части, а из заголовка — поля, которые не нужны при локальной передаче данных. Далее компрессия распространяется на заголовки транспортного уровня (UDP и TCP). Однако одной компрессии может быть недостаточно — размер пакета все равно превышает 106 байт (размер фрейма IEEE Std 802.15.4-2011 — 133 байт, размер его заголовков — 6 байт, при использовании «длинного» формата адреса заголовка MAC, инкапсулированного во фрейм, — 19 байт, два байта выделяется для контрольной суммы, остальные данные — 106 байт), поэтому промежуточный уровень, описанный в RFC 4944, реализует возможность фрагментации исходных пакетов, а не пакетов IPv6.

Cжатие заголовков в пакетах IPv6 вызывает проблемы с маршрутизацией — для построения маршрута маршрутизатор оперирует четырьмя адресами: исходным адресом отправления пакета, конечным адресом получения, адресом текущего маршрутизатора и адресом следующего маршрутизатора в соответствии с таблицей маршрутизации текущего маршрутизатора. Адреса маршрутизаторов — это MAC-адреса в стандарте IEEE 802.15.4, а вот начальный и конечный адреса — это адреса IPv6, следовательно, протокол маршрутизации через сети IEEE 802.15.4 должен содержать алгоритм преобразования адресов (сжатия пакетов). Идеи таких алгоритмов развиты в RFC 6282, но основным протоколом обмена маршрутной информацией является RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks (RFC 6550). В этом протоколе определены типы обмена данными: «многие к одному», «один ко многим» и «один к одному». Но главное — фактически все объекты маршрутизации являются узлами дерева, и пакеты между узлами путешествуют по ветвям этого дерева либо через корень, либо через ближайший родительский узел, а листьями дерева являются сенсоры или другие вещи Интернета вещей. Перемещение сообщений между сенсорами возможно через узел-концентратор, и обычно таким узлом будет корень дерева: сообщение будет от листа следовать до корня, а потом по новой ветке спускаться к другому листу. Это означает, что промежуточная связь через любое коммутирующее устройство рассматривается как маловероятная, и совсем нереально, что сенсоры будут общаться напрямую.

Хождение пакетов через узел-концентратор — это типичное решение задачи сбора информации с датчиков. Так устроено большинство современных систем контроля множества датчиков. Очень вероятно, что возможность прямого обмена данными с датчиком останется совершенно не востребованной, так же как не востребован в настоящее время механизм мгновенного обмена сообщениями (instant messaging) в протоколе SMTP.

В текущей версии RPL мобильные устройства не поддерживаются — cуществуют лишь различные предложения по разработке протоколов с поддержкой мобильности, но они еще не вышли на IETF-трек разработки стандартов.

В области протоколов прикладного уровня основные усилия в контексте Интернета вещей сосредоточены на разработке протоколов типа WWW — с 2010 года этим занимается рабочая группа CoRE. Задача этой группы — разработка протокола приложений для встроенных устройств CoAP (Constrained Application Protocol). Основные свойства такого протокола:

  • возможность создавать, читать, обновлять и удалять ресурсы на устройстве;
  • возможность разрешить устройству размещать значение или событие на другом устройстве, которое подписано на подобные действия;
  • возможность многоадресной рассылки сообщений группе устройств для манипулирования ею;
  • использование UDP в качестве основного транспорта, а TCP — только опционная возможность обмена данными;
  • применение идентификаторов типа URI с использованием DNS;
  • использование расширений HTTP;
  • требование для любого протокола иметь индикатор, отображающий снабжение устройства энергией.

В июне 2014 года была завершена работа над протоколом CoAP (RFC 7252) [3] — порядок межмашинного обмена данными через Web (web transfer protocol), которому должны следовать встроенные устройства в сетях себе подобных, стал более-менее понятен. Этот протокол имеет архитектуру «клиент-сервер», ориентирован на нахождение ресурсов и сервисов в сети, поддерживает нотификацию URI, хорошо интегрируется с HTTP и поддерживает реализации стандартного управления устройствами. Любопытно, что в данном протоколе поддерживаются прокси и кэширование, а значит, доступ к устройствам Интернета вещей в архитектуре CoAP возможен из внешних приложений не напрямую, а через кэш — это исключает взаимодействие в реальном времени, оставляя лишь возможность получения некоторой усредненной информации о состоянии устройств. Такое решение дает возможность обеспечить как реакцию в реальном времени, так и контроль состояния за некоторый интервал времени.

Отдельно следует отметить документ RFC 6690, описывающий формат URI для работы в сетях встроенных устройств. Данная спецификация базируется на расширении стандартного формата URI для взаимодействия с сервером, поддерживающим протокол CoAP. Фактически ответом на любой запрос в CoAP является список ссылок, при этом сами ссылки — это скорее описания ресурсов, а не ссылки на ресурсы, как это принято в традиционном WWW. Запросы-ссылки должны решать несколько задач: поиск устройств; фильтрацию списков ссылок-описаний, которые клиент получает от сервера в ответ на запрос, и поиск ссылок в найденных коллекциях. Расширение стандартного формата URI в рамках RFC 6690 требовалось именно для этого, а для Интернета вещей решается вопрос адресации и получения описания ресурсов при межмашинном взаимодействии. Человеку как субъекту Интернета вещей по-прежнему удобнее работать со стандартами «обычного» WWW.

Сегодня в работе находятся еще несколько прототипов документов, относящихся к расширению перечисленных протоколов: draft-ietf-core-block-17 — передача блоков в CoAP; draft-ietf-core-http-mapping-06 — трансляция HTTP запросов в CoAP и трансляция CoAP ответов в HTTP. Все эти разработки направлены на обеспечение «прозрачного», незаметного для человека взаимодействия сетей встроенных устройств с традиционным WWW.

Еще одним аспектом работы по стандартизации в области Интернета вещей является создание протоколов автоконфигурации сетевых имен устройств, требуемой для построения интерфейса взаимодействия с ним человека. Если нужно с мобильного телефона включить кондиционер в спальне, то в идеале достаточно произнести «кондиционер». Однако как определить, какой именно кондиционер включится? Традиционно в Интернете для именования хостов используют доменные имена. Каждому такому имени в DNS ставится в соответствие IP-адрес, и авторы рабочего материала «DNS Name Autoconfiguration for Internet of Things Devices» также предлагают использовать DNS для назначения имен устройствам в Интернете вещей. Однако имена назначаются не всем устройствам, а только тем, с которыми взаимодействует человек — например, телевизор, кондиционер, стиральная машина и т. п. При этом имена предлагается назначать автоматически в зависимости от контекста окружающей среды, то есть устройства сами автоматически опрашивают окружающих соседей по сети и определяют свои имена, которые потом транслируются на устройства управления с обычным веб-интерфейсом. Данная идея вполне разумна — современные бытовые устройства, в отличие от встроенных датчиков и сервомеханизмов, как правило, имеют постоянное энергопитание и достаточные вычислительные мощности «на борту».

Несмотря на многообразие предложений по унификации работы объектов Интернета вещей, стандартизации пока подвергся лишь незначительный слой технологий — управление сетями встроенных устройств. Вероятно, это произошло из-за желания «съесть слона по частям», используя там, где возможно, уже существующие TCP/IP технологии для объединения «больших вещей» (компьютеров, смартфонов и т. п). Однако для «малых форм» данные технологии и стандарты непригодны в силу мизерности их возможностей, поэтому для этих приборов нужны и свои технологии, и свои стандарты.

Вслед за протоколами взаимодействия «маленьких» устройств стандартизация требуется и в области безопасности как самих таких устройств, так и обмена данными между ними. Сейчас в стадии разработки и обсуждения находятся документы: Transport Layer Security (TLS) и Datagram TLS (DTLS) — обеспечение безопасности транспортного уровня; Security Bootstrapping of IEEE 802.15.4 based Internet of Things — безопасное подключение встроенных устройств; DNS Name Autoconfiguration for Internet of Things Devices — безопасная идентификация; OAuth 2.0 Internet of Things — безопасное подключение приложений. Без этих стандартов о безопасности Интернета вещей говорить еще рано — именно этой точки зрения придерживаются в Федеральной торговой комиссии США, считая Интернет вещей «Интернетом угроз». Особенно это будет актуально при превращении Интернета вещей в Интернет всего [4], когда многократно возрастут требования к безопасности Сети.

***

Детальная проработка стандартов и вопросов организации сети для Интернета вещей свидетельствует о серьезности намерений индустрии довести концепцию до продуктивной стадии, однако не следует забывать, что на разработку стандартов обычно уходят годы, да и их реализация — процесс не быстрый, и за это время возможности встроенных устройств уйдут так далеко вперед, что специализированные протоколы могут не понадобиться. Однако вполне реальна и совсем другая история. В свое время в компании Sun Microsystems работали над проектом языка программирования встроенных интерфейсов бытовых приборов, который был признан неудачным, но языку нашли новое применение, и сейчас на нем запрограммировано более половины таких «бытовых» устройств, как сотовые телефоны. Что-то подобное может произойти и со специализированными протоколами для Интернета вещей, которые могут пригодиться совсем для других целей.

Анализ стандартов и различных подходов приводит к выводу, что, к сожалению, единой концепции Интернета вещей пока нет — есть сети встроенных устройств, для которых пытаются организовать взаимодействие на базе открытых спецификаций, есть попытки объединить в сеть «мощные» устройства и дать им адаптивный интерфейс. Вместе с тем достигнуто понимание того, что при бесконтрольном межмашинном взаимодействии существование «матрицы» Интернета вещей может само по себе представлять угрозу обществу. Совершенно очевидно только одно — по мере обретения более определенных очертаний и прорисовки деталей Интернет вещей как нечто целостное начинает постепенно отодвигаться в будущее, а на первый план выходят конкретные реализации конкретных проектов, привносящие все новые и новые проблемы. За пиком ожиданий на кривой зрелости технологий всегда следует глубокий спад, и далеко не все технологии выбираются на «плато продуктивности» — Интернету, благодаря пулу общепризнанных стандартов, это удалось.

Литература

  1. Рой Уонт, Бил Шилит, Скотт Дженсон. Механизмы Интернета вещей // Открытые системы.СУБД. — 2015. — № 1. — С. 38–42. URL: http://www.osp.ru/os/2015/01/13045328 (дата обращения 18.05.2015).
  2. G. Montenegro, N. Kushalnagar, J. Hui, D. Culler. Transmission of IPv6 Packets over IEEE 802.15.4 Networks, September, 2007. URL: https://tools.ietf.org/html/rfc4944 (дата обращения 18.05.2015).
  3. Z. Shelby, K. Hartke, C. Bormann. Constrained Application Protocol, June 2014.  URL: https://datatracker.ietf.org/doc/rfc7252 (дата обращения 18.05.2015).
  4. Ирена Боянова, Джордж Херлберт, Джеффри Воас. Интернет будущего // Открытые системы.СУБД. — 2014. — № 06. — С. 28–31. URL: http://www.osp.ru/os/2014/06/13042314 (дата обращения 28.05.2015).

Павел Храмцов (paulkh@yandex.ru) — доцент, Национальный исследовательский ядерный университет («МИФИ»).