Il ruolo dello standard nel mondo dei servizi e applicazioni

L’industria delle telecomunicazioni sta affrontando dei cambiamenti radicali con effetti sui modelli di business e conseguentemente la modalità con cui gli standard sono definiti. Anche se la situazione corrente può essere vista come una “caotica transizione” in un ecosistema in continua evoluzione, esiste ancora la necessità di utilizzare standard di riferimento, per assicurare l’interoperabilità tra soluzioni diverse.

 

1 - Introduzione

Può essere utile ricordare le origini dello standard. Nel febbraio del 1904, un grande incendio devastò per due giorni interi la città di Baltimora, nel Maryland (USA). Più di milleduecento pompieri furono necessari per domare le fiamme. Una delle principali ragioni della durata di tale incendio fu la mancanza di uno standard nazionale nell’equipaggiamento delle manichette usate dai vari pompieri. Nonostante siano accorsi dalle città vicine (come Filadelfia e Washington D.C., ma anche da New York City, Virginia, Wilmington, e Atlantic City) numerosi mezzi dei pompieri, molti non poterono essere utilizzati perché le manichette dei mezzi antincendio non poterono essere agganciati agli idranti di Baltimora. Dopo l’incendio di Baltimora, divenne chiaro che uno standard di riferimento era necessario e fu adottato dalla National Fire Protection Association uno standard nazionale per i connettori degli idranti antincendio [nota 1].

 

Figura 1 - L’incendio di Baltimora del 1904 e l’origine degli standard

2 - Dalla via “inerziale” ai nuovi modelli introdotti dagli OTT

Lo stesso principio fu applicato all’inizio dell’industria delle telecomunicazioni. Agli albori delle telecomunicazioni così come di Internet, dal momento che una tecnologia fondamentale stava per essere inventata, era imperativo per la crescita di nuovi mercati che degli standard di riferimento fossero stabiliti prima di un dispiegamento in grande scala della tecnologia e dei relativi servizi. Il processo per lo sviluppo di questi standard seguì un approccio tradizionale “a cascata” , il che aiutò ad armonizzare (a volte anche con delle alternative in ballo) soluzioni tecniche pre-standard alle necessità del mercato. Agli inizi degli anni 2000, un evento “di rottura” invase l’industria delle telecomunicazioni: lo sviluppo di un tipologia di Service Provider del tutto nuova, i cosiddetti “OTT (Over The Top)”. Gli OTT come Apple, Google, Amazon e molte altre ‘web companies’ che si sono sviluppate in questi anni hanno introdotto un’innovazione radicale in termini sia di hardware e tecnologie  sia di servizi, contribuendo significativamente alla crescita della penetrazione del mobile e dell’uso dei dati. Gli OTT hanno costruito il loro successo sulla loro capacità di capire e soddisfare i bisogni degli utenti e per alcuni di essi addirittura creare questi bisogni, sfruttando un approccio centrato sul cliente (“customer-centric”), educando il mercato ai propri servizi e prodotti

 

3 - La “rottura” introdotta dagli OTT riflessa sul mondo degli standard

La “rottura” che si è verificata nel mondo dei servizi digitali ha avuto un riflesso sulle attività standard dell’industria delle telecomunicazioni: la digital revolution ha  infatti  cambiato molto il  mondo degli standard per il layer dei servizi ed applicazioni negli ultimi 15 anni. In passato, l’”Application Layer” era sotto il completo controllo dell’Operatore. Solo l’Operatore era capace di fornire servizi all’utente finale. L’interoperabilità (e “interoperabilità” significa “standard di riferimento”) era necessaria a tutti i livelli, rete e servizi. Accadde che gli OTT hanno preso l’egemonia sull’“Application Layer” e sul “Control Layer”, relegando il business degli operatori al solo “Network Layer”. E non solo, ma gli OTT hanno anche “ri-disegnato” il mondo dei servizi e oggi gli OTT sono i principali fornitori di servizi. L’interoperabilità è ancora necessaria e obbligatoria  al livello di rete, ma per l’“Application Layer” è diventata “utile” nel migliore dei casi.

 

Figura 2 - Business degli OTT e degli Operatori a confronto

4 - La reazione dell’industria delle telecomunicazioni

L’industria delle telecomunicazioni (e con essa incluso l’ecosistema degli standard per le telecomunicazioni) ha reagito focalizzandosi sull’arricchimento e valorizzazione degli asset degli Operatori, quelli esistenti (come la rete, i sistemi di billing, i sistemi di customer care, identità e autenticazione, sicurezza) e identificandone dei nuovi (come l’identità singola, gestione del traffico attraverso policy control e deep-packet inspection, qualità end-to-end, qualità differenziata, Network API, dati). Gli OTT sono stati bravi ad aggirare le limitazioni derivanti dall’impossibilità di controllare le policy di rete e avere accesso alle informazioni del livello di rete. Oggi la banda non è più un problema in termini di offerta di servizi real-time per la rete fissa e lo stesso sta già accadendo per la rete mobile con il dispiegamento del 4G (e prossimamente il 5G). In aggiunta, gli OTT riescono a funzionare senza informazioni provenienti dalla rete, facendo affidamento solo sugli end-points su cui possono avere il controllo. Per esempio, per l’autenticazione, la stessa user experience può essere resa all’utente finale, usando i cookies del browser web (con un livello di sicurezza inferiore, ma senza che gli utenti ne percepiscano la differenza).

 

5 - Application Layer: i punti chiave per il mondo degli standard

Il risultato di questa trasformazione è un ecosistema più complesso che evolve sempre più velocemente man mano che ci avviciniamo al futuro in cui tutte le comunicazioni (un tempo solo tra le persone, ma oggi sempre più tra le “cose”) saranno Internet-based.
Per star dietro a questi cambiamenti, è importante realizzare quanto differentemente rispetto a oggi, gli standard futuri debbano essere strutturati. Come raggiungere questo obiettivo e stare al passo con i tempi? Attraverso un approccio con più sfaccettature, tra cui:

  • assicurarsi che il processo di standardizzazione sia accompagnato da tool per sviluppatori in un ambiente di servizi aperto e programmabile, attraverso API (Application Programming Interface) esposte sia a livello di rete sia a livello di terminale;
  • adottare approcci agili e collaborativi per lo sviluppo di enabler “alla velocità di Internet”, che risultino nel rendere disponibile del codice base che possa accelerare lo sviluppo dell’enabler;
  • estendere il focus su servizi per nuovi segmenti di mercato come Machine-to-Machine, Healthcare, Public Safety, e conseguentemente, assicurarsi che il processo di standardizzazione sia multi-stakeholder, ossia non più un processo che vede coinvolti soltanto operatori e fornitori del mondo telco, ma bisogna considerare tale processo come un effort "multi-stakeholder“ (Agenzie Governative, utenti, Enti regolatori, operatori, fornitori, aziende automobilistiche, municipalità, OTT, ecc.), per avere l’opportunità per molti altri gruppi di essere coinvolti nel definire i “requisiti” per i prossimi standard, e specialmente essere sicuri che qualsiasi standard tecnologico emerga, esso non vincoli alcun modello di business né alcuna tipologia di interazione applicazione/utente;

Inoltre è importante per gli SSO non essere soli nel loro ruolo di stabilire standard di riferimento, ed è fondamentale riconoscere l’importanza di lavorare con altre organizzazioni per lavorare congiuntamente sulle stesse attività o su aspetti complementari in maniera coordinata e all’interno di un quadro di riferimento cooperativo.
Infine, un valore incommensurabile per un SSO è rappresentato dal gruppo di persone, delegati esperti delle varie tecnologie. Le associazioni SSO rappresentano un luogo, una struttura dove i delegati possono incontrarsi, condividere le attività su cui stanno lavorando, discutere, identificare punti di vista comuni, definire specifiche tecniche che saranno più di valore che se specificate da una sola azienda.

 

6 - Le Network API negli standard

Le API (Application Programming Interface, in italiano Interfaccia di Programmazione di un'Applicazione) sono da tempo note agli sviluppatori come una modalità di interazione tra componenti software, ossia uno strumento tecnico attraverso il quale semplificare e risolvere il problema dell’interoperabilità tra moduli o piattaforme. Con il termine Network API (o NetAPI) si intendono le API che descrivono ed espongono funzionalità erogate dall’infrastruttura di un operatore Telco e che abbiano caratteristiche di resilienza ed utilità di utilizzo anche da parte di terze parti. Le Network API sono nate a fine degli anni ’90 nell’ambito dell’iniziativa Parlay (Figura 3), un consorzio guidato da BT. L’obiettivo iniziale di Parlay era la definizione di meccanismi ed interfacce per “aprire” la Rete Intelligente dell’operatore verso applicazioni di provider esterni, al fine di soddisfare una richiesta elaborata dall’authority britannica per le telecomunicazioni. 

 

Figura 3 - Le Network API negli standard

Seguendo l’evoluzione tecnologica delle API, dalla metà degli anni 2000 in ambito di lavoro congiunto tra 3GPP e Parlay sono state standardizzate le API OSA (Open Service Architecture) Parlay X Web Services, attività poi confluita nel 2008 in OMA (Open Mobile Alliance). OMA è l’ente di riferimento per la standardizzazione dei cosiddetti Service Enabler, ossia elementi abilitatori per realizzare servizi per l’utente finale. OMA ha istituito un “API Programme” ed è riconosciuta come riferimento per la definizione delle API e del modello di esposizione (OMA Service Exposure Framework). Dal 2008 ad oggi, OMA ha definito oltre 25 Network API con paradigma REST che riguardano le principali funzionalità Telco “esponibili” dagli operatori Telco verso terze parti (Content Service Provider, Developers, Business Partners): messaging, audio call, payment, terminal status, customer profile, ecc. Tra le ultime Network API rilasciate da OMA citiamo: la Roaming REST API, che viene utilizzata da tutti gli operatori europei per l’interconnessione con gli Alternate Roaming Provider al fine di ottemperare alla nuova regolamentazione Roaming in vigore dal Luglio 2014; la QoS REST API che abilita un’applicazione a controllare la qualità del servizio (QoS) applicata alla connettività di un utente finale su base temporanea. Tra le NetAPI in fase di specifica troviamo:

  • la Zonal Presence REST API, che permette l’accesso di terze parti ad informazioni su utenti che si trovano in determinate aree geografiche (es. in una determinata zona o in uno dei negozi di una particolare catena);
  • la Twinning REST API che permette di associare un “secondary” device ad un “primary” device, di modo che il secondary device assuma l’identità del primary device e quindi sia in grado di ricevere chiamate e messaggi destinati al primary device, originare chiamate e messaggi ed essere percepito dalla destinazione come se fosse il primary device.
 

7 - Le Network API in Telecom Italia e nel mondo

Prima di passare a cosa hanno fatto o stanno facendo altri Operatori sul tema delle Network API, si rende opportuna una precisazione. A volte si trovano in dei report o blog su Internet delle considerazioni su confronti tra le API esposte da attori Web (quali Amazon, Google) e le API esposte dagli Operatori, ma le Network API che un Operatore può esporre sono e devono essere diverse da quelle esposte da Amazon o Google. Il Service Exposure di Telecom Italia (nato circa dieci anni fa per implementare l’esposizione di funzionalità verso i MVNO) è considerato nel contesto internazionale un caso di successo di esposizione di API da parte di un Operatore. La scelta di Telecom Italia è stata infatti di creare un’infrastruttura di esposizione verso business partner e per utilizzo interno. Così come sono ritenute esperienze di successo quelle di Portugal Telecom e TELUS, molto simili al Service Exposure di Telecom Italia. Telefonica è identificata invece come esempio di fallimento (riconosciuto e ammesso) di esposizione delle API verso i developers (long tail), con quella che era la loro iniziativa “BlueVia”. Telefonica ha spostato il focus verso un utilizzo interno delle API, promuovendo in particolare le Payment e Communication API.

 

Figura 4 - Architettura del Service Exposure di Telecom Italia

AT&T ha messo in piedi sicuramente il più rilevante ecosistema di esposizione API verso “developer”, con un portale ed eventi, quali Summit e Hackaton, aperti ai developers, ma non è chiaro che livello di business AT&T faccia con questa iniziativa, e sembra piuttosto che l’iniziativa continui a fiorire solo grazie ai capitali che AT&T continua ad investirci.
In tutti i casi di successo di esposizione di Network API è stato molto importante e decisivo l’impatto in termini di processi e governance aziendale come elemento abilitante: non si tratta quindi solo di una questione tecnologica, ma anche di mindset che l’Operatore deve assumere: anche su questo Telecom Italia ha fatto scuola.
Le API pubbliche offerte sul Web dagli OTT sono invece tipicamente utilizzate per creare nuovi ecosistemi e per supportare offerte digitali su Web Marketplace.
Le Network API oggi disponibili ed esposte dal Service Exposure sono più di 50, raggruppate in aree funzionali, con statistiche di utilizzo che riportano circa 2 miliardi di invocazioni di API per mese distribuita tra terze parti (13%) ed applicazioni interne a Telecom Italia (87%).

 

Figura 5 - Network API esposte dal Service Exposure di Telecom Italia

8 - Un framework standard per le applicazioni Web:  specifica OMA GotAPI

La Open Mobile Alliance ha rilasciato lo scorso febbraio l’enabler OMA GotAPI (Generic Open Terminal API Framework) Version 1.0, un package di specifiche che può influenzare la nostra vita di tutti i giorni. Noi tutti abbiamo uno smartphone e attraverso il nostro smartphone siamo sempre connessi ( “Smartphone Society”). E viviamo in un mondo connesso, un mondo di Internet delle Cose (“Internet of Things - IoT”): smart TV, tablet, dispositivi wearable, e PCs, ma anche elettrodomestici, apparati di illuminazione e di riscaldamento, così come dispositivi di monitoring delle nostre auto controllati dalle compagnie di assicurazione che permettono agli utenti di pagare il premio assicurativo solo per la quantità di kilometri effettivamente percorsi. Le previsioni dicono che per l’anno 2020 ci saranno 50 miliardi di dispositivi connessi alla Big Internet. L’aspettativa è che gli smartphone saranno connessi a tutti questi dispositivi e che applicazioni che girano sugli smartphone permetteranno agli utenti di interagire con questi dispositivi attorno a loro per controllarli, raccogliere dati da loro a fini di analisi e utilizzare i risultati di questa analisi per migliorare la vita di tutti i giorni degli utenti.

 

Figura 6 - GotAPI (Generic Open Terminal API Framework) di OMA

Connettere dei dispositivi ad uno smartphone richiede delle applicazioni dedicate che devono essere installate nello smartphone e che includano i driver per il controllo dei device, con differenti versioni di tali applicazioni per ciascun sistema operativo, arrivando così a considerevoli costi di sviluppo. È qui che il GotAPI di OMA può giocare un ruolo chiave. OMA GotAPI definisce un framework per applicazioni Web (in esecuzione sullo smartphone) per accedere a dispositivi esterni attraverso delle “device API” tramite tecnologie Web. Questo permette agli sviluppatori di creare applicazioni (usando tecnologie Web) compatibili con una varietà di dispositivi. Gli utenti possono avere applicazioni che girano nei browser dei loro smartphone, che possono accedere a dispositivi esterni consistentemente per qualsiasi sistema operativo, per esempio accedendo ad un monitor o ad una stampante dalla stessa applicazione attraverso le stesse device API. Ovviamente, lo smartphone dovrà avere a bordo il plug-in che permetta allo smartphone stesso di interagire con il dispositivo esterno, ma l’applicazione Web in esecuzione sullo smartphone (unica per tutti i sistemi operativi) potrà interagire con tutti i dispositivi esterni per i quali è presente il plug-in. Questo dà agli sviluppatori l’opportunità di creare un nuovo ecosistema di dispositivi ed applicazioni interoperabili, di cui gli utenti potranno beneficiare.
Lo sviluppo del OMA GotAPI è stato fortemente supportato da NTT DoCoMo, che ha anche rilasciato il codice open source del loro GotAPI-compliant software [nota 2]. NTT DoCoMo ha anche annunciato ad Aprile la creazione del Device WebAPI Consortium [nota 3], al fine di promuovere la diffusione (inizialmente in Giappone, ma poi world-wide) del OMA GotAPI: tra i membri del consorzio ci sono NEC, CASIO, SHARP, Sony, SoftBank, Microsoft Japan, Vuzix, Fujitsu.

 

Conclusioni

In questo attuale contesto di mercato fluido ed innovativo, la continua evoluzione tecnologica dei servizi digitali insieme al ruolo predominante degli OTT e Web Companies avrà sempre più impatti dirompenti nella Social Digital Life e gli Operatori dovranno sempre più raccogliere tali sfide contribuendo all’erogazione di servizi agili, affidabili e di elevata qualità.
Come descritto in questo articolo, anche se in un accezione differente dagli standard di rete, sviluppare specifiche standard per il Service Layer può costituire ancora un elemento importante per accelerare la diffusione di alcuni servizi, soprattutto se tali specifiche sono progettate con approccio differente dal passato. Lo standard assomiglierà sempre più a qualcosa che prende forma man mano che la si usa. Tentare di imporre standard in un ecosistema così dinamico non può funzionare. D’altro canto, focalizzandosi su design pattern e approcci condivisi che possono divenire nel tempo linee guida e  diventare “standard” attraverso il suo utilizzo. E questo approccio è simile a quello che accade nel mondo open source e per gli standard Internet.
Il ruolo degli Operatori sarà quindi quello di facilitare questo nuovo modello, contribuendo con requisiti meno tecnologici ma più di business in un ecosistema di coopetion (cooperation + competition).

 


comments powered by Disqus