Введение
При передаче коротких пакетов измерений от IoT-устройств по IP-сетям служебные данные могут на порядок превышать объем полезных данных, что приводит к существенной загрузке канала Ethernet даже при небольшой суммарной скорости передачи данных с устройств. Конечно, если планируется использовать небольшое количество датчиков, то дополнительной загрузкой сети можно пренебречь. Развитие сиcтем IoT (Internet of Things) и других похожих приложений имеет тенденцию на использование все более разнообразных устройств и, как следствие, увеличение их количества на одном объекте. Передача измерений от сотен датчиков может существенно повлиять на производительность сети, если при проектировании не учесть особенности передачи данных по сетям.
Ниже под катом рассмотрим физические причины этого явления, приведем подходы к расчету соотношения объема передаваемых данных к служебным и покажем, как использование концентраторов измерений от группы датчиков позволяет значительно разгрузить канал передачи данных Ethernet.
Немного теории (передача по высокоскоростным сетям Ethernet)
Физика процесса
В сетях Ethernet используется метод множественного доступа с контролем несущей и обнаружения столкновений CSMA/CD (Carrier Sence Multi Access/Collision Detecting), характерный для сетей шинной топологии. Большую часть времени сетевые устройства, подключенные к сети, находятся в режиме прослушивания канала. Если канал свободен, то постоянная составляющая («несущая») в нем отсутствует. В этом состоянии канала любое сетевое устройство, подготовившее кадр для передачи, может начать его передачу. Переданный кадр поступает на приемники остальных устройств, подключенных к сети. Сетевое устройство, опознавшее свой адрес, копирует этот кадр в свой приемный буфер. После завершения успешной передачи кадра все сетевые устройства, подключенные к шине, включая устройство-отправитель, должны выдержать технологическую паузу, равную времени передачи 96 бит (12 байт) данных.
Эта пауза называется межпакетной паузой IPG (Inter Packet Gap). Если же во время передачи кадра возникла конфликтная ситуация, то передача должна быть немедленно прекращена. Коллизия происходит в том случае, когда информация о том, что рабочая станция начала передачу, не достигла других станций
Внутренняя структура фрейма Ethernet указана в стандарте IEEE 802.3. В таблице 1 показан полный пакет Ethernet, содержащий передаваемый кадр с минимальной полезной нагрузкой.
Таблица 1 – Структура пакетов и кадров Ethernet
№ | Поле | Скорость Ethernet | ||
10,100 Мбит/с | 1000 Base X | 1000 Base Т | ||
Размер (байт) | ||||
1 | Преамбула | 7 | 7 | 7 |
2 | Разделитель начального фрейма (SFD) | 1 | 1 | 1 |
3 | Назначение (Dest) MAC | 6 | 6 | 6 |
4 | Исходный (Source) MAC | 6 | 6 | 6 |
5 | Тег 802.1Q (необязательно) | (4) | (4) | (4) |
6 | Тип Ethertype (Ethernet II) или длина (IEEE 802.3) | 2 | 2 | 2 |
7 | Минимальная полезная нагрузка (Payload) | 46 | 46 | 46 |
8 | Последовательность проверки фрейма (FSC) | 4 | 4 | 4 |
9 | Межпакетный разрыв (IPG) | 12 | 12 | 12 |
10 | Расширение до | нет | 416 | 520 |
Минимальный размер полезной нагрузки кадра определяется временем интервала, используемого для обнаружения столкновений в архитектуре локальной сети Ethernet. Полезная нагрузка – это поле переменной длины, минимальный размер которого определяется требованием о передаче минимального информационного кадра (поля 3–8 таблицы 1) размером:
64 байта для Ethernet 10 Mbps (Ethernet), для Fast Ethernet (100 Mbps);
64 байта Gigabit Ethernet (1000 Mbps), но с добавлением защитного интервала (спецификация 802.3z):
до 416 байт для оптических интерфейсов;
до 520 байт для «витой пары».
В литературе часто указывают величину расширения, равную 512 байтам, которую отсчитывают от первого значащего поля пакета (передаваемого на сетевой уровень). Аналогично часто смешивают понятия минимального размера кадра (84 байта), минимального полезного кадра (64 байта) и минимальной полезной нагрузки (46 байт). Взаимосвязь этих понятий отображена на следующем рисунке:
При наличии тега 802.1Q (сетевое оборудование обеспечивает поддержку VLAN) минимальная полезная нагрузка уменьшается еще на 4 байта.
Таким образом на сетевом уровне (стек протоколов IP/TCP) мы получаем для обработки только 46 (42) байта информации, но на их передачу задействуется физическая линия на время, необходимое для передачи 84 (520) байт.
Наиболее неприятная ситуация складывается для сетей 1 Гбит/с, в которых при передаче коротких кадров с периодичностью менее 4 мкс будет тратиться полоса пропускания, на порядок превышающая полезную нагрузку.
Для передачи информации современные информационные сети наиболее часто используют стек протоколов IP/TCP(UDP). Пакеты данного протокола инкапсулируются в поле полезной нагрузки Ethernet.
Стек протоколов IP/TCP(UDP)
Полное описание протокола IP приведено в RFC 791, 1122, 2003 и 6864 (дополняющие обновления).
Классическая структура кадра имеет следующий вид:
Для нашей задачи имеет значение только размер заголовка, составляющий 20 байт.
При необходимости обеспечить гарантированную доставку сообщений по IP-сетям используется протокол TCP, имеющий заголовок (минимум 20 байт) следующего вида:
Полное описание протокола TCP приведено в RFC 793, …, 9293.
Если обеспечение гарантий доставки данных возложено на прикладной уровень, то используется 8-байтный заголовок UDP, имеющий следующий вид:
Полное описание протокола UDP приведено в RFC 768, 4113.
Защита данных
Для защиты передаваемых данных используется инкапсуляция в VPN-туннели. Пакет данных шифруется, и к нему добавляется заголовок, размер которого зависит от используемого протокола. Для наиболее распространенных протоколов величина заголовка составляет:
WireGuard – 16 байт;
OpenVPN – 17–29 байт;
IKEv2/Ipsec – 20 байт.
Протоколы передачи IoT-устройств
IoT-устройства для передачи данных используют несколько видов протоколов:
HTTP;
Web сокеты;
XMPP (RFC2779, RFC3920, RFC3921, RFC3923);
CoAP (RFC7252, …, RFC 9175);
MQTT.
Рассмотрим для примера заголовок протокола CoAP:
Минимальный размер заголовка при передаче данных не менее 5 байт (сопоставимо с минимальной длиной заголовка для Web-сокетов – 6 байт, MQTT – 2 байта).
Расчет потерь пропускной способности
Получаем итоговую картину инкапсуляции протоколов:
В итоге получаем, что для передачи 16-битного числа (2 байта) будет использоваться временной интервал, эквивалентный передаче 86–120 байт, то есть будет затрачено ресурсов канала передачи данных в 60 раз больше! При группировке максимально возможного количества измерений в единый блок (1412 байт) для передачи будет задействован временной интервал, эквивалентный 1538 байтам (для стандартных настроек MTU=1500), то есть всего на 8% больше.
Теперь – голая практика (снижение сетевого трафика)
Минимизация нагрузки на сетевое оборудование при построении приложений для IoT-устройств позволит обеспечить устойчивое функционирование систем, использующих большое количество датчиков, на низкоскоростных сетях передачи данных.
Для оценки численных характеристик при передаче пакета данных с измерениями устройств IoT (PDII) приведем зависимость потерь пропускной способности канала от размера PDII, рассчитанную, исходя из рисунка 6 и приведенных ранее данных.
Таблица 2 – Эффективность использования пропускной способности канала
Размер PDII, байт | Интервал занятости для канала, байт | Полезная нагрузки на интервале передачи пакета данных, % | ||||||
10, 100 Мбит/с | 1 Гбит/с | 10, 100 Мбит/с | 1 Гбит/с | |||||
min | max | min | max | min | max | min | max | |
2 | 86 | 120 | 416 | 520 | 2,3 | 1,7 | 0,5 | 0,4 |
20 | 104 | 138 | 416 | 520 | 19,2 | 14,5 | 4,8 | 3,8 |
40 | 124 | 158 | 416 | 520 | 32,3 | 25,3 | 9,6 | 7,7 |
80 | 164 | 198 | 416 | 520 | 48,8 | 40,4 | 19,2 | 15,4 |
160 | 244 | 278 | 416 | 520 | 65,6 | 57,6 | 38,5 | 30,8 |
320 | 404 | 438 | 438 | 520 | 79,2 | 73,1 | 73,1 | 61,5 |
332 | 416 | 450 | 450 | 520 | 79,8 | 73,8 | 73,8 | 63,8 |
436 | 520 | 554 | 520 | 554 | 83,8 | 78,7 | 83,8 | 78,7 |
Внимательно посмотрев на таблицу 2, сделаем некоторые выводы:
Увеличение размера полезной информации, передаваемой от устройства IoT, нелинейно влияет на загрузку канала Ethernet.
Имеет практический смысл увеличивать размер полезного пакета данных до 80–100 байт, при использовании каналов с пропускной способностью 10 или 100 Мбит/с.
Пакеты данных с полезной нагрузкой до 320–332 байт (зависит от стека используемых протоколов) при передаче по сети Gigabit Ethernet обеспечивают одинаковое потребление полосы пропускания.
Возникает вопрос о практическом применении приведенной выше информации – ведь размер поля данных от конкретного датчика всегда фиксирован? Ответ представляется таким – следует группировать измерения от нескольких датчиков и передавать их в одном пакете данных. Таким образом мы сразу можем уменьшить загрузку сети передачи данных и снизить требования к производительности центрального сервера, осуществляющего обработку данных от датчиков.
Последнее преимущество особенно заметно, если применяется защита данных с использованием криптографических протоколов.
При группировании измерений итоговый размер блока объединяемых данных желательно выбирать в пределах 80÷1412 байт (превышение верхней границы приведет к передаче измерений в нескольких пакетах).
Выполнение предварительной обработки данных в микроконтроллере, установленном на физическом объекте (как правило, осуществляется измерение нескольких параметров физического объекта), позволяет реализовать описанный подход. Приведенные в статье справочные таблицы позволяют рассчитать оптимальное количество измерителей, подключаемых к одному микроконтроллеру.
И еще немного о финансах (экономия)
Часто IoT-устройства используют для управления хозяйством в загородном доме или на даче (системы отопления, автополива и т. д). Как правило, в этом случае единственный способ подключиться к IP-сети – это связь через сотовый модем или телефон.
Принципы инкапсуляции протоколов аналогичны сетям Ethernet, начиная со стека IP/TCP/UDP, но экономика подключения сильно зависит от тарифного плана и принципов организации сессий подключений. Количество денег, расходуемых на оплату трафика, зависит как от его объема, так и от принципов тарификации, используемых операторами связи. При построении системы сбора данных, использующих сотовые системы связи, на первый план выходят подходы к организации сессий обмена данными.
При выборе тарифного плана и оператора для подключения контроллера IoT необходимо внимательно почитать сноски к тарифным планам оператора.
Существуют следующие особенности тарификации:
Осуществляется тарификация сессий подключения, причем объем данных, переданных за время подключения, округляется до величины, определенной данным тарифным планом (анализ договоров операторов большой четверки показал, что величина может составлять от 1 до 500 Кбайт).
Для активных длинных сессий округление может проводиться ежечасно.
Таким образом, при передаче данных через сотовую IP-сеть необходимо согласовывать алгоритм построения сессий с особенностями тарификации провайдера. При развертывании сети сбора данных необходимо в настройках учесть:
необходимость организации длинных сеансов обмена данными IoT-устройств с сервером управления;
особенности округления, используемые при калькуляции стоимости передачи данных в выбранном тарифном плане.
Заключение
Надеемся, что подсвеченные особенности передачи данных от IoT-устройств через сети Ethernet или мобильные сети помогут улучшить важные потребительские свойства разрабатываемых систем IoT.
