Nell'articolo "", parlando dell'architettura del packet core della rete NB-IoT, abbiamo accennato alla comparsa di un nuovo nodo SCEF. Spieghiamo nella terza parte cos'è e perché serve?
Quando creano un servizio M2M, gli sviluppatori di applicazioni devono affrontare le seguenti domande:
- come identificare i dispositivi;
- quale algoritmo di verifica e autenticazione utilizzare;
- quale protocollo di trasporto scegliere per interagire con i dispositivi;
- come fornire in modo affidabile i dati ai dispositivi;
- come organizzare e stabilire regole per lo scambio di dati con loro;
- come monitorare e ottenere informazioni sulla propria condizione online;
- come fornire simultaneamente dati a un gruppo di dispositivi;
- come inviare contemporaneamente dati da un dispositivo a più client;
- come ottenere l'accesso unificato a servizi operatore aggiuntivi per la gestione del tuo dispositivo.
Per risolverli è necessario creare soluzioni proprietarie tecnicamente “pesanti”, che comportano un aumento del costo del lavoro e del time-to-market dei servizi. È qui che viene in soccorso il nuovo nodo SCEF.
Come definito dal 3GPP, SCEF (funzione di esposizione delle capacità del servizio) è un componente completamente nuovo dell'architettura 3GPP la cui funzione è quella di esporre in modo sicuro i servizi e le capacità forniti dalle interfacce di rete 3GPP tramite API.
In parole semplici, SCEF è un intermediario tra la rete e l'application server (AS), un'unica finestra di accesso ai servizi dell'operatore per gestire il proprio dispositivo M2M nella rete NB-IoT attraverso un'interfaccia API intuitiva e standardizzata.
SCEF nasconde la complessità della rete di un operatore, consentendo agli sviluppatori di applicazioni di astrarre meccanismi complessi e specifici dei dispositivi per interagire con i dispositivi.
Trasformando i protocolli di rete in un'API familiare per gli sviluppatori di applicazioni, l'API SCEF facilita la creazione di nuovi servizi e riduce il time-to-market. Il nuovo nodo include anche funzioni per l'identificazione/autenticazione dei dispositivi mobili, definendo le regole per lo scambio di dati tra il dispositivo e l'AS, eliminando la necessità per gli sviluppatori di applicazioni di implementare queste funzioni dalla loro parte, spostando queste funzioni sulle spalle dell'operatore.
SCEF copre le interfacce necessarie per l'autenticazione e l'autorizzazione dei server delle applicazioni, il mantenimento della mobilità dell'UE, il trasferimento dei dati e l'attivazione dei dispositivi, l'accesso a servizi aggiuntivi e le capacità della rete dell'operatore.
Verso l'AS esiste un'unica interfaccia T8, un'API (HTTP/JSON) standardizzata da 3GPP. Tutte le interfacce, ad eccezione di T8, funzionano in base al protocollo DIAMETER (Fig. 1).
T6a – interfaccia tra SCEF e MME. Utilizzato per procedure di gestione della mobilità/sessione, trasmissione di dati non IP, fornitura di eventi di monitoraggio e ricezione di report sugli stessi.
S6t – interfaccia tra SCEF e HSS. Necessario per l'autenticazione dell'abbonato, l'autorizzazione dei server delle applicazioni, l'ottenimento di una combinazione di ID esterno e IMSI/MSISDN, il provisioning degli eventi di monitoraggio e la ricezione di report sugli stessi.
S6m/T4 – interfacce da SCEF a HSS e SMS-C (3GPP definisce il nodo MTC-IWF, utilizzato per l'attivazione del dispositivo e la trasmissione di SMS nelle reti NB-IoT. Tuttavia, in tutte le implementazioni la funzionalità di questo nodo è integrata in SCEF, quindi per semplificazione del circuito non lo considereremo separatamente). Utilizzato per ottenere informazioni di instradamento per l'invio di SMS e l'interazione con il centro SMS.
T8 – Interfaccia API per l'interazione SCEF con i server delle applicazioni. Sia i comandi di controllo che il traffico vengono trasmessi attraverso questa interfaccia.
*in realtà ci sono più interfacce; qui vengono elencate solo quelle più basilari. Un elenco completo è fornito in 3GPP 23.682 (4.3.2 Elenco dei punti di riferimento).
Di seguito sono elencate le principali funzioni e servizi di SCEF:
- collegare l'identificatore della carta SIM (IMSI) all'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 dati con conferma;
- buffering dei dati MO (Mobile Originated) e MT (Mobile Terminated);
- autenticazione e autorizzazione di dispositivi e server applicativi;
- utilizzo simultaneo di dati da una UE da parte di più AS;
- supporto per funzioni speciali di monitoraggio dello status dell'UE (MONTE – Monitoring Events);
- attivazione del dispositivo;
- fornitura di roaming dati non IP.
Il principio fondamentale dell'interazione tra AS e SCEF si basa sul cosiddetto schema. abbonamenti. Se è necessario ottenere l'accesso a qualsiasi servizio SCEF per una UE specifica, il server delle applicazioni deve creare una sottoscrizione inviando un comando all'API specifica del servizio richiesto e ricevere in risposta un identificatore univoco. Successivamente tutte le ulteriori azioni e comunicazioni con l'UE nell'ambito di questo servizio avverranno utilizzando questo identificatore.
ID esterno: identificatore universale del dispositivo
Uno dei cambiamenti più importanti nello schema di interazione tra AS e dispositivi quando si lavora tramite SCEF è la comparsa di un identificatore universale. Ora invece del numero di telefono (MSISDN) o dell'indirizzo IP, come avveniva nella classica rete 2G/3G/LTE, l'identificatore del dispositivo per il server delle applicazioni diventa “ID esterno”. È definito dallo standard in un formato familiare agli sviluppatori di applicazioni “ @ "
Gli sviluppatori non hanno più bisogno di implementare algoritmi di autenticazione del dispositivo; la rete assume completamente questa funzione. L'ID esterno è legato all'IMSI e lo sviluppatore può essere sicuro che quando accede a uno specifico ID esterno interagisce con una specifica scheda SIM. Quando si utilizza un chip SIM, si ottiene una situazione completamente unica in cui l'ID esterno identifica in modo univoco un dispositivo specifico!
Inoltre, più ID esterni possono essere collegati a un IMSI: una situazione ancora più interessante si verifica quando l'ID esterno identifica in modo univoco un'applicazione specifica responsabile di un servizio specifico su un dispositivo specifico.
Viene visualizzato anche un identificatore di gruppo: ID gruppo esterno, che include una serie di ID esterni individuali. Ora, con una richiesta a SCEF, AS può avviare operazioni di gruppo, inviando dati o comandi di controllo a più dispositivi uniti in un unico gruppo logico.
Poiché per gli sviluppatori AS il passaggio a un nuovo identificatore di dispositivo non può essere istantaneo, SCEF ha lasciato la possibilità di comunicazione AS con l'UE tramite un numero standard: MSISDN.
Trasmissione di traffico non IP (Non-IP Data Delivery, NIDD)
In NB-IoT, nell'ambito dell'ottimizzazione dei meccanismi per la trasmissione di piccole quantità di dati, oltre ai tipi PDN già esistenti, come IPv4, IPv6 e IPv4v6, è apparso un altro tipo: non IP. In questo caso al dispositivo (UE) non viene assegnato un indirizzo IP e i dati vengono trasmessi senza utilizzare il protocollo IP. Il traffico per tali collegamenti può essere instradato in due modi: classico - MME -> SGW -> PGW e poi attraverso il tunnel PtP verso AS (Fig. 2) o utilizzando SCEF (Fig. 3).
Il metodo classico non offre particolari vantaggi rispetto al traffico IP, tranne la riduzione della dimensione dei pacchetti trasmessi grazie all'assenza di intestazioni IP. L'utilizzo di SCEF apre una serie di nuove possibilità e semplifica notevolmente le procedure di interazione con i dispositivi.
Nella trasmissione dei dati tramite SCEF si presentano due vantaggi molto importanti rispetto al classico traffico IP:
Consegna del traffico MT al dispositivo tramite ID esterno
Per inviare un messaggio ad un dispositivo IP classico, l'AS deve conoscere il suo indirizzo IP. Qui sorge un problema: poiché il dispositivo riceve solitamente un indirizzo IP “grigio” al momento della registrazione, comunica con il server dell'applicazione, che si trova su Internet, attraverso un nodo NAT, dove l'indirizzo grigio viene tradotto in bianco. La combinazione di indirizzi IP grigi e bianchi dura per un tempo limitato, a seconda delle impostazioni NAT. In media, per TCP o UDP, non più di cinque minuti. Cioè, se non avviene alcuno scambio di dati con questo dispositivo entro 5 minuti, la connessione si disintegrerà e il dispositivo non sarà più accessibile all'indirizzo bianco con cui è stata avviata la sessione con AS. Esistono diverse soluzioni:
1. Usa il battito cardiaco. Una volta stabilita la connessione, il dispositivo deve scambiare pacchetti con l'AS ogni pochi minuti, impedendo così la chiusura delle traduzioni NAT. Ma qui non si può parlare di efficienza energetica.
2. Controllare ogni volta, se necessario, la disponibilità dei pacchetti per il dispositivo sull'AS - inviare un messaggio all'uplink.
3. Creare un APN privato (VRF), in cui il server delle applicazioni e i dispositivi si troveranno sulla stessa sottorete e assegnare indirizzi IP statici ai dispositivi. Funzionerà, ma è quasi impossibile quando si parla di un parco di migliaia, decine di migliaia di dispositivi.
4. Infine, l'opzione più adatta: utilizzare IPv6, non richiede NAT, poiché gli indirizzi IPv6 sono direttamente accessibili da Internet. Tuttavia, anche in questo caso, quando il dispositivo verrà nuovamente registrato, riceverà un nuovo indirizzo IPv6 e non sarà più accessibile utilizzando quello precedente.
Di conseguenza, è necessario inviare al server un pacchetto di inizializzazione con un identificatore del dispositivo per segnalare il nuovo indirizzo IP del dispositivo. Attendere poi un pacchetto di conferma da parte di AS, che incide anche sull'efficienza energetica.
Questi metodi funzionano bene per i dispositivi 2G/3G/LTE, dove il dispositivo non ha requisiti rigorosi di autonomia e, di conseguenza, non ci sono restrizioni sul tempo di trasmissione e sul traffico. Questi metodi non sono adatti per NB-IoT a causa del loro elevato consumo energetico.
SCEF risolve questo problema: poiché l'unico identificatore del dispositivo per un AS è un ID esterno, l'AS deve solo inviare un pacchetto di dati a SCEF per un ID esterno specifico e SCEF si occupa del resto. Nel caso in cui il dispositivo sia in modalità di risparmio energetico PSM o eDRX, i dati verranno memorizzati nel buffer e consegnati quando il dispositivo sarà disponibile. Se il dispositivo è disponibile per il traffico, i dati verranno consegnati immediatamente. Lo stesso vale per i team di gestione.
In qualsiasi momento, l'AS può richiamare il messaggio bufferizzato nell'UE o sostituirlo con uno nuovo.
Il meccanismo di buffering può essere utilizzato anche quando si trasmettono dati MO dalla UE all'AS. Se SCEF non è in grado di fornire immediatamente i dati all'AS, ad esempio se sono in corso lavori di manutenzione sui server dell'AS, questi pacchetti verranno bufferizzati e garantiti per essere consegnati non appena l'AS sarà disponibile.
Come notato sopra, l'accesso a un servizio specifico e a un UE per un AS (e NIDD è un servizio) è regolato da regole e politiche da parte di SCEF, che consentono la possibilità unica di utilizzo simultaneo di dati da un UE da parte di diversi AS. Quelli. se diversi AS hanno aderito ad un UE, allora dopo aver ricevuto i dati dall'UE, SCEF li invierà a tutti gli AS iscritti. Ciò è particolarmente adatto ai casi in cui il creatore di una flotta di dispositivi specializzati condivide i dati tra diversi clienti. Ad esempio, creando una rete di stazioni meteorologiche in esecuzione su NB-IoT, è possibile vendere i dati da esse a molti servizi contemporaneamente.
Meccanismo di consegna dei messaggi garantito
Reliable Data Service è un meccanismo per la consegna garantita di messaggi MO e MT senza l'uso di algoritmi specializzati a livello di protocollo, come ad esempio l'handshake in TCP. Funziona includendo un flag speciale nella parte di servizio del messaggio quando scambiato tra UE e SCEF. Se attivare o meno questo meccanismo durante la trasmissione del traffico è deciso dall'AS.
Se il meccanismo è attivato, l'UE include un flag speciale nella parte aerea del pacchetto quando richiede la consegna garantita del traffico MO. Al ricevimento di tale pacchetto, lo SCEF risponde all'UE con una conferma. Se la UE non riceve il pacchetto di riconoscimento, il pacchetto verso SCEF verrà reinviato. La stessa cosa accade per il traffico MT.
Monitoraggio dispositivi (monitoraggio eventi - MONTE)
Come accennato in precedenza, la funzionalità SCEF comprende, tra le altre cose, funzioni per il monitoraggio dello stato dell'UE, le cosiddette. monitoraggio del dispositivo. E se i nuovi identificatori e i meccanismi di trasferimento dei dati sono ottimizzazioni (anche se molto serie) delle procedure esistenti, allora MONTE è una funzionalità completamente nuova che non è disponibile nelle reti 2G/3G/LTE. MONTE consente ad AS di monitorare i parametri del dispositivo come lo stato della connessione, la disponibilità della comunicazione, la posizione, lo stato del roaming, ecc. Ne parleremo più dettagliatamente un po' più tardi.
Se è necessario attivare un qualsiasi evento di monitoraggio per un dispositivo o gruppo di dispositivi, l'AS si iscrive al servizio corrispondente inviando a SCEF il corrispondente comando API MONTE, che include parametri come Id esterno o ID gruppo esterno, identificatore AS, monitoraggio tipo, numero di report, che AS desidera ricevere. Se l'AS è autorizzato a eseguire la richiesta, SCEF, a seconda della tipologia, metterà a disposizione l'evento all'HSS o alla MME (Fig. 4). Quando si verifica un evento, la MME o l'HSS genera un rapporto allo SCEF, che lo invia all'AS.
Il provisioning di tutti gli eventi, ad eccezione del “Numero di UE presenti in un'area geografica”, avviene tramite HSS. Due eventi "Modifica dell'associazione IMSI-IMEI" e "Stato di roaming" vengono tracciati direttamente su HSS, il resto verrà fornito da HSS su MME.
Gli eventi possono essere singoli o periodici e sono determinati dal tipo.
L'invio della segnalazione di un evento (reporting) viene effettuato dal nodo che traccia l'evento direttamente a SCEF (Fig. 5).
Punto importante: Il monitoraggio degli eventi può essere applicato sia ai dispositivi non IP collegati tramite SCEF sia ai dispositivi IP che trasmettono dati in modo classico tramite MME-SGW-PGW.
Diamo uno sguardo più da vicino a ciascuno degli eventi di monitoraggio:
Perdita di connettività — informa l'AS che l'UE non è più disponibile né per il traffico dati né per la segnalazione. L'evento si verifica quando il "timer di raggiungibilità mobile" per l'UE scade sulla MME. In una richiesta per questo tipo di monitoraggio, l'AS può indicare il suo valore di “Tempo massimo di rilevamento” - se durante questo tempo l'UE non mostra alcuna attività, l'AS verrà informato che l'UE non è disponibile, indicandone il motivo. L'evento si verifica anche se l'UE è stata rimossa forzatamente dalla rete per qualsiasi motivo.
* Per far sapere alla rete che il dispositivo è ancora disponibile, periodicamente avvia una procedura di aggiornamento - Tracking Area Update (TAU). La frequenza di questa procedura viene impostata dalla rete tramite il timer T3412 o (T3412_extended nel caso di PSM), il cui valore viene trasmesso al dispositivo durante la procedura di Allega o il TAU successivo. Il timer di raggiungibilità mobile è in genere più lungo di diversi minuti rispetto a T3412. Se la UE non ha effettuato un TAU prima della scadenza del “Timer di raggiungibilità mobile”, la rete la considera non più raggiungibile.
Raggiungibilità dell'UE – Indica quando l'UE diventa disponibile per il traffico DL o SMS. Ciò si verifica quando l'UE diventa disponibile per il paging (per un UE in modalità eDRX) o quando l'UE entra in modalità ECM-CONNECTED (per un UE in modalità PSM o eDRX), vale a dire effettua un TAU o invia un pacchetto uplink.
Segnalazione della posizione – Questo tipo di eventi di monitoraggio consente all'AS di interrogare la posizione dell'UE. È possibile richiedere la posizione corrente (Current Location) o l'ultima posizione nota (Last Known Location, determinata dall'ID della cella da cui il dispositivo ha effettuato TAU o trasmesso traffico l'ultima volta), che è rilevante per i dispositivi in modalità risparmio energetico PSM o eDRX modalità. Per la "Posizione corrente", l'AS può richiedere risposte ripetute, con la MME che informa l'AS ogni volta che cambia la posizione del dispositivo.
Cambiamento dell'associazione IMSI-IMEI – Quando questo evento viene attivato, SCEF inizia a monitorare le modifiche nella combinazione di IMSI (identificatore della carta SIM) e IMEI (identificatore del dispositivo). Quando si verifica un evento, informa AS. Può essere utilizzato per riassociare automaticamente un ID esterno a un dispositivo durante un lavoro di sostituzione programmato o fungere da identificatore in caso di furto di un dispositivo.
Stato di roaming – questo tipo di monitoraggio viene utilizzato dall'AS per determinare se l'UE si trova nella rete domestica o nella rete di un partner in roaming. Opzionalmente può essere trasmessa la PLMN (Public Land Mobile Network) dell'operatore presso il quale è registrato l'apparecchio.
Errore di comunicazione — Questo tipo di monitoraggio informa l'AS di eventuali guasti nella comunicazione con il dispositivo, in base ai motivi della perdita di connessione (codice causa rilascio) ricevuti dalla rete di accesso radio (protocollo S1-AP). Questo evento può aiutare a determinare il motivo per cui la comunicazione non è riuscita, a causa di problemi sulla rete, ad esempio quando l'eNodeb è sovraccarico (risorse radio non disponibili) o a causa di un guasto del dispositivo stesso (connessione radio con UE persa).
Disponibilità dopo errore DDN – questo evento informa l'AS che il dispositivo è diventato disponibile dopo un errore di comunicazione. Può essere utilizzato quando è necessario trasferire dati a un dispositivo, ma il tentativo precedente non è andato a buon fine perché l'UE non ha risposto a una notifica dalla rete (paging) e i dati non sono stati consegnati. Se questo tipo di monitoraggio è stato richiesto per l'UE, allora non appena il dispositivo effettua una comunicazione in entrata, effettua un TAU o invia dati all'uplink, l'AS verrà informato che il dispositivo è diventato disponibile. Poiché tra MME e S/P-GW funziona la procedura DDN (downlink data notification), questo tipo di monitoraggio è disponibile solo per i dispositivi IP.
Stato della connettività PDN – informa l'AS quando cambia lo stato del dispositivo (stato connettività PDN) - connessione (attivazione PDN) o disconnessione (cancellazione PDN). Questo può essere utilizzato dall'AS per avviare la comunicazione con l'UE, o viceversa, per capire 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 area geografica.
Attivazione del dispositivo)
Nelle reti 2G/3G la procedura di registrazione nella rete era in due fasi: prima il dispositivo si registrava al SGSN (procedura di collegamento), quindi, se necessario, attivava il contesto PDP - una connessione con il packet gateway (GGSN) per trasmettere dati. Nelle reti 3G queste due procedure avvenivano in sequenza, cioè il dispositivo non ha aspettato il momento in cui era necessario trasferire i dati, ma ha attivato il PDP immediatamente dopo aver completato la procedura di collegamento. In LTE queste due procedure sono state combinate in una, ovvero durante il collegamento l'apparecchio ha richiesto immediatamente l'attivazione della connessione PDN (analoga al PDP in 2G/3G) tramite l'eNodeB all'MME-SGW-PGW.
NB-IoT definisce un metodo di connessione come "collegamento senza PDN", ovvero l'UE si collega senza stabilire una connessione PDN. In questo caso non è disponibile per trasmettere traffico e può solo ricevere o inviare SMS. Per inviare un comando a tale dispositivo per attivare il PDN e connettersi all'AS, è stata sviluppata la funzionalità "Attivazione dispositivo".
Quando si riceve un comando per connettere tale UE dall'AS, SCEF avvia l'invio di un SMS di controllo al dispositivo attraverso il centro SMS. Alla ricezione di un SMS il dispositivo attiva il PDN e si connette all'AS per ricevere ulteriori istruzioni o trasferire dati.
Potrebbero verificarsi momenti in cui l'abbonamento del dispositivo scade su SCEF. Sì, l'abbonamento ha una propria durata, stabilita dall'operatore o concordata con AS. Alla scadenza il PDN verrà disattivato sulla MME e il dispositivo non sarà più disponibile per l'AS. In questo caso, anche la funzionalità “Attivazione dispositivo” sarà di aiuto. Quando si ricevono nuovi dati da AS, SCEF scoprirà lo stato di connessione del dispositivo e invierà i dati tramite canale SMS.
conclusione
La funzionalità di SCEF, ovviamente, non si limita ai servizi sopra descritti ed è in continua evoluzione ed espansione. Attualmente sono già stati standardizzati più di una dozzina di servizi per SCEF. Ora abbiamo toccato solo le funzioni principali richieste dagli sviluppatori, del resto parleremo nei prossimi articoli.
Sorge immediatamente la domanda: come ottenere l'accesso di prova a questo nodo "miracoloso" per i test preliminari e il debug di possibili casi? Tutto è molto semplice. Qualsiasi sviluppatore può inviare una richiesta a [email protected], in cui è sufficiente indicare lo scopo del collegamento, la descrizione di un possibile caso e i dati di contatto per la comunicazione.
Fino a quando ci incontriamo di nuovo!
Autori:
- esperto senior del dipartimento di soluzioni convergenti e servizi multimediali Sergey Novikov ,
- esperto del dipartimento di soluzioni convergenti e servizi multimediali Alexey Lapshin
Fonte: habr.com