{"id":52138,"date":"2019-11-01T00:00:00","date_gmt":"2019-10-31T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/nb-iot-kak-on-rabotaet-chast-3-scef-edinoe-okno-dostupa-k-uslugam-operatora"},"modified":"2020-02-18T13:59:48","modified_gmt":"2020-02-18T10:59:48","slug":"nb-iot-kak-on-rabotaet-chast-3-scef-edinoe-okno-dostupa-k-uslugam-operatora","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/nb-iot-kak-on-rabotaet-chast-3-scef-edinoe-okno-dostupa-k-uslugam-operatora","title":{"rendered":"NB-IoT: come funziona? Parte 3: SCEF \u2013 un'unica interfaccia per accedere ai servizi dell'operatore","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><b>Nell'articolo \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/ru_mts\/blog\/431648\/\">NB-IoT: come funziona? Parte 2<\/a><\/noindex>\u00bb, 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.<\/b><\/p>\n<p><img decoding=\"async\" alt=\"NB-IoT: come funziona? Parte 3: SCEF \u2013 un&#039;unica interfaccia per accedere ai servizi dell&#039;operatore\" src=\"\/wp-content\/uploads\/2019\/11\/95652a1e2bfce0589b51b106ebf6e64f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNella creazione di un servizio M2M, gli sviluppatori di applicazioni si trovano ad affrontare le seguenti domande:<\/p>\n<ul>\n<li>come identificare i dispositivi;<\/li>\n<li>quale algoritmo utilizzare per la verifica e conferma dell'autenticit\u00e0;<\/li>\n<li>quale protocollo di trasporto scegliere per interagire con i dispositivi;<\/li>\n<li>come garantire la consegna dei dati ai dispositivi;<\/li>\n<li>come organizzare e stabilire le regole per lo scambio di dati con loro;<\/li>\n<li>come controllare e ricevere in tempo reale informazioni sul loro stato;<\/li>\n<li>come inviare dati simultaneamente a un gruppo di propri dispositivi;<\/li>\n<li>come inviare simultaneamente dati da un dispositivo a pi\u00f9 client;<\/li>\n<li>come ottenere un accesso unificato ai servizi aggiuntivi dell'operatore per la gestione del proprio dispositivo. <\/li>\n<\/ul>\n<p>\nPer risolverli, \u00e8 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.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Secondo la definizione 3GPP, SCEF (service capability exposure function) \u00e8 un nuovo componente dell'architettura 3GPP, la cui funzione \u00e8 quella di esporre in modo sicuro i servizi e le possibilit\u00e0 forniti dalle interfacce di rete 3GPP tramite API. <\/p>\n<p>In parole semplici, SCEF \u00e8 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.<\/p>\n<p>SCEF nasconde la complessit\u00e0 della rete dell'operatore, consentendo agli sviluppatori di applicazioni di astrarsi da meccanismi di interazione complessi e specifici con i dispositivi.<\/p>\n<p>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\u00e0, delegando tali compiti all'operatore.<\/p>\n<p>SCEF gestisce le interfacce necessarie per l'autenticazione e l'autorizzazione dei server delle applicazioni, il mantenimento della mobilit\u00e0 dell'UE, la trasmissione dei dati e il triggering dei dispositivi, l'accesso a servizi e funzionalit\u00e0 aggiuntive della rete dell'operatore.<\/p>\n<p>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).<\/p>\n<p><img decoding=\"async\" alt=\"NB-IoT: come funziona? Parte 3: SCEF \u2013 un&#039;unica interfaccia per accedere ai servizi dell&#039;operatore\" src=\"\/wp-content\/uploads\/2019\/11\/6538d7d9e0d94244e6415b78f080b159.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nT6a \u00e8 l'interfaccia tra SCEF e MME. Viene utilizzata per procedure di gestione della mobilit\u00e0\/sessione, trasmissione di dati non-IP, provisioning di eventi di monitoraggio e ricezione di report su di essi.<\/p>\n<p>S6t \u00e8 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.<\/p>\n<p>S6m\/T4 \u2013 interfacce da SCEF a HSS e SMS-C (nel 3GPP \u00e8 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\u00e0 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.<\/p>\n<p>T8 \u2013 interfaccia API per l'interazione tra SCEF e i server delle applicazioni. Tramite questa interfaccia vengono trasmessi sia comandi di controllo che traffico.<\/p>\n<p>*in realt\u00e0 ci sono pi\u00f9 interfacce, qui sono elencate solo le pi\u00f9 fondamentali. L'elenco completo \u00e8 riportato nel 3GPP 23.682 (4.3.2 Elenco dei Punti di Riferimento).<\/p>\n<p>Di seguito sono riportate le funzioni chiave e i servizi di SCEF:<\/p>\n<ul>\n<li>associazione dell'identificativo della SIM (IMSI) a un ID esterno; <\/li>\n<li>trasmissione di traffico non IP (Non-IP Data Delivery, NIDD);<\/li>\n<li>operazioni di gruppo utilizzando un ID gruppo esterno;<\/li>\n<li>supporto per la modalit\u00e0 di trasmissione dei dati con conferma;<\/li>\n<li>bufferizzazione dei dati MO (Mobile Originated) e MT (Mobile Terminated);<\/li>\n<li>autenticazione e autorizzazione dei dispositivi e dei server delle applicazioni;<\/li>\n<li>uso simultaneo dei dati di un singolo UE da parte di pi\u00f9 AS;<\/li>\n<li>supporto delle funzionalit\u00e0 speciali di monitoraggio dello stato UE (MONTE \u2013 Monitoring Events);<\/li>\n<li>triggering dei dispositivi;<\/li>\n<li>garantire il roaming dei dati non IP.<\/li>\n<\/ul>\n<p>\nIl principio fondamentale di interazione tra AS e SCEF si basa sul modello delle cosiddette sottoscrizioni. Quando \u00e8 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.<\/p>\n<p><b>External ID: identificatore universale del dispositivo<\/b><\/p>\n<p>Una delle modifiche pi\u00f9 significative nel modello di interazione tra AS e dispositivi attraverso SCEF \u00e8 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 \u00e8 definito dallo standard in un formato familiare per gli sviluppatori di applicazioni \"@\".<\/p>\n<p>Non \u00e8 pi\u00f9 necessario per gli sviluppatori implementare algoritmi di autenticazione dei dispositivi; la rete si occupa interamente di questa funzione. L'External ID \u00e8 legato all'IMSI e lo sviluppatore pu\u00f2 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!<\/p>\n<p>Inoltre, a un IMSI possono essere associati diversi external ID, creando una situazione ancora pi\u00f9 interessante, in cui l'external ID identifica in modo chiaro un'applicazione specifica responsabile di un determinato servizio su un dispositivo specifico.<\/p>\n<p>Appare anche un identificatore di gruppo \u2014 external group ID, che include un insieme di singoli external ID. Ora, con una sola richiesta al SCEF AS, \u00e8 possibile avviare operazioni di gruppo \u2014 inviare dati o comandi di controllo a molti dispositivi riuniti in un'unica logica gruppo.<\/p>\n<p>Poich\u00e9 per gli sviluppatori AS il passaggio a un nuovo identificatore di dispositivo non pu\u00f2 essere immediato, il SCEF ha mantenuto la possibilit\u00e0 di comunicazione dell'AS con l'UE attraverso un numero standard \u2013 MSISDN.<\/p>\n<p><b>Consegna di dati non IP (Non-IP Data Delivery, NIDD)<\/b><\/p>\n<p>Nel NB-IoT, nell'ambito dell'ottimizzazione dei meccanismi di trasmissione di piccoli volumi di dati, oltre ai gi\u00e0 esistenti tipi di PDN come IPv4, IPv6 e IPv4v6, \u00e8 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\u00f2 essere instradato in due modi: in modo classico \u2014 MME -&gt; SGW -&gt; PGW e poi attraverso un tunnel PtP fino ad AS (fig. 2) oppure utilizzando SCEF (fig. 3). <\/p>\n<p><img decoding=\"async\" alt=\"NB-IoT: come funziona? Parte 3: SCEF \u2013 un&#039;unica interfaccia per accedere ai servizi dell&#039;operatore\" src=\"\/wp-content\/uploads\/2019\/11\/557caf393c9da84fc635c57bb5ecf4a5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl 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\u00e0 e semplifica notevolmente le procedure di interazione con i dispositivi.<\/p>\n<p>Nella trasmissione dei dati tramite SCEF emergono due vantaggi molto importanti rispetto al traffico IP classico: <\/p>\n<p><u>Consegna del traffico MT al dispositivo tramite ID esterno<\/u><\/p>\n<p>Per inviare un messaggio a un dispositivo IP classico, l'AS deve conoscere il suo indirizzo IP. Qui sorge un problema: poich\u00e9 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\u00e0 e il dispositivo non sar\u00e0 pi\u00f9 accessibile tramite l'indirizzo pubblico con cui \u00e8 stata avviata la sessione con l'AS. Ci sono diverse soluzioni: <\/p>\n<p>1. Utilizzare heartbeat. Stabilendo una connessione, il dispositivo deve scambiare pacchetti con l'AS ogni pochi minuti, evitando cos\u00ec che la traduzione su NAT venga chiusa. Ma non si pu\u00f2 parlare di alcuna efficienza energetica in questo caso. <\/p>\n<p>2. Ogni volta che \u00e8 necessario, controllare la presenza di pacchetti per il dispositivo sull'AS: inviare un messaggio nell'uplink.<\/p>\n<p>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\u00e0, ma \u00e8 quasi irrealizzabile quando si tratta di un parco di migliaia o decine di migliaia di dispositivi.<\/p>\n<p>4. Infine, la soluzione pi\u00f9 adatta: utilizzare IPv6, che non richiede NAT, poich\u00e9 gli indirizzi IPv6 sono accessibili direttamente da Internet. Tuttavia, anche in questo caso, quando un dispositivo viene registrato nuovamente, ricever\u00e0 un nuovo indirizzo IPv6 e non sar\u00e0 pi\u00f9 accessibile tramite il precedente. <\/p>\n<p>\u00c8 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.<\/p>\n<p>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.<\/p>\n<p>SCEF risolve questo problema: poich\u00e9 l'unico identificatore del dispositivo per l'AS \u00e8 l'external ID, \u00e8 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\u00e0 risparmio energetico PSM o eDRX, i dati verranno memorizzati in buffer e consegnati quando il dispositivo sar\u00e0 disponibile. Se invece il dispositivo \u00e8 disponibile per il traffico, i dati verranno consegnati immediatamente. Questo vale anche per i comandi di gestione.<\/p>\n<p>In qualsiasi momento, l'AS pu\u00f2 ritirare il messaggio memorizzato in buffer verso l'UE o sostituirlo con uno nuovo.<\/p>\n<p>Il meccanismo di buffering pu\u00f2 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\u00e0 disponibile.<\/p>\n<p>Come accennato sopra, l'accesso a un determinato servizio e UE per AS (e NIDD \u00e8 un servizio) \u00e8 regolato da regole e politiche lato SCEF, consentendo un'opportunit\u00e0 unica di utilizzare simultaneamente i dati di un singolo UE da pi\u00f9 AS. Cio\u00e8, se pi\u00f9 AS si abbonano a un UE, dopo aver ricevuto i dati dall'UE, SCEF li distribuir\u00e0 a tutti gli AS iscritti. Questo \u00e8 particolarmente utile nei casi in cui il creatore di un parco di dispositivi specializzati condivide i dati tra pi\u00f9 clienti. Ad esempio, creando una rete di stazioni meteorologiche basate su NB-IoT, \u00e8 possibile vendere i dati provenienti da esse a molti servizi contemporaneamente.<\/p>\n<p><b>Meccanismo di consegna garantita dei messaggi <\/b><\/p>\n<p>Reliable Data Service \u2014 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. \u00c8 AS a decidere se attivare o meno questo meccanismo durante la trasmissione del traffico.<\/p>\n<p>Se il meccanismo \u00e8 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\u00e0 ritrasmesso. Lo stesso vale anche per il traffico MT.<\/p>\n<p><b>Monitoraggio dei dispositivi (monitoring events- MONTE)<\/b><\/p>\n<p>Come accennato in precedenza, la funzionalit\u00e0 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 \u00e8 una funzionalit\u00e0 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\u00e0 per le comunicazioni, la posizione, lo stato del roaming, ecc. Approfondiremo ciascuno di questi aspetti tra poco.<\/p>\n<p>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 \u00e8 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.<\/p>\n<p>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.<br \/>\nGli eventi possono essere sia occasionali che periodici, a seconda del loro tipo.<\/p>\n<p><img decoding=\"async\" alt=\"NB-IoT: come funziona? Parte 3: SCEF \u2013 un&#039;unica interfaccia per accedere ai servizi dell&#039;operatore\" src=\"\/wp-content\/uploads\/2019\/11\/da265ed0443b7459d28101aa07adf221.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nL'invio del report dell'evento (reporting) avviene da parte del nodo che monitora l'evento, direttamente verso il SCEF (fig. 5).<\/p>\n<p><img decoding=\"async\" alt=\"NB-IoT: come funziona? Parte 3: SCEF \u2013 un&#039;unica interfaccia per accedere ai servizi dell&#039;operatore\" src=\"\/wp-content\/uploads\/2019\/11\/9b385bbc324f14e1d484f1949d926b34.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Un aspetto importante:<\/b> 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.<\/p>\n<p>Esaminiamo pi\u00f9 in dettaglio ciascuno degli eventi di monitoraggio:<\/p>\n<p><u>Perdita di connettivit\u00e0<\/u> \u2014 informa l'AS che l'UE non \u00e8 pi\u00f9 disponibile n\u00e9 per il traffico dati n\u00e9 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\u00f2 specificare il proprio valore di \"Maximum Detection Time\" \u2014 se entro questo tempo l'UE non mostra alcuna attivit\u00e0, l'AS verr\u00e0 informato che l'UE non \u00e8 disponibile, con l'indicazione del motivo. L'evento si verifica anche se l'UE \u00e8 stata rimossa forzatamente dalla rete per qualche motivo.<\/p>\n<p>* Per far sapere alla rete che il dispositivo \u00e8 ancora accessibile, esso avvia periodicamente la procedura di aggiornamento \u2014 Tracking Area Update (TAU). La frequenza di questa procedura \u00e8 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\u00e0 mobile \u00e8 solitamente di alcuni minuti pi\u00f9 lungo rispetto a T3412. Se l'UE non esegue un TAU prima della scadenza del \u201cMobile reachability timer\u201d, la rete lo considera meno accessibile. <\/p>\n<p><u>Accessibilit\u00e0 UE<\/u> \u2013 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\u00e0 eDRX) o quando l'UE passa alla modalit\u00e0 ECM-CONNECTED (per l'UE in modalit\u00e0 PSM o eDRX), cio\u00e8 esegue un TAU o invia un pacchetto uplink.<\/p>\n<p><u>Reporting della posizione<\/u> \u2013 Questo tipo di monitoraggio degli eventi consente all'AS di richiedere dati sulla posizione dell'UE. Pu\u00f2 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 \u00e8 rilevante per i dispositivi in modalit\u00e0 di risparmio energetico PSM o eDRX. Per la \u201cCurrent Location\u201d l'AS pu\u00f2 richiedere report ripetuti, con l'MME che informer\u00e0 l'AS ogni volta che cambia la posizione del dispositivo. <\/p>\n<p><u>Cambiamento dell'associazione IMSI-IMEI<\/u> \u2013 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\u00f2 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.<\/p>\n<p><u>Stato di Roaming<\/u> \u2013 Questo tipo di monitoraggio \u00e8 utilizzato dall'AS per determinare se l'UE \u00e8 nella rete domestica o in quella di un partner di roaming. Facoltativamente, pu\u00f2 essere fornito il PLMN (Public Land Mobile Network) dell'operatore a cui il dispositivo \u00e8 registrato.<\/p>\n<p><u>Fallimento di comunicazione<\/u> \u2014 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\u00f2 aiutare a determinare il motivo per cui si \u00e8 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). <\/p>\n<p><u>Disponibilit\u00e0 dopo il guasto DDN<\/u> \u2013 Questo evento informa l'AS che il dispositivo \u00e8 diventato disponibile dopo un guasto nella comunicazione. Pu\u00f2 essere utilizzato quando \u00e8 necessario inviare dati al dispositivo, ma il tentativo precedente non \u00e8 andato a buon fine, poich\u00e9 l'UE non ha risposto alla notifica della rete (paging) e i dati non sono stati consegnati. Se questo tipo di monitoraggio \u00e8 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\u00e0 informato che il dispositivo \u00e8 diventato disponibile. Poich\u00e9 la procedura DDN (downlink data notification) funziona tra MME e S\/P-GW, questo tipo di monitoraggio \u00e8 disponibile solo per dispositivi IP.<\/p>\n<p><u>Stato di connettivit\u00e0 PDN<\/u> \u2013 informa l'AS quando cambia lo stato del dispositivo (stato di connettivit\u00e0 PDN) \u2013 connessione (attivazione del PDN) o disconnessione (rimozione del PDN). Questo pu\u00f2 essere utilizzato dall'AS per avviare la comunicazione con l'UE, o viceversa, per comprendere che la comunicazione non \u00e8 pi\u00f9 possibile. Questo tipo di monitoraggio \u00e8 disponibile per dispositivi IP e non IP.<\/p>\n<p><u>Numero di UE presenti in un'area geografica<\/u> \u2013 questo tipo di monitoraggio viene utilizzato dall'AS per determinare il numero di UE in una determinata zona geografica.<\/p>\n<p><b>Attivazione dei dispositivi (Device triggering<\/b>)<\/p>\n<p>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 \u2013 connessione con il gateway packet (GGSN). Nelle reti 3G, queste due procedure si svolgevano in sequenza, cio\u00e8 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\u00e8 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.<\/p>\n<p>In NB-IoT, a connection method called \u201cattach without PDN\u201d 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 \u201cDevice triggering\u201d functionality was developed. <\/p>\n<p>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.<\/p>\n<p>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 \u201cDevice triggering\u201d 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.<\/p>\n<p><b>Conclusione<\/b><\/p>\n<p>Le funzionalit\u00e0 di SCEF non si limitano certo ai servizi sopra descritti, ma sono in continua evoluzione e ampliamento. Attualmente, per SCEF sono gi\u00e0 standardizzati pi\u00f9 di una dozzina di servizi. Qui abbiamo trattato solo le funzioni principali e pi\u00f9 richieste dagli sviluppatori; parleremo del resto in articoli futuri. <\/p>\n<p><b>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? \u00c8 molto semplice. Qualsiasi sviluppatore pu\u00f2 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.<br \/>\n<\/b><br \/>\nA presto!<\/p>\n<p><i>Autori: <\/p>\n<ul>\n<li>senior expert in soluzioni convergenti e servizi multimediali Sergey Novikov <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/sanov\/\" class=\"user_link\">sanov<\/a><\/noindex>, <\/li>\n<li>expert in soluzioni convergenti e servizi multimediali Alexey Lapshin <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/aslapsh\/\" class=\"user_link\">aslapsh<\/a><\/noindex><\/li>\n<\/ul>\n<p><\/i><br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/ru_mts\/blog\/473982\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 \u0441\u0442\u0430\u0442\u044c\u0435 \u00abNB-IoT: \u043a\u0430\u043a \u043e\u043d \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442? \u0427\u0430\u0441\u0442\u044c 2\u00bb, \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u044f \u043f\u0440\u043e \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0443 \u043f\u0430\u043a\u0435\u0442\u043d\u043e\u0433\u043e \u044f\u0434\u0440\u0430 \u0441\u0435\u0442\u0438 NB-IoT, \u043c\u044b \u0443\u043f\u043e\u043c\u044f\u043d\u0443\u043b\u0438 \u043f\u0440\u043e \u043f\u043e\u044f\u0432\u043b\u0435\u043d\u0438\u0435 \u043d\u043e\u0432\u043e\u0433\u043e \u0443\u0437\u043b\u0430 SCEF. \u041e\u0431\u044a\u044f\u0441\u043d\u044f\u0435\u043c \u0432 \u0442\u0440\u0435\u0442\u044c\u0435\u0439 \u0447\u0430\u0441\u0442\u0438, \u0447\u0442\u043e \u0436\u0435 \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u0438 \u0437\u0430\u0447\u0435\u043c \u044d\u0442\u043e \u043d\u0443\u0436\u043d\u043e? \u041f\u0440\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0438 M2M-\u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u044e\u0442\u0441\u044f \u0441\u043e \u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0438\u043c\u0438 \u0432\u043e\u043f\u0440\u043e\u0441\u0430\u043c\u0438: \u043a\u0430\u043a \u0438\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u0446\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0430; \u043a\u0430\u043a\u043e\u0439 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c \u0430\u043b\u0433\u043e\u0440\u0438\u0442\u043c \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0438 \u0438 \u043f\u043e\u0434\u0442\u0432\u0435\u0440\u0436\u0434\u0435\u043d\u0438\u044f \u043f\u043e\u0434\u043b\u0438\u043d\u043d\u043e\u0441\u0442\u0438; \u043a\u0430\u043a\u043e\u0439 \u0432\u044b\u0431\u0440\u0430\u0442\u044c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-52138","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.0.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412 \u0441\u0442\u0430\u0442\u044c\u0435 \u00abNB-IoT: \u043a\u0430\u043a \u043e\u043d \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442?\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/nb-iot-kak-on-rabotaet-chast-3-scef-edinoe-okno-dostupa-k-uslugam-operatora\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47NB-IoT: \u043a\u0430\u043a \u043e\u043d \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442? \u0427\u0430\u0441\u0442\u044c 3: SCEF \u2013 \u0435\u0434\u0438\u043d\u043e\u0435 \u043e\u043a\u043d\u043e \u0434\u043e\u0441\u0442\u0443\u043f\u0430 \u043a \u0443\u0441\u043b\u0443\u0433\u0430\u043c \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412 \u0441\u0442\u0430\u0442\u044c\u0435 \u00abNB-IoT: \u043a\u0430\u043a \u043e\u043d \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442?\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/nb-iot-kak-on-rabotaet-chast-3-scef-edinoe-okno-dostupa-k-uslugam-operatora\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T10:59:48+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47NB-IoT: come funziona? Parte 3: SCEF \u2013 punto unico di accesso ai servizi dell'operatore | ProHoster","description":"Nell'articolo \"NB-IoT: come funziona?\"","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/nb-iot-kak-on-rabotaet-chast-3-scef-edinoe-okno-dostupa-k-uslugam-operatora","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47NB-IoT: \u043a\u0430\u043a \u043e\u043d \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442? \u0427\u0430\u0441\u0442\u044c 3: SCEF \u2013 \u0435\u0434\u0438\u043d\u043e\u0435 \u043e\u043a\u043d\u043e \u0434\u043e\u0441\u0442\u0443\u043f\u0430 \u043a \u0443\u0441\u043b\u0443\u0433\u0430\u043c \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430 | ProHoster","og:description":"\u0412 \u0441\u0442\u0430\u0442\u044c\u0435 \u00abNB-IoT: \u043a\u0430\u043a \u043e\u043d \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442?","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/nb-iot-kak-on-rabotaet-chast-3-scef-edinoe-okno-dostupa-k-uslugam-operatora","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T21:00:00+00:00","article:modified_time":"2020-02-18T10:59:48+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"52138","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 02:37:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:48:32","updated":"2026-01-24 02:37:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/52138","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=52138"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/52138\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=52138"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=52138"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=52138"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}