5G New Stack: sfide e opportunità

5G New Stack: sfide e opportunità
 

5G New Stack: sfide e opportunità

La velocità e l’ampiezza dell’evoluzione tecnologica e la competizione commerciale su un numero sempre maggiore di servizi sono tali che gli operatori Telco devono cambiare radicalmente il loro approccio all’adozione e al dispiegamento di nuovi sistemi e servizi. Il fattore che appare sempre più centrale è quello della agilità, per poter esplorare nuovi segmenti di business e offrire un numero maggiore di nuovi servizi in modo efficiente in termini di investimenti e risorse. Le tecnologie cloud native e l’uso dell’Intelligenza di rete appaiono un supporto rilevante al pieno sviluppo del 5G.

 

5G new stack: architettura end to end

Il 5G è riconosciuto come la tecnologia che permette la realizzazione dei nuovi servizi, grazie ai suoi abilitatori. Vediamoli insieme. In primo luogo le caratteristiche trasmissive, che permettono di supportare un numero elevatissimo di device e bande più alte ed estese rispetto al passato, con conseguenti performance di throughput e latenza migliori. Queste caratteristiche portano a definire le tre famiglie note dei servizi 5G (eMTC, eMBB, URLLC), al cui interno sono collocabili i nuovi servizi digitali. Il secondo abilitatore caratterizzante il 5G è la flessibilità introdotta dal Network Slicing, che permette di assegnare sistemi virtuali a servizi e utilizzatori specifici, liberando gli Operatori dal vincolo di dispiegare e integrare sistemi e piattaforme fisiche dedicate. Infine, la SBA (Service Based Architecture), basata su API web based per realizzare l’inter-lavoro tra funzioni di controllo di rete in forma di invocazione di servizi, permette una maggiore agilità di dispiegamento rispetto alle architetture tradizionali basate su interfacce punto-punto.
Tuttavia, le funzionalità standard del 5G rappresentano solo una parte degli abilitatori tecnologici necessari per raggiungere gli obiettivi di business dei Telco. L’obiettivo ultimo è duplice: da un lato dispiegare una grande varietà di servizi appartenenti ad Industry differenti, anche in collaborazione con partner di business e sviluppatori, dall’altro raggiungere questo obiettivo con time to market brevi e con efficienza di rete a tutti i livelli, dal dispiegamento, all’integrazione, alla gestione, allo scaling, ed in modo tale che l’introduzione di un servizio non comporti modifiche all’architettura di rete o catene verticali di sistemi.
Per raggiungere questi obiettivi occorre definire una visione generale di sistema, in cui il 5G non sia solo un nuovo sistema mobile con le proprie entità logiche specifiche, ma è il sistema di riferimento che integri gli accessi fissi e mobili ultra-broadband (LTE e New Radio) e si appoggi ad una piattaforma di rete agile ed intelligente, in grado di offrire le caratteristiche di flessibilità ed autonomia richieste. In questo scenario, le tecnologie cloud native diventano di grande interesse per gli operatori Telco, poiché forniscono queste capability essenziali.

 

Figura 1 - Architettura e2e – Componenti logici

Un ambiente Cloud Native è composto da due elementi logici: una CNI (Infrastruttura Cloud Native - Cloud Native Infrastructure) e l’insieme delle Applicazioni CNA (Cloud Native Application), che girano su di essa. La CNI è definita in modo tale che lo sviluppo della CNA possa essere centrato unicamente sulla logica funzionale ed essere svincolata dagli aspetti di dispiegamento e gestione, grazie al fatto che la CNI fornisce gli strumenti per la gestione dell’intero ciclo di vita delle Applicazioni. Inoltre, la CNI fornisce le risorse di rete in forma astratta a più livelli e con soluzioni che migliorano la scalabilità del dispiegamento virtualizzato, fornendo un livello di efficienza maggiore rispetto alla semplice virtualizzazione dei sistemi. Infine, un ambiente Cloud Native è caratterizzato da un elevato livello di autonomia, sia nel prendere le decisioni (ad es. relative ad affidabilità, scalabilità, etc.), sia nell’attuarle grazie alla automazione dei sistemi, tendendo a quell’approccio zero human touch, che prevede l’intervento umano solo in casi eccezionali. Un aspetto peculiare dell’astrazione delle risorse di rete è la mancanza di vincoli di tipo geografico, purché siano rispettati i requisiti della CNA che utilizza quelle risorse, ragion per cui, ad esempio, un’entità di core network non sarà più dispiegata staticamente in un sito, ma attivata on demand dove e quando necessario. Considerato che le CNA sono composte da moduli atomici (microservizi) ed utilizzano servizi della CNI, un’applicazione di rete potrà essere composta da moduli ed utilizzare servizi dispiegati fisicamente in siti CNI distinti ed anche appartenenti ad una cloud ibrida, cioè in parte Pubblica, in parte on premises dell’Operatore.
Il dispiegamento del 5G avverrà dunque su due livelli, quello funzionale delle applicazioni e dei sistemi di controllo 5G e quello dell’infrastruttura Cloud Native, dove le applicazioni di core network e di controllo saranno sviluppate secondo tale paradigma. Lo sviluppo avverrà in fasi successive in funzione della maturità delle due architetture. La maturità dell’architettura funzionale 5G dipende sia dai rilasci 3GPP sia dalle release di prodotto dei vendor: se l’architettura Non Stand-alone appare disponibile già nel corso del 2019, resta da valutare la disponibilità di architetture più complesse, quali l’architettura, Stand Alone sia New Radio sia LTE, e l’architettura di interworking LTE-NR. Un piano di dispiegamento evoluto del 5G richiede inoltre che l’architettura infrastrutturale vada valutata rispetto ai complessi requisiti di un ambiente Telco (affidabilità, alto traffico, requisiti regolatori, intercetto delle comunicazioni ecc.) e rispetto alle roadmap di sviluppo per il pieno raggiungimento dei paradigmi plug & play e zero touch.

 

Core network mobile verso il paradigma cloud-native

TIM ha avviato da tempo un percorso di trasformazione della rete fissa e mobile basato sull’adozione del paradigma NFV (Network Functions Virtualisation), il cui scopo è quello di separare il software che implementa una data funzionalità di rete dall’hardware sui cui viene eseguito.
Ad oggi, TIM dispone di un’infrastruttura cloud in tecnologia VMware ed OpenStack distribuita nei principali PoP di rete che ospita oltre 60 VNF (Virtual Network Function) a traffico.
I benefici di questa trasformazione sono molteplici ed includono:

  • risparmi sugli investimenti derivanti dall’utilizzo di un’infrastruttura condivisa;
  • risparmi sui costi operativi (manutenzione, energia e spazi) abilitati dalla separazione tra hardware e software;
  • incremento significativo della velocità di realizzazione di nuovi servizi e prestazioni di rete attraverso l’automazione e l’impiego di soluzioni implementate integralmente in software.

E’ chiaro che, per conseguire pienamente tutti questi benefici, l’Operatore si doti di funzioni di rete ridisegnate secondo un’architettura ottimizzata per il dispiegamento in ambiente cloud. Questo aspetto rappresenta il principale punto di attenzione, in quanto la maggior parte dei fornitori, anziché puntare in modo deciso sull’innovazione dei prodotti, ha cercato di rispondere velocemente alla forte spinta degli operatori sulla virtualizzazione di rete, realizzando un semplice porting del proprio software da ambienti fisici basati su hardware specializzato a macchine virtuali in esecuzione su hardware general-purpose.
L’obiettivo di TIM è sfruttare la discontinuità tecnologica introdotta dal 5G per realizzare un importante salto in avanti sul livello di automazione, agilità, efficienza e resilienza della rete e dei servizi erogati. Questo percorso inizierà dagli elementi della core network mobile, che saranno realizzati utilizzando applicazioni di rete specificamente progettate ed ottimizzate per il dispiegamento in ambiente cloud (CNA), eseguite su piattaforma Cloud (CNI).
Le caratteristiche distintive di una CNA sono le seguenti:

  • Astrazione delle risorse infrastrutturali. Una CNA può avere requisiti prestazionali stringenti sui servizi offerti dalla CNI, ma non deve porre vincoli sulle risorse infrastrutturali utilizzate per eseguirla (e.g. richiesta di specifiche tipologie di hardware e/o hypervisor). In ultima analisi deve essere possibile dispiegare l’applicazione in qualunque punto della piattaforma senza impatti sulle funzionalità erogate.
  • Automazione e “zero touch configuration”. Tutte le caratteristiche di una CNA (e.g. topologia, modalità di istanziazione, terminazione, scaling, healing e upgrade, requisiti di monitoraggio, configurazioni applicative) devono essere descritte tramite template, utilizzabili dalle soluzioni di automazione disponibili nella piattaforma, per gestire senza l’ausilio di interventi manuali tutte le fasi del ciclo di vita dell’applicazione. A tal fine è essenziale che la CNA esponga un insieme completo di API utilizzabile per accedere in modo programmatico a tutte le funzionalità erogate dall’applicazione.
  • Riuso dei servizi offerti dalla piattaforma. Per svolgere le proprie funzioni una CNA deve utilizzare i servizi a catalogo che la CNI mette a disposizione di tutte le applicazioni su di essa ospitate (e.g. Service Discovery, Identity and Access Management, “DB as a Service”, “Load Balancer as a service”, “Firewall as a Service”).
  • Architettura modulare e decomposizione. I moduli che compongono una CNA devono essere il più possibile disaccoppiati tra loro in termini di sviluppo, dispiegamento, testing e gestione del ciclo di vita. Le comunicazioni tra moduli devono essere basate su protocolli standard noti alla CNI (e.g. utilizzo di API REST e HTTP invece di Diameter o altri protocolli “telco”), in quanto questo è un fattore abilitante per poter sfruttare i servizi a catalogo messi a disposizione dalla piattaforma.
  • Elasticità. Al variare del carico smaltito deve essere possibile ridurre o ampliare automaticamente, sulla base di metriche di tipo infrastrutturale e/o applicativo, la capacità erogata da una CNA decrementando o incrementando il numero di moduli che implementano specifiche componenti dell’applicazione (scale in/out). Al fine di abilitare un’elevata granularità nello scaling, consentire l’impiego di hardware COTS a basso costo ed ottimizzare l’efficienza d’uso delle risorse infrastrutturali, i moduli che costituiscono una CNA dovrebbe essere molto piccoli in termini di quantità di CPU e RAM utilizzata.
  • Resilienza. Una CNA dovrebbe essere progettata con caratteristiche di ridondanza e strategie di gestione dello stato, tali da poter continuare ad erogare il servizio (eventualmente con un degrado prestazionale graduale e controllato), anche al verificarsi di malfunzionamenti multipli nei moduli che realizzano l’applicazione e/o nella piattaforma sottostante.
  • Fault monitoring e failure detection. Una CNA deve essere osservabile, ovvero deve offrire meccanismi di monitoraggio e notifica che permettano di verificarne lo stato di salute, rilevare prontamente eventuali problemi ed eventualmente innescare automaticamente meccanismi di healing mirati a ripristinare la piena operatività dell’applicazione.

La modalità raccomandata per realizzare una CNA con tali proprietà prevede di implementare i moduli che compongono l’applicazione sotto forma di microservizi in esecuzione su una piattaforma a container, come Kubernetes.
La core network 5G di TIM si presta bene ad essere realizzata secondo questo paradigma, in quanto è stata progettata fin dall’inizio privilegiando scelte tecniche espressamente pensate per il dispiegamento in cloud, considerato un fattore abilitante irrinunciabile per alcune funzionalità cardine del 5G come il network slicing, che richiede la capacità di creare rapidamente istanze di rete dedicate a specifici clienti e/o scenari di servizio. Un esempio importante di come questi principi siano stati recepiti dallo standard 3GPP è la SBA (Service Based Architecture), che raggruppa le funzionalità di controllo alla base del funzionamento della core network 5G ed introduce importanti innovazioni orientate al cloud-native.

 

La Cloudification dell’Infrastruttura

La virtualizzazione delle reti di TIM ha perseguito un modello d’infrastruttura che ha come primo traguardo la netta divisione tra il software delle funzioni di rete e lo strato hardware che lo ospita. Il progetto 5G New Stack di TIM mira a realizzare con la CNI (Cloud Native Infrastructure) un ambiente infrastrutturale totalmente Cloud Native, affidabile, performante e scalabile, che ospiterà micro-servizi ed applicazioni realizzate secondo il paradigma PaaS oltre ai modelli definiti nell’ambito della Cloud Native Foundation.

Cloud Native Infrastructure

In un’infrastruttura Cloud Native, le applicazioni vengono create ed eseguite run-time in ambienti dove lo stesso sistema operativo, la sicurezza, la scalabilità, i backup e gli altri componenti sono astratti e gestiti dal fornitore dell’infrastruttura. Una delle caratteristiche chiave è che la configurazione dell’ambiente viene effettuata tramite API ed interfacce dichiarative dalle quali derivano opportunità di automazione e agilità.
Inoltre, è necessario avere infrastrutture che possano ospitare congiuntamente applicazioni di molteplici funzionalità, dalle applicazioni di rete a quelle di OSS e BSS. Si è inoltre optato per l’adozione, sebbene non esclusiva, di un metodo di “Immutable Infrastructure”, per migliorare la gestione del ciclo di vita dell’infrastruttura, e per un approccio “as a Code”, per conseguire un elevato livello di automazione sull’intera catena.

Platform as a Service

In una CNI, la PaaS espone servizi ad alto livello attraverso contenitori logici, chiamati Container, funzionalità di orchestrazione (es. Kubernetes), Common Services (API, Networking, Persistent Storage, ecc.) e Dedicated Services (istanze a catalogo che nascono e muoiono con l’Applicazione).
La PaaS introduce quindi un ulteriore livello di astrazione ed automatismo rispetto ai servizi offerti dalla sola virtualizzazione. L’High Level Architecture della CNI si compone di diversi layer e blocchi funzionali:

  • CaaS (Container as a Service), strato che offre il supporto per la creazione e la gestione di container. I container sono contenitori logici che vengono creati on demand con un sistema operativo minimale condiviso con la macchina ospitante su cui si effettua l’installazione, creando così un sistema rapido, efficace e scalabile dovuto anche al fatto che l’oggetto viene generato e lasciato risiedere in RAM.
  • CI/CD (Continuous Integration/Continuous Delivery), layer che coadiuva gli sviluppatori per l’integrazione, il testing e il delivery dell’applicazione.
  • Common Services, tool messi a disposizione alle applicazioni (Service Mesh, Persistent Storage, ecc.) dalla PaaS in maniera trasversale e agli utenti (Identity & Access Manager, Logging, Telemetry, ecc.) per rendere efficienti e flessibili i micro-servizi.

Una PaaS, per definirsi tale, dovrebbe disporre di funzioni architetturali predefinite e standardizzate che consentano di creare e gestire Contenitori logici, automatizzare il versioning del software e le pipeline di sviluppo, collaudo, deploy (Continuous Integration & Deployment), che garantiscano osservabilità e profondità di analisi, che orchestrino la scalabilità in funzione delle necessità di servizio (Autoscaling), che offrano capabilities di Networking evoluto, Database distribuito, messaggistica interna intra funzione.
L’elemento di maggiore innovazione rispetto ad una più classica architettura virtualizzata risiede nell’astrazione logica introdotta dai Container, che consente di poter distruggere ambienti applicativi senza dover disinstallare, reinstallare o effettuare tuning sul server ospitante, fisico o virtuale che sia. I container da soli offrono una grande flessibilità e scalabilità, ma non dispongono di una ridondanza intrinseca, ne deriva pertanto l’esigenza di clusterizzare questo tipo di risorse. Per ovviare al problema sono nati prodotti, attualmente utilizzati in TIM, che aggiungono la possibilità di orchestrare grossi volumi di container organizzandoli in maniera logica, in linea con i progetti sviluppati.
Immutable infrastructure: the world is enclosed in a code
Un’infrastruttura cosiddetta immutabile segue un paradigma fondato sulla regola secondo cui i server non vengono mai modificati dopo la distribuzione. Se qualcosa dev’essere aggiornato, i nuovi server creati da un'immagine comune con le modifiche appropriate sono predisposti per sostituire quelli vecchi. Dopo essere stati convalidati, vengono messi in uso e quelli precedenti vengono rimossi. I vantaggi d’una Immutable Infrastructure consistono in primis in un’affidabilità e integrità dei dati, oltre che in una semplificazione a livello di deployment dei processi. Per sua natura essa mitiga, se non elimina del tutto, i problemi intrinseci di un’infrastruttura di tipo mutevole, ad esempio disallineamenti ed errori umani.
Questo nuovo approccio permette di effettuare dei provisioning più precisi e veloci e un disaster recovery più efficiente grazie alla possibilità di avere dei servizi atomici che non necessitano di altro al di fuori di quello che è stato installato e configurato nel proprio contenitore.
Per poter realizzare un’infrastruttura immutabile è necessario poterla programmare su tutti i livelli logici architetturali che la compongono: uno dei concetti principali diffusi dalla Cloud Native Foundation è che tutto possa essere “sviluppato”, che tutto, dall’infrastruttura al software, sia racchiuso in file di configurazione o in template. Da qui prendono piede i concetti di IAC (Infrastracture As a Code) e IaaS (Infrastracture as a Software). Nello specifico, la IAC è la chiave per ottenere un sistema di scaling efficiente: la possibilità di gestire un intero data center attraverso file di definizione, piuttosto che configurare i server manualmente, puntualmente e specificatamente ogni volta che se ne presenti la necessità.

 

Figura 2 - Architettura della Cloud Native Infrastructure

La sfida della trasformazione dei Support Systems e gli impatti sulla gestione operativa

La trasformazione Digitale di TIM coinvolge anche i propri Support Systems, BSS (Business Support Systems) ed OSS (Operations Support Systems), per renderli sempre più flessibili, dinamici e abilitatori al cambiamento e all’innovazione di prodotto/servizio. Ciò consentirà una maggiore ottimizzazione e semplificazione delle attività inerenti lo sviluppo del business (quali ad esempio l’interazione col cliente su molteplici canali), il miglioramento dell’operatività (tipo l’allocazione delle opportune risorse di rete per la fornitura di un servizio o il monitoraggio di parametri significativi per rilevare le performance di un servizio) ed il contenimento dei costi operativi. Per i BSS il programma di trasformazione più rilevante in essere in TIM è “Fly Together”, che ha l’obiettivo di abilitare la trasformazione digitale dell’azienda ottimizzando la Customer Experience attraverso tutti i canali, assistiti e non assistiti, mentre per gli OSS il programma di riferimento è “OSS Transformation”, che ha l’obiettivo di disaccoppiare la gestione dei servizi commerciali dalle tecnologie di rete migrando dall’attuale architettura “siloed” ad una layered, service-based, catalogue e data-driven.
I principi di “Cloud Nativeness” si applicano anche ai support systems evoluti, i quali, essendo anch’essi Cloud Native Application, potranno essere implementati sulla Cloud Native Infrastructure in via di predisposizione in TIM ed usufruiranno dei “servizi gestionali” messi a disposizione dall’infrastruttura (es. monitoraggio dei container su cui risiederanno i support systems). Un ulteriore beneficio di soluzioni B-OSS Cloud Native è che non necessariamente esse saranno “on-premise”, bensì potranno essere rese disponibili (a valle di valutazioni su opportunità / rischi) anche su cloud pubblico con vantaggi quali lo scaling e con la garanzia di collegamenti ad altissima velocità alle reti e piattaforme informatiche dei gestori.
Sul percorso di cambiamento già avviato per i support systems in TIM, si innesta la “sfida” e opportunità, offerta dal 5G, che a livello di standardizzazione (3GPP) introduce l’approccio della Service Based Architecture come elemento di discontinuità rispetto alle generazioni precedenti, sia per quanto riguarda il “sistema rete” sia per gli aspetti di gestione. Il nuovo modello service based adottato dal 3GPP per il 5G, a livello di Network & Service Management implicherà la necessità di revisione del modello di riferimento per i support system, rendendo necessario il passaggio da un modello estremamente rigido e gerarchico, come quello posto in essere per il 4G e le generazioni precedenti, ad un modello più flessibile ed adattabile, anch’esso basato su microservizi, con evidenti vantaggi per l’Operatore.
Il modello di management attuale prevede specifici Management Element (es. Element Manager, Network Manager) che, in una relazione gerarchica definita, gestiscono ed “operano” la rete. Tale modello, anche grazie alla mancata standardizzazione fra Element Manager e nodi di rete, tende a portare all’adozione di una soluzione verticale e “rigida” per gestire i nodi di rete, in cui molti componenti gestionali vengono forniti dal vendor del nodo di rete. Il modello service based del 5G invece, per sua natura, non pone vincoli alla composizione di un sistema di management, in cui potranno essere integrati i “management services” forniti da vendor diversi, e consentirà la riduzione del lock-in operato dai vendor.
Infine, il modello gestionale per il 5G consentirà di enfatizzare e valorizzare il processo in atto di ammodernamento dei sistemi di gestione preposti verso la cloud nativeness, in termini di componibilità dei servizi gestionali, flessibilità delle logiche di orchestrazione, rapida adattabilità a cambiamenti di esigenze di business / operative.
Nel 5G le funzionalità di rete sono state specificate secondo l’approccio Service Based, abilitando la loro implementazione in modalità cloud native; ciò incrementa notevolmente la possibilità di controllare la rete via software introducendo livelli di agilità, flessibilità ed automatismi (zero-touch management) non proponibili per le generazioni precedenti. Saranno quindi rese disponibili in near real-time moli di dati e informazioni decisamente maggiori rispetto a quelli messi a disposizione da reti tradizionali; questi dati vista la loro numerosità e complessità saranno difficilmente gestibili da umani o da support systems tradizionali, imponendo la necessità di definire e implementare specifici sistemi di Advanced Analytics basati sull’intelligenza artificiale e il machine learning (AI & ML). L’intelligenza artificiale consentirà di velocizzare le diagnosi sui problemi riscontrati sulla rete, di identificare e applicare le decisioni opportune per evitare il loro ripetersi. Alcuni moduli di tali sistemi di Advanced Analytics potranno essere essi stessi cloud native, e i support systems cloud native potranno facilmente reperire i dati elaborati dai sistemi di Advanced Analytics e resi disponibili via open API.
Una considerazione finale sui benefici ed impatti derivanti dallo sviluppo dei support systems con approccio cloud native e modello Service Based va fatta per le attività di esercizio delle reti e dei servizi di TIM (Operations), che subiranno nel tempo modifiche rilevanti in alcune “discipline”, quali la Gestione Applicativa e delle Infrastrutture:

  • la Semplificazione: le applicazioni cloud native che realizzeranno le funzioni di rete 5G saranno altamente automatizzate in molte fasi del loro ciclo di vita, dal design e progettazione attraverso blueprint di riferimento, allo scheduling delle risorse e alla loro orchestrazione, al monitoring del loro stato, all’aggiornamento delle politiche di controllo; meccanismi di feedback “closed-loop” sempre più raffinati e precisi consentiranno un’autonomia gestionale elevata ed efficace.
  • la Trasparenza: in un mondo cloud native le Operations progressivamente (asintoticamente) diventeranno “trasparenti”: la gestione del ciclo di vita per le istanze delle applicazioni sarà fornita in automazione dietro le quinte dall’infrastruttura cloud native che porrà a disposizione degli operatori della Gestione Applicativa una serie di servizi di piattaforma, quali il monitoring, il self healing, ecc.
  • la Specializzazione: con una gestione cloud-native, il personale di esercizio potrà essere liberato da attuali attività labor-intensive e ripetitive, e potrà concentrare il proprio impiego in task di maggiore complessità, contribuendo ad una generale riduzione dei costi operativi.

La sfida aziendale della trasformazione dei support systems per renderli abilitatori al cambiamento è stata intrapresa con decisione, e in questo senso l’approccio cloud native sarà uno dei fattori chiave; in aggiunta a questa dimensione, le opportunità di cambiamento introdotte dall’approccio innovativo e di discontinuità proprie del 5G potranno e dovranno contribuire al successo finale della trasformazione di TIM in una digital company.

 

Conclusioni

Il dispiegamento del 5G, se interpretato diversamente dal solo lancio di un nuovo sistema mobile più performante, rappresenta una fase di trasformazione degli Operatori Telco. Il suo sviluppo su una piattaforma basata su principi radicalmente diversi dal passato rappresenta l’opportunità di creare un modo nuovo di interagire con i clienti e con l’ecosistema delle Industrie, dei fornitori e dei partner. L’evoluzione delle tecnologie della cloudification fornisce quegli abilitatori di agilità di cui gli Operatori hanno bisogno sia per la gestione dei nuovi servizi sia per la gestione dei sistemi tecnologici. Un ruolo centrale è svolto dall’Intelligenza di rete, che, a partire da dati ed eventi, è in grado di gestire il ciclo di vita delle Applicazioni in modo autonomo e attraverso strumenti automatizzati, realizzando un paradigma zero human touch, che semplifica radicalmente i processi. Strumenti quali le Cloud Native Application e Cloud Native Infrastructure, unite a tecnologie specifiche del 5G, quali il Network Slicing e la Service Based Architecture, mostrano un potenziale rilevante per permettere agli Operatori Telco di fornire la varietà di servizi digitali del 5G con la flessibilità e l’efficienza necessarie.

 

comments powered by Disqus