Баннер GTPCProxy

GTP-C Proxy

Прокси управляющей плоскости GTP-C для мобильных сетей

О решении

СКАТ GTP-C Proxy позволяет объединять PGW разных производителей в общие пулы, распределять абонентов по правилам оператора и управлять отказами без изменения конфигурации SGW и MME: достаточно один раз указать прокси в DNS для APN.

Решение поддерживает GTPv1 и GTPv2, помогает развивать сеть без перенастройки SGW и MME и сохраняет состояние подключений при перезапуске прокси.

СКАТ GTP-C Proxy зарегистрирован в реестре российского ПО Минцифры

Схема GTP-C Proxy

Зачем оператору GTP-C Proxy

PGW разных производителей – в одной сети

GTP-C Proxy объединяет шлюзы в общие пулы, которыми можно управлять через единые правила. Существующую конфигурацию SGW и MME при этом менять не нужно.

Выбор PGW по правилам оператора

Абоненты направляются на нужные шлюзы по IMSI, MSISDN, APN, PLMN, типу радиодоступа (RAT) и местоположению абонента (ULI), а также по их сочетаниям. Веса пулов и резервные PGW позволяют настраивать распределение под требования сети.

Реакция на сбои без ручного переключения

Если PGW выходит из строя, GTP-C Proxy исключает его из пула и направляет новые подключения на исправные PGW с подходящей версией GTP. Состояние подключений сохраняется в Redis, в том числе при перезапуске самого прокси.

Переходы между 2G/3G и LTE

GTP-C Proxy поддерживает GTPv1 и GTPv2 и обеспечивает смену версии протокола при переходе абонента между поколениями сети.

Как устроен СКАТ GTP-C Proxy

Пулы GTP-C Proxy

GTP-C Proxy работает с управляющей плоскостью GTP-C между SGW / SGSN и PGW. Для SGW прокси выглядит как PGW, а для PGW – как SGW. DNS оператора для APN указывает на прокси, который выбирает целевой PGW по настроенным правилам и передает ему сигнализацию.

Абонентский трафик GTP-U идет напрямую между SGW и PGW. GTP-C Proxy не включается в тракт передачи пользовательских данных.

В результате оператор получает дополнительный уровень управления выбором PGW, сохраняя существующую архитектуру сети доступа. Взаимодействие использует стандартные сообщения GTP.

Отправьте запрос на персональную демонстрацию и тестирование решения

Масштабирование

Производительность растет вместе с числом потоков

Как масштабируется инфраструктура?

GTP-C Proxy масштабируется на трёх уровнях: потоки обработки на сервере, экземпляры прокси и хранилище состояния. Каждый уровень наращивается независимо.

Потоки обработки

Сигнализацию обрабатывают несколько рабочих потоков, закреплённых за ядрами процессора. На промышленном тестовом стенде производительность обработки достигает 348 тыс. операций Modify Bearer в секунду на четырех ядрах.

Экземпляры прокси

Несколько экземпляров GTP-C Proxy работают с общим хранилищем и общими правилами маршрутизации. Состояние сессий хранится централизованно, поэтому отказ одного экземпляра не приводит к потере подключений. Переключение между экземплярами выполняется через BGP.

Хранилище состояния

Один сервер Redis выдерживает около 105 тыс. Modify Bearer/с. Для большей нагрузки используется кластер Redis с репликами и автоматическим переключением при отказе ведущего узла.

Правила без перезапуска

Пулы PGW, веса и правила маршрутизации хранятся в едином документе (YAML-файл или Redis) и применяются ко всем экземплярам на лету, без перезапуска и потери сессий.

Отказоустойчивость

Не более 2,03 с (максимальное время переключения при отказе ведущего узла Redis в испытании под нагрузкой)

Рестарт прокси

Состояние хранится в Redis, поэтому подключения сохраняются.

Отказ или рестарт PGW

Отказавший PGW выводится из пула, а новые подключения направляются на исправные PGW с подходящей версией GTP. Рестарт PGW определяется по сообщениям Echo.

Рестарт SGW

Сессии сохраняются и восстанавливаются по процедуре 3GPP TS 23.007 (раздел 27).

Перегрузка

Действующие абоненты обслуживаются в первую очередь; новые подключения отклоняются.

Резервирование экземпляров

Переключение между экземплярами прокси через BGP.

Возможности СКАТ GTP-C Proxy

Протоколы и маршрутизация

  • GTPv2 на S5/S8 и GTPv1 на Gn/Gp.
  • Непрерывность сессии при переходе между 2G/3G и LTE.
  • Пулы PGW разных производителей.
  • Маршрутизация и перераспределение новых подключений между PGW, замена параметров сессий и отчеты о местоположении для S5/S8 и Gn/Gp.
  • Сохранение подключений при перезапуске SGW согласно TS 23.007, раздел 27.

Надежность, емкость и управление

  • Производительность до 348 тыс. операций Modify Bearer в секунду на четырех потоках.
  • Управление нагрузкой и сторожевой таймер.
  • Веб-интерфейс, Prometheus и Grafana.
  • Просмотр сессий и настройка пулов Gn/Gp в веб-интерфейсе.
  • Поставка в RPM-пакетах для VEOS 8.x и EL8.

Единое окно управления

 

Веб-интерфейс

Сессии, история документа маршрутизации, состояние экземпляров и PGW, роли администратора и наблюдателя.

Prometheus

Метрики сообщений, транзакций, отказов, хранилища и PGW по версиям GTP.

Grafana

Встроенные панели мониторинга с аутентификацией через веб-интерфейс.

Требования к развертыванию

Параметр Требования
ОС VEOS 8.x или EL8, x86_64; glibc 2.28, systemd 239
Поставка RPM-пакеты gtpcproxy и gtpcproxy-web. Установка, обновление и откат через dnf
Виртуализация KVM или VMware. Рекомендуются выделенные vCPU в соотношении 1:1 с физическими ядрами одного узла NUMA
Сеть Буфер приема сигнализации 8 МиБ: CAP_NET_ADMIN или net.core.rmem_max не менее 8 МиБ
Redis Redis должен отвечать без пауз длиннее 250 мс (например, при живой миграции ВМ). Перенос виртуальной машины с Redis рекомендуется выполнять в окно обслуживания
CPU и память Для 348 тыс. Modify Bearer/с: 19 выделенных ядер всего, из них 4 – обработка сигнализации
Контейнер Podman (rootless)

Отправьте запрос

Заполните форму
Мы свяжемся с вами, обсудим ваши задачи, предоставим доступ к документации и ответим на вопросы.
Выберите решение
Определим исходную ситуацию: объем трафика, доступное оборудование, необходимую функциональность.
Протестируйте
Наши инженеры установят программное обеспечение в вашу сеть и помогут с настройками. Договор — только после успешного тестирования.