APPROFONDIMENTO

Cloud native design nello standard

Cloud native design nello standard
 

Le specifiche 3GPP di Release 15 per la Core Network 5G (5GC) sono state definite tenendo in considerazione sin dall’inizio i requisiti più rilevanti per ottenere una soluzione cloud native. Infatti una delle più importanti novità introdotte con la 5GC è rappresentata dalla Service Based Architecture. In questo nuovo approccio architetturale, specificato per il Control Layer della 5GC, le CNA sono definite come una composizione di microservizi per quanto possibile self-contained, riutilizzabili e gestibili in modo indipendente. I microservizi all’interno di una CNA godono di un lifecycle management autonomo che garantisce l’elasticità delle singole componenti della CNA. Ciò abilita scenari di dispiegamento sia in central data center che scenari di micro-dispiegamento all’edge della rete o addirittura a casa del Cliente.
La comunicazione tra tali microservizi è realizzata attraverso delle API (Application Programming Interface) standardizzate sia dal punto di vista semantico che sintattico. A differenza delle precedenti generazioni della Core Network mobile, dove ciascuna interfaccia del Control Layer utilizzava un protocollo dedicato (ad esempio Diameter, GTP-C), le Service Based Interface sono tutte basate su HTTP/2 come protocollo applicativo, JSON come protocollo di serializzazione e Open API 3.0.0 come schema di definizione delle API REST. Le procedure che governano il funzionamento della 5GC sono realizzate come una sequenza di interazioni tra microservizi che sono stati standardizzati: un microservizio “producer” espone via API le proprie funzionalità che sono consumate da altri microservizi “consumer”. Proprio l’adozione di API con sintassi comune e semantica standardizzata consente potenzialmente ad un microservizio di interagire con qualunque altro microservizio, qualora ve ne sia la necessità nell’ambito di una procedura di 5GC; ne deriva la possibilità di riutilizzare quegli stessi microservizi anche per definire nuove procedure, riducendo il tempo di implementazione e, in ultima analisi, il time to market. Poiché le CNA e i microservizi sono dispiegati in modo ridondato, nasce la necessità di scoprire lo specifico microservizio da invocare nell’ambito di una data procedura. A tale scopo è stata introdotta la nuova funzionalità di NRF (Network Repository Function) dove i microservizi si registrano (o vengono registrati dall’O&M) nel momento in cui sono istanziati e che il microservizio “consumer”, previa autorizzazione basata su protocollo OAuth 2.0, interroga per scoprire il microservizio “producer” da contattare.
Al fine di abilitare una maggiore elasticità e resilienza delle CNA, una volta completata la transazione, i microservizi possono depositare lo “stato” della CNA all’interno di un database esterno denominato UDSF (Unstructured Data Storage Function). Ciò consente un efficiente fault recovery, poiché qualsiasi altro microservizio dello stesso tipo può prendere in carico la transazione recuperandone lo “stato” dall’UDSF a valle del fault.
Anche nella comunicazione con le reti di altri Operatori sono utilizzate le Service Based Interface. In questo caso la comunicazione tra un “consumer” ed un “producer” continua ad essere una comunicazione diretta. Nel caso del roaming, tale comunicazione è protetta grazie ad una coppia di SEPP (Security Edge Protection Proxies) che criptano il traffico HTTP che transita sulla rete dei Carrier.

 

Opzioni per discovery e comunicazione tra microservizi [3GPP TS 23.501 Rel-16]

Nelle specifiche 3GPP di Release 16 è stato introdotto anche il modello di comunicazione indiretto tra microservizi basato sul SCP (Service Communication Proxy) che può essere dispiegato in maniera centralizzata oppure distribuita. Tale modello prevede che il processo di discovery dei microservizi e l’instradamento della comunicazione tra microservizi sia mediato dall’SCP garantendo un disaccoppiamento tra il “consumer” ed il “producer” (ad esempio in caso di variazione degli indirizzi IP dovuti a scale-in o scale-out).
Quanto descritto per la 5GC non prevede ad oggi un’analoga attività di standardizzazione per la EPC. Quindi l’eventuale implementazione di un modello cloud native dell’EPC, in termini di disaggregazione in microservizi, modelli di API adottate e loro comunicazione, sono lasciate all’implementazione dei singoli fornitori 

 

Torna all'articolo