La release 5.0.0 di ETSI introduce l’interconnessione tra piattaforme CAPIF, allineata alle procedure di sicurezza 3GPP della Release 19
Per chi progetta l’esposizione di API di rete, il limite è noto: finora un’API pubblicata su una piattaforma CAPIF restava, nella pratica, disponibile solo lì. Con OpenCAPIF Release 5.0.0 questo vincolo cade. Secondo l’annuncio diffuso da ETSI la scorsa settimana, due o più piattaforme CAPIF possono ora scoprirsi e condividere reciprocamente le proprie API, seguendo le procedure di sicurezza definite da 3GPP per l’interconnessione. Per un ufficio architetture la domanda pratica è una sola: che cosa cambia nello stack, e in quale ordine conviene intervenire.
Release 5.0.0: le piattaforme CAPIF smettono di essere isole
Il Software Development Group OpenCAPIF (SDG OCF) di ETSI presenta la Release 5.0.0 come una delle versioni più ricche di funzionalità finora pubblicate. La novità principale è la CAPIF Interconnection: piattaforme CAPIF diverse, gestite dalla stessa organizzazione o da organizzazioni differenti, possono scoprire e condividere le API l’una dell’altra. È un cambio di prospettiva: si passa dal singolo dominio a un insieme di domini che dialogano.
Il punto di riferimento normativo resta stabile. OpenCAPIF rimane allineato a 3GPP CAPIF Release 19, e la nuova funzione di interconnessione segue le procedure di sicurezza 3GPP previste per l’interconnessione CAPIF. In termini di conformità, chi adotta l’implementazione di riferimento non deve ricostruire da sé la catena delle regole di sicurezza tra domini: trova un comportamento già allineato alla specifica. Resta però aperta una questione: se le piattaforme ora si parlano, chi stabilisce che cosa ciascun soggetto può vedere?
Visibility Control e Open Discover: cosa cambia sul tavolo di chi espone e consuma API
Un’interconnessione senza un controllo granulare sull’esposizione sarebbe difficile da governare. Ed è proprio qui che la Release 5 chiude il cerchio: completa la funzione Visibility Control, avviata con la Release 4. Ora i fornitori di API possono decidere in modo completo chi può vedere e usare le proprie API, e per quanto tempo. La combinazione tra interconnessione e controllo della visibilità è ciò che rende la federazione gestibile: si allarga il perimetro di scoperta, ma ogni fornitore mantiene la regia su chi accede e con quale durata.
La seconda novità operativa riguarda il lato di chi consuma le API. Il nuovo Open Discover Service permette agli sviluppatori di verificare se le API di cui hanno bisogno sono disponibili su una piattaforma prima di registrarsi, con un risparmio di tempo per entrambe le parti. È un passaggio che sposta la verifica di disponibilità a monte del processo di onboarding, riducendo registrazioni inutili e richieste di supporto.
Tradotto in azioni concrete, la Release 5 suggerisce un percorso distinto per ciascun attore. Si tratta di indicazioni di buona prassi, non di obblighi formali derivanti dall’annuncio:
Fornitore di API. Prima di aprire le proprie API a piattaforme interconnesse, conviene definire attraverso il Visibility Control le regole di esposizione: quali soggetti possono vedere e utilizzare ciascuna API, e per quale finestra temporale. Documentare queste scelte rende tracciabili le decisioni di esposizione anche quando il numero di domini cresce.
Sviluppatore. Inserire l’Open Discover Service nella fase di valutazione: verificare la disponibilità delle API richieste su una piattaforma prima di avviare la registrazione, e solo dopo procedere con l’integrazione.
Operatore di piattaforma. Pianificare l’interconnessione con altre piattaforme CAPIF assumendo come riferimento le procedure di sicurezza 3GPP per l’interconnessione e l’allineamento a CAPIF Release 19. Lavorare su un’implementazione di riferimento già allineata riduce il rischio di soluzioni proprietarie da riallineare in seguito.
Resta da capire quanto valga fare bene queste scelte: considerate singolarmente sono decisioni di progetto, ma il loro valore emerge solo quando si moltiplicano su scala.
Perché lo standard armonizzato è il vantaggio, non il vincolo
Il dato di mercato chiarisce la posta in gioco. Secondo la pagina di 3GPP dedicata alle API di esposizione, il potenziale di ricavi abilitato dalle API di rete nei prossimi 5-7 anni è stimato fino a 300 miliardi di dollari. La stessa fonte pone però una condizione esplicita: per sbloccare questo potenziale servono approcci armonizzati e standardizzati, in grado di garantire maggiore copertura ed economie di scala. L’interoperabilità, in altre parole, è la precondizione del mercato, non un suo effetto collaterale.
Il percorso verso la commercializzazione su larga scala era già avviato: come ricostruito in un’analisi pubblicata su NTT Technical Review, già nel 2024 erano 62 gli operatori mobili che partecipavano all’iniziativa per la commercializzazione globale delle API standardizzate. Un dato di contesto che aiuta a leggere la Release 5 come tassello di un processo consolidato, più che come novità isolata.
La conclusione per gli uffici tecnici è pragmatica. Adeguarsi a OpenCAPIF Release 5 e all’allineamento con 3GPP CAPIF Release 19 non è un adempimento difensivo: è il modo più economico per entrare in un ecosistema federato, in cui copertura e scala premiano chi ha progettato secondo lo standard fin dall’inizio. La finestra utile per allinearsi è questa, mentre lo standard si consolida e le piattaforme iniziano a connettersi tra loro.
