Мережі без ланцюжків: перехід до автономних операцій на основі намірів – блог IBM

Телекомунікаційна галузь, наріжний камінь глобального зв’язку, вже деякий час переживає технологічний ренесанс, який спонукають такі інновації, як 5G, IoT, хмарні обчислення та ШІ. У результаті керувати мережами стає дедалі важче. Існує потреба в автоматизації для виконання рутинних завдань, моніторингу стану мережі та реагування на проблеми в режимі реального часу. Проте існуючі навички постачальників послуг зв’язку (CSP) можуть не відповідати мінливим вимогам цього динамічного середовища. Щоб досягти успіху в сучасну епоху, провайдерам послуг потрібні різноманітні команди, включаючи фахівців з обробки даних для інтерпретації даних і операцій, розробників програмного забезпечення для автоматизації через інтерфейси прикладного програмування постачальників (API) та інженерів із забезпечення обслуговування для проектування замкнутих циклів для забезпечення надійності обслуговування.

У той час як CSP усувають розрив, створюючи команди з різноманітним досвідом, вони також одночасно отримують вигоду від значного прогресу в одночасній тенденції. Мови програмування еволюціонували до парадигм з низьким кодом/без коду, і з появою генеративного штучного інтелекту ми досягли точки, коли базові моделі можуть генерувати формальний код на основі описів завдань природною мовою. Це дало новий погляд на концепцію мережа на основі намірів (IBN), де люди-адміністратори висловлюють мережеві цілі високого рівня природною мовою, відомою як «наміри», і що ці наміри людини автоматично перетворюються на мережеві політики та конфігурації. IBN має потенціал для покращення управління мережею та може стати кардинальним фактором у подоланні нестачі кадрів у телекомунікаційних компаніях. Роблячи крок далі, автономні мережі (AN) обіцяють використовувати наміри як вхідні дані для автономного самоналаштування, самооптимізації та самовідновлення мереж у міру розвитку їх умов.

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

Мотиваційний випадок: впровадження нових послуг без намірів

Щоб зрозуміти потребу в оптимізації взаємодії між командами CSP і мережею, ми використаємо розгортання нового сервісу як приклад.

Ми припускаємо, що робота мережі CSP автоматизована відповідно до специфікацій, викладених у Вступний посібник TMF 1230 (IG1230) щодо технічної архітектури автономних мереж. У цьому контексті OSS CSP має (1) координатора для надання послуг, автоматизованого надання та автоматизованого тестування, (2) систему гарантії з інвентаризацією мережі, яка збирає дані, створює уявлення про стан мережі та, отже, полегшує прийняття рішень на основі даних у контексті замкнутого контролю та (3) менеджер політики, який керує поведінкою мережі, використовуючи попередньо визначені політики, забезпечуючи узгодження з ширшими політиками CSP. У двох словах, автоматизовані операції обертаються навколо тісного зв’язку служб із призначеними для них дескрипторами служб TOSCA, конфігураціями, політиками та обов’язковими робочими процесами, в які розробники послуг додають інтелектуальні дані та прийняття рішень під час проектування. Розробники сервісів повинні завчасно передбачати широкий спектр умов, які можуть виникнути в мережі, і надавати детальні інструкції про те, як їх потрібно вирішувати — досвід нульового дотику досягається, якщо майбутні умови передбачені та існують політики для їх вирішення.

Ми використовуємо терміни День 0, День 1 і День 2 для різних етапів життєвого циклу служби, а саме сервісний дизайн, екземпляр служби та гарантія обслуговування, відповідно.

• Проектування сервісу включає в себе розробку різноманітних активів сервісу, як показано на малюнку 1. Це завдання групи проектувальників сервісу, яка має зрозуміти операції першого та другого дня сервісу та створити необхідні робочі процеси та сценарії. Червоні лінії на малюнку 1 зображують процес надання нової послуги, що гарантує, що послугу можна замовити.

• Створення екземпляра послуги відбувається, коли надходить замовлення на послугу після запиту абонента. Сьогодні в CSP замовлення на обслуговування зазвичай надходить через інтерфейс TMF 641 від диспетчера замовлення на обслуговування (SOM). Коли оркестратор служби отримує замовлення на послугу, він гарантує, що робочі процеси виконуються, а запитані конфігурації моніторингу, моделі PM/FM і політики розгорнуті та запущені. Ми показуємо екземпляр служби на малюнку 2 зеленими лініями.

• Гарантія обслуговування базується на підході замкнутого циклу, коли умови розгорнутих служб піддаються постійному моніторингу та автоматизованим діям життєвого циклу. На малюнку 2 блакитними лініями ми показуємо надійний замкнутий цикл.

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

Що таке наміри?

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

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

Перспективи ІБН та АН

Далі ми надаємо деякі з аспектів, у яких наміри потенційно можуть революціонізувати усталені практики з епохи до намірів:

• Операції дня 0:
  • Підготовка до нових послуг – Використовуйте генеративний штучний інтелект для обробки вхідних даних природною мовою для автономного доповнення вимог до послуг.
  • Впровадження нових послуг – Визначайте нові послуги за допомогою природної мови, наприклад «забезпечте індивідуальне рішення підключення для безпечного зв’язку в установах охорони здоров’я» або «ввімкніть зв’язок пристроїв Інтернету речей через інфраструктуру розумного міста» та використовуйте генеративний ШІ для автоматичного створення необхідних сервісних активів.
  • Автоматизована генерація драйверів ресурсів постачальника– Використовуйте генеративний штучний інтелект для створення специфічних драйверів ресурсів постачальника на основі документації постачальника.
• Операції дня 1:
  • Спрощення замовлення обслуговування – Дозволяє клієнтам запитувати послуги за допомогою природної мови. Цей зручний підхід дає змогу замовляти нові послуги, наприклад змішувати та поєднувати пропозиції з каталогу.
  • Перевірки здійсненності – Спрощує перевірки підтвердження, коли клієнти висловлюють свої наміри, ефективно оцінюючи критичні фактори, такі як доступність оптоволоконної лінії. Результатом є зменшення навантаження на мережевих інженерів, швидша перевірка сервісу та більш гнучке та оперативне розгортання.
• Операції дня 2:
  • Динамічне забезпечення обслуговування – Дозволяє мережам розумно реагувати на зміни умов і потреб користувачів. Гнучкі політики на основі намірів підвищують гнучкість, забезпечуючи надійність у реальному часі та оперативність мережевих служб.

Проблеми з IBN та AN

Є дві основні проблеми, які необхідно вирішити:

1. Як висловити і передати намір?
2. Як виконати намір: як виглядає обробник намірів?

TM Forum представила мережевий API на основі намірів TMF921, який пропонує структуровану структуру для визначення мережевих намірів високого рівня. TM Forum визначає намір таким чином: «Намір — це формальна специфікація всіх очікувань, включаючи вимоги, цілі та обмеження, надані технічній системі”. Проте частина формальна специфікація викликає занепокоєння: мережевим інженерам потрібно буде ознайомитися з цією формальною мовою, щоб використовувати весь потенціал концепції наміру. Більше того, наміри з формальною специфікацією не обов’язково зменшують кількість параметрів, які мають бути надані з ними. Цей аспект кидає виклик очікуваній оптимізації управління мережею, яку зазвичай асоціюють з IBN.

Крім того, шляхом формалізації специфікації намірів, обробник намірів, основний компонент IBN, який містить логіку інтерпретації намірів, стає просто детермінованим інтерпретатором формальної мови намірів. Виникає питання про те, як ми перетворимо обробник намірів на автономну систему з декларативним способом роботи, де людям не потрібно передбачати кожну потенційну умову мережі та надавати конкретні інструкції для її вирішення. Інакше робота системи не може успішно перейти від автоматизованої до автономної (TMF IG1230).

У наступних блогах ми більш детально розглянемо проблеми та можливості IBN та AN. Хочете дізнатися більше? Зв'яжіться з нами за адресою maja.curic@ibm.com, chris.van.maastricht@nl.ibm.com та tmtattis@ae.ibm.com.

Перетворення для майбутнього
з телекомунікаціями