Nell'articolo «», parlando dell'architettura del kernel a pacchetti della rete NB-IoT, abbiamo accennato alla nascita di un nuovo nodo SCEF. Spieghiamo nella terza parte di cosa si tratta e a cosa serve.
Nella creazione di un servizio M2M, gli sviluppatori di applicazioni si trovano ad affrontare le seguenti domande:
- come identificare i dispositivi;
- quale algoritmo utilizzare per la verifica e conferma dell'autenticità;
- quale protocollo di trasporto scegliere per interagire con i dispositivi;
- come garantire la consegna dei dati ai dispositivi;
- come organizzare e stabilire le regole per lo scambio di dati con loro;
- come controllare e ricevere in tempo reale informazioni sul loro stato;
- come inviare dati simultaneamente a un gruppo di propri dispositivi;
- come inviare simultaneamente dati da un dispositivo a più client;
- come ottenere un accesso unificato ai servizi aggiuntivi dell'operatore per la gestione del proprio dispositivo.
Per risolverli, è necessario creare soluzioni tecniche proprietarie e "pesanti", il che porta a un aumento del lavoro e del tempo di immissione sul mercato dei servizi. Qui entra in gioco il nuovo nodo SCEF.
Secondo la definizione 3GPP, SCEF (service capability exposure function) è un nuovo componente dell'architettura 3GPP, la cui funzione è quella di esporre in modo sicuro i servizi e le possibilità forniti dalle interfacce di rete 3GPP tramite API.
In parole semplici, SCEF è un intermediario tra la rete e il server delle applicazioni (application server - AS), fungendo da punto di accesso unico ai servizi dell'operatore per la gestione del proprio dispositivo M2M nella rete NB-IoT tramite un'interfaccia API standardizzata e intuitiva.
SCEF nasconde la complessità della rete dell'operatore, consentendo agli sviluppatori di applicazioni di astrarsi da meccanismi di interazione complessi e specifici con i dispositivi.
Attraverso la conversione dei protocolli di rete in un'interfaccia API familiare agli sviluppatori, SCEF facilita la creazione di nuovi servizi e riduce il time-to-market. Inoltre, il nuovo nodo include funzioni di identificazione/autenticazione dei dispositivi mobili e di definizione delle regole per lo scambio di dati tra il dispositivo e l'AS, sollevando gli sviluppatori dall'onere di implementare queste funzionalità, delegando tali compiti all'operatore.
SCEF gestisce le interfacce necessarie per l'autenticazione e l'autorizzazione dei server delle applicazioni, il mantenimento della mobilità dell'UE, la trasmissione dei dati e il triggering dei dispositivi, l'accesso a servizi e funzionalità aggiuntive della rete dell'operatore.
Verso AS esiste un'unica interfaccia T8, interfaccia API (HTTP/JSON), standardizzata da 3GPP. Tutte le interfacce, ad eccezione di T8, funzionano sulla base del protocollo DIAMETER (fig. 1).
T6a è l'interfaccia tra SCEF e MME. Viene utilizzata per procedure di gestione della mobilità/sessione, trasmissione di dati non-IP, provisioning di eventi di monitoraggio e ricezione di report su di essi.
S6t è l'interfaccia tra SCEF e HSS. Necessaria per l'autenticazione dell'utente, l'autorizzazione dei server delle applicazioni, l'ottenimento del collegamento tra ID esterno e IMSI/MSISDN, provisioning di eventi di monitoraggio e ricezione di report su di essi.
S6m/T4 – interfacce da SCEF a HSS e SMS-C (nel 3GPP è definito il nodo MTC-IWF, utilizzato per il triggering dei dispositivi e la trasmissione di SMS nelle reti NB-IoT. Tuttavia, in tutte le implementazioni, le funzionalità di questo nodo sono integrate in SCEF, quindi, per semplificare lo schema, non lo analizzeremo separatamente). Utilizzate per ottenere informazioni di routing per la spedizione di SMS e per l'interazione con il centro SMS.
T8 – interfaccia API per l'interazione tra SCEF e i server delle applicazioni. Tramite questa interfaccia vengono trasmessi sia comandi di controllo che traffico.
*in realtà ci sono più interfacce, qui sono elencate solo le più fondamentali. L'elenco completo è riportato nel 3GPP 23.682 (4.3.2 Elenco dei Punti di Riferimento).
Di seguito sono riportate le funzioni chiave e i servizi di SCEF:
- associazione dell'identificativo della SIM (IMSI) a un ID esterno;
- trasmissione di traffico non IP (Non-IP Data Delivery, NIDD);
- operazioni di gruppo utilizzando un ID gruppo esterno;
- supporto per la modalità di trasmissione dei dati con conferma;
- bufferizzazione dei dati MO (Mobile Originated) e MT (Mobile Terminated);
- autenticazione e autorizzazione dei dispositivi e dei server delle applicazioni;
- uso simultaneo dei dati di un singolo UE da parte di più AS;
- supporto delle funzionalità speciali di monitoraggio dello stato UE (MONTE – Monitoring Events);
- triggering dei dispositivi;
- garantire il roaming dei dati non IP.
Il principio fondamentale di interazione tra AS e SCEF si basa sul modello delle cosiddette sottoscrizioni. Quando è necessario accedere a un servizio specifico, SCEF richiede che il server applicativo crei una sottoscrizione inviando un comando a un API del servizio richiesto e ricevendo in risposta un identificatore unico. Da quel momento, tutte le azioni e le comunicazioni con l'UE nell'ambito di quel servizio avverranno utilizzando tale identificatore.
External ID: identificatore universale del dispositivo
Una delle modifiche più significative nel modello di interazione tra AS e dispositivi attraverso SCEF è l'introduzione dell'identificatore universale. Ora, invece del numero di telefono (MSISDN) o dell'indirizzo IP, come avveniva nelle reti classiche 2G/3G/LTE, l'identificatore del dispositivo per il server applicativo diventa "external ID". Questo è definito dallo standard in un formato familiare per gli sviluppatori di applicazioni "@".
Non è più necessario per gli sviluppatori implementare algoritmi di autenticazione dei dispositivi; la rete si occupa interamente di questa funzione. L'External ID è legato all'IMSI e lo sviluppatore può essere certo che, accedendo a un specifico external ID, sta interagendo con una specifica SIM card. Utilizzando un chip SIM, si crea una situazione realmente unica, in cui l'external ID identifica inequivocabilmente un dispositivo specifico!
Inoltre, a un IMSI possono essere associati diversi external ID, creando una situazione ancora più interessante, in cui l'external ID identifica in modo chiaro un'applicazione specifica responsabile di un determinato servizio su un dispositivo specifico.
Appare anche un identificatore di gruppo — external group ID, che include un insieme di singoli external ID. Ora, con una sola richiesta al SCEF AS, è possibile avviare operazioni di gruppo — inviare dati o comandi di controllo a molti dispositivi riuniti in un'unica logica gruppo.
Poiché per gli sviluppatori AS il passaggio a un nuovo identificatore di dispositivo non può essere immediato, il SCEF ha mantenuto la possibilità di comunicazione dell'AS con l'UE attraverso un numero standard – MSISDN.
Consegna di dati non IP (Non-IP Data Delivery, NIDD)
Nel NB-IoT, nell'ambito dell'ottimizzazione dei meccanismi di trasmissione di piccoli volumi di dati, oltre ai già esistenti tipi di PDN come IPv4, IPv6 e IPv4v6, è stato introdotto un ulteriore tipo: non IP. In questo caso, al dispositivo (UE) non viene assegnato un indirizzo IP e i dati vengono trasmessi senza l'uso del protocollo IP. Il traffico per tali connessioni può essere instradato in due modi: in modo classico — MME -> SGW -> PGW e poi attraverso un tunnel PtP fino ad AS (fig. 2) oppure utilizzando SCEF (fig. 3).
Il modo classico non offre particolari vantaggi rispetto al traffico IP, ad eccezione della riduzione delle dimensioni dei pacchetti trasmessi grazie all'assenza delle intestazioni IP. Tuttavia, l'uso di SCEF apre una serie di nuove possibilità e semplifica notevolmente le procedure di interazione con i dispositivi.
Nella trasmissione dei dati tramite SCEF emergono due vantaggi molto importanti rispetto al traffico IP classico:
Consegna del traffico MT al dispositivo tramite ID esterno
Per inviare un messaggio a un dispositivo IP classico, l'AS deve conoscere il suo indirizzo IP. Qui sorge un problema: poiché il dispositivo di solito riceve un indirizzo IP 'grigio' durante la registrazione, comunica con il server delle applicazioni, che si trova su Internet, attraverso un nodo NAT, dove l'indirizzo grigio viene tradotto in un indirizzo pubblico. Il legame tra indirizzi IP grigi e pubblici dura un tempo limitato, a seconda delle impostazioni del NAT. In media, per TCP o UDP, non supera i cinque minuti. Quindi, se non ci sono stati scambi di dati con questo dispositivo per cinque minuti, il legame si interromperà e il dispositivo non sarà più accessibile tramite l'indirizzo pubblico con cui è stata avviata la sessione con l'AS. Ci sono diverse soluzioni:
1. Utilizzare heartbeat. Stabilendo una connessione, il dispositivo deve scambiare pacchetti con l'AS ogni pochi minuti, evitando così che la traduzione su NAT venga chiusa. Ma non si può parlare di alcuna efficienza energetica in questo caso.
2. Ogni volta che è necessario, controllare la presenza di pacchetti per il dispositivo sull'AS: inviare un messaggio nell'uplink.
3. Creare un APN privato (VRF), dove il server delle applicazioni e i dispositivi si trovano nella stessa subnet, e assegnare agli apparecchi indirizzi IP statici. Funzionerà, ma è quasi irrealizzabile quando si tratta di un parco di migliaia o decine di migliaia di dispositivi.
4. Infine, la soluzione più adatta: utilizzare IPv6, che non richiede NAT, poiché gli indirizzi IPv6 sono accessibili direttamente da Internet. Tuttavia, anche in questo caso, quando un dispositivo viene registrato nuovamente, riceverà un nuovo indirizzo IPv6 e non sarà più accessibile tramite il precedente.
È quindi necessario inviare un pacchetto di inizializzazione contenente l'identificativo del dispositivo al server, per comunicare il nuovo indirizzo IP del dispositivo. Poi si attende un pacchetto di conferma da parte dell'AS, il che influisce anche sull'efficienza energetica.
Questi metodi funzionano bene per dispositivi 2G/3G/LTE, dove non ci sono requisiti severi per l'autonomia e, di conseguenza, non ci sono limitazioni per il tempo di attesa e il traffico. Per NB-IoT, questi metodi non sono adatti a causa del loro elevato consumo energetico.
SCEF risolve questo problema: poiché l'unico identificatore del dispositivo per l'AS è l'external ID, è sufficiente che l'AS invii un pacchetto di dati a SCEF per un determinato external ID, mentre SCEF si occupa del resto. Nel caso in cui il dispositivo sia in modalità risparmio energetico PSM o eDRX, i dati verranno memorizzati in buffer e consegnati quando il dispositivo sarà disponibile. Se invece il dispositivo è disponibile per il traffico, i dati verranno consegnati immediatamente. Questo vale anche per i comandi di gestione.
In qualsiasi momento, l'AS può ritirare il messaggio memorizzato in buffer verso l'UE o sostituirlo con uno nuovo.
Il meccanismo di buffering può essere applicato anche durante la trasmissione di dati MO dall'UE verso l'AS. Se SCEF non riesce a consegnare i dati all'AS immediatamente, ad esempio se sono in corso lavori di manutenzione sui server dell'AS, questi pacchetti verranno memorizzati in buffer e garantiti per la consegna, non appena l'AS sarà disponibile.
Come accennato sopra, l'accesso a un determinato servizio e UE per AS (e NIDD è un servizio) è regolato da regole e politiche lato SCEF, consentendo un'opportunità unica di utilizzare simultaneamente i dati di un singolo UE da più AS. Cioè, se più AS si abbonano a un UE, dopo aver ricevuto i dati dall'UE, SCEF li distribuirà a tutti gli AS iscritti. Questo è particolarmente utile nei casi in cui il creatore di un parco di dispositivi specializzati condivide i dati tra più clienti. Ad esempio, creando una rete di stazioni meteorologiche basate su NB-IoT, è possibile vendere i dati provenienti da esse a molti servizi contemporaneamente.
Meccanismo di consegna garantita dei messaggi
Reliable Data Service — meccanismo di consegna garantita dei messaggi MO e MT senza l'uso di algoritmi specializzati a livello di protocollo, come il handshake in TCP, ad esempio. Funziona attivando un'apposita flag nella parte di controllo del messaggio durante lo scambio tra UE e SCEF. È AS a decidere se attivare o meno questo meccanismo durante la trasmissione del traffico.
Se il meccanismo è attivato, l'UE prevede la consegna garantita del traffico MO includendo un flag speciale nella parte di intestazione del pacchetto. Al ricevimento di tale pacchetto, SCEF risponde all'UE con una conferma. Se l'UE non riceve il pacchetto di conferma, il pacchetto verso SCEF verrà ritrasmesso. Lo stesso vale anche per il traffico MT.
Monitoraggio dei dispositivi (monitoring events- MONTE)
Come accennato in precedenza, la funzionalità di SCEF include, tra l'altro, funzioni di controllo dello stato dell'UE, noto come monitoraggio dei dispositivi. Se i nuovi identificatori e meccanismi di trasmissione dei dati rappresentano ottimizzazioni (anche se molto significative) delle procedure esistenti, MONTE è una funzionalità completamente nuova, non disponibile nelle reti 2G/3G/LTE. MONTE consente all'AS di monitorare parametri del dispositivo come lo stato della connessione, la disponibilità per le comunicazioni, la posizione, lo stato del roaming, ecc. Approfondiremo ciascuno di questi aspetti tra poco.
Se necessario, per attivare un evento di monitoraggio per un dispositivo o un gruppo di dispositivi, l'AS si iscrive al servizio corrispondente inviando al SCEF un comando dell'API MONTE, che include parametri come l'ID esterno o l'ID del gruppo esterno, l'ID dell'AS, il tipo di monitoraggio e il numero di report che l'AS desidera ricevere. Se l'AS è autorizzato a effettuare la richiesta, il SCEF, a seconda del tipo, provvede all'evento su HSS o MME (fig. 4). Quando si verifica l'evento, MME o HSS generano un report verso il SCEF, che lo invia all'AS.
Il provisioning di tutti gli eventi, tranne "Number of UEs present in a geographic area", avviene tramite HSS. Due eventi, "Change of IMSI-IMEI Association" e "Roaming Status", vengono monitorati direttamente sull'HSS, mentre gli altri vengono provisionati dall'HSS su MME.
Gli eventi possono essere sia occasionali che periodici, a seconda del loro tipo.
L'invio del report dell'evento (reporting) avviene da parte del nodo che monitora l'evento, direttamente verso il SCEF (fig. 5).
Un aspetto importante: Gli eventi di monitoraggio possono essere applicati sia ai dispositivi non IP connessi tramite SCEF, sia ai dispositivi IP che trasmettono dati in modo tradizionale attraverso MME-SGW-PGW.
Esaminiamo più in dettaglio ciascuno degli eventi di monitoraggio:
Perdita di connettività — informa l'AS che l'UE non è più disponibile né per il traffico dati né per lo scambio di segnali. Questo evento si verifica quando il "mobile reachability timer" dell'UE scade sul MME. Nella richiesta di questo tipo di monitoraggio, l'AS può specificare il proprio valore di "Maximum Detection Time" — se entro questo tempo l'UE non mostra alcuna attività, l'AS verrà informato che l'UE non è disponibile, con l'indicazione del motivo. L'evento si verifica anche se l'UE è stata rimossa forzatamente dalla rete per qualche motivo.
* Per far sapere alla rete che il dispositivo è ancora accessibile, esso avvia periodicamente la procedura di aggiornamento — Tracking Area Update (TAU). La frequenza di questa procedura è stabilita dalla rete tramite il timer T3412 o (T3412_extended nel caso del PSM), il cui valore viene trasmesso al dispositivo durante la procedura di Attach o durante un TAU successivo. Il timer di accessibilità mobile è solitamente di alcuni minuti più lungo rispetto a T3412. Se l'UE non esegue un TAU prima della scadenza del “Mobile reachability timer”, la rete lo considera meno accessibile.
Accessibilità UE – Indica quando l'UE diventa disponibile per il traffico DL o SMS. Questo avviene quando l'UE diventa accessibile per il paging (per l'UE in modalità eDRX) o quando l'UE passa alla modalità ECM-CONNECTED (per l'UE in modalità PSM o eDRX), cioè esegue un TAU o invia un pacchetto uplink.
Reporting della posizione – Questo tipo di monitoraggio degli eventi consente all'AS di richiedere dati sulla posizione dell'UE. Può essere richiesta sia la posizione attuale (Current Location) sia l'ultima conosciuta (Last Known Location, determinata dal cell ID dall quale il dispositivo ha eseguito l'ultima TAU o trasmesso traffico), il che è rilevante per i dispositivi in modalità di risparmio energetico PSM o eDRX. Per la “Current Location” l'AS può richiedere report ripetuti, con l'MME che informerà l'AS ogni volta che cambia la posizione del dispositivo.
Cambiamento dell'associazione IMSI-IMEI – Quando questo evento viene attivato, l'SCEF inizia a monitorare il cambiamento dell'associazione IMSI (identificatore della SIM) e IMEI (identificatore del dispositivo). Quando si verifica l'evento, informa l'AS. Può essere utilizzato per il riassociamento automatico dell'ID esterno al dispositivo durante operazioni pianificate di sostituzione o per fungere da identificatore del furto del dispositivo.
Stato di Roaming – Questo tipo di monitoraggio è utilizzato dall'AS per determinare se l'UE è nella rete domestica o in quella di un partner di roaming. Facoltativamente, può essere fornito il PLMN (Public Land Mobile Network) dell'operatore a cui il dispositivo è registrato.
Fallimento di comunicazione — Questo tipo di monitoraggio informa l'AS sui guasti nella comunicazione con il dispositivo, basandosi sulle cause di interruzione della connessione (release cause code) ricevute dalla rete di accesso radio (protocollo S1-AP). Questo evento può aiutare a determinare il motivo per cui si è verificato il guasto nella comunicazione, ad esempio, a causa di problemi di rete, come il sovraccarico dell'eNodeB (Radio resources not available), o a causa di un guasto del dispositivo stesso (Radio Connection With UE Lost).
Disponibilità dopo il guasto DDN – Questo evento informa l'AS che il dispositivo è diventato disponibile dopo un guasto nella comunicazione. Può essere utilizzato quando è necessario inviare dati al dispositivo, ma il tentativo precedente non è andato a buon fine, poiché l'UE non ha risposto alla notifica della rete (paging) e i dati non sono stati consegnati. Se questo tipo di monitoraggio è stato richiesto per l'UE, non appena il dispositivo stabilisce una comunicazione in entrata, esegue una TAU o invia dati in uplink, l'AS sarà informato che il dispositivo è diventato disponibile. Poiché la procedura DDN (downlink data notification) funziona tra MME e S/P-GW, questo tipo di monitoraggio è disponibile solo per dispositivi IP.
Stato di connettività PDN – informa l'AS quando cambia lo stato del dispositivo (stato di connettività PDN) – connessione (attivazione del PDN) o disconnessione (rimozione del PDN). Questo può essere utilizzato dall'AS per avviare la comunicazione con l'UE, o viceversa, per comprendere che la comunicazione non è più possibile. Questo tipo di monitoraggio è disponibile per dispositivi IP e non IP.
Numero di UE presenti in un'area geografica – questo tipo di monitoraggio viene utilizzato dall'AS per determinare il numero di UE in una determinata zona geografica.
Attivazione dei dispositivi (Device triggering)
Nelle reti 2G/3G, la procedura di registrazione alla rete era in due fasi: prima il dispositivo si registrava nel SGSN (procedura di attacco), poi, se necessario trasmettere dati, attivava il contesto PDP – connessione con il gateway packet (GGSN). Nelle reti 3G, queste due procedure si svolgevano in sequenza, cioè il dispositivo non aspettava il momento in cui doveva trasmettere dati, ma attivava il PDP immediatamente dopo aver completato la procedura di attacco. Nel LTE, queste due procedure sono state unite in una sola, cioè al momento dell'attacco il dispositivo richiedeva immediatamente l'attivazione della connessione PDN (analogo del PDP in 2G/3G) attraverso eNodeB a MME-SGW-PGW.
In NB-IoT, a connection method called “attach without PDN” is defined, meaning the UE attaches without establishing a PDN connection. In this case, it is unavailable for traffic transmission and can only send or receive SMS. To send a command for activating PDN and connecting to AS to such a device, the “Device triggering” functionality was developed.
Upon receiving a connection command for such a UE from AS, SCEF initiates the sending of a control SMS to the device via the SMS center. Upon receiving the SMS, the device activates the PDN and connects to AS for further instructions or data transmission.
There may be cases where the subscription for the device on SCEF expires. Yes, the subscription has a lifespan set by the operator or agreed upon with AS. Upon expiration, the PDN will be deactivated on MME, and the device will become unavailable for AS. In this case, the “Device triggering” functionality will also assist. Upon receiving new data from AS, SCEF will determine the connection status of the device and deliver the data via the SMS channel.
Conclusione
Le funzionalità di SCEF non si limitano certo ai servizi sopra descritti, ma sono in continua evoluzione e ampliamento. Attualmente, per SCEF sono già standardizzati più di una dozzina di servizi. Qui abbiamo trattato solo le funzioni principali e più richieste dagli sviluppatori; parleremo del resto in articoli futuri.
Sorge subito la domanda su come ottenere l'accesso di prova a questo "meraviglioso" nodo per test preliminari e debug di possibili casi d'uso? È molto semplice. Qualsiasi sviluppatore può inviare una richiesta a iot.info@mts.ru, specificando solo l'obiettivo della connessione, una descrizione del possibile caso d'uso e le informazioni di contatto per essere richiamato.
A presto!
Autori:
- senior expert in soluzioni convergenti e servizi multimediali Sergey Novikov ,
- expert in soluzioni convergenti e servizi multimediali Alexey Lapshin
Fonte: habr.com
