Multi-access Edge Computing

L’edge computing permette di hostare le applicazioni sulla parte edge della rete, il pi`u vicino possibile agli utilizzatori e ai dati generati dalle applicazioni. L’edge computing `e riconosciuto come uno dei pilastri chiave per soddisfare i KPI del 5G, soprattutto per quanto riguarda la bassa latenza e l’efficienza della larghezza di banda [24].

ETSI ISG MEC (Industry Specification Group for Multi-access Edge Computing) `e la sede degli standard tecnici per l’edge computing. In [2.25] sono raffigurati gli elementi funzionali e i punti di riferimento tra essi dell’ar- chitettura di un sistema MEC [25].

Figura 2.25: Architettura funzionale di un sistema Multi-access Edge Computing

I punti di rifermento possono essere raggruppati in tre categorie: • quelli riguardanti le funzionalit`a della piattaforma MEC, Mp • quelli legati alla gestione, Mm

• quelli che connettono entit`a esterne, Mx.

Di seguito verranno presentati i diversi blocchi funzionali.

MEC host `e un’entit`a che contiene la MEC platform e l’infrastruttura virtualizzata che fornisce capacit`a di rete, computazione e memorizzazione alle applicazioni MEC. L’infrastruttura virtualizzata contiene anche un piano dati che esegue le regole sul traffico ricevute dalla MEC platform e indirizza il traffico tra diverse applicazioni, servizi, DNS server, reti 3GPP o meno, LAN e reti esterne.

MEC platform `e responsabile delle seguenti funzioni:

• offrire un ambiente in cui le applicazioni MEC possano scoprire, pub- blicare, utilizzare e offrire servizi;

• ricevere regole sul traffico dal MEC platform manager, applicazioni o servizi e orchestrare il piano dati mediante queste;

• ricevere record DNS dal MEC platform manager e configurare DNS server/proxy in accordo con queste;

• ospitare servizi MEC.

Le MEC application vengono eseguite come macchine virtuali sull’in- frastruttura di virtualizzazione fornita dall’host MEC e possono interagire con la piattaforma MEC per utilizzare e fornire servizi MEC. Possono avere un certo numero di regole e requisiti associati, come risorse richieste, latenza massima, servizi necessari o utili, eccetera. Questi requisiti sono convali- dati dal MEC system level management e possono essere assegnati a valori predefiniti se mancanti.

Il MEC system level management `e composto dal Multi-access edge orchestrator, dall’ Operations Support System, OSS e dal User application lifecycle management proxy.

Il primo, `e la parte principale del sistema ed `e responsabile di:

• mantenere una visione del sistema MEC basata su MEC host, risorse disponibili, servizi MEC disponibili e topologia;

• on-boarding dei pacchetti delle applicazioni, controllo dell’integrit`a e dell’autenticit`a di questi, convalida delle regole e dei requisiti dell’ap- plicazione e, se necessario, l’adeguamento degli stessi per conformarsi alle politiche dell’operatore. Inoltre, mantiene un registro dei pacchetti on-boarded e prepara i virtualization infrastructure manager alla gestione delle applicazioni;

• selezionare i MEC host appropriati su cui istanziare le applicazioni in base ai vincoli, come latenza, risorse e servizi disponibili;

• avviare l’istanziazione e la terminazione delle applicazioni;

• avviare il riposizionamento delle applicazioni quando supportato e se necessario.

Il secondo, fa riferimento all’OSS dell’operatore. Riceve di istanziazione o terminazione di applicazioni tramite il CFS portal o le device applica- tions e decide se autorizzarle o meno. Le richieste autorizzate sono inoltrate al Multi-access edge orchestrator per essere ulteriormente processate. Se supportato, l’OSS riceve anche richieste dalle device applications per il trasferimento delle applicazioni tra Cloud esterni e il sistema MEC.

Il terzo consente alle device applications di richiedere l’on-boarding, l’istanziazione, la terminazione delle applicazioni utente e se supportato il ri- posizionamento di queste all’interno o all’esterno del sistema MEC. Permette

anche di informare le device applications in merito allo stato delle appli- cazioni utente. Un’applicazione utente `e un’applicazione MEC istanziata su un sistema MEC a seguito di una richiesta effettuata da un utente tramite device application.

Il MEC host level management `e composto dal MEC platform manager e dal virtualization infrastructure manager.

Il primo, `e responsabile delle seguenti funzionalit`a:

• gestire il ciclo di vita delle applicazioni e informare il multi-access edge orchestrator in merito agli eventi applicativi rilevanti;

• fornire funzionalit`a di gestione alla MEC platform

• gestire le regole e i requisiti delle applicazioni comprese le autorizzazioni del servizio, le regole del traffico, la configurazione DNS e la risoluzione dei conflitti;

• ricevere dal virtualization infrastructure manager i report dei gua- sti delle risorse virtualizzate e della misurazione performance e conser- varli per elaborazioni successive.

Il secondo, `e responsabile di:

• allocare, gestire e rilasciare le risorse virtuali della virtualized infra- structure;

• preparare la virtualized infrastructure a eseguire un’immagine soft- ware

• collezionare le informazioni in merito alle performance e agli errori delle risorse virtualizzate

• quando supportato, effettuare il riposizionamento delle applicazioni. Le device applications sono applicazioni che girano su un device uten- te e hanno la capacit`a di interagire con il sistema MEC tramite un user application lifecycle management proxy.

Il customer facing service portal permette ai clienti dell’operatore di selezionare e ordinare un insieme di applicazioni MEC che soddisfano le loro esigenze e ottenere informazioni in merito al livello di servizio fornito da queste.

MEC e NFV sono concetti complementari: l’architettura MEC `e stata progettata in modo da consentire diverse modalit`a di esecuzione e distribu- zione di un sistema MEC. Un gruppo dedicato, ETSI GR MEC 017, fornisce

un’analisi dettagliata sulla messa in esecuzione di un sistema MEC in un am- biente NFV. In [2.26] `e mostrata l’architettura di un sistema MEC eseguito in ambiente NFV. Le differenze dall’architettura discussa precedentemente sono:

• la MEC platform e le MEC applications sono eseguite come VNF • la virtualization infrastructure `e eseguita come una NFVI e gestita

da un VIM

• il MEC platform manager, MEPM `e sostituito dal MEC plat- form manager - NFV, MEPM-V e delega la gestione del ciclo di vita delle VNF a uno o pi`u VNFM.

• Il MEC orchestrator, MEO `e sostituito dal MEC application orchestrator, MEAO che si affida al NFVO per l’orchestrazione delle risorse e degli insiemi di applicazioni MEC, implementate come VNF, che assieme formano un servizio di rete NFV.

Figura 2.26: Architettura sistema Multi-access Edge Computing eseguito in ambiente NFV