В этой статье я делюсь гибким архитектурным подходом к автоматизации сетей уровня сервис-провайдера и своим личным опытом отладки сигнального обмена.
Статья рассчитана не на новичков, а скорее тех, кто знаком с основными архитектурными принципами и технологиями, используемыми в сетях уровня оператора и имеет в этом практический опыт.
Представьте себе мультивендорную сеть крупного мобильного оператора или сервис-провайдера. В этой сети присутствует множество различных архитектурных элементов, каждый из которых имеет свои собственные интерфейсы и форматы M2M взаимодействия. Управление, обслуживание и реагирование на различные события в сети требует постоянного внимания. Ответственность за разные элементы сети часто лежит на различных подразделениях, что иногда затрудняет оперативное взаимодействие между ними. В рамках такой сети постоянно выполняются проекты по замене (свопу) платформ, внедрению новых систем, обновлению устаревшего оборудования и прочим изменениям. Доступный бюджет обычно ограничен, поэтому зачастую выбирают решения с минимально необходимым набором функционала, что впоследствии иногда может оказаться недостаточным для реализации определенных сервисов. Иногда требуемый функционал отсутствует в выбранном решении, а вендор может не предоставить кастомизацию или сделать это за высокую цену, особенно если речь идет о крупных мировых брендах. Причем речь не идет про отсутствие бизнес‑функционала, предусмотренного стандартом, а скорее про некие специальные особенности, требуемые для конкретной компании. В таких случаях может быть ограничен выбор альтернативных решений для операторских платформ класса корпоративного уровня. Часто препятствием для полноценного использования платформы могут стать несовместимость формата API, отсутствие необходимых процедур или другие особенности, которые могут сделать эксплуатацию неудобной. Малейшие изменения в алгоритме работы платформы могут стать сложными или даже невозможными для внедрения, что создает проблемы в долгосрочной перспективе.
Для создания гибкой, монолитной, автоматизированной и отлаженной сети оператора, которая будет удобной в эксплуатации, важно иметь систему, способную эффективно управлять взаимодействием между всеми сервисными элементами и системами, такими как биллинговая/CRM системы, системы самообслуживания, сервисные платформы и элементы автоматизации.
Причем сеть крупного оператора — это система, где могут происходить тысячи событий одновременно, то есть требуется решение, которое будет гибко расширяться и масштабироваться. Также стоит отметить, что, как правило, сеть провайдера — это критический для бизнеса его клиентов сервис, поэтому решение также должно быть отказоустойчивым и, по возможности, геораспределенным.
Что делать в этом случае? Видится 3 возможных решения для управления сетью, имеющих свои как достоинства, так и недостатки:
Каждая платформа сама по себе. Эксплуатацию проводить вручную. Нанять под каждую платформу (или группу платформ) людей и поручить им их эксплуатацию. Не совсем решение обозначенной проблемы, однако подход, который используют некоторые операторы. Решение это дорогое, а при большом количестве рутинных операций не всегда эффективное. Также в этом случае имеет значение человеческий фактор, когда не выспавшийся после третьих ночных работ инженер ошибается в введенной команде или открытой консоли и, например, перезагружает то что не стоило перезагружать, при этом лишая связи целый регион.
Частичная автоматизация, лишенная монолитности и централизации своими силами. Написать множество скриптов автоматизации бизнес‑процессов и технологических процессов, также внедрить одну или несколько СУС, тратиться на дальнейшую техподдержку данного решения, а также при каждом изменении на сети (будь то свопы оборудования/программных платформ, обновления ПО при которых могут поменяться форматы API) переписывать данные скрипты автоматизации. В данном случае сеть лишается монолитности, а резервирование запуска скриптов автоматизации будет оставлять желать лучшего. А также возникает вопрос в преемственности решения при увольнении сотрудника, написавшего тот или иной скрипт.
Разделить функции запуска управляющих команд и интерфейс взаимодействия с сетью в отдельные сетевые элементы. Причем в качестве интерфейса запустить централизованную масштабируемую систему, своеобразный сигнальный маршрутизатор для передачи управляющих команд между узлами сети, централизованный интерфейс взаимодействия с сетью. А передача управляющих команд в этом случае сведется к взаимодействию с этим единым интерфейсом, API шлюзом.
Причем третий вариант — разработка централизованной масштабируемой системы, API шлюза для управления сетью, выглядит весьма перспективно и эффективно. Это действительно может значительно упростить управление сетью, обеспечивая высокую отказоустойчивость, масштабируемость и гибкость. Такой подход мною уже был апробирован на практике и показал отличные результаты. Самое главное — все обозначенные проблемы, описанные выше, он решил.
Перед тем как рассказать про саму Систему, хотелось бы показать общую тенденцию и актуальность решения описываемой архитектуры, обозначить, каким образом происходила эволюция стека протоколов используемых в сетях операторов, а также как трансформировалось ядро сети оператора для разных технологий.
Начнем с технологий мобильной связи, а именно с сетей 2G/3G. Архитектура их ядра схожа, и в данном контексте рассматривать отдельно 2G от 3G не имеет особого смысла.
Итак, сети 2G/3G имеют множество различных протоколов сигнального обмена. Здесь и протоколы стека SS7 и Radius/Diameter. Явно выделенное голосовое ядро и пакетное ядро. Базовые станции включаются в радиоконтроллеры, которые направляют голос и СМС по одному плечу, а пакетные данные по-другому. Множество различных специфических протоколов, развивавшихся еще со времен SDH/PDH.
Взаимодействие со сторонними системами управления возможно, как по протоколам, отмеченным на схеме, так и стандартным протоколам управления, например, SSH, SNMP, API (если поддерживается элементами сети). Ни о какой унификации здесь речи не идет, присутствует большой набор разнообразных форматов сообщений, который можно усовершенствовать и упростить, что собственно и было сделано в последующем. Также для маршрутизации сообщений стека SS7, как правило используется централизованная сигнальная маршрутизация через STP.
Далее, в сетях 4G уже отсутствует использование протоколов стека SS7 и на его замену пришел протокол Diameter и SIP. Для поддержки легаси остался старый принцип по части передачи SMS сообщений через SGs интерфейс (интерфейс между ММЕ и MSC), если в сети оператора не реализован функционал VoLTE и как следствие недоступна передача SMS по SIP через IMS платформу.
Причем прошу обратить внимание, протоколы меняются только в части сигнализации, в части передачи данных как был GTP-U, так он и остался (в том числе и для 5G), лучше еще не придумали, только версия меняется. Как собственно не придумали лучше, чем протокол BGP для передачи маршрутной информации в глобальной сети.
Здесь уже отсутствует явно выраженное голосовое ядро. Передача голоса возможна двумя вариантами – выполнять процедуру CS fallback, то есть хендовер в 3G при голосовом звонке, либо проключать голосовые вызовы по пакетной сети с использованием протокола SIP и IMS платформы. Это уже IP телефония.
То есть здесь процесс упрощения и унификации уже начат, но в том числе ввиду необходимости совместимости сетей 4G с сетями предыдущих поколений, не закончен.
Но суть осталась прежней, при передаче управляющих команд на сервер отправляется набор атрибутов и в ответ получаем набор атрибутов.
Также появился элемент централизованной маршрутизации сообщений Diameter – DRA (аналог STP в сетях 2G/3G).
Сети 5G в части передачи управляющих команд уже более интересны.
С развитием технологии 5G была предложена новая концепция архитектуры сети — Сеть с сохранением состояния (Stateless Network). В этой архитектуре сеть становится более гибкой и масштабируемой, а также получает возможность быстро реагировать на изменения в нагрузке.
Для передачи сигнализации в сетях 5G используется только один протокол — REST API поверх HTTP/2. Все, этого достаточно. Но суть осталась прежней, передаем набор параметров и принимаем набор параметров.
Архитектурно сеть полноценно разделилась на CP (control plane) и UP (user plane) функции, то есть базовая станция пропускает пользовательский трафик сразу на шлюз UPF (в отличие от принципа 4G, когда трафик идет сначала на SGW, а потом на PGW, причем SGW и PGW также имели в том числе отчасти функционал управления).
Голос здесь также как в 4G идет по SIP через IMS платформу и пакетное ядро в этом случае выступает как транспорт до IMS. Присутствует альтернативный вариант — 4G fallback для поддержки легаси.
В настоящее время наблюдается постепенная унификация протоколов, что особенно заметно в области управления, где происходит переход на единый протокол — REST API и сервис‑ориентированную архитектуру (Service Based Architecture). REST API становится все более популярным как протокол для передачи управляющих команд.
Благодаря HTTP, REST API удобен в использовании и обладает простым, понятно структурированным форматом. Он позволяет передавать данные в виде JSON‑объектов, содержащих все необходимые параметры. При этом есть возможность добавлять дополнительные опции в заголовки запросов.
Основные принципы работы таких протоколов, как Diameter, Radius и SS7/MAP, схожи с REST API. С его помощью можно передавать набор атрибутов (параметров) и получать в ответ другую их порцию. Вся логика сервера, реализовывающая функционал, заключается в том, что происходит на сервере от момента получения запроса до отправки ответных данных. Для разработчиков, зачастую мало знакомых с телеком‑процессами, данный подход более интуитивно понятен, чем работа с множеством экзотических протоколов.
Вероятно, в будущем эта тенденция к изменению принципов сигнального обмена будет только усиливаться. Устаревшие протоколы передачи AAA‑сообщений, вероятно, сменятся на REST API. Это приведет к необходимости создания элемента, который будет обеспечивать стыковку между операторами, таким элементом может стать API шлюз.
Использование REST API в телекоммуникациях имеет ряд преимуществ. Этот подход упрощает и ускоряет процесс совершенствования протоколов: достаточно изменить перечень полей в передаваемом JSON, не переделывая протокол полностью. Несмотря на сложившиеся системы обмена данными в сетях операторов и их межоператорское взаимодействие, переход на REST API очевиден. Для ускорения адаптации протоколов могут быть полезны системы, способные преобразовывать один протокол в другой, например, трансформируя Diameter или Radius в HTTP REST API. Это подчеркивает значимость такого архитектурного элемента, как API шлюз.
API шлюз — это централизованная система, обеспечивающая единый унифицированный интерфейс для взаимодействия между различными внешними и внутренними приложениями. Он выступает в качестве единой точки доступа для клиентских приложений и систем, упрощая и повышая безопасность взаимодействия с внешним миром. Само понятие API шлюз в IT давно известен, но, здесь речь скорее про более широкое его назначение в виде отдельной платформы с дополнительным функционалом.
Еще в 2016 году я разработал и внедрил подобную систему, что в последствии показало свою эффективность.
Получилась платформа, которая обрабатывает входящие API запросы, при необходимости взаимодействует с внешними системами и возвращает ответ. Помимо основной функции, платформа также обладает дополнительным функционалом для самоконтроля: отслеживает показатели KPI, контролирует состояние узлов, обеспечивает внутренний обмен данными между компонентами системы, собирает телеметрию и использует резервирование структурных элементов.
Способ интеграции в сеть этой платформы изображен на схеме ниже.
Все что может быть автоматизировано – должно быть автоматизировано. Из этого принципа исходят современные архитектуры программируемых сетей. Особенно подключение услуг, настройка технологических параметров, реализация рабочих сценариев. Но на практике не всегда получается связать Биллинг/CRM с сервисными элементами напрямую. Также ввиду широкого развития и внедрения в процессы компании систем искусственного интеллекта, требуется интерфейс, по которому такая система будет взаимодействовать с сетью. Причем давать прямой и неконтролируемый доступ подобным системам к элементам сети слишком рискованно. Намного безопаснее использовать прослойку в виде API-шлюза, предоставляющего ограниченный набор доступов и процедур, которые можно использовать.
API-шлюз также может служить централизованным связующим элементом для унификации формата API между различными производителями ПО, что удобно при смене платформ, интегрирует различные системы и приложения, позволяя им работать синхронно. Это позволяет избежать необходимости доработок на обеих сторонах.
Иногда требуется дополнительный функционал, такой как ограничение количества запросов для конкретной процедуры или установка квоты на количество запросов. На основе этих требований представлена архитектура обработки запросов для API-шлюза.
Также полезна функция маршрутизации API-запросов, например, по IP-адресу источника, заголовку или другим параметрам. В этом случае API-шлюз функционирует как L7 маршрутизатор (аналогично STP либо DRA для сетей 2G/3G, 4G).
Для гибкости в написании сценария обработки запроса в моей Системе можно использовать любой язык программирования или конструктор из готовых блоков. Таким образом, ядро обработки представляет собой подпрограмму, в которой реализуется вся необходимая логика.
Набор и порядок блоков предобработки и постобработки для различных процедур могут отличаться. Есть возможность исключать некоторые модули, например, полностью отключить валидацию или контроль скорости.
Контроль скорости осуществляется на двух уровнях: для входящих запросов и для взаимодействия с бэкендом. При превышении установленного порога возвращается ответ с соответствующим кодом ошибки. Также доступны интерфейсы для различных бэкендов с поддержкой разнообразных протоколов.
Вот ряд сценариев, для которых данная система использовалась на практике:
Реализация единого сценария. Была система, которая умела обращаться к стороннему SOAP API, но не поддерживала выполнение сложных запросов, когда необходимо сначала запросить одну процедуру, достать из ответа на нее определенный параметр, а потом запросить другую процедуру. С помощью API шлюза была сделана кастомизация и сведение подобного алгоритма к единой процедуре.
Адаптация формата API к формату, который поддерживает система. То есть у системы уже в код был зашит определенный формат API, менять через инструменты конфигурации можно только передаваемые параметры, но никак не сам формат. Исходных кодов разумеется не было, поменять формат возможности не было. А другая система имела свой немного отличающийся формат запроса. Соответственно проведено подобное преобразование.
Подготовка API метода, реализующего довольно сложный алгоритм работы с взаимодействием к ряду различных систем, с предоставлением этого метода разработчикам WEB портала для реализации на нем необходимого функционала. Аналогичный принцип с приложением для ПК и мобильным приложением.
Взаимодействие между системами разных подразделений в компании. Когда требуется также свести реализацию сложного алгоритма к выполнению простой процедуры.
API маршрутизация запросов. Сокрытие внутренней архитектуры сети.
Да, действительно, возможности применения API шлюза очень разнообразны и вышеупомянутые способы использования просто подчеркивают его важность в современном мире цифровых технологий. Единый API шлюз для всех взаимодействий как внутри организации, так и с внешними партнерами позволяет существенно упростить управление трафиком, обеспечить безопасность и контроль над обменом данными и периметром сети, что является критически важным аспектом в современной информационной безопасности.
Интеграция с микросервисами, инструментами DevOps и другими системами с открытым исходным кодом при помощи API шлюза может значительно ускорить развертывание новых сервисов и обеспечить их надежную работу. Создание API сервера с определенным форматом ответа для лабораторных целей также может быть очень полезным для тестирования и отладки различных сценариев.
API шлюз может быть использован для реализации различных архитектурных элементов комплексных платформ, в том числе и в контексте сетей 5G.
В завершение хочу добавить немного коммерческой составляющей, как внедрение такого элемента сети можно монетизировать.
Продажа пакета с определенным количеством запросов или оплата по количеству запросов. В этом случае оператор предоставляет конечному клиенту M2M интерфейс для получения какой-то информации или выполнения действий. Например, проверка какому оператору принадлежит конкретный абонентский номер (за счет реализации HLR запроса). Предлагать различные тарифные планы в зависимости от объема запросов может привлечь клиентов.
Автоматизация выполнения рутинных задач с помощью внедрения новых элементов сети, позволяющая экономить человеко-часы, также может быть коммерчески успешной стратегией. Клиенты будут заинтересованы в оптимизации своих рабочих процессов и готовы заплатить за автоматизацию.
Повышение конкурентного преимущества и привлекательности других услуг компании за счет более быстрой обработки запросов благодаря автоматизации - это отличный способ привлечения новых клиентов и удержания текущих.
Предложение API шлюза как составной части других сервисных платформ/систем также может быть прибыльным. Компании, работающие с подобными платформами, будут оценивать возможность использовать вашу интегрированную технологию.
Снижение затрат на внедрение других платформ благодаря упрощению их взаимодействия с сетью может привлечь компании и организации, которые стремятся к оптимизации своих бизнес-процессов.
Объединив эти коммерческие возможности, можно создать привлекательное предложение для клиентов и достичь успешной монетизации внедрения данного продукта.
Если у вас возникнут дополнительные вопросы или нужна помощь с чем-то еще, не стесняйтесь обращаться!
Буду рад обратной связи и услышать ваше видение об описанном архитектурном подходе.