Si chiama mSpot il portale che porta la musica sulle nuvole per seguire gli utenti ovunque, su piattaforma Apple, Android, o Microsoft. Ma quando dalle nuvole la musica ripiove sulla terra intasa le solite reti degli operatori (mobili e non) che non hanno modelli di business adeguati a sopportare questo nuovo tipo di traffico e a trarne vantaggio.

Il cloud computing non è una novità: è argomento di ricerca da più di 10 anni ed è entrato nell’uso comune grazie alla diffusione di applicazioni e servizi online di successo come quelli offerti da Amazon e, soprattutto, da Google (Google Apps). Se ce ne fosse bisogno, una conferma indiretta della diffusione del cloud computing viene dal recente successo dei netbook .

L’iniziativa di mSpot apre però uno scenario nuovo, perchè spinge gli utenti a depositare in Internet i propri file multimediali, indipendentemente dal desiderio di condividerli con altri o dall’esigenza di elaborarli. La motivazione principale è la comodità di averli sempre “a portata di mano”.

E’ questa la rivoluzione: pensare che ciò che sta in rete sia più a portata di mano di un file sulla memoria di massa del nostro smart phone o del nostro notebook.

Quando si sviluppano sistemi o applicazioni di rete si devono fare i conti con la capacità di elaborazione, lo spazio di archiviazione e la capacità di comunicazione. Di solito si ricorre alla rete quando la comunicazione è essenziale (applicazioni condivise) o quando servono capacità di elaborazione o spazio di storage tali da giustificare il costo della comunicazione. Fino ad ora ascoltare musica non era ritenuta un’attività che rendesse vantaggioso l’uso della rete se non per “scaricare” nuovi file. Infatti le capacità di elaborazione e di memoria dei dispsitivi ultraportatili sono più che adeguate allo scopo. Il fatto di ricorrere alla nuvola solo per comodità, presuppone che la comunicazione tra la nuvola e il proprio dispositivo abbia un costo trascurabile, al punto da riscaricare lo stesso file multimediale ogni volta che lo si vuole ascoltare. Al momento non è così: scaricare un file multimediale ha un costo. Se questo costo non è percepito dall’utente finale, qualcuno deve comunque farsene carico perchè il modello sia sostenibile.

Non escludo che il via-vai di file multimediali tra le nuvole e la terra possa essere un’applicazione vincente, nè che possa generare profitti e utilità, ma di due cose sono convinto. La prima è che tenere i file distanti da chi li deve usare è intrinsecamente antieconomico (la diseconomia è il prezzo da pagare per offrire agli utenti la comodità di cambiare smartphone senza trasferire i file), la seconda è che l’equilibrio tra gli interessi in gioco si può trovare solo con modelli che tengano conto dei costi. In una rete di accesso neutrale si può cercare di instaurare questo equilibrio senza che le nubi minaccino gli operatori.

Riferimenti

• “mSpot: music that follows you“, sito ufficiale, 2010.
• Ivan Fulco, “Mp3 e hard disk addio: la musica va sulle nuvole“, Repubblica.it, 21 dicembre 2010.

Considerando la maturità della normativa finlandese sul wireless viene da pensare che non sia per una semplice coincidenza che la sigla del Wi-Fi termina con la sigla della Finlandia…

In particolare, per quanto ne so, la normativa finlandese è la prima a regolamentare le comunità wireless, fin dal 2007. Si veda il WLAN memorandum della Finnish Communications Regulatory Authority.

Nel frattempo in Italia vengono ancora visti come pionieri ignorati dalla  normativa i ragazzi di Ninux che da anni si organizzano spontaneamente per creare reti wireless comunitarie sui tetti di Roma a partire dalla costruzione dei nodi. E giustamente ne parla Nòva. Consiglio di visitare il sito e il blog di Ninux a chiunque voglia saperne di più sulle community networks.

Da qualche mese è partito un progetto europeo denominato ULOOP (user-centric wireless local loop) che studia i rapporti tra comunità wireless e reti di accesso ad Internet, per metterne in luce le potenzialità e abilitarne il pieno utilizzo. Il progetto tratterà non solo aspetti tecnologici, ma anche sociali, economici e legali.

Riferimenti

• Fi.Co.R.A., “Application of the Communications Market Legislation to the Provision of Wireless Broadband Connections“, WLAN Memorandum, 21 agosto 2007.
• Alessandro Longo, “Wi-Fi di condominio“, Nòva24, 16 dicembre 2010.
• Ninux.org
• ULOOP: User-Centric Wireless Local Loop, FP7 – ICT project

Il 21 dicembre si e’ svolto a Urbino un incontro di aggiornamento sulla gestione avanzata di flussi multimediali organizzato dal Corso di Laurea in Informatica Applicata e da NeuNet. Anche questa volta si è trattato di un esperimento condotto in pubblico dagli sviluppatori di openBOXware, la piattaforma open source per la gestione di flussi multimediali.

In poco più di un’ora Lorenz e Saverio sono riusciti a programmare e ad illustrare ai partecipanti tutti i plugin per openBOXware necessari a dimostrare la fattibilità di innovative modalità di distribuzione di contenuti multimediali.

Per capire il senso del’incontro potete dare un’occhiata alle slides proiettate nel corso della presentazione. La prima parte illustra sinteticamente l’architettura di openBOXware, la seconda parte discute i problemi di banda che affliggono le reti di accesso e le conseguenti esigenze di gestione dei flussi multimediali, la terza parte mostra la struttura della demo ed enumera i plugin di cui è stata data dimostrazione pratica.

Chi avesse già assistito a precedenti incontri su openBOXware o a presentazioni sul multicast wireless e sulle reti di accesso neutrali può risparmiarsi le prime due parti e passare direttamente alla terza, a cui è dedicato il resto di questo post.

L’esperimento

Lo schema dell’esperimento è illustrato di seguito. I blocchi azzurri rappresentano 5 computer sui quali è installato openBOXware. Tutti i computer appartengono alla stessa rete locale. I riquadri gialli rappresentano i plugin per openBOXware che consentono alle 5 istanze di scambiarsi flussi multimediali di diversa natura, rappresentanti dalle frecce. Le frecce nere rappresentano collegamenti unicast, mentre quelli rossi collegamenti multicast. Le frecce più spesse rappresentano flussi a banda larga (superiore a 1Mbps).

Hop 1:
Sulla macchina A gira un’istanza di openBOXware che implementa un server HTTP [1] che rende disponibile un filmato in un container Mp4 (video H.264 e audio AAC). Sulla macchina B openBOXware riceve il filmato attraverso un  media source HTTP [2] che si comporta da client.

Hop 2:
Sulla macchina B il flusso ricevuto dal media source HTTP è ridiretto da openBOXware senza transcodifica su un media target TCP [3] che si comporta da client mandando lo stream alla macchina C in modalità push. La macchina C riceve lo stream attraverso un media source TCP [4] configurato come server.

Hop 3:
L’istanzie di openBOXware che gira sulla macchina C rilancia il video H.264 in un container RTP in modalità multicast su UDP attraverso l’apposito plugin RTP media target [5]. Il descrittore SDP è reso disponibile dal server HTTP [1] che gira sulla macchina A. Sulla macchina E gira un media source SDP [6] che recupera il descrittore dal server HTTP e si collega al gruppo multicast a cui invia il flusso il media target RTP.

La macchina E emula il comportamento di un utente non autorizzato a ricevere il video. Per questo il flusso generato dalla macchina C è corrotto in modo da non poter essere fruito senza ulteriori informazioni trasmesse in unicast direttamente dalla macchina A ai soli utenti registrati. Nel nostro esempio il flusso multicast non contiene la traccia audio.

La macchina D rappresenta un utente registrato presso il server [1] e autorizzato a ricevere il video.  Il plugin per openBOXware che gira sulla macchina D non è un semplice media source, ma un’applicazione [7] che include un media source SDP per la ricezione di video in multicast, una custom pipeline UDP per la ricezione in unicast del flusso audio generato dal server [1] in modalità push a seguito della prima richiesta del video, e un widget srt per la riproduzione dei sottotitoli scaricati in unicast http dallo stesso server [1].

Scenari

L’esperimento condotto in laboratorio è esemplificativo della possibilità di implementare meccanismi evoluti per la distribuzione di flussi multimediali lavorando ad un livello di astrazione che massimizza la produttività e la portabilità del codice, e utilizzando la stessa piattaforma software in tutti gli elementi della catena. Nel caso specifico, la macchina A rappresenta un generico server disponibile in rete, la macchina B rappresenta un proxy, la macchina C rappresenta un gateway unicast-multicast, la macchina D rappresenta un client autorizzato alla fruizione di un contenuto on demand, la macchina E rappresenta un client non autorizzato. L’esempio mostra come sia possibile:

• sfruttare il multicast per ottimizzare l’occupazione di banda sul penultimo miglio consentendo a più utenti (autorizzati) di ricevere lo stesso flusso,
• implementare tecniche di protezione che consentano di limitare la fruizione dei contenuti ai soli utenti registrati,
• personalizzare/localizzare l’audio e/o i sottotitoli attraverso flussi unicast sincronizzati al flusso video multicast,
• rendere trasparente all’utente il rilancio locale in multicast attraverso descrittori SDP.

Corre voce che nel consiglio dei ministri di oggi si sia tornati a parlare della liberalizzazione del Wi-Fi in occasione dell’approvazione del milleproroghe, il cui testo non è ancora disponibile. Le dichiarazioni dei politici sono contraddittorie e i commenti dei giornali e della rete non possono fare chiarezza su ciò che non si conosce ancora. Alle tante voci aggiungo la mia.

Il comunicato ufficiale pubblicato dal governo a valle del consiglio dei ministri n. 120 non fa alcun riferimento alla liberalizzazione dell’accesso ad Internet. Guardando l’elenco dei provvedimenti discussi e approvati (ma non ancora pubblicati) l’unico che ragionevolmente potrebbe avere a che fare con l’articolo 7 della Legge 155/05 (il cosiddetto decreto Pisanu) è il milleproroghe, che genericamente si intitola “Proroga di termini previsti da disposizioni legislative“.

Se la liberalizzazione del Wi-Fi è stata discussa nell’ambito del mille proroghe, dovrebbe avere a che fare con una scadenza. Nell’articolo 7 del  Decreto Pisanu l’unica scadenza è quella che riguarda l’obbligo di licenza per il Wi-Fi pubblico, prescritto dal comma a. Quindi a rigore dovrebbero esserci due possibilità:

1. il comma a dell’Art. 7 è stato prorogato, e quindi per il 2011 sarà tutto come prima;
2. il comma a dell’Art. 7 non è stato prorogato, e quindi dal primo gennaio non sarà più necessario richiedere la licenza al questore per accendere hot spot Wi-Fi pubblici.

L’abrogazione in toto dell’Art. 7 è poco realistica per due ragioni: la prima è che il milleproroghe mi sembra uno strumento tecnicamente inadeguato per abrogare disposizioni di legge che non hanno scadenza, la seconda è che mi stupirebbe non trovare traccia nel comunicato ufficiale del governo di un provvedimento tanto atteso e discusso.

Quanto ho appena affermato è in contrasto con le dichiarazioni che sono circolate oggi, ma aspetto che a smentire le mie congetture sia il testo dei provvedimenti.

Sei miliardi di dollari non bastano a Google per acquisire Groupon, il sito che gestisce offerte locali online. Il fatto che si tratti dell’offerta più alta di sempre e che sia stata rifiutata, la dice lunga sul valore della dimensione territoriale della rete, che è in buona parte ancora inesplorata.

Il collo di bottiglia delle reti è il penultimo miglio, quello che collega le centrali alle dorsali nelle reti degli operatori. E’ quanto affermava lo scorso ottobre Stefano Quintarelli su Nova24. Sono d’accordo con lui, a parte per il fatto che mi piace chiamare “penultimo miglio” quello che lui chiama “secondo”.

Condivido anche l’idea che la soluzione per superare il collo di bottiglia non vada ricercata in complesse politiche di priorità, ma nella rimozione della scarsità. Per arrivarci occorrono modelli di business che motivino e ripaghino gli investimenti necessari. Prima di arrivarci, non si può fare altro che usare al meglio la banda disponibile.

Il corso di laurea di Informatica Applicata dell’Università di Urbino organizza un incontro di aggiornamento tecnico su openBOXware 1.0.

openBOXware
gestione avanzata di flussi multimediali
Urbino, Collegio Raffaello, Piazza della Repubblica 13
Martedi’ 21 dicembre 2010, ore 14:00 – 18:00
http://www.openboxware.net/

L’incontro sara’ interamente dedicato alla gestione avanzata di flussi multimediali. Verra’ data dimostrazione pratica delle potenzialita’ di openBOXware nella gestione di: streaming http, streming UDP, streaming multicast, flussi multipli, place shifting, controllo remoto, applicazioni multimediali distribuite.

La registrazione gratuita puo’ essere effattuata utilizzando l’apposito modulo online.

Segnalo il sito su questo blog sia perchè sono direttamente coinvolto insieme a Lorenz Klopfenstein e Saverio Delpriori, sia perchè le modalità di gestione di flussi multimediali di cui verrà data dimostrazione sono condizioni abilitanti per lo sviluppo di applicazioni innovative su reti di accesso neutrali.

France Telecom, Telecom Italia, Vodafone e altri operatori sentono il bisogno di nuovi modelli di business per sostenere il traffico generato sulle proprie reti dalla crescente offerta (e domanda) di contenuti e applicazioni a banda larga.

La situazione e’ ben spiegata negli articoli apparsi su Bloomberg ( Matthew Campbell and Jonathan Browning, 8 dicembre 2010) e su Repubblica.it (Alessandro Longo, 10 dicembre 2010).

In sostanza quello che chiedono gli operatori e’ che i fornitori di contenuti e servizi (Google, Apple, Facebook e gli altri) contribuiscano a pagare il traffico. Questo sovverte il modello di business orientato all’accesso e all’integrazione verticale e apre la strada ad un nuovo modello orientato ai servizi. Al momento la situazione sembra preludere ad uno scontro tra operatori e service provider, e riapre il dibattito sulla neutralita’.

Ma superando le polemiche e i contrasti apparenti quello che chiedono gli operatori sembra proprio l’adozione del modello di “neutral access network” (NAN) che e’ l’oggetto di questo blog. Forse i tempi sono maturi per approfondire il dibattito e per sperimentare sul campo il modello, conciliando le esigenze di operatori e fornitori di servizi a vantaggio dello sviluppo sostenibile delle reti e nel rispetto della neutralita’.

Alessandro Bogliolo

Riferimenti:

• Alessandro Longo, “Tlc, gli operatori fanno fronte unito: Facebook, Google & C. ci paghino“, Repubblica.it, 10 dicembre 2010.
• Matthew Campbell and Jonathan Browning, “Apple, Google Asked to Pay Up as Mobile Operators Face Data Flood“, Bloomberg, 8 dicembre 2010.
• Alessandro Bogliolo, “Introducing Neutral Access Networks“, in Proceedings of the Conf. on Next Generation Internet Networks (NGI-09), 2009.

IDEM è il nome dell’infrastruttura di autorizzazione e autenticazione federata della rete GARR. Il 2 e 3 dicembre il MIUR ha ospitato il secondo IDEM day, nell’ambito del quale si è parlato di aunteticazione federata per l’accesso ad Internet. Io sono stato invitato a riparlare delle linee guida del tavolo tecnico Università Digitale, e ne ho approfittato per aggiornare le riflessioni sulla liberalizzazione del Wi-Fi alla luce della complessa situazione politica.

Se siete interessati, ecco le slide, ma in estrema sintesi è sempre meno probabile che cambi davvero qualcosa da qui alla fine dell’anno.