Как вы догадались из названия, речь пойдёт о подключении камер видеонаблюдения по сети WiFi.
В общем, решили мы выпустить камеру без LAN’а (без разъёма RJ-45) с возможностью подключения только по WiFi. На стадии тестирования образцов и сравнения их с конкурентами, мы заметили что на одном роутере адекватно работает только 2-3 камеры. А у нас их было 6 или 7 для сравнения. И это было немного удивительно, ведь битрейт у камер был в районе 6000 кбит\с и по идее одного роутера должно быть достаточно что бы подключить все камеры.
На тот момент мы использовали, если мне не изменяет память, роутер TP-Link Archer А5. На веб интерфейсе роутера мы увидели что загрузка ЦП уходит в 100% и начали грешить на то что у нас слабый роутер, не вывозит видеопоток с IP камер.
Тогда мы взяли точку доступа UniFi AP AC PRO, потому что на её контроллере есть обширный функционал по анализу состояния сети. С учётом всех помех в офисе, на частоте 2.4Ггц мы получили канал шириной 40 Мб\с и провели следующий тест:
Методика тестирования:
1) Мы замеряем нагрузку на точке доступа без камер.
2) Затем подключаем одну камеру , фиксируем как изменяется нагрузка на точку , записываем данные в таблицу.
3)Потом подключаем 2 камеру и фиксируем нагрузку на точку при подключении двух камер
И т.д.
Условия тестирования:
Камеры подключены к серверу видеонаблюдения на дефолтных настройках,( для 2Mp камер это : переменный битрейт 4096, GOP 20, FPS 25, качество кодирования — лучшее) включен звук, пишет по детектору, около 30% кадра занимает включённый маятник.
Ведём с результатами тестирования.
В таблице мы фиксируем загрузку ЦП, памяти и трафик ( потребляемый от общей ширины канала в 40Мб\с.). Так же фиксируем качество потока при Live — просмотре на сервере в основном потоке.
Результат:
Исходя из данных в таблице мы видим что подключая первые 4 камеры , нагрузка на процессор растёт на 3-5% за каждую камеру. Память камеры вообще практически не используют. 6 камер на 1% загрузили память.
Но при подключении 5 и 6ой камеры рост нагрузки на процессор останавливается и начинаются проблемы с потоком и растут дропы пакетов по вай фаю.
При этом используется только половина ширины канала — 21.5Мб\с.. В этот же момент замеряем пропускную способность канала через iperf и видим что есть ещё 20Мб\с. свободной ширины канала.
Из этого следует что все наши предположения о том что нам не хватает мощности роутера, пропускной способности, хороших условий для Wifi без помех , оказались в корне не верны.
Мы думали что у нас плохие условия, много помех. слабое оборудование и тд. и пытались исправить эти проблемы.
По факту проблема абсолютно другая и кроется в самих принципах работы WIFi сетей.
Проблема в том что на WiFi сеть, (как на среду передачи данных), перекладывается обязанность устранения коллизий. Вдобавок к этому, WiFi единовременно может работать только с одним клиентом, остальные ждут и находятся в очереди.
При подключению по кабелю, свитч сам работает над устранением коллизий и приотирезации трафика, а благодаря кабелю он может единовременно общаться со всеми подключенными клиентами.
При подключению по WIFI Устройство должно само анализировать среду передачи данных на наличие помех, прослушивать канал на наличие других устройств передающих трафик, дождаться конца передачи (освобождения канала) и только при этих условиях начинать передачу. Для этого используются дополнительные инструменты и протоколы которые и вызывают задержки трафика и следовательно проблемы с потоком.
Чем больше устройств подключено по WiFi на одной точке, тем больше очередь ожидания благоприятной среды для передачи данных и при количестве 4-6 камер эта очередь становится критической.
Я предполагаю что на количество камер, для создание критической очереди, может влиять битрейт и количество движения в кадре и в принципе работа детектора движения, но это нужно исследовать отдельно, если вообще нужно, потому что корень проблемы не в этом.
В данной статье,(https://www.proxim.com/technology/worp) некий производитель Proxim описывает свой протокол WORP, который оптимизирует служебные протоколы в среде передачи данных WiFi и даёт возможность подключить бОльшее количество WiFi камер к своей точке доступа (которые они производят) которая использует ,вышеуказанный протокол WORP.
В этой статье ссылаются на непригодность протокола 802.11 MAC используемого в текущих WiFi сетях стандарта 802.11 для создания точки доступа с множеством подключенных устройств с аудио и видео трафиком из за создания заторов на канале, в следствии согласования приоритетов передачи трафика между устройствами.
Протокол 802.11 MAC(https://ru.wikipedia.org/wiki/IEEE_802.11e) использует протокол DCF (https://ru.wikipedia.org/wiki/Distributed_coordination_funct…), чтобы разделить эфир между множеством станций.
А протокол DCF в свою очередь базируется на протоколе CSMA/CA (https://ru.wikipedia.org/wiki/CSMA/CA) который как раз и производит прослушивание канала, согласование передачи трафика с другими WiFi устройствами и этим самым должен предотвращать появление колизий.
При подключении нескольких WiFi устройств к одной точке, они начинают выстраивать между собой очередь передачи трафика и ,в случае с камерами, при подключении 6ой камеры у нас переполняется очередь до «критических» значений задержек и появляются дикие лаги на видео.
Если камеры разнести друг от друга, чтобы они не могли согласовывать между собой приоритеты подачи трафика, то они все начинают слать трафик одновременно что приводит к образованию коллизий и следовательно потеря пакетов приводит к ухудшению видеопотока.
Вывод: В силу особенностей работы беспроводных сетей стандарта 802.11, на одном роутере адекватно будут работать только 3-5 2Mp камер со средними настройками.
Что касается 5Ггц — в видеонаблюдении они бесполезны. Полосы пропускания в 2.4Ггц достаточно для камеры, а дальнобойность и пробивная способность препятствий у 5Ггц намного меньше.