Как обеспечить низкие задержки в беспроводных сетях распространенных архитектур (4G, 5G, Wi-Fi 5/6/7)
Будучи производителем оборудования, мы хотим затронуть тему обеспечения сквозной низкой задержки передачи сигнала в беспроводных сетях, особенно в специальных применениях. Cisco ушел с нашего рынка, а мы прорабатываем собственные решения, которые помогут закрыть образовавшуюся рыночную нишу. Приглашаем вас к обсуждению проблемы, делимся своим опытом.
Где нужны действительно низкие задержки
Говоря о низких задержках, мы подразумеваем непотребительские решения. Для видеозвонков и совместной работы нам, как правило, достаточно соединения с задержками до 50 мс. А вот мир realtime управления ставит более жесткие границы - 20 мс и ниже. Некоторые задачи высокотехнологичных производств или телемедицины, где необходимо постоянно снимать информацию с датчиков или видеопотоки с камер, требуют задержек менее 10 мс. Более высокие значения могут помешать адекватному управлению оборудованием.
В целом надежная связь с минимальными задержками востребована в:
диагностике и хирургии в рамках удаленного здравоохранения - так можно повысить качество медицинских услуг в удаленных регионах;
промышленной автоматизации критически-важных процессов — это оптимизация расходов на производство;
интеллектуальном транспорте, способном обмениваться информацией между собой и с дорожной инфраструктурой - один из путей повышения безопасности дорожного движения;
построении дополненной/виртуальной реальности — это улучшение пользовательского опыта в самых разных областях;
задачах автоведения и разнообразных беспилотных решениях.
Сервисы и востребованная задержка
Откуда берется задержка сигнала
Производители телеком оборудования часто указывают значения задержки сигнала. Но как правило, это вклад их конкретного устройства. Мы же хотим поговорить о задержке с точки зрения потребителя, т.е. суммарном времени путешествия IP-пакета между конечным устройством и сервером. И раз уж мы говорим о концепции как таковой, не важно, имеем мы в виду end-to-end (от потребителя до сервера) или круговую задержку (RTT, измеряемую в обоих направлениях с учетом времени, необходимого на обработку запроса сервером).
Общее время прохождения IP-пакета складывается из задержек:
каждой из аппаратных компонент,
радиоинтерфейса как такового;
передачи данных через интернет.
И здесь важен вклад каждого компонента, т.е. работы по сокращению задержек в сети необходимо вести по всем этим направлениям, начиная с комплексного проектирования.
Сократить вклад последнего пункта можно за счет размещения сервера ближе к потребителю, поскольку сигнал имеет хоть и большую, но конечную скорость распространения. К примеру, если необходимо обеспечить покрытие некой территории сервисом с задержкой менее 10 мс, сервера должны располагаться в радиусе 200 км от потребителя. Это в свою очередь определяет количество и места размещения серверов.
Второй пункт определяется стандартом связи.
При разработке каждого следующего поколения беспроводных стандартов, рабочие группы заостряют внимание на задержках, пытаясь их минимизировать (и понимая, что в реальных сетях задержки будут выше, чем в идеализированных расчетах). В сетях 4G, 5G и Wi-Fi последних поколений предусмотрены под это интересные решения.
4G и 5G изначально создавались под обеспечение критически важных коммуникаций с низкими задержками. В 5G предусмотрено несколько реализаций для разного типа услуг. Есть своя реализация для подключения большого количества устройств (mMTC), для передачи видео высокой четкости (eMBB), а есть - для промышленных сценариев со сквозной задержкой менее 5 мс (URLLC). Отличаются реализации разным интервалом передачи - он выбирается, в зависимости от того, востребована спектральная эффективность или низкая задержка передачи.
У промышленного Wi-Fi с задержками чуть хуже, но стандарт также позволяет решить некоторые задачи на грани, хотя и работает в нелицензируемом диапазоне. Предполагается, что в следующем поколении Wi-Fi работа с задержками будет усовершенствована.
В целом тенденция к уменьшению задержек отлично прослеживается при сравнении поколений стандартов.
Еще один пункт - задержки на распаковку пакетов в аппаратных компонентах - можно сократить, упаковав все туннель так, что их не будут разбирать промежуточные устройства, тратя на это ценное время. Имеет значение количество устройств коммутации на пути движения пакета в сети, т.к. добавляется время на нахождение в очереди и задержка на прием-передачу из порта в порт. Более детально с методикой расчёта таких задержек, к примеру, можно ознакомиться в статье:
https://www.baeldung.com/cs/packet-time-latency-bandwidth
Как это реализуется на практике
По сути, существующие беспроводные стандарты немного перекраиваются под другой аспект применения. Известный пример - Cisco URWB (Cisco Ultra-Reliable Wireless Backhaul), основанный на Wi-Fi и ориентированный на обслуживание мобильных сред, вроде поездов, автобусов и дистанционно управляемого оборудования. В масштабах одного из мегаполисов у партенера развернута беспроводная сеть Cisco URWB на которой собраны данные ping RTT с различной нагрузкой трафиком на сеть (данные снимались при движении по одному и тому же маршруту, в одно и тоже время и на одной и той же беспроводной точке доступа транспортной единицы).
Как видно из представленных данных, с увеличением загрузки канала происходит ухудшение ситуации с прохождением пакетов. Особенно опасны всплески в местах с проблемами с покрытием или узким горлышком.
Это промышленный Wi-Fi, но мы могли бы улучшить результаты, перейдя на 4G или 5G. Собранные данные позволяют проектировщикам критических систем или систем автоведения сделать выводы на сколько существующая система связи отвечает требованиям и, по крайней мере, принять меры, зная реальное положение дел на беспроводной сети. Так же эти данные можно загрузить в симулятор и отладчик, чтобы посмотреть, как система сможет отреагировать на ситуацию в канале. Так можно сэкономить затраты на этапе отладки.
Обратим внимание на то, что при реализации критической инфраструктуры партнера, чувствительной к задержкам, оказалось очень влияют следующие факторы:
Задержка на коммутаторах и маршрутизаторах опорной сети – становится заметно особенно в часы наибольшей нагрузки;
Возможность использовать QoS – данные, например, автоведения должны иметь наибольший приоритет;
Наличие резервирования оборудования – однозначно важно при реализации, т.к. от этого зависят критические сервисы;
Наличие резервного питания – как минимум несколько часов работы должно обеспечиваться на аккумуляторах;
Оптические и другие типы SFP модулей в 1 Гбит/c не годятся на опорной сети, если вы собрались делать автоведение. Требования к сервисам слишком высоки для автоведения. В таком случае важно провести кропотливую работу по выявлению узких горлышек опорной сети следуя условию одномоментной максимальной нагрузки. Или если система реализуется в масштабах мегаполиса, то здесь однозначно сегментирование сети и применение более скоростных типов SFP+/SFP модулей в том числе с учетом задержки и рекомендаций по размещению беспроводных шлюзов непосредственно в зоне обслуживания сегмента сети;
Единый широковещательный домен L2 (Broadcast domain) не допустим в рамках беспроводной сети мегаполиса. Следует применять механизмы кластеризацию сети на малые широковещательные сегменты L2, которые соединяются между собой через беспроводные шлюзы по L3, образуя иерархическую структуру. Деление по географическому принципу приветствуется.
Коммутаторы последней мили должны обеспечить пропускание гораздо большей нагрузки и адекватно реагировать на переполнение таблицы MAC и широковещательный домен. Не должно возникать ситуации, когда коммутатор подвисает при забивке порта UDP пакетами.
Очень вам поможет возможность QoS на уровне VLAN на L3 – это нужно, что бы трафик от пользователей не мешал работе, например, автоведения.
Борьба с помехами – очень актуально в нынешних реалиях. Партнер не раз сетовал, что установленное оборудование работает в одном диапазоне частот и не имеет механизмов борьбы с помехами.
Улучшение покрытия и проблемных зон – требуется возможность расширенного анализа и методология.
Безопасность, шифрование – это очень востребованная опция. Если беспроводное оборудование из коробки позволяет делать шифрование трафика в сети, то этого недостаточно, необходимы сертификаты безопасности и согласования. Использование сторонних продуктов сразу же вызывает массу вопросов, не только у безопасников, но и у сетевых инженеров по задержкам, функционалу таких решений (поддержка VLAN, QoS, производительность и т.д.).
Возможность отключать пользовательский трафик, для создания идеальных условий.
И другое, т.к. существует много нюансов применительно к каждой уникальной задаче того или иного Заказчика.
Можно ли их реализовать на нашем оборудовании
Лидер по производству подобного оборудования - компания Cisco. Но она по понятным причинам ушла с нашего рынка и вряд ли в ближайшее время вернется. Можно сказать, что образовался некоторый вакуум, который мы в Аквариусе пытаемся заполнить.
Безусловно решение поставленных нами задач амбициозно и не ограничено рамками тестовых зон. Мы сразу закладываем в алгоритмы полученный нами опыт на сетях масштаба мегаполиса наших текущих Партнеров. Рады приветствовать так же обращение к нам за реализацией проектов наших будущих Партнеров: роботизации уборочной техники в сельском хозяйстве, занимающихся различными беспилотными тематиками для дорожной ифраструктуры, ГОК, шахт, служб беспилотной доставки товаров и грузов, Сортировочных узлов железной дороги и т.д. Применений более дешевых технологий базирующихся на промышленном Wi-Fi масса, а особенно там где заказчики не хотят вкладываться в дорогостоящие проекты Private LTE/5G.
Наше оборудование во многом базируется на идеях Cisco - мы взяли за основу их идеологию URWB. Однако мы пошли немного дальше, например ориентируясь на более высокие скорости передачи данных, использовали более высокопроизводительные чипы (как радиочипы, так и чипы самой платформы). В теории мы сможем достичь скоростей в 2,5 Гбит/с, что конечно же сильно зависит от реалий состояния радиоинтерфейса, покрытия, наличия помех. Кроме того, мы будем работать в различных диапазонах частот - перекрывать полосы и в 2.4, и в 5 ГГц (система позволяет работать и с другими диапазонами при использовании плат расширения, место под них предусмотрено).
В отличие от оборудования Cisco, мы прорабатываем возможность к промышленным точкам доступа подключать и обычных пользователей.
Разработка железа пока на стадии опытных образцов, которые мы обкатываем на площадках партнеров. Анонс устройств запланирован на вторую половину 2025 года.
В рамках статьи не представляется возможным поделиться многими аспектами в силу их конфиденциальности. Но мы всегда рады после подписания Соглашения о неразглашении (NDA) поделиться с потенциальным Партнерами нашими наработками, учесть их пожелания, построить совместные планы на будущее.
Если вам интересно поучаствовать в разработке оборудования, приходите. Мы ищем и талантливых инженеров, и стратегических партнеров со стороны бизнеса, под задачи которых можно было бы адаптировать технологии. Более подробную информацию о самом оборудовании вы сможете найти в наших будущих статьях.