Сучасні телеком-оператори переходять від монолітних систем до модульної архітектури, щоб прискорити впровадження інновацій та підготуватися до автономних мереж. Проте на цьому шляху виникає серйозна перешкода: спроби інтегрувати нові хмарні сервіси із застарілими (legacy) BSS/OSS обмежують гнучкість бізнесу, сповільнюють запуск нових тарифів та знижують ефективність управління мережею. Операторам доводиться шукати баланс між стабільністю наявної інфраструктури та інноваційністю cloud-native рішень.
Анатомія моноліту: чому класична зв'язка BSS/OSS гальмує розвиток оператора
Історично архітектура оператора зв'язку ділилася на два великі та майже ізольовані блоки: Business Support Systems (BSS), що відповідають за роботу з клієнтами, білінг, тарифікацію та продажі, та Operations Support Systems (OSS), які керують ресурсами мережі, моніторингом, конфігуруванням та усуненням несправностей. Зв'язок між ними зазвичай будувався за допомогою пропрієтарних конекторів від конкретних вендорів.
Монолітна архітектура минулих поколінь жорстко пов'язує бізнес-логіку з операційними процесами, створюючи залежність від постачальників та ускладнюючи масштабування мережевих функцій. Будь-яка зміна в тарифікації або запуск нового пакета послуг вимагає каскадних змін у суміжних системах. Окрім низької швидкості виходу на ринок (time-to-market), утримання застарілих систем без наскрізного аудиту доступу поглиблює ризики кібербезпеки. Цифрова інфраструктура та сервіси становлять близько 27.7% усіх витоків даних серед постраждалих організацій, що вимагає переходу до захищених архітектурних моделей.
Перехід до Open Digital Architecture (ODA): декомпозиція систем на практиці
Для подолання обмежень моноліту індустрія керується концепцією Open Digital Architecture (ODA) від TM Forum. ODA замінює монолітні BSS/OSS на компонентну, API-first архітектуру, що є ключовим для переходу до автономних мереж. Замість закритих систем оператор отримує набір стандартизованих програмних компонентів, які взаємодіють через відкриті інтерфейси.
Практичним прикладом такого підходу є впровадження Open APIs для інтеграції між різними бізнес-доменами оператора (наприклад, між фронтендом для клієнтів та системами білінгу чи оркестрації мережі). Це дозволяє абстрагувати бізнес-логіку від технічних деталей реалізації мережі. Коли клієнт замовляє послугу, система надсилає стандартизований API-запит до ядра, не потребуючи прямого доступу до протоколів мережевого обладнання.
Cloud-Native та Service-Based Architecture: як стандарти 3GPP змінюють ядро мережі
Паралельно з трансформацією IT-систем еволюціонує і ядро телеком-мережі (Core). Згідно зі стандартами консорціуму 3GPP, архітектура сучасних мереж будується на принципах Service-Based Architecture (SBA). Архітектура 5G core (service-based) максимально наближає телеком-операторів до cloud-native принципів роботи.
Міграція ядра мережі на хмарні технології згідно зі стандартами 3GPP для підтримки 5G Standalone дозволяє операторам гнучко керувати ресурсами, розгортаючи мережеві функції як незалежні сервіси. Важливо розуміти, що 5G не є єдиним стандартом або миттєвим рішенням для всіх — еволюція мереж залежить від конкретних релізів 3GPP та індивідуальної стратегії міграції кожного оператора.
Інтеграційний виклик: поєднання legacy-протоколів із сучасними API-first платформами
Найскладнішим етапом модернізації є побудова містка між застарілою інфраструктурою (включаючи softswitch, BSS/OSS) та новим хмарним ядром. Оскільки відмовитися від старих систем одномоментно неможливо, виникає потреба в надійному проміжному інтеграційному шарі.
Модернізація legacy OSS та проектування хмарної телеком-інфраструктури успішно реалізується силами команд технологічного альянсу Intecracy Group (зокрема рішеннями компанії IQusion, що спеціалізується на телеком-секторі). Технологічною основою для побудови такого інтеграційного шару виступає платформа UnityBase. Це спільна розробка компаній Intecracy Group, де InBase є ключовим, але не єдиним розробником.
Завдяки використанню механізмів платформи UnityBase, таких як єдина Domain metadata-модель, автоматично згенеровані REST APIs та вбудовані підсистеми аудиту (audit trail), оператори отримують можливість швидко створювати гнучкі шини даних. Вони поєднують логіку застарілих систем із сучасними API-контрактами. Для телеком-систем із високим навантаженням або підвищеними вимогами до безпеки офіційна документація платформи рекомендує використовувати комерційні редакції Enterprise або Defence, які підтримують розширені механізми контролю доступу (RLS, ACL) та промислові СУБД.
Безпека перехідного періоду: захист сигнальних каналів при модернізації
Перехідний період, коли оператор одночасно експлуатує хмарні сервіси та застарілу інфраструктуру, створює додаткові вектори для кібератак. За даними звіту ENISA Threat Landscape 2025, експлуатація застарілих сигнальних протоколів, таких як SS7 та Diameter, залишається суттєвим ризиком для безпеки мобільних мереж.
Крім того, за оцінками дослідження CFCA Global Fraud Loss Survey 2025, глобальні втрати від телеком-шахрайства у 2025 році оцінюються приблизно у 41.82 мільярда доларів. Це змушує операторів інтегрувати механізми автентифікації безпосередньо в архітектуру систем, зокрема для боротьби з підміною номерів у голосових мережах.
Слід пам'ятати, що впровадження стандарту ODA автоматично не усуває всі ризики кібербезпеки — це насамперед архітектурний фреймворк. Для захисту сигнальних каналів та API оператори повинні впроваджувати моделі Zero Trust, сувору автентифікацію мікросервісів та наскрізний аудит дій.
Рівні зрілості телеком-архітектури при переході до Cloud-Native
Для оцінки поточного стану інфраструктури та планування міграції оператори можуть спиратися на таку шкалу технологічної зрілості:
- Рівень 1: Монолітний. Жорстко зв'язані BSS/OSS, пропрієтарні інтерфейси, фізична інфраструктура.
- Рівень 2: Гібридний. Часткова віртуалізація функцій, впровадження API для окремих нових сервісів.
- Рівень 3: Сервісно-орієнтований. Компонентна архітектура ODA, використання Open APIs, контейнеризація.
- Рівень 4: Автономний / Cloud-Native. Повністю хмарне ядро 3GPP SBA, автоматичне масштабування, наскрізна оркестрація.
Поступова декомпозиція моноліту за принципами ODA, перехід до сервісно-орієнтованої архітектури ядра та впровадження стандартизованих інтеграційних платформ дозволяють телеком-операторам забезпечити гнучкість бізнесу та надійно захистити свою мережу від сучасних загроз.
Поширені питання
Що таке TM Forum Open Digital Architecture (ODA) і які її переваги для оператора?
TM Forum ODA — це концепція, яка замінює монолітні BSS/OSS на компонентну, API-first архітектуру. Вона дозволяє абстрагувати бізнес-логіку від технічних деталей мережі, що прискорює впровадження інновацій, зменшує залежність від одного вендора та є ключовим етапом переходу до автономних мереж.
Як інтегрувати застарілі BSS/OSS системи з новими хмарними 5G-компонентами?
Для цього розгортають проміжний інтеграційний шар, який транслює застарілі протоколи у сучасні стандартизовані API-контракти. Ефективним підходом є використання low-code платформ, таких як UnityBase, що забезпечують єдину метамодель даних, автоматичну генерацію REST APIs та надійний аудит транзакцій.
Які ризики безпеки виникають при одночасному використанні legacy-протоколів та хмарних API?
Згідно з даними ENISA, головним ризиком залишається експлуатація застарілих сигнальних протоколів (SS7, Diameter). Для мінімізації загроз необхідно впроваджувати принципи Zero Trust, надійні механізми автентифікації для запобігання підміні номерів та використовувати спеціалізовані рішення для захисту API.