Liberare le reti: il passaggio a operazioni autonome basate sugli intenti

Da qualche tempo il settore delle telecomunicazioni, pietra miliare della connettività globale, sta attraversando una rinascita tecnologica guidata da innovazioni come 5G, IoT, cloud computing e AI. Di conseguenza, la gestione delle reti è diventata sempre più difficile. Per gestire le attività di routine è necessario implementare l'automazione, monitorare la salute della rete e rispondere ai problemi in tempo reale. Tuttavia, le competenze esistenti all'interno dei fornitori di servizi di comunicazione (CSP) potrebbero non essere in linea con le esigenze in evoluzione di questo panorama. Per avere successo nell'era moderna, i CSP hanno bisogno di team versatili, tra cui data scientist per l'interpretazione e le operazioni dei dati, sviluppatori di software per l'automazione tramite application programming interface (API) dei fornitori e service assurance engineers per la progettazione di a loop chiuso per garantire l'affidabilità del servizio.

I CSP colmano il divario creando team con esperienze diverse, ma beneficiano anche dei notevoli progressi di una tendenza concomitante. I linguaggi di programmazione si sono evoluti verso paradigmi low-code/no-code e, con l'emergere dell'AI generativa, ci troviamo a un punto in cui i foundation model possono generare codice formale basato sulle descrizioni in linguaggio naturale delle attività. Ciò ha dato una nuova prospettiva al concetto di reti basate sugli intenti (IBN), in cui gli amministratori umani esprimono obiettivi di rete di alto livello in un linguaggio naturale, noti come "intenti", e questi intenti umani vengono tradotti automaticamente in politiche e configurazioni di rete. L'IBN ha il potenziale di migliorare la gestione della rete e potrebbe diventare un punto di svolta nel colmare la mancanza di talenti all'interno delle società di telecomunicazioni. Facendo un ulteriore passo avanti, le reti autonome (AN) promettono di utilizzare gli intenti come input per auto-configurare, ottimizzare e riparare autonomamente le reti man mano che le loro condizioni si evolvono.

Sebbene possiamo immaginare un futuro brillante sia per l'IBN che per le AN, ci sono persistenti preoccupazioni sulla loro fattibilità e sulle applicazioni del programma, tra cui l'espressione degli intenti, la traduzione accurata della configurazione di rete, la trasparenza e la complessità del sistema. In questo blog, approfondiremo le aree in cui la loro applicazione pratica ha più potenziale e analizzeremo le sfide che potrebbero incontrare lungo il percorso.

Per comprendere la necessità di semplificare le interazioni tra i team di CSP e la rete, utilizzeremo come esempio una nuova distribuzione di servizi.

Partiamo dal presupposto che il funzionamento della rete CSP sia automatizzato secondo le specifiche delineate nella guida TMF Introductory Guide 1230 (IG1230) on Autonomous Networks Technical Architecture. In tale contesto, l'OSS del CSP dispone di (1) un orchestratore per la fornitura di servizi, il provisioning automatizzato e i test automatizzati, (2) un sistema di garanzia con inventario che raccoglie i dati, crea insight sullo stato della rete e facilita il processo decisionale basato sui dati nel contesto del controllo a loop chiuso e (3) un gestore delle politiche che guida il comportamento della rete utilizzando criteri predefiniti, garantendo l'allineamento con le politiche del CSP più ampie. In poche parole, le operazioni automatizzate ruotano attorno a uno stretto collegamento dei servizi con i descrittori di servizio TOSCA progettati dall'uomo, le configurazioni, le politiche e i workflow in cui l'intelligenza e il processo decisionale vengono aggiunti dai designer di servizi in fase di progettazione. I designer di servizi devono prevedere in modo proattivo un'ampia gamma di condizioni che possono verificarsi nella rete e fornire istruzioni dettagliate su come affrontarle: purché siano state previste le condizioni future e ci siano politiche per gestirle, si ottiene un'esperienza zero touch.

Utilizziamo i termini Giorno 0, Giorno 1 e Giorno 2 per diverse fasi del ciclo di vita del servizio, vale a dire rispettivamente la progettazione del servizio, l'istanziazione del servizio e la garanzia del servizio.

• La progettazione dei servizi comprende lo sviluppo di vari asset di servizio, come illustrato nella Figura 1. Questo è il compito del team di progettazione del servizio, che deve comprendere le operazioni di Giorno 1 e Giorno 2 e produrre il workflow e gli script richiesti. Le linee rosse nella Figura 2 descrivono il processo di fornitura di un nuovo servizio, per assicurare che possa essere ordinato.

Figura 1: Processo di progettazione del servizio, Giorno 0 – Progettazione degli asset di servizio

• L'istanziazione del servizio avviene quando l'ordine di servizio arriva a seguito di una richiesta di abbonato. Oggi, nei CSP, l'ordine di servizio arriva in genere tramite l'interfaccia TMF 641 dal gestore degli ordini di servizio (SOM). Quando l'orchestratore riceve l'ordine di servizio, garantisce che i workflow vengano eseguiti e che le configurazioni di monitoraggio richieste, i modelli e le politiche PM/FM siano distribuiti e funzionanti. Nella Figura 2 mostriamo l'istanza del servizio tramite linee verdi.

• La garanzia del servizio segue un approccio a loop chiuso in cui le condizioni dei servizi implementati sono sottoposte a monitoraggio continuo e ad azioni automatizzate sul ciclo di vita. Nella Figura 2 mostriamo il loop chiuso di garanzia tramite linee blu.

Figura 2: Interazioni Giorno 0/Giorno 1/Giorno 2

In sintesi, è la fase di progettazione a comportare una notevole mole di lavoro manuale, in quanto è necessario fornire alla rete le istruzioni per il nuovo servizio.

Nell'IBN, con "intenti" facciamo riferimento agli obiettivi di alto livello che il CSP vuole raggiungere nella sua rete. Invece di occuparsi di configurazioni di rete complesse di basso livello durante le operazioni del Giorno 0, come discusso sopra, i team di ingegneri esprimono gli obiettivi con gli intenti, e la logica alla base degli intenti li traduce nella configurazione di rete richiesta in grado di soddisfarli.

Dopo l'applicazione delle configurazioni alla rete, l'AN monitora continuamente i servizi implementati e adatta la configurazione per garantire che l'operazione rimanga in linea con gli intenti specificati. L'AN estende l'uso delle finalità alle operazioni del Giorno 2.

A seguire, forniamo alcuni degli aspetti in cui gli intenti potrebbero potenzialmente rivoluzionare le pratiche consolidate dell'era pre-intenti:

• Operazioni di routine
  • Preparazione per nuovi servizi: utilizza l'AI generativa per elaborare l'input in linguaggio naturale e integrare in modo autonomo i requisiti del servizio.
  • Introduzione di nuovi servizi: definisci nuovi servizi utilizzando il linguaggio naturale, ad esempio "fornisci una soluzione di connettività su misura per comunicazioni sicure all'interno delle istituzioni sanitarie" o "abilita la comunicazione dei dispositivi IoT attraverso l'infrastruttura delle smart city" e utilizza l'AI generativa per la generazione automatica degli asset necessari.
  • Generazione automatizzata di driver di risorse specifici del fornitore: utilizza l'AI generativa per creare driver di risorse specifici in base alla documentazione del fornitore.
• Operazioni Giorno 1:
  • Semplificazione dell'ordine di servizio: consente ai clienti di richiedere servizi utilizzando il linguaggio naturale. Questo approccio intuitivo abilita un'esperienza di ordinazione di servizi completamente nuova, come la possibilità di mescolare e abbinare le offerte del catalogo.
  • Controlli di fattibilità: semplifica i controlli di convalida man mano che i clienti esprimono le proprie intenzioni, valutando in modo efficiente fattori critici come la disponibilità della linea in OPTIC. Il risultato è una riduzione del carico di lavoro per gli ingegneri di rete, una convalida più rapida dei servizi e un'implementazione più agile e reattiva.
• Operazioni Giorno 2
  • Garanzia dinamica del servizio: consente alle reti di rispondere in modo intelligente alle mutevoli condizioni e alle esigenze degli utenti. Le politiche flessibili basate sugli intenti migliorano l'agilità, garantendo affidabilità e reattività in tempo reale ai servizi di rete.

Le sfide principali da affrontare sono due:

1. Come esprimere e trasmettere un intento?
2. Come eseguire un intento e che aspetto ha un gestore degli intenti?

TM Forum ha introdotto l'API TMF921 Intent-based Networking, che offre un framework strutturato per la definizione degli intenti di rete di alto livello. TM Forum definisce l'intento come segue: "l'intento è la specifica formale di tutte le aspettative, inclusi requisiti, obiettivi e vincoli dati a un sistema tecnico". Tuttavia, la specifica formale parziale introduce una preoccupazione: gli ingegneri di rete devono familiarizzare con questo linguaggio formale per sfruttare tutto il potenziale del concetto di intento. Inoltre, gli intenti con specificazione formale non riducono necessariamente il numero di parametri che devono essere forniti con essi. Questo aspetto mette in discussione la prevista semplificazione della gestione della rete che in genere si associa all'IBN.

Inoltre, formalizzando la specifica dell'intento, l'intent handler, cioè il componente principale dell'IBN che contiene la logica per interpretare l'intento, diventa semplicemente un interprete deterministico del linguaggio formale. Si pone quindi la questione di come evolvere il gestore degli intenti in un sistema autonomo con modalità operativa dichiarativa in cui gli umani non sono tenuti ad anticipare ogni potenziale condizione della rete e fornire istruzioni specifiche per la sua risoluzione. Se ciò non avviene, infatti, il funzionamento del sistema non può passare correttamente da automatizzato a autonomo (TMF IG1230).

Nei prossimi blog affronteremo le sfide e le opportunità di IBN e AN in modo più dettagliato. Vuoi saperne di più?