В 2017 году мы в НТЦ ПРОТЕЙ начали разработку пакетного ядра частных 4G-сетей для корпоративных заказчиков. О главных задачах, которые нам пришлось решать, и основных сложностях, с которыми мы столкнулись при работе над полностью отечественным продуктом, рассказано в этой статье.
Корпоративные задачи по передаче мультимедиа, в том числе в разношерстных сетях датчиков IoT, вполне можно решать с помощью стандартов для сетей общего пользования — 4G и 5G, если адаптировать их к частным сетям. Эта идея подтолкнула развитие сегмента Private LTE, и сейчас в мире есть много новых игроков с комплексными решениями. С той же идеи в 2017 году началась наша разработка полностью отечественного ядра сети 4G для частных сетей.
Почему мы взялись за проект?
Более 15 лет мы разрабатываем различные решения для операторов связи, как проводных, так и мобильных, занимаемся собственными исследованиями в этой области.
В начале 2000-х нашими первыми заказчиками были региональные предприятия связи, позже объединенные в рамках ПАО «Ростелеком». Кроме того, долгое время в Мегафоне работал наш центр обработки SMS-трафика. А тарификацию голосовых вызовов в режиме онлайн в ряде крупных регионов обеспечивают наши CAMEL-шлюзы.
На старте мы разрабатывали только отдельные компоненты ядер сетей GSM/UMTS и LTE. Но по мере развития пришли к пониманию, что можем построить всю логическую часть сети (не трогая радиоподсистему), поскольку основные компоненты — HLR/HSS, GMSC, GGSN/PGW, DPI — уже были в нашем портфолио. Теперь на нашем ПО работают все российские виртуальные операторы общедоступной мобильной связи LTE (MVNO, Mobile Virtual Network Operator).
Частные мобильные сети связи — PMR (Professional или Private Mobile Radio) — начали развиваться даже раньше, чем операторы связи общего пользования. Но до сих пор большинство корпоративных сетей отдают приоритет голосу, базируясь на цифровых стандартах второго поколения: TETRA, APCO 25, DMR. В корпоративном сегменте эти задачи частично решаются при помощи Wi-Fi-сетей. Но сама идеология этого семейства стандартов не обеспечивает необходимой надежности передачи данных. Кроме того, несмотря на постепенную адаптацию следующих версий Wi-Fi к сетям с высокой плотностью абонентских терминалов, проблем добавляет общий частотный ресурс.
Особняком стоят специализированные узкополосные сети передачи данных для сбора показаний с датчиков. В основном они строятся на проприетарных технологиях и радиомодемах и совершенно не предназначены для передачи больших объемов данных, например, оцифрованного звука или видео.
Особняком стоят специализированные узкополосные сети передачи данных для сбора показаний с датчиков. В основном они строятся на проприетарных технологиях и радиомодемах и совершенно не предназначены для передачи больших объемов данных, например, оцифрованного звука или видео.
Наш Private LTE
Пакетное ядро LTE — это оборудование и программное обеспечение, осуществляющее обработку и маршрутизацию трафика внутри частной мобильной сети 4G. По сути, это центр управления сетью, через который взаимодействуют все базовые станции. Ядро связано с радиоподсистемой посредством стандартных интерфейсов, поэтому может рассматриваться как самостоятельный элемент сети и самостоятельный продукт. Но, естественно, при этом оно должно поддерживать рекомендации 3GPP.
В основу ядра частной сети 4G легли наши наработки для общедоступных сетей.
Схема построения LTE-сети разработки НТЦ ПРОТЕЙ
Как и продукты для общедоступных операторов, ядро частной 4G мы разрабатывали на C++. С нашей точки зрения, это оптимальный выбор.
Отдельной большой частью проекта стала оптимизация кода. Это естественный процесс развития продуктов: ПО просто не может стоять на месте. Внешние факторы — от потребностей абонентов до прошивок железа — меняются, так что даже при неизменном наборе функций продукт должен развиваться. Исходя из этих соображений, мы оптимизировали все компоненты ядра. С переходом на новые стандарты связи нагрузка на железо растет, а пропорционально наращивать аппаратные мощности в некоторых случаях не просто дорого, а невозможно. Так что у нас не было выхода.
Ядро сети 4G должно обрабатывать миллионы пакетов и сотни тысяч транзакций в секунду. В этих условиях любое обращение к памяти, любой дополнительный вызов виртуальной функции вносит свой вклад в общую производительность. Так что нам пришлось провести глубокий рефакторинг кода. Мы ушли от синхронизации кэшей L1-L2 ядер, которая влияла на скорость доступа к оперативной памяти через выравнивание структур данных. Мы не стали раздувать структуры, занимавшие около 80 байт, до 128 (чтобы не терять впустую треть памяти). Вспомнили про выравнивание полей внутри структур, за счет чего сократили размер до 64 байт, кратных размеру кэша.
Использование каждой новой возможности C++ добавляло еще по 3–5% к производительности, так что в итоге мы получили почти двукратный рост.
Выжав разумный максимум из высокоуровневой оптимизации, мы перешли к низкоуровневым. Анализ показал, что процессоры ждут данных: L1 missed, показатель Cycles per Instruction высокий (4–20 тактов на инструкцию). Это вынудило искать решения по превентивной загрузке данных из памяти в кэш процессора.
Для этого мы использовали prefetch.
GCC поддерживает __builtin_prefetch. Мы используем:
<source>
static inline void prefetch(const volatile void *p) {
asm volatile ("prefetcht0 %[p]" : : [p] "m" (*(const volatile char *)p));
}
</source>Prefetch обеспечил нам рост производительности еще примерно на 5%. В абсолютных величинах это обработка дополнительно примерно 10–20 тыс. пакетов в секунду без какого-либо изменения логики их обработки.
В процессе работы над ядром 4G нам пришлось учитывать, что каждое предприятие имеет собственные специфические требования и запросы. В частности, многим нужна гладкая миграция от используемых аналоговых и цифровых стандартов голосовой связи к частной сети нового поколения. Поэтому нам пришлось поработать над взаимодействием разрабатываемого ядра с сетями предыдущих поколений. В отдельных сегментах бизнеса существуют собственные требования регулятора, а также корпоративные правила, касающиеся внутренней связи. Это также пришлось иметь в виду.
Вариант построения ведомственной сети LTE
В целом такие частные требования и интеграции серьезно усложняют жизнь нашим разработчикам. Наш любимый пример на эту тему — история с общедоступным мобильным оператором из далекой африканской страны. Хотя это немного другой рынок, история отлично иллюстрирует идею, не раскрывая ничьих корпоративных секретов. В той сети мы внедрили наш PGW (Packet data network Gateway). Он справлялся со своими функциями, пока один из абонентов не начал жаловаться на отсутствие мобильного интернета. Анализ логов показал, что от абонента приходило целых три стандартных запроса Create Session Request с разницей в несколько миллисекунд. Наша система обрабатывала эти запросы в соответствии с 3GPP, который, естественно, не предусматривает возможности такой отправки запросов. В итоге все сессии абонента закрывались — мобильный интернет отключался. Хотя формально баг был не на нашей стороне, пришлось усложнить код TDF, чтобы устранить проблему.
Еще один интересный пример — про TDF (Traffic Detection Function), но уже корпоративного уровня. Установив решение у заказчика из другой страны, мы получили негативную обратную связь с пометкой: CEO IS NOT HAPPY. Однако все тесты показывали, что работа подсистемы в норме. После прояснения ситуации оказалось, что CEO привык к более гладкому графику двухнедельной статистики, поскольку предыдущее решение другого производителя снимало контрольные точки раз в 15 минут. А наш TDF работает слишком точно — берет контрольные точки раз в 10 секунд, чем «портит» гладкий график. В этом случае пришлось ограничиться разъяснительной работой, поскольку на собираемые данные была завязана вся структура нашего пакетного ядра, т. е. нельзя было просто сменить форму отображения графика (красивый график не стоил потерь в остальном продукте).
На сегодняшний день разработка закончена. Ядро позволяет организовать беспроводную связь в компаниях любой численности и любой территориальной локализации, так как по сравнению с сетями общего пользования, с которыми мы обычно работаем, размерность таких сетей невелика, что, однако, компенсируется большей сложностью системы сервисов, требующих гарантированной доставки мультимедиа-данных. В России такого рода системы строятся только крупными организациями, так что и сети заказчиков сразу приобретут значительную размерность уже после опытной эксплуатации.
Уже сейчас мы начали развивать наше ядро в направлении 5G. В логике работы стандартов есть некоторые отличия, кроме того, нам необходимо еще больше оптимизировать ПО для работы с новыми объемами трафика. Выпуск 5G-решений запланирован на 3–4-й квартал 2020 года.