AI-Powered Cooperation for Efficient Networks

ОГЛЯД

Мережі радіодоступу кількох постачальників послуг зв’язку (CSP) часто покривать одні й ті самі зони. Змінюючись протягом дня, трафік користувачів потребує більш різноманітного покриття між CSP. Проект TM Forum “AI-Powered Cooperation for Efficient Networks” спрямований на надання можливості самостійного проектування та розумної взаємодії між мережами радіодоступу (RAN) та іншими мережевими елементами з перекриваючимся покриттям CSP з метою зменшення витрат, підвищення ефективності та допомоги операторам стати більш екологічноими, скоротивши викиди вуглецю.

ЗАВДАННЯ

Головна мета полягала в тому, щоб розробити структуру, яка б використовувала компоненти BSS і OSS для автономного керування та реконфігурації мереж у режимі реального часу для всіх залучених до цього процесу CSP, без зупинки та переривання інших бізнес-операцій. Іншими цілями були мінімізація споживання енергії та максимізація енергоефективності різними операторами мобільних мереж (MNO).

Команда NATEC об’єднала зусилля з Vodafone та Orange, які прагнули вирішити проблему автоматичної комунікації та взаємодії між операторами зв’язку, щоб вибрати одного оператора, який би забезпечував покриття в зонах із тимчасово низькою навантаженістю та автоматично переконфігурував мережі всіх операторів зв’язку. відповідно зменшуючи власне та колективне споживання енергії.

КОМАНДА

• Vodafone та Orange. Лідери проекту та технічні керівники. Вони забезпечували відповідність загальному проекту та створювали сценарії, які відображали реальні мережі з точки зору архітектури та параметрів.
• Comarch. Відповідальний за реалізацію послідовності сценаріїв проекту, підготовку тестів та надання необхідних систем OSS та компонентів штучного інтелекту для виконання проекту.
• NATEC. Задачею було надання компонента “Enterprise Integration” та “Process Flow Management API”, які би повністю відповідали Відкритій цифровій архітектурі TM Forum з метою об’єднання існуючих систем та забезпечення взаємодії між компонентами цих систем, а також надання всієї необхідної підтримки, обслуговування та консультацій для забезпечення безперервного функціонування.
  Для спрощення процесів розробки, підвищення гнучкості і можливості керування всіма елементами та компонентами, ми використали нашу платформу MEF.DEV та її BPMN + Low-Code функціонал. Платформа також слугувала місцем для розміщення функціоналу, що погано вписувалися в інші компоненти, наприклад, графічні інтерфейси менеджменту, додаткова логіка циклів контролю, трансформації між стандартними та нестандартними API, а також інші завдання, спрямовані на спрощення інтеграції.
• Inetum. Відповідальний за впровадження алгоритму “On Guard Tour”, який визначає відповідальних за управлінням мережами радіодоступу CSP та логіку інтеграції, яка мала відповідати стандартам TM Forum.

ВИКЛИКИ

З технічної точки зору, головна проблема полягала у створенні надійної автоматизованої структури для полегшення зв’язків між CSP, що дозволило би їм синхронізувати свою діяльність щодо розподілення зон покриття та забезпечило безперервне обслуговування абонентів. Ці задачі слугують тригерами для повністю автоматизованого перепроектування мережі, включаючи увімкнення та вимкнення об’єктів, що керуються RAN, адаптацію базової мережі до зміненої топології RAN і налаштування з’єднання, при цьому постійно оптимізуючи дизайн мережі та ефективно розподіляючи ресурси на стратегічні цілі, що представлені кількома критеріями оптимізації. З точки зору експлуатації, головним завданням була ефективна реконфігурація мережі відповідно до взаємно узгодженого покриття території та розподілу відповідальності, а також дотримання політики кожного з CSP. З комерційної точки зору, головною перешкодою було дотримання єдиних процедур обліку та виставлення рахунків між CSP, що робить розподіл відповідальності за охоплення території комерційно вигідним для всіх учасників і відповідає нормативним вимогам.

РІШЕННЯ

Стратегія полягала в тому, щоб зменшити споживання енергії шляхом вибіркової деактивації компонентів RAN у періоди зниження попиту, повністю або частково. Такий підхід призводить до значної економії електроенергії. Крім того, він включає в себе комплексну реконструкцію мережі, яка містить у собі не тільки RAN, але й основну інфраструктуру 5G. Ця реконфігурація адаптується до нових стратегічними вимог, які визначають, коли і де саме мережа RAN має бути активною або неактивною.
Запропоноване рішення базується на використанні різноманітних систем та компонентів, включаючи програмне забезпечення, яке інтегрує, контролює та маніпулює всіма доступними даними та вчасно звітує про отриманий результат.

КОМПОНЕНТИ СИСТЕМИ

1. On-Guard Tour. Це алгоритм прийняття рішень, який розподіляє відповідальність за охоплення певних зон RAN між операторами для максимізації енергоефективності.
2. Enterprise Integration Layer, наданий платформою MEF.DEV.
3. OSS Web-Console. Керуючий елемент, який уніфікує вигляд мережі в різних формах та надає інформацію про стан мережі, її механізми управління та операції обслуговування.
4. Resource Catalog. Головний репозиторій для інформаційних моделей, шаблонів та оркестрації активів.
5. E2E Orchestrator. Перекладає наміри для мережі в набір відповідних операцій.
6. Performance Management. Надає прогнозований попит на зону покриття разом із інформацією про поточне енергоспоживання через систему KPI.
7. Dynamic Resource Inventory. Представляє мережу кожного CSP на основі необробленої інформації з різних джерел.
8. MIRA. Алгоритм прийняття рішень на основі штучного інтелекту, який відповідає за проектування мережі та розподіл ресурсів.
9. Kafka і Nifi. Інструменти інтеграції для взаємодії між компонентами архітектури на основі івентів.

РОБОЧИЙ ПРОЦЕС

Як показано на схемі вище, робочий процес складається з наступних кроків:

Крок 0: два або більше CSP укладають угоду про співпрацю відповідно до закону про національне регулювання, щоб розділити відповідальність за надання послуг абонентам в узгоджених географічних зонах у періоди низького попиту.

Крок 1: оператори надають свої очікування попиту для кожної зони покриття, включаючи приблизну кількість активного обладнання користувача та його пропускну здатність. Модуль Enterprise Integration відбирає області з низьким попитом для On-Guard Tour на основі попередньо визначеного порогу та надає поточні дані про споживання енергії в цих районах і досягнуту економію.

Крок 2: Модуль On-Guard Tour визначає розподіл відповідальності для зон із низьким попитом, призначаючи одного з операторів «на варті». Інші оператори припиняють надавати покриття RAN у областях, де вони не виконують цю роль.

Крок 3: Новий розподіл обов’язків передається до модулю Resource Order Management (ROM) як зміна наміру. Це визначає, які області слід увімкнути або вимкнути для даного оператора в найближчий період, а які оптимізувати для покращення енергоефективнрсті. Задача оркестратора полягає в тому, щоб відповідним чином оновити мережу, увімкнувши/вимкнувши елементи RAN (наприклад, зони покриття окремих базових станцій та gNodeB) та переконфігурувати транспортну та базову мережу відповідно до змінених вимог покриття RAN.

Крок 4: ROM зв’язується з Resource Catalog, щоб отримати важливу інформацію, включаючи шаблон оркестрації, специфікації мережевого елемента/xNF та інформаційну модель, що описує задіяні мережеві об’єкти. Він також завантажує відповідні артефакти оркестрації.

Крок 5: ROM отримує поточний стан мережі від Resource Inventory, охоплюючи топологію мережі (від низькорівневої інфраструктури до логічної топології та фрагментів) та поточну конфігурацію мережевих елементів, включаючи адміністративні та робочі зон покриття базових станцій та gNB. Він поєднує цю інформацію для створення нової конфігурації та топології мережі, яка відображає оновлений намір. Це призводить до проміжної, неоптимальної конструкції мережі.

Крок 6: Дизайн і глобальні наміри щодо змін, включно з цілями оптимізації, передаються в MIRA, яка відповідає за визначення їх подальшої реалізації в мережі. MIRA поєднує проект із наявною інфраструктурою, використанням ресурсів і даними про ефективність, технологічними обмеженнями та планами оптимізації, щоб створити комплексний проект, включаючи плани розгортання та маршрутизації для всіх елементів у вхідній топології.

Крок 7: ROM готує багатофазовий план оркестрації для реалізації остаточного проекту мережі. Він визначає необхідні операції над керованими об’єктами, визначає їхній порядок та готує блоки оркестрації та необхідні активи. ROM виконує сценарій end-to-end оркестрації та оновлює відповідні задіяні ресурси.

Крок 8: Модуль Resource Performance Management постійно відстежує зміни в топологіях і конфігураціях, забезпечуючи адаптацію до нової ситуації за допомогою розрахунків енергоспоживання та інших KPI.

Потім вищеописаний процес повторюється, але вже з новими прогнозами попиту на наступний період, наданими системою Performance Management, ініціюючи наступну ітерацію замкнутого циклу. Після завершення розрахунків інформація про споживання енергії та оновлені значення попиту стають доступними для Enterprise Integration для подальшої обробки.

ВНЕСОК КОМАНДИ NATEC

Платформа MEF.DEV зробила значний внесок в успіх проекту Catalyst, надаючи необхідний функціонал для досягнення цілей та завдань проекту.

1. Можливості Enterprise Integration забезпечили безперебійний зв’язок та обмін даними між кількома мережевими системами та їх компонентами, таким чином виводячи мережеву оркестрацію на новий рівень, забезпечуючи ефективний зв’язок і обмін даними між різними частинами мережі.

2. Process Flow Management API допоміг керувати потоком даних, забезпечуючи безперервне та ефективне виконання кожного кроку робочого процесу. Це сприяло автоматизації та оркестрації процесів, зменшуючи потребу в ручному втручанні.

3. Можливості BPMN у поєднанні з Low-Code платформи MEF.DEV спростили процеси розробки в рамках проекту. Це підвищило гнучкість існуючих систем, зробивши їх більш чутливими до змін умов мережі. Ця гнучкість дозволила швидко розробляти та розгортати мережеві служби та програми, підвищуючи загальну ефективність проекту.

4. Враховуючі відсутність попередньо визначених технічних вимог, платформа MEF.DEV стала своєрідним хабом співпраці для всіх залучених команд розробників та забезпечила їм чіткий, логічний і зрозумілий спосіб взаємодії для ефективного об’єднання компонентів разних модулів та системи в єдину систему за допомогою підходу BPMN + Low-Code. Такий підхід дозволив розробити, протестувати та розгорнути всі необхідні мережеві служби та задіяні процеси бізнес-логіки, а також адаптувати їх до постійно змінюємих вимог мережі.