Reti senza catene: lo spostamento verso operazioni autonome basate sugli intenti

L’industria delle telecomunicazioni, pietra angolare della connettività globale, sta attraversando da tempo una rinascita tecnologica, guidata da innovazioni come 5G, IoT, cloud computing e intelligenza artificiale. Di conseguenza, le reti sono diventate sempre più difficili da gestire. È necessario che l’automazione gestisca le attività di routine, monitori lo stato della rete e risponda 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 dinamico. 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 attraverso le interfacce di programmazione delle applicazioni (API) dei fornitori e ingegneri di garanzia del servizio per la progettazione di circuiti chiusi per garantire l’affidabilità del servizio.

Se da un lato i CSP colmano il divario costruendo team con esperienze diversificate, dall’altro beneficiano contemporaneamente di progressi significativi rispetto a una tendenza simultanea. I linguaggi di programmazione si sono evoluti verso paradigmi low-code/no-code e con l’emergere dell’intelligenza artificiale generativa, siamo a un punto in cui i modelli fondamentali possono generare codice formale basato sulle descrizioni dei compiti in linguaggio naturale. Ciò ha dato una nuova prospettiva al concetto di networking basato sugli intenti (IBN), in cui gli amministratori umani esprimono obiettivi di rete di alto livello in un linguaggio naturale noto come “intenti” e questi intenti umani vengono automaticamente tradotti in policy e configurazioni di rete. IBN ha il potenziale per migliorare la gestione della rete e potrebbe diventare un punto di svolta nell’affrontare il divario di talenti all’interno delle società di telecomunicazioni. Facendo un ulteriore passo avanti, reti autonome (AN) promettono di utilizzare gli intenti come input per auto-configurarsi, auto-ottimizzarsi e auto-guarire le reti man mano che le loro condizioni evolvono.

Sebbene possiamo immaginare un futuro luminoso sia per IBN che per AN, permangono preoccupazioni persistenti sulla loro fattibilità e sulle applicazioni del programma, tra cui l’espressione di intenti, la traduzione accurata nella configurazione di rete, la trasparenza e la complessità del sistema, tra gli altri. In questo blog, approfondiamo le aree in cui la loro applicazione pratica ha potenziale e analizziamo le sfide che potrebbero incontrare lungo il percorso.

Un caso motivante: introdurre nuovi servizi senza intenti

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

Partiamo dal presupposto che il funzionamento della rete CSP sia automatizzato secondo le specifiche delineate nella Guida introduttiva TMF 1230 (IG1230) sull’architettura tecnica delle reti autonome. In tale contesto, l’OSS del CSP dispone di (1) un orchestratore per la fornitura di servizi, la fornitura automatizzata e i test automatizzati, (2) un sistema di garanzia con inventario di rete che raccoglie dati, crea approfondimenti sullo stato della rete e quindi facilita il processo decisionale basato sui dati nel contesto del controllo a circuito chiuso e (3) un policy manager che guida il comportamento della rete utilizzando policy predefinite, garantendo l’allineamento con le policy più ampie del CSP. In poche parole, le operazioni automatizzate ruotano attorno allo stretto accoppiamento dei servizi con i descrittori, le configurazioni, le politiche e i flussi di lavoro imperativi del servizio TOSCA progettati dall’uomo, in cui l’intelligenza e il processo decisionale vengono aggiunti dai progettisti del servizio durante la fase di progettazione. I progettisti di servizi devono prevedere in modo proattivo un’ampia gamma di condizioni che possono verificarsi nella rete e fornire istruzioni dettagliate su come affrontarle: l’esperienza zero-touch si ottiene purché le condizioni future siano state previste e vi siano politiche per gestirle.

Usiamo i termini Giorno 0, Giorno 1 e Giorno 2 per le diverse fasi del ciclo di vita del servizio, vale a dire progettazione del servizio, istanziazione del servizio E garanzia del serviziorispettivamente.

• La progettazione del servizio comprende lo sviluppo di varie risorse del servizio, come illustrato nella Figura 1. Questo è il compito del team di progettazione del servizio, che deve comprendere le operazioni del giorno 1 e del giorno 2 del servizio e produrre i flussi di lavoro e gli script richiesti. Le linee rosse nella Figura 2 rappresentano il processo di fornitura di un nuovo servizio, garantendo che il servizio possa ora essere ordinato.

• L’istanziazione del servizio avviene quando arriva l’ordine di servizio, a seguito di una richiesta dell’abbonato. Oggi nei CSP l’ordine di servizio arriva generalmente tramite l’interfaccia TMF 641 dal gestore degli ordini di servizio (SOM). Quando l’agente di orchestrazione del servizio riceve l’ordine di servizio, garantisce che i flussi di lavoro vengano eseguiti e che le configurazioni di monitoraggio richieste, i modelli PM/FM e le policy siano distribuiti ed eseguiti. Mostriamo l’istanziazione del servizio nella Figura 2 in linee verdi.

• La garanzia del servizio segue un approccio a circuito chiuso in cui le condizioni dei servizi distribuiti sono sottoposte a monitoraggio continuo e azioni automatizzate del ciclo di vita. Mostriamo il circuito chiuso di garanzia nella Figura 2 con linee blu.

In sintesi, è la fase di progettazione che comporta una notevole quantità di lavoro manuale, poiché è necessaria per fornire alla rete le istruzioni per il nuovo servizio.

Cosa sono gli intenti?

In IBN, gli intenti si riferiscono agli obiettivi di alto livello che CSP vuole raggiungere nella sua rete. Invece di occuparsi di complesse configurazioni di rete di basso livello durante le operazioni del giorno 0 come discusso sopra, i team di ingegneri esprimono gli obiettivi con intenti e la logica alla base degli intenti li traduce nella configurazione di rete richiesta che soddisfa l’obiettivo dell’intento.

Dopo l’applicazione delle configurazioni alla rete, l’AN monitora continuamente i servizi distribuiti e adatta la configurazione per garantire che l’operazione rimanga in linea con gli intenti specificati. L’AN estende l’uso degli intenti alle operazioni del secondo giorno.

Prospettive di IBN e AN

Successivamente, forniamo alcuni degli aspetti in cui gli intenti potrebbero potenzialmente rivoluzionare le pratiche consolidate dell’era precedente all’intento:

• Operazioni del giorno 0:
  • Preparazione per nuovi servizi – Sfruttare l’intelligenza artificiale generativa per elaborare l’input del linguaggio naturale per integrare autonomamente i requisiti di servizio.
  • Introduzione di nuovi servizi – Definire nuovi servizi utilizzando il linguaggio naturale, ad esempio “fornire una soluzione di connettività su misura per una comunicazione sicura all’interno delle istituzioni sanitarie” o “abilitare la comunicazione dei dispositivi IoT attraverso l’infrastruttura della città intelligente” e sfruttare l’intelligenza artificiale generativa per la generazione automatica delle risorse di servizio necessarie.
  • Generazione automatizzata di driver di risorse specifici del fornitore– Utilizzare l’intelligenza artificiale generativa per creare driver di risorse specifici del fornitore, in base alla documentazione del fornitore.
• Operazioni del primo giorno:
  • Semplificazione dell’ordine di servizio – Consente ai clienti di richiedere servizi utilizzando il linguaggio naturale. Questo approccio intuitivo consente una nuova esperienza di ordinazione dei servizi, come la combinazione e l’abbinamento delle offerte dal catalogo.
  • Verifiche 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 fibra ottica. Il risultato è un carico ridotto per gli ingegneri di rete, una convalida del servizio più rapida e un’implementazione più agile e reattiva.
• Operazioni del secondo giorno:
  • Garanzia dinamica del servizio – Consente alle reti di rispondere in modo intelligente alle mutevoli condizioni e alle esigenze degli utenti. Le policy flessibili basate sugli intenti migliorano l’agilità, garantendo l’affidabilità e la reattività in tempo reale dei servizi di rete.

Le sfide con IBN e AN

Ci sono due sfide principali da affrontare:

1. Come esprimere e trasmettere un intento?
2. Come eseguire un intento: che aspetto ha il gestore dell’intento?

TM Forum ha introdotto l’API di rete basata sugli intenti TMF921, offrendo 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 imposti a un sistema tecnico”. Tuttavia, la parte specificazione formale introduce una preoccupazione: gli ingegneri di rete dovrebbero familiarizzare con questo linguaggio formale per sfruttare tutto il potenziale del concetto di intento. Inoltre, gli intenti con specifica formale non riducono necessariamente il numero di parametri che devono essere forniti con essi. Questo aspetto mette in discussione la prevista razionalizzazione della gestione della rete che normalmente si associa all’IBN.

Inoltre, formalizzando la specifica dell’intento, il gestore dell’intento, il componente principale dell’IBN che contiene la logica per l’interpretazione dell’intento, diventa semplicemente un interprete deterministico del linguaggio formale dell’intento. La questione si solleva su come evolvere il gestore dell’intento in un sistema autonomo con modalità di funzionamento dichiarativa in cui agli esseri umani non è richiesto di anticipare ogni potenziale condizione della rete e fornire istruzioni specifiche per la sua risoluzione. In caso contrario, il funzionamento del sistema non potrà passare con successo da automatizzato ad autonomo (TMF IG1230).

Nei blog futuri affronteremo le sfide e le opportunità di IBN e AN in modo più dettagliato. Vuoi saperne di più? Contattaci a maja.curic@ibm.com, chris.van.maastricht@nl.ibm.com e tmtattis@ae.ibm.com.

Trasformarsi per il futuro
con le telecomunicazioni