Использование протокола IP в локальных сетях

Рассмотрим реализацию обеих способов на примере Интернета вещей, основанном на протоколе MQTT, состоящего из локальных сенсорных сетей под управлением протокола ZigBee.

Современные интернет-вещи имеют программное обеспечение, управляющее двумя средствами связи – локальным беспроводным каналом и каналом для связи с глобальной сетью.

 

Рисунок 6. Функциональная диаграмма приложения для интернет-вещи

 

На рисунке 6 показана схема приложения для интернет-вещи, содержащей в себе модуль ZigBee (для локальных соединений с ближайшими вещами) и модуль GPRS (для связи с удалённым сервером). В данной ситуации при разработке такого приложения обращение к вещам, находящимся в локальной сети будет производиться по их внутренним адресам в формате протокола ZigBee, в то время как обращение к внешним вещам, находящимся территориально удалённо, будет производиться по протоколу MQTT. Такой подход усложняет разработку приложений с поддержкой концепции Fog Computing.

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

 

Рисунок 7. Приложение с межсетевым интерфейсом

 

Проблема совместимости сетевых протоколов в Интернете вещей в настоящий момент решается вполне успешно. Существует множество решений по разработке программных интерфейсов для объединения различных протоколов сенсорных сетей (в т.ч. ZigBee) с другими сетевыми протоколами. Наиболее удачное решение продемонстрировала компания Jennic, разрабатывающая беспроводные микроконтроллеры, использующие стандарт 802.15.4, а также программное обеспечение и операционную систему для них (JenNet и JenOS).

Компания Jennic использует протокол IPна сетевом уровне, поверх 802.15.4. Это позволяет обращаться к узлам сенсорной сети, используя IP-адрес и TCP-порт.

При использовании протокола IP, разработчик сможет использовать один из узлов локальной сети в качестве брокера MQTT, отвязав часть интернет-вещей от Интернета.

Также, модифицировав прикладной уровень клиентской части протокола MQTT, станет возможным реализовать прозрачный обмен данными между локальными узлами по протоколу MQTT.

Брокер локальной сети

Беспроводные сенсорные сети имеют архитектуру, поддерживающую любой вид топологии (звезда, дерево, ячеистая) и предусматривающую наличие координатора – узла сети, организующего сеть и играющего роль в некоторой степени напоминающую брокера в сети MQTT.Однако, связь с ближайшим узлом сенсорной сети возможна и без помощи брокера – напрямую. Координатор играет роль брокера в случае невозможности установить связь с узлом в силу его удалённости. Более простыми “брокерами” сенсорных сетей являются маршрутизаторы, которые также предназначены для ретрансляции сообщений от одного узла к другому. Любое конечное устройство сенсорной сети может быть настроено на предоставление услуги маршрутизации.

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

- использовать протокол IP,

- установить программное обеспечение брокера MQTT на маршрутизаторы и координатор локальной сети,

- установить клиентское ПО MQTT на конечные узлы сети,

- использовать таблицу брокеров.

 

 

Рисунок 8. Сеть интернет-вещей с локальными брокерами

 

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

 

К недостаткам такого метода можно отнести:

- необходимость подключения вещи к нескольким брокерам (локальному и глобальному),

- наличие дополнительного устройства для развёртывания на нём брокера,

- отсутствие локальной сети в случае недоступности брокера,

- связь двух узлов только посредством третьего узла – брокера (отсутствие ячеистой топологии).

Необходимость подключения сразу к двум брокерам приведёт к тому, что одни и те же данные придётся публиковать дважды. Выходы из этой ситуации следующие:

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

 

 

Рисунок 9. Связь узлов и брокеров с ретрансляцией

 

- модификация клиентского ПО MQTT с целью добавления режима multicast. Данный режим должен предусматривать возможность публикации сообщений сразу на все доступные брокеры и возможность обрабатывать адресованные узлу сообщения от разных брокеров одной функцией. Поскольку уникальность идентификаторов устройств в глобальной сети должна распространяться и на локальные сети, то проблем с повторной доставкой сообщений быть не должно. Сообщение будет обработано только тем узлом, которому оно адресовано. К тому же режим multicast поддерживается практически любыми стандартами беспроводной связи.

 

 

Рисунок 10. Связь узлов и брокеров в режиме multicast

 

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

В случае недоступности брокера или выхода его из строя, сенсорная сеть самовосстановится, однако сеть вещей распадётся, если не будет запасного брокера. Такая проблема решается внедрением брокеров на доступные маршрутизаторы сети, или на все узлы сети. Во время выхода из строя основного локального брокера, один из узлов, по возможности, трансформируется в брокер, загрузив сохранённую в нём программу сервера-брокера. Некоторые беспроводные сенсорные сети имеют подобный механизм восстановления – когда вышедший из строя координатор может быть заменён одним из маршрутизаторов сети.

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

К достоинствам метода локального брокера можно отнести:

- полная прозрачность взаимодействия между интернет-вещами,

- автоматическая маршрутизация,

- минимальные изменения пользовательского приложения.

Псевдо-сервер MQTT

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

Под псевдо-сервером подразумевается часть программного обеспечения узла, эмулирующая сервер MQTT.

При таком подходе необходимо знать сетевой адрес устройства, к которому мы хотим подключиться. При этом, на уровне приложения, известен только идентификатор MQTT необходимой вещи, а сетевой адрес скрыт. В такой ситуации проблема может быть разрешена при помощи координатора сенсорной сети. При инициализации сети должна создаваться таблица идентификаторов устройств с соответствующими сетевыми адресами всех вещей, входящих в локальную сеть и сохраняться на координаторе. Любой узел сети при необходимости сможет запросить её у координатора (доступ к координатору есть у каждого узла сети) и выполнить присоединение к псевдо-серверу.

На момент соединения с псевдо-сервером отправитель будет знать точно, что это именно тот узел, которому адресуется информация. Узел 1 будет публиковать информацию на псевдо-сервер, не имея ни одного подписчика, в то время как узел 2 будет принимать её и передавать в приложение.

Такой способ является простейшей надстройкой над протоколом MQTT. Главной задачей при таком подходе является инкапсуляция реализации псевдо-сервера и осуществление прозрачного обмена между вещами с помощью определённого набора функций. Это решается путём создания некоторой библиотеки для Point-to-Point соединений, содержащей в себе эмуляцию сервера MQTT и соединения клиента с ним.

Для организации прозрачной связи между территориально-удалёнными вещами при таком подходе необходимо сделать обёртку над API общения с сервером MQTT и API соединений Point-to-Point с целью включения алгоритма поиска вещи в локальной сети и автоматической маршрутизации. Поиск вещи в локальной сети будет производиться без особых проблем благодаря таблице устройств, хранимой на координаторе. В случае присутствия вещи в локальной сети, будет использоваться Point-to-Point API. В случае отсутствия вещи, будет произведён запрос к глобальному серверу MQTT.

Недостатки такого подхода включают в себя:

- необходимость использования API для осуществления прозрачных соединений,

- серверный функционал узлов сети, следствием использования которого является увеличение энергопотребления сети,

- необходимость внесения изменений в протокол MQTT, реализацию серверной и клиентской части.

Достоинства метода:

- нет необходимости использовать отдельное устройство для развёртывания брокера,

- взаимодействие может быть осуществлено между любыми двумя близлежащими устройствами без участия посредников,

- более рациональная топология.

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

Выводы

Среди различных методов физической организации Интернета вещей предпочтение отдаётся методу централизованного сервера, поскольку такой метод

- переносит нагрузку обработки запросов пользователей с интернет-вещей на централизованный сервер, тем самым разгружая слабый радио-канал связи интернет-вещей, перенося нагрузку на проводные каналы связи между сервером и пользователями,

- предоставляет надёжные средства хранения и обработки информации,

- позволяет интернет-вещам взаимодействовать друг с другом и пользоваться облачными вычислениями.

Среди недостатков существующих средств организации метода централизованного сервера можно выделить:

- отсутствие общепринятого стандарта организации Интернета вещей и интерфейсов взаимодействия,

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

На практике данный метод используется совместно с протоколом MQTT – наиболее развитое и оптимальное средство в условиях экономии электроэнергии и объёма передаваемых данных. Однако протокол MQTT ещё не окончательно развит и имеет основную проблему - отсутствие возможности создавать соединения “точка-точка” между двумя узлами одной локальной сети. Это означает невозможность использования технологии туманных вычислений. Однако у этой проблемы есть ряд решений.

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

Более надёжным и хорошо применимым к любым существующим системам, основанным на протоколе MQTT, способом является использование локального брокера. Такой метод изменяет лишь структуру сети, добавляя в пользовательское приложение минимум нового функционала. Для использования такого метода в локальных сетях, необходимо:

- использовать протокол IP,

- установить программное обеспечение брокера MQTT на маршрутизаторы и координатор локальной сети,

- установить клиентское ПО MQTT на конечные узлы сети,

- использовать таблицу брокеров для автоматического выбора сервера-брокера.

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

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

 

WEB вещей

Активное развитие Интернета вещей привело к тому, что всё больше пользователей стали использовать Интернет для доступа к всевозможным “умным вещам”. При этом самым удобным способом доступа является всемирная паутина – World Wide WEB, пользование которой осуществляется с помощью веб-браузеров, способных загружать веб-страницы и представлять их в виде графического интерфейса для пользователей.

Рост числа Интернет-вещей, доступных для управления с помощью Интернета и веб-браузера, говорит о появлении некоторой среды в WEB’е, объединённой общей функциональной направленностью – управлением интернет-вещами. Такая среда получила название WEB вещей.

WEB вещей можно рассматривать как прикладной (или пользовательский) уровень Интернета вещей, поскольку является лишь интерфейсом между пользователем и интернет-вещами.

На начальных этапах развития WEB’а вещей имелось некоторое множество устройств, которые использовали протокол HTTP для отправки данных на веб-ресурсы. При этом, находясь в одной среде, все интернет-вещи использовали свой формат представления данных, который мог распознаваться только определённым типом веб-приложений. Таким образом, появилась проблема стандартизации обмена информацией в WEB’е вещей. При решении данной проблемы основной целью является обеспечение возможности интернет-вещам публиковать свои сообщения на любом веб-ресурсе, при том условии, что каждая интернет-вещь также является веб-ресурсом. То есть интернет-вещи должны стать частью всемирной паутины и быть наравне с любыми другими веб-ресурсами.

В рамках решения данной проблемы был использован ряд проектов, разработанных ранее для объединения вещей (в основном домашних бытовых, мобильных устройств и компьютеров) в одну вычислительную сеть, который включает в себя JINI, UPnP, DNLA и прочие. Однако организация поддержки данных технологий в WEB’е вещей довольно проблематична, поскольку требует создания интерфейса между внутрисетевыми протоколами и WEB’ом.

В результате, была выбрана технология REST (Representational State Transfer), описывающая стиль построения архитектуры распределённых приложений.

Стандарт REST был описан и популяризован в 2000 году Роем Филдингом, одним из создателей протокола HTTP. Самой известной системой, построенной в значительной степени с использованием архитектуры REST, является современная Всемирная паутина, поэтому данная архитектура как никакая другая подходит для организации взаимодействия в WEB’е вещей.

Данные в REST должны передаваться в виде небольшого количества стандартных форматов (например HTML, XML, JSON). Сетевой протокол (как и HTTP) должен поддерживать кэширование, не должен зависеть от сетевого слоя, не должен сохранять информацию о состоянии между парами «запрос-ответ». Утверждается, что такой подход обеспечивает масштабируемость системы и позволяет ей эволюционировать с новыми требованиями.

Противоположностью REST является подход, основанный на вызове удаленных процедур (Remote Procedure Call — RPC). Подход RPC позволяет использовать небольшое количество сетевых ресурсов с большим количеством методов и сложным протоколом. При подходе REST количество методов и сложность протокола строго ограничены, из-за чего количество отдельных ресурсов может быть большим.

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

Таким образом, WEB вещей является третьим типом взаимодействия в Интернете вещей – взаимодействием между пользователями и интернет-вещами. Этот тип взаимодействия включает в себя не только WEB, но и другие средства, рассмотренные в следующем разделе.