Зі зростанням кількості розгортань приватних мереж 5G Standalone (SA) перед архітекторами корпоративного зв'язку постало завдання об'єднання нової мобільної інфраструктури з наявними VoIP-мережами. За даними звіту Ericsson Mobility Report 2025, понад 90 операторів уже запустили або знаходяться на стадії soft-launch 5G Standalone. Мета інтеграції на рівні підприємства — не просто забезпечити фізичний зв'язок між доменами, а створити єдиний контур маршрутизації за найменшою вартістю (Least Cost Routing, LCR) та уніфікованого білінгу.
Без архітектурної конвергенції підприємство отримує дві ізольовані системи. Це призводить до фрагментації білінгових даних, складнощів у керуванні трафіком та критичних вразливостей в ідентифікації абонентів на стику технологій. Головна проблема криється в несумісності сигнальних та білінгових протоколів: традиційні SIP-системи використовують статичні транки та генерують офлайнові CDR-файли, тоді як 5G Core вимагає тарифікації в реальному часі та працює на базі HTTP/2 REST APIs.
Анатомія розриву: чому legacy SIP-ядро не розуміє мову 5G Standalone
Проблема інтеграції полягає у кардинальній різниці архітектурних підходів. Традиційні корпоративні VoIP-мережі побудовані на протоколі SIP (RFC 3261), який працює через UDP або TCP. Маршрутизація сесій у таких мережах спирається на статичні IP-адреси або централізовані SIP-проксі.
Натомість ядро 5G Standalone (5G Core) спроєктоване за сервісно-орієнтованою архітектурою (Service-based Architecture, SBA), стандартизованою 3GPP. Усі мережеві функції (NF) у 5G Core взаємодіють як мікросервіси через HTTP/2 REST APIs. Замість звичних SIP-транків використовується динамічна реєстрація сервісів (NRF). Коли legacy-система очікує стандартного обміну повідомленнями INVITE/OK/ACK, 5G-ядро вимагає взаємодії з функціями керування сесіями (SMF) та користувацьким планом (UPF).
Без проміжного конвергентного шлюзу пряма сигнальна взаємодія неможлива, що блокує наскрізний LCR та знижує загальну якість обслуговування (QoS).
Архітектура конвергентного LCR: об'єднання 5G та фіксованого VoIP
Least Cost Routing у гібридному середовищі має враховувати не лише тарифи зовнішніх PSTN-провайдерів, а й доступність локальних 5G-ресурсів. Для реалізації такого LCR необхідно налаштувати транкінг між 5G-ядром та корпоративним VoIP-комутатором (softswitch). У стандартах 3GPP ця взаємодія зазвичай забезпечується через підсистему IMS або спрощені шлюзи MGCF/IP-SM-GW.
На практиці це працює так: коли абонент із 5G-смартфоном набирає зовнішній міський номер, LCR-модуль аналізує маршрути. Замість виходу через комерційну мережу мобільного оператора, виклик спрямовується через локальний SIP-транк корпоративної АТС у міську мережу за значно нижчим тарифом. Для ефективної роботи модуль повинен підтримувати динамічний аналіз MNP (Mobile Number Portability) та визначати оптимальну точку виходу в реальному часі.
Уніфікація білінгу: перехід від CDR до real-time тарифікації
Традиційний корпоративний VoIP-білінг є офлайновим: після завершення сесії генерується файл CDR (Call Detail Record), який пізніше обробляється білінговою системою. Проте стандарти 5G Core вимагають застосування функції тарифікації в реальному часі (Charging Function, CHF) та конвергентної системи (CCS). Це зумовлено тим, що обсяги транзакцій різко зростають: масштабування 5G-підписок очікується на рівні 6.4 мільярда до кінця 2031 року (за прогнозами Ericsson), що включає також величезну кількість IoT-пристроїв.
Вирішенням є впровадження принципів TM Forum Open Digital Architecture (ODA). Перехід до компонентованої, API-first архітектури дозволяє об'єднати білінг. Згідно зі спостереженнями з інтеграційних проєктів, близько 53.7% організацій стикаються зі складнощами синхронізації білінгових циклів між доменами, а до 27.7% бюджету впровадження може йти на кастомізацію legacy-інтерфейсів без використання Open APIs. Real-time білінг дозволяє обробляти як 5G-трафік, так і SIP-виклики в єдиному циклі, миттєво реагуючи на вичерпання лімітів корпоративних користувачів.
Безпека на стику середовищ: автентифікація викликів (RFC 8224)
Приватне ядро 5G забезпечує високий ступінь захисту (3GPP AKA, шифровані SUCI). Однак при виході виклику в SIP-домен виникає ризик підміни номера (Caller ID spoofing). Проблема автентифікації джерел є критичною: очікується, що глобальні втрати від телеком-шахрайства сягнуть 41.82 мільярда доларів у 2025 році.
5G не вирішує проблему безпеки VoIP-транків автоматично. Надійним архітектурним підходом є застосування стандарту RFC 8224 (Authenticated Identity Management in SIP). При маршрутизації виклику з 5G в корпоративний контакт-центр прикордонний контролер (SBC) генерує криптографічний підпис та розміщує його в заголовку Identity SIP-запиту. Платформа-одержувач верифікує цей підпис. Якщо валідація успішна, система гарантує, що номер ініціатора є справжнім, що мінімізує ризики соціальної інженерії.
Проєктування цільової архітектури: перехід до конвергентного ядра
Щоб подолати розрив між SIP та SBA, підприємствам необхідна проміжна інфраструктура з підтримкою трансляції протоколів. Одним із таких рішень є операторська VoIP-платформа DooxSwitch — розробка з портфеля технологічного альянсу Intecracy Group. Рішення працює як високопродуктивний softswitch з API-driven LCR-модулем та вбудованим білінгом реального часу, дозволяючи тарифікувати сесії за принципами CHF/CCS.
Для обробки великих масивів даних, складних інтеграцій та забезпечення суворого контролю доступу платформа може спиратися на механізми UnityBase (low-code платформа є спільною розробкою компаній Intecracy Group; InBase виступає ключовим, але не єдиним розробником). UnityBase надає інструменти RBAC/RLS, глибокий аудит (audit trail) та можливість автоматичної генерації REST APIs для прозорої інтеграції між телеком-ядром та зовнішніми корпоративними BSS-системами.
| Критерій порівняння | Legacy VoIP (SIP) | 5G Core (SBA) | Конвергентне рішення (DooxSwitch) |
|---|---|---|---|
| Протокол сигналізації | SIP (RFC 3261) через UDP/TCP | HTTP/2 REST APIs (JSON) | Конвергентний шлюз із трансляцією протоколів |
| Метод тарифікації | Офлайн-обробка CDR-файлів | Real-time Charging (CHF/CCS) | Єдиний BSS-контур через TM Forum Open APIs |
| Ідентифікація та безпека | Простий Caller ID (P-Asserted) | 3GPP AKA та шифровані SUCI | Криптографічний підпис SIP Identity (RFC 8224) |
| Керування LCR | Статичні таблиці в Softswitch | Динамічний вибір сервісів (NRF) | API-driven LCR з підтримкою MNP |
Успішний перехід до конвергентної телефонії потребує аудиту наявних SIP-інфраструктур, розгортання API-шлюзів для взаємодії з 5G Core та обов'язкового налаштування криптографічної верифікації викликів для усунення вразливостей на стику двох доменів.
Поширені питання
Як налаштувати LCR між корпоративною АТС та приватною мережею 5G Standalone?
Налаштування виконується шляхом створення транку між корпоративним конвергентним softswitch та шлюзом (наприклад, MGCF/IP-SM-GW) у 5G Core. LCR-модуль аналізує маршрути в реальному часі, скеровуючи виклики найефективнішим шляхом для уникнення зайвих витрат на інтерконект.
Які вимоги висуває 3GPP до інтеграції зовнішніх SIP-транків у 5G Core?
3GPP вимагає дотримання принципів Service-based Architecture (SBA). Зовнішня сигналізація SIP повинна транслюватися в HTTP/2 REST APIs за допомогою медіа- та сигнальних шлюзів для забезпечення взаємодії з функціями керування сесіями (SMF).
Як реалізувати real-time білінг для 5G-абонентів, що використовують корпоративний VoIP-шлюз?
Це досягається шляхом інтеграції корпоративної BSS-системи через TM Forum Open APIs. Завдяки цьому VoIP-дзвінки та 5G-сесії даних тарифікуються синхронно через єдину функцію тарифікації (CHF/CCS), що дозволяє керувати лімітами в реальному часі.