Nell'articolo "», parlando dell'architettura del nucleo di rete NB-IoT, abbiamo accennato all'emergere di un nuovo nodo SCEF. Spieghiamo nella terza parte che cos'è 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 il controllo e la verifica dell'autenticità;
- quale protocollo di trasporto scegliere per l'interazione con i dispositivi;
- come garantire la consegna dei dati ai dispositivi;
- come organizzare e stabilire le regole per lo scambio di dati con essi;
- come monitorare e ottenere in tempo reale informazioni sul loro stato;
- come inviare contemporaneamente dati a un gruppo dei propri dispositivi;
- come inviare dati da un dispositivo a più clienti contemporaneamente;
- come ottenere un accesso unificato ai servizi aggiuntivi dell'operatore per gestire il proprio dispositivo.
Per risolvere queste questioni, è necessario creare soluzioni proprietarie tecnicamente "pesanti", il che porta a un aumento del tempo e dei costi di sviluppo dei servizi. È qui che entra in gioco il nuovo nodo SCEF.
Secondo la definizione 3GPP, SCEF (service capability exposure function) è un componente completamente nuovo dell'architettura 3GPP, la cui funzione è quella di esporsi in modo sicuro ai servizi e alle funzionalità 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), una finestra unica per accedere ai servizi dell'operatore per gestire il 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 dalle meccaniche di interazione con i dispositivi, complesse e specifiche.
Grazie alla trasformazione dei protocolli di rete in un'interfaccia API SCEF familiare per gli sviluppatori di applicazioni, viene facilitata la creazione di nuovi servizi e ridotto il time-to-market. Inoltre, il nuovo nodo include funzioni di identificazione/autenticazione dei dispositivi mobili e definizione delle regole di scambio dati tra il dispositivo e l'AS, sollevando gli sviluppatori di applicazioni dalla necessità di implementare queste funzioni sul proprio lato, trasferendo queste funzioni nelle mani dell'operatore.
SCEF centralizza le interfacce necessarie per l'autenticazione e l'autorizzazione dei server di applicazioni, mantenendo la mobilità degli UE, la trasmissione di dati e il triggering dei dispositivi, nonché l'accesso a servizi e funzionalità aggiuntive della rete dell'operatore.
Verso l'AS c'è un'unica interfaccia T8, un'interfaccia API (HTTP/JSON) standardizzata da 3GPP. Tutte le interfacce, ad eccezione di T8, operano su base del protocollo DIAMETER (fig. 1).
T6a è l'interfaccia tra SCEF e MME. Viene utilizzata per le procedure di gestione della mobilità/sessione, la trasmissione di dati non IP, il provisioning degli eventi di monitoraggio e la ricezione di report su di essi.
S6t è l'interfaccia tra SCEF e HSS. Necessaria per l'autenticazione del sottoscrittore, l'autorizzazione dei server di applicazioni, la ricezione del legame tra ID esterno e IMSI/MSISDN, il provisioning degli eventi di monitoraggio e la ricezione di report su di essi.
S6m/T4 sono le interfacce da SCEF a HSS e SMS-C (in 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 la funzionalità di questo nodo è integrata in SCEF, quindi per semplificare lo schema non la tratteremo separatamente). Vengono utilizzate per ottenere informazioni di routing per l'invio di SMS e interagire con il centro SMS.
T8 è l'interfaccia API per l'interazione di SCEF con i server di applicazioni. Attraverso 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 è fornito in 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'ID della scheda SIM (IMSI) a un ID esterno;
- trasmissione di traffico non IP (Non-IP Data Delivery, NIDD);
- operazioni di gruppo, utilizzando l'ID di 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 di applicazioni;
- utilizzo simultaneo dei dati di un UE da parte di più AS;
- supporto per funzioni speciali di monitoraggio dello stato dell'UE (MONTE – Monitoring Events);
- attivazione dei dispositivi;
- garanzia di roaming per dati non-IP.
Il principio fondamentale di interazione tra AS e SCEF è basato sul cosiddetto schema delle iscrizioni. Quando è necessario accedere a un certo servizio, il SCEF deve creare un'iscrizione, inviando un comando a un api specifico del servizio richiesto e ricevendo in risposta un identificatore unico. Da quel momento in poi, tutte le ulteriori azioni e comunicazioni con l'UE nel contesto di quel servizio avverranno utilizzando tale identificatore.
ID esterno: identificatore universale del dispositivo
Una delle modifiche più importanti nello schema di interazione tra AS e dispositivi quando si lavora tramite SCEF è l'introduzione di un identificatore universale. Ora, invece del numero di telefono (MSISDN) o dell'indirizzo IP, come avveniva nella rete classica 2G/3G/LTE, l'identificatore del dispositivo per il server delle applicazioni diventa "ID esterno". È definito dallo standard nel formato "@" familiare agli sviluppatori di applicazioni.
Gli sviluppatori non devono più implementare algoritmi di autenticazione dei dispositivi; la rete si occupa completamente di questa funzione. L'ID esterno è associato all'IMSI, e lo sviluppatore può essere certo che, accedendo a un ID esterno specifico, sta interagendo con una specifica SIM card. Quando si utilizza un chip SIM, si crea una situazione davvero unica, in cui l'ID esterno identifica in modo univoco un dispositivo specifico!
Inoltre, un singolo IMSI può essere associato a più ID esterni — si crea così una situazione ancora più interessante, in cui l'ID esterno identifica in modo univoco una specifica applicazione responsabile di un determinato servizio su un dispositivo specifico.
Appare anche un identificatore di gruppo — ID di gruppo esterno, che include un insieme di singoli ID esterni. Ora, con una sola richiesta a SCEF, l'AS può avviare operazioni di gruppo — invio di dati o comandi di gestione a più dispositivi, uniti in un'unica LOGICA gruppo.
Poiché per gli sviluppatori il passaggio al nuovo identificatore del dispositivo non può avvenire istantaneamente, il SCEF ha lasciato la possibilità di comunicazione tra AS e UE tramite il numero standard - MSISDN.
Trasferimento di traffico non IP (Non-IP Data Delivery, NIDD)
In NB-IoT, nell'ambito dell'ottimizzazione dei meccanismi di trasmissione di piccoli volumi di dati, è stato introdotto un ulteriore tipo – non-IP, oltre ai già esistenti tipi di PDN, come IPv4, IPv6 e IPv4v6. 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: quello classico – MME -> SGW -> PGW e successivamente attraverso un tunnel PtP fino ad AS (fig. 2) oppure utilizzando SCEF (fig. 3).
Il metodo classico non presenta particolari vantaggi rispetto al traffico IP, ad eccezione della riduzione delle dimensioni dei pacchetti trasmessi grazie all'assenza delle intestazioni IP. L'uso di SCEF, invece, apre una serie di nuove opportunità e semplifica notevolmente le procedure di interazione con i dispositivi.
Durante la trasmissione dei dati tramite SCEF emergono due vantaggi molto importanti rispetto al traffico IP classico:
La consegna del traffico MT al dispositivo tramite ID esterno
Per inviare un messaggio a un dispositivo IP classico, AS deve conoscerne l'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 si effettua la traduzione dall'indirizzo grigio a quello pubblico. La connessione tra indirizzi IP grigi e pubblici ha una durata limitata, a seconda delle impostazioni del NAT. In media, per TCP o UDP, non supera i cinque minuti. Quindi, se non c'è stato uno scambio di dati con questo dispositivo per cinque minuti, la connessione si interromperà e il dispositivo non sarà più accessibile all'indirizzo pubblico con cui è stata avviata la sessione con AS. Esistono diverse soluzioni:
1. Utilizzare heartbeat. Una volta stabilita la connessione, il dispositivo deve scambiare pacchetti con AS ogni pochi minuti, in modo da non consentire la chiusura della traduzione sul NAT. Tuttavia, non può esserci alcuna considerazione di efficienza energetica.
2. Ogni volta che è necessario, controllare la presenza di pacchetti per il dispositivo su AS - inviare un messaggio in uplink.
3. Creare un APN privato (VRF), dove il server delle applicazioni e i dispositivi si trovano nella stessa sottorete, e assegnare indirizzi IP statici ai dispositivi. Funzionerà, ma è praticamente irrealizzabile quando si tratta di un parco di migliaia, decine di migliaia di dispositivi.
4. Infine, la soluzione più adeguata: utilizzare IPv6, poiché non richiede NAT, dato che gli indirizzi IPv6 sono accessibili direttamente da Internet. Tuttavia, anche in questo caso, al momento della ri-registrazione del dispositivo, esso riceverà un nuovo indirizzo IPv6 e non sarà più accessibile tramite il precedente.
Pertanto, è necessario inviare un pacchetto di inizializzazione con l'identificatore del dispositivo al server, per comunicare il nuovo indirizzo IP del dispositivo. Successivamente, si dovrà attendere un pacchetto di conferma dall'AS, che influisce anche sull'efficienza energetica.
Questi metodi funzionano bene per dispositivi 2G/3G/LTE, dove non ci sono rigorose esigenze in termini di autonomia e, di conseguenza, non ci sono limitazioni sul tempo in onda o sul 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 AS è l'external ID, AS deve semplicemente inviare un pacchetto dati a SCEF per un determinato external ID, mentre SCEF si preoccupa di tutto il resto. In caso di risparmio energetico PSM o eDRX, i dati verranno memorizzati nella cache e consegnati quando il dispositivo sarà disponibile. Se il dispositivo è disponibile per il traffico, i dati verranno consegnati immediatamente. Questo vale anche per i comandi di gestione.
In qualsiasi momento, AS può revocare il messaggio memorizzato nella cache verso UE o sostituirlo con uno nuovo.
Il meccanismo di memorizzazione nella cache può essere applicato anche per la trasmissione di dati MO da UE a AS. Se SCEF non riesce a consegnare i dati ad AS immediatamente, ad esempio, se sono in corso lavori di manutenzione sui server AS, questi pacchetti saranno memorizzati nella cache e consegnati garantiti, non appena AS sarà disponibile.
Come accennato in precedenza, l'accesso a un determinato servizio e UE per AS (e NIDD è un servizio) è regolato da norme e politiche sul lato SCEF, il che consente di realizzare l'unica possibilità di utilizzo simultaneo dei dati di un UE da parte di più AS. Cioè, se più AS si sono iscritti a un UE, dopo aver ricevuto i dati da UE, SCEF li inoltrerà a tutti gli AS iscritti. Questo è particolarmente utile per i 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 che funzionano su NB-IoT, è possibile vendere i dati 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 ad esempio il handshake in TCP. Funziona includendo un flag speciale nella parte di intestazione del messaggio durante lo scambio tra UE e SCEF. Attivare o meno questo meccanismo durante la trasmissione del traffico è una decisione dell'AS.
Se il meccanismo è attivato, l'UE include un flag speciale nella parte di intestazione del pacchetto per la consegna garantita del traffico MO. Al ricevimento di tale pacchetto, il SCEF risponde all'UE con una conferma. Se l'UE non riceve un pacchetto di conferma, il pacchetto verso il SCEF verrà reinviato. Lo stesso avviene per il traffico MT.
Monitoraggio dei dispositivi (monitoring events- MONTE)
Come detto in precedenza, la funzionalità del SCEF include, tra le altre cose, funzioni di monitoraggio dello stato dell'UE, ovvero il monitoraggio dei dispositivi. Se i nuovi identificatori e meccanismi di trasmissione dei dati sono ottimizzazioni (anche se molto importanti) di procedimenti già esistenti, MONTE rappresenta una funzionalità completamente nuova, non disponibile nelle reti 2G/3G/LTE. MONTE consente all'AS di monitorare parametri come stato di connessione, disponibilità per comunicazioni, posizione, stato di roaming, ecc. Forniremo maggiori dettagli su ciascuno di essi più avanti.
Se necessario attivare un evento di monitoraggio per un dispositivo o un gruppo di dispositivi, l'AS si iscrive al servizio corrispondente inviando al SCEF il comando dell'API MONTE, che include parametri come l'ID esterno o il gruppo ID esterno, l'identificativo dell'AS, il tipo di monitoraggio, e il numero di report che l'AS desidera ricevere. Se l'AS è autorizzato a eseguire la richiesta, il SCEF provvede a fornire l'evento sull'HSS o sull'MME a seconda del tipo (vedi fig. 4). Al verificarsi dell'evento, MME o HSS generano un report verso il SCEF, che lo invia all'AS.
La provisioning di tutti gli eventi, ad eccezione di "Number of UEs present in a geographic area", avviene tramite HSS. I due eventi "Change of IMSI-IMEI Association" e "Roaming Status" vengono monitorati direttamente sull'HSS, mentre gli altri eventi vengono provisionati dall'HSS sull'MME.
Gli eventi possono essere sia singoli che periodici, a seconda del loro tipo.
L'invio del rapporto sull'evento (reporting) viene effettuato dal nodo che monitora l'evento direttamente su SCEF (fig. 5).
Un punto importante: gli eventi di monitoraggio possono essere applicati sia ai dispositivi non IP collegati tramite SCEF, sia ai dispositivi IP che trasmettono dati nel modo tradizionale tramite MME-SGW-PGW.
Esaminiamo più nel 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 segnali. Questo evento si verifica quando il "mobile reachability timer" per l'UE scade su MME. Nella richiesta per questo tipo di monitoraggio, l'AS può specificare il proprio valore di "Tempo Massimo di Rilevamento" — se durante questo periodo l'UE non mostra alcuna attività, l'AS verrà informato che l'UE è non disponibile, con l'indicazione della causa. Si verifica anche un evento quando l'UE è stata rimossa forzatamente dalla rete per qualunque motivo.
* Affinché la rete sappia che il dispositivo è ancora disponibile, esso inizia periodicamente la procedura di aggiornamento — Tracking Area Update (TAU). La frequenza di questa procedura è impostata dalla rete tramite il timer T3412 o (T3412_extended in caso di PSM), il cui valore viene trasmesso al dispositivo durante la procedura di Attach o la successiva TAU. Il mobile reachability timer è generalmente di qualche minuto superiore al T3412. Se l'UE non effettua un TAU prima della scadenza del "Mobile reachability timer", la rete considera che non sia più disponibile.
Raggiungibilità dell'UE – Mostra quando l'UE diventa disponibile per il traffico DL o SMS. Ciò avviene quando l'UE diventa disponibile 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è effettua un TAU o invia un pacchetto in uplink.
Reporting della posizione – Questo tipo di eventi di monitoraggio consente all'AS di richiedere dati sulla posizione dell'UE. Può essere richiesta sia la posizione corrente (Current Location) che l'ultima conosciuta (Last Known Location, determinata dal cell ID da cui il dispositivo ha effettuato l'ultima TAU o ha trasmesso traffico), che è rilevante per i dispositivi in modalità di risparmio energetico PSM o eDRX. Per la "Current Location" l'AS può richiedere rapporti ripetuti, con l'MME che informa l'AS ogni volta che cambia la posizione del dispositivo.
Cambiamento dell'associazione IMSI-IMEI – Attivando questo evento, SCEF inizia a monitorare le modifiche della coppia IMSI (identificatore della scheda SIM) e IMEI (identificatore del dispositivo). Quando si verifica l'evento, informa AS. Può essere utilizzato per il riaggancio automatico dell'ID esterno al dispositivo durante le attività programmate di sostituzione o per servire come identificatore di furto del dispositivo.
Stato di Roaming – Questo tipo di monitoraggio viene utilizzato da AS per determinare se l'UE si trova nella rete domestica o in quella di un partner di roaming. Facoltativamente, può essere trasmesso il PLMN (Public Land Mobile Network) dell'operatore in cui il dispositivo è registrato.
Errore di comunicazione – Questo tipo di monitoraggio informa 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 la causa del guasto nella comunicazione: a causa di problemi nella rete, ad esempio, durante un sovraccarico dell'eNodeb (Risorse radio non disponibili) o in seguito a un guasto del dispositivo stesso (Connessione radio persa con l'UE).
Disponibilità dopo il guasto DDN – Questo evento informa 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 effettuerà una comunicazione in ingresso, eseguirà un TAU o invierà dati in uplink, AS sarà informato che il dispositivo è diventato disponibile. Poiché la procedura DDN (notifica dei dati downlink) funziona tra MME e S/P-GW, questo tipo di monitoraggio è disponibile solo per dispositivi IP.
Stato di connettività PDN – Informa AS quando cambia lo stato del dispositivo (stato di connettività PDN) — connessione (attivazione PDN) o disconnessione (rimozione PDN). Questo può essere utilizzato da AS per avviare comunicazioni 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 è utilizzato da 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 nella rete era in due fasi: prima il dispositivo si registrava nel SGSN (procedura di attach), poi, se necessario per inviare dati, attivava il PDP context – la connessione con il gateway di pacchetto (GGSN). Nelle reti 3G, queste due procedure si svolgevano in modo sequenziale, cioè il dispositivo non attendeva il momento in cui doveva inviare dati, ma attivava subito il PDP al termine della procedura di attach. In LTE, queste due procedure sono state unite in una sola, cioè durante l'attach il dispositivo richiedeva subito l'attivazione della PDN connection (analogo al PDP in 2G/3G) attraverso l'eNodeB verso il MME-SGW-PGW.
Nel NB-IoT è definito un modo di connessione chiamato “attach without PDN”, cioè l'UE esegue l'attach senza stabilire una connessione PDN. In questo caso, non è disponibile per il trasferimento di traffico e può solo ricevere o inviare SMS. Per inviare a un tale dispositivo un comando per attivare la PDN e collegarsi all'AS, è stata sviluppata la funzionalità “Device triggering”.
Quando arriva il comando per connettere tale UE dall'AS, SCEF attraverso il centro SMS avvia l'invio di un SMS di controllo al dispositivo. Quando il dispositivo riceve l'SMS, attiva la PDN e si connette all'AS per ricevere ulteriori istruzioni o inviare dati.
Possono verificarsi casi in cui la sottoscrizione del dispositivo presso il SCEF scade. Sì, la sottoscrizione ha una sua durata, stabilita dall'operatore o concordata con l'AS. Alla sua scadenza, il PDN sarà disattivato sul MME, e il dispositivo diventerà non disponibile per l'AS. In questo caso, anche la funzionalità “Device triggering” sarà utile. Quando il SCEF riceve nuovi dati dall'AS, verificherà lo stato di connessione del dispositivo e consegnerà i dati tramite il canale SMS.
Conclusione
La funzionalità SCEF, naturalmente, non si limita ai servizi descritti sopra e continua a evolversi ed espandersi. Attualmente, per SCEF sono già standardizzati più di una dozzina di servizi. In questo momento abbiamo toccato solo le funzioni principali e più richieste da parte degli sviluppatori; di altre parleremo in articoli futuri.
Sorge subito la domanda su come ottenere l'accesso di test a questo "miracoloso" nodo per test preliminari e debug di casi possibili? È molto semplice. Qualsiasi sviluppatore può inviare una richiesta a iot.info@mts.ru, in cui è sufficiente indicare lo scopo della connessione, una descrizione del possibile caso e le informazioni di contatto per essere richiamato.
A presto!
Autori:
- esperto senior nel dipartimento di soluzioni convergenti e servizi multimediali Sergey Novikov ,
- esperto nel dipartimento di soluzioni convergenti e servizi multimediali Aleksej Lapšin
Fonte: habr.com
