Телеком 5 хв читання

Модернізація legacy телеком-систем: поетапний перехід до cloud-native без зупинки ядра

Практичний посібник з модернізації телекому: розбір монолітів BSS/OSS, захист застарілих сигнальних протоколів та безпечний перехід до архітектур ODA й 5G SBA.

Сучасний телеком-ринок вимагає від операторів безпрецедентної гнучкості, швидкості запуску нових послуг та надійного рівня безпеки. Проте розвиток більшості гравців досі стримується застарілими монолітними системами BSS/OSS (Business/Operations Support Systems). Перехід до повноцінних мереж 5G неможливий без кардинальної зміни підходу: операторам необхідно трансформувати жорстку інфраструктуру в масштабоване cloud-native середовище.

Головний виклик полягає в тому, що телеком-ядро не можна зупинити для одномоментного оновлення. Модернізація має відбуватися без переривання критичних бізнес-процесів. Єдиним життєздатним сценарієм є поетапний транзит через створення інтеграційних шарів та поступове витіснення застарілих компонентів мікросервісами.

Чому монолітне ядро BSS/OSS та legacy-протоколи стали точкою відмови

Історично телеком-архітектура будувалася як моноліт, де логіка білінгу, маршрутизації трафіку та управління профілями була жорстко пов'язана. Будь-яка зміна чи запуск нового сервісу потребують перескладання значної частини системи, що критично уповільнює розробку та впровадження інновацій.

Крім обмежень у гнучкості, legacy-архітектура має фундаментальні вразливості на рівні безпеки. Застарілі сигнальні протоколи (SS7 та Diameter) не містять вбудованих механізмів автентифікації сучасного рівня. Згідно зі звітом ENISA Threat Landscape 2025, суттєво інцидентів безпеки зачіпають критично важливі суб'єкти, а експлуатація вразливостей сигнальних протоколів залишається постійною загрозою для мобільних мереж. Ці прогалини активно використовуються для організації складних фрод-схем. За даними CFCA Global Fraud Loss Survey 2025, глобальні збитки від телеком-фроду оцінюються приблизно у $41,82 млрд на рік, що підтверджує неспроможність застарілих систем самостійно протистояти сучасним загрозам.

Концепція ODA та SBA: архітектурні орієнтири

Для подолання обмежень монолітів світова індустрія стандартизувала два ключові підходи: Open Digital Architecture (ODA) від TM Forum та Service-Based Architecture (SBA) від 3GPP.

Концепція ODA передбачає заміну монолітних BSS/OSS на компонентну, API-first архітектуру. Це дозволяє розгорнути набір стандартизованих, слабопов’язаних модулів для автономних операцій. Оператор отримує можливість оновлювати або замінювати окремі блоки без ризику вплинути на роботу всього білінгу.

Зі свого боку, архітектура SBA (визначена 3GPP для 5G Core) є головним драйвером переходу мереж на принципи cloud-native. Вона трансформує традиційні мережеві елементи на програмні мережеві функції, які взаємодіють між собою через API, забезпечуючи динамічне масштабування та оптимізацію ресурсів.

Стратегія «Душителя» (Strangler Fig): як розібрати моноліт

Спроба замінити ядро стратегією одночасного запуску («Big Bang») майже завжди призводить до масштабних збоїв. Найбільш ефективною та безпечною є стратегія «Душителя» (Strangler Fig pattern), яка складається з трьох ключових етапів:

  1. Створення API-first інтеграційного шару: Поверх моноліту розгортається шлюз, який перехоплює зовнішні запити та транслює їх у зрозумілий для legacy-системи формат.
  2. Поетапний декоплінг: Окремі функції виділяються у незалежні модулі, сумісні з ODA. Нові транзакції обробляються вже в cloud-native середовищі, що дозволяє значно прискорити час виходу нових послуг на ринок.
  3. Міграція функцій на SBA: Мережеві функції поступово переносяться з пропрієтарного обладнання на сумісну з 3GPP архітектуру для ядра 5G.

Безпека перехідного періоду та протидія фроду

Перехід до відкритих API та cloud-native середовища змінює ландшафт загроз. Під час гібридного етапу, коли застарілі та нові компоненти працюють паралельно, сигнальний трафік SS7/Diameter потребує жорсткої ізоляції. Цього досягають за допомогою сучасних сигнальних фаєрволів та шлюзів.

Водночас для захисту мікросервісів та API застосовується принцип нульової довіри (Zero Trust). У поєднанні з компонентною архітектурою це дозволяє впроваджувати ефективніші механізми аналізу трафіку та зменшувати ризики фінансових втрат від фроду.

Інтеграційні шари на базі UnityBase для плавного транзиту

У телеком-практиці консорціуму Intecracy модернізація legacy-систем, інтеграція OSS/BSS та побудова транзитних архітектур часто базується на використанні платформи UnityBase. UnityBase — це full-stack JavaScript low-code / model-driven платформа, що є спільною розробкою компаній Intecracy Group (де InBase виступає ключовим, але не єдиним розробником).

Для поетапного переходу телеком-інфраструктури платформа слугує надійним інтеграційним фундаментом. Використовуючи єдину модель метаданих (Domain metadata), UnityBase дозволяє швидко генерувати REST API для зв'язку між legacy-ядром та новими мікросервісами. Це забезпечує безшовну інтеграцію застарілих систем із сучасними цифровими платформами.

Для проєктів із підвищеними вимогами до навантаження та безпеки (що є критичним для телеком-операторів) офіційна документація рекомендує використання комерційних редакцій Enterprise (EE) або Defence (DE). Вони забезпечують вбудовані механізми аудиту дій (audit trail), управління доступом на рівні записів (RLS) та ролей (RBAC), а також можливість розгортання on-premises для повного контролю над критичною інфраструктурою.

Рівні зрілості телеком-інфраструктури при переході до Cloud-Native

Рівень зрілості Опис архітектури Особливості безпеки та інтеграції
Рівень 1: Legacy Monolith Закрите пропрієтарне обладнання, монолітні BSS/OSS. Протоколи SS7/Diameter без вбудованих сучасних механізмів шифрування.
Рівень 2: Hybrid Integration API-first шари поверх моноліту, зв'язок legacy із зовнішніми цифровими сервісами. Базовий моніторинг сигнального трафіку через периметральні шлюзи.
Рівень 3: ODA-Compliant Компонентна архітектура BSS/OSS, модульна взаємодія через відкриті API. Ізоляція застарілих протоколів, шифрування міжсервісного трафіку.
Рівень 4: Cloud-Native (SBA) Повністю мікросервісна архітектура ядра 5G (3GPP). Вбудована безпека (Zero Trust) на рівні API, динамічний захист від фроду.

Поетапна модернізація через впровадження ODA-сумісних компонентів та розгортання надійних інтеграційних шарів дозволяє операторам мінімізувати ризики переривання послуг та створити адаптивну інфраструктуру для стандарту 5G.

Поширені питання

Як модернізувати застарілий телеком-білінг без ризику зупинки транзакцій?

Процес здійснюється за моделлю Strangler Fig. Спочатку створюється паралельний мікросервісний інтеграційний шар для обробки нових запитів. Застаріла система продовжує працювати як джерело історичних даних, доки всі її функції не будуть поетапно перенесені на нові модулі, сумісні з концепцією ODA.

Що таке Open Digital Architecture (ODA)?

ODA — це архітектурний стандарт від TM Forum, який пропонує заміну монолітних BSS/OSS на компонентну екосистему. Модулі в такій архітектурі взаємодіють між собою за допомогою відкритих API, що дозволяє швидко оновлювати сервіси та досягати автономності операцій.

Як захистити мережу від вразливостей SS7 та Diameter під час гібридного етапу?

Для мінімізації ризиків legacy-трафік має бути ізольований. Використовуються спеціалізовані сигнальні шлюзи та фаєрволи, які аналізують вхідні з'єднання. Водночас для нових cloud-native компонентів розгортається архітектура Zero Trust, де кожен API-запит вимагає суворої автентифікації.

Джерела даних