Negli ultimi anni, si è assistito ad una sempre più crescente diffusione di dispositivi mobili (smarphone, PC, tablet, etc.) ed, in particolar modo, ad un aumento delle loro capacità di processamento e di memoria. Tuttavia, tali caratteristiche sono spesso non sfruttate a pieno. L'idea alla base del Fog Computing è quella di usare le risorse non utilizzate dei dispositivi nelle vicinanze, per poter creare un server locale di piccole dimensioni con bassi tempi di latenza. Scenari plausibili sono per esempio l'insieme dei passeggeri di un mezzo pubblico, oppure gli studenti all'interno di un aula, o ancora dei clienti di una caffetteria.
Nell'ambiente delle applicazioni per smartphone, sono inoltre di particolare interesse gli scenari, quali per esempio il processamento di immagini o di video, dove i task eseguibili (le funzioni) sono noti a priori ed, in un contesto di Fog Computing come quello delle femtocloud, non serve passare ai vari helper in input il codice degli stessi task. Uno scenario molto simile a quello appena descritto è presente nel contesto della Network Function Virtualization (NFV). L'architettura di rete NFV sfrutta il concetto di virtualizzazione delle funzionalità di rete, sia fissa che mobile, diventano infatti applicazioni software, denominate VNF (Virtual Network Function), che l'operatore può istanziare su server COTS (Commodity Off-The-Shelf).
Il progetto ha come obiettivo quello di affrontare un problema così determinato mediante un approccio di tipo NFV, sfruttando le similitudini tra le due architetture e la minore complessità nella fase di scheduling di quest'ultima. Ad fase iniziale di studio e valutazione di modelli per l'analisi del problema, si procederà con l'implementazione di un testbed sperimentale.
Nell'ambiente delle applicazioni per smartphone, sono di particolare interesse gli scenari, quali per esempio il processamento di immagini o di video, dove i task eseguibili (le funzioni) sono noti a priori ed, in un contesto di Fog Computing come quello delle femtocloud, non serve passare ai vari helper in input il codice degli stessi task. Esempi di tali funzioni nell'ambito dell'elaborazione delle immagini sono la classificazione, la regressione, l'estrazione di caratteristiche, il riconoscimento di pattern, il riconoscimento dei contorni o la segmentazione. [4] Le richieste, che potrebbero giungere al controller, possono quindi differenziarsi solo per la composizione di tali funzioni, ovvero per il set di task richiesti e per il loro ordine di esecuzione.
Uno scenario molto simile a quello appena descritto è presente nel contesto della Network Function Virtualization (NFV). Generalmente le funzioni di una rete di comunicazione vengono implementate in maniera hardware in appositi dispositivi, detti "middlebox", installati in ogni nodo d¿accesso. Al contrario, l'architettura di rete NFV sfrutta il concetto di virtualizzazione delle funzionalità di rete, sia fissa che mobile, diventano infatti applicazioni software, denominate VNF (Virtual Network Function), che l'operatore può istanziare su server COTS (Commodity Off-The-Shelf). La connessione tra loro serve a formare dei servizi di comunicazione (Service Function Chain). La NFV introduce un sostanziale cambio di paradigma nel modo in cui vengono realizzate le reti di telecomunicazioni, spezzando il legame tra hardware e software presente negli apparati odierni. Trattando quella che è l'architettura NFV, così come prevista dall'ETSI (European Telecommunication Standards Institute), è possibile individuare tre principali domini: il dominio delle funzioni di rete virtualizzate (VNF - Virtual Network Functions), generalmente realizzate come moduli software in esecuzione su una o più virtual machine, il dominio delle NFVI (NFV Infrastructure), ovvero delle infrastrutture fisiche dove vengono dispiegate, gestiste ed eseguite le VNF, ed infine il dominio MANO (MANagement and Orchestrator), che è l'ambiente che si occupa di ricevere e gestire le richieste nonché dell'orchestrazione delle risorse infrastrutturali e delle funzioni virtualizzate.
Soffermandoci su quelle che sono le similitudini tra l'ambiente appena descritto e le femtocloud, in particolare nello scenario di elaborazione d'immagini, è possibile pensare ad un utilizzo dell'approccio di tipo NFV per poter effettuare l'opera di scheduling dei vari task sui dispositivi, sfruttando soluzioni già proposte per problemi di placement e routing delle funzioni di rete virtualizzate. E' importante notare come questo tipo di approccio porterebbe ad una soluzione del problema di minore complessità e come sia possibile esportare elementi architetturali delle NFV nel contesto delle femtocloud. In un contesto combinato tra le due architetture, vi è una naturale associazione tra il controller ed il MANO, come entità centrali per la gestione delle richieste ed assegnazione dei task oltre che per l'orchestrazione delle risorse di calcolo, e tra le infrastrutture NFVI e gli helper, che rappresentano l'insieme dei dispositivi su cui eseguire i vari task. Mentre essendo noto a priori il set di funzioni richiedibili, è facile immaginare che quest'ultime siano già presenti sugli helper, evitando quindi il trasferimento del codice di ogni task. In questo contesto, i compiti del controller/MANO saranno quello di schedulare i diversi task sui vari helper e di raccogliere i dati risultanti, tenendo conto delle capacità richieste e delle risorse messe a disposizione, senza tralasciare il vincolo legato alla permanenza dell'helper stesso all'interno del cluster.
In letteratura, non sono presenti lavori che prevedano un approccio di tipo NFV a problemi di Fog Computing che riguardano un set di task prefissato. L'innovatività del progetto risiede, quindi, nel particolare modo di affrontare un problema così determinato e nell'integrazione delle due architetture in un unico sistema.
[4] Rafael Gonzalez, "Digital Image Processing, 3rd (2008)", Pearson Hall