Контакты
Подписка
МЕНЮ
Контакты
Подписка

В рубрику "Обзоры, прогнозы, мнения" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Аналитический обзор протоколов Интернета вещейAnalytical review of the Internet of Things protocols

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

This article discusses the protocols of the Internet of things, overview protocols peculiar properties, possible applications, further it is classified. Contains an analysis and justify the protocol choice depends on the specifics of the planned Internet of things network. Actuality of the subject is due to the variety of existing protocols, Internet of Things standards and the lack of established terminology, describes the concept as a whole.

Вадим
Гойхман
К.т.н., доцент кафедры инфокоммуникационных систем, СПбГУТ им. проф. М.А. Бонч-Бруевича
Vadim
GoikhmanPh.D, senior lecturer, Bonch-Bruevich Saint-Petersburg State University of Telecommunications
Анастасия
Савельева
Бакалавр кафедры инфокоммуникационных систем СПбГУТ им. проф. М.А. Бонч-Бруевича
Anastasiia
SavelevaBachelor Bonch-Bruevich Saint-Petersburg State University of Telecommunications
Ключевые слова:
Интернет вещей, IoT, протоколы IoT, M2M, XMPP, SOAP, COAP, STOMP, MQTT, DDS
Keywords:
Internet of Things, IoT, IoT protocols, M2M, XMPP, SOAP, COAP, STOMP, MQTT, DDS

Введение

Стремительное развитие Интернета вещей [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. Сенсорный узел – сенсорный узел

Обозначим отрезок сети между сенсорными узлами как участок 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].

  • Опрос (Polling) – приложение (обычно периодически) запрашивает DDS для получения новых данных или информирования о смене состояния. Интервал опроса зависит от приложения и от данных.
  • Списки ожидания (WaitSets) – приложение регистрирует в DDS списки ожидания и ждет, пока одно из переданных событий не произойдет.
  • Слушатели (Listeners) – приложение регистрирует в DDS (в классах, где события описаны) специальные классы-слушатели, которые будут информированы при наступлении этих событий.

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

Участок 2. Сенсорный узел-брокер

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

В относительно небольших персональных сетях используется протокол 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).

Участок 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 ориентирован только на взаимодействие брокера с сервером.

Участок 4. Сервер-приложение

Заключительным участком топологии, представленной на рис. 1, является сегмент, ориентированный на взаимодействие сервера с приложением пользователя (см. рис. 6).


На данном участке выполняются задачи, связанные с взаимодействием пользователя и системы: получение информации с сервера (возможно, с участием сервера-посредника, поскольку информация может быть распределена); конфигурация пользователем параметров (частоты получения информации, активация/дезактивация датчиков и узлов и т.д.) и другие.

Протокол MQTT (Message Queue Telemetry Transport) – как следует из названия, предназначен для телеметрии и дистанционного мониторинга. Используется для обмена сообщения между устройствами по принципу "издатель-подписчик", позволяет устройствам посылать и получать данные при возникновении некоторого события. MQTT – бинарный протокол обмена сообщениями, подразумевающий публикацию/подписку, работающий с использованием транспорта TCP [31].

Для распределенной вычислительной среды, для 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].




На основании проведенного анализа можно сделать следующие выводы:

  • большинство рассмотренных протоколов используют транспорт TCP, что обеспечивает необходимый уровень надежности;
  • протокол DDS обеспечивает контроль "жизнеспособности" элементов сети, обнаружение и использование ресурсов, а также синхронизацию;
  • протокол MQTT поддерживает качество обслуживания, обеспечивает проверку доставки сообщений;
  • протокол XMPP поддерживает поиск имен в огромной базе данных Интернета вещей, но его способ адресации подходит больше для небольших сетей.

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

Заключение

Интернет вещей – перспективная концепция, получившая уже сегодня активное распространение [22], но это концепция, о которой нет единого представления, отсюда и возникает череда барьеров на пути его развития [34].

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

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

Протокол SOAP предназначен для использования в распределенной вычислительной среде, поддерживает обслуживание Web-сервисов и обеспечивает совместную работу платформы и интернет-приложений. С его помощью обеспечивается связь приложения пользователя с другими элементами сети Интернета вещей для получения информации, управления элементами сети и т.д.

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

Литература

  1. Newsroom: Gartner Says 6.4 Billion Connected "Things" Will Be in Use in 2016, Up 30 Percent From 2015. Gartner, Inc. [online]. Доступ через: http://www.gartner.com/newsroom/id/3165317.
  2. Прогнозы развития. TAdviser. Аналитика. 2016. [online]. Доступ через: http://www.tadviser.ru/index.php/Статья:Интернет_вещей,_IoT,_M2M_(мировой_рынок) .
  3. ITU-T: Recommendations: Y Series: Y.2060/ International Telecommunication Union-Telecommunications /Overview of the Internet of things. 2012.
  4. IEEE Standards Association. Internet of Things related standards. 2016. [online]. Доступ через: http://standards.ieee.org/innovate/iot/stds.html.
  5. IEEE Standards Association // IEEE Standards Activities in the Smart Grid Space (ICT Focus). 2015. [online]. Доступ через: http://standards.ieee.org/develop/msp/smartgrid.pdf.
  6. ETSI Recommendation: TR 103 290 V1.1.1 / Machine-to-Machine communications (M2M) / European Telecommunications Standards Institute. 2015.
  7. OASIS Standard: TOSCA Version 1.0 / Topology and Orchestration Specification for Cloud Applications TC. 2013.
  8. oneM2M // Standards for M2M and the Internet of Things. Published Specifications. 2016. [online]. Доступ через: http://www.onem2m.org/technical/published-docu-ments.
  9. Rahim Tafazolli / IERC IoT International Forum // European Research Cluster on the Internet of Things. Результаты форума и перспективы. 2012.
  10. ISO / Identification cards – Contactless integrated cir-cuit(s) cards – Vicinity cards14443 // International Organization for Standardization ISO/IEC. 2003.
  11. IoT-A // Documents. 2016. [online]. Доступ через: http://www.iot-a.eu/public/public-documents/documents-1.
  12. SK-ИТ Фонд "Сколково" // Миссия Ассоциации IoT/RU. 2016. [online]. Доступ через: http://sk.ru/founda-tion/itc/iot/.
  13. PC Week/RE. Компьютерная неделя // "МегаФон" и Huawei будут внедрять в России Интернет вещей стандарта NB-IoT. 2016. [online]. Доступ через: h ttp://w ww.pc week.ru/iot/news-company / detail.php?ID=186797.
  14. А.В. Росляков.Интернет вещей / А.В. Росляков, С.В. Ваняшин, А.Ю. Гребешков. – Самара: ПГУТИ, 2015. С. 107–109.
  15. Б.С. Гольдштейн. Сети связи пост-NGN / Б.С. Гольдштейн, А.Е. Кучерявый. – СПб.: БХВПетербург, 2014. С. 160.
  16. Ю.В. Воеводин. Обзор уникальных программно-аппаратных параметров различных технологий Интернета вещей // Информационные технологии и телекоммуникации. – СпбГУТ. – 2015. – № 4.
  17. Dr. Ovidiu Vermesan. Internet of Things – From Research and Innovation to Market Deployment / Dr. Ovidiu Vermesan, Dr. Peter Friess// River Publishers., 2014. С. 106– 112.
  18. Stan Schneider / Understanding The Protocols Behind The Internet Of Things / Stan Schneider // Electronic Design. 2013.
  19. Juhani Latvakoski / A Survey on M2M Service Networks / Juhani Latvakoski, Antti Iivari, Paul Vitic // Computers // № 3, 2014. Р. 130–173.
  20. В.О. Тихвинский. Монетизация сетей LTE на основе услуг M2M// Электросвязь.– 2014. –№ 6.
  21. А. Футахи. Сенсорные сети в гетерогенной зоне системы длительной эволюции / А. Футахи, А.И. Парамонов, А.В. Прокопьев, А.Е.Кучерявый // Электросвязь. – 2015. –№ 3..
  22. М.Кольцов. IT- и телеком-отрасль: итоги 2014 года // Технологии и средства связи. – 2014. – № 6.
  23. П. Зернов. Интернет вещей (IoT): задача идентификации и верификации речи на встраиваемых устройствах // Технологии и средства связи, – 2016. – № 2.
  24. А. Залогин. Современные IT-решения в сегменте грузового транспорта/ А.Залогин // Технологии и средства связи. – 2016. – № 1.
  25. Beecham Research // M2M/IoT Sector Map. 2011. [online]. Доступ через: http://www.beechamresearch.com/article.aspx?id=4.
  26. Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., & Stal, M./ Pattern Oriented Software Architecture, Volume 1: A System of Patterns./ John Wiley & Sons. 1996. Р. 339–343.
  27. Birman, K. and Joseph, T. Exploiting virtual synchrony in distributed systems/ доклад ACM Symposium on Operating systems principles (SOSP '87). 1987. Р. 123–138.
  28. OMG/ DDS v1.4 – the DDS specification / Object Management Group. 2015.
  29. ITU-T/ Extensible Messaging and Presence Protocol (XMPP): Core // RFC-3920. 2004.
  30. ITU-T/ The Constrained Application Protocol (CoAP) / RFC 7252 – Proposed Standard. 2014.
  31. IBM/ MQTT V3.1 Protocol Specification // International Business Machines Corporation Eurotech. 2015.
  32. STOMP Protocol Specification, Version 1.2 // licensed under the Creative Commons Attribution v2.5 license. 2012.
  33. W3C/ Simple Object Access Protocol (SOAP) 1.1 / World Wide Web Consortium / Don Box, David Ehnebuske, Gopal Kakivaya. 2000.
  34. Н. Соколов. Сценарии реализации концепции "Интернет вещей" // Первая миля. – 2016. – № 4.

Опубликовано: Журнал "Технологии и средства связи" #4, 2016
Посещений: 22961

  Автор

Вадим Гойхман

Вадим Гойхман

К.т.н., доцент кафедры инфокоммуникационных систем, СПбГУТ им. проф. М.А. Бонч-Бруевича

Всего статей:  3

  Автор

Анастасия Савельева

Анастасия Савельева

Бакалавр кафедры инфокоммуникационных систем СПбГУТ им. проф. М.А. Бонч-Бруевича

Всего статей:  1

В рубрику "Обзоры, прогнозы, мнения" | К списку рубрик  |  К списку авторов  |  К списку публикаций