В рубрику "Обзоры, прогнозы, мнения" | К списку рубрик | К списку авторов | К списку публикаций
Вадим 
АнастасияСтремительное развитие Интернета вещей [1, 2] привело к появлению множества прикладных протоколов, необходимых для его реализации. Вопросами стандартизации и практического внедрения этих протоколов занимаются международные организации (ITU-T [3], IEEE [4, 5], ETSI [6], OASIS [7]), неправительственные ассоциации (oneM2M [8]), альянсы производителей и операторов (IERC [9], ISO/IEC [10]), партнерские проекты (IoT-A [11]). Несмотря на большое число заинтересованных сторон или, наоборот, благодаря этому, предпринимаемые усилия в основном носят локальный, разобщенный характер и направлены на решение достаточно узких задач. Касательно участия российских компаний в этом процессе необходимо отметить, что такая доля мала и не позволяет сделать выводы о ее существенности. Стоит упомянуть о существовании Российской ассоциации Интернета вещей [12], которая относится к кластеру информационных технологий фонда "Сколково", официально участвует в работе международных организаций по стандартизации Интернета вещей (ITU-T) и представляет наши интересы среди мирового экспертного сообщества, поскольку внедрение Интернета вещей на отечественном рынке является очевидной задачей для ведущих телекоммуникационных компаний [13].
Анализ существующих публикаций показал, что данной тематике в русскоязычном сегменте посвящено не так много литературы [14, 15], а находящиеся в открытом доступе источники не раскрывают в полной мере интересующий нас вопрос использования прикладных протоколов Интернета вещей. В большинстве случаев внимание уделяется таким технологиям, как ZigBee, Bluetooth Low Energy, NFC, RFID и др. [16, 17]. В то же время в зарубежных источниках данный вопрос поднимается все чаще, однако информация также достаточно разобщена и носит ознакомительный характер [18, 19, 20]. Таким образом, очевидна необходимость в обобщении имеющихся материалов и их систематизации.
Цель настоящей статьи – аналитический обзор существующих протоколов, выработка рекомендаций по их использованию, классификация по ключевому критерию. Для эффективного достижения поставленной цели необходимо последовательно выявить особенности протоколов, этапы их взаимодействия, ключевые признаки классификации.
Становление Интернета вещей значительно расширяет возможности сбора, анализа и распределения данных, которые для человека превращаются в информацию, знания и используются для решения специфических задач. Существует множество реализаций сетей Интернета вещей [20–23] – системы контроля [24] и наблюдения на производственных объектах, в частных домах, а также в различных других сферах жизни [25], например в здравоохранении. То, чем будет являться Интернет вещей для конкретной организации или сферы, напрямую зависит от поставленных целей и задач.
Архитектура Интернета вещей предполагает наличие следующих функциональных уровней: сеть датчиков, шлюз, управление, приложение [3, 14]. Поскольку нижний уровень состоит из датчиков, сенсоров и актуаторов, то сразу же возникает необходимость в "особенных" протоколах для обеспечения взаимодействия этих устройств друг с другом и верхними уровнями. Стандартные прикладные протоколы не подходят ввиду их неприспособленности к условиям сети Интернета вещей. Датчик, обычно миниатюрный, с небольшой памятью, измеряет физические параметры в режиме реального времени, чаще всего в условиях низкого энергообеспечения. Результаты измерений обрабатываются сенсорным узлом и передаются на сервер. Объем информации, формируемый одним сенсорным узлом, сравнительно небольшой, однако большинство сервисов Интернета вещей построено на принципе обработки информации от множества узлов, что принципиально отличается от архитектур, принятых в классических сетях, типа абонент – узел связи для телефонии, клиент-сервер для передачи данных.
Таким образом, мы сталкиваемся с новой архитектурой: много источников – много получателей, кроме того, объем трафика от сенсорного узла может быть как очень маленьким, так и очень большим. Привычные прикладные протоколы не рассчитаны на подобное использование.
В качестве отправной точки исследования была взята следующая топология (см. рис. 1). Легко заметить, что такая сеть полностью подходит под описанную нами архитектуру Интернета вещей.
Представленная топология соответствует шаблону проектирования передачи сообщений [26], который носит название "издатель-подписчик" (Publisher-subscriber, или pub/sub) [27]. В такой схеме вводится понятие издателя – источника информации – и подписчика – ее получателя. Термин "подписка" связан с определенной операцией, выполняемой участниками шаблона, с целью получения информации подписчиком от конкретного издателя, а также упорядочивания сбора информации – параметров периодичности получения и аналогичных (в зависимости от реализации) показателей.
В данном случае рассматривается ситуация, когда сенсорный узел (на рис. 1 – Node) объединяет информацию от нескольких датчиков (например, данные телеметрической системы) и направляет ее согласно параметрам подписки либо по запросу, либо самостоятельно с определенным интервалом времени или по происшествии какого-либо события на сервер. Обычно сами датчики достаточно примитивны, их задачи сводятся к постоянной передаче информации о контролируемом параметре. Поэтому появляется необходимость объединять датчики в узлы, оснащенные микроконтроллерами, которые будут отвечать за считывание измеряемых данных и отправку их по заранее определенным алгоритмам далее на сервер. Также чаще всего для взаимодействия клиента с системой необходимо клиентское приложение (на рис. 1 – Application), установленное на персональном устройстве, служащее для графического представления получаемой с датчиков или уже обработанной сервером информации и управления системой. Такая топология также рассчитана на включение брокера (на рис. 1 – Broker). Брокер – это сервер, который принимает информацию от издателей и передает ее соответствующим подписчикам, в сложных системах может выполнять, также различные операции, связанные с анализом и обработкой поступивших данных [14]. Брокер может устанавливать приоритеты сообщениям и формировать очереди для передачи сообщений. Таким образом брокер организует пересылку сообщений, их хранение и фильтрацию. Под очередью сообщений понимается контейнер, или блок, в котором хранятся сообщения в процессе их пересылки. При недостаточном ресурсе канала связи или если получатель недоступен во время отправки сообщения, очередь хранит сообщение до тех пор, пока оно не будет доставлено.
Следовательно, можно сделать вывод о том, что для взаимодействия элементов подобной системы необходимы специальные прикладные протоколы. Для определения этих протоколов разобьем сеть на составляющие и опишем каждый участок в отдельности. Таким образом, классифицируем протоколы по области применения – для обеспечения связей между сенсорными узлами/датчиками, брокерами либо серверами/приложениями пользователя. Такая классификация позволяет абстрагироваться от конкретного решения по применению протокола и сфокусироваться на его целевом назначении.
Обозначим отрезок сети между сенсорными узлами как участок 1. На данном участке выполняется ряд задач, например распределение информации между сенсорными узлами для временного хранения или перенаправления. Для обеспечения связи между сенсорными узлами/датчиками используется протокол DDS (Data Distribution Service). Проиллюстрируем его применение на отрезке сети (см. рис. 2).
Протокол DDS распределяет данные между устройствами [28]. DDS реализует прямую шинную связь между устройствами на базе реляционной модели данных. Протокол DDS реализует многоадресную систему, используя UDP. Данный протокол ориентирован на шаблон "издатель-подписчик", при этом передача сообщений производится по шине с использованием метода "запрос-ответ". Операции, выполняемые протоколом, задаются тринадцатью классами (Entity Class, WaitSet Class, Condition Class, Publisher Class, DataWriter Class, Subscriber Class, DataReader Class, ReadCondition Class, QueryCondition Class и другими). Протокол DDS реализует две операции – чтения и записи, используя соответствующие классы. Операция записи является достаточно примитивной, поэтому остановим внимание на операции чтения.
Операция чтения (Read) осуществляется на всех доступных устройствах. Данные не удаляются из локального кеша DDS в результате этой операции и могут быть прочтены снова при указании специальных параметров. Получение данных осуществляется тремя следующими способами [28].
Подводя итог обзора протокола DDS, необходимо отметить его назначение – для связи сенсорных узлов/датчиков, объединение их прямой шинной связью и обеспечение многоадресной системы. В общем случае DDS применяется в автоматизированных системах управления движением, а также в энергетике, военной и финансовой сфере.
На этом участке реализуется несколько задач, например такие как регистрация сенсорного узла; конфигурация и настройки узлов; передача и распределение информации и т.д. На этом сегменте сети могут использоваться два следующих протокола.
В относительно небольших персональных сетях используется протокол XMPP.
XMPP (Extensible Messaging and Presence Protocol) – расширяемый протокол обмена сообщениями и информацией о присутствии [29]. Применительно к Интернету вещей XMPP обеспечивает простой способ адресации устройств. Для идентификации пользователей используются запоминающиеся идентификаторы JID, по формату похожие на адреса электронной почты (например, username@jabber.ru). В протоколе XMPP применяется текстовый формат XML. В качестве транспорта используется протокол TCP. XMPP поддерживает различные коммуникационные модели (запрос-ответ, публикация-подписка и другие).
Адресация XMPP особенно удобна в случаях, когда данные передаются между отдаленными, чаще всего независимыми точками, например в случае взаимодействия двух абонентов. С помощью XMPP, например, возможно подключение домашнего термостата к Web-серверу для получения к нему доступа с телефона. Сильными сторонами этого протокола являются также безопасность и масштабируемость, что делает его идеальным для приложений Интернета вещей с ориентацией на потребителя.
Для сетей с ограниченными ресурсами, низким энергопотреблением больше подойдет протокол COAP.
COAP (Constrained Application Protocol) – это специализированный протокол передачи, разработанный рабочей группой IETF – CORE, созданный для сетей и устройств с ограниченными ресурсами, M2M-приложений и т.д. [30]. COAP можно рассматривать как дополнение к HTTP, но в отличие от HTTP COAP нацелен на использование в устройствах с определенными ограничениями. COAP использует транспортный протокол UDP.
Сообщений, используемых протоколом COAP, не так много, некоторые подразумевают запросы-ответы: GET, PUT, HEAD, POST, DELETE, CONNECT. Клиенты (приложения пользователя) используют сообщения для управления и наблюдения за ресурсом. По запросу устанавливается флаг наблюдения, и сервер продолжает отвечать после того, как первоначальное сообщение было передано. Это позволяет серверам организовывать потоковую передачу изменений состояний датчиков.
Таким образом, на участке сети между сенсорным узлом и брокером для обеспечения их связи, с целью регистрации и конфигурации узлов, а также для передачи информации чаще всего применяются два протокола – XMPP и COAP. Выбор конкретного протокола зависит от условий реализуемой сети. Можно отметить, что XMPP нашел свое применение в системах освещения и климата, а также используется для адресации устройств в небольших персональных сетях. Очевидно, что COAP предназначен для устройств с ограниченными ресурсами и для сетей с низким энергопотреблением. Известно применение протокола в системах датчиков температуры и других датчиков умного дома.
Приведем для наглядности данный сегмент сети с обозначенными на нем протоколами (см. рис. 3).
Следующим рассматриваемым отрезком топологии является участок сети, где ключевым элементом является брокер (см. рис. 4). Учитывая описанное ранее назначение брокера в сети Интернета вещей, можно выделить задачи, которые должны решаться на данном участке: сбор и агрегация данных; организация очередей сообщений; распределение и хранение информации "до востребования".
Для загруженных сетей с большим количеством устройств рациональнее применять протокол, снижающий нагрузку на канал за счет организации очередей, – протокол MQTT.
Протокол MQTT (Message Queue Telemetry Transport) – как следует из названия, предназначен для телеметрии и дистанционного мониторинга. Используется для обмена сообщения между устройствами по принципу "издатель-подписчик", позволяет устройствам посылать и получать данные при возникновении некоторого события. MQTT – бинарный протокол обмена сообщениями, подразумевающий публикацию/подписку, работающий с использованием транспорта TCP [31]. Упрощенная схема, иллюстрирующая обмен сообщениями MQTT, представлена на рис. 5 [14]. Протокол использует четырнадцать сообщений, предполагающих запрос-ответ: CONNECT, CONNACK, PUBLISH, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK, PIN-GREQ, PINGRESP, DISCONNECT. Согласно спецификации [31] с помощью перечисленных сообщений возможно контролировать такой параметр, как QoS, – в данном случае под этим подразумевается контроль отправки сообщений с помощью трех классов QoS.
Для сетей, использующих оборудование различных платформ и допускающих применение простого протокола передачи сообщений, можно использовать STOMP.
STOMP – Simple (или Streaming) Text Oriented Message Protocol – простой протокол обмена сообщениями, предполагающий широкое взаимодействие со многими языками, платформами и брокерами [32]. Данный протокол подходит под шаблон "издатель-подписчик" и с помощью сообщений SEND, SUBSCRIBE, UNSUBSCRIBE, BEGIN, COMMIT, ABORT, ACK, NACK, DISCONNECT организует связь с брокером по методу "запрос-ответ".
Протокол в целом похож на HTTP, использует транспорт TCP, является простым текстовым протоколом, что позволяет клиентам STOMP общаться с любым брокером сообщений, поддерживающим данный протокол. Таким образом, это способ взаимодействия, разработанный для обмена сообщениями между платформой, описываемой на одном языке программирования, и клиентом, программное обеспечение которого разработано на другом языке. Поддерживает большое количество совместимых клиентских библиотек, связанных языков.
Обобщая данный раздел, отметим, что для обеспечения работы брокера в сети Интернета вещей возможно использование обоих протоколов: MQTT и STOMP. Необходимо только уточнить, что протокол MQTT обеспечивает "сквозную" связь, как от брокера к сенсорным узлам, так и от брокера к серверу, тогда как протокол STOMP ориентирован только на взаимодействие брокера с сервером.
Заключительным участком топологии, представленной на рис. 1, является сегмент, ориентированный на взаимодействие сервера с приложением пользователя (см. рис. 6).
На данном участке выполняются задачи, связанные с взаимодействием пользователя и системы: получение информации с сервера (возможно, с участием сервера-посредника, поскольку информация может быть распределена); конфигурация пользователем параметров (частоты получения информации, активация/дезактивация датчиков и узлов и т.д.) и другие.
Для распределенной вычислительной среды, для Web-сервисов наиболее часто используемым является протокол SOAP, так как у этого протокола выделен механизм доступа RPC (Remote Procedure Call), который отвечает за удаленный вызов функций.
SOAP (Simple Object Access Protocol) – протокол обмена структурированными и произвольными сообщениями формата XML в распределенной вычислительной среде [33]. SOAP использует базовую модель соединения, обеспечивающую согласованную передачу сообщения от отправителя к получателю, потенциально допускающую наличие посредников, которые могут обрабатывать часть сообщения или добавлять к нему дополнительные элементы. Применим в архитектурах, где нужны более сложные взаимоотношения, чем: "создать", "прочитать", "изменить", "удалить".
SOAP поддерживает два механизма доступа – SOAP RPC и SOAP Message [33].
SOAP RPC представляет собой простой протокол "запрос-ответ", который основывается на объекте Call. Этот объект (и некоторые низкоуровневые методы для создания и отсылки сообщений) используется для синхронного удаленного вызова процедур с помощью XML.
SOAP Message – это протокол для отсылки и обработки SOAP-сообщений, который может использоваться для асинхронных коммуникаций и подразумевает немедленный или отложенный ответ на запрос. Протокол SOAP Message основан на объекте Message.
Благодаря всего нескольким сообщениям (Get; SOAPAction, SOAPAction-Response), подразумевающим запрос-ответ, протокол может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS.
Подводя итог, можно сказать, что протокол SOAP предназначен для использования в распределенной вычислительной среде, поддерживает обслуживание Web-сервисов и обеспечивает совместную работу платформы и интернет-приложений. С его помощью обеспечивается связь приложения пользователя с другими элементами сети Интернета вещей для получения информации, управления элементами сети и т.д.
Результаты аналитического обзора представленных в статье протоколов сведены в табл. 1 и 2. Табл. 1 классифицирует представленные протоколы по их назначению, а табл. 2 – по реализуемым операциям [28–33].
На основании проведенного анализа можно сделать следующие выводы:
На данный момент нет возможности сделать какие-либо выводы или оценить требования каждого из протоколов к физическому уровню системы реализации, к сожалению, в спецификациях не отражаются подобные аспекты. Можно предположить, что это связано с многообразием возможных топологий сетей Интернета вещей, отсутствием рамок реализации и единой стандартизации в целом. Очевидно, при внедрении Интернета вещей такая информация была бы полезна.
Интернет вещей – перспективная концепция, получившая уже сегодня активное распространение [22], но это концепция, о которой нет единого представления, отсюда и возникает череда барьеров на пути его развития [34].
Интернет вещей и M2M-приложения предполагают большое количество вовлеченных устройств, что накладывает ограничения, к которым не готовы традиционные протоколы связи.
Приведенные описания протоколов наглядно иллюстрируют заметные различия между ними. Представленный пример классификаций по ключевому параметру – направленности – является первичным. Учитывая, что существуют и перекрывающиеся области применения протоколов, возможно использование различных подходов к сравнительному анализу протоколов.
Ключевые особенности протоколов зависят от их предполагаемого применения. Основные задачи протоколов различны, различны архитектуры и возможности. Поэтому к выбору оптимального протокола для своего приложения нужно подходить основательно, объективно взвешивать все положительные и отрицательные свойства каждого из них, исходя из конкретных потребностей.
Литература
Опубликовано: Журнал "Технологии и средства связи" #4, 2016
Посещений: 26939
Автор
| |||
Автор
| |||
В рубрику "Обзоры, прогнозы, мнения" | К списку рубрик | К списку авторов | К списку публикаций
